►
From YouTube: 2021-03-15 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
B
B
B
All
right,
well
that
looks
like
a
good
quorum.
So
morgan
is
out
this
week,
but
I'm
happy
to
run
the
agenda
as
we
started
last
week,
we're
gonna
try
to
kick
this
meeting
off
with
a
check-in
from
various
sig
leads
who
attend.
So
this
is
just
a
brief.
B
You
know
one
two
minute
overview
of.
What's
going
on
in
your
sig,
any
calls
to
action.
Help
requests
quick
ones
can
be
made
here.
B
So
I'm
terrible
at
picking
people
do
people
want
to
just
start
chiming
in
otherwise
I'll
start
calling
names.
D
D
E
E
No,
no,
nothing
really
significant.
Just
you
know
a
good,
a
good
amount
of
adoption
use
user
feedback.
You
know
little
little
issues.
So
that's
good.
B
Some
awesome:
do
we
have
someone
here
from
javascript.
C
Yes,
so
with
that
javascript
we
released
the
last
week
we
discontinued
version
one
for
api,
and
this
week
we
basically
continue
with
instrumentation.
There
is
one
more
instrumentation
that
needs
to
be
converted
after
this
we'll
be
able
to
start
removing
all
the
plugins
and
preparing
towards
release
candidate
for
the
sdk.
C
I
mean
we
basically
are
going
towards
releasing
the
sdk
rc
candidate
also,
but
to
happen
to
make
this
happen,
we
need
to
convert
one
more
plugin
from
plugin
to
instrumentation,
then
remove
all
the
updated
plugins
and
so
on
and
yeah
after
this.
I
think
we'll
be
good
to
to
make
it
happen,
but
probably
not
this
week
yet.
B
Okay!
What
about
python
see
some
python
people.
F
Yeah
well
we're
just
working
through
our
rc2
issues,
we're
aiming
tentatively
to
try
to
get
a
release
by
the
end
of
this
week.
So.
B
Congrats,
that's
great
pride,
great
progress.
A
A
B
Sweet,
do
we
have
anyone
from
the
chicken.
A
Doesn't
seem
to
be
the
case,
but
I
I
can't
speak
for
cj,
because
I
was
in
the
sick
meeting.
I
believe
donald
is
currently
working
on
the
1.10
release.
There
are
many
improvements
and
also
doughnut
is
joining
the
matrix
prototype.
A
B
A
B
B
Okay,
go
check
to
check
in.
G
G
B
Awesome
and
c,
plus
plus
already
checked
in
ruby
matt
want
to
check.
H
In
yeah,
we're
working
towards
rc1
there's
two
open
issues
in
the
milestone.
I
think
both
of
those
have
draft
prs
in
progress.
B
And
swift
yeah,
I
see
bryce
is.
I
On
the
call,
hey
howdy,
let's
see
so
we
had
a
chat
last
week,
looks
like
I
think.
Maybe
the
big
topic
is
v1.
Readiness
haven't
really
made
any
progress
towards
that.
Yet
so.
B
Yeah,
I
actually
think
there's
a
request
for
action
from
this
greater
group.
As
long
as
people
are
here,
swift
needs
more
reviewers,
so,
besides
the
the
technical
committee
helping
them
go
through
the
1.0
checklist.
B
Ios
is
a
hugely
important
platform.
I'm
sure
many
people
on
this
call
work
for
a
company
that
would
love
to
have
really
good
ios
instrumentation.
We
do
need
more
people
in
that
working
group,
in
particular.
Just
reviewing
the
work.
That's
been
done,
since
it's
been
a
very
small
small
crew.
That's
been
working
on
it.
B
B
So
let's
just
take
a
minute
right
now
and
put
on
your
calendar
to
to
reach
out
for
that
or
your
to-do
list.
B
B
B
It's
like
that
scene
from
the
princess
bride.
It's
like
I've
taken
an
hour
of
your
life.
B
B
B
The
content
of
that
will
be
markdown,
specifically
hugo
style
markdown,
which
means
using
the
the
front
matter
that
hugo
provides
so
that
it
pops
onto
our
website.
It's
also
possible
to
use
the
various
hugo
features
around
templating
and
blocks,
and
this
will
get
pulled
in
whenever
there's
a
pr
made
to
the
it
looks
like
sigs
just
open
a
pull
request,
and
then
it
will
get
applied.
Automatically
sounds
like
that's
that's
the
plan.
B
This
will
just
be
pulling
in
from
master.
That's,
I
believe
how
the
automation
will
be
set
up
and
so
links
to
prior
documentation
will
need
to
be
done
as
links
to
the
github
version,
for
the
time
being,
which
I
should
say.
B
The
first
thing
that
comes
to
mind
here
is,
if
we're
going
to
say
old
versions
of
the
stocks
live
on
github.
That
kind
of
goes
counter
to
the
idea
of
making
a
lot
of
use
of
hugo
features,
as
it
means
older
versions
of
the
docs
won't
be
very
readable.
B
Yeah
pardon
my
my
old
language.
Yes
main
that's
correct,.
B
B
B
Okay,
I
see
a
thumbs
up
from
riley
no
comments
at
this
time.
The
the
main
thing
that
that
I
notice
is
links.
So
that's
my
one
question
here
is:
how
do
we
handle
links
if
we're
going
to
have
links
between
pages
of
documentation?
B
I
think
links
to
images
and
other
stuff
get
a
little
tricky,
so
just
from
prior
projects,
I
recall:
that's
that's
one
of
the
the
more
annoying
things
to
figure
out,
but
maybe
if
we
keep
our
docs
fairly
simple
and
straightforward
as
far
as
what's
going
to
go
on
the
website,
it
won't
be
too
much
of
a
problem
so
anyways,
that's
the
update.
Austin
is
on
vacation
this
week,
so
there
probably
won't
be
any
further
movement
on
this,
but
please
chime
in
to
this
issue.
If
you
have
any
questions
or
comments.
J
Yeah
so
far,
there's
only
this
one,
it's
very
minor.
Please
take
a
look,
I
suspect
you
know
it's
about
trace
id
radio
description
that
users
will
be
getting.
I
think
it's
very
minor,
but
it's
so
minor
that
maintainers
may
be
overseeing
that
one.
So
just
please
check
it
out.
Nothing
else.
On
that
front.
J
B
K
B
And
I
see
bogdan's
joint
call
just
hopping
back
to
the
sig
check-ins.
We
didn't
have
a
java
person.
Do
you
have
a
quick
java
check-in
for
us
ogden.
L
Not
too
much,
we
just
merged
a
bunch
of
pr's
and
we
have
huge
amount
of
questions
and
things
from
the
community,
which
is
a
good
sign.
But
a
lot
of
questions
and
people
are
already
integrating
the
the
open
telemetry
in
projects
like
college
db
and
couple
of
others.
Awesome.
B
B
B
Bogdan
is
there
any
themes
from
the
questions
coming
up
that,
like
other
maintainers,
might
want
to
hear
about.
L
B
Yeah
people
super
super
interested
in
the
metrics
part,
okay
moving
forwards,
so
we're
making
good
time
through
our
agenda.
Hopefully
we'll
have
time
for
a
little
brainstorming
before
we
go.
B
I
just
had
a
quick
item,
so
we're
kicking
off
these
new
initiatives,
so
convenience
api,
instrumentation
user
research,
starting
to
gel
up,
I'm
gonna
try
to
avoid
talking
about
the
details
of
those
in
this
meeting,
just
based
on
feedback
trying
to
keep
that
to
the
spec
meeting
so
that
people
know
what
meeting
to
attend
if
they're
trying
to
follow
along.
So
I'll
have
more
details
about
that
stuff
tomorrow.
B
My
one
question
for
maintainers
is
you
know
with
these
initiatives?
We
do
need
places
to
talk
about
this.
We
only
have
one
spec
meeting.
It
seems
like
adding
more
meetings
is
like
really
getting
burdened
some.
So
my
thought
was
for
these
initiatives.
We
could
try
running
them
through
slack,
just
creating
a
slack
channel
and
taking
up
time
in
the
the
the
primary
spec
meeting
to
discuss
this
work,
but
otherwise
discussing
things
through
slack,
maybe
more
actively
than
we've
discussed
other
projects.
B
So
I'm
just
curious
feedback
from
this
group.
Since
a
lot
of
this
is
cross
kind
of
cross-domain
stuff
that
I'd
love,
the
maintainers
to
at
least
be
following
not
actively
contributing
to
does
tracking
a
slack
channel
seem
better
than
having
another
meeting
on
your
calendar,
who's
for
or
against
this.
B
M
I
could
imagine
that
both
would
work
well,
so
a
one-hour
meeting
to
get
things
started
and
then
letting
it
sink
in,
and
people
think
make
that
make
up
their
mind
and
comment
on
the
section.
J
B
All
right,
my
hope,
is
that
now
we
do
need
to
keep
some
time
in
that
main
spec
meeting
for
various
issues
that
that
come
up,
because
that's
sort
of
a
grab
bag
of
dealing
with
triaging
the
the
current
spec
backlog.
But
my
hope
is,
with
the
metrics
work
being
the
other
major
lift
moved
out
to
its
own
meetings,
we'll
be
able
to
use
that
time
to
work
on
the
issue.
Du
jour,
so
that'll
be
convenience
and
instrumentation
for
the
beginning.
B
If
it
does
seem
like
we're,
we're
failing
to
make
progress
on
one
of
these
simply
due
to
the
inability
to
reach
consensus
or
move
forward
through
slack
and
github,
we
might
start
looking
to
do
one-off
meetings
or
something
like
that.
B
But
for
now
we'll
see
if
we
can
make
it
work
with
our
current
meeting
load,
because
I
do
feel
like
open,
telemetry's
rather
meeting
heavy.
My
one
request
is,
if
we
do
move
this
stuff
to
slack
that
the
people
that
it
doesn't
just
become
something
that
no
one
responds
to.
So
my
hope
is
that
we'll
be
able
to
keep
track
of
the
slack
channel
and
then
we'll
have
slack
overload.
Instead
of
meeting
overload.
B
B
It's
it's
like
crappy,
slack
honestly
as
far
as
trying
to
have
a
discussion,
because
it's
basically
single
threaded-
and
these
are
issues
where
we're
trying
to
to
bring
a
project
together,
figure
out
who's,
going
to
do
what
get
a
backlog
going
and
chew
through
it
having
a
place
to
discuss
that
going
along,
doesn't
really
match
with
the
discussion
format.
B
In
my
opinion,
because
discussions
a
little
bit
more
like
reddit
with
people
upvoting
and
down
voting
issues,
so
it
seems
more
like
a
place
for
stack,
overflowy
kinds
of
things,
not
running
a
project
kind
of
thing.
That's
that's!
That's
my
personal
experience
with
discussions.
Other
people
might
have
had
other
experiences
if
there
are
good
examples
of
using
discussions
to
run
a
project.
I'd
love
to
see
him,
but
just.
B
Okay,
well,
that's
good,
but
it
still
seems
like
with
the
voting
and
everything
else.
It's
not
it
things
get
a
little
jumbled
there
and
it's
not
clear
where
we
would
put
these
discussions
like
would
we
just
have
one
discussion
thread
on
the
spec
project
or
the
spec
repo?
If
we
have
multiple
discussion
threads,
then
how
do
we
keep
them
together?
B
So
we
were
discussing
in
the
triage
meeting
as
long
as
discussions
are
coming
up.
Is
this
being
a
good
way
to
manage
public
feedback,
especially
for
the
spec
repo?
One
thing
we
want
to
deal
with
is
there's,
like
you
know,
we're
getting
a
couple
hundred
issues
in
there
and
the
way
these
projects
track.
Is
you
end
up
with
thousands
of
issues
that
are
open,
most
of
which
are
ideas
that
someone
said
hey?
Wouldn't
this
be
good
and
the
project
maintainers
say
yeah,
that's
cool!
We're
not
working
on
that
right.
B
When
someone
comes
to
post
an
issue
when
they
see
there's
a
thousand
issues
there,
it
doesn't
give
you
a
lot
of
confidence
if
you're
trying
to
get
up
to
speed
with
what
a
project's
up
to
it's
also
very
difficult
when
you've
got
a
couple
hundred
issues
open
and
one
idea
we
are
experimenting
with
was
to
maybe
see
if
we
can
reduce,
what's
open
in
that
spec
repo
to
just
things
that
are
actively
planned
on
being
worked
on.
So
people
might
open
an
issue.
B
Ask
a
question:
if
it's
a
thing
that
it
seems
like
we
are
going
to
assign
someone
to
and
do
soon
or
as
part
of
one
of
the
tracks,
we'll
try
to
leave
it
there
or
integrate
it
into
one
of
our
work
streams.
If
it's
more,
like
that's
a
good
idea,
but
we
don't,
we
don't
have
the
bandwidth
to
discuss
it
or
think
about
it,
asking
those
ideas
to
go
into
discussions
or
another
repo
or
basically
some
somewhere.
That's
separate
where
people
can
upvote
or
downvote
on
the
ideas
and
then
periodically.
B
Look
at
the
the
things
that
have
gotten
the
top
up
votes
and
have
this
be
a
way
to
kind
of
get
feedback
from
the
community
about
what
kind
of
features
they'd
like
to
see
or
where
they
like
to
go.
This
is
just
an
idea
stage.
You
can
see
bogda
making
a
face,
but
we're
that's
just
one
thing
we're
thinking
about.
So
if
people
have
seen
good
examples
of
of
managing
that
kind
of
stuff
like
how
do
we
take
a
thousand
ideas
and
turn
it
into
something?
B
Triageable
where
the
public
can
kind
of
have
some
say
seems
like
discussions
might
work
because
they
have
like
an
upvote
and
down
vote
feature
so,
but
looking
for
feedback
on
that
front.
So,
since
you
mentioned
discussions,
that's
that's
more.
Where
I've
been
thinking
we
might
want
to
take.
Discussions
is
a
way
to
get
feedback
from
from
the
community,
at
least
for
the
spec.
L
B
B
My
hope
is
over
the
next
month,
or
so
we
can,
as
we
get
the
backlogs
built
out
for
these
other
projects,
we'll
then
be
able
to
do
a
pass
and
kind
of
clean
up
clean
up
the
spec
spec
issue
catalog
in
particular,
moving
away
from
the
nice
required
for
ga
ga
this
ga
that
kind
of
language
since
we're
moving
away
from
a
concept,
technical
concept
of
ga
to
more
like
project-based
initiatives,
and
things
like
that.
B
So
as
part
of
that,
we
kind
of
want
to
review
this
giant
backlog
of
stuff,
that's
sort
of
sitting
there
and
figure
out
where,
where
to
put
these
things,
that
isn't
just
closing
all
the
ones
that
we're
not
going
to
work
on,
because
I'm
sure
there
are
good
ideas
in
there
that
we
want
to
capture.
B
J
So
one
of
the
things
that
was
proposed
is
that
we
actually
allow
people
to
release
official
or
semi-official
packages
through
their
own
organizations,
especially
if
they
are,
like
actual
you
know,
companies
or
contributors
that
you
know
they
are
actually
working
with
us,
but
they
don't
want
to.
J
You
know
to
have
this,
this
fear
of
of
having
everything
go
so
slow
and
not
enough
reviews
and
not
being
able
to
ship
stuff
whenever
they
want,
and
for
this
to
happen,
of
course,
the
the
registry
would
be
like
super
important,
because
this
could
be
the
way
how
you
know
like,
even
if
some
of
these
instrumentation
or
plug-in
components
are
not
in
the
organization,
users
can
always
go
and
check.
You
know,
what's
the
state
and
where
they
live
and
all
that.
So
that's
one
of
the
things.
J
What
that's
one
of
the
approaches,
the
alternative
approaches.
We
try
to
go
with
the
collector
country,
repo,
where
each
project
or
component
has
its
own
code
owners
file,
but
we
had
the
impression
that
this
is
not
going
to
scale
for
instrumentation,
because
there's
only
so
many
plugins
that
you
may
want
to
have
for
a
collector
for
the
collector,
but
for
instrumentation
you
can
have
this.
J
L
So
one
thing
that
probably
will
worth
doing
is-
and
I
think
had
we
discussed
this
six
months
ago
or
something
is
a
process
of
kind
of
what
is
what
is
a
distribution
or
what
is
called
something
that
open
is,
is
open,
telemetry,
compatible
or
or
whatever
was
the
term.
I
don't
remember,
but
it
was
some
some
kind
of
validation
or
stuff
process
for
this.
B
Yeah,
the
the
main
I
I
for
one,
so
we
have
an
instrumentation
project.
That's
gonna,
be
kicking
off
very
soon,
gonna
be
presenting
that
at
tomorrow's
spec
meeting
as
well.
This
is
absolutely
one
of
the
tracks,
so
we
do
need
people
who
are
interested
in
kind
of
sorting
this
out
to
to
show
some
leadership
and
help
maybe
champion
this
particular
track.
B
So
if
anyone
is
interested
in
this
in
particular,
please
ping
me
on
slack-
and
let
me
know
that
you're
interested,
because
we
really
need
people
to
work
on
this.
But
the
thing
I
will
say
for
anyone
want
to
working
on
work
on.
This
is
there's
this
balance
between
auto
instrumentation,
for
every
language
that
we
have.
It's
really,
where
possible,
it's
really
important
for
new
users
to
have
the
instrumentation
installed
automatically
for
them
if
it
can
be,
even
if
it
can't
automatically
be
installed
having
tooling,
that
can
at
least
find
the
instrumentation
for
them.
B
B
Trask.
I
imagine
you
have
you
have
a
way
of
dealing
with
external
instrumentation
getting
added
to
the
agent,
but
if
we're
going
to
say
this
is
a
major
way
that
we
do
it.
You
know
I'm
sure
there
will
be
language
specific
things
like
java,
for
example,
we'll
have
to
work
it
out
so
figuring
out
a
balance
between
security,
which
is
here's
instrumentation,
that
the
end
user
is
going
to
need,
regardless
of
whether
we
think
it's
good
or
not,
they're
going
to
install
the
redis
instrumentation
because
they're
running
redis.
B
So
how
do
we
provide
that
for
them
and
also
provide
some
amount
of
security
advice?
It
seems,
like
we've
got
a
three
tiers
here
that
we
could
work
out.
One
is
we
maintain
it?
It's
part
of
open,
telemetry
core
so
or
open
telemetry
contrib,
so
we're
promising
to
kind
of
keep
on
top
of
it
to
a
certain
degree.
B
There's
I
don't
know
what
you
want
to
call
them
partners
certified
open,
telemetry
providers
whatever,
but
organizations
where
we
feel
like
we
have
enough
of
a
direct
connection
with
or
we've
otherwise
certified
that
we're
gonna
trust
trust.
What
what
they
give
us
in
some
way
and
then
the
third
is
just
the
internet.
B
Anyone
can
add
something
to
the
registry
and
say
here's
my
instrumentation
for
x
and
hopefully
have
that
be
discoverable
in
the
same
way,
the
rest
of
this
stuff
is
discoverable,
but
I
think
we
do
need
to
have
a
way
of
for
users
who
are
becoming
security
conscious,
and
this
is
a
real
issue
with
open
source
in
this
modern
world
open
source.
Has
this
bad
history
of,
like
I
just
download
the
internet?
What
I
just
I
found
this
thing
lying
around
in
the
internet,
so
I
jammed
it
into
my
application.
B
B
So,
if
anyone's
interested
in
helping
me
work
on
this
project,
I'm
going
to
help
work
on
it,
just
because
it's
more
like
a
community
thing,
but
figuring
out
how
we're
going
to
work
this
together,
as
far
as
having
a
plan
improving
the
registry
from
a
technical
perspective,
to
facilitate
it
and
then
figuring
out
for
all
the
different
languages
that
do
have
some
form
of
suggestion
or
auto
installation.
B
As
far
as
instrumentation
goes
like
like
making
sure
what
we're
planning
is
actually
going
to
work
with
all
of
those
different
strategies,
that's
the
project
so
I'll
be
pushing
this
in
other
meetings.
But
please
say
hi
in
the
the
meeting
agenda
right
now
or
pee
me
on
slack.
If
you're
interested
in
working
on
this.
J
B
To
regurgitate
what
I
just
said
into
that
thread,.
B
B
B
So,
to
reiterate
what
convenience
apis
are
things
that
we
know
users
wish
they
wanted,
maybe
they're
things
we
used
to
have
in
our
api
that
went
away,
maybe
they're
things,
you've
noticed
you're,
building
or
wish
to
add
to
the
project,
and
if
we
could
just
quickly
see
if
we
could
jot
down
as
many
of
these
that
we
happen
to
know
about,
I'm
just
curious
where
we're
standing
on
this-
and
this
is
got
two
parts.
One
is
just
any
like
convenience
methods.
B
So
this
is
just
api
calls
we
would
add
somewhere
and
the
other
is
annotations
for
any
language
that
supports
annotations
or
something
that
could
do
more
powerful
macros
than
you
could
get
out
of
just
an
api
call
like
what
would
be
good
things
to
have
there.
B
Okay,
great,
so
this
is
the
beauty
of
having
multiple
shared
docs,
so
my
request
is
just
just
start:
adding
away
we're
gonna
take
10
minutes
here.
Thank
you.
Anonymous
dragon
for
making
a
bunch
of
bullet
points.
B
B
C
Why
I
cannot
change
things
like
and
I
brought
and
delete
and
then
refresh
the
page
and
you
should
be
able
to
edit
it
now.
B
D
L
And
also
maybe
the
language,
because
if
you
have
something
in
mind
like
a
specific
language
that
you
don't
have
this
functionality,
it
will
be
useful
to
add
that,
as
I
was
referring
to
javascript,
because
I
was
using
that
and
did
not
have
this.
L
N
K
M
M
M
B
B
M
B
Them
yeah,
I
think
that's
good.
We
got
a
good
head
of
steam
going
here
and
we've
got
10
minutes
left.
So
why
don't
we?
Why
don't
we
start
discussing?
B
We
could
just
do
you
have
a
particular
thing.
You
want
to
start
with
bogdan
or
let's
start
in
order.
So
the
first.
L
The
first
two
I'm
I'm
impressed
that
they
are
missing
because
they
are
specified
in
the
specification
as
a
should,
so
so
the
language
should
provide
that.
If,
if
this
is
possible,
I
don't
know
what
language
the
user,
who
the
the
person
who
wrote
this
is
referring
to.
But,
for
example,
in
java,
it's
already
available.
C
I
wrote
it,
but
it's
not
available
as
a
in
a
global
context.
It's
available,
like
dot
content,
stop
gets
done
what
it
has
like
a
context.
Namespace.
L
B
I
think
what
bart's
saying
he
works
on
the
javascript
group.
I've
seen
what
they
did.
I
think
in
the
the
way
we
did
it
in
the
spec.
Is
we
moved
this
stuff
down
to
the
context
domain
and
since
they're
trying
to
strictly
follow
the
spec?
If
you
look
at
javascript
right
now,
end
users
have
to
go
through
a
context,
object
all
the
time
to
to
get
at
this
stuff.
So
it
it's
got
kind
of
a
long,
ugly
method,
signature.
There.
C
But
you
cannot
color
like
one
method
only.
You
have
to
call
two
or
three
methods
to
make
this
happen,
which
I
really
don't
like,
and
it's
not
pretty
straightforward
for
the
user.
If
you
have
some
like
get
active
spam,
I
would
assume
you
don't
need
to
read
any
documentation,
because
it's
self-explanatory.
L
No,
that
that
sounds
great,
I
think
I
think
so
ted.
Do
you
wanna
mark
that
with
jess
so
somewhere
put
something
that
is
for
the
moment.
So
far
is
just
specific
because,
as
I
said,
I
think
I
am
confident
that
it's
available
in
java
and
it
will
be
specific
in
it-
may
be
just
a
js
problem.
So
let's,
but
but
it's
good
to
track
that,
I
I
like
the
idea.
E
B
L
M
There
so
in
that
case
the
spec
actually
specifies
that
exact
shortcut,
but
it's
a
short
requirement.
So
if
there
are
like
valid
reasons
to
be
considered
to
not
do
it,
then
it
is
possible
to
not
do
it.
But
it's
like
it's
a
short
requirement.
It's
strongly
recommended
to
do
so,
and
it's
not
like
globally
at
api
dot
get
active
span
because
it's
related
to
tracing.
So
it
would
be.
I
don't
know
the
structure
in
js,
but
it
would
be
api,
dot,
tracing
dot,
get
active
span.
It's.
M
B
B
You
can
have
something
exactly
like
what
armin
described
of
an
api
module
with
a
tracing
object
in
it
or
a
namespace
that
just
just
has
these
as
static
methods
on
them
or
whatever
is
most
convenient
in
your
language,
but
just
clarifying
that
like,
if
all
of
these
things
are
available
in
one
spot,
it
makes
things
easier
for
the
end
user.
L
B
L
The
next
one
is
the
same:
it's
the
same
topic
as
it
says
same
as
above
the
other
one
is
api
with
span
inside
the
callback
where
spam
promo
become
active.
L
H
I'm
kind
of
yeah,
like
I'm
a
huge
proponent
of
having
some
sort
of
functionality
like
this,
but
as
as
we're
getting
as
we're
getting
serious
about
an
rc.
Some
of
us
already
have
methods
like
this
and
I'm
talking
about.
There's
there's
a
withspan
and
I
also
wrote
another
one
called
inspan
and
the
context.
Interaction
is
still
kind
of
up
to
debate.
H
I
think
with
it
within
our
sig,
and
I
start
to
get
concerned
that
once
we
ship
these
things,
we're
stuck
with
them
and
as
this
working
group
moves
forward
and
kind
of
establishes
some
api
method
names,
some
convenience
methods
and
behaviors
that
they
might
not
match,
and
that
seems
like
a
pretty
big
risk.
That's
just
taking
the
game
is
this
or
this
these
debates
are
going
on
in
ruby
and
js,
but
ruby
actually
js
is
safe.
H
I
think,
because
in
js
we've
taken
the
safe
route
of
just
like
no
no
convenience
you're
using
kind
of
the
raw
context
api
which
people
don't
like,
but
it
is
actually
the
safe
thing
to
do
and
ruby.
I
am
almost
as
much
as
I
feel
like.
We
need
some
convenience
methods.
I
almost
feel
like
we
should
remove
them,
because
we
don't
know
how
they
should
work.
L
One
option
that
we
did
in
java
fyi,
we
started
an
incubator
or
extension
api
project
which
we
marked
as
alpha.
So
we
we
were
able
to
ga
stabilize
the
core
things,
but
we
started
to
think
about
all
of
these
things
marked
as
alpha
and
we
don't
we're
not
gonna
mark
them
as
stable
until
we
get
more
confirmation
and
better
understanding
of
this.
J
Yeah,
I
would
like
to
sorry
go
ahead.
Carlos
sorry,
a
very
quick
point,
but
just
to
be
clear.
All
of
these
additions
that
we're
talking
about
would
be
on
a
ledger
on
top
of
the
of
the
core,
so
it
doesn't
mean
if
there's
any
fear
that
we
will
break
things
it
shouldn't
be
because
I
think
that
this
is
an
additional
layer.
C
Yeah
exactly
I
don't
want
this
to
be
tight,
because
I
don't
know
in
one
language
you
will
tie
to
this
trace
in
the
other
into
tracing
in
in
js.
It
would
be
ip.context
and
as
a
user,
you
have
to
figure
out
okay,
which
language
is
keeping
what,
where,
instead
of
just
using
global
method,
which
would
be
get
active
spam.
B
B
I
think
that's
that's
a
critical
thing
to
be
wary
of
before
you,
1.0
is
making
sure
you're
not
creating
a
situation
where
the
someone's
going
to
pull
be
using
methods
that
that
cause
things
that
aren't
the
span
to
get
lost,
so
the
rest
of
the
context
getting
lost,
but
so
I
think
that's
critical.
B
Maybe
a
would
be
nice
for
a
little
bit.
Less
critical
is
oh,
we
already
added
some
sugar
and
then
open
telemetry
defined
some
sugar.
That
was
like
a
little
bit
different
than
what
we
added.
I
think
that's,
okay,
you
can
always
mark
the
existing
sugar
as
deprecated
and
at
the
end
of
the
day,
I
don't
think
it's
like
a
super
duper
big
deal
if
some
of
the
sugar
works
a
little
bit
differently
across
different
languages,
so
I
just
wanted
to
call
that
out.
H
H
I
think,
but
the
risk,
though,
is
that
if
we
define
these
convenience
methods,
even
if
we
shipped
one
that
we
thought
is
reasonable,
like
it
could
have
a
very
similar
name
or
the
same
name
as
something
that
gets
defined
here,
but
different
behavior,
if
we
kind
of
release
the
convenience
before
we've
kind
of
agreed
on
what
they
should
look
like
so.
L
B
But
I
will
say
matt
at
the
end
of
the
day,
if
these
are
things
that
have
been
vetted
is
like
it's
nice
to
have
this
in
ruby
and
we
like
it.
I
do
think
we
should
add
some
stuff
into
the
spec
about
like
what
happens.
B
If
there
is
a
conflict
between
sugar
that
we
add
and
add
officially
and
like
sugar,
that
an
individual
sig
may
have
added
on
their
own
to
say
that
it's
it's
okay
just
make
sure
in
the
documentation
you
call
it
out
and
if
the
functionality
is
different
enough,
then
you
know
deprecate
what
you
have
or
provide
the
alternatives.
B
L
Yeah
I
want
to
discuss
the
last
one
ted
because
I'm
very
curious
the
set
parent
one
I
am
so
triggered
by
that.
C
It
is
just
a
proposal
because
quite
often
people
are
like
struggling.
How
can
I
define
a
parent?
I
mean
we
had
this
previously,
but
it
was
removed
right,
so
you
could
set
directly
apparent
span
on
other
parent.
You
cannot
do
this
now,
so
it's
like
a
for
people
difficult,
really
to
understand
why
I
cannot
set
a
spam
directly,
another
another
spam
to
be
a
parent
spam.
L
But
we,
I
think
we
define
that
parent
is
available
only
the
span
construction
time,
so
this
will
break
one
of
the
the
assumption
that
we
have
in
this
because
because
so
so
I'm
I'm
curious
about
this,
and
I
want
to
understand.
Maybe
maybe
there
is
a
use
case
for
for
starting
a
span
before
knowing
their
parent
and
then
sitting
the.
L
B
L
That's
that's
reasonable,
yeah
because
so
far
we
have
things
like
we
inherit
the
trace
id
from
the
parent,
which
will
no
longer
be
the
case,
because
if
you
have
the
pattern,
the
span
created
separately
will
have
a
different
span,
a
span.
We
will
have
a
different
trace
id.
So
if
we
offer
this
set
parent,
then
we
would
mean
that
we
reset
their
trace
id
and
identifiers
correct.
B
So
I
I
just
want
to
note
the
time
it's
it's
after
10,
so
a
lot
of
us
have
to
go,
but
this
was
a
great
brainstorming
session.
I
feel
like
we
got
a
bunch
of
good
stuff
at
the
door
and
I
will
try
to
triage
this
into
a
form
figure
out
what
the
best
form
is
for
us
to
to
continue
these
discussions.
Probably
you
know
either
as
oteps
or
or
github
issues
for
each
each
particular
method.
We
want
to
add
would
probably
be
good,
but
continue
to.
B
Please
continue
just
to
make
comments
in
this
doc.
In
the
meantime,
any
questions
or
comments
you
have
on
these,
like
it's
just
good
to
just
get
them
rounded
up
for
the
time
being.
So.
Thank
you
all.
It's
a
great
meeting,
always
great
to
see
your
faces
on
monday,
have
a
good
one.
Yeah.