►
From YouTube: 2022-05-23 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).
C
B
B
It
just
getting
gets
intense
with
like
the
brands
and
then
the
very
steep
slope
of
pricing
or
whatever
it
gets
very
expensive
very
quickly.
It's.
D
I
bleached
my
son's
hair
this
weekend,
so
he
looks
like
a
like
an
anime
character.
D
Yeah
he's
ready
to
be
in
a
band
he's,
got
some
color
changing
glasses,
so
they're,
like
all
black
when
he
gets
in
the
sun,
yeah
he's
a
band
member.
Okay,
we're
one
minute
over!
Thank
you
all
for
joining.
This
is
the
maintainership
working
group
for
may
23rd
2022
and
let's
go
over
changes
since
last
time.
If
you
want
to
get
a
started
max.
A
Sure
so
yeah
we've
made
some
good
progress.
I've
sort
of
put
a
50
percent
complete
mark
on
it,
but
we're
open
to
that.
So
the
data
from
roulette
is
now
available
in
site
sense
and
can
be
queried,
which
is
really
great
and
I've
put
a
link
in
the
agenda
there.
The
work
I've
done
to
start
building
out
some
sort
of
meaningful
dashboards,
based
mainly
on
data
suggestions
for
what
that
dashboard
should
look
like
in
terms
of
how
it
can
be
valuable,
so
left
for
this
exit
criteria.
A
So
it
doesn't
go
on
forever.
I
guess
to
define
an
endpoint
for
it,
so
I
think
we
should
try
and
build
as
many
of
those
graphs
as
possible
and
where
it's
not
possible
to
figure
out
either.
Why
or
whether
or
not
you
know
to
maybe
follow
up
to
build
those
at
a
later
date
and
based
on
that
newly
available
analysis,
whether
or
not
we
should
be
updating
our
kpis
for
maintainership
in
general,.
F
Hello,
I
I
put
a
so
for
the
training
maintainership
updates
I've
put
a
completion
mark
of
about
five
percent.
I
don't
think
that
we've
made
a.
I
haven't,
made
a
whole
lot
of
progress
on
this.
I
did
file
an
issue
last
week
that
I'm
just
starting
to
circulate
now
about
soliciting
proposals
for
updating
how
we
change
how
we
want
to
handle
training
maintainership
going
forward.
So
if
folks
have
a
minute
to
look
through
that
in
the
future,
that
would
be
great
I'll
circulate
this
in
slack
as
well.
F
I
also
wanted
to
say
thanks
to
chun
for
filing
an
issue
and
being
proactive
about
changing
the
the
some
of
the
voting
around
adding
new
maintainers.
I
think
that's
a
that's
a
good
proposal
so
yeah.
If
people
have
feedback
on
that,
please
feel
free
to
add
it
to
that
merge
request.
D
G
Thank
you
natalia
you
want
to
go,
I've
run
a
survey
for
back-end
and
front-end
maintainers
database
aren't
included,
but
we
can
include
them
in
the
survey
as
well
asking
what
is
the
number
of
the
mars?
They
are
comfortable
reviewing
for
the
day,
it's
very
rough
numbers,
because
we
don't
count
on
future
mars.
That
can
happen
like
the
last
week
for
the
milestone.
G
E
Yeah,
I
was
just
curious
like
if
we
thought
that
was
a
reasonable
expectation
or
not
and
kind
of
the
other
kind
of
follow-up.
Is
you
know
if
it
is,
should
we
like
give
like
some
guidance
but
like
to
be
clear,
make
it
work
in
a
way?
That's
not
a
requirement,
it's
more
of
like
this
is,
like
you
know,
an
objective
or
a
goal.
G
Yeah
looking
through
that
dashboard,
I
can
tell
that
for
front
end
is
1.4
mr
per
maintainer
per
day,
and
even
considering
the
fact
that
50
of
maintainers
are
unavailable,
it
should
be
doable
of
course,
right
now.
The
distribution
is
not
even
for
maintainers,
but
this
a
different
problem
has
a
different
solution
for
this
and
on
to
darva.
H
Did
we
differentiate
between?
Is
there
a
way
to
differentiate
between
the
two.
G
No,
it
was
the
same
survey
for
both
groups
posted
on
both
as
well.
So
there
is
no
differentiation,
but
I
can
tell
looking
right
now
the
results
that
front
end
and
vacuum
maintainers.
Both
groups
voted
mostly
for
three.
Mrs.
D
So
my
my
thought
here
is
there
does
seem
to
be
a
disconnect
related
to
the
uneven
distribution,
which
I
know
that
there's
an
mri
for
from
max
on.
But
if
the,
if
the,
if
it's
comfortable
at
three
a
day-
and
we
don't
see
front-end
hitting
that-
and
we
don't
see
back-end
doing
that
so
excluding
database-
should
this
actually
be
required
guidance.
If
we're
getting
this
complaint
that
we're
overwhelmed,
maybe
it
should
be
required
that
three
is
the
expectation
less
than
that
is
fine.
D
G
It's
hard
to
tell
because,
in
my
opinion
again
it
depends
day
by
day
on
how
big
the
mr
is
so,
maybe
not
three
daily,
but
we
can
have
a
number
for
a
week
or
a
milestone
not
per
day
per
se,
because
again
sometimes
you
have
an
mr
and
you're
viewing
it
for
48
hours
straight.
But
after
this
maybe
you
have
five
marks
a
day
and
they
are
all
one
liners
and
you're
completely
fine
with
this.
So
the
requirement
should
be
for
the
milestone,
maybe
not
for
day.
C
I
just
want
to
know
I
did
share
this
with
the
database.
Maintainer
channel,
not
sure
how
many
people
may
have
voted,
but
I
wanted
to
clarify
is
the
three
per
day.
Is
that
likely
meaning
three
review
requests?
So
these
might
be
mrs
already
in
progress
that
you're
just
getting
re-pinged
on,
or
is
it
three
new,
mrs
per
day,
that
we're
kind
of
talking
about.
E
Yeah,
that's
that's
actually,
let's,
let's
get
clarification
on
that
because,
like
having
three
outstanding
versus
three
per
day,
is
a
completely
different,
well,
a
different
different
order
of
magnitude,
I'm
guessing
at
the
end
of
the
milestone.
F
I
also
kind
of
wonder
if
we
should
be
if
we
should
be
doing
more
differentiation
between
the
types
of
of
maintainership
too,
because
there
aren't
really
one-liner
database.
Merge
requests
right
like
that.
That
doesn't
exist,
there's
a
lot
of
testing
that
goes
into
all
of
those.
So
so
sometimes
sometimes
some
things
are
bigger
than
other
things.
I
guess
I
don't
know.
E
Yeah,
that's
why,
earlier
on
michelle
asked
the
question:
should
we
make
it
required?
I'm?
I
think
we
eventually
get
there,
but
I
don't
know
if
I'm
there
like
what
I
don't
want
to
do
is
put
on
a
requirement
and
then
everybody
feels
like
this
is
unattainable
right.
E
So
it's
almost
like
we
have
to
get
in
there
and
kind
of
get
a
better
feel
for
what's
realistic,
like
we're
getting
survey
information
that
says
that
that's
realistic
from
a
population
but
like
I
still
feel
like
there's
enough
enough
of
a
percentage
of
folks
that
probably
didn't
respond
or
give
feedback
that
I'd
be
I'd,
be
cautious
about
just
immediately
putting
it
in.
Oh,
it's
required,
and
you
know
I
mean
everybody's
like
well.
I
can't
even
I
can't
even
get
to
that
pace
right,
christopher.
H
E
I
Would
would
treating
this
similar
to
like
mr
velocity
at
first
we'd,
like
review
velocity,
where
you
have
a
30-day
window,
and
you
have
you
know
your
average
reviews
and
just
kind
of
getting
getting
data?
That
way.
Would
that
be
helpful.
E
D
David
kim
as
well,
I
don't
think
he's
added
it
to
the
agenda.
It's
pretty
new,
but
david
kim
created
an
issue
for
capacity,
what's
our
review
capacity
so
that
we
can
reduce
our
feature,
work
which
would
decrease
throughput
and
so
maybe
having
this
review
velocity
kind
of
number
to.
B
Trying
to
find
my
mouse,
so
I
can
hit
that
new
button.
I
apologize
cool
so
with
the
I
haven't,
made
up
much
progress
since
the
last
update
here
in
terms
of
the
open
training,
maintainer
issues.
That
said,
I
have
made
the
data
public
and
I
will
be
chiming
into
the
issues
later
today.
Now
that
the
dashboards
and
license
is
set
up,
I
can
see
that
we
can
set
up
some
queries
there
to
be
able
to
filter
between
training,
maintainer
issues
and
how
long
they've
been
open.
B
As
far
as
immediate
action
items,
though
I
am
looking
at
so
we
originally
discussed,
issues
that
have
been
around
for
a
year
should
definitely
be
looked
at
either
being
updated
or
closed.
I've
looked
into
a
little
bit
further.
B
There
are
39
issues
that
haven't
been
updated
in
the
past
six
months,
17
that
haven't
been
updated
in
the
past
year,
I'm
just
thinking
we
just
go
with
the
39
that
haven't
been
updated
in
the
past
six
months,
I'll
ping,
the
signees,
the
training
maintainers,
as
well
as
the
managers
to
see
if
they'd
still
like
to
move
forward
with
that.
B
I
think
it's
called
to
be
able
to
update
training
container
issues
a
little
bit
easier,
but
the
data
is
all
there
if
anyone
would
like
to
poke
around,
but
I'll
definitely
be
looking
to
see
how
we
can
build
that
into
sci-sense.
Now
that
we've
got
a
dashboard
set
up.
D
B
No,
that
would
er
so
yeah
we
not
yet
I'm
gonna
reach
out
to
the
training,
maintainers
and
cc
the
managers
to
see
kind
of,
like
you
know,
is
there
anything
part
of
that
is
like
formulating
that
kind
of
message
in
terms
of
like
is
there
help
we
can
provide,
or
you
know,
to
better
understand
why
they've
been
open
for
so
long
without
you
know,
framing
it
negatively
or
anything
like
that,
just
to
try
to
understand.
H
Okay,
as
far
as
I
had
one
question
dennis
as
part
of
this
effort,
how
we
thought
about
how
to
maintain
this,
like
have
some
type
of
automation
when
an
issue
has
been
open
for
so
many
days
or
so
many
months
that
the
supervisor's
paying
for
the
team
members
paying
just
because
right
now,
it's
great
you
know
you
go
through
it
once,
but
you
don't
want
to
have
to
do
that
manually.
Every
quarter.
B
100-
and
so
I
think,
that's
part
of
the
criteria
for
right-
I
think
improving
efficiency
and
how
we
can
fall
up
on
these.
So
I
don't
think
I
mean
we
have
automation
on
and
set
up
in
this
project
already.
So
I
imagine
it's
just
another
set
of
rules
to
say:
hey
if
you
have
a
training,
maintainer
issue
older
than
x
months,
like
ping,
the
author
and
or
assignee,
and
then
we
can
have
that
going
so
I'll.
Add
that
to
the
I
think,
epic,
four
to
see
if
how
we
can
chase
that
down.
E
B
D
Okay,
are
there
any
other.
D
Dennis
all
right,
moving
on
to
the
help
needed
section,
menage
isn't
on
the
call,
so
I
will
verbalize
for
him.
He
is
requesting
help
for
this
issue
to
add
the
approved
by
username
filter
into
the
api.
This
is
functionality
that
already
exists,
but
he
needs
that
functionality
to
be
added
to
the
api
in
order
to
set
a
maximum
number
of
reviews
at
a
time
for
reviewers
and
maintainers.
D
D
Okay,
so
if
anybody
can
pick
up
that
issue,
I'm
sure
he
would
greatly
appreciate
it.
Otherwise
this
is
part
of
the
code
review
team.
I
think.
C
Sure
yeah-
I
was
just
thinking
about
this
this
morning,
about
how
maintainership
is
somewhat
unique
in
that
it's
something
that's
kind
of
voluntary
currently
and
then
the
engineers
sort
of
democratically
elected
by
their
peers
to
be
a
maintainer,
but
once
they're
a
maintainer
they
just
kind
of
are
a
maintainer
for
as
long
as
they
want
to
be
and
there's
not
really
any
sort
of
re-evaluation.
C
And
I'm
not
saying
I've
seen
any
examples
where
a
maintainer
has
necessarily
let
their
skills
slide.
But
it's
something
that
could
happen
and
it
might
not
be
noticed
until
something
goes
really
wrong.
So
I
was
wondering
if
we
should
consider
some
sort
of
a
periodic
check-in
or
or
something
else,
to
kind
of
ensure
that
maintainers
are
up
to
date.
G
G
This
should
be
disconnected
completely
from
the
career
progression,
then,
because
if
we
make
this
audit
and
say
you're,
not
a
maintainer
anymore,
and
if
we
have
the
requirement,
I
know
we
don't
have
a
requirement
right
now
have
a
recommendation
for
senior
roles.
But
if
we
have
a
requirement,
it
would
be
an
issue.
D
Actually,
I
looked
at
the
job
responsibilities
for
the
at
least
the
senior
back
end
role
last
week,
and
this
is
maintainership
is
listed
on
the
backend
engineer,
job
family,
and
that
was
something
that
I
was
not
completely
aware
of,
and
so
I
wondered
if
the
working
group
was,
but
that
is
on
the
job
responsibilities.
For
a
senior
back-end
engineer,
I
didn't
check
the
others.
B
Should
be
for
front-end
as
well,
I
think
when
we
last
discussed
it,
this
is
a
similar
topic
in
terms
of
like
do
we
make
this
a
requirement
for
the
position
and
so
the
reason
why
it's
mentioned
there,
but
it's
also
saying
like
striving
to
become
a
maintainer,
that
language
is
specific
because
it's
not
required
to
get
into
senior.
But
as
you
move
higher
into
excellence
and
as
a
senior
engineer,
it
becomes
more
of
an
expectation,
it's
a
weird
one
where
it's
like
yeah
right.
B
So
sorry,
it
started
to
become
an
expectation,
that's
like
once,
especially
as
you
move
towards
staff
right,
and
so
naturally
you
progress.
You
know
further
in
the
in
this
year,
competencies.
So
that's
why
it's
worded
the
way
it
is.
It
was
certainly
presented
to
me
as
someone
who
joined
as
a
senior.
A
As
not
something
that
was
critical
immediately,
but
something
that
it
was
almost
expected,
you
know,
as
time
went
on
it
wouldn't
be
considered
under
performance
for
not
doing
it,
but
it
was
certainly
you
know.
This
is
something
that
you
should
aspire
to.
D
E
My
next
okay,
I
just
want
to
make
sure
and
walk
over
steve
yeah.
You
know
like
just
at
a
high
level.
Of
course
you
know.
I'd
definitely
be
supportive
of
this.
The
one
thing
I'm
trying
to
figure
out
is
that
magic
balance,
because
one
thing
that
I
don't
want
to
do
is
like
you
can
put
out
a
policy
that
then
becomes
like
almost
like
a
quota
or
binary
policy
or
security.
There
are
not
meeting
it
and
then
people
start
producing
gaming
behavior
or
what
I'll
call
negative
gaming
behavior.
E
We
want
positive
gaming
behavior
we're
possible,
but
but
what
we're
trying
to
avoid
is
you
know
like
somebody
who
reviews
things
and
they're
they
know
they're
behind.
So
then
they
quickly
rifle
through
a
bunch
of
reviews
and
aren't
actually
giving
it
the
thought
process
that's
needed,
associated
as
an
example.
H
I
was
just
curious
about
when
someone
when
this
scenario
would
occur.
I've
seen
situations
where
people
move,
they
leave
teams
and
they're
no
longer
supporting
that
work
or
the
technology
changes,
but
have
you
seen
this
like?
Is
this
a
rare
scenario?
Right
is
this?
Does
this
happen
often
that
people
are
not
able
to
maintain
their
maintainership
status.
E
What
I've
seen
is
in
other
organizations,
I've
been
I've
seen
in
cases
where
people
become
maintainers
and
then
the
the
pace
that
they
were
at
immediately
drops
as
soon
as
afterwards,
and
then
it
goes
to
some
level
that
is
below
what
expectations
are,
though,
usually
it's
not
it's.
It's
not
necessarily
like
it's
more
of
like
it's
a
consistency,
thing
not
a
you
know,
and
because
expectations
aren't
well
understood,
that's
just
what
happens
right,
particularly
with
open
source
projects.
E
You
see
that
a
lot
where
it's
like
somebody
becomes
a
maintainer
they're,
keeping
up
some
pace
associated
with
that
and
then
that
pace
drops
and
it's
okay.
If
it
drops
to
an
expectation
level
where
people
agree,
that's
the
right
expectations,
but
it's
it's
where
you
know
say:
drop
to
zero
or
you
know
basically
not.
H
E
I
mean
swapping
yeah
so
so
to
that
end,
like
you
know,
there's
general
maintainership.
So
if
we're
just
talking
about
generally
t-shirt
but
like
the
other
thing
is
like,
I
don't
want
this
to
be
that
you
have
to
be
a
maintainer
of
a
specific
area
always
like
it
could
be.
Just
you
have
to
be
a
maintainer
or
some
repo
in
that
is
a
product,
be
kind
of
my
initial
set
of
criteria
for
like
the
job
role
description
as
an
example.
E
So
so,
if
you
move
groups
and
you
become
a
maintainer
of
a
different
area
and
it
happens
to
be
a
different
repo
and
you
drop
from
one
maintainer
ship
and
go
to
the
other
one-
that's
totally
fine.
That
makes
sense.
In
fact,
if
anything
we
want
to
get
catch
that
early,
because
otherwise,
what's
going
to
happen,
is
it's
going
to
look
like?
We
have
maintainers
in
a
certain
area?
We
don't
right.
So
I
think
that's!
E
H
I
think
that's
a
good
idea
because
we
ran
into
problems
with
the
shell
maintainership,
that's
exactly
what
happened.
People
moved
on
and
we
didn't
decrease
the
amount
and
realize
we
didn't
have
enough
enough.
So
I
think
it's
development.
E
Yeah
so,
like
I
think
this
inadvertently,
this
effect
fixes
that
problem,
though
I
think,
like
I
said
you
gotta,
you
gotta,
do
it
like.
Some
people
will
still
wanna
support
that
at
least
for
some
period
times
so,
like
maybe
six
months,
other
people
will
be
like.
No,
I
just
I'm
switching
like
you
know,
instantaneously,
right
and
I'd
like
to
support
both
of
those
models.
D
D
C
I
think
I
can
open
an
issue
to
capture
those
first,
two,
two
aspects
that
you
just
mentioned
and
then
see
if
there's
some
more
discussion
that
needs
to
be
had
and
some
ideas
around
how
we
can
create
such
a
process.
If
we
want
to
move
that
direction,
and
certainly,
as
mentioned
that,
would
be
kind
of
tied
directly
to
the
outcome
of
the
job
requirement
discussion
as
well.
So,
okay,
I'll
open
admission
for
that.
E
And
steve
I'll
be
a
little
bold,
come
back
with
a
proposal,
something
like
you
know,
even
if
it's
the
first
iteration,
we
want
to
do
something
small
to
kind
of
get
this
moving.
Okay,.
D
Okay,
awesome
very
good.
I
think
we
have
five
minutes
left
unless
we
want
to
well.
Unless
we
want
to
be
on
git
lab
leave
time,
and
so
is
there
anything
else
we
want
to
cover
all
right.
E
D
D
B
It's
a
little
late.
I
was
curious
since
we
do
have
like
a
number
of
senior
engineers
on
the
call
like
how
how
do,
but
how
does
everyone
feel
about
like
maintainership
being
kind
of
like
not
immediately
expected
but
expected
later
on
in
in
your
role?
Behavior,
like?
Is
that
fair,
like
I
just
want
to?
B
Basically
I'm
asking
that,
because
I
want
to
establish
a
general
baseline
before
we
start
like
deciding
or
debating
whether
it
should
be
required
or
should
not
at
all,
though
I
I
do
understand
it
to
be,
like
I
think
in
staff
position
plus
like
that
is
an
expectation
because
you
are
specializing
somewhere.
B
A
Is
an
open
core
product
and
being
able
to
function
on
an
open
source
team
as
a
senior
requires
the
ability
to
be
a
maintainer
of
that
project?
You
know
you
wouldn't
be
able
to
see
me
a
member
of
any
other
open
source
projects
without
some
sort
of
mutation
power.
So
I
don't
see
how
we
should
be
any
different.
J
I
think
that
being
a
maintainer
is
a
specific
skill
that
worship
feeling
flag
to
develop
over
time
and
he's
had
this
responsibility.
J
I
think
that
not
every
engineer
feels
as
inclined
as
others
to
perform
maintenance
reviews,
so
I
think
that,
should
that
should
be
taken
into
account
when
once
one
create
a
a
requirement
for
you
to
continue
progressing
with
your
career.
K
Yeah,
I
am
excuse
me,
my
voice
is
a
little
off
today,
but
I
almost
I
feel
like
I
like
it
being
required
for
staff
plus,
but
I
also
think
it's
important
to
note
that
some
folks
may
want
to
just
be
senior
back
in
teachers
and
they're.
L
F
I
think
this
is
the
first
job
I've
ever
had
where
it
wasn't
automatically
assumed
that
senior
engineers
would
be
merging
code,
and
so
I'm
still
like
whenever
someone
is
like
well
senior
engineers,
don't
have
to
I'm
like
a
little
surprised
by
that
yeah
and
it's
the
first
place
where
it's
also
hasn't
been
like
automatic,
oh
you're,
a
senior
engineer:
okay,
maybe
there's
some
onboarding
period,
but
after
that
you're
gonna
have
merged
privileges
to
the
projects
you
work
on.
B
That's
fair
and
I
think,
and
so
I'll
try
to
wrap
it
up,
because
I'm
pretty
sure
we
can
have
a
meeting
about
this
specifically
alone,
but
I
agree
because
I've
been
like
organizations
just
that
as
well.
I
think
that
that's
different
here,
because
it's
it's
open
source
and
you
are
dealing
with
people
contributing
outside
of
just
your
team
but
yeah.
I
think
it's
it's.
B
It's
definitely
a
more
unique
case,
but
I
also
agree
to
previous
points
and
like
yes
like
it,
it's
a
whole
thing
about
career
progression,
because
you
can
be
a
very
good,
reliable,
senior
engineer
and
not
you
know
have
that
responsibility
emerging
code
and
that's,
I
think,
that's
a
perfectly
good
way
to
to
to
work
as
an
engineer,
but
then
yeah
in
terms
of
staff,
plus
it
definitely
becomes
more
of
a
requirement.
There
is
requirement
so
anyways.
I
appreciate
everyone's
thoughts
on
that.
B
In
the
I
think,
it's
epic,
four
or
exit
criteria
for
so
thanks.
H
D
Well
in
terms
of
guidance
and
how
we
really
do
need
to
wrap
it
up,
so
maybe
there
are
two
issues
that
get
merged
into
one,
but
my
understanding
is
natalia
has
potentially
required
guidance
on
how
many
you
should
be
reviewing
and
dennis
has
one
on
potentially
requiring
or
not
requiring
the
senior
responsibility.
Okay,
thank
you.
All
very
much.
We're
at
time
have
a
good
one.