►
From YouTube: 2022-06-28 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
B
Hello,
we
are
one
minute
pass,
so
I
was
going
to
get
started,
but
I
think
it's
just
us
three:
okay,
okay,
all
right!
B
Welcome
everybody
to
the
june
28
or
29th,
depending
on
where
you're
at
maintainership
working
group,
so
starting
at
the
agenda
changes
since
last
time
I
was
actually
out
of
office
for
the
last
two
meetings,
and
so
I
have
not
followed
up
on
any
of
the
action
items
to
put
in
the
changes
since
last
time,
so
it
may
not
be
completely
filled
out,
but
I'll
start
with
steve
who's,
not
in
attendance.
This
is
for
exit
criteria,
number
five,
the
communication
plan.
B
He
says
this
is
45,
complete,
no
changes
since
last
week,
but
a
reminder
that
we
have
labels
for
mrs
and
issues
that
will
help
facilitate
communication
of
updates.
Please
also
consider
adding
feedback
to
the
run
book
for
communicating
changes.
This
will
be
a
reference
to
help
increase
adoption
and
awareness
of
any
changes.
So
if
there
are
any
topics
you
think
are
missing,
please
drop
a
comment.
B
All
right
go
ahead.
Nick.
C
Yep,
this
is
for
exit
criteria,
one
implementation
plan
to
remedy
gaps.
I
moved
it
from
five
to
ten
percent
and
that's
because
I
added
some
issues
for
each
of
the
projects
that
we
decided
to
focus
on,
and
so
just
some
help
needed,
and
I
guess
I'll
broadcast
this
more
widely
in
the
channel
since
it's
just
the
three
of
us
in
this
call,
but
yeah
one
is
for
feedback
on
the
issue
structure.
So
just
a
very
simple
like
what
are
the
metrics?
What
do
we
think
the
gaps
are
for
this
project?
C
You
know
what
are
our
targets
any
help
needed
action
steps
so
just
feedback
on
that
structure.
I
added
an
example
for
the
database,
maintainership
and
and
reviewer
issue,
because
that's
something
that
we've
kind
of
have
an
example
for
this
for
already
with
all
the
work
that
alex.
D
C
In
coming
up
with
targets
and
and
some
metrics
to
back
that
up-
and
so
a
lot
of
this
is
just
linking
to
the
issue
that
he
had
already
created,
but
I
think
that's
okay,
too,
if
some
of
these
groups
already
have
other
issues
they're
working
off
of,
I
think
I
think
it's
fun
to
use
those
just
as
long
as
we
have
a
plan
and
kind
of
summarize
some
of
these
some
of
these
items
and
then.
B
I'm
sorry
for
the
for
the
issue
structure
is,
I
just
want
to
make
sure
I'm
understanding,
you're
saying
so.
If,
in
this
example,
the
issue
is
going
to
be
based
on
the
database
coverage
and
it'll
have
any
metrics
that
are
available
targets
needed
for
the
next
6
to
12
months
and
any
action
items
that
need
to
be
taken
in
order
to
get
there
right.
A
So
I've
got
a
question
nick,
so
this
is
part
of
a
larger
epic,
correct,
yes
and
so
you're.
Looking
for
dris
for
each
of
these
issues
is
what
you're
saying.
C
Yeah,
ideally
I
I
I
mean
it
would
be
great
to
have
somebody
involved
who's
who's,
actually
that
a
maintainer
of
one
of
those
projects
or
that
maintainer
type,
and
if
I
can't
find
dris
for
each
of
those
I
mean
I
I
I
find
reaching
out
to
somebody
who's-
have
who's
active
and
in
those
and
and
working
with
them
more
closely
and
being
the
dri.
But
I
think
ideally
somebody
would
would
volunteer
to
to
take
that
issue
on
directly.
A
If
should
we
like,
at
some
level,
go
to
maybe
the
directors
and
ask
them
to
like
look
for
team
members
who
are
looking
for
like
career
opportunities,
you
know
growth
or
what
have
you
and
maybe,
if
it
comes
from
their
their
management,
we
might
get
more
more
volunteers
instead
of
just
saying
like
I
don't
look
at
the
working
group
as
the
only
group
that
we
can
ask
for
help
on
this
one
until
we
start
doing
that.
What
are
your
thoughts,
michelle.
B
Yeah,
I
totally
agree.
I
think
that
this
group
is
going
to
impact
all
groups
at
git
lab,
and
so
that
makes
sense
and
if
nothing
else
we
should
circulate
it.
I'll
also
say,
though,
that
I
would
empower
the
functional
leads
to
do
the
same
thing
in
terms
of
circulating.
It.
A
A
C
I
think
that's
a
good
idea
and
I
think,
to
michelle's
point
as
well:
opening
it
up
to
the
functional
leads.
We
already
have
in
this
group,
if
there's
already
say
representation
from
certain
projects
like
a
workhorse
or
or
front
end
or
back
end,
and
anyone
in
this
group
wants
to
take
that
on.
I
think
I'd
see
what
we
get
from
people
who
are
involved
in
the
group
first
and
then,
if
there's
any
one,
we're
missing
then
yeah,
taking
that
also
to
development
staff
and
and
putting
on
a
call.
B
Do
you
think
nick
I'm
sorry
we
keep
digging
in
on
this,
but
I'm
just
looking
at
the
timeline
for
the
working
group.
So
far,
do
you
think
two
weeks
for
finding
a
dri
for
the
dri
to
circulate
this
and
to
get
what
those
targets
should
be.
C
D
C
I
don't
know
if
getting
getting
a
good
sense
of
the
targets
by
then
might
be
tricky,
because
some
of
those
projects
might
be
lacking
the
the
data
needed
like
I
think
we
could
probably
get
some
qualitative
data
or
you
know,
anecdotal
information
about
what
the
gaps
are,
but
for
some
of
those
we
might,
we
might
be
needing
to
do
some
work
to
to
create
dashboards
and
we
do
have
the
database
team
example
and
we've
been
able
to
to
use
to
port
that
over
for
omnibus.
C
So
maybe
it's
it's
not
too
much
more
work
to
do
it
for
these
other
projects,
but
yeah.
I
think
two
weeks
might
be
tough
for
all
that,
but
I
think
we
certainly
aim
for
that.
B
Okay,
all
right
cool
are
we
do,
should
we
move
on
to
dennis.
B
Okay,
dennis,
I
would
hate
to
read
all
of
this:
let's
see
no
exit
criteria,
just
your
friendly
neighborhood
working
group
members,
the
dentist
was
pushing
for
to
see
how
many
active
trainee
maintainers
would
be
able
to
convert
into
maintainers
he'll
be
pinging
some
people
in
an
issue-
and
this
is
in
order
to
contribute
to
the
trainee
target
of
30
for
the
okr-
and
there
is
looks
like
looks
like
a
triage
ops
issue
for
keeping
the
trainee
maintainer
issues
updated
and
yeah
I'll.
B
D
Yeah,
I
thought
I'd
just
let
you
guys
know
that
last
time
I
created
nema
for
mentioning
the
capacity
adjustment
when
you
become
a
maintainer
and
things
like
that,
so
eric
approved
about
a
week
ago,
and
then
I
pinged
him
after
a
while
and
then
christopher,
I
haven't
heard
anything
from
him
yet
so
I
might
just
ping
him
just
to
see
what
it
thoughts
are
and
hopefully
we
can
get
it
merged.
B
Okay,
there
is
actually
help
needed
that
nick
mentioned
up
above
and
then
otherwise
I'll
move
on
to
discussion
and
questions.
B
I
know
that
this
is
going
to
be
a
controversial
topic
but,
as
I
said
before,
I
was
out
of
office
for
the
last
two
meetings
and
when
I
came
back
there
was
a
lot
of
data
in
the
slack
channel.
There
was
a
lot
of
data
in
the
agenda.
I
already
had
a
lot
of
data,
a
lot
of
data
from
previous
meetings,
and
then
I
saw
robert's
questionnaire,
so
in
robert's
questionnaire
responses.
B
So
one
two
and
five,
I
know
that
we've
discussed
already
in
past
meetings
and
david.
I
think
the
capacity
adjustment,
mr
actually
contributes
to
it.
I
linked
to
the
issue.
So,
based
on
that,
I
want
to
make
sure
that
we're
still
addressing
the
end
result.
So
a
lot
of
the
focus
of
this
working
group
has
been
based
around
making
the
guidelines
more
efficient,
making
the
trainee
process
more
efficient,
making
the
distribution
more
efficient.
B
We're
really
focused
on
kind
of
how
to
get
more
maintainers,
but
the
result
is
still
to
have
more
maintainers
and
so
at
a
bias
for
action.
I
did
open
up
this,
mr,
it's
just
to
collaborate
on
requiring
seniors
to
become
maintainers,
but
from
my
perspective
it
sounds
like
we
are
doing
the
right
things.
We
are
working
to
address
these
concerns,
and
but
we
just
still
need
to
keep
that
other
side
of
it
in
mind.
B
Can
can
you
elaborate
more
on
that
last
part,
the
existing
maintainers
and
their
capacity?
The
problem
today
is
that
they're
overwhelmed.
D
Yeah,
I
guess
that's
what
I'm
saying:
that's
where
my
emma
was
coming
from
that,
like
I
mean,
depending
on
how
much
you
want
to
adjust
the
capacity
to
I
guess,
like
I
saw
quite
a
few
times,
people
were
not
really
willing
to
become
a
maintainer
because
of
extra
work.
You
know
things
and
they
don't
want
to
be
like.
Should
we
still
push
all
seniors
to
be
a
maintainer,
even
though
they
have
they
have
that
kind
of
feeling.
At
this
point.
B
C
B
B
On
that,
it's,
like
some
people,
have
done
more
than
120
mr
reviews
in
the
last
30
days.
So
I
think
we've
got
like
really
far
over
on
one
side
and
then
the
other
side
of
that
problem
is
we.
We
need
more
maintainers
and
I
think
that's
a
different
approach,
new
maintainers
and
existing
maintainers,
and
so
maybe
trying
to
accommodate
solutions
towards
both-
and
I
think
this
working
group
is-
I
mean
for
new
maintainers.
I
think
we're
working
on
what
the
training
training
mentorship
is
like
what
you'll
actually
be
doing
as
a
maintainer.
B
I
know
there's
an
issue
for
local
reviewers
and
things
like
that.
So,
if
you
were
to
ask
me,
I
would
say
yes,
I
think
it's
both.
I
think
it's
the
capacity
and
the
conversions.
D
I
I
suppose,
like
yeah,
I
think
it's
sort
of
related.
If
we
are
addressing
other
things
yeah,
it
will
be
easier
for
them
to
be
a
maintainer,
but
I
guess
what
I'm
saying
is
just
to
I
don't
know.
I
want
to
make
it
more
voluntary
process,
as
opposed
to
a
compulsory
process
to
become
a
maintainer,
because
I
I
don't
know
personally,
I
feel
like
by
making
it
compulsory.
I
I'm
less
motivated
or
less
what
I
call
it's
not
proactive,
a
task
for
me
to
do
as
opposed
to
it's
something
that
I
have
to
do.
A
So
I
I
like
to
respond
a
little
bit
so
the
way
I
see
it,
my
big
picture.
We
need
maintainers
to
support
our
craft.
That's
the
problem
we're
trying
to
solve.
I
don't
think
we're
trying
to
force
people
to
become
maintainers
against
their
will
or
for
any
other
reason
that
that
we
need
to
support
our
product
and
we
need
to
not
burn
out
the
maintainers
we
have.
A
So
if
people
are
saying
no,
I
don't
want
to
be
a
maintainer,
but
I
have
this
great
answer
solution
that
will
solve
the
problem
and
I
haven't
seen
a
solution
that
will
prevent
our
the
maintainers.
We
have
from
being
burnt
out
or
support
our
product.
So
I
it's
almost
like
I'm
off.
If
anybody
out
there
says
about
imox,
no
one
wants
to
be
an
imoc
probably,
but
if
we
don't,
we
have
no
one
to
manage
the
incidents.
So
it's
really
tough
with.
A
How
do
you
meet
the
needs
of
the
product
and
not
like
burn
out
your
fellow
peer
at
the
same
time
asking
people
to
to
do
more
work
to
carry
more
load
so
that
someone
else
doesn't
have
to?
We
have
a
quality
product,
so
something
has
to
get
it's
either
going
to
be
the
product
or
the
people
being
burned
out
and
leave
or
people
say
you
know
what
I'm
going
to
take
one
for
the
team.
My
product
needs
me.
My
company
needs
me,
my
peers.
A
Need
me:
I've
had
teams
where
the
entire
team,
intermediates
and
seniors
were
all
we're
all
maintainers
for
multiple
years
and
and
there
were
some
teams
that
didn't
have
people
as
maintenance
because
they
didn't
want
to
be,
and
they
got
to
the
point
where
the
team
that
had
our
own
maintainers
were
completely
overwhelmed.
They
weren't
working
on
their
features
and
they
spent
all
their
time
doing,
reviews
and
it
they
felt
like
that.
Wasn't
fair.
So
it's
a
struggle
for
us
to
come
up
with
the
way,
that's
fair
and
we
can
support
our
product.
A
So
that's
I'm
just
framing
like
what
the
problem
is
that
and
it's
really
tough,
because
as
far
as
I'm
concerned,
we've
been
asking
for
volunteers,
the
the
current
system
is
a
volunteer
system
and
it's
breaking
down.
We
have
an
okr
right
now.
I
don't
think
we're
doing
so
great
on
it
to
get
maintainers
to
volunteer.
D
Yeah,
I
understand
that
that's
what
this
is
for,
but
I
guess
the
way
where
I'm
coming
from
is
more.
I
want
to
think
about
more
from
the
incentivizing
becoming
a
maintainer
as
opposed
to
making
a
compulsory.
That's
I
mean
that's
the
ideal
situation.
That's
what
I'm
saying
that
it
would
be
nice
if
you
don't
have
to
come
like
make
it
compulsory,
but
maybe
creating
some
environment
where
they
get
other.
D
You
know
encouraging
people
to
spend
more
time,
maintaining
if
they
want
to
be
or
like.
I
just
think
their
capacity
is
one
thing,
but
we
can
think
about
some
other
things,
maybe
hopefully
incentivizing
becoming
a
maintainer
as
opposed
to
you
know,
just
a
thing
you
have
to
do.
That's
that's
my
thought,
but
that's
just
my
thoughts,
though.
A
I
think
your
thought
is
a
commonly
held
belief.
I
think
that
you're
doing
a
great
job
representing
how
a
lot
of
people
out
there
feel,
but
it's
a
tough
problem
that
has
to
be
solved
and
I
feel
like
what
we
have
right
now
is
a
volunteer
system
right
now,
but
I
can't
keep
asking
someone
to
burn
themselves
out
like
something
something's
got
to
change.
A
I
think
we're
doing
a
great
job
and
I
think
what
michelle
was
trying
to
figure
out
is
well
we'll
we'll
make
it
easier
so
that
they'll
want
to
be
a
maintainer
like
incentivize
them
by
giving
answers
and
solutions,
and-
and
I
wonder
if
we
did
the
survey-
I
know
that
I'm
saying
in
the
survey,
but
if
we
did
the
survey
and
said
okay,
if
we
fix
this
this
and
this,
how
would
you
feel
if
that
number
would
look
different?
A
C
Yeah
yeah
david,
and
I
think
that
point
brings
up
another
some
other
questions
too,
like
if
we
are
requiring
that
and-
and
there
is
a
motivation
problem
like
people
are
becoming
maintainers
because
now
it's
required,
but
then
they're
just
maybe
always
putting
up
red
circles
or
not
taking
on
you
know,
like,
I
think,
there's
the
question
of
are:
are
they
going
to?
If
someone
is
doing
this,
but
they're
not
motivated
to
do
it?
C
Are
they
actually
are
they
actually
providing
the
covers
that
we'd
be
hoping
and
then
and
then,
if
that's
not
the
case,
then
are
we
also
requiring
ourselves
to
go
further
kind
of
to
your
point
darv
about
the
imoc
program
like
it
is
a
very
kind
of
mandatory
thing,
and
so
so
then
we're
having,
and
it
has
a
lot
a
lot
of
process
around
it
to
make
sure
that
that
people
are
doing
these
things
like
you
know,
there's
a
lot
more
scheduling
and
that
kind
of
stuff
that
goes
into
it
then.
C
C
I
don't
have
a
strong
opinion
on
either
way
yet,
but
I
do
see
like
if
we
go
down
this
path,
then
we
need
to
maybe
start
adding
a
whole
bunch
of
other
things
in
the
process
to
make
sure
that
as
people
become
maintainers,
we
are
then
kind
of
getting
the
coverage
that
that
we
expect
out
of
out
of
them.
So
it
does
kind
of
add
a
bunch
of
extra
process
potentially
down
the
road.
E
I
don't
have
too
much
to
add
to
this.
I
probably
have
a
slightly
different
view
to
david
that
I
quite
enjoy
maintaining
reviewing
in
that
aspect,
and
but
I
think
I
agree
with
think
that
maybe
there
is
additional
process
required
further
down
the
track
for
this.
I
think
part
of
it
might
be
coming
back
again
to
that
scheduling,
issue
and
workload.
E
I
think,
generally,
if
we
have
more
maintenance
and
if
all
our
seniors
were
maintainers
that'll
reduce
the
workload
on
all
maintainers,
which
I
think
is
the
end
goal,
and
maybe
it's
about
just
finding
a
balance
between
maintainers
who
spend
say
like
50
of
that
time,
reviewing
as
opposed
to
maintainers,
who
have
maybe
25
of
that
time,
I'm
not
entirely
sure
how
that
would
work
outside
of,
like
maybe
like
a
team
level.
E
So
say
if
you
had
a
team
and
you
had
two
maintainers
between
the
team,
you
could
sort
of
work
out
what
sort
of
balance
you
have
yeah.
That
might
be
something
you
need
to
think
about
as
part
of
this
proposal
as
well.
B
Yeah,
nick
ezekiel,
that's
actually
and
also
david.
My
thought
is
in
terms
of
incentivization.
I
hear
you
there
what
if
there
was
a
metric
similar
to
like
the
narrow
mr
rate,
where
we
could
say
this
team
has.
B
B
Maintainer
merged,
mrs
out
of
this
group,
or
based
on
an
individual
or
or
whatever
it
is
we
do
already.
I
said
it
kind
of
in
terms
of
coverage
on
this.
It
is
already
part
of
the
exit
criteria
to
kind
of
say
you
know
today
we
need
this
much
coverage
and
in
12
months
we
need
this
much
coverage,
so
these
are
kind
of
the
targets
that
we
need
to
hit,
but
maybe
putting
a
number
at
the
team
level.
You
know
narrow
mr8
is
sort
of
the
productivity
incentivize.
D
Yeah
but,
but
I
guess
from
my
point
of
view
is
analysts,
knowing
their
sentiment
would
help
us
to
see
which
way
we
need
to
go.
If
you
see
that
lots
of
people
want
to
spend
more
time
and
we
are
having
trouble
finding
maintainer,
then
why
can't
we
let
them
be?
You
know
I
don't
know,
that's
that's
my
feeling.
B
Well,
we
do
already
have
the
data
that
says:
11
do
not
want
to
be
a
maintainer
and
35
do
not
want
it
to
be
a
responsibility,
and
so,
once
again,
I
think
this
is
a
split
between
do.
We
accommodate
our
existing
team
members
who
are
overwhelmed
and
may
or
may
not
need
more
time,
and
what
about
the
non-maintainers
that
the
survey
was
for?
So
I
think
again,
that's
really
a
compromise
on
both
levels.
A
But
my
guess
would
be
that
a
lot
of
times
they
end
up
having
to
do
more
work
because
there
are
fewer
of
them
and
they
have
to
have
more
reviews
and
things
like
that,
and
it
could
actually
be
really
impactful
for
aipac
to
have
like
all
seniors,
not
saying
it
should
be
apac
specific.
But
that
group
actually
might
really
be
supportive
of
all
seniors
being
maintainers,
because
maybe
they
have
a
hard
time
finding
maintainers.
A
And
I
think
that
we
need
to
think
about
everyone
and
not
just
like
mia
and,
like
maybe
there's
an
epiphany.
C
A
B
When
I
was
trying
to
find
representation-
and
I
can't
recall
what
it
was
that
I
found-
but
it
it
was
something
like
ezekiel-
I
might
have
told
you-
maybe
you
remember
it's
like
there
were
no,
there
were
no
non-maintainers
in
aipac
or
there
were
no
there
weren't
any
of
something
in
apac,
and
so
it
was
like
an
unequal
distribution,
but
I
don't
know
I
mean
this
kind
of
goes
back
to
my
last
point
in
terms
of.
B
E
Just
anecdotally
from
my
experience
it's
maybe
it's
because
of
the
domain
I
mean
I
feel
like
I'm
not
specifically
overburdened
being
in
apac
with
maintainer
reviews.
I
kind
of
feel
like
it's.
Maybe
I'm
just
a
general
burden.
My
guess
would
be
that
it's
probably
more
project
and
specific
domain,
so,
like
databases
for
example,
is
one
that
always
gets
overworked,
and
I
guess
some
of
the
other
projects
like
runner
and
pages,
and
things
like
that.
So
not
sure.
D
Yeah,
I
feel
the
same.
I
don't
think
I'm
overburdened
by
just
because
I'm
in
apac,
I
think
it's
depending
on
the
time
of
the
day
and
stuff
like
that.
So
that's
different
but
yeah.
I
guess
like
that's,
I'm
a
reviewer
of
database
so
that
increased
my
chance
of
getting
reviews
a
bit
higher,
but
also
that's
stopping
me
from
becoming
a
maintainer
of
database,
because
it
would
mean
that
I
would
spend
more
time
on
it
to
get.
You
know
be
more
efficient
in
it
and
things
like
that.
So
there's
a
that
thing
too.
A
Thanks
for
that
data
point
michelle
in
terms
of
your
your
question,
I've
been
asked
most
multiple
times
by
engineers.
If
we
could
track
their
review
metrics,
so
they
could
get
credit
they
felt
like
just
tracking
mr
throughput.
It
was
not
transparent
about
like
their
what
they're
contributing
to
the
team.
So
I
don't.
I
would
imagine
that
most
engineers
will
welcome
tracking
the
review
metrics
by
the
engineering.
What
do
you
ezekiel
david?
What
do
you
think?
Would
that
be
something
you
were
welcome,
just
so
that
you
could
kind
of
get
credit.
E
I
mean,
maybe
I
I
do
kind
of
loosely
look
at
the
workload
and,
admittedly
sometimes
I
guess,
if
I've
had
like
a
red
circle
up
or
something-
and
I
noticed
I'm
kind
of
falling
below
the
average
for
frontend
main
maintainers,
I
might
kind
of
put
a
little
bit
more
emphasis,
but
that's
more
of
a
I
guess,
personal
thing,
so
yeah,
I'm
not
sure
if
getting
credit
and
tracking
it
in
that
respect,
would
make
much
difference
to
me.
D
Yeah,
I
guess,
like
I
do
a
similar
thing
like
you:
do
this
kill
just
to
see
where
I
am
in
terms
of
review
and
occasionally
just
to
see,
but
I
sometimes
I
feel
like
I'm
overwhelmed
with
like
five
reviews
or
whatever.
Sometimes
I
need
to
say
no
and
stuff
like
that.
So
that's
when
I
look
at
it
as
well,
but
I
don't
know
I
feel
like,
instead
of
not
so
much
about
like
crediting,
but
so
but
more
about
a
data
point
just
to
see.
D
B
C
Yeah,
that's
that's
okay
and
I
do
think
the
discussion
about
metrics
is
good
to
keep
having
but
yeah.
I
was
just
gonna
say
if
I
read
the
requirement
correctly,
we
are
already
expecting
seniors
to
eventually
become
maintainers,
so
I
I
think
you
know
maybe
the
change
we're
not
it's
not
so
controversial,
we're
making
a
little
more
concrete,
but
I
think
the
expectation's
still
there,
if
I'm
not
mistaken,
is
that
right.