►
From YouTube: 2022-05-31 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
A
A
I'm
going
to
get
started,
hopefully
others
will
join
along
the
way,
but
it
is
on
the
dot
so
changes
since
last
time.
I'll.
Let
you
go
ahead.
Steve.
C
C
Cool,
I
just
follow
up
to
some
very,
very
overdue
items,
but
I'm
happy
to
have
made
some
progress
there
in
terms
of
the
identified
training,
maintainer
issues
that
were
older
or
hadn't
been
updated.
In
the
past
six
months,
I've
gone
out
and
actually
pinged
the
training
maintainers,
as
well
as
the
managers
and
in
order
to
see,
if
they're
still
actively
pursuing
it
or
if
they're
you
know,
perhaps
perhaps
some
way
we
can
help
them
in
terms
of
making
sure
they're
progressing
towards
their
maintainership.
C
So
it'll
be
interesting
to
see
what
responses
we
get
there.
At
the
very
least,
we
can
expect
that
some
of
those
issues
may
just
ultimately
be
closed,
so
we
have
a
more
accurate
reflection
on
who's
actively
pursuing
maintainership,
so
I'll
be
sure
to
follow
up
once
I
have
some
more
information
there.
C
At
the
same
time,
I
also
am
looking
at
the
inverse
situation
where
the
active
maintainer
issues,
basically
seeing
you
know
how
many
of
those
could
we
potentially
try
to
push
for
in
this
quarter,
to
support
the
the
quarterly
okr
and
so
I'll,
be
reaching
out
to
them
a
little
bit
differently,
not
directly
on
the
maintainer
issue,
but
I'll
reach
out
to
the
managers
to
see
you
know
how
they
could
potentially
push
for
maintainership
there
and
then
just
kind
of
fyi.
C
There's
a
issue
out
in
triage
ops
in
order
to
drive
some
automation
in
terms
of
making
this
a
bit
more
a
less
manual
auditing
process.
So
that'll
be
good
if
you
want
to
follow
along
and
then
I've
also
chimed
into,
I
think
epics
two
to
four
in
terms
of
how
I
might
be
able
to
provide
some
data
to
help
push
for
these.
The
exit
criteria
there
so
check
those
out.
A
Thank
you.
It's
a
very
good
update.
I
do
have
one
question
you
had
mentioned
past
six
months
and
following
up
to
see,
if
we
can
make
some
of
these
maintainers,
are
you
talking
about.
C
So
it's
separate
so
so
I've
reached
out
to
the
older
than
it
hasn't
been
updated
in
six
months.
Crowd
to
say:
hey
is
this
something
you're
still
pursuing,
but
then
I'm
looking
at
the
ones
that
have
been
updated
within
six
months,
there's
actually
a
concentration
of
those
like
updated
in
the
last
two
to
three
months
to
see
hey.
These
are
pretty
active.
C
You
know,
what's
your
chance
on,
you
know
actually
seeing
if,
if
you
you're
going
to
propose
this
to
the
maintainership,
maintain
a
group
to
actually
you
know
see
whether
or
not
that
you'd
be
accepted
or
not
into
that,
just
to
kind
of
have
a
better
read
on
who's
more
likely
to
in
support
of
like
actually
confirming
or
pushing
for
more
maintainers.
This
quarter,
who's
likely
to
actually
hit
that
so
I'll
be
reaching
out
to
the
the
managers
there.
C
Meeting
after
because
I'll
I'll
be
pinging,
the
managers
it'll
be
good
to
get
them
time
to
like
talk
to
their
trainees
as
well.
To
see
to
get
to
get
an
accurate
read
on
on
how
confident
they'd
be
so
yeah.
A
Okay,
thank
you,
help
needed
section
so
exit
criteria,
one
is
still
missing
a
dri,
and
I
wondered
if
this
was
for
a
reason.
If
we
needed
to
define
it
better
or
make
it
more
clear
nick,
I
think
he
just
volunteered,
though,
so
maybe
we
don't
need
to
discuss
that.
D
Yeah,
I
think
I
mean
I
was
looking
through
and
it
was
a
little
unclear,
but
I
may
just
be
missing
some
of
the
context
from
not
having
attended
for
a
few
sessions.
I'm
happy
to
pick
it
up
as
dri
and
and
help
get
whatever
clarity
we
need
to
and
if
anyone
else
is
interested
in
collaborating
on
it
yeah,
please
what
let
me
know
happy
to
work
with
you
on
it.
Awesome.
E
C
I
opened
mr
proposing
a
maintainership
auditing
process,
so
just
looking
for
some
feedback
and
suggestions
there,
so
please
leave
anything,
leave
any
comments.
A
C
Sure
yeah,
the
idea
came
up.
That
maintainership
is
interesting
because
you
know
you
kind
of
become
a
maintainer
through
this
sort
of
approval,
voting
type
process
and
fro
after
that,
there's
not
really
any
checks
on
it.
So
it's
kind
of
once
your
maintainer,
you
kind
of
just
have
that
until
you
decide
not
to
be
it
anymore
and
so
there's
the
question
of,
should
we
have
some
sort
of
a
check
to
ensure
that
the
quality
of
maintainers
stay
high
over
the
course
of
years.
A
Okay,
I
will
check
that
out
here
in
a
little
bit.
So
thank
you,
okay,
discussions
and
questions.
Nick.
If
you
want
to
get
us
started,
I'm
going
to
move
my
point
to
the
end
sure.
D
Yeah
last
week
there
was
for
like
a
day
or
two,
there
was
a
setting
to
prevent
approvals
and
merges
by
users
who
had
commits
this
was
enabled
on
the
main
gitlab
project.
It's
part
of
some
config
changes
for
compliance
reasons.
It
immediately
impacted
tech
writing,
workflows,
I
think,
with
other
code
review
workflows,
maybe
not
as
much
but
a
database
reviewer
a
database
maintainer
didn't
notice
some
issue.
D
I
think,
there's
just
a
general
concern
that
this
sort
of
thing
could
slow
down
development
quite
a
bit,
and
you
know
for
trying
to
increase
the
mr
rate.
It
could
certainly
have
have
an
impact
on
that.
There's
some
I
linked
to
the
the
change
issue
there,
so
anyone
who's,
interested
or
unfamiliar
can
get
for
context.
There's
also
a
pretty
lengthy
slack
discussion
in
the
vp
development
channel.
D
I
think
christopher
has
met
with
julia
wake,
a
couple
times
to
kind
of
talk
through
development
standpoint
and
and
just
try
to
understand
what
exactly
we're
looking
to
do
here.
So
I
think
the
next
one
of
the
next
steps
is
so
the
setting
is
still
disabled.
One
of
the
next
steps
is
for
julian
security
to
follow
up
with
our
advisor
who's
kind
of
advising
us
on
some
of
these
compliance
changes.
So,
depending
on
what
comes
out
of
that,
you
know
it
may
impact
our
maintainer
reviewer
workflows.
D
I
guess
my
question
for
the
group,
so
so
I
bring
this
for
a
couple
of
reasons.
One
is
to
just
give
a
heads
up
about
it,
for
anyone
who
wasn't
familiar
two
is
to
just
ask
like:
is
this
something
that
we
want
to
kind
of
discuss
as
part
of
this
working
group
like
do
we
want
to
maybe
proactively,
as
part
of
this
working
group,
gather
some
more
feedback
and
ideas
about,
assuming
that
we
do
have
to
make
some
changes
to
this
process?
That'll?
D
Assuming
that
we
have
to
make
some
of
these
approval
changes
that
could
disrupt
some
workflows
like
do
we
do?
We
want
to,
as
part
of
this
working
group,
get
more
feedback
and
ideas
for
work
around,
so
my
thought
on
that
was
maybe
not
cluttering
that
original
change
issue,
where
some
discussion
was
already
a
lot
of
discussions
already
happening
happening
with
technical
writing
and
I
think
kai
you're
involved
in
that
issue
as
well.
So
my
thought
was
we
can.
D
If
people
were
interested
in
taking
sound
as
part
of
the
working
group,
we
could
open
a
separate
issue
to
discuss
specifically
with
maintainers
and
anyone
who's
interested
from
development
and
then
and
then,
if
we
did
want
to
do
that,
then
my
next
follow-up
question
was
which
exit
criteria
might
it
fit
best
under.
So
you
know
that's
quite
a
bit
but
I'll
leave
it
at
that
and
let
anyone
else
who
wants
to
chime
in.
C
I
don't
know
how
often
that
happens.
I
know
I've
done
it
like
once
or
twice
in
the
past
year,
but
in
those
few
cases
it
could
lead
to
longer
merge
times
and
there's
also
some
cases
where
you
know.
If
something
goes
wrong
with
the
pipeline,
a
maintainer
can
feel
okay
about
merging
their
own.
Mr
for
example,
because
it's
been
fully
approved,
but
those
are
just
some
some
thoughts
to
add
to
where
yeah.
D
I
know
yeah
caillou
had
also
shared
some
in
that
slack
thread.
Maybe
some
some
metrics
around
like
how
many
times
people
actually
apply
suggestions,
and
things
like
that.
So
I
think
one
thing
I'd
be
interested
in
kind
of
to
your
point.
See
is
like
how
are
those
stats
reflective
of
of
how
we
do
things
in
our
process
at
gitlab,
my
understanding
was
those
were
kind
of
like
more
general,
more
general
metrics
across
all
of
dot
com,
so
that
might
be
one
thing
to
gather
feedback
on
from
maintainers
is
like.
F
I
I
haven't
had
a
quick
look
at
the
thread
yet,
but
just
anecdotally,
I
know
with
community
contributions.
F
It's
often
useful
to
do
that,
particularly
if
it's
say
small
linting
changes
or
things
like
that,
where
a
contributor
has
already
devoted
some
time,
it's
pretty
close
to
merging
so
I'll,
often
just
go
in
and
make
those
sorts
of
changes
myself
and
also
just
generally
being
an
apac
if
they're
pretty
trivial
changes
on
an
mr-
and
I
know
that
the
author
is
in
another
time
zone,
I
might
just
go
ahead
and
do
it
and
merge
it.
A
B
I
would,
I
would
say
yes,
based
on
what
the
auditors
have
said
so
far,
if
that
setting's
enabled
in
combination
with
like
resetting
approvals,
it'll
effectively
bar
a
maintainer
from
approving
and
or
merging
anything
where
they're,
an
author
or
a
committer,
and
if
you
think
back
to
one
of
your
final
things
in
code
review,
it
was
finishing
james's,
mr
before
he
left
that
made
the
author
of
a
suggestion
account
as
an
author
in
merge
requests,
and
this
is
what
breaks
some
sort
of
approval
flows.
B
A
A
Should
we
look
at
the
responsibilities
of
a
maintainer
and
which
exit
criteria
does
this
fall
under,
and
I
I
kind
of
wanted
to
bring
this
up
a
little
bit
anyway,
because
it's
been
a
month
of
the
working
group
so
far,
one
of
the
main
goals
of
the
working
group
is
to
increase
maintainers
and
there's
so
many
ways
to
do
that.
One
of
the
ways
to
do
that
is
by
making
their
responsibilities
easier,
getting
them
to
be
a
maintainer
easier
like
the
training,
maintainer
process
and
things
like
that.
A
So
from
that
aspect
I
think
this
makes
sense
because
we're
talking
about
what
are
their
responsibilities
and
what
workflows
will
be
hindered
by
any
of
these
changes
that
either
we
make
or
compliance
makes
or
whatever.
So
with
that
in
mind,
I
think
that
it
is
a
topic
for
the
working
group,
probably
under.
A
Maybe
exit
criteria
number
three
to
update,
expected
behaviors
and
responsibilities
for
engineers
and
maintainers,
but
just
keeping
in
mind
that
maybe
the
solution
here
is
not
necessarily
workarounds
to
be
compliant
or
trying
to
make
the
process
that
they're
taking
today
still
work
after
these
changes.
Maybe
the
solution
here
is
really
just
to
make
the
whole
thing
much
easier
for
them
while
being
compliant,
and
maybe
that's
a
brand
new
process.
D
Yeah,
that's
that's
great
thanks.
All
I
can
go
ahead
and
open
up
that
issue.
I
just
wanted
to
make
sure
we
weren't
there's
already
a
lot
of
exit
criteria
and
things
going
on
there.
So
I
just
want
to
make
sure
I
I
figured
even
if
it
wasn't
within
this
working
group
like
the
conversation
would
still
happen
somewhere,
but
just
wanted
to
see
if
we
thought
this
was
a
good
form.
To
kind
of,
I
guess
lead
that
conversation.
C
I
think
it's
good
to
have
a
lot
of
the
people
in
the
working
group
involved
in
the
conversation
thinking
about
how
it
affects
like
it'll.
It
might
affect
like
processes
that
maintainers
follow,
but
I'm
not
necessarily
sure
it
it
really
like
disrupts
like
it's,
not
necessarily
adding
more
work
for
a
maintainer
is
the
thing
I
noticed.
A
I
could
see
maybe
additional
like
focus
time.
You
know,
looking
at
the
merge
request
counter
there's
I
do
this
several
times
every
day,
I'm
like
what's
the
status,
what's
the
status
what's
the
status,
so
I
could
see
maybe
that
approach
or
an
obligation
that
now
now
because
you're,
the
maintainer
and
you're
not
able
to
merge
now
you
need
to
go,
find
another
maintainer
and
whose
responsibility
is
this
and
things
like
that.
E
Yeah
I
brought
up
this
point
last.
I
mean
last
meeting
that
I
could
attend
and
I
created
an
issue
and
I
haven't
got
much
feedback
from
working
group,
so
I
was
wondering
how
we
want
to
proceed
with
this,
whether
we
think
it's
something
that
we
need
to
bring
it
to
broader.
You
know
engineering
community
to
see
what
they
feel,
but
mainly
my
point
is
that
I'm
just
wondering
whether
we
want
to
increase
the
quality
of
the
maintainer
reviews,
or
we
just
want
to
increase
the
number
of
maintainers
by
lowering
the
bar.
E
I
think,
by
giving
them
more
time
to
focus
on
the
reviews.
I
think
we
will
get
higher
quality
reviews
more
often
because,
like
maybe
smaller
maintainers
will
be
more
familiar
with
the
process
and
give
be
able
to
give
better
reviews
than
those
who
are
reluctant
to
be
a
maintainer
or
just
being
a
maintainer
just
because
it
was
a
job
description
or
something
like
that.
So
I
wondering
whether
we
should
look
at
that
aspect,
so
I
just
want
to
hear
your
thoughts.
F
I
think
this
is
an
interesting
one,
because
this
is
something
I've
heard
a
lot
from
trainee
mentees
that
they're
not
entirely
sure
how,
once
you
become
a
maintainer,
how
to
like
balance
that
workload
and
and
sort
of
effectively
contribute
still
to
your
team
as
well,
and
it's
also
been
something
that
I've
heard
has
affected
different
mentees
traineeship
as
well
different
times.
Your
team
responsibilities
tend
to
sort
of
take
priority
over
updating
your
training
and
maintainership.
F
So
it
would
be
good
to
get
some
clarity
around
this.
I
can
add
some
thoughts
to
that
as
well.
If
that
makes
sense
to
the
issue,
sorry.
A
I'll
add
that
one
piece
of
feedback
we've
received
in
the
past
talking
about
maintainership,
is
that
you
know
when
you
talk
about
job
description.
A
B
Like
ignorance,
I
have
always
assumed
that
groups
that
I
work
in
factor
in
people
who
are
maintainers
as
part
of
their
capacity
and
it's
like
an
accounted
for
piece
of
like
the
time
that
is
they're
given
in
a
month
and
and
I'm
given
when
I've
worked
with
my
engineering
managers,
I'm
given
a
capacity
for
the
team,
and
I
assume
that
that's
reflective
of,
like
all
the
other
things
that
engineering
managers
know
that
their
engineers
need
to
do,
and
so
I
don't
necessarily
if
that
number
got
lower,
I'm
not
sure
I
would
know
why
or
necessarily
care
like
it
varies
from
month
to
month.
B
So
I
don't
know
that
I,
I
necessarily
have
a
strong
opinion,
one
way
or
the
other.
I
guess,
if
you
want
more
of
that
time,
that'd
be
interesting
to
know
like
how
much
more
time
but
like
a
weight
of
one
from.
However
many
maintainers,
I
don't
know,
we
have.
B
Three
back
end
maintainers
and
maybe
two
two
or
three
back-end
maintainers
and
one
or
two
front-end
maintainers.
I
think
just
one
actually
I
mean
that's
not
a
very
significant
hit
to
like
my
capacity
for
other
teams.
It
might
be
more.
A
So
david,
I
think
kai
brings
up
a
really
good
point
that
number:
what's
that
number
you
know
that
would
be
a
hard
thing
to
pin
down.
What
do
you
personally
feel
you
need
more
more
of
like
a
day
dedicated
across
a
week
or
whatever
it
is,
how
much
more
time
or
maybe
asked
another
way.
What
time
do
you
feel
is
missing
from
your
maintainership.
E
I
think,
like
it's
sort
of
it's
not
like
one,
one
number
that
you
can
give
to.
You
have
multiple
different
kind
of
maintainers
right.
Obviously,
database
maintainer
have
a
higher
workload
and,
like
back
end
and
front
end,
also
different
project.
They
all
have
different
workloads.
So
we
can't
have
just
one
number
to
do
that.
E
I
guess
if
we
need
to
be
a
bit
flexible
around
that,
like
depending
on
the
situation,
so
it's
basically
you
know
the
dri
or
the
many
just
discussion,
how
how
much
of
work
that
would
be
and
decided
that
a
number,
but
I
think
mainly
the
reason
that
I'm
bringing
it
up
is
that,
like
it's
kill
or
kai,
said
we
don't.
E
As
far
as
I
know,
we
don't
account
the
fact
that
someone
is
maintainer
when
you
are
working
out
the
capacity,
but
obviously
we
think
that
it
will
be
higher,
and
that
means
that
many
people
feel
like.
I
know
that
some
people
dropped
off
being
a
maintainer.
I
guess
the
one
of
the
reason
is
that
they
feel
pressure
to
do
more
than
they
can
do
and
by
acknowledging
that
by
becoming
maintainer
you're
given
time
to
actually
do
the
maintainer
properly,
instead
of
just
expecting
them
to
do
their
job
plus
a
maintainership.
E
E
E
C
I've
been
making
a
lot
of
phases
because
I've
been
trying
to
think
about
this,
but
I'm
wondering
if
it's
useful
to
also
provide
some
guidance
to
managers.
Because,
sorry,
let
me
back
back
that
up.
I
factor
my
maintainers
potential
review
load
ahead
of
time
as
part
of
capacity
planning
for
the
next
milestone,
so,
for
example,
for
15.0,
because
we
knew
we
ourselves
had
a
lot
of
breaking
changes.
But
we'd
also
know
that
we'd
be
reviewing
a
lot
of
those
changes.
C
We
we
kind
of
earmarked
more
capacity
for
reviews
and
took
on
less
because
of
that.
So
but
it
sounds
like
not
every
group's
doing
that,
and
so
I
wonder
if
that
should
be
something
that
we
discuss
as
an
org
in
terms
of
like
making
sure
that
you're
factoring
in
your
maintainers
capacity
being
spent
towards
reviewing
things.
Obviously,
it's
hard
to
tell
and
hard
to
predict
milestone
the
milestone,
but
in
the
cases
of
like
a
major
release,
being
more
concern,
being
more
cautious
would
be
beneficial
there.
F
I
didn't
have
too
much
more
to
add.
I
was
actually
gonna
say
more
or
less
the
same
thing.
I
think
it
would
be
good
to
reinforce
it
at
the
manager
level
and
probably
needs
to
be
something
that
needs
to
reinforce
milestone
by
milestone
particularly
say
on
the
front
end.
We
often
get
okrs
for
pyjamas
migrations
or
just
generally,
when
the
hackathons
come
around.
Those
really
spike
up,
mr
reviews,
so
that
definitely
impacts
the
capacity
in
those
milestones.
C
Yeah,
it's
certainly
harder
for
me,
people
who
have
been
maintainers
for
less
time,
but
I
think
those
that
have
been
for
for
at
least
a
few
miles,
some
to
get
a
general
sense
of
how
much
time
they're
spending
on
reviewing-
and
I
think
that's
like.
I
think,
that's
what
is
being
communicated
to
you
in
terms
of
like
the
general
capacity
available
for
features
so
to
ziko's.
Point
yeah.
C
If
we
have
things
coming
up
like
a
hackathon
or
a
major
release,
or
something
like
that,
then
we
should
be
able
to
give
you
that
that
justification
of
we're
gonna
actually
have
one
less
weight
per
per
maintainer.
Because
of
this
reason,
so
we
should
be
able
to
clearly
communicate
that
whenever
we
want
to
say
that
we
would
have
reduced
capacity.
So.
A
I
think
I
have
two
things,
one
of
them
david,
based
on
that
conversation.
Do
you
think
what
would
help
you
personally
is?
If
this
was
just
more
transparent
in
terms
of
your
manager,
comes
to
you
and
says
I
just
want
you
to
know
I've
allotted
time
or
capacity
or
whatever
it
is
for
you
to
do
so.
Many
reviews
or,
however,
many
reviews
that
you
want
to
do
this
week
and
just
being
transparent
about
we've.
Given
you
time
that
way,
it's
not
happening
behind
the
scenes,
and
you
know
that
it's
happening
and
things
like
that.
E
Yeah,
I
think
like
including
that,
during
the
capacity
planning
and
to
specify
you
know
this
is
how
much
you
know
weight
that
we
are
signing,
because
you
are
a
maintainer
or
you
know
things
like
that.
Endless
having
that
kind
of
conversation
makes
it
in
a
sense
that
you
are
taking
a
very
cool
company-wide
responsibility,
as
opposed
to
team-wide
responsibility.
Right
capacity
planning
is
team-wide
responsibility
and
maintainership
is
bigger
than
that.
E
So
we
need
to
acknowledge
that
you
are
taking
on
more
more
responsibility
outside
of
the
team
by
removing
some
of
your
capacity,
so
making
that
clear
would
help,
for
especially
people
with
training
maintainers.
Also
they'll
spend
lots
of
time
to
get
that
up
to
speed
by
acknowledging
that
you
are
doing
it,
that'll
make
it.
A
A
And
and
then
the
second
thing
that
I
wanted
to
mention
was
that's
a
really
good
call
out
about
where
what
role
does
the
engineering
manager
play
and
so
we're
talking
about
in
one
of
the
other
exit
criterias
we're
talking
about
guidance
in
terms
of
how
many
reviews
should
a
maintainer
take
on,
and
things
like
that,
it
should
be
maybe
the
same
kind
of
guidance
to
an
engineering
manager
in
terms
of
capacity
planning,
like
you
were
saying
dennis
and
for
these
spikes
like
the
breaking
changes
or
the
major
releases,
and
things
like
that.
A
A
We're
at
time,
that's
why
I
put
mine
last,
but
it
has
been
a
month.
We
should
walk
the
board
if
you
have
an
issue
in
dev
or
if
there's
an
issue,
that's
unassigned,
please
see
how
it
can
move
itself
along
there's
only
two
closed
issues.
I
know
there's
a
lot
of
things
in
slack
with
issues
and
merge
requests,
and
things
like
that
which
is
not
reflected
on
the
board.
So
if
we
can
clean
that
up,
it
would
be
much
easier
for
steve
to
communicate
changes.