►
From YouTube: 2021-11-11 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
B
That's
true,
but
I'm
almost
always
here
liz
I
mean.
Is
that
isn't?
Is
that
not
true
or
something?
I
was
in
my
office
for
like
two
weeks
while
my
home
was
being
destroyed
temporarily,
but
I
think
I've
been
here
most
time.
Maybe
it's
because,
oh
you
know
what
it
is
is
that
I
upgraded
my
laptop
and
now
my
like
camera
isn't
like
zoomed
in
like
this,
because
it
keeps
on
resetting
itself.
So
you
can
see
more
of
my
office.
Is
that
is
that
possibly
the
case.
B
It's
just
zoomed
out
look
at
experience
the
difference.
It's
amazing.
I
also
upgraded
slack
as
part
of
this
and
now
like
it
used
to
be
that
if
you
had
do
not
disturb
on
on
a
mac,
slack
was
quiet
and
now
it's
not,
which
is
driving
me
a
little
bit
insane.
Maybe
someone
this
is
like
hard
computer
science
problems.
B
That's
true:
both
distance
are
true.
I
honestly
liz.
I
think
we
should
wait
until
five
past
the
hour,
since
we
have
the
whole
hour
percentage-wise.
We
still
have
a
little
bit
of
time.
I
don't
know
it
would
be
great
if
there's
a
little
bit
more
representation
from
the
folks
who
said
they
would
show
up
anyway,
there's
some
actually.
I
seem
to
have
most
we're
missing
alolita,
another
bunch
of
people
who
haven't
responded,
one
way
or
the
other.
B
Well,
the
regular
call
was
deleted,
so
I
doubt
it
josh
surat
should
be
here
as
well.
B
I
don't
know,
maybe
we
should
start
bypassed,
let's
see
so
there
are
two
things
we
wanted
to
talk
about.
I
think
one
of
them
had
to
do
with
creating
a
contributor
ladder,
the
problem,
the
overall
problem
being
like
a
lack
of
maintainers
in
hotel
and
a
huge
number
of
contributors
and
one
oh
and
some
other
things
too.
I
think
it
would
help
us
with
it
could
help
us
with
diversity
and
a
number
of
other
things.
So
the
idea
of.
B
Josh
mcdonald,
this
meeting's
being
recorded,
so
you
don't
really
have
to
take
notes
if
you
don't
want
to,
but
I
think
the
idea
was
to
talk
about
creating
a
contributor
ladder
like
other
projects
have
and
then,
if
we
have
time
after
doing
that,
I
wouldn't
mind
talking
about
road
map
stuff,
as
it's
kind
of
a
joint
gctc
thing
and
and
one
of
the
main
issues
that
I
think
the
dc
identified
with
the
project.
B
Overall,
when
we
talked
about
you
know
problems
that
we
have
a
couple
of
weeks
ago,
I
actually
don't
recall
who,
on
the
gc,
brought
up
the
contributor
ladder
thing
off
top
of
my
head.
Does
anyone
remember
that?
B
F
Yeah
sure
it
was
something
that
the
cncf
suggested
we
do
as
like
a
next
step
of
project
maturity.
I
guess
they
strongly
recommend
that
you
have
not
just
well-defined
roles
which
we
have,
but
a
well-defined
and
measurable
process
to
attain
the
next
goal
so
that
when
people
say
I'm
a
community
member,
how
do
I
become
a
contributor
there's
somewhere?
There's
a
like
a
concrete
list
of
things.
F
Here
are
the
things
you
can
do
to
be
elevated
to
the
next
level,
all
the
way
up
to
sort
of
maintainer
which
at
this
point
we
do
have
a
defined
process.
For
that
like
we
in
order
to
become
a
maintainer,
you
must
be
approved
by
the
tc,
but
that
doesn't
say
anything
about
how
do
I
apply
for
that?
How
do
I
know
if
I
am
close
to
that
or
if
the
tc
will
or
will
not
approve
me?
F
What
metrics
will
they
use
to
evaluate
me,
and
things
like
that
that
particular
one
is
important
to
me
right
now,
because
some
of
you
most
of
you
know
that
js
is
actually
losing
a
maintainer,
which
means
right
now
we
only
have
the
two
maintainers
and
a
very
small
handful
of
regular
contributors,
so
we've
been
seeing
sort
of
a
lack
of
steam
so
to
have
that
process
in
place
be
helpful
for
us
in
the
short
term,.
D
Daniel,
how
many
of
the
folks
who
are
approver
right,
like
I
know
you
mentioned,
there's
a
maintainer
shortage.
What
about
the
number
of
approvers?
Do
we
need
to
advance
people
to
approve
her
first
or
is
it
the
lack
of
process
for
going
from
approver
to
maintainer.
F
I
think
to
approve
her
also
like
there's
no
there's
nowhere
where
somebody
who's,
not
an
approver,
can
go
and
see.
These
are
the
like.
The
the
metrics
that
I
need
to
attain
in
order
to
become
an
approver,
and
I
see
I
think,
being
an
approver
is
a
prerequisite
to
being
a
maintainer.
Certainly.
D
Yeah
I
agree.
The
good
news
is
that
we
don't
necessarily
have
to
resolve
this
at
the
tc
level
to
talk,
because
individual
maintainers
can
decide
who
they
want
to
have
as
approvers
helping
them.
But
certainly
it
would
be
helpful
to
have
guidelines
project
wide,
even
if
they're
not
firm,
rules
enforced
by
the
tc.
F
Yeah
and
as
a
maintainer,
knowing
you
know,
it's
not
just
somebody
who's
trying
to
become
an
approver
that
doesn't
know
how
they
become
an
approver
myself
as
a
maintainer.
I'm
never
really
sure.
When
I,
you
know,
add
someone
as
an
approver.
I
want
to
make
sure
that
I'm
not
being
arbitrary,
just
based
on
like
who
shows
up
with
the
calls
more
often
or
you
know,
people
that
I
have
met
and
things
like
that.
F
E
We
might
want
to
to
change
them,
but
I
wonder
if,
if
the
problem
is,
is
less
requirements
and
more
just
not
having
a
process
like
right?
Now,
it's
just
sort
of
on
maintainers
to
just
kind
of
go
and
do
it.
We
don't
have
a
way
of
reminding
maintainers
or
periodically
reminding
community
members
that
that
they
can
apply
for
these
roles
or
a
review
process,
or
anything
like
that.
That
would
kind
of
make
it
structured.
G
I
can,
I
can
definitely
say
that
you
know
again,
there
is
no
process
right.
It's
quite
looks
quite
arbitrary
today
and
you
know
a
lot
of
engineers
who
have
contributed
to
the
project.
The
same
thing
I
at
least
hear
is
that
you
know
what
what
is
the
process
right
and
is
there
an?
Is
there
a
tie
again
now,
at
least
there
is
some
more
detail
that
you
know
you
have
to
contribute
and
interact
with
issues
for
at
least
one
month.
G
Some
of
this
will
help,
but
still,
how
do
you
actually
get
involved,
and
you
know
who
do
you
contact?
How
do
you
get
to
the
next
level.
H
Okay,
here
sorry,
I
just
wanna,
I
think
we've
been
acting
reactively
as
a
community
in
a
lot
of
ways.
In
a
lot
of
things,
we've
set
up
like
the
the
the
we've
set
up
a
process.
That
is
reactive
and
I
think
what
we're
learning
now
is.
We
need
to
be
proactive
in
certain
areas,
and
this
is
a
specific
one,
the
roadmap's
the
other
one
where
I
think
we
actually
need
to
plan
say
every
end.
You
know
weeks
we
go
reach
out
to
maintainers
and
say:
hey
how's,
your
approver
list.
H
Looking
are
there
people
you
can
promote
and
just
ask
the
question
proactively
again:
we're
very
reactive,
because
everybody's
busy,
we're,
like
you,
know
in
the
middle
of
the
10
000
things,
and
so,
unless
we
start
becoming
proactive
and
put
time
in
our
calendar
to
like
do
these
things,
we're
not
going
to
do
them.
So
I
really
think
it's
more
about
proactive
scheduling
here.
I
Yeah,
going
back
to
one
thing
that
dad
mentioned
is
that
we
do
have
those
requirements,
but
in
my
experience
those
requirements
are
too
abstract
to
be
useful.
You
know
in
the
day-to-day
I
basically
link
here
to
the
a
similar
dock
that
we
have
for
jager
and
in
there
it
is
very
concrete
right,
so
we
say
that
you
know
to
become
a
maintainer.
You
have
to
participate
in
discussions
contributions,
code,
reviews
for
three
months
or
more
perform
code
reviews
for
10
non-trivial
poll
requests.
I
I
mean
they
are
still
subjective
in
a
way
that
you
know
how
do
you
define
what
is
not
trivial?
What
is
the
boundary,
but
it's
still
concrete
enough
for
people
to
have
an
idea
or
a
feeling
on
where
they
are
in
this
letter.
G
Yeah
for
sure,
because
there
is
no,
I
mean
that's
one
thing
that
you
know
I've
asked
for
a
while
is
that
where
what's
the
timeline
right
like
again,
resources,
scarce
and
engineers
are
always
in
high
demand
across
different
projects?
G
G
F
See
on
this
jager
document
that
we
don't
have
so
I'm
looking
at
the
community
guidelines
we
have
and
our
requirements
are
actually
fairly
similar
to
be
like
you
know,
we
have
a
prover
and
maintainer.
It
looks
like
jaeger.
Only
has
one
level
almost
a
misunderstanding,
but
we
do
have
author
of
at
least
10
substantial
prs
nominated
by
maintainer
reviewer
for
at
least
one
month
like
those
are
definitely
concrete,
measurable.
F
But
what
I
see
on
the
jager
that
we
don't
have
is
actually
how
do
I
say:
I've
met
these
requirements,
so
what
they
have
is
must
be
proposed
by
an
existing
maintainer
by
sending
a
message
to
this
email
address
with
the
following
information:
if
no
one
objects
in
five
days,
the
nomination
is
accepted
like
that
is
extremely
clear.
How
do
I
become
a
maintainer
if
I
fulfill
these
requirements,
and
I
can
get
a
maintainer
to
nominate
me
with
this
divine
process,
then
I
become
a
maintainer
with
ours.
F
I
think
it's
very
likely
that
we
have
people
that
have
met
these
approver
requirements
that
just
don't
know
that
they're
supposed
to
reach
out
to
a
maintainer
or
the
maintainers.
Don't
know
that
they're
supposed
to
nominate
people
and
things
like
that,
it's
just
the.
How
do
I
take
the
actual
step
that
we're
missing.
D
I
did
want
to
raise
one
additional
thing
with
regard
to
our
process
for
becoming
an
approver,
which
is
that
in
the
past,
as
one
of
the
hotel
go
up,
reverse
like
my
experience,
was
that
once
we
instituted
the
requirement
that,
like
the
maintainer,
has
to
be
the
one
who
actually
presses
the
merge
button,
that
approvers
cannot
press
the
merge
button
and
then
have
their
actions
later
reviewed
by
the
maintainer
asynchronously.
D
It
felt,
like
my
approval,
wasn't
actually
like
doing
anything
useful
right
like
the
maintainer
is
going
to
have
to
look
at
it
anyways.
So
I'm
kind
of
wondering
whether
part
of
the
bottleneck
in
terms
of
getting
people
motivated
to
become
improvers
is
to
actually
give
them
a
sense
of
like
you
know.
This
is
velocity.
This
is
moving
the
project
forward.
G
Definitely
also
the
other
issue.
There
is
that
we
have
approvers
on
approver
lists
who
actually
are
not
active
so
again,
maybe
an
activity.
You
know,
update
of
some
sort
needs
to
be
also
looked
at
by
different.
G
G
Yeah
and
and
that's
been
the
case
quite
a
lot
because
you
know
approvers
get
auto
assigned
right
and-
and
there
are
often
many
many
issues
or
pr's
which
just
sit
because
there
is
no.
You
know
we
have
to
ping
folks
constantly.
H
There's
also
an
issue
between
maintainer
approver
relationships
that
it's
different
by
community,
like
like
the
experience
in
go,
might
be
different.
I've
seen
different,
very
different
experiences
between
java
c
plus
go
and
the
collector
for
sure
yeah.
So
I
I
think
we
it
there's
a
question
of
how
much
stability
do
we
want
here
between
them
and
like
what
can
we
do
to
make
that
the
same
but
like
in
the
end?
There's
a
bit
of
this.
That's
like
people
relationships
too.
H
If
a
maintainer
isn't
is
going
in
and
re-reviewing
approver
code,
we
should
dive
into
that.
That's
a
people
issue
right.
E
Yeah,
can
I
suggest
we
we
move
to
some
concrete
actions
here
and
like
possibly
move
on
to
other
issues.
It
seems
like
we
have
like
a
clear,
concrete
action
is
set
a
cadence
for
reminding
maintainers
to
talk
to
their
community,
about
saying,
hey,
we're
looking
for
these
roles
and
if
you're
interested
tell
me
and
to
then
review
those
roles
and
reach
out
actively
to
people
and
ask
them
if
they
would
like
to
become
approvers
and
maintainers,
so
that
there's
like
once
a
month,
there's
an
actual
active,
active,
proactive
motion
on
this.
J
E
K
Do
it
because
it
works
right
that
would
been
would
be
helped
if
we
had
some
sort
of
like
a
script
which
can
give
you
stats
once
a
month,
because
otherwise,
it's
still
very
subjective
and
like
the
jaeger
process
that
daniel
was
talking
about
it's
it
is,
I
don't
actually
recall
anyone
ever
volunteering
to
become
a
maintainer,
even
though
that
process
exists.
So
it
was
always
like
us
proactively
asking.
K
Would
you
like
to
right
and
so
doing
that
requires
sort
of
already
collecting
some
stats,
which
is
like,
especially
in
the
larger
project
like
hotel?
It's
it's
a
lot
of
work
for
maintainers
like
doing
it
every
month.
I
feel
like
if
we
had
some
minimal
automation
and-
and
that
would
also
take
care
of
stale
approvers
or
other
roles
like
if
your
stats
showing
that,
like
clearly
that
you
dropped,
then
they
can
reach
out
and
ask
like.
Would
you
like
to
remain
or.
B
Another
question
about
the
the
the
active
approvers
thing.
I
definitely
agree
that,
in
terms
of
assessing
the
health
of
any
particular
part
of
the
project
like
we
would
want
to
know
how
many
active
approvers
there
are,
but
if
we're
having
a
maintainer
shortage,
automating
the
removal
of
maintainers
who
are
qualified
in
the
sense
that
they
understand
how
the
project
works
and
know
what
the
coding
style
is
and
so
on
and
so
forth.
Removing.
B
Seem
necessarily
all
that
helpful
like
would
we
is
there
a
problem
like
you
know,
liz
not
to
to
pick
you
up,
but
since
you
volunteered
yourself
like,
would
it
maybe
make
sense
for
there
to
be
a
place
for
people
who
have
been
like
vetted
like?
I
would
certainly
trust
you
liz
like
do
a
code
review
if
you
had
time
for
it
or
something
like
that,
it
just
that
you
have
a
lot
of.
D
B
D
B
Yeah
yeah,
I
guess
I
meant
just
in
terms
of
well
yeah.
Okay,
totally,
fair
point,
I
my
point
is
just
that,
like
in
terms
of
the
problem
we're
trying
to
solve
as
a
project
there's
both
development
of
the
contributors,
payroll
alolita
was
saying
it's
like
without
a
path
to
development,
there's
very
little
incentive
to
staff
the
project
and
then
also
that
we
that
we
lack
bandwidth
like
in
the
maintainer
population
and
like
well
really
just
at
the
upper
side
of
the
upper
rungs
of
the
ladder.
B
So
anything
we're
doing
to
remove
people
who
haven't.
I
who
haven't
like
done
something
bad.
They
just
maybe
haven't
been
participating
that
much.
I'm
not
sure
if
we
should
be
pursuing
that.
If
that
makes
sense,.
D
K
Yeah
I
agree
like
I
think
it
is
a
problem
to
have
stale
basically
roles,
people
in
the
stale
roles,
because
then
let's
say
someone
opens
the
pr
and
they
tag
like
approvers,
but
none
of
the
approvers
actually
are
available,
and
so
what
happens?
Then
it's
exactly
a
bad
experience.
E
G
Yep
yeah
I
mean,
and
then
you
know
one
of
the
things
to
consider.
Given
I've
been
working
with
the
collector
a
lot
and
is
that
the
collector
is
a
confederation
of
components
right
and
today
we
have
a
very
pyramid
scheme
of
you
know
and,
and
it
thins
down
very
quickly
on
top,
so
it
is
literally,
you
know,
takes.
J
At
vendors,
who
are
like
paid
to
do
open
summit
tree
and
are
shuffling
their
priorities,
and
we
have
contributors
who
work
for
large
companies
who
have
an
observability
engineer.
That's
like
trying
to
get
his
thing
to
work
using
the
new
stuff
and
they
they're
like
very
motivated
and
there.
Some
of
those
approvers
will
come
in
and
get
to
be,
approvers
simply
to
help
push
the
project
forward
to
make
to
further
their
own
ends.
But
they're
not
going
to
be
interested
in
reviewing
and
approving
everything.
They're,
not
expert
in
everything.
J
They
just
have
this
narrow
interest,
and
so
those
approvers
tend
to
like
come
and
go
and
only
be
qualified
in
one
area
of
the
code
for
the
same
for
like
but
for
different
reasons
than
a
leto.
Just
said
it's
not
because
we
have
a
huge
confederation
of
components.
It's
because
he
only
cares
about
metrics,
which
is
in
a
sense
a
different
component.
So
having
more
more
approvers
with
narrower
responsibilities
might
also
help.
G
Yeah
yeah,
absolutely
I
mean
that
was
exactly
what
I
was
also
pointing
to
that.
It's
a
you
know
an
assortment
of
different
types
of
components
right
and
and
and
really
having
ownership
on,
perhaps
a
maintainership
on
a
component
level.
We've
had
these
discussions
before,
but
you
know
being
able
to
narrow
that
down
and
have
clear
responsibilities
might
be
useful,
focused
responsibilities.
D
Yeah,
certainly
that
is
the
direction
that,
for
instance,
kubernetes
has
gone,
but
we
thought
earlier
that
we
weren't
at
that
level
of
complexity.
Now
now
is
the
time
to
kind
of
revisit
that
yeah.
D
I
know
that
the
first
place
we
bumped
into
this
was
kind
of
the
tc
and
kind
of
sub
tc
for
like
metrics
and
so
metrics
and
logs,
where
it
became
necessary
to
delegate
spec
access.
But
now
we
should
think
about
that
for
sigs
as
well.
B
Hey,
I
have
a
question:
that's
relevant
to
all
this
stuff,
just
kind
of
a
gut
check,
mostly
for
the
tc,
I'm
not
suggesting.
We
do
this
to
be
clear.
So
it's
sort
of
a
hypothetical
question
but
there's
a
question
behind
the
question
so.
G
B
We
were
to
just
go
through
the
project
and
say
to
all
of
the
maintainers
go
and
just
pick
the
people
that
seem
like
they're,
fantastic
that
are
actually
contributing,
and
I
don't
know
up
level
them
in
the
latter.
Like
again,
I
know
that
we
need
a
real
process
with
real
criteria
and
stuff
like
that.
B
If
we
made
that
if
we
made
those
choices-
and
they
were
mostly
correct,
like
would
things
be
a
lot
better,
like
I
mean
I'm
just
trying
to
figure
out
like
are
we
kind
of
stuck
by
are
we
are
we?
Is
there
a
bottleneck
here
around
our
approval
criteria?
Like
do
we
think
we
have
great
people,
but
they
just
haven't
met
the
thresholds,
or
are
we
just
lacking
the
right
people
and
contributing
to
the
project?
No.
F
It
depends
yeah,
I'm
really
sick
to
sing,
because
I
know
php,
for
instance,
is
just
lacking
the
people
yeah
and
I
can
say,
njs.
We
are
lacking
the
people
we
have.
We
have
three
people,
including
the
two
maintainers
that
are
very
actively
contributing
right
now
and
that
third
person
we
were
actually
talking
about
having
him
promoted
to
be
a
maintainer.
So
like
we're,
the
only
people
active
on
it
and
oh
there
are
no
people
that
I
would
promote
because
they're
not
there.
D
Yeah,
we
definitely
need
to
be
able
to
highlight
which
areas
of
the
project
need
the
most
help
and
also
like
we
can
reach
out
to
people
who
are
actively
using
the
project
and
ask
whether
they'd
like
to
pitch
in
or
whether
they
have
things
that
they
would
like
to
do
right
that
we
could
help
help
them
with
those
kind
of
you
know
hey
if
one
of
the
requires
for
requiring
approval
is
submitting
significant
pull
requests
like
let's
talk
to
them
about
what
their
ideas
are,
what
they
feel
motivated
to
work
on
yeah.
E
I
wonder
if
other
open
source
projects
are
there
techniques
for
encouraging
participation
like,
for
example,
one
thing
I
did
long
ago
with
open
tracing
was
we
needed
documentation,
so
I
announced
like
a
docu-thon
like
we're
going
to
like,
like
do
like
a
week
like
hackathon
to
like
get
the
docs
in
order
and
that
actually
caused
some
some
extra
people
to
show
up
who
were
just
kind
of
watching
the
project.
We're
like
you
know,
hey
I'll,
take
part
in
that.
E
H
An
area
in
the
project
where
casual
contribution
is
totally
fine
and
welcome
and
that's
that's
beautiful
and
we
should
make
sure
the
cost
for
casual
contributions
is
very,
very
low,
because
these
are
people
who
come
use.
Their
phone
free
time
want
to
contribute
some
things.
There
should
be
a
very
low
cost
of
overhead.
We
we
accept
those
things
in
quickly.
That's
not
every
project
like
you,
don't
want.
H
Contributor
change,
like
the
core
implementation
of
say
how
we
do
metric
aggregation
or
like
trace
sampling
or
something
right.
That
is
a
highly
sophisticated
topic
that
we
need.
Experts
on
that.
You
need
a
bit
more
trust
and
more
thought
through
and
that
that
needs
more
friction
naturally.
So
I
just
want
to
make
sure
we're
calling
out
when
we're
thinking
about
this,
if
we're
looking
to
get
maintainers
we're
actually
looking
for
the
latter,
not
performer,
so
I
I
think
I
I
just
want
to
build
that
competency.
E
Yeah,
I
think
I
want
to
just
clarify
right
now.
The
the
main
path
in
to
open
telemetry
contribution
is
someone
is
getting
paid
by
an
organization
to
to
work
on
it,
and
if
we
want
other
people
to
come
in
like
does,
there
have
to
be
a
more
active
path
to
like
casually
contribute
or
otherwise
like
get
used
to
the
community
and
then
like,
like
how.
E
D
Is
why
I'm
frustrated
in
a
lot
of
ways
that
we
turned
off
contributions
of
additional
of
additional
contrib
integrations,
because
to
me
that
is
a
really
great
way
for
people
to
get
oriented
in
our
project
and
our
ways
of
working.
That
is
less
core
and
therefore
that's
how
we
can
bring
people
in
right
like
to
me.
There
kind
of
has
to
be
a
carrot.
D
B
I'm
not
sure
it's
liz
about
the
contrib
thing,
though
I
mean,
if
I
recall
the
reason
why
we
wanted
to
push
from
the
contrib
stuff
out
of
the
project
was
ironically,
because
it
you
know,
especially
in
the
in
the
when
you
think
about
the
end
game
for
all
this
stuff,
it's
just
such
a
large
footprint
and
that
we
don't
want
to
be
responsible
for
maintaining
that
footprint.
I
mean,
I
think,
if
it
was
very
clear
that
contrib
is
like
it's,
it's
just
the
wild
west
and
you
know,
don't
assume
anything
about
code
quality.
D
B
If
I
imagine
approaching
the
project,
you
know,
without
any
context,
it
doesn't
seem
like
something
where
you
could
jump
in
and
feel
like
a
lot
of
velocity
right
like
it
seems
like
a
very
high
friction
thing
to
make
changes
just
due
to
the
nature
of
the
dependency
tree
and
stuff
like
that,
if
nothing
else.
E
So
this
is
actually
a
thing.
I
should
point
out:
there's
still
lift
to
be
done
here,
but
we're
working
on
this
with
the
instrumentation
sig,
which
is
part
part
of
why,
like
the
the
trib
stuff
is
uneven,
is
like
our
our
guidance
on
like
what
counts,
as
like
good
instrumentation,
for
example,
is
is
not
there,
and
part
of
my
hope
is
if
we
can
get
that
guidance
there,
that
it's
much
easier
for
for
people
to
co-maintain
these
various
repositories.
Someone
comes
in,
and
it's
not
being
maintained
or
they're,
not
happy
with
it.
E
G
But
I
think
that
that
fundamentally-
and
this
is,
I
think
something
that
we
all
allude
to
is
that
there
is
an
you
know
rightfully.
So
there
is
an
fundamental.
You
know,
hesitation
towards
maintaining
you
know,
er
a
friction
I
should
say
between
maintaining
quality
of
the
code.
That
is,
you
know.
Hotel
is
signing
off
on
as
core
components
versus
even
vendor
components,
or
you
know,
vendor
integrations
if
you
will
versus
plug-ins.
E
I
I
guess
I
think
maybe
one
of
my
points
is
it's
not
it's
actually
totally
insufficient
to
just
say
we're
not
going
to
maintain
all
this
contrib
stuff,
because
end
users
actually
need
all
that
stuff
to
work.
If
they
have
an
integration
like
they
are
forced
to
use,
whatever
integration
is
being
provided,
whether
it's
open
telemetry
or
some
third-party
thing
in
the
registry.
So
I
like,
like
providing
enough
guidance
and
enough
tooling
that
it's
like
possible
to
maintain
quality
on
those
components
is
is
like.
E
E
They
aren't
core
maintainers,
and
this
is
a
place
where,
where
they're
getting
to
have
input
and
and
work
on
stuff,
and
if
we
have
some
more
people
who
help
up
with
that,
we
can
build
like
tooling,
and
you
know,
test
infrastructure
and,
like
other
things,
that
make
it
easier
to
to
maintain
this
stuff
and
and
that
stuff's
also
kind
of
exciting
for
people
to
write.
So
I
I
think
I
guess
what
I'm
saying.
D
Is
I
think
yeah
can?
Can
we
include
people
who
are
active
in
sick
instrumentation
and
doing
work
outside
the
core
open
telemetry
repos?
Can
we
somehow
like
have
language
segmenters
like
at
least
consult
with
them
or
like
otherwise
get
exposed
to
their
work
right
rather
than
just
focusing
on
instrumentation.
E
But
yeah,
I
think
I
can
try
to
make
it
an
item
to
start
promoting.
That
working
group,
like
I
think,
there's
an
avenue
in
for
more
outside
contributors
to
get
involved
through
this
stuff.
We're
also
seeing
people
coming
in
from
like
hbase
and
like
big
data
systems
and
saying
we're
thinking
about
native
instrumentation,
and
we
want
to
participate.
So
so
I
I
think
this
is
actually
an
area
where
we
can
start
cultivating
new
people.
If
we,
if
we
make
it
a
focus
in
2022.,.
J
Yeah
ted.
I
was
wondering
if
there's
some
like
threshold,
that
we're
going
to
cross
when
our
protocols
are
stable
and
our
1.0s
are
out
that
brings
in
other
contributors,
because
I
think
it's
a
completely
different
group
of
people
who
wants
to
write
specs
and
protocols.
I
don't
actually
think
anyone
wants
to
write
specs
and
protocols
versus
ones
that
want
to
write
fancy,
instrumentation
and
high
performance,
instrumentation
and
good
instrumentation.
E
I
don't
want
to
spend
too
long
on
this
subject,
but
I
also
think
there's
a
the
inverse
of
this
is
true,
which
is
like
if
we
don't
get
a
handle
on
this
and
then
release
like
stable
1.0
and
like
that
ecosystem
is
like
vague
and
we're
not
we're
not
wrangling.
It
then
that'll
like
create
its
own
bottleneck,
so
I.
G
E
E
E
We
are
being
a
little
independent
right
now
and
I
don't
totally
know
where
to
to
funnel
them.
So
so
maybe
some
more
tc
participation
is
helpful.
There,
maybe
even
moving
people
up
to
the
tc
level,
who
have
a
focus
on
ecosystem
stuff,
might
be
helpful.
J
Yeah
ted,
you
know,
the
list
of
people
that
you
just
named
are
all
people
who
have
expressed
frustration
with
the
hotel
tc.
I
think
I
probably
did
that
on
purpose
right,
but
no.
E
J
So
one
comment
I
have
on
that
that
we
haven't
really
discussed
is,
I
feel
like
there
is
a
tendency
among
all
of
us,
including
myself,
perhaps
to
respond
to
that
group
of
people
who
have
legitimate
needs
and
interests
with
a
here's.
Why
you
can't
do
that
kind
of
answer?
Here's
why
you
can't
do
that?
I'm
it's
really
easy
to
come
up
with
here's,
why
you
can't
do
that.
J
It's
really
hard
to
come
up
with
here's,
how
we
can
make
this
possible
or
here's
how
I
can
make
this
possible
for
your
special
interest
and
I
don't
know
how
to
say
we
should
be
more
of
an
enabler
in
our
role
as
tc,
but
I
know
that
those
particular
people
have
come
with
legitimate
issues
that
need
solution.
Finding
and
and
it's
much
easier
and
I've
seen
cases
I
don't
want
to
name
specifically
of
just
like
you
can't
do
that,
and
I
have
nothing
more
to
say
and
I'm
on
the
tc.
E
Yeah,
I
think
sorry
ben
you
look
like
you're
talking.
Oh,
you
should
respond
to
that.
Oh
I
just
my
my
experience,
because
hanging
out
with
a
lot
of
these
people
is
it's.
It
is
a
combination
of.
E
E
So
I
think
that's.
Why
there
just
needs
to
be
some
structure
here
and
also
again
if
the
tc
is
like
literally
spread
too
thin
expanding
it
to
add
some
people
who
you
know
could.
H
I
guess,
but
I
want
to
call
out
that,
like
you
know,
there's
there's
an
element
to
the
specification
that
until
we
get
the
community
degree
on
stability
in
certain
pieces,
we
can't
build
on
top
of
it
and
a
lot
of
the
things
that
you're
talking
about
people
who
want
to
build
on
top
of
a
stable
spec
and
and
we
didn't
stabilize
our
spec
and
like
that's
like
one
of
these
fundamental
things,
that's
been
kind
of
frustrating
for
me
personally
to
deal
with
of
there's
all
sorts
of
things.
H
I
want
to
propose
and
do
that.
I
can't
because
I
have
to
wait
for
something
to
be
stable
first,
that
we
can
build
on
top
of
and
get
agreement
there.
So
I
redirected
all
of
my
efforts
around
the
stabilizing
pieces
to
like
then
accomplish
these
extra
things,
and
that's
like
the
question
I
have
fundamentally
is:
if
someone's
not
willing
to
do
that,
how
do
we
continue
to
keep
them
an
active
helpful
member
of
the
community
because,
again
like
this
is
where
the
roadmap
can
come
into
play
and
help
of
just
telling
people?
B
I'd
be
sorry,
sorry,
I
really
want
to
talk
about
that
too,
because
that's
my
personal
acts
to
grind
about
open
telemetry,
but
I
want
to
make
sure
we
don't.
You
know,
come
away
from
the
first
part
of
this
discussion
with
something
a
little
more
actionable.
I
mean
it
seems
like
we
all
agree
that
we
don't
have
a
a
good
pro,
a
great
process
to
clarify
how
people
move
through
the
ladder.
Nor
are
we
proactive,
as
josh
said
josh
s
said,
which
I
totally
agree
with.
B
We
agree
that
we
don't
have
enough
people
just
contributing
to
certain
areas
of
the
project,
even
though
we
have
so
many
contributors
from
this
devstat
standpoint.
It's
not
uniform
and
that
part
of
the
issue
is
stability,
and
you
know
just
kind
of
opening
the
floodgates
on
1.0,
stuff
or
whatever,
and
then
there,
and
that
brings
in
roadmap
conversation.
B
But
are
there
things
that
I
mean?
I
guess
I
would.
I
would
say
that
there's
a
pretty
tactical
thing
to
just
write
down
some
process
stuff
and
then
to
you
know,
explain
to
the
maintainership
community
that,
like
the
maintainer
community
that
needed
to
do
this
stuff,
so
that
seems
like
something
someone
could
own.
There's.
B
Maybe
there's
some
expectation
we
set
around
like
the
number
of
times
per
year
per
quarter
per
month
or
whatever
that
that
we
go
and
like
look
for
people
who
could
be
laddered
up
and
like
encourage
them
to
do
so,
something
more
proactive.
B
I
don't
the
1.0
thing,
I'm
totally
all
in
on
that,
but
that's
a
hard
problem
and
gets
back
the
road
map
thing.
Are
there
any
other
things
that
I
mean
lizzie
brought
out
the
contrib
stuff?
Is
I
don't
think
that
we
actually
want
to
reverse
that
decision,
though,
are
there
any
other
like
actual
actions
that
we
can
take
now
that
that
will
improve
the
situation.
I
So,
at
the
very
beginning
of
the
letter
you
know
we
can
encourage
people
to
contribute
to
small
items
for
our
individual
projects
by
you
know
taking
the
time
and
labeling
issues
with
you
know,
good
first
issues
and
having
people
to
contribute
to
small
nuggets
through
our
projects.
I
Now
that
that
initial
contribution
generally
converts
into
further
contributions,
so
not
not
saying
that
those
people
are
going
to
become
maintainers
over
time.
Most
of
them
are
not,
and
most
of
them
are
just
going
to
disappear
after
after
a
month
or
so,
but
I
do
know
a
few
people
who
are
around
and
they
are
interested
in
working
on
those
items.
You
know
on
their
free
time-
and
I
know
a
couple
of
people
that
also
moved
closer
to
our
area,
closer
to
telemetry
observability
in
general,
because
those
small
nuggets
they
contributed.
I
They
were
fun
to
work
with
you
know
and
they
started
working
with
observability
at
their
companies
and
now
they're
expanding
their
roles.
So
I
think
my
point
is
you
know
we
should
also
take
some
time
to
not
do
things
this
easy
things
ourselves,
but
mark
them
as
good
first
issues
and
and
make
sure
that
people
know
about
them.
You
know
so
go
on
twitter,
on
social
media,
go
on
whatever
and
announce
them
and
also
have.
G
Mean
jurassic,
what
I
would
say
is
I
completely
agree
with
you,
but
you
know
one
of
the
things
that
I've
noticed
and
just
having
worked
across
the
different
segs
is
that
you
know
we
have
very
experienced
engineers
who
are
maintainers
at
this
point
and
and
again
as
josh
was
referring
to
them
as
the
old
guard
right
and
and
then
we
have
the
rest
right
like
all
of
us.
You
know
I
have
at
least
added,
you
know
almost
almost
70
80
engineers
on
this
project
and
and
more.
We
continue
to
add.
G
But
again,
the
graduation
path
is
very
slim
there,
right
and
and
most
of
the
time
the
maintainers
actually
don't
have
the
bandwidth
to
go
and
tag
good.
First
issues,
triagers
even
I
mean
I,
I
look
at
the
collective
backlogs.
I
back,
you
know
triage
as
much
as
I
can,
but
the
point
is
that
this
is
an
activity
that
either
maintainers
delegate
to
others.
You
know
who
are
not
as
experts
as
they
are,
but
are
happy
to.
G
You
know,
actually
work
with
the
larger
community
and
encourage
new
engineers
to
participate
and
stick
around
on
the
project.
But
it's
a
question
of
delegation
right
and
maintainers
are
leaders
and
and
if
you're
looking
at
your
roles
as
senior
engineers,
as
just
you
know,
doing
your
own
stuff
and
being
technical
experts,
then
yes,
that's
absolutely
okay,
but
you
also
have
to
delegate-
and
I
absolutely
you
know
seeing
that.
I
I
completely
agree
with
that.
I
mean
I
think
we
can
unite
those
two
things
here.
So
whenever
we
would
see
like
a
green
review
on
apr,
meaning
an
approver
approved,
then
our
role
as
maintainers
is
just
to
merge
it
and
not
think
about
reviewing
it
again.
I
B
B
A
H
Not
practical
in
some
cigs,
like
cpus,
plus
where
the
approver
pool
was
really
really
really
low,
yeah,
but
I
agree
with
you
in
general:
it
should
definitely
be
too
it's
just
we
might
have
to.
We
might
have
to
have
some
caveats
there.
I
have.
I
have
a
quick
proposal
in
terms
of
something
that
I
think
is
concrete.
H
We
can
do
I
we
talked
about
doing
a
monthly,
proactive
review
of
maintainers
and
approvers
and
lists
if
we
can
have
just
a
monthly
dump
of
statistics
on
github
repos
of
who
is
making
pull
requests,
who's,
doing,
reviews
who's,
opening
issues
that
sort
of
thing
like
just
a
contribution.
H
You
know
accountability
thing
and
then
we
just
evaluate
it
and
say:
is
there
someone
here
we
want
to
reach
out
to
just
let's,
let's
just
make
that
part
of
the
process.
Every
month
we
ask
sigs
to
do
this,
we
send
them
an
email.
Is
that
a
reasonable
thing
for
us
to
all
agree
that
this
is
this
will
start
moving
the
direction
we
want
to
go.
G
That'd
be
great,
I
mean
I
already
pulled
these
stats
so
because
we
have
to
look
at
them
aws,
but
I
can
definitely
add
that
to
the
contribute
that
to
the
refunds,
yeah,
you
know
the
reaper
reports.
B
So
did
you.
G
B
Did
we
make
a
decision
about
the
approver
thing
I've
the
two
approvers.
A
D
I'm
I'm
fine
with
saying
that
this
is
now
an
option
that
maintainers
can
have
for
their
projects.
Rather
than
saying
we
are
doing
this
across
the
board
right
maintainer.
If
you
are
finding
that
you
are
not
adding
value,
you
trust
your
approvers
to
merge.
You
may
go
ahead
and
give
them
permissions.
Does
it
seem
reasonable
somewhat?
Although
I
I
mean.
B
I
I'm
worried
a
little
bit
about
just
just
a
desire
to
control
things
from
a
maintainer
standpoint
like
trumping
the
needs
of
the
project,
or
I
I
prefer
the
option
of
having
the
maintainers
decide,
not
necessarily
with
total
consensus,
but
like
yes,
maintainers
can
decide
jointly
what
you
know
what
we
want
to
do,
but
I
generally
want
to
make
it
easier
for
things
to
move
forward
in
the
project
and-
and
I
can
see
this
as
a
mechanism
to
to
do
that-
one
maintainer
or
two
approvers-
I'm
just
worried
liz
about
someone
saying
no,
because
they
don't
personally
want
that,
even
though
it
would
be
better
for
the
sig.
G
I
agree
with
then,
because
the
reason
I
I
say
this
is
that
why
not
you
know
if
somebody
fails,
I
mean
I
have
not
seen
the
lack
of
good
faith
on
every
approver
and
every
maintainer
who's
on
the
project.
So
if,
if
an
approver
doesn't
live
up
to
their
commitments
and
somehow
makes
an
error,
then
the
maintainers
can
take
away,
you
know
and
say:
okay,
we
don't
want
to
give
you
the
rights
so,
but
why
not?
G
F
Right
and
if
we're
worried
about
something
like
whether
it's
malicious
or
accidental,
but
something
bad
getting
getting
merged
and
released,
I
think
most,
if
not
all
cigs
the
release
process
is
still
gated
on
the
maintainers
anyways.
So
it's
not
like
some
rogue
approver
could
could
release
some
some
bad
or
malicious
update
on
their
own.
A
Yeah,
I'm
supportive
of
the
idea
to
lower
the
barrier
and
make
approvers
kind
of
make
it
possible
for
them
to
merge
things.
I
just
want
to
make
sure
that
others
are
on
board
as
well.
We
have
tcng
members
who
are
not
here
and
it
would
be
good
to
also
see
what
maintainers
think
about
it.
I
am
supportive
personally
yeah
myself
as
well
yeah.
E
H
Want
to
call
out
I'm
supportive
as
long
as
the
community
is
large
enough
of
this
change,
yeah
for
the
really
small
community,
c,
plus
plus
php.
I
I
think
we
need
to
give
them
a
little
more.
You
know
get
what
what
do
you
call
that
judgment
in
terms
of
what's
gonna
work
best
for
their
community
and
their
process,
just
because
they're,
a
lot
tinier.
F
Yeah,
but
I
think
if
we
bring
it
up
in
the
maintainers
meeting
as
a
proposal,
we
say
we
would
like
to
propose
one
maintainer
or
two
approvers
and
the
approvers
can
then
merge
and
then
one
open
it
up
to
the
other
maintainers
to
to
say
I
do
or
do
not
like
this
for
these
reasons,
but
then
also
to
make
it
clear.
If
you
want
to
deviate
from
the
from
this,
then
you
know
you
have
to
have
a
good
reason.
Like
a
php
says
we
don't
have
enough
people
to
do
that.
F
Then
you
say:
okay,
you
do
something
different,
but
maybe
they
have
to
get
the
approval
of
the
tc
to
have
a
different
process
right.
They
just
just
tell
the
tc.
We
can't
do
this.
For
these
reasons
the
tc
says
we
voted
on
it
and
said:
that's
fine.
G
F
We
also
don't
really
have
a
good
way
to
have
like
maintainer
votes
on
anything
right
now,
which
that's
an
entirely
separate
discussion,
but
a
lot
of
these
decisions
that
are
should
be
made
by
the
maintainers.
As
a
group,
we
don't
have
any
way
to
make
a
group
decision.
E
I
think
a
community
issue
with
a
proposal
coming
from
the
you
know:
gctc.
That's
then
posted
in
their
slack
channel
and
then
raised
in
the
maintainers
meeting,
but
you
know
proposed
as
a
proposal
for
discussion
and
daniel.
I
think
you
put
a
lot
of
good
caveats
in
there,
which
I
think
are
important
to
have
as
part
of
the
proposal.
G
E
Saying
recognizing
not
all
cigs
are
in
the
same
place,
yep
yeah.
I
I
would
like
to
make
one
more
proposal
specifically
about
the
stakes
that
are
just
understaffed
right.
We've
identified,
there
are
groups
that
are
literally
just
understaffed
and
we
have
a
lot
of
staff
and
potential
staff.
A
lot
of
these
core
organizations
that
we
work
for
is
it.
F
So
I
guess
I
to
make
my
my
problem
a
little
bit
more
clear.
We
have
contributors
for
the
contrib
repository
like
we
tend
to
have
people
that
want
to
work
on
the
instrumentations,
but
those
people
either
don't
feel
comfortable
contributing
to
the
core
or
you
know,
for
whatever
reason
they
just
don't.
We
also
have
instituted
some
level
of
like
ownership
of
individual
components,
so
we've
we've
delegated
individual
components.
In
our
contrib
repository
to
say
this
person
has
authority
over
this
component,
and
that
has
worked
really
well
for
us.
F
Our
contrib
repository
is
as
healthy
as
it's
ever
been
yeah,
it's
the
core
that
that
we're
having
trouble
with.
I.
E
I
guess
what
I'm
saying
is:
is
there
another
way
we
can
have
a
discussion
more
explicitly
for
the
the
groups
that
are
actually
paying
people
to
work
on
this
project
like
who
have
like
a
strong
stake
in
the
project
and
are
paying
people
to
work
on
it?
Is
there
a
way
we
can
review
the
balance
of
contributions
and
like
try
to
collaborate
on
rebalancing
in
cases
where
we're
just
identifying
that,
like
you
know,.
G
E
Plus
is
an
example.
Js
is
an
example.
Php
is
harder
because
we
don't
tend
to
have
people
who
know
how
to
work
on
that.
But
but
those
are
just
examples
of
places.
Could
we
just
perhaps
coordinate
more
on
the
staffing
side?
It's
like
possibly
a
slightly
different
group
that
has
that
discussion,
but
I
just
want
to
bring
that
up
as
a
way
to
help
with
with
this
other
problem
that
that
we're
having.
M
Yeah,
I
think,
to
this
idea
of
promotion.
We
underst
like
paying
blender
paid
maintainers.
The
idea
of
approvers
merging
things
may
even
hurt
us,
because
if
we
under
wants
to
control
over
like
some
sdk
or
like
piece
of
code-
and
they
have
approvers
that
can
merge
things,
then
they
may
think
it's
enough
for
them
to
participate
in
this
kind
of
repository.
M
So
that
might
be
I
mean,
maybe
you
can
I
like
your
idea
of
like
asking
vendors
like
some
somehow
promotion
who
is
controlling,
which
repositories
and
maybe
putting
the
under
names
more
explicitly
will
make
companies
want
to
contribute
more
and.
E
M
G
And
also
actually
ted,
you
know
just
to
again,
you
know
having
an
understanding
of
where
we
need
more
participants
and
more
contributors
would
be
helpful
because,
again,.
E
F
Yeah,
okay,
that
sounds
good.
There
was
something
else.
The
second
one
was
a
more
proactive
look
at.
Who
is
an
approver?
G
B
Totally
supportive
of
doing
that,
daniel
and
providing
that
guidance,
not
a
command
as
ted
would
say,
but
I
think
it's
good
guidance.
I
was
also
wondering
you
know
we
were
talking
about
automating
various
things
via
scripts,
which
I'm
totally
supportive
of.
Would
it
be
reasonable
for
the
maintainers?
B
I
don't
know
like
once
a
month
or
something
like
that
to
just
do
like
stoplight
health
on
you
know
their
perception
of
a
number
of
contributors,
the
code
like
we
call
it
velocity
or
whatever
just
the
sort
of
progress
within
the
sig,
as
well
as
the
number
of
maintainers
just
on
a
month
month,
minute
basis.
B
Just
you
know
green,
yellow
red,
that's
it
and
just
track
it
somewhere,
because
I
think
I
would
trust
the
maintainers
to
make
those
assessments,
and
I
think
it
can
be
difficult
with
scripts
to
really
like
tease
out
whether
there's
a
problem,
and
it
would
give
us,
as
a
cohes
as
a
tcgc
group,
a
little
bit
more
data
to
work
with.
In
terms
of
where
we
need
to
focus
effort,
because
you
know
the
reality
is
certain
cigs
need
more
people
than
others.
So
it's
not
like.
B
B
B
F
Yeah
yeah
totally
doing
more
yeah.
Maybe
we
should
try
to
do
quarterly
combined
meetings
or
something
like
that.
That
sounds
good.