►
From YouTube: 2022-05-04 Maintainership Working Group
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
Welcome
everyone
to
the
maintainership
working
group
it
is,
may
4th.
Let
me
go
over
some
follow-ups
since
last
time.
A
First
of
all,
this
is
a
new
meeting
set
up
to
accommodate
more
team
members,
but
now,
after
looking
at
the
team
members
that
were
invited
to
this
meeting
compared
to
the
one
on
monday,
I
might
reschedule
the
monday
scheduling
is
very
difficult
with
the
amount
of
people,
so
that's
evolving.
A
Depending
on
when
you
checked
the
exit
criteria,
there
might
have
been
10
or
11
bullet
points
in
the
exit
criteria,
but
nick
and
darva
have
consolidated
a
lot
of
that,
and
so
some
of
these
epics
are
filled
out
already
with
issues
that
used
to
be
previous
exit
criteria,
but
instead
wrap
up
under
these
now.
All
of
these
epics
still
need
more
issues
in
them,
though.
So
keep
that
in
mind
this
is
exit
criteria
zero.
This
used
to
be
the
first
exit
criteria,
which
is
representation.
A
I
put
here
I'd
like
to
have
the
fault
the
final
volunteers
by
end
of
this
week,
but
there
is
an
updated
comment
on
here
from
me
where
I
made
some
suggestions
in
terms
of
who
those
seven
functional
leads
should
be.
The
list
actually
has
eight
on
it.
So
before
I
move
on,
I
don't
know
if
anyone
had
comments
suggestions,
if
you
disagreed
with
the
people
that
I
recommended
or
anything
like
that,.
A
Okay,
so
I'm
going
to
follow
up
on
that
issue
async
and
see
if
we're
good.
If
we
need
to
make
changes
first
thing
that
I'm
always
going
to
ask
the
exit
criteria
epics
some
of
them
still
don't
have
dris
and
so
of
you
all
that
are
on
the
call.
Today
there
are
some
epics
that
don't
have
dris.
A
B
A
Okay,
well,
thank
you
very
much.
Let
me
see
so
that
gives
us,
so
we
would
still
be
missing,
create
an
implementation
plan
to
remedy
gaps
and
maintainership
coverage
and
develop
and
implement
a
communication
plan
for
maintainership
changes
that
last
one
I'm
sure
is
probably
blocked
by
the
other
four.
C
Just
so,
I
just
wanted
to
understand
what
was
involved
in
this
one,
so
when
we
say
identify
gaps
in
maintainership
coverage
by
maintainership
coverage,
we
mean
on
all
projects
and
all
areas
are
in
scope
for
this
working
group.
C
A
Yeah,
it
could
be
probably
not.
We
do
have
an
is
part
of
product
selector,
and
so
the
the
first
thing
on
this
epic
would
be,
for
example,
the
maintainer
kpi,
the
maintainer
ratio,
that's
only
using
back-end
front-end
database
for
the
gitlab
project,
and
should
that
include
more
it's
kind
of
an
open-ended
question.
We
have
288
projects
that
fall
under
that
product
category,
should
they
all
be
included
in
this
working
group,
which
ones
should
which
one
shouldn't.
A
So
there
are
a
lot
of
questions
to
ask
for
that
one,
but
you
brought
up
get
lab
shell.
Is
there
a
process
that
we'll
discuss
in
this
working
group
that
should
apply
to
gitlab
shell?
Should
it
be
treated
the
same?
Should
it
be
treated
differently?
And
so,
like
I
said
with
all
of
these
epics,
they
are
missing
those
issues.
There
are
a
lot
of
questions.
Does
that
make.
C
Sense,
okay,
so
forget
lab
shell.
We
could
use
the
what
we've
learned
from
this
working
group
to
apply
it
to
get
lifeshell,
but
this
working
group
doesn't
need
to
deal
with
gitlab.
Shell
is
that
is
that
right.
A
A
One
of
the
reasons
for
this
working
group
is:
there
are
a
lot
of
complaints
that
maintainers
are
overwhelmed
and
that
there
aren't
enough
maintainers.
I
know
that
that's
a
complaint
of
gitlab
shell
as
well,
and
so
I
would
assume
that
gitlab
shell
qualifies
for
that,
but
that
we're
missing
data
on
things
like
that.
C
I
know
I
think
that
helps
so.
I
think
it
sounds
like
we're
sort
of
talking
about
a
core
set
of
projects
here,
not
the
full,
like
I
said,
like
I
said
I
didn't
know,
there
was
288,
but
like
the
sort
of
the
main
pain
points,
I
guess
exactly.
B
I
added
a
few
discussions,
but
so
we
can
start
with
the
second
one,
potentially
because
the
that's
relevant
to
workhorse
shell
and
stuff,
like
that,
if
they
are
going
to
be
involved
in
this,
they
are
probably
quite
awkward.
B
Database
is
a
little
bit
different,
but
my
I
mean
workhorse
and
shell
is
technically
in
my
team,
but
we're
supposedly
mostly
responsible
for
it,
but
we're
all
still
learning
go,
which
makes
it
very
hard
to
be
a
maintainer
for
a
project
which
is
so
performance
specific
in
particular,
where
maintainers
for
that
project,
probably
don't
need
to
know
the
project
as
much
as
they
need
to
really
know.
Go
well
and
that's
quite
different.
B
I
think
to
the
main
gitlab
application,
because
most
of
us,
if
you're
a
back-end,
maintainer
or
reviewer,
are
already
very
familiar
in
ruby,
because
that's
the
main
thing
we're
working
in
every
day,
whereas
those
projects
are
a
little
bit
different.
B
So
my
experience
in
the
database
is
not
really
relevant,
and
so
it
feels
quite
difficult
to
review
for
it
and
particularly
to
be
a
maintainer
if
you're
not
doing
it
every
day
or
often
enough.
So
I
resigned
from
that
because
I
just
like
I
don't
know
what
queries
are
going
to
be
optimum
because
I'd
written
about
five
in
my
time
at
the
company,
because
we
just
don't
do
that.
B
Many
of
them-
and
I
think
the
same
is
true
of
a
workhorse
in
the
show,
and
I
think
you
really
need
to
be
working
on
that
project
a
lot
or
already
an
expert
in
the
language.
So
I
think
that
there's
some
sort
of
different
questions
around
that
compared
to
the
gear
lab
repo.
B
So
that's
about
as
much
as
I've
done
and
that's
technically
in
my
team
it
was
predominantly
nick,
thomas
and
yeah.
I
think,
there's
probably
less
than
five
from
what
I.
C
Can
remember,
because
for
workhorse
I
know
that,
like
you
know,
one
of
the
maintainers
did
yakov
last
month,
he's
on
my
team,
so
he's
not
necessarily
doing
workhorse
work
day
to
day,
but
he
wrote.
The
initial
version
so,
like
he's
got
the
the
context
but,
like
you
said,
I
think
I
think
you
do
need
one
of
the
two.
C
You
only
need
to
be
working
in
it
day
to
day
or
have
a
strong
historical
context
for
the
projects,
and,
if
you
don't
it's
not
really
practical
to
ask
for
maintainers
from
people
who
aren't
working
on
something
already
yeah
right,
like
the
the
group
of
people.
Working
on
a
thing
is,
is
what
we
need.
First
before
we
can
ask
for
more
maintainers.
There
I
mean
if
we
were
because.
B
Yeah,
that's
how
I
feel
as
well,
and
I
think
if,
if
it
was
say
written
in
rust,
which
is
something
I
write
in
my
spare
time,
then
I
would
feel
like
yes,
okay,
I
could
probably
be
a
maintainer
for
that,
even
without
the
context,
because
at
least
I
can
look
at
the
code
and
stay
yeah.
That
does
what
you
say
it
does,
but
with
the
go
code
for
me,
I'm
still
learning
go.
That's
quite
difficult
and
I
think
that's
the
case
for
quite
a
lot
of
people.
B
So
there
is
that
sort
of
problem
where
we
either
have
to
find
go,
experienced,
go
programmers
who
can
just
be
maintainers
because
they
know
go
and
then
they
can
fill
in
the
context
or
we
have
to
have
people
working
on
the
project
that
as
a
dedicated
sort
of
thing
for
a
few
months.
In
order
to
have
the
experience
to
know
what
could
be
merged
and
that
sort
of
thing.
D
Yeah
we
have
as
someone
who
reviews
and
triages
community
contributions.
You
know
I'm
often
assigned
the
initial
review
on
things
in
gitlab,
shell
or
helm,
charts
things
like
that,
and
it's
like
well,
I'm
100
not
qualified
to
say
that
this
is
good.
I
can
say
that
it
does
what
you
say
it
does,
but
in
terms
of
hitting
that
merge
button,
absolutely
not
there's.
D
B
Yeah,
I
think
it's
kind
of
similar
in
a
way
to
I
don't
know
the
whole
gitlab
application,
because
I
work
on
one
specific
part
of
it,
but
because
I'm
very
experienced
in
ruby.
I
feel
confident
that
I
can
look
at
someone's,
merge,
request
and
say:
yeah.
Okay,
you've
changed
the
power
application.
I've
literally
never
used,
but
it
does
do
what
you
say
it
does,
because
I
can
see
that
it
does
that,
and
I
can't
do
that
for
work
course
and
show-
and
I
think
quite
a
few
people
are
finding
that
as
well.
A
B
C
Sorry,
well,
I
think
I
think
one
way
would
be
to
just
look
at
what
we
should
by
default.
It's
a
good
start.
So,
like
you
know,
what's
in
the
omnibus
package
or
the
helm
chart
by
default,
like
you
know,
shell
has
to
be
on
otherwise
get
that
doesn't
work.
Workhorse
has
to
be
on
otherwise
gitlab
doesn't
work.
I
think
those
sort
of
required
components
are
probably
where
we
see
the
most
pain.
C
Another
thing
that
occurred
to
me,
when
I
was
talking
about
go,
is
that,
as
far
as
I'm
aware,
we
don't
have
this
issue
with
runner,
but
runner
has
a
dedicated
team
and
like
robert's
team,
that
is
a
team
that
basically
only
works
on
a
runner
as
opposed
to
a
team
that
owns
a
runner
but
spends
a
lot
of
time
working
on
something
else
same.
C
As
well
yeah,
exactly
like
you
know,
if
the
italy,
if
there's
a
problem
with
italy
and
maintainers,
I'm
assuming
the
italy
team,
will
figure
that
out,
I
don't
think
the
working
group
needs
to
figure
that
out,
because
nobody
on
this
team
actually
works
on
the
italy
team.
Nobody
on
this
call
anyway,
so
you
know
I
feel,
like
you
know,.
C
B
I
think
I'm
technically
a
trainee
maintainer
for
rouge
the
the
code
highlighting
library.
E
A
So
here
in
my
there's,
a
link
that
says
internal
only
and
if
you
click
on
that
there's
a
huge
list.
C
Should
we
start
from
one
of
these
lists
and
prune
them,
because
I
think
for
the
the
long
list
there
like
a
lot
of
them,
are
in
security
products
which
again
will
have
a
dedicated
team
working
on
them
or
they
are
what
was
the
other
example?
I
was
looking
at
model.
Ops
will
also
have
a
dedicated
team
working
on
it.
So
should
we
start
with
that
list
and
prune
that,
by
like
someone
already
owns
this,
this
working
group
doesn't
need
to
care
about
it.
A
Be,
I
think,
that's
a
a
good
topic
of
discussion.
I
would
be
curious.
I
would
be
curious
if
they
see
problems.
You
know
just
a
second
of
terrible
allergies.
Robert's
team
does
own
gitlab
shell,
it's
just
that
his
team
isn't
working
on
it.
So
is
that
true
of
these
other
projects.
A
So,
unless
there's
more
to
say
on
this,
what
I
would
recommend
we
do
is
sean.
First
of
all,
I
think
that's
a
great
idea
to
start
with.
If
you
want
to
comment
on
that
issue
and
just
kind
of
recommend
that
so
we
don't
forget
and
maybe
dive
into
that
a
little
robert.
Is
there
any
other
action
that
we
can
take
based
on
this
conversation,
because
it's
really
more
than
just
what
I
said
about
is
part
of
product
or
not.
B
Yeah,
it's
kind
of
hard
to
tell-
I
guess
maybe
it'd
be
good
to
just
narrow
the
list
down
first,
and
then
we
can
figure
out
what
we
want
to
do
about
it.
After
that,
I
think,
like
workhorse
and
shella
their
own
interesting
problem.
It'd
be
I'd,
be
to
be
curious
to
see
what
other
ones
we
have
so
like.
B
If
we
have
other
ruby
projects,
I
don't
really
worry
about
those,
because
in
theory
anyone
can
pick
them
up
unless
it's
really
bizarre
any
of
our
back-end
engineers
can
should
be
able
to
be
a
maintainer
for
a
ruby
project
if
it
needs
it,
but
the
go
ones
that
are
technically
owned
by
the
ruby,
like
primary
teams,
are
a
bit
of
an
odd
case.
B
I'll
go
through
the
second
one
quite
quickly,
but
so
especially
for
like
the
last
six
months,
I've
just
had
a
red
circle
online
most
of
the
time,
and
the
problem
is
that
I
probably
as
me
I
get
easily
distracted,
but
reviews
are
very
countered
to
our
general
sort
of
the
way
we
work
in
a
release.
So
in
a
release,
you
kind
of
have
the
freedom
to
pick
and
choose
the
order
in
which
you
want
to
do
things
when
you
want
to
work
on
things.
B
But
when
you
receive
a
review,
you
effectively
have
a
two-day
time
constraint,
so
you
have
to
do
it
quite
quickly
or
you're
interrupting
other
people's
work.
So
it's
almost
like
getting
like
a
priority
issue
that
you
have
to
work
on.
You
can
send
it
off
to
somebody
else,
but
then
you're
only
really
sending
the
problem
on
to
somebody
else
who
also
might
be
having
the
same
issue,
and
so
it's
all
gets
spread
around
a
bit.
B
B
I
never
get
like
a
steady
trickle
and
there
is
now
the
orange
diamond
as
an
option
and
that's
almost
how
it
feels
the
default
should
work
if
that
makes
sense,
because
if
you
have
the
orange
diamond
on,
I
think
you
get
about
50
of
the
number
of
reviews
and
that
feels
more
like
the
correct
ratio,
because
otherwise
it
always
goes
in
this.
Like
spiky
burst,
you
put
the
red
circle
and
you
take
it
off.
You
go
straight
back
up
to
like
five
plus
reviews.
You
put
it
on.
B
It
goes
back
down
and
it's
like
this
all
the
time
and
I've.
I've
noticed
him
before
I
send
like
an
inordinate
amount
of
reviews
to
sean
for
some
reason,
but
in
burst.
So
every
two
months
sean
gets
like
five
to
ten
murder
requests
from
me,
because
his
name
always
appears
for
that
month.
It's
very
weird:
it's
like
it's
going
in
a
loop
around
the
people
and
some
people
just
end
up
with
a
really
large
amount
of
them
all
at
once.
D
It's
not,
I
think
so.
One
of
the
things
I'm
I
was
working
on
but
seems
to
have
been
taken
over
quite
effectively
by
other
folks,
is
getting
some
more
of
that
useful
data
in
a
way
we
can
use
for
those
now
capacity
data
in
the
roulette
dashboard.
D
I
from
what
I
can
tell-
and
this
is
anecdotal,
although
it
seems
to
chime
with
what
you're
saying,
is
that
there
is
a
small,
well,
a
large
group
of
maintainers
that
have
a
red
circle
on
a
lot
of
the
time,
and
that
means
that
the
pool
of
available
maintainers
is
sort
of
trending
downwards
over
time.
But
we
don't
have
the
data
to
really
back
that
up
yet
so
I'm
hoping
we
will
soon
but
yeah
like
you
say
because
of
that,
you
put
the
red
circle
on
you,
get
nothing!
D
There's
a
small
group
of
maintainers.
Eventually
you
take
it
off
that
small
group
becomes
one
larger
and
then
you
get
a
an
abnormal
number.
So
I
think
the
useful
thing
is
going
to
be
seeing
how
long
people
leave
the
red
circle
on
four
and,
if
we've
got
maintainers,
who
have
it
on
for
multiple
consecutive
months,
perhaps
suggesting
that
all
maintainers
who
are
not
on
pto,
remove
it
for
a
while
and
see.
If
that
kind
of
alleviates
this
sort
of
circle
that
we
have
of
a
small
group.
B
Becoming
a
smaller
group,
that's
going
to
be
interesting,
I
mean
we
could
always
recommend
as
a
first
step
that
they'll
like
ask
that
people
set
it
to
the
orange
diamond
instead
and
just
see
if
that
allows
us
to
ease
it
back
on
a
bit
without
everyone,
suddenly
getting
the
initial
burst
again.
D
There's
a
definite
irony
in
the
sense
of
if
we
were
to
ask
all
the
available
maintainers
to
remove
their
red
circle.
Everyone
would
get
few
reviews
because
that
pool
would
immediately
quadruple
in
size.
I
I'm
not
suggesting
we
do
that.
I
don't
think
it'd
be
a
particularly
popular
idea,
but
it
kind
of
would
have
an
intended
effect.
I
think.
F
So
whenever
you
take
off
a
red
circle,
you
get
an
immediate.
You
know,
rush
of
reviews
coming
to
you,
so
I
think
the
problem
with
the
current
approach
is
there's
no
way
to
control
the
upper
limit
of
what
I
can
take.
It's
like,
if
you
remove
the
red
circle.
Okay,
give
me
everything,
and
that
is
going
to
get
you
a
feeling
of.
I
am
overwhelmed
with
reviews.
F
So
if
you
can
get
to
a
point
where
I
can
control
the
maximum
amount
of
reviews,
I
can
do
in
a
day
and
if
everybody
does
that,
I
think
we
will
have
enough
space
for
all.
The
reviews
and
red
circle
is
like
the
the
red
circle
will
now
correlate
to
putting
zero
as
your
status,
because
I
can't
take
any
more
reviews,
but
you
can
obviously
take
one
or
two
at
any
point
of
time.
If
you
know
that
it
won't
go
beyond
two.
B
I
think
it
makes
sense
to
me,
and
especially
for
one
reason
with
the
the
current
way
of
doing
things
is
when
you
get
that
burst
of
reviews
when
you
take
the
red
circle
off,
because
you
have
essentially
two
days
in
which
to
do
those
you
effectively
have
to
then
say
well,
I'm
doing
no
other
work
for
the
next
two
days
and
you
clear
all
the
reviews.
B
Inevitably,
because
you
always
get
one,
that's
just
like
140
changes
or
something
and
just
makes
you
want
to
die
inside,
and
you
have
to
sort
of
work
through
all
that
for
a
really
long
time,
but
being
able
to
control
that,
like
one
or
two
a
day
for
me
is
really
easy
like
I
can
do
that
in
the
morning
before
I,
while
I
check
my
email
or
something
that's
a
nice
sort
of
if
it
was
regular,
doing
10
a
week,
that
way
is
much
better
than
doing
the
10
in
one
single
day
that
you
end
up
getting
and
then
having
to
be
red
circle
for
the
rest
of
weeks
to
catch
up
again.
A
G
Yep,
just
a
very
quick
point
about
review
and
maintain
a
ratio,
for
example
for
frontend.
We
are
not
our
goal
in
these
terms
like
we
are,
I
think,
twice
as
even
as
good
as
a
goal,
but
the
problem
is,
I
think
this
still
is
not
showing
the
real
ratio.
That's
why
I
shared
the
statistics.
So
maybe
we
should
change
it
not
to
reviewer
maintainer,
but
reviewed
available,
maintain
a
ratio
that
I
can
tell
for
front
end.
Around
50
percent
of
maintainers
are
constantly
busy
on
red
circle.
C
I
agree
because
at
the
moment,
like
we've
targeted
our
maintainer
ratio,
based
on
an
assumption
that
wasn't
really
like
based
on
any
data,
it
was
just
sort
of
like
this
sort
of
feels
like
the
right
level.
But
then,
if
we
have
more
people
on
red
circle,
then
we
don't
actually
have
that
many
main
containers.
C
Then
the
ratio
is
actually
not
what
we
think
it
is.
So
I
definitely
agree,
and
since
we
started
collecting
historical.
A
Let's
get
an
issue
for
this
inside
of
the
max:
what's
yours
to
develop
metrics,
to
provide
more
transparency,
let's
get.
I
think
there
are
a
few
issues
here
and
natalya
your
maintainer
available
ratio.
Kind
of
we
see
a
problem
like
we
don't
need
more
maintainers
because
we're
meeting
our
ratio,
but
the
ratio
is
wrong
and
maybe
based
on
minaj
and
robert.
Your
two
kind
of
concerns
here,
maybe
guidance
like
based
on
the
data
that
we
are
gathering
as
part
of
max's
initiative.
A
Thank
you
very
much.
We've
only
got
three
minutes
so,
let's
wrap
up
like
I
said
I
will
add
action
items
in
a
bit
after
my
next
call
add
action
items
here
and
I'll
tag
you
in
it
is
there
anything
that
we
want
to
spend
the
next
three
minutes
on.
A
A
B
A
Well,
everything
is
important
robert.
I
will
also
say:
please
join
the
slack
channel
if
you
haven't,
because
a
lot
of
these
conversations
bleed
over
into
slack
and
then
they
end
up
in
an
issue
so
that
works
too.