►
From YouTube: 2021-12-16 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
Yeah,
after
I
don't
know
four
months,
we
finally
got
it.
You
know
there,
you
have
such
a
a
back
order
for
those
things
and
it
takes
ages.
B
C
A
What
a
party,
I
wonder
if
we're
gonna
get
the
quorum
today.
A
E
A
A
F
A
A
The
only
thing
I
had
on
the
agenda
for
myself,
which
I
didn't
actually
put
on
an
agenda,
was
just
I'm
trying
to
get
people
to
pay
attention
to
this
issue
around
tracking,
sick,
it
health,
but
an
indicator
of
a
sick
health
issue.
A
There's
no
traction
on
like
that
topic
I
mean
we
can
just
like
force
maintainers
to
complete
a
survey
that
was
basically
unchanged
since
my
proposal,
but
I'm
still
kind
of
feeling
like
there's
some
sort
of
like
like
there
is
a
sick
health
problem
and
that
the
proposal
that
I've
made
isn't
going
to
address
it
like
like,
depending
on
the
sig,
like
the
collector's
sake,
is
like
probably
oversubscribed
in
terms
of
contributions
and
scope,
and
then
others
like
the
javascripts
that
daniel
that
you've
mentioned
it's
like
really
starved
for
contributors
and
but
I
I
think
that
there
are
is
like
a
big
health
issue,
but
I
I'm
not
really
sure
if
the
proposal
that
we
have
on
the
tables
the
maintainers
haven't
been
like,
jumping
up
and
down
about
it
and
I'm
I'm
not
sure
it's
going
to
help.
A
So
I
don't
know,
I
think
it's
kind
of
our
job
to
address
that
from
the
governance
standpoint,
but
I'm
not.
I
don't
want
to
just
like
push
the
proposal
through
and
be
like
great.
You
know
we
solved
it
when
when
it
doesn't
seem
like
it's,
I
don't
know
the
maintainers
just
expressed
like
almost
no
enthusiasm
or
concern
just
like
no
response,
one
way
or
the
other.
F
I
think
I
think,
when
one
of
the
things
that
is
happening
is
that,
as
you
mentioned,
there
is
some
lopsidedness
right.
I
mean
if
you
look
at
some
of
the
sigs.
We
are
really
struggling
with.
You
know
the
number
of
active
maintainers
or
maintainers
per
se,
and
and
and
then
we
have,
you
know
over
subscription
on
other
components
such
as
the
collector.
F
But
yet
you
know
some
some
amount
of
throttling
on
the
maintainership
right.
So
so
there
again.
I
think
that
this
can
only
be
solved
by
working
closely
with
the
maintainers
at
least
having
one
maintainer
from
every
sig.
You
know
being
a
point
of
or
being
an
owner
and
working
with
us
on,
you
know
being
able
to
at
least
take
a
call
for
each
sig,
but
it
has
to
it
requires
some
work
because,
as
you're
seeing
you
know,
there's
either
crickets
or
you
know
or
lots
of
noise,
I
mean
we
are
lucky.
A
G
A
Rephrase
the
sigs
have
for
different
totally
different
reasons,
have
health
issues
and
then
it's
difficult
as
a
governance
committee
to
come.
If
the
governance
was
just
for
one
of
them,
it
would
be
fine,
be
like
well,
we
need
more
contributors.
In
some
cases
we
kind
of
need
fewer
contributors.
So
I'm
having
trouble
coming
up
with
governance
proposals
to
address
this
across
the
board,
since
the
issues
are
so
different
and
diverse,.
E
Well,
for
cigs
that
have
too
many
contributors,
I
guess
to
me
it
seems
like
the
solution's
easy
you
just
promote
more
of
them
to
be
maintainers
to
handle
the
bandwidth
like
the
bandwidth
problem.
There
is
that
maintainers
can't
review
and
merge
quickly
enough
when
there's
too
many
changes
coming
in
right.
E
So
with
the
the
promoting
people,
when
you
have
too
many
seems
much
easier
than
conjuring
people
out
of
thin
air,
when
you
don't
have
enough
yep,
when
you
don't
have
enough,
which
is
the
situation
that
I
think
most
of
the
sigs
are
in
yeah,
it's
a
lot
harder
and
I
think
the
way
I
look
at
it
is
we
have.
We
have
a
scope
of
the
project
and
we
have
a
certain
number
of
people
to
work
on
it.
E
H
E
H
E
Yeah
liz
you're,
you're
sort
of
quiet-
I
don't
know
if
anyone
else
yeah,
hey
man.
E
What
was
I
going
to
say?
One
thing
that
that
particularly
the
js
sig
struggled
with
was
the
transition
from
tracing
to
metrics
for
two
different
reasons.
One
was
that
we
had
a
lot
of
active
contributors
on
tracing
things
and
once
tracing
felt
complete
or
even
complete
enough
when
it
wasn't
1.0.
Yet
people
were
once
it
became
usable
for
their
use
case.
E
They
dropped
like
flies,
which
was
really
difficult,
and
the
other
thing
was
that
the
at
that
time
it
felt
like
the
metrics
was
ramping
up,
while
tracing
wasn't
even
done
yet,
and
it
was
taking
away
from
when
we
were
trying
to
finish
up
and
and
make
tracing
1.0.
E
Or
tracing
were
getting
a
significant
amount
of
work
for
a
long
period
of
time.
We
were
in
this
like
weird
limbo
state,
where
neither
of
those
signals
was
getting
a
significant.
You
know
enough
attention,
and
now
that
tracing
is
1.0,
we
certainly
have
more
time
to
spend
on
metrics,
but
it
seems
like
as
soon
as
one
thing
is
nearing
the
point
where
we're
ramping
up
and
getting
close
to
completing
it.
Everybody
wants
to
talk
about
what
we're
going
to
do
next
like
right.
E
E
So
we
have
a
lot
of
contributions
and
contrib,
I
would
say,
for
every
contribution
in
the
core
we
have
10
in
can
trip,
which
means
that
a
lot
of
my
bandwidth
is
sucked
up
in
reviewing
those
and
it's
taking
away
from
the
sdk.
I
E
I
Yeah
we
we
have
it
for,
for
this
reason,
daniel
and
helped
us
a
lot.
I
E
Yeah
so
I
mean
maybe
we
should
consider
something
like
that
and
I
you
know
I
probably
will
we
at
the
moment
we
have
like
de
facto
maintainers
on
contrib
as
it
is
they're.
H
I
Is
this
chicken
egg
problem
which
I
don't
know
how
to
solve
yet
I
I
really
saw
that
once
you
empower
people
and
you
put
their
title
on
them,
majority
of
the
people
start
working
more
for
good
or
for
bad.
Once
you
put
a
bit
of
maintainer
to
them
or
approve
her,
they
start
to
do
forward
now.
The
chicken
egg
problem
here
is:
you
cannot
randomly
put
to
everyone
the
maintainer
bit
and
wait
for
for
people
to
start
working.
I
E
B
E
F
So
I
think
daniel
I
can
outline
to
you
what
you
know.
For
example,
we
had
a
lot
of
javascript.
You
know
support
and
interest
last
last
year
right
right
up
to
the
end
of
last
year
and
and
this
is
2020
right
and
and
then
when
we
when
we
tried
to
contribute
from
aws.
You
know
there
were
a
huge
number
of
google
engineers
involved
and
we
just
didn't
have
enough
projects
to
work
on,
so
we
reassigned
engineers
into
other
sites.
So
again
it's
it's
also.
H
F
So
you
know,
maybe
if
we
figure
out
what
the
map
is
of
you
know.
Where
I
mean
you
know,
contributors
are
required,
then
we
can
definitely
do
a
more
organized
way
of
helping,
especially
for
the
large
orgs
right.
E
B
Can
be
somewhat
addressed
by
something
that
we
discussed
a
couple
of
weeks
ago.
I
think
which
is
coming
up
with
this
letter.
You
know
the
the
progression
ladder
or
I
don't
know
how
it
was
called,
but
you
know
having
a
way
of
people
to
very
concrete
set
of
steps
where
people
can
take
to
to
grow
within
a
project,
but
not
only
having
those
steps
listed
somewhere
in
some
talk,
but
also
you
know
being
telling
all
the
maintainers
that
it
is
their
jobs
to
mentor
folks
as
well.
B
I
I
see
some
success
in
you
know
encouraging
personally
encouraging
people
to
contribute
and
to
review
other
folks
prs
and
actually
pinging
them,
and
once
they
become
an
approver
or
wants
to
become.
I
don't
know
the
next
step
after
remember
they,
then
it
becomes
what
bogom
said,
which
is
you
know
they
have
now
a
a
bigger
title,
so
they
start
working
more.
B
E
E
You
know
like
alolita
mentioned
aws
can
can
always
dedicate
engineers
when,
when
a
sig
needs
help
here
and
there,
but
that's
not
necessarily
going
to
work
long
term
for
every
sig,
so
maybe
a
solution
for
for
my
particular
problem.
But
it's
not
a
solution
for
the
project's
problem.
I
don't
think.
B
Yeah,
I
think
it
circles
back
to
the
original
question
from
ben
and
I
think
it
there
is
a
reflection
on
on
why
people
are
not
answering
or
not
paying
that
much
attention
to
the
spreadsheet
or
or
to
the
survey
because
they
might
not
be
seeing
what
is
what
is
the
benefit?
So
what?
What?
What
are
they
getting
from
investing
time?
On
that?
B
You
know
so,
perhaps,
instead
of
asking
and
requiring
everyone
to
fill
out
a
a
some
fields
and
a
spreadsheet
somewhere,
perhaps
you
know
focus
on
one
project
that
is
interested
in
being
helped
and
assess
the
health
for
them
and
and
come
up
with
a
solution
for
problems
that
they
might
be
having.
You
know,
so
do
the
full,
the
full
work
or
the
full
job
for
one
specific
project
and
then
publish
the
results
and
see
you
know
this.
F
You
know
initially
to
vet
out,
you
know
what
works,
doesn't
work
and
also
have
a
more
you
know
evolving
standard
if
you
will
a
process,
but
but
I
think,
there's
also
some
skepticism,
which
I
am
also
part
of
which,
where
I
do
see
things
are
not
really
progressing
and-
and
you
know
it's,
it's
a
trade-off
between
sustainability
and
interest
right,
because
at
the
end
of
the
day,
resources
you
know,
that
is
engineering
in
every
organization
is
very
precious
and
we
are
an
enterprise
or
you
know,
organization,
driven
project,
we're
not
and-
and
you
know
individual
engineer,
driven
project,
as
you
know,
open
source
used
to
be
so
so
we
need
to
look
at
it.
F
You
know
with
some
more
dimensions
in
one
sense,.
A
Yeah
jurassia,
I
first,
I
agree
with
you
in
terms
of
the
assessment
and
the
topic
here
is
not
so
much
my
issue,
but
more
inspired
by
that,
like
I
do
think,
there's
an
issue
with
the
six.
I
don't
think
my
proposal
is
going
to
help
that
much
and
I
think
your
assessment
is
right
on
that.
It
was
kind
of
like
what's
in
it
for
me,
basically
and
not
in
a
like
bad
way,
but
just
like.
Why
would
someone
want
to
do
that?
The
problem
I'm
having
is
that
I
think
some
of
the.
A
If
we
sort
of
ask
the
sig,
I
think
what
we're
doing
is
we're
asking
the
maintainers,
and
sometimes
the
problems
are
from
the
contributors
or
I
mean
alita
brings
up
a
good
point
from
the
people
who
employ
the
contributors.
That
may
also
be
an
area
where
there
are
concerns
in
some
cases.
A
Are
you
missing?
Are
you
at
risk
of
missing,
like
commitments
that
we've
already
established
as
a
project?
If
so,
let's
talk
and
then
see
who
takes
us
up
on
it
and
then
just
take
it
case
by
case
which
is
different
than
filling
out
a
spreadsheet,
similar
spirit.
I'm
a
little
bit
worried
that
when
we
approach,
if
we
approach
the
maintainers
and
the
problem
is
on
the
contributor
side
that
we
might
not
hear
the
problems
or
if
it's
on
the
employer
side,
we
might
not
hear
the
problems,
but
we
could
start
there.
A
If
that
I
agree
with
you
basically
that
we
should,
we
should
try
to
engage
more
directly
and
then
you
know
come
up
with
some
success
stories
where
we've
actually
improved
things,
whether
it
was
reducing
scope
or
adding
people
or
adding
maintainers
or
whatever,
but
I'm
just
trying
to
figure
out
how
to
kind
of
like
get
that
process
going
because
right
now
we
talk
about
this,
the
gc
pretty
frequently,
but
I
don't
see
a
lot
of
tangible
change
aside
from
the
the
criteria
to
be
a
maintainer,
there
hasn't
been
much
that
we've
really
accomplished
and
that
that's
what
I'm
trying
to
push
on.
F
B
I
guess,
as
a
maintainer,
I
would
really
appreciate
some
help,
but
not
only
in
asking
me
what
what
do
I
need,
but
it
helped
me
assess
what
do
I
need
you
know.
So
perhaps
I
don't
know
that
my
contributor
guides
guidelines,
they're
they're,
accurate
they're
up
to
date,
they're
usable
you
know
for
for
newcomers.
B
So
perhaps
that's
the
problem
for
my
for
my
specific
niche
and
having
some
help
from
someone
like
an
outside
outsider
hearing
in
quotes,
of
course,
in
in
making
a
first
contribution
to
the
project
following
the
guidelines
following
documentation.
You
know
that
might
that
might
help
that
might
bring
that
might
help,
understand
the
pain
points
for
the
initial
contributors
and
then
perhaps
also
running
a
survey
with
the
top
contributors
that
are
not
maintainers.
B
You
know
so
ask
approvers
and
occasional
contributors
as
well
so
people
from
from
from
vendors
who
are
not
working
100
on
on
open
telemetry,
but
they
do
periodically
or
they
they
do
with
some
frequency
crs.
You
know
so
I
wouldn't
have
the
time
to
ask
them
all
of
them.
I
do.
B
I
do
have
some
some
contact
with
some
of
them,
but
I
would
certainly
appreciate
having
insights
on
a
broader
scope.
G
I
have
a
question
to
people
on
this
call
where
one
two,
three
four
at
least
five
people
are
vendors
kind
of
representatives
of
vendors
like
when,
when
we
were
developing
jaeger's
the
case,
we
were
using
them
actively
at
uber
and
as
a
result,
we
always
had
maintainers
developing
those
case
because
we're
using
them
right
and
we
needed
changes.
G
And
so
is
that
the
case
that
the
vendors
who
participate
in
opengl
just
are
not
interested
in
these
decades
in
development,
and
that's
why
they
don't
put
up
resources,
because
that
that's
something
that
I
I
don't
understand
why
we
have
the
issue
with
maintainers.
If
there's
like
participants
actually
really
need
that
thing.
So.
H
I
think
it
has
to
do
with
the
phenomenon
that
was
being
discussed
earlier.
There
was
a
lot
of
very
active
interest
in
tracing
because
that
was
kind
of
the
critical
blocking
factor
towards
a
large
number
of
folks
being
able
to
dedicate
their
proprietary
tracing
apis,
whereas
for
metrics
the
support,
I
will
say,
is
a
little
bit
more
uneven
among
the
contributors
to
the
hotel
ecosystem
and
some
folks
have
a
larger
interest
in
ensuring
full
metric
support
than
others.
A
A
F
F
A
Looking
at
the
clock,
well,
first
of
all
yuri
did
that
I
don't
know
what
the
question
behind
your
question
was,
but
did
did
that?
Do
you
have
other
questions
about
the
the
kind
of
dog
fooding
aspect
of
it.
G
A
I,
in
terms
of
I'm
trying
to
like
move
things
forward
and
not
just
kind
of
talk
about
this
again
in
january,
I
mean:
are
there?
Could
we
make
a
short
list
of
things
like
right
now
that
we
think
we
should
engage
in
specifically
is
kind
of,
like
you
know,
cases
where
there's
some
sort
of
improvement
we
made,
I
mean
off
the
top
of
my
head.
We've.
A
We've
certainly
talked
about
the
javascript
thing,
just
having
like
some
resourcing
issues,
but
I
don't
know
daniel
if
you
think
it's
actually
necessary
at
all
to
like
engage
in
it
or
I
mean
you're.
Obviously,
super
competent.
I'm
sure
that
you
have
your
head
around
it,
but
if
we
could
try
that
the
collector
is
another
area
where
I
could
imagine
there
being
some
real
benefit,
because
that's
just
super
super
complicated
and
has
a
ton
of
people
involved.
A
I
don't
know
if
there
are
others,
I'm
just
trying
to
see
like.
Can
we
start
the
new
year
saying
like
we're,
genuinely
trying
to
be
helpful,
but
go
go
and
figure
out
like
what
the
issues
are
and
try
to
solve
them
somewhat
quickly
like
or
at
least
improve
upon
the
state
of
the
art?
But
I'm
just
trying.
F
A
F
F
I
I
think
that
ben
I
would
say
that,
given
you
know,
even
with
our
metrics
stability
goals
that
are
coming
up
next,
we
have
three
language
sigs
and
the
collector
that
need
to.
Actually,
you
know,
implement
an
initial
stable
version
right
and
if
you
were
to
even
take
that
the
collector,
as
well
as
java,
javascript
go
and
python
are
the
ones
which
are
you
know
most
active
today
on
the
project
right
so
from
those.
Even
if
we
were
to
select
three
languages
and
the
collector.
That
would
be
your
short
list.
E
Yeah-
and
I
don't
know-
I
don't
have
a
lot
of
insight
into
the
other
cigs,
but
it's
it's
my
feeling
at
least
from
the
outside,
that
the
java
sig
is
one
of
the
healthiest
ones
that
we
have
and
I
usually
have
a
fairly
good
feeling
about
go.
But
I
again
that's
from
the
outside.
I'm
really
not
sure.
F
Now
go
has
a
shortage
of
maintainers
too,
at
this
point
so
again
and
java
is
also
having
you
know
some
some,
because
they're
spread
quite
quite
thin
now,
given
that
they're
doing
instrumentation,
they're
doing
sdks
and
then
they're
doing
other
core
functionality
right.
So
the
number
of
maintainers
and
even
on
java,
has
not
increased
as
much
as
the
scope
has.
A
E
Yeah
javascript
yeah.
I
I
would
say
that
my
my
feeling
of
the
health
of
the
javascript
seg
is
fairly
negative
at
the
moment.
They
could
definitely
use
help.
A
All
right,
I
think
we
should
try
that,
and
you
know
we'll
see
what
happens.
They're
three
very
different
cigs,
which
I
think
is
good,
so
should
give
us
some
diversity
of
problems,
so
we
don't
over
fit
to
one,
and
I
think
we
try
to
do
more
than
three.
It's
gonna
fail
just
for
resources.
If
nothing
else.
A
F
So
as
next
steps,
first
of
all,
do
we
have
a.
I
guess
we
don't
have
a
meeting
next
week
right.
So
what
do
we.
F
Right,
so
is
there
anything
we
can
help
with
then,
where
you
know,
maybe
for
the
initial
part
of
jan,
we
have
something
I.