►
From YouTube: 2020-09-14 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
B
E
B
D
E
Sure
I
I
put
in
an
agenda
item
to
talk
about
where
we
are,
and
the
recent
issue
scrubbing
and
I'll
also
go
over
the
status
of
the
issues
that
are
currently
open
for
for
specber
now
into
ga.
And
then
I
got
another
item
to
request
for
more
information
on
the
compliance
matrix.
E
I'll
share
a
screen,
and
we
can
start
by
saying
last
week,
went
through
another
issue
scrubbing
session
thanks
to
tigre
and
carlos
army,
to
help
have
a
look
over
the
p2
and
p3
issues
to
see
which
ones
could
be
moved
to
after
ga
and
then
also
have
a
hard
look
at
all
the
p1
issues
to
make
sure
that
they
represent
all
the
ones
that
we
need
to
take
care
of
in
order
to
freeze
for
the
trace
part
of
the
spec.
E
And
this
is
also
working
within
the
context
of
morgan.
Your
blog
post,
we're
currently
in
this
actually
post
first
week
of
september
and
following
on
and
I'm
assuming
that
technical
committee
has
the
ability
to
make
some
video
velocity
velocity
decisions
in
order
to
continue
on
that
being
said,
the
p1
issues
are
still
being
used
to
represent,
what's
needed.
For
the
spec,
but
instead
of
just
choosing,
which
ones
should
be
ones,
that's
going
to
block
for
the
spec
trace.
Freeze
it's
now
looked
at
with
the
lens
of
if
the
p1
is.
E
If
the
issue
is
necessary
for
the
functionality
for
the
language
implementations,
that's
the
line
for
p1
and
p2
and
p3
considered
okay
to
still
have
a
bunch
open
if
they
happen
to
not
be
addressed.
If
all
the
p1
issues
are
closed,
that's
needed
for
freezing
the
spec,
so
that's
the
lens
upon
which
we
had
done
the
triaging
and
take
a
look
at
at
the
p1
p2
p3s.
E
With
that
also
going
with
the
assumption
that
we
will
not
merge
after
ga
issues,
we
will
be
only
taking
a
look
at
prs
that
are
required
for
ga
associated
with
an
issue
that
says
required
for
gi.
So
that
being
said,
let's
see
the
summary
of
what
we
have
on
the
spec
burn
down
is
in
total
we
got
65
open
issues,
p1
p2p3s,
we've
knocked
out
21
issues
either
by
closing
them
or
by
pushing
them
into
after
ga.
E
So
that's
like
we're
able
to
make
some
hard
decisions
and
with
the
numbers
in
that
sense,
in
progress
we
have
six
done.
We
have
65
so
like
we're
coming
to.
You
know,
like
I
don't
know
over
the
cresting
over
the
hill.
I
don't
know
if
that's
okay
but,
like
you
know
it's
hard
to
tell
because
a
lot
of
the
p
ones
we've
been
concentrating
a
lot
of
our
energies
on.
E
It
looks
like
that
we're
making
progress
on
a
lot
of
important
decisions
for
p
ones,
but
we
still
have
stuff
to
do,
and
so
the
breakdown
of
what
we
have
for
p1
is
12
items
to
do
three
in
progress
and
13
done
so
more
than
just
the
trace
spec
issues.
Let
me
see
I'll
go
to
this
one.
E
Oh
I'll.
Sorry
to
this
one,
which
has
the
search
criteria
to
put
in
12
open
you'll,
see
that,
like
after
going
through
the
p1
issues,
it's
not
just
spec
trace.
It's
also
spec
context,
which
was
identified
as
needed
in
order
to
lock
down
the
trace
portion
of
the
spec
issue.
So
that's
why
this
number
is
12.,
because
they
cover
a
lot
of
these.
Some
of
them
from
my
session
with
carlos,
looks
like
it's
not
a
huge
amount
of
work,
but
some
of
them
are
still
pretty
big
works,
such
as.
E
Like
the
error,
this
one
removes
spin
stats
from
api,
this
one's
still
in
progress,
so
they're
of
different
sizes
of
amounts
of
work.
So
don't
let
the
numbers
scare,
you
necessarily.
B
Do
all
p1's
have
assignees.
B
B
B
E
G
B
Saying
that
it
would
probably
make
sense
to
look
at
the
issues
that
don't
have
any
prs
that
resolve
them,
yet
those
would
be
more
risky
right
if
there
is
nothing
that
that
is
planned
to
cross
all
the
issue
then-
and
we
have
quite
a
few
of
those
right
that
are
not
even
started
yet.
So
that's
slightly
concerning,
I
guess.
E
Okay,
yeah,
that's
a
good
point!
You
don't
have
to
solve
this
right
now,
but
just
a
quick
stats
on
that.
So
of
the
14
one,
two
three
four
five
have
prs.
That
means
nine
of
them
are
are
missing
in
that
sense,.
E
E
I've
already
got
my
eye
looking
at
like
how
we
could
break
down
the
metrics
issues.
So
that's
what
I'm
working
on
a
bit
in
parallel
in
order
to
analyze
how
things
are
are
going
in
terms
of
what
spec
issues
need
to
be
addressed
and,
as
you
see,
this
search
criteria
is
everything
without
the
metrics
label.
E
This
is
just
a
preview,
but
like
the
upcoming
metrics,
p1
has
got
seven
open.
So
that's
not
addressed
in
in
this
list
of
the
first
milestone,
I'm
trying
to
get
of
our
nearest
milestone.
H
E
Trying
to
get
the
trace
api
locked
down
and
frozen,
but
also
further
on
downstream
I'm
going
to
the
next
agenda
item,
which
is
after
the
trace
api,
is
frozen
for
the
language
six
to
work
on
the
implementation
of
such.
I
think
I
need
some
more
help
here.
Tigran.
I
think
you
filed
a
bunch
of
issues
in
order
to
fill
out
this
table
initially,
which
is
fantastic,
and
I
think
everyone
went
to
town
and
like
put
all
the
plus
signs
and
minus
signs
and
what
they
could,
which
is
really
really
helpful.
E
Since
then,
I
saw
context
propagation
get
added
after
the
trace
table
is
added,
so
I
think
these
need
to
be
addressed
as
well
in
order
to
figure
out
what
the
status
is
in
order
to
figure
out
like
how
much
time
until
implementation,
and
then
following
that,
we
will
have
metrics
fleshed
out
in
order
to
figure
out
like
what
the
languages
need
to
do.
In
order
to
finish
up
the
metrics.
B
E
It
helps
numerically,
but
some
of
these
are
like
unknown
like
how
much
time
does
this
take?
How
much
time
does
this
take,
but
it's
comforting
to
see
majority
of
the
rows
or
plus
signs.
E
But
I
think
this-
this
is
also
related
to
the
issue
that
alex
had
brought
up
from
relay
to
the
python
sig
a
few
weeks
back.
Is
that,
like
help,
could
also
be
used
to
implement
some
of
these
missing
items
in
the
python
sig
else?
We
we
just
work
within
the
timelines
of
what
resources
we
have
thus.
B
E
B
Tells
me
is
that
we
probably
don't
need
well
okay,
six
months
after
freezing
the
spec,
to
have
the
implementations
ready.
That's
why
I
think
this
is.
This
is
important
for
us
to
know
how
much,
how
much
time
we
need
to
after
the
freezing
of
respect,
how
much
time
we
need
to
before
the
before
the
gym
is.
Actually
you
know.
So
this
tells
me
probably
a
couple
of
months,
maybe
a
reasonable
time.
E
D
Propagation
all
right,
thank
you
for
the
update
any
other
thoughts
or
discussions
in
our
ga
progress.
D
From
anyone
else,
nope
okay,
next
up
is
ted
merging
errors
proposal
today,
unless
there
are
no
final
objections,.
A
Yeah
just
wanted
to
do
a
last
call
here.
This
proposal
has
enough
approvals
at
this
point,
but
I
do
want
to
make
sure
the
maintainers
are
aware
of
this
change,
and
so
it
doesn't
surprise
people
there's
been.
You
know
a
lot
of
back
and
forth
around
status
codes
and
errors,
and
how
do
we
manage
these
things?
A
The
air
working
group
came
to
what
I
think
is
a
simple
solution.
That
is
not
very
disruptive.
A
A
End
users
can
set
it
to
ok
if
they
wish
and
error
and
we're
to
differentiate
between
instrumentation
and
end
users,
we're
adding
a
new
field
called
status
source.
The
default
is
instrumentation,
so
by
default,
anything
being
set
is
presumed
to
come
from
the
instrumentation
like
auto
instrumentation,
we've
added
or
more
generic
instrumentation,
and
then
we're
adding
a
new
source
user,
which
indicates
that
the
status
actually
represents
a
subjective
decision
by
the
person.
A
Who
has
something
directly
to
do
with
this
particular
deployment
of
this
particular
application.
So
that's
to
help
analysis
tools
be
able
to
choose
whether
they're
overwriting,
the
status
code
or
whether
they
should
respect
the
status
code.
So
if
it's
instrumentation-
and
you
have
other
analysis,
you're
doing
you
can
ignore
that.
But
if
it's
set
to
user,
it's
suggested
that
you
use
that
as
an
override
that
the
end
user
said
specifically,
this
span
is
okay.
A
A
If
you
have
objections
to
this,
you
know
please
raise
them
quickly,
but
I'd
suggest
going
and
reading
the
otep
first
before
digging
into
it.
B
Just
one
more
comment:
this
was
a
highly
debated
topic.
I
think
this
is
the
third
or
even
fourth
proposal
to
address
the
issue,
and
I
saw
less
activity
on
the
issue
than
I
saw
on
the
previous
ones.
I
guess
people
maybe
got
tired
of
discussing
the
same
topic
over
and
over,
but
it's
it's
still
important
right
that
we
make
sure
we're
not
we're
merging
something
that
at
least
does
not
have
strong
objections.
B
So
I'd
like
to
encourage
everybody
who
did
participate
in
the
previous
proposals
to
at
least
have
a
look
at
what
this
one
suggests
to
do
and
and
comment
but
comment.
If
you
have,
let's
say
strong
objections
right.
Hopefully,
hopefully
we
can
afford
it
to
this.
One.
A
A
But
I
do
think
this
may
be
the
last
big
otep
coming
in
before
the
freeze,
and
so
this
will
generate
some
new
p1
spec
issues,
but
it
will
also
remove
some
existing
p1
spec
issues.
It
sort
of
replaces
some
of
the
stuff
that's
already
in
there.
D
Sweet
thanks
ted.
Do
we
have
any
other
topics
for
today
I
mean
we'll
go
into
depth
the
in
the
specs
sig
tomorrow,
on
and
on
the
outstanding
spec
issues
and
the
the
steps
we're
taking
to
close
them.
But
are
there
any
topics
we
need
for
in
front
of
all
the
maintainers
today.
F
Yes,
remember
the
last
gc
meeting
the
morgan
that
had
especially
you,
you
promised
to
talk
about
the
health
wanted
and
first.
G
First
goodbyes,
it
wasn't
me,
actually,
I
think
it
was
ted
or
sergey.
I
think
ted
promised.
F
A
That,
oh
yeah,
so
we're
going
around
there
is
a
mentorship
program.
I
think
it's
called
open
bridge.
D
A
There
is
a
mentorship
program.
I
think
we
are
a
little
late
to
officially
apply
for
it
and
honestly
we're
kind
of
buried.
I
don't
know
if
maintainers
or
anyone
right
now
would
want,
would
want
to
mentor
basically
interns
and
new
people
just
to
be
clear.
We've
done
community
bridge
in
the
past.
It's
just
a
mentorship
program
where
we
sign
up
and
then
we
create
you
know,
help
wanted
and
good
first
issues
and
then
people
from
community
bridge
will
come
in
and
try
and
tackle
those
issues.
A
So
it's
just
the
way
to
get
younger,
more
junior
programmers
experience
an
open
source
project
like
open
telemetry,
so
we're
too
late
to
actually
apply
for
that
officially,
but
we
felt
it
would
be
good
to
possibly
start
just
leveraging
those
two
tags
good
first
issue
and
help
wanted
just
to
get
in
the
rhythm
of
being
a
more
open
and
easy
to
join
project.
A
It's
such
a
big
project
and
it's
it's
got
so
much
detail,
it's
very
hard
for
new
people
to
come
in
and
be
helpful
and
so
help
wanted,
and
good
first
issue
are
ways
that
we
can
get.
Let
newcomers
participate
and
kind
of
get
a
handle
on
things.
So
that's
the
request
is
maintainers.
A
If
you
could,
since
we've
got
lots
of
time
on
this
meeting,
if
you
could
use
the
remaining
time
here
to
just
go
through
your
backlog
and
look
at
things
that
are
one-offs
things
that
someone
could
tackle
if
they
were
new
to
the
project,
that'd
be
good
first
issue
and
help
wanted
for
things
that
are
like
we
would
be
nicest,
but
you
know
the
the
core
group
is
probably
not
going
to
get
to
because
we're
so
focused
on
on
the
the
p1s.
A
So
so
that's
the
request.
Just
just
try
to
add
those
to
your
to
your
backlog
as
labels.
B
I
guess
shameless
clock
here
in
the
collector.
We
have,
I
think,
a
second
72
health
wanting
issues.
Nice.
A
Yeah,
if
you're
doing
this,
this
is
great.
It's
just
a
reminder
that
those
those
actually
are
helpful
and
github
actually
does
extra
things
in
the
ui
with
those
two
issues,
so
it
surfaces
them
a
little
bit
more.
F
Yeah,
it
was
not
about
any
any
rep,
particularly,
but
across
the
entire
org.
We
should
start
using
it
more
consistently
and
encourage
people
newcomers
to
focus
on
some.
Some
things
that
are
will
help
them
to
to
get
more
familiar
with
the
code
base
and
have
a
starting
point.
A
Yeah
longer
term
we've
been
trying
to
think
up
diversity
and
inclusion,
initiatives
that
we
can
do
and
one
that
I'm
excited
about
would
be
to
figure
out.
You
know.
In
the
past,
I've
participated
in
things
like
railsbridge,
which
is
teaching
women
to
code
specifically
rails,
and
so
nothing
specific
right
now.
A
But
it's
not
clear
to
me
if
there
are
those
kind
of
dni
workshops
for
ops
work
and
for
observability
and
some
of
the
stuff
that
we're
doing
here
so
longer
term
once
we're
through
this
ga
thing.
That's
something
I'll
be
thinking
about.
So
that's
just
a
heads
up.
If
other
people
are
interested
in
in
how
we
could
be
more
involved
in
in
mentorship,
that's
something
I
want
to
want
to
push
on,
but
post
ga
we
have
enough
on
our
plate
right
now,.
H
Ted,
this
is
alita,
I'm
definitely
interested
in
helping
you-
and
I
have
you
know-
worked
with
the
different
cncf
groups,
as
well
as
with
the
apache
software
foundation
on
different.
You
know,
mentorship
programs,
so
I'll
ping,
you
offline.
C
Yeah,
sorry,
I
have
a
small
thing
to
mention
sorry
for
sure
calling
from
my
phone,
but
it
has
no
problem.
There
was
a
small
change
that
I
could
like
maintain
there
specifically
to
take
a
look
at.
I
don't
have
the
link
now,
but
it's
basically
about
probably
is
having
context
as
parent
for
expansion
baggage,
which
was
previously
called
correlation
context.
C
That's
a
change
that
was
proposed
by
christian
from
dana
trace
and
I
think
bogdan's
commented
on
that
that
it
could
be
a
minimalistic
api,
but
they
would
like
to
have
maintainers.
You
know
give
their
opinion
on
this.
As
I
said,
context
would
be
now
the
only
source
of
parenthood.
So
let's
take
a
look
and
we
can
discuss
the
technical
details
tomorrow.
C
A
Oh,
I
was,
I
was
gonna
jump
in
and
explain
it,
but
go
ahead.
A
One
thing
we're
concerned
is
this
project
started
with
just
tracing
and
now
we've
added
a
variety
of
things
and
we're
trying
to
pull
context
out
into
its
own
separate,
lower
level,
fundamental
that
all
these
different
signals
are
built
on
top
of,
and
one
thing
we're
a
little
concerned
about
is
whether
or
not
spans
can
get
decoupled
from
the
rest
of
the
context.
So
there's
other
stuff.
In
that
context,
like
baggage
metrics
may
start,
you
know
holding
stuff
in
there.
A
New
things
might
go
in
there
and
there
are
some
span
operations
around
parentage
and,
and
you
know,
moving
between
threads
and
following
the
work
and
we're
a
little
concerned
that
the
span
may
move
somewhere
and
the
context
may
decouple
from
it
and
not
follow
it.
And
so
that's
at
the
core
of
this
is
to
really
investigate
that
in
in
your
language
and
make
sure
that's
not
something
that
can
happen
and
we
think
the
just.
When
we
were
working
on
otep
66,
that
giant
thing
and
really
digging
into
context.
A
It
seemed
like
this
solution
was
to
use
spans
less
more
indirectly
when
it
comes
to
things
like
parentage
and
and
moving
things
around,
and
to
to
actually
lift
that
up
onto
the
context,
object
itself
or
whatever
that
representation
is
in
your
language.
A
So,
if
you
say,
span
takes
a
context
as
a
parent
that
that
gives
more
freedom
to
the
sdk
under
their
hood
to
do
various
things
and
if
you
are
moving
between
threads
or
having
to
follow
the
work
in
some
tricky
way
to
have
those
operations
actually
move
the
context
around
potentially,
rather
than
just
the
span.
If
the
intention
is
for
baggage
and
everything
else
to
to
follow
along.
A
So
we
think
that's
just
a
place.
Maybe
we
just
haven't
really
been
looking
at
clearly
enough
after
we
made
these
other
changes,
but
we
don't
want
to.
We
don't
want
a
ga
with
with
an
oopsie
like
that
in
there.
So
so
there's
some
concern
that
that's
a
genuine
issue
in
different
languages.
We
have
to
look
at.
D
A
I
kind
of
feel
like
it
should,
I
feel
like
we
need
to.
We
definitely
need
to
look
at
this
and
make
sure
it's
at
minimum.
Not
a
problem,
but
my
suspicion
is,
is
that
it
probably
is
in
some
languages
and
go.
It
isn't
because
go
has
you're
manually
passing
a
context
around
anyways,
but
in
these
other
languages
the
context
is
sort
of
this
thing
in
the
background
and
so
whether
that
those
things
can
get
unlinked
or
decoupled
in
some
way,
I
think
investigating
that
is
a
p1.
F
So
I
know
I
know
about
this
issue
and
I
I
I
do
agree
with
everyone
that
we
should
make
sure
that
every
time
when
we
propagate
we
pass
the
context,
I
do
understand
that
as
a
parent,
probably
passing
the
context
is
the
safest
thing
and
probably
is
not
gonna
cause
any
problem.
There
are
some
follow-ups
that
concern
me,
which
is
inside
the
tracing.
F
For
example,
people
wanted
to
change
the
sampler
api
to
accept
the
context
instead
of
accepting
the
current
span
and
so
on,
like
that,
I
think
we
have
to
decouple
things
like
when
it
comes
to
propagation
and
stuff
versus
things
internally
in
the
tracing
package
itself.
So
anyway,
what
I'm
trying
to
say
is.
F
I
do
agree
with
this
idea
that,
on
the
surface
on
the
on
the
api
level,
when
it
comes
to
propagation
patterns
and
stuff,
we
should
use
the
context
to
ensure
that
people
are
are
getting
familiar
with
this
and
are
not
making
mistakes,
but
inside
the
package
itself
we
should
not.
We
should
not
over,
let's
say
overusing
the
context,
sometimes.
A
But
you
do
remind
me
on
a
separate
issue:
sampling,
I'm
worried
about
sampling,
I've
been
running
a
sampling
working
group
and
it's
kind
of
different
people
showing
up
each
week,
and
my
main
concern
is
that
I'm
not
feel
like
I'm
not
hearing
feedback
from
people
who
need
a
custom
sampling
in
order
for
their
analysis
system
to
work.
A
A
I
think
my
concern
is
that
it's
just
we
need
actual
implementations
at
this
point
to
understand
whether
it
has
the
features
we
need
or
not.
So
my
request
is
for
people.
This
is
you
know
aws
azure,
anyone
else
honeycomb.
Anyone
who
I
know
is
is
gonna
need
a
sampler
like
this.
A
E
Except
I've
changed
the
corresponding
issue
to
the
pr
from
p2
to
p1.
Who
should
I
assign
this
to.
C
I
suggest
we
talk
about
that
tomorrow,
unless
somebody
wants
to.
You
know,
take
this
item
because
there's
there
are
already
implementations,
we
need
to
validate
that.
This
is
correct
in
other
languages,
because
in
java
we
have
that.
But
if
somebody
wants
to
take
this
now
feel
free
to
raise
your
voice.
Otherwise
we
can
assign
it
to
somebody
tomorrow.
A
It's
almost
like
an
issue
that
needs
to
be
put
into
every
every
implementation
backlog
to
to
check
this
right
like
because
whether
it's
less
a
spec
issue,
I
mean
it
might
turn
into
a
spec
issue,
but
it's
it's
also
that,
like
this
needs
to
get
cross-checked
in
every
implementation,
that's
going
to
ga
soon.