►
From YouTube: 2021-11-18 Governance Committee private meeting
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).
B
C
A
Yeah
yeah
the
same
here,
I
try
not
to
get
the
kids
to
get
here.
Otherwise
it
gets
messy
very
quickly,
but
yeah.
A
A
It's
a
sort
of
infection
looks
like
berlin
is
suffering
from
from.
You
know
it's
beginning
of
of
the
autumn
and
winter
season.
So
you
know
infection
season,
basically
yeah.
A
E
All
right
so
ben
did
we
have
items
in
our
agenda.
D
E
I
think
daniel's
proposal
is
here,
I'd
looked
at
it,
so
we
can
certainly
talk
about
it.
Ben.
I
think
you
had
an
action
item
of
posting,
the
a
post
or
a
either
a
blog
post
or
an
issue
for
the
top
priorities
that
you
know
were
kind
of
prioritized
from
the
discussions
that
we
had
with
the
pc.
D
That
volunteered
to
do
that,
I
I'm
happy
to
also
do
it,
but
I
think
she
had
said
that
she
wanted
to
for
some
reason.
E
E
D
I
I
would
like
that
I
mean
yeah.
She
seemed
to
actually
want
to
do
it,
which
was
puzzling
to
me,
but
I
will,
but
if
she
decides
she
doesn't
want
to
do
it
anymore.
I
don't
want
to
do
it
either,
but
I
will
I'll
put
it
up.
E
E
Yeah,
apparently,
some
some
companies
have
the
whole
week
off
liz.
Do
you
guys
have
a
whole
confidence.
E
All
right
cool,
so
I
guess
daniel
did
you
want
to
bring
up
your
tim.
C
C
I
guess
I'll
just
open
the
documents.
C
Hello,
so
either
I
threw
this
together
based
on
what
we
had
talked
about
in
the
in
the
previous
meeting,
it's
by
no
means
final
or
anything
like
that.
I
am
looking
for
comments
and
then
bogdan
asked
me
to
iterate
on
this,
the
tc
and
gc
together
I
feel
like.
C
F
C
E
F
C
E
C
We
could
do
an
email
or
we
could
do
it
right
in
the
combined
slack
channel.
We
have
would
also
be
fine
yeah.
I
think.
C
Yeah
yeah,
I
agree
most
of
the
comments.
I've
gotten
have
been
rewarding
changes
armin
and
I
think
bogdan
were
a
little
bit
worried
about
how
strong
the
proposal
is
and
how
how
forceful
it
is
in
terms
of
trying
to
get
all
of
the
sigs
to
use
the
same.
C
Policy
bogdan,
if
I
understand
your
concern
correctly,
it's
that
the
the
maintainers
may
not
have
as
much
power
if
there
are
a
couple
of
approvers
that
can
just
approve
and
merge
things
without
them
right.
F
So
the
problem
is:
let's,
let's
understand
what
a
maintainer
role
is.
First
maintainer
has
to
maintain
the
pro
project
correct
so
once
for
me,
the
understanding
is
a
maintainer.
Once
you
merge
a
change,
it
becomes
responsible
to
ensure
that
that
change
will
will
work
in
the
next
years
and
will
maintain
that
code.
It's
not
just
blindly
and
going
in
the
merge
things.
Okay,
so
so
it
comes
with
a
lot
of
commitment
that
merging
something
is
not
just
pressing
a
button.
It's
a
commitment
that
you
are
going
to
maintain
that
code,
that
you
merge
correct.
E
F
F
D
G
Argument
is
by
making
it
easier
to
add
things
to
the
code
base
that
it's
going
to
increase
the
maintenance
burden
even
further,
and
there
won't
be
people
accountable
for
it.
So
I
agree,
and
I
think
the
way
that
we
combat
this
is
to
be
clear,
that
what
maintainers
are
expected
to
support
is
what
is
included
in
the
scope
of
a
release
that
they've
released.
If
they
are
not
happy
with
a
change
having
been
merged,
they
can
revert
it
right
like
they
can
strip
approver
bits
right
like
it
is.
G
It
is
a
discussion
between
the
maintainers
and
approvers
to
provide
guidelines
as
to
what
the
maintainers
trust
the
approvers
to
do,
or
not
right
like
so.
I
think
that,
ultimately,
yes,
the
buck,
stops
here
at
the
maintainer.
The
maintainer
has
the
right
to
decide
this
is
or
isn't
in
the
service
area.
People
should
not
be
using
right,
like
in
general,
people
should
not
be
using
build
cut
from
tip.
People
should
be
using
cut
releases.
F
D
F
Yeah,
I'm
not
saying
the
single
person,
a
group
of
small
people
that
pass
some
some
tests,
so
the
other
problem
is,
you
are
kind
of
upgrading
the
or
promoting
the
approvers,
but
the
rules
for
being
an
approver
were
very
loose
initially
because
we
didn't
think
that
they
will
have
this
power.
They
we
used
to
have
this
power.
G
G
It
stops
someone
from
being
actively
involved
if
they
are
waiting
on
the
on
the
bandwidth
of
a
single
maintainer,
who
is
already
too
overwhelmed
to
mentor
additional
approvers
right
like
if,
if,
if
you
have
that
bottleneck
where
your
changes
are
not
making
in
because
the
proofs
are,
the
maintainers
are
too
overwhelmed,
you
have
enough
approvers
who
are
saying
like
we
think
this
is
good.
This
should
go
in
right,
like
let's
try
to
e.
You
know
make
it
easier
for
people
to
become
maintainers
in
the
long
term.
F
Now,
because
of
this,
in
some
projects
you
make
maintainers
remove
a
blood
of
the
approvers
because
of
trusting
issues
or
of
other
things,
because,
okay,
I'm,
as
I
said
my
two
cents
on
this,
I
don't
think
it's
healthy
to
just
go
and
promote
these
approvers.
For
the
reasons,
as
I
mentioned,
the
the
requirements
for
becoming
an
approver
are
very,
very
loose
like
you
can
become
an
approver
in
two
weeks,
literally
in
any
project
in
hotel.
That
doesn't
mean
that
you're
going
to
be
there
for
maintaining
this
for
three
years
or
five
years.
It's
the.
G
D
F
You
exactly
yes,
that's
pretty
critical
actually,
but
we
tend
we
tend
to
be
very.
We
did
not
tend
to
be
very
careful
on
that.
Let's
do
this
so
can.
D
I
don't
really
want
to
call
it
code
quality,
because
I
don't,
but
there's
a
trade-off
between
the
control
that
maintainers
can
have
over
the
code,
which,
hopefully
will
be
in
the
name
of
quality
and
the
number
of
people
we
have
who
have
the
the
right
to
like
kind
of
move
the
ball
forward,
so
to
speak.
D
At
least
the
tip
is
liz
points
out
right,
there's
a
trade-off
there,
like
the
the
more
we
open
that
up
independent
of
how
the
quality
is
assessed,
of
like
someone
who
becomes
a
maintainer
or
not
there
or
an
approval
over
there's
a
lot
of
there's
a
trade-off
there
and
it
I'm.
D
The
question,
in
my
mind,
is
where
do
we
think
we
are
on
that
trade-off
today
within
hotel
as
a
project
in
terms
of
our
overall
project
health,
because
it
doesn't
make
sense
for
it
to
move
all
the
way
to
either
side
of
the
spectrum?
Obviously,
we
shouldn't
auto,
promote
people
to
being
maintainers,
because
they've
met
the
minimum
criteria
as
assessed
by
pull
requests
or
something
like
that.
D
Nor
does
it
make
sense,
in
my
mind,
to
say
actually
we're
going
to
take
the
best
programmer
in
otel
and
make
them
the
sole
reviewer
of
every
pr
like
those
are
the
two
alternatives
either
in
the
spectrum:
no
one's
proposing
either
one
of
those.
Where
are
we
on
the
spectrum
right
now?
Are
we
too
far
in
one
direction
or
the
other,
and
that
seems
like
the
thing
we
need
to
be
thinking
about
here.
When
we're
having
this
discussion,
I
mean
we've
documented,
I
think,
fairly
clearly
across
end
users.
D
It's
actually
just
talking
to
an
end
user
at
t
today,
and
it's
like
velocity
is
like
a
huge
problem
for
the
project
and
we
heard
the
same
thing
from
from
atlassian
as
a
gc
a
few
months
ago,
and
you
know
whatever
number
of
other
people.
I
just
like
it's
like
the
number
one
problem.
We
have
the
project
and
I
I
just
don't
understand
as
as
a
well,
the
number
of
maintainers
was
assessed
as
the
actual
number
one
problem
from
the
gc,
and
I
just
don't
see
how
we
say
the
current
state
is
the
right
state.
D
Nor
do
I
see
how
we
move
the
the
the
threshold
in
the
other
direction
like
we've
got
to
have
more
maintainers
and
more
velocity
as
a
project,
and
it
is
intentional
with
what
you're
talking
about
for
sure
it
means
less
control,
but
I
I
think
that's
the
right
direction
for
us.
It
doesn't
mean
less
control.
I
want
it
well,
it
does.
F
D
E
E
G
And-
and
I
think
right
like
that's
the
thing
where
like,
if
you
have
wrote,
things
that
are
needing
to
be
approved
on
it,
are
needing
to
be
merged
on
a
regular
basis
like
depend
about
stuff
and
all
of
that
stuff
right
like.
Doesn't
it
make
sense
for
a
trusted
approver
to
be
able
to
help
you
with
that
to
be
able
to
take
that
load
off
your
shoulders
like.
G
Complex
feature
edition
you
do
want
to
be
involved
and
that's
fine
right.
If
you
set
a
guideline
to
your
approver
saying
please
only
like
auto
merge
like
depend
about
things
and
and
small
and
trivial
changes,
don't
auto,
merge
large
features
without
checking
with
me.
I
think
that's
fine,
I
think
that's
up
to
you
as
a
maintainer
to
set
guidelines
with
your
approvers.
F
I
I
don't
think
the
problem
is
dependable.
I
think
the
problem
is
people
are
not
stepping
up
to
fix
their
stuff
in
advance,
so,
except
and
I'm
what
what
does
it
mean
like?
Do
I
need
to
go
again,
you
you,
you
please
and
sorry,
but
you
never
been
a
maintainer
on
this
and
you
don't
know
the
burden
that
all
these
approve.
All
these
just
approving
blindly
puts
on
the
maintenance.
F
E
That's
not
a
fair
statement,
because
at
the
end
of
the
day
you
know
I
work
with
you
closely
on
a
daily
basis.
I
track
the
backlogs
you
know
very
closely
and,
and
you
know
I
have
tried
to
apply
and
bring
in
senior
engineers
wherever
possible.
The
question
is
again,
you
know
stating
clear
expectations:
getting
approvers
to
be
graduating
and
being
able
to
actually
spread
the
load,
and
that's
you
know,
as
a
maintainer,
you
probably
have
to
take
some.
You
know
time
to
make
sure
that
happens.
Right.
G
G
I
genuinely
don't
know
what
the
threshold
is,
but,
like
you
know,
I
think
that
if
something
is
right
like
would
you
trust
an
approver
to
in
general,
like
you
know,
review
a
ten-lined
full
request
without
you
needing
to
look
at
it.
F
E
That
is
your
deep
understanding.
Since
you
wrote
some
of
the
most
of
this
code,
everybody
else
actually
has
to
step
up
to
that
understanding
right
and
there
is
some
give
and
take
there.
If
you
don't
give
them
the
opportunity
to
be
take
ownership
for
some
of
these
areas,
you
don't
have
to
tell
them.
They
know
everything,
but
let
me.
G
Think
that's!
The
challenge
is
that
if
the
approvers
are
not
looking
at
it,
because
you
are
personally
merging
everything
right,
they're
just
going
to
sit
there
and
wait
for
you
to
do
it
and
they're
because
them
saying
yes
or
not
or
reviewing,
it
doesn't
make
a
difference
right
yeah.
It
makes
it
makes
a.
F
Difference
it
makes
a
total
difference
as
long
as
I
see
that
they
identify
things
so
so
by
going
and
just
approving
things,
because
anyway,
I'm
not
gonna
enter
to
details.
Why?
But
if
you
see
people
how
easy
they
approve
things,
you
will
be
on
the
same
page
with
me.
So
I've
seen
I've
seen
people
that
are
approving
any
pr
every
pr.
Without
any
comment
they
had.
They
have
probably
10
times
more
approvals
than
comments.
C
C
Maybe
you
need
it
a
different
level
in
between
approver
and
maintainer,
which
is
like
an
approval
with
merge
rights,
because
the
maintainer
determines
like
project
direction
and
that's
we
don't
want
the
approvers
to
take
that
away
from
the
maintainer,
because
I
feel
like
that's
important,
important,
to
keep
that
to
a
small
number
of
people
who
generally
agree,
but
the
that
doesn't
mean
that
that
group
of
people
needs
to
be
merging
every
pr.
It
just
means
that
they
need
to
determine
the
project
direction.
D
That's
a
slight
tweak
on
that.
Would
it
be
possible?
I
mean
this
is
an
actual.
Unlike
my
last
question
is
not
rhetorical,
so
a
real
question
for
you
this
time
bogdan.
So
I
mean,
if
you,
if
you
could
hand,
pick
I'm
not
asking
you
to
name
names,
someone
to
become
a
maintainer
with
the
understanding
that
they're,
probably
not
going
to
be
like
just
based
on
your
tenure
in
the
project.
D
I
think
it's
pretty
much
de
facto
the
case
that
you
would
be
more
likely
to
set
technical
direction
like
is
it
possible
to
have
someone
be
a
maintainer
but
not
officially
create
like
a
new
tier
in
our
structure
and
just
have
sort
of
just
let
the
natural
experience
levels
dictate.
You
know
who's,
doing,
project
direction,
who's
handling,
more
tactical
things,
or
something
like
that.
I'm
just
trying
to
avoid
like
creating
additional
structure
like
is.
E
Like
modern
areas
of
specialization
right
like
releases
or
you
know,
specific
components
that
that
are
that
are
owned
by
you
know
different
maintainers,
and
then
you
know,
like
you,
lead
the
project
direction
on
the
collector.
So
I
mean
again
it's
I
think
that
that
could
be
called
out
very
easily
and
within
the
maintainers
too,.
F
So
so
to
answer
first
question
ben:
I
think
it's
possible
and
whenever
I
see
people
being
reasonable
on
that,
I
I
I
take
a
step
and
empower
them
from
the
beginning.
F
I
can
give
you
clear
examples:
alex
is
one
of
my
favorite
that
I
work
with,
for
example,
on
the
other
side,
when
I
see
a
lot
of
time
and
stuff
jurassic,
for
example,
is
another
example
where
he
became
a
maintainer
and
jurassic.
Did
I
work
with
you
to
explain
things
like
in
the
client
and
stuff,
and
we
worked
one
hour
together
to
to
to
help
with
this.
F
So
I
don't
know,
I
I'm
seeing
a
lot
of
progress
in
that
area
and
I'm
seeing
that
there
is
a
definitely
a
case
where,
where
I'm
adding
new
people
and
and
they
they
are
more
newer
into
the
project,
but
they
they
will
grow.
Definitely.
A
Yeah,
I
think
we
have,
I
think
one
exchange
that
we
take
we
can
take
today
is
clearly
define
what
is
expected
of
maintainers.
You
know,
is
it
only
about
merging
things
or
is
it
about
also
mentoring,
other
folks,
like
approvers
and
so
on,
and
perhaps
one
thing
that
we
can
do
better?
Is
you
know,
separate
issues
that
we
don't
have
to
work
ourselves
and
and
ask
people
you
know
either
directly
or
in
a
specific
channel
or
by
labeling
those
issues
and
then
making
a
report
by
the
end
of
the
week?
A
A
So
because
you
know
there
are
quite
a
lot
of
people
being
in
me
and
I
assume
them
as
well,
and
I
assume
it
is
also
for
others,
sub
projects
for
people
willing
to
come
to
the
community
and
and
collaborate
and
help
either
by
reviewing
by
writing
code.
Or
you
know
things
like
that.
I
ask
people
to
review
aprs.
So
if
you
see
approval
approvals
from
people
who
are
not
approvers,
you
know
that's
possibly
one
of
the
people
that
I
ask
to
review
prs.
A
E
A
That's
true,
that's
true,
but
I
think
yeah
going
back.
Then
one
point
is
that
you
know
if
we,
if
we
define
clearly
what
is
expected
of
maintainers
and
what
is
expected
of
approvers,
then
I
would
be
fine
in
having
you
know
like
two
main
two
approvers
approving
apr
and
then
I'm
manually
going
there
and
merge
things
if
I
trust
the
approvers
right.
So
I
think
I've
seen
cases
that
you
know
that
some
cases
where
that
bogdan
mentioned
you
know
people
not
really
caring
that
much
about
approving.
A
So
if
I
see
those
prs
I
would
as
a
maintainer,
I
would
go
in
and
review
the
pr
myself
as
well
in
addition
to
the
two
approvals.
So
perhaps
the
two
approvals
don't
have
to
be
like
a
a
a
rule
that
has
been
forced
but
more
like
a
recommendation.
So
if
you
see
two
approvals
from
from
people,
you
trust
and
you
you
can
blindly
merge.
Otherwise
you
know
do
a
review
yourself.
F
But
one
one
thing
I
wanna
say:
are
we
gonna
have
a
tool
to
enforce
this,
or
are
we
gonna
just.
G
That's
kind
of
the
question
is:
if
we
manage
to
adopt
a
standard
across
all
of
hotel,
it
makes
sense
to
make
to
have
our
tooling
enforce
this
in
a
similar
way
that
kubernetes
handles
like
having
a
bot
auto
merge.
If
the
person
with
the
right
bits
says
exclamation
mark
merge
right
like,
but
if
there
is
not
consensus
among
the
hotel
sigs,
then
we
can't
really
invest
in
the
in
the
effort
to
do
this.
Tooling.
F
Yeah
one
one
of
the
big
problem
with
the
truman
to
approvals
is,
you
know,
for
example,
all
my
reviews,
even
though
I'm
not
an
approver
in
a
project
would
be
marked
as
green,
because,
whatever
stupid
github
does
that
and
probably
for
you
as
well
as
gc
members,
I
think
you
are
in
a
group
that
have
access
to
the
org,
so
any
approver
coming
from
us
will
be
marked
as
green.
Even
though
we
don't,
we
are
not
approver
and
we
may
be
confusing.
F
Could
be
only
for
tc
whatever,
but
but
I
don't
want
those
to
be
considered,
for
example,
as
a
prover.
If
I'm
not
an
approver,
because,
for
example,
I'm
looking
at
goal
changes
for
metrics
and
stuff,
because
I
want
to
use
that
library-
and
I
may
approve
some
some
of
the
bits
there
and
my
approver
seems
green,
and
I
don't
want
that
to
be
counted
because
I'm
not
an
approver
in
that
project.
C
Somebody,
I
think
it
was
lolita,
said
something
about.
Oh,
can
you
promote
a
maintainer
who
doesn't
really
have
you
know
direction
project
direction,
you
know,
could
you
do
the
opposite?
I
maybe
we
don't
introduce
a
new
role,
but
we
just
individually
talk
to
certain
approvers
and
say
say:
hey.