►
From YouTube: 2021-10-21 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).
A
C
Tired,
why
we've
been
doing
like
this
huge
company-wide
planning
effort
all
week,
and
then
I
had
my
cute,
my
not
kubecon
aws
re
invent
recording
where
it
takes
four
hours
to
record
a
20-minute
talk
yeah.
I.
C
C
I'll
tell
you
on
a
non-recorded
call,
it's
okay,
just
to
say:
don't,
don't
speak
it
reinvent.
If
you
can
avoid
it,
it's
don't
speak
virtually
a
reinvent.
If
you
can
avoid
it.
I'm
doing
my.
A
C
It's
it's
basically
an
iphone
7
with
no
cell
antenna.
That's
that's
what
the
current
ipod
touches,
but
the
biggest
one
is
just
telling
them.
Oh,
I
have
a
live
demo
and
I'm
saying
what
do
you?
Why?
No
one
does
that
like?
Why
do
you?
Why
are
you
doing
that?
Why
don't
you
just
not
have
a
live
demo
like.
E
G
C
C
E
F
F
Oh
yeah,
and
you
already
commented
on
this-
I
mean
I
think
the
question
behind
my
question
is
that
we
have
this
thread
the
cncf
that
a
few
of
us
are
on.
I
don't
know
if
all
of
us
are
on.
I
can't
remember
about
you,
know
moving
forward
with
this
deprecation
and
I
think
yuri
had
brought
up.
I
think
you
know
correctly
that
when
we
started
open
telemetry,
the
idea
was
to
have
opened
open,
tracing
and
open
census
backwards.
Compatibility
is
kind
of
like
a
must-do
priority.
F
I
will
say
that,
like
it
seems
to
me
that
over
the
course
of
the
whatever
two
years
since
we
made
that
pronouncement
that
open
telemetry
has
managed
to
succeed
from
a
mindshare
standpoint
and
I'm
not
totally
sure
like
how
ironclad
the
open
tracing
backwards,
compatibility
needs
to
be
on
the
fringes
of
things,
but
I
do
think
it's
important
that
we
have
it
in
the
non-fringe
areas
and
so
yuri's
like
put
in
some
notes
about
where
things
are
at
now,
but
I
think
his
I
wish
he
was
here
on
the
call,
because
I
think
my
question
for
him
is
going
to
be
like.
F
Are
we
willing
to
deprecate
open
tracing
now
or
do
we
need
to
do
that?
What's
missing
in
hotel
like
the
spec
does
not
require
the
open
tracing
shim,
there's
no
matrix
of
support,
et
cetera,
like
our
that
that's
the
question
I
really
want
to
have
is
kind
of
an
open
tracing
question
in
some
ways
more
than
open
telemetry
question,
but
since
the
people
overlapped
so
much
I'm
happy
to
raise
it.
Here
I
mean
ted.
You
might
have
an
opinion
about
this
too,
but
but
I
think
like
that's.
F
B
Yeah,
I
can,
I
give
a
little
bit
of
as
a
maintainer.
For
one
thing,
I
thought
that
it
was
a
requirement
and
I
suspect,
I'm
not
the
only
maintainer
that
thinks
that
the
second
thing
is
we
do
in
js
have
an
open
tracing
shim
that
works
well,
and
we
see
extremely
little
demand
for
it.
We
maintain
it
because
we
we
treat
it
as
a
requirement,
but
just
for
what
it's
worth
it
doesn't
have
very
many
users.
We
see
more
people
that
just
switch
right
right,
yeah.
H
H
H
D
Logan
again,
you
know
the
approach
we
took
with
tracing
ga.
For
example,
right
we've
been
rolling
ga
across
different
languages.
You
know
over
time,
and
so
could
we
maybe
do
that?
You
know
for
this
functionality
also
over
time
right
like.
H
D
I
think
I
think
what
would
be
useful
on
our
end
is
to
actually
have
an
issue
that,
where
we
document
that
this
is
the
you
know,
paths
that
we
are
going
to
take
and
and
we'll
roll
language
by
language
and
as
we
you
know,
provide
this
support,
we
request
the
open
tracing.
You
know,
project
to
mark,
you
know
their
their
on
their
end.
Accordingly,
that
is
we
can.
We
can
provide
that
guidance
in
a
issue
and
people
can
discuss
it.
D
I
It's
okay.
I
was
going
to
say
because
the
one
thing
I
think
we're
going
to
have
to
do,
especially
for
the
toc
and
to
address
amy's
thing
is:
we
need
to
show
progress
and
so
yeah.
If
we
can
at
least
do
like,
say
the
incremental
part
that
shows
that
we
haven't
ignored
it
and
we're
meeting
our
commitments
to
the
toc.
G
I
think
that
would
be
good.
I
think,
starting
with
coming
back
to
them
with
just
an
audit
of
what
is
the
current
state
of
support,
because,
like
daniel
said,
this
has
always
been
communicated
as
as
a
hard
requirement
c
plus
plus
is
like
off
in
the
weeds
and
a
little
disconnected
from
the
rest
of
the
world.
So
I
could
see
them.
G
In
most
languages
there
are
some
edge
cases
like
ben
mentioned,
that
maybe
don't
work,
and
maybe
it's
fine
to
say
like
well
sorry
about
the
edge
cases
and
then
there's
languages
like
lua
or
whatever
that,
like
we
just
don't,
have
any
support
for,
and
I
I
would
be
willing
to
like
as
like
an
open
tracing
person
to
kind
of
like
cut
it
in
the
middle
and
say
you
know
we're
supporting
core
functionality
in
all
of
the
core
languages
and
we're
gonna
deprecate
those
one
by
one
in
some
clear
fashion
and
then
once
we
get
through
those,
then
we're
gonna
call
it
archivable.
F
I
mean
I
my
my
two
cents.
I
I
think
internally
it'll
be
fine
to
think
of
it
in
terms
of
per
language
this
and
that.
But
the
reality
is
that
the
long
tail
like
the
last
language
to
be
fully
deprecated
open
tracing
could
be
in
like
2027.
For
all.
I
know
if
we
go
that
route
just
because
of
lack
of
interest
lack
of
development,
I
think
the
paul
as
as
daniel,
I
think
correctly
said.
F
The
pull
for
open
tracing
right
now
is
probably
very
weak,
and,
although
I
bet
it's
deployed
because
all
code
is
legacy
code
and
all
that
stuff
like
I'm,
not
sure
that
there's
a
lot
of
pull
for
it
and
as
such,
I'm
not
sure
that
anyone's
going
to
prioritize
the
work
to
kind
of
move
the
stuff
over.
I
think,
like
I
mean,
maybe
we
should
actually
just
have
a
separate
meeting
of
the
open
tracing
people,
because
it
does
seem
like
an
open
tracing
decision.
F
We're
making
here,
but
but
I'll
just
say
for
the
record,
like
my
my
point
of
view,
is
that
we
should
have
an
open
tracing,
expert
kind
of
like
audit,
the
state
of
the
world
and
open
telemetry
and
verify
that
either
a
we've
already
built
the
shim
like
in
javascript,
so
check,
plus
like
it's
done
or
b.
We
understand
that
there
is
a
path
to
build
the
shim
and
that
we
have
not
painted
ourselves
into
a
corner
and
then
that's
enough
to
deprecate
like
open
tracing
in
that
language.
F
Just
the
the
feasibility,
I
guess
rather
than
the
existence
of
the
thing
and
then,
if
we
end
up
in
a
situation
where
it's
actually
not
feasible
and
like
there's
a
hard
blocker,
then
we
have
to
make
a
decision
about
whether
we
consider
that
to
be
like
a
serious
issue.
My
guess
is
that
there
are
no
cases
where
there's
like
an
infeasible,
shim,
maybe
c,
plus
plus,
but
I'm
willing
to
personally
I'd
be
like
whatever
about
c
plus
plus.
F
But
but
you
know
what
I
I
just
wanted
to
be
more
about
feasibility
than
actuality,
because
I
just
don't
think
anyone's
going
to
build
the
thing
like
no
one
is
motivated
to
do
it
in
some
of
these,
like
in
lua
or
something
like
it's
just
like
no
one's
going
to
build.
That
shim,
you
know,
is
that
I.
F
G
Like
the
biggest
consumer
of
it
out
there,
and
we
can
say
like
once-
we
are
capable
of
getting
jaeger
off
of
open
tracing.
Then
then
we
can
call
it
again.
F
I
F
Should
let's,
let's,
let's,
if
it's
cool
like
for
folks
who
are
on
the
open
tracing
side
of
things,
let's
have
a
separate
meeting
with
yuri,
because
I
think
yuri
actually
feels
stronger
about
this
than
anybody
else.
So
it's
kind
of
silly
to
have
this
discussion
without
him.
Let's
have
a
separate
meeting
with
yuri,
like
you
know,
sometime
relatively
soon,
where
we
can
come
up
with
some
sort
of
you
know,
consensus
about
what
we
think
does
that
make
sense.
Yeah.
F
G
G
G
D
Can
just
ask
in
the
maintainer's
meeting
on
monday
yeah
we
can
collect
that.
D
F
Also,
just
to
contextualize,
like
I'm,
I'm
way
more
worried
about
open,
open,
telemetry
just
continuously
being
delayed
than
I
am
about
anything
else
right
now
for
the
project.
I
think
it's
like
the
number
one
existential
thing:
it's
getting
to
a
point
where
open
telemetry
is
truly
stable
from
an
api
standpoint
and
otherwise
across
all
the
languages.
People
want,
and
I'm
I'm
really
reluctant
to
like
produce
like
major
work
items
for
people
who
could
otherwise.
D
G
F
D
F
J
F
We'll
we'll
talk
offline
and
bogdan,
I
hear
you
on
just
like,
let's
be
clear
on
specifically
what
we
need
and,
and
that
sort
of
thing
and
amy
said
that
she
was
hoping
we
could
make
some
sort
of
update
in
the
next
couple
of
weeks.
It's
not
like
this
has
to
be
resolved
tomorrow
or
something
like
that.
F
I
see
the
other
things
that
got
put
in
the
agenda.
I
I
really
mainly
just
want
the
a
bunch
of
folks
in
the
gc.
I
made
a
change
to
the
open,
telemetry
io
web
page
like
in
a
pr
which
I
haven't
merged,
yet
I
normally
wouldn't
bring
it
up
in
a
meeting.
But
it's
like
above
the
fold
like
what
is
the
message
and
then
some
stuff
like
just
below
the
fold
in
terms
of
like
you
know
where
people
are
going
to
click
through
patrice.
F
Who,
who
is
helping
to
you,
know
just
develop
the
website
and
manage
it.
Had
some
suggestions.
I
guess
the
ask
is
just
please
take
a
look
at
that
because
you
know
we're
not
like
it's
very
low
temperature
thing,
but
but
we're
just
not
in
agreement
about
what
we
should
do
so
and
I
would
just
appreciate
a
few
votes
one
way
or
the
other.
F
So
we
can
kind
of
just
commit,
make
a
decision,
and
then
the
separate
thing
is
that
he's
he
filed
an
issue
this
morning
about
adding
specs
sort
of
natively
to
the
website
rather
than
having
them
like
link
off
into
github,
and
I
think
you
know
his
point
of
view
is
that
we
should
have
the
website
be
the
place
where
people
learn
about
things
and
and
not
bring
people
off
that
site
elsewhere.
F
I'm
not
sure
I
agree
with
that,
just
because
it
seems
like
every
spec
change
is
going
to
like
require
a
you
know,
something
you
can't
synchronize
and
get
to
the
website
and
they're.
Inevitably,
gonna
fall
out
of
date,
and
so
on
so
forth.
So
I'll
admit
to
my
bias
there,
but
I
I
said
I'd
bring
it
up
so
here
I
am
bringing
it
up
and
I'm
curious
if
people
think
it's
important
for
the
spec
to
be
like
prettified
and
on
the
website
with
proper
brand.
D
G
We
have
with
the
rest
of
the
documentation
there.
There
is
a
mechanism.
What
we
decided
in
general
is
you
know:
docs
can
remain
in
the
github
repos
and
there's
a
tool
for
pushing
those
docs
up
to
the
website.
When
we
hit
a
major
version,
you
know
when
the
release
occurs.
Basically,
and
we
we
could
do
something
similar
for
the
spec,
which
is
just
I
mean
we
do
release
the
spec
monthly
now,
and
so
what
appears
on
the
website
could
just
be
the
the
latest
release
of
the
spec
but
yeah.
D
D
B
Yeah
for
what
it's
worth
cloud
events
has
a
similar
problem
that
we
do
and
they
just
have
a
link
right
in
the
header
of
their
website.
That
links
out
to
the
github
specification.
C
B
D
F
Yeah
I
mean,
I
think,
it's
fair
to
say
that
an
end
user.
Probably
would
I
mean
I
I
would
if
I
was
googling
it
I'd
rather
go
there
than
the
github,
but
I've
totally.
I
mean
I
didn't.
I
guess
I
did
sort
of
bias
things,
but
I'm
totally
in
agreement
that
things
that
are
changing
frequently.
F
H
G
Seo
is
the
reason
they
want
to
move
the
blogs
to
the
website
by
the
the
blogs
are
well
read,
and
right
now
that
funnels
everything
off
onto
medium
also
medium's
a
terrible
platform
for
publishing
the
kind
of
stuff
we
want
to
do.
G
Roadblocks,
yeah,
you
know
really
basic
things,
and
so
the
plan
is
to
move
the
blog
to
the
website.
You
know
use
seo
redirects
to
redirect
everything
over
there
and
use
that
to
help
drive
the
the
google
ranking
of
the
of
the
website.
C
G
D
C
G
D
B
Yeah,
so
I
I
attended
several
contributor
strategy
sessions
because,
honestly,
like
the
the
technical
talks,
are,
I
I
feel
like
tech
is
my
strong
point.
So
I
was
trying
to
shore
up
weaknesses
here
and
I
I
attended
several
of
these
talks
and
they
had
several
good
suggestions
for
like
maintaining
large
open
source
projects
that
I
thought
I
would
bring
back
here.
B
Not
just
what
are
the
levels
like?
We
already
have
pre
defined
like
what
are
the
contribution
levels,
I'm
a
contributor
or
maintainer
or
whatever,
but
measurable
goals.
How
do
I
make
it
to
the
next
level?
So
if
I'm
a
community
member,
how
do
I
become
an
approver?
If
I'm
an
approver?
How
do
I
become
a
maintainer
and
what
are
the
measurable
like
goals
if
you
want
to
move
up
that
ladder?
B
They
also-
and
the
third
item
here
strongly
recommend
creating
an
emeritus
status
or
emeretus,
I'm
not
sure
how
it's
pronounced
for,
like
x,
maintainers
before
it's
needed,
because
a
natural
part
of
the
life
cycle
of
maintenance
is
stepping
down,
and
if
you
never
have
anyone
step
down,
then
the
project
will
stagnate
by
definition
right
we're
all
going
to
be
80
years
old
one
day,
and
I
hope
I'm
not
still
working
on
this.
B
So
that's
the
contribution
ladder,
there's
a
template
there
and
I'm
happy
to
make
a
pr
for
that.
If
you
guys
all
agree
that
that's
a
good
idea,
the
only
thing
is
we
need
to
agree
on
what
are
the
measurable,
like
you
know,
what
are
the
the
the
steps
so
like?
I
don't
want
to
just
make
up
numbers
and
say:
oh,
if
you
have
this
many
contributions,
then
then
you
can
become
an
approver.
I
think
we
need
the
gc
at
least
to
weigh
in
on
that.
H
E
G
Can
I
suggest
a
thing
that
we're
lacking
is
a
a
like
schedule
where
we
poke
the
maintainers
like
if,
as
a
project
every
quarter,
you
know
we,
we
did
a
community
review
as
like
an
official
thing
that
we,
you
know
the
the
part.
That's
I
think
hard
is
the
maintainers
actually
doing
a
review
of
members
and
then
like
moving
people
up
the
contribution
ladder.
F
H
Do
you
have
this
in
your
company
alolita,
do
you
have
a
timeline
for
when
people
should
be
promoted?
No.
K
G
G
Of
weird
issue,
then
they
should
just
bump
them
up
and
part
of
it
is,
I
think,
member
maintainers,
just
don't
have
it
in
their
minds
to
to
do
that.
Yeah.
H
Mean
that
constantly-
and
I
know
the
reason
why
I'm
commenting
here
is
because
I
know
you're
frustrating
on
me
and
I
I
can
tell
you,
I
can
tell
you
that
I'm
not
gonna
lower
the
bar
for
for
any
maintainer
just
because
it
comes
from
any
company
or
anything,
and
I
don't
know
but
bogdan.
We.
H
We
have
three
who's:
the
third
alex
from
livestream,
oh
okay,
okay,.
F
Many
of
them
are
probably
qualified.
I
would
suggest
we
don't
need
to
necessarily
change
our
bar,
but
we
do
need
to
change
our
process
for
identifying
people
who
are
talented
and
moving
them
into
a
position
of
greater
control
and
authority,
because
right
now
we
are
literally
bottlenecked
on
this
as
a
project,
and
it's
just
a
self-inflicted
wound
like
it
doesn't
involve
lowering
a
bar.
It
involves
changing
a
process
so
that
we
can.
F
F
Changing
our
process-
and
I
mean
you-
can
I
think
the
bar
should
be
about
the
quality
of
the
people's
judgment.
That's
the
bar
and
the
way
we're
measuring
the
bar
right
now
is
sort
of
arbitrary
and
started.
Whenever
we
started
the
project,
we
should
change
the
criteria.
It's
not
about
lowering
the
bar.
It's
about
making
faster
decisions,
yeah.
F
How
do
we
maintain
our
bar
with
a
different
set
of
criteria
that
we
can
satisfy
more
quickly
like
if
you
had
a
really
talented
person
join
your
team?
I'm
sure
you
can
identify
that
they're
amazing
pretty
quickly.
We
should
still
be
seeking
those
people
for
technical
judgment.
We
have
to
find
a
process
that
gets
the
answer
much
more
much
more
quickly
than
the
current
that's
fair
enough,
but
based
on
the.
H
F
G
I
G
F
G
Because
I
think
we
want
to
respect
the
tc's
desire
to
you
know,
keep
the
the
quality
high
and
to
not
be
looking
like
they're
playing
favorites
and
doing
things
like
that.
But
at
the
same
time
you
know
do
it
do
what
we're
asking
of
like
when
we
do
identify
people
who
would
obviously
be
good,
have
the
ability
to
move
them
up.
H
Yeah
and
sometimes
it's
it's
a
matter
of
individual
six,
pushing
requirements
like
what
expected
and
it
actually
works
both
ways.
It
works
for
people
to
understand
what
see
what
it's
needed
from
them,
but
also
this
person
can
go
back
to
employer
and
say
like
this
is
the
thing
I
need
to
do
to
become
a
maintainer.
Can
you
sponsor
all
the
things,
and
sometimes
it's
not
clear
from
employer
like
I
mean
you're
spending
like
two
hours
of
your
week
to
this
project?
G
Yeah,
maybe
we
can
create
a
feedback
form
to
throw
out
to
the
community
on
this
issue
too.
D
I
Also,
one
thing
too:
if
we're
worried
about
checking
things
in
that
will
break
things,
it's
more
of
a
process.
Failure
on
us
and
not
necessarily
with
individuals
right
like
either
have
gaps
in
testing
or
something
else
there
that
could
catch
issues
because,
like
I
think
it's,
I
think
we
almost
expect
people
to
be
super
heroes
when
they're
doing
code
reviews
to
catch
like
every
potential
bug.
It's
like
more.
We
should
make
sure
that
we
have
guardrails
in
place
to
catch
those
things
when
people
do
check-ins
and
so.
G
Yeah
so
that
sounds
like
we
gotta
we
gotta
go,
but
maybe
we
can
invite
the
tc
to
the
next
gc
meeting
next
week.
Maybe
that's
the
simplest,
simplest
thing
and
just
have
next
week's
meeting
be
focused
on
this
particular
issue.
Should
that
be
public
meeting
I
mean
these
meetings
are
are
published
on.
You
know.
F
G
B
H
It
actually
maybe
not
good
next
week,
since
it's
election
time
and
stuff
so
yeah,
maybe.
H
B
Yeah
first
day
of
new
new
gc
members
is
the
end
of
the
month.
I
believe
the
voting
will
be
announced
on
29th.
If
I.