►
From YouTube: 2021/12/02 - Backdrop Weekly Dev
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
This
is
the
weekly
backdrop
developer
meeting
where
we
talk
about
the
development
tests
that
are
in
front
of
backdrop,
community
members,
and
we
talk
about
how
we
can
move
things
forward.
My
name
is
nate
lampton,
I'm
quick
sketch
on
the
internet
and
I'm
a
core
committer.
We'll
do
other
introductions
here.
Robert.
Could
you
go
and
then
greg.
B
A
Thank
you
greg
and
then
tim.
C
Hey
greg,
I'm
joining
from
greece
generally
interested
in
anything
related
to
backdrop,
and
any
way
that
I
can
help
very
excited
about
activity
in
the
issue
queue.
A
lot
of
issues
are
ready
to
be
committed
and
a
lot
of
work
being
done
by
all
this.
So
yeah
thanks.
D
A
Thanks
tim,
joseph
and
then
justin.
E
E
A
Well
glad
you're,
still,
you
know
where
your
home
is
so.
D
F
I'm
jessica
christopherson,
I'm
in
denver,
colorado
and
contribute
to
the
infrastructure
when
I
can
and
some
contributed
modules.
Recently,
thanks
thanks.
B
A
Let's
see
jenna's
not
on
the
meeting
today,
she
normally
does
the
community
updates,
but
I
will
go
through
and
cover
those
things.
We
have
three
new
contributed
modules
in
the
last
week,
masonry
gallery
conditional
content,
block
and
devel
sub
themer
modules.
So
thank
you
for
creating
reporting
those
modules.
Some
of
those
are
brand
new
specifically
for
backdrop,
and
some
of
them
are
ports
from
drupal
so
great
to
have
both
kinds
of
modules
coming
in.
A
A
What
do
we
do
about
contrib
projects
that
are
not
modules
and
should
not
be
on
backdropcms.org
or
the
project
installer,
and
the
answer
to
that
looks
like
it's
a
little
bit
fuzzy
right
now,
but
she
noted
that
drush
was
kind
of
an
exception.
That
drush
is
available
and
listed
on
backdrop
cms.org,
but
it's
not
in
the
download
and
search
functionality
inside
of
the
project.
A
Installer
and
possibly,
if
you
have
another
project
that
is
not
a
module
and
should
not
be
on
the
project
installer,
we
could
do
the
same
thing
as
drush,
which
is
apparently
what
happened
is
that
drush
is
a
manually
created
node
on
backdrop
cms.org
on
which
we've
turned
off
releases,
and
so
that
makes
it
so
that,
even
if
there
is
a
release
in
github
when
it
comes
over
to
backdrop
cms.org,
it
doesn't
create
a
release
on
the
node
so
that
it
won't
show
up
in
the
project
installer
and
it
won't
show
up
on
the
releases
node
on
backdrop
cms.org.
A
And
then,
if
we
want
to
prevent
it
from
creating
release,
notes
on
backdrop
cms.org,
we
could
either
manually
create
a
release
or
a
project
on
backdrop,
cms.org
and
disable
it
or
the
first
time
you
make
an
official
release.
It
will
automatically
create
a
node
on
backdrop
cms.org
to
match
it,
and
then
we
could
edit
that
node
and
then
disable
releases
after
the
fact.
So
I'd
probably
say,
let's,
like
pre,
proactively,
create
the
node
on
backdrop.
Cms.Org
to
you
know,
silence
it.
C
C
A
A
node
type
on
backdropcms.org
called
project
placeholder
and
those
modules
don't
show
up
anywhere
that
I
can
find
other
than
if
you
go
directly
to
those
pages
and
a
good
example
of
that
is
ck,
editor
module,
but
also
it
applies
to
like
link
email,
any
module.
That's
been
moved
into
core
or
a
lot
of
modules
that
have
been
moved
into
query
they've
been
converted
into
like
placeholders
on
backdrop
cms.org,
I
think,
possibly
to
reserve
the
namespace
so
that
you
don't
create
a
module
with
the
same
name
as
the
one
that's
already
in
core.
A
We
could
also
create
a
placeholder
project
for
for
for
something
that
is
not
module,
because
we
don't
really
have
a
good
way
of
handling
these,
like
non-non-module
modules
still.
A
But
I
like
the
idea
of
like
I
think
we
have
an
issue
that
there's
actually
been
recent
discussion
on
about
like
supporting
more
data
in
dot
info
files,
where
you
start
putting
tags
and
stuff
like
that
in
there
like
just
generally
speaking,
the
dot
info
file
would
be
the
solution
to
this
problem
that
if
we
want
to
have
a
new
type,
because
there's
type
equals
module
typical
theme.
If
you
want
to
make
a
new
type
type,
equals
placeholder
type
equals
other
or
miscellaneous,
or
something
like
that,
we
can
do
that.
A
We
need
to
decide
what
that
should
be
and
what
it
should
do,
and
then
we
can
incorporate
that
into
the
packager.
So
when
a
release
is
created
on
github,
it
sends
a
release
notification
to
backdropcms.org
that
does
the
packaging
that
creates
the
archive,
creates
nodes,
create
release
nodes,
does
all
the
work
on
backdrop
cms.org,
and
then
we
can
decide.
You
know
if
we
decide
that
there's
some
special
functionality
we
could
make
it
do
new
things.
A
Does
anyone
have
thoughts
or
suggestions
on
like
what
it
is
that
we
want
for
this
kind
of
thing
for
a
project?
That's
not
a
module,
so
drush
be
anagozella,
brought
up
the
php
cs
sniffs
as
another
thing:
it's
not
really
a
module
but
would
exist
in
backdrop.
Contrib.
C
A
A
How
would
you
find
a
module
like
like
drosh,
for
example,
like
we,
don't
have
a
mechanism
for
that
on
backdropcms.org
like?
Where?
Should
we
put
it?
You
know,
because
the
search
is
for
modules.
It's
literally
you
go
to
modules
first
and
then
there's
the
search.
D
Well,
we
have
a
themes,
search
and
a
module
search.
Don't
we
so
couldn't
we
have
a
an
other
page
or
we're
one
thing
that
searches,
everything
I
don't
know
yeah.
I
just
like
a
different
project
type
on
backdrop.org,
that's
separate
from
the
modules
yeah.
C
B
A
A
B
A
Yeah,
okay,
yeah-
these
are
are
all
good
ideas,
but
for
now
the
short
version
is
go
ahead
and
throw
it
in
backdrop,
contrib
we'll
figure
out
what
to
do
with
it
in
the
future.
I
think
we
can
hang
on.
Let
me
see
if
we
can
actually
change.
A
No,
you
cannot
change,
we'll
have
to
figure
it
out,
but
the
the
backdrop
the
corresponding
node
that
is
created
on
backdropcms.org,
there's
different
node
types
for
node
versus
or
sorry
module
versus
theme,
and
I
think
that
might
be
because
there's
different
fields
depending
on
whether
or
not
it's
a
theme
versus
a
module
which
I
could
see
happening.
A
So
if
you
create
a
project
right
now.
Well,
first
of
all,
if
there's
no
dot
info
file
doesn't
matter
what
you
you
do,
it
won't
show
up
on
backdrop
cms.org
period,
and
so
I
think
just
putting
it
in
backdrop
contrib.
If
there's
no
info
file
at
all,
that
will
prevent
it
from
creating
a
matching
node,
because
it
won't
know
what
type
of
node
it
should
create.
A
B
If
there
is
a
dot
info
file,
but
the
type
field
is
missing,
does
that
just
not
get
anything
moved
into
v.org
or.
A
Yeah
streams
it
will,
it
will
do
a
couple
of
things.
It
will
not
make
a
node
on
backdropcms.org,
but
what
backdropcms.org
will
do
when
it
gets
a
notification
of
a
new
module
existing
and
contrib?
It
looks
for
a
dot
info
file
and
if
it
can't
find
one
or
if
the
type
is
equal
to
something,
that's
not
module,
theme
or
layout.
What
it
will
do
is
it'll
upload,
a
txt
file
to
the
release
thing
on
github.
That
is
the
the
log.
The
message
the
log
that
says
this
is
a
failure
like
I
failed
to
create.
A
For
this
reason,
and
if
you
open
up
the
text
file,
it'll
tell
you
there's
something
wrong
with
your
repository,
because
your
dot
info
file
is
doesn't
isn't
valid,
which
is
could
be
undesirable
for
a
project
that
intentionally
doesn't
have
a
dot
info
file.
But
for
the
time
being,
a
module.
Maintainer
can
just
simply
delete
that
file
from
the
release
node
and
then
that
that
will
solve
the
problem.
A
C
Yeah
and
it's
like
one
of
those
things
that
involves
both
infrastructure
changes
in
the
backdrop
cms.org,
the
gitlab
github
integration
that
we
have
the
module.
So
the
core
related
thing
is
that,
if
we
come
up
with
a
with
another
project
type
is
that
the
the
project
installer
should
skip
or
ignore
the
type
of
those
projects,
and
so
not
to
show
them
within
backdrop
like
within
the
software.
A
Yeah,
which
yeah,
which,
as
long
as
it's
not
a
modular
theme,
you
know
that
will
happen
automatically
yeah.
So
I
think
the
key
thing
is
for
now.
I
put
it
in
backdrop
contrib,
but
don't
declare
its
type
equals
module.
Otherwise
it
will
start
showing
up
yeah.
E
A
Project
integration
is
on
backdrop,
cms.org
right
now
too,
so
there's
actually
no
con,
no
core
work.
That
needs
to
be
done
here.
This
is
purely
a
backdrop.
Cms.Org
thing.
A
Okay,
let's
see
next
topic,
we
have
here
there's
a
so
hang
on,
maybe
I'll
just
read
to
this
one,
because
because
it
has
a
has
a
lot
of
things,
okay
or
or
tim,
if
you
want
it's
your
concern,
would
you
like
to
summarize
and
say
it
in
your
own
words.
D
This
is
the
issue
about
the
bugs
right:
okay,
so
yeah
really
quickly.
We
had
in
the
prior
to
the
last
security
release.
We
had
discovered
a
bug
in
the
dev
branch
and
we
had
apr
ready
to
go,
but
we
had
we
didn't
flag
that
to
the
core
maintainer
in
any
way,
so
that
when
a
release
was
cut,
the
core
maintainer
was
unaware
of
an
existing
bug
in
the
branch
and
so
number
one.
The
question
is:
how
do
we
in
the
future?
What's
the
best
way
to
handle
that
to
prevent
releasing?
D
You
know,
cutting
a
release
when
we
know
there's
a
bug
there
and
then
I
think
two.
The
follow-up
issue
is:
if
that
does
happen.
How
can
we
better
respond
quickly?
Because
it's
been
two
weeks
now,
where
we've
got
kind
of
a
bad
bug?
D
That's
in
the
it's
basically
in
a
security
release
right
now
and
the
sooner
we
could
have
fixed
this,
the
fewer
people
would
have
to
go
through
the
release
twice
but
anyways.
So
those
are
the
questions.
D
D
If
we
see
a
bug
in
the
in
the
current
dev
branch
is
that
we
specifically
contact,
you
know
a
core
maintainer
and
draw
their
attention
to
it,
but
you
know
I
really
need
to
hear
from
you
nate
like
what
do
you
think
would
work
or
or
how
you
know,
how
does
how
could
we
handle
this?
From
your
perspective,.
A
Well,
I
think
the
solution
that
we
have
right
now,
which
would
have
which
would
have
been
effective
in
this
situation,
would
have
been
reaching
out
via
zulip
to
individual
core
committers
like
myself
or
bw,
panda
or
laryn,
or
any
you
know
the
ones
that
we
have.
That
probably
would
have
worked
to
prevent
this
problem
because
it
was
just
like
we
just
didn't
see
it.
You
know
before
the
release
was
made.
It
did
go
through
the
rtbc
list
before
the
release,
but
it
wasn't
marked
rtbc
yet,
and
so
it
could
have
been.
A
There
was
already
a
pull
request,
and
so
so
we
missed
it
on
that
approach
too.
That
I
think
I
like
to
go
through
the
rdbc
list,
and
I
think
everybody
else
does
too
to
make
sure
that
we
get
in
as
much
as
possible
before
release,
and
so
that
also
would
have
worked,
although
it
would
have
been
incorrect
use
of
our
tags.
A
If
you
would
have
marked
it
rtbc,
I
would
have
looked
at
it,
even
if
it
wasn't,
even
if
it
wasn't
officially
ready
yet
and
I've
seen
people
abuse
that
label
for
that
purpose
before
and
it
is
effective.
Even
though
I
don't
really
like
to
see
it
done
that
way,
so
the
the
problem
with
the
first
approach,
though
that
would
have
been
most
effective
and
correct,
you
know
just
asking
the
court
committers
is
that
not
everybody
knows
who
the
court
committers
are
or
who
would
be
the
best
person
to
tackle
something?
F
A
A
Yeah
and
that's
that's,
the
other
thing
that
I
was
going
to
say
is
that,
like
adding
more
tags,
is
another
thing
that
that's
that's
kind
of
the
solution
that
seems
like
it
would
be
the
right
one
and
yeah.
My
hesitation
is
definitely
yeah.
There's
more
tags.
You
know
that
makes
finding
it
and
needing
to
know
when
to
use
it.
You
know,
that's
a
new
learning
curve
there
as
well
yeah,
I'm
open
to
other
ideas,
though
joseph
I
see
you
on
muted.
E
D
D
But
if,
if
the
the
the
you
know,
if
we
decided
that
well
really,
the
appropriate
response
here
would
be
to
revert
the
commit.
I
mean
that's
like
a
specific
action
that
could
be
taken
fairly
quickly
to
prevent
it
from
getting
released,
but
as
opposed
to
like
oh
well.
Let's
just
try
to
get
this
fixed
before
the
next
release
and
then
we
try,
but
we
don't,
and
then
we
forget
so
maybe
the
appropriate
thing
to
do
here
which
didn't
occur.
D
A
Yeah,
I
I
think
that
so
in
the
event
that
that
time
is
short-
and
it
requires
some
specific
knowledge
to
like
solve
the
problem-
reverting
should
always
be
an
option
like
it
should
be
an
easily
available
option
that
any
core
committer
can
perform
that
action
of
like
reverting
the
commit,
even
without
the
knowledge
of
the
the
issue.
Previously,
that
does
make
a
that
does
make
a
frustrating
experience,
sometimes
for
the
developer.
A
That's,
you
know,
didn't
have
to
get
it
in
and
they
have
to
go
through
the
whole
process
again,
and
that's
that's
fine,
as
as
long
as
we're
not
like,
like,
I
don't
want
to
discourage
the
contributors
that
are
that
are
doing
that,
and
so
reverting
is
always
an
option,
but
I'm
not
sure
that
it
should
be
the
one
that
we
go
to
first.
So
I
think
that
we
should
always
look
at.
Can
we
fix
this
easily
and
quickly
with
a
follow-up?
A
And
then,
if
the
answer
to
that
is
no,
but
the
problem
is,
this
is
still
a
big
big
bug.
Then
we
should
go
to
reverting.
We.
I
think
that
if
there's
a
known
problem,
we
don't
have
time
where
the
ability
to
fix
it
before
release.
We
should
revert
it
before
the
next
release,
like
I
think
that
should
generally
always
happen,
but
this
was
a
this
was
a
case
where
yeah
it's
like
fixing.
It,
I
think,
was
the
right
approach
in
this
case,
because
it
wasn't
a
hard
fix
right
yeah.
A
So
those
are
just
my
thoughts
on
things.
That's
again
a
little
bit
of
a
fuzzy
area,
because
it's
really
about
you
know
what
does
the
situation
call
for
you
know
whether
or
not
you
want
to
revert
something
or
not.
C
I
don't
want
to,
you
know
seem
like
I'm
insisting,
although
I'm
doing
that,
but
trying
to
approach
the
core
developers
via
zulip
or
leave
a
message,
and
even
if
we
do
maybe
it
gets
forgotten
forgotten
or
they
don't
have
time
at
that
time.
And
then
we
have
time
zone
differences
and
someone
else
suggested
that
we
not
mention
a
core
commuter
group
in
the
issue.
So,
instead
of
doing
add
specific
person
in
the
issue
we
use
the
add
group
mention
in
github.
C
But
if
it
were,
I
know
I
understand
the
the
overhead
of
having
just
another
step
in
another
label,
but
the
label
would
be
there
and
if
the
process
that
I'm
trusting
core
commuters
are
following
has
a
step
that
says:
hey
check.
If
there's
any
release,
blocker
it
sort
of
like
takes
the
human
factor
or
most
of
the
human
factors
and
the
time
zone
factors
out
of
the
equation.
So
the
other
solutions
that
we
suggested,
as
are
fine
from
less
overhead
perspective.
C
But
if
we
want
to
be
diligent
about
not
getting
things
out
there
and
also
providing
a
time
agnostic
time
zone
agnostic
way
for
people
to
do
it,
then
I
think,
having
like
a
way
if
labels
is
not
preferable,
maybe
maybe
we
we
create
projects
that
are
released,
I'm
referring
to
the
feature
projects,
the
github
projects
feature,
which
is
tagged
as
a
release,
and
then
we
add
things
in
there
or
something
like
that,
but
yeah
anyways
food
for
thought,
and
we
have
another
core
committee
that
joined
by
the
way.
G
I
came
in
halfway
through
this
conversation,
so
I'm
not
sure
exactly
what
all
the
conversations
about,
but
I
just
heard
the
last
bit
and
if
you're
worried
about
putting
extra
tags
on
the
issue
cube
what
about
because
this
discussion
seems
to
be
specific
to
like
a
pull
request,
making
a
change
or
doing
something
whatever.
G
So
what
about
adding
tags
to
the
issue
like
that
pull
request
place
because
that
doesn't
mean
we
don't
really
use
tags
there
currently
and
they're,
not
really
visible
to
most
users,
so
that
wouldn't
be
like
adding
more
overhead
or
whatever
you
call
it,
but
maybe
that'll
be
an
option,
because
that's
what
we're
actually
doing
the
merge
on
is
the
pull
request.
Maybe
there's
a
tag
there
to
say:
don't
merge
or
block
her
or
whatever.
C
C
We
just
didn't
do
a
good
job
at
communicating
to
to
core
committees
that
the
release
should
not
go
out
without
that
the
fix
being
merged
as
well.
So
we
had
the
options
to
either
merge
the
fix,
which
was
not
marked
rtbc
or
revet
the
chains.
So
we
have
a
release
out
there.
Now
that
has
a
rather
serious
or
obvious,
I
should
say
bug
and
that's
what
we
have
been
discussing:
improving
the
the
workflow
and
our
processes.
So
we
don't.
A
Yeah,
well,
I
I
think
I
mean
speaking
personally.
I
think
I
would
be
okay
with
another
label.
I
think
we
should
need
to
come
up
with
a
good
one.
One
idea
peter
that
you
had
about
putting
on
the
pull
request.
A
I
don't
frequently
check
the
pull
request
list
just
directly
because
there's
there's
a
lot
in
there
that
is
or
is
not
actually
actionable,
but
one
problem
with
putting
a
label
on
the
pull
request
is
that
only
committers
have
access
to
put
labels
on
there
or
organization
owners,
because
we
we
do
this
thing
where
we
like
manually,
add
people
to
the
triage
group
for
backdrop
issues
so
a
lot.
A
lot
of
people
have
access
to
those
labels,
but
very
few
people
have
access
to
labels
on
the
pull
requests
themselves.
A
You
know
which
which
could
be
useful,
except
that
sometimes
the
people
need
to
do
the
flagging.
Like
actually
you
know,
they
don't
have
that
permission.
A
So
and
yeah
I
think,
putting
on
the
on
the
issue
would
be
preferable,
even
though
we
already
have
a
lot
of
labels,
but
I
don't
really
want
to
make
that
decision
unilaterally.
I'm
not
really
sure
if,
if
this
is
a
pmc
type
thing,
if
you
want
to
vote
on
adding
a
label
that
also
seems
like
excessively
bureaucratic
but
yeah,
what
do
you
guys
think
tim
and
greg?
You
guys
are
the
pmc
reps
here.
I.
C
D
D
I'm
I'm
I'm
a
little
bit
concerned
about
the
notion
that
I
should
have
just
pinged
somebody
in
zula
and
that
that
would
have
necessarily
prevented
this
because
to
me
that
feels
like
there
would
have
been
plenty
of
our,
but
but
I'm
not
sure
that
adding
a
tag
necessarily
would
fix
it
either,
because
this
is
the
first
time
I
can
think
of
that.
This
has
happened
in
three
years
and
if
you
know
this
tag
only
gets
used
every
three
years,
there's
still
going
to
be
a
human
tendency
to
like.
A
That
you
check
the
box
and
the
release
checklist.
I
literally
make
sure
they
do
every
single
step
before
I
check
the
box
so
that
that
seems
to
be
pretty
effective.
As
far
as
a
process
goes.
D
Well,
that's
what
we
need.
We
really
need
something
that
you
think
is
gonna
work
or,
or
you
know,
whoever
is
doing
this
and
I
mean
the
other
part
of
this
question
is
that
I
think
right
now
we
have
multiple.
My
assumption
about
this
is
that
we
have
multiple
core
core
committers
that
could
do
a
release.
So
so,
once
we
did
discover
this
bug
that
had
had
been
released,
we
came
up
with
a
pull
request,
pretty
quickly
it
even
got
merged.
D
But
now
it's
it's
set
merged
for
over
a
week,
and
my
assumption
is
that
nate
is
that
you're,
not
the
only
one
that
could
do
a
release,
but
that
nobody
else
feels
comfortable
doing
a
release,
and
so
I
think
the
other
part
of
the
solution
is
that
we
need
to
make
sure
that
more
than
one
person
feels
you
know,
empowered
and
ready
to
you
know
somebody
should
have
been
able
to
step
up
and
kind
of
release
sooner.
A
Yeah,
this
is
a
another
thing
where
I
think
I
think,
as
far
as
the
ability
to
to
create
a
release,
I
think
that
that's.
A
Fairly
distributed,
let
me
see,
because
I
know
that
yeah
I
made-
I
made
the
release
nodes
for
1.20.2,
but
I
think
that
it
wasn't
me
that
made
the
tag.
I
think
I
excuse
me.
I
can't
totally
remember
who
it
was,
but
I
think
it
was
laryn
actually
made
made
the
the
release
tags,
which
is
helpful
and
others
have
made
releases
previously.
A
What
is
was
actually
lacking
here
is
the
feeling
of
authority
that
they
can
make
a
release
at
an
arbitrary
time
you
know,
and
so,
if
we,
if
we
schedule
it
and
say
like
here's,
the
time
that
we
want
to
release
to
be
made,
I
think
that
we
can
get
our
existing
core
commanders
to
make
releases
like
in
in
like
separate
for
me
entirely.
I've
actually
there's
been
one
or
two
releases
where
I
didn't
wasn't
involved
at
all.
So
I
think
when
that
happens,
you
know
we.
A
We
just
need
another
authority
to
like
actually
do
the
scheduling
of
like
we
should
make
a
release
and
right
now
yeah
I
mean
our
release.
Process
mostly
is
well.
A
If
it's
a
security
release,
the
schedule
gets
pushed
on
us
most
of
the
time,
but
if
it's
just
an
intermittent
release,
it's
usually
whenever
you
know
we
have
time
I'll,
be
honest
whenever
I
have
time
and
I'd
feel
like
making
one,
but
that
could
that
could
be
the
case
for
anyone
and
I
I
don't
think
that
we
will
get
to
a
point
that
we're
having
releases
too
frequently
like.
A
I
don't
think,
that's
really
a
problem
that
we
need
to
be
too
concerned
about,
and
so
I
think
that
we
could
probably
try
to
nurture
a
culture
of
anybody
that
feels
like
there
should
be.
A
release
should
be
able
to
make
a
release
like
any
time.
The
problem
is
that
it's
just
actually
a
lot
of
work
to
make
a
release,
so
there's
that
that
whole
portion
of
like
it,
you
know,
takes
effort
to
actually
go
through
all
the
steps
and
to
do
all
the
things
and
there's
a
lot
of
people
involved.
A
So
there
does
need
to
be
like
a
little
bit
of
scheduling
just
to
like
let
people
know
that
it's
happening
but
yeah,
but
a
lot
of
the
tasks
we
do
them.
Asynchronously.
You
know
like
after
release
like
peter,
goes
through
and
updates
tugboats.
You
know
that,
can
that
happens
a
day
or
two
after
the
release
sometimes,
and
that's
fine
yeah.
C
C
Yeah,
so
so
would
I
imagine
that's
and
the
reason
why
I'm
asking
it
is:
would
the
leadership
thread
in
zulu
the
the
commuter
thread
just
to
avoid
noise,
be
something
that
would
draw
your
attention
and
peter
as
well
the
same
question
for
you.
C
So
would
that
I
know
that's
there's
limited
people
that
have
access
to
that,
but
there's
many
more
and-
and
most
of
us
are
very
active
that
we
could
ping
you
guys
there
if
that's
more
appropriate,
because
I
know
zulip
is
a
lot
of
noise,
but
could
could
you
sort
of
like
just
limit
your
attention
to
that
queue
just
and
we
never
abuse
it
and
we
use
it
in
emergencies.
Only.
A
Yeah,
the
the
leadership
chat
in
zulip
is
is
very
effective
for
me
personally,
but
again,
like
only
a
very
small
number
of
people
actually
have
access
to
that
group.
So
that's
only
core
committers
in
the
pmc
at
this
point
so,
but
that
would
that
would
have
also
worked
if
we
just
if
pmc
members
need
to
surface
something
to
core
committers.
I
think
zulip
in
the
leadership
channel
is
exactly
the
right
place.
Yeah,
okay,.
A
Okay,
so
yeah,
I
guess
from
all
of
that.
So
if
we
want
to
speaking
of
the
the
zulip
chat,
I
think
that
also
could
be
a
great
place
to
discuss,
making
a
new
tag.
A
If
we,
if
we
want
to
work
that
out
amongst
ourselves,
without
doing
it
publicly,
you
know,
because
if
somebody
resists
it,
then
it
just
doesn't
go
anywhere.
You
know
we
can
figure
that
out
using
the
chat
before
we
use
an
issue,
possibly.
C
C
It's
time
that
I
install
something
or
I
happen
to
work
on
a
backdrop
site
some,
so
maybe
the
the
moment
that
we
realize
that
there
is
a
an
issue
and
there's
also
a
workaround
or
multiple
workarounds,
maybe
maybe
make
an
announcement
there
and
point
to
the
thread
in
in
the
forum
so
that
you
know
site
site
builders,
site
administrators,
see
that
and
say.
Oh
beware,
there's
a
there's
a
there's,
a
bug!
We
have
that.
C
A
C
A
We'll
be
around
we'll
go
ahead
and
make
the
release
note.
So
this
is
we're
seeing
it
live.
This
is
how
releases
are
made
and
scheduled
right.
Can
we
make
a
release?
Yes,
we
make
a
node
that
is
like
from
the
template
that
says
we're
planning
to
schedule
the
release
at
x
time
and
then
yeah
we'll
go
through
the
steps
in
the
checklist,
so
yeah.
Well,
we'll
try
to
do
that
tomorrow.
I
think
that'll
leave
plenty
of
time
to
go
through
the
very
extensive
rtbc
queue
that
is
there
already.
A
I
think
it
was
pointed
out
before
the
meeting
that
there's
14
issues
that
are
marked
rtbc,
some
of
which
I'll
I'll
be
really
happy
to
see.
I'd
love
to
take
a
look
at
this
4342,
the
modal
window,
how
it
jumps
to
the
top.
A
Every
time
you
open
the
modal
I'd
love
to
see
that
fixed,
because
that
just
drives
me
up
the
wall,
so
yeah
lots
of
really
great
fixes
that
are
in
the
rtbc
queue
right
now
that
we'll
want
all
of
them
to
get
in
yeah
and
and
the
issue
at
stake
here.
A
That's
in
the
list
right
because
it's
it's
marked,
rdbc
too,
isn't
it?
Oh
no.
It's
already
been
committed.
A
Yeah,
that's
right!
Yeah,
let's
see
yeah,
there's
only
two
issues
that
have
been
added
already:
okay,
all
right!
Well,
that's
that's.
What
we'll
do
we'll
shoot
for
that?
Okay
and
then
over
in
the
leadership
queue
we'll
talk
about
adding
a
new
tag
and
who,
who
should
start
that
threat
greg?
Are
you
up
for
that.
A
Yeah
there's
a
couple
of
other
special
tags.
You
know
most
of
them
are
like
status,
dash
whatever
or
needs
dash
whatever,
but
there's
a
blocked,
contrib
candidate
design,
good
for
tissue
and
help
wanted.
So
there
are
these
special
ones
and
release.
Blocker
sounds
good.
It
will
be
sorted
alphabetically,
which
is
kind
of
annoying,
but
that's
the
way
it
goes.
C
A
A
Okay,
yeah,
that
sounds
good.
A
Let's
see,
we
don't
really
have
time
to
do
the
full
status
update
on
things,
although
I
wanted
to
draw
attention
to
this
issue
that
is
very
exciting
that
doc
willmott
has
been
working
on
issue
5257
that
adds
a
search
or
quick
filter
to
the
list
of
simple
test
tests.
I'm
very
excited
about
that
one.
It's
already
in
the
it's
a
new
feature,
so
it's
in
the
1.21
milestone.
A
So
I
guess
you
could
possibly
call
this
a
ux
improvement,
and
so
we
could
potentially
put
it
into
the
next
bug
fix
release
as
well,
but
anyway,
I'm
excited
about
this
issue,
just
the
fact
that
it
exists.
It's
been
something
I've
been
looking
for
for
a
long
time
and
I'm
glad
that
doc
willmott
put
that
together
for
us
very
excited
any
other
issues
you
guys
would
like
to
discuss
today.
D
I
I
posted
in
zulu
yesterday
we're
we're
a
month
away
from
the
next
feature:
freeze,
1.21
and
something
that
worked
well,
I
I
thought
at
least
it
worked
well
for
me
a
few
issues
ago
was
we
created
a
blog
post
where
anybody
could
list
the
the
issues
that
there
was
up
to
three
issues
that
they
would
like
to
focus
on
and
or
or
would
like
help
with,
and
it's
just
a
chance
for
all
of
us
to
sort
of
flag
the
issues
that
we're
really
focused
on
for
the
next
few
weeks,
and
I
I
went
ahead
and
I,
if
you've
got
a
few
responses
to
that,
so
I
created
the
blog
post
it's
already
published,
but
the
plan
is
to
just
keep
updating
that
through
through
feature
freeze.
D
So
if
anybody
wants
to
add
something
to
that
list,
my
my
thought
or
the
way
we
did
this
last
time
is-
you
can
have
three
issues
at
a
time
on
that
list.
So
if
one
of
them
gets
merged
or
gets
completed,
you
can
take
that
off
and
add
another
one
and
again
it's
purely
meant
to,
as
in
you
know,
to
help
other
people
discover
what
issues
need
help
there's
no
guarantees
or
no.
D
In
fact,
I
have
a
little
note
at
the
bottom
of
the
blog
post,
which
says
you
know.
None
of
the
issues
here
have
been
necessarily
approved
for
inclusion.
This
is
just
the
personal
opinions
of
each
person,
so
one
if
anybody
wants
to
add
something
to
that
list.
You
can't,
if
you
have
edit
access,
feel
free
to
just
edit
the
list
yourself.
It's
a
blog
post
on
bankrupt.org.
D
If
you
don't
have
edit
access
or
you
just
don't
want
to
just
flag
me
and
zoom
up
and
I'll
add
it
and
along
those
lines.
We
don't
need
to
discuss
this
now,
but
I
think
we
should
we
could
do
this
informally.
It's
just
that.
We've
for
the
last
few
releases,
we've
tried
to
schedule
one
or
two
sort
of
sprint
days
leading
up
to
the
release,
and
you
know
if
anybody
has
suggestions
or
thoughts
on
that.
C
Yeah,
perhaps
we
could
take
advantage
of
the
office
office
office,
hours
or
schedule.
I
don't
know
for
those
that
prefer
the
weekends
some
sprints
court
reviews
sprints
or
you
know,
workshops
whatever.
I'm.
D
Not
for
that
it's
a
great
point,
for
I
think
most
of
us
have
all
been
there
at
least,
but
my
friend
or
our
friend
wilbur
has
committed
himself
to
making
sure
that
we
do
have
somebody
there
for
office
hours
every
wednesday
through
at
least
the
end
of
the
year.
So
for
the
last
three
weeks,
we've
actually
had
regular
office
hours
with
somebody
in
the
in
the
zulu
room
or
in
the
zoom
room,
and
we
had
like
five
or
six
people
there
last
week.
D
So
so
we
could
use
that
that
time
is
a
great
time
to
check
in
and
sort
of
do
printing
sort
of
little
two-hour
mini
sprints.
Every
week.
A
No
sounds
great.
I
went
ahead
and
filed
the
issue
for
the
release.
It's
53.82
so
we'll
be
doing
that
tomorrow.
That's
set
all
right.
I
don't
have
anything
else
for
today,
so
I
think
we
can.
We
can
call
it
a
meeting.
Thank
you
everybody
for
joining
this
week,
thanks
for
the
great
suggestions
participating
in
the
forum,
as
mentioned
before,
like
thanks
for
all
the
new
contrib
projects,
that's
happening,
thank
you
for
the
rtbcq.
A
That
is
full
of
great
things
that
are
that
are
all
happening,
so
yeah
very
exciting.
I
guess
we're
actually
like
last
week
was
thanksgiving
for
us
americans.
So
this
is
actually
two
weeks
of
of
work
all
piled
up.
Maybe
that's
why
it
seems
like
so
much
is
happening,
but
yeah
still
yeah.
I
guess
you
know
thanksgiving
thankful
for
all
of
our
contributors
out
there.
So
yeah
thanks.