►
From YouTube: 2022-06-21 meeting
Description
cncf-opentelemetry@cncf.io's Personal Meeting Room
B
Okay,
silent
people
see
how
it
goes.
We
can
start.
I
think
I
think
it's
okay
to
start
yeah.
What
about
we
start
with
make
otp
one
two:
zero
tigran.
You
want
to
try
that
part.
Yeah.
C
So
I
I
posted
the
summary
of
I
guess
what
I
I've
been
thinking
about
for
the
last
few
days
or
more
tlp
there
as
a
comment.
So
maybe
let
me
try
to
tell
it
now,
so
I
think
I
think
we
should
provide
stronger
guarantees
than
is
strictly
necessary.
Just
from
the
perspective
of
wire
compatibility,
I
guess
the
wire
compatibility
is
the
bare
minimum.
Obviously
right,
so
you
want
to
make
sure
that
otp
implementations
are
interoperable,
but
I
think
that
is
not
enough.
C
I
think
we
need
to
provide
stronger
guarantees
and
the
reason
for
that
is.
I
think
that
we
need
to
be
providing
providing
these
guarantees
in
order
for
developers
to
implement
otlp
and
particularly
developers,
even
outside
open
telemetry,
to
make
their
lives
easier
right
so
that
we
don't
make
changes
that
result
in
in
them
having
to
change
their
code,
and
from
that
perspective
I
think
the
the
items
that
I
listed
earlier
all
the
names
of
messages,
field,
fields
and
arms,
all
the
stuff
that
is
not
necessarily
appearing
on
the
wire
at
all.
C
C
So
the
only
thing
that
we
will
not
guarantee
is
a
particular
behavior
of
code
generators,
but
we
will
not
knowingly
make
changes
that
will
break
the
generated
code
right
and
so
the
names
of
everything,
the
locations
of
staff,
fields,
messages
and
arms,
the
files
and
packages
that
will
be
guaranteed
to
remain
unchanged
once
1.0
is
declared.
C
So
that's
that's
what
I
think
we
should
do
if
you
think
otherwise.
Please
comment.
B
I
think
it
sounds
sounds
great,
maybe
didn't
dial
in
javascript
people
for
a
start
can
take
a
look
at
that
later.
Overall,
I
went
through
the
items.
I
think
it's
a
great
proposal.
C
D
Yes,
I
I
fully
support
the
that
stability
declaration.
In
definition,
I
think
that,
for
the
remaining
breaking
changes,
now
is
the
time
to
make
them.
If
we
are
going
to
make
them,
we
should
have
a
high
bar
for
making
them
at
this
point,
though,
with
strong
justification
for
their
need.
D
E
E
We
have
not
released
the
json
exporters
as
1.0,
because
we've
been
waiting
for
the
stability
guarantees
to
be
made.
That
said,
we
do
have
users
who
are
using
them
and
if
there
are
breaking
changes
they
are
at
least
going
to
wonder
why
that
happened,
and
I
agree
with
anthony.
I
think
that
the
justification
for
any
breaking
changes
should
be
fairly
strong.
At
this
point,.
F
I
have
a
general
question,
so
is
there
any
tooling
that
can
detect
the
the
problem
of
breaking
change?
Now,
for
example
like
in
the
opencountry.net,
I
introduced
the
two
breaking
change:
detection
tools
from
the
donai
team,
and
actually
I
was
surprised
to
know
that
a
lot
of
things
that
people
didn't
realize
it
it
is
actually
causing
braking
change
and
the
tool
captured.
Three
potential
breaks.
G
It
can
detect
like
wire
breaking
changes,
json
breaking
changes
and
also
generated
code
breaking
changes,
but
I'm
not
sure
the
scope
of
those,
since
it
kind
of
depends
if
you're
using
a
standard
or
non-standard
code
generator.
So
it
would
basically
be
like
a
ci
check,
probably
similar
to
what
you're
saying
riley.
F
C
Yeah,
I
think
that
would
be
great
to
have
this
enforced
by
a
tool
so
that
we
don't
accidentally
break
it
before
we
can
enforce
it.
I
guess
we
need
to
agree
what
what
are
the
rules?
What
is
allow
it
to
be
changed
and
the
tool
from
what
I
saw
is
fairly
flexible.
It's
configurable,
you
can
tell
it
what
is
allow
it
to
be
changed
and
what
not.
So
once
we
agree,
I
think
yes,
we
should
just
add
that
to
to
enforce
it.
B
C
B
C
I
don't
think
there
is
anything
major
remaining
there,
there's
one
pr
to
remove
deprecated
messages,
couple
prs,
which
are
overlapping,
which
are
proposing
changes
to
the
enums
and
one
is
just
a
capsule
I
think
which,
which
is
about
what
else
is
remaining
in
json
stability,
which
I
think
is
nothing
outside
of
what
already
is.
There
is
a
separate
pr.
So
technically,
if
we
can
agree
on
an
approach,
there's
really
not
much
to
do
there,
maybe
a
couple
weeks
and
we're
done
right.
Maybe
a
week
yeah.
B
B
Perfect,
thank
you
so
much
for
that.
Yeah
make
sense.
Okay,
let's
continue
talking
offline
yeah.
Let's
see
how
this
moves
on
with
bogdan
okay.
Next
one
then
ludmila
logical
versus
physical
net
attributes
are
you
around
with
them
yeah.
H
I'm
here
yeah,
thank
you
hi.
So
this
is
the
spin
of
discussion
from
http
attributes.
What
we
found
this
question,
that
net
pair
name
attributes
are
not
clearly
defined
and
they
maybe
mean
the
fear
you're
talking
this,
or
maybe
they
mean
the
logical
thing
at
the
end,
there's
maybe
proxies
and
other
things
in
the
middle.
So
was
this
pure?
H
I
am
saying
that
the
net
pure
name
attribute
and
that
purport
represent
this
logical
destination.
So,
if
I'm
connecting
through
proxy,
this
is
the
remote
endpoint
and
I
also
rename
net
peer
id
to
net
peer.
H
Sorry
net
sock
peer
under
address,
so
it
matches
the
system
apis
like
get
pure
name
that
return
address
and
represent
more
than
ap.
Potentially
I
think
we
are
mostly
in
the
consensus
is
christian
about
it.
C
Yeah,
so
I
have
a
question
on
this:
is
this
logical
peer,
ip
easily
obtainable
by
the
implementations,
if
the,
if
I
have
a
server,
if
I'm
implementing
a
server
and
the
client
connects
to
me
through
a
proxy?
H
Great
question:
so
there
are
two
parts
that
collide
on
the
client
side:
http
clients,
for
example,
usu.
They
usually
have
the
url
right
or
the
base
address,
and
they
also
have
proxy
address.
So
they
they
know
both
and
if
they
might
not
know
proxy
address,
but
they,
if
it's
transparent
or
if
it's
a
reverse
proxy
on
the
other
end.
But
they
for
sure
know
where
they
are
connecting
to
at
least
the
logical.
C
H
Yes,
you
usually
in
http
case,
you
usually
obtain
it
from
a
max
forwarded
or
forwarded
header,
or
something
like
that.
That's
specific
to
the
technology,
but
on
the
server
side,
you
probably
very
have
very
limited
knowledge
about
who
you're
talking
with,
on
the
other
side,.
C
H
For
http
we
have
a
different
attribute
for
a
real
client
that
is
in
x,
forwarded
for
header
and
the
ip
address
that
you
are
talking
to
the
socket
address.
It
depends
whether
you
have
the
connection
instance
or
not,
and
this
is
optional-
you,
oh
sorry,
it's
recommended.
C
H
I
So
I
I
can
say
that
when
I
wrote
the
http
spec
initially,
I
assumed
it
was
the
low
level
stuff,
but
since
we
had
separate
attributes
for
the
logical
stuff,
but
I
think
this
will
now
be
cleaned
up
after
we
have
these
two
pr's.
It
should
be
clear
because
it
it.
I
agree.
It
wasn't
very
clear
before
yeah.
I
I
Have
both
possibilities?
We
have
all.
I
All
right,
you
don't,
I
think
you
know
correct
me
wrong,
but
your
httpr,
which
is
not
really
the
one
we
are
discussing
here,
but
that
one
would
then
require
setting
the
logical
here
and
optionally.
If
you
know
it,
you
can
also
set
the
low
level
here
on
the
client
side
and
on
the
server
side.
It's
as
previously,
you
don't
need
to
know
anything
about
the
key.
C
B
Yeah
I
used
the
christian's
approval
so
okay,
perfect,
so
let's
get
more
reviews
on
that.
Thank
you
so
much
for
that.
Okay,
let's
move
to
the
next
item
then
feature
flaggy
sematic
conventions.
E
Yeah,
so
this
was
introduced
a
while
ago.
Actually,
originally
the
pr
was
opened
and
then
the
the
author
of
the
pr
was
told
to
create
an
issue
for
it.
So
he
marked
his
pr
as
a
draft
and
opened
an
issue.
E
He
also
linked
discussion
from
their
community,
which
includes
a
lot
of
you,
know
major
industry
players
in
the
future
flagging
space,
and
then
this
has
essentially
sat
and
had
no
interaction
from
our
side
at
all.
The
pr's
been
mark
stale
a
couple
of
times
and
we've
had
to
just
keep
commenting
just
to
say
it's,
not
stale.
E
E
So
I
guess
I
told
him
I
would
bring
it
up
in
the
spec
meeting
just
to
to
ask
what
is
the
current
status
of
this?
What
are
we
waiting
for,
or
you
know
it's,
it's
not
a
unique
situation.
E
I
think,
unfortunately,
we've
had
a
handful
of
prs
on
a
fairly
regular
basis
where,
where
people
open
them
and
then
get
frustrated
and
then
leave-
and
I
think
it
leaves
a
sour
taste
in
the
mouth
of
people
who
would
otherwise
become
involved
in
the
project,
so
I'm
trying
to
avoid
that
happening
here.
I
just
don't
know
what
to
tell
him.
I
mean
there's
been
there's
been
interaction
on
on
their
community
and
on
our
issue
in
pr
from
from
the
future
flagging
community
saying
that
they
support
this.
E
J
J
E
J
C
C
C
I
am
personally
I
I
don't
have
a
use
for
this,
but
I
can
see
the
value
of
it
right,
so
I'm
I'm
not
against
or
wouldn't
be
rejecting
this,
but
again
to
me
this
looks
like
something
that
didn't
just
didn't
generate
enough
interest,
and
that
is
probably
the
reason
why
he
didn't
move
forward.
I
may
be
wrong.
G
G
To
get
a
little
more
consistent
about
doing
just
not
just
not
not
letting
people
hang
one
way,
the
other.
If
we
can
write
back
to
them
and
say
you
know,
I
think
in
general
we
should
make
sure
there's
there's
somebody
assigned
to
moving
these
things,
to
completion
and
complete,
and
in
general
that
means
when
responding
to
them,
leaving
it
on
some
point
of
action
either.
Can
you
please
do
this
to
prove
to
us
there's
interest
or
telling
them
you
know
we.
G
We
don't
think
we're
interested
at
this
time
and
adding
it,
but
I
think
it's
important
for
us
to
to
respond
to
people
with
action
items
or
like
a
definitive
yes
or
no
about
it.
E
So
from
a
process
perspective,
I
totally
agree.
I
would
also
mention
riley
just
posted.
I
had
forgotten
we're
actually
using
this
in
our
open,
telemetry
demo
application.
So
in
my
mind
that
would
be
a
strong
argument
for.
Yes,
there
is
interest
from
the
open,
telemetry
community.
E
It
seems
silly
to
me
that
we
would
use
something
in
our
own
demo
and
then
not
accept
it
into
the
specification.
So
we
should
either
remove
it
from
the
demo
or
add
it
to
the
spec.
F
I
can
share
more
context,
so
this
pr
was
sent
before
we
have
that
process
like
I,
I
added
a
spike
change
pr
saying
in
in
the
pull
request,
template
that
if
you
create
a
pr
that
is
fairly
big,
you
should
have
an
issue
first
and
get
explicit
yes
from
any
tc
member
or
spy
controller,
but
that's
after
this
pr,
so
that
you
wouldn't
apply
here.
It's
a
it's
a
one-off
case,
I
believe,
moving
forward.
F
We
shouldn't
have
this
problem,
like
I've
seen
other
prs
when
they
open,
they
don't
have
the
issue
and
they
were
created
after
we
enforces
you,
and
I
just
tell
the
the
creator
of
the
pr
to
move
back
for
this
ap
testing
thing.
I
personally
I'm
interested
and
I've
seen
in
the
in
the
demo
project
that
were
exploring
this,
not
necessarily
we're
following
the
proposal,
but
I
can
see
the
need.
What
I'm
not
sure
is.
This
pr
seems
to
be
very
focusing
on
a
specific
scenario.
Well,
I
think
eb
testing
is
a
much
bigger
area.
F
E
Yeah,
that's
fine,
I
mean
the
the
pr
is
a
draft.
I
don't
think
he's
expecting
immediate
pr
reviews.
I
think
what
he
was
hoping
for
was
just
some
indication
of
what
that
the
next
step
of
the
process
would
be
on
the
issue
yeah.
So.
F
I
I
I
think
we
have
a
topic
from
ted
and
he's
trying
to
make
a
formal
proposal.
How
do
we
handle
this,
and
I
think
the
av
testing
scenario
is
a
perfect
case
just
to
go
through
this
new
process.
G
Yeah,
if,
if
this
is
something
that's
big
enough,
we're
saying
there
needs
to
be
like
kind
of
a
working
group
to
resolve
it.
I
do
think
some
things
like
this
might
be
smaller
than
that,
but
but
regardless
I
think
it's
like
we.
We
have
a
process,
but
I
don't
think
we
maybe
it's
like.
We
need
to
go
back
to
having
a
triage
session
led
by
someone
and
making
sure
we're.
G
You
know,
issue
issues
get
like
auto
assigned.
You
know
we
do
a
lot
of
like
auto
assigning
and
following
that
up,
maybe
with
like
some
rebalancing
or
something
like
that,
just
to
make
sure
you
know
if
one
person's
not
interested
in
taking
it
on
or
like
I
said
like
sergey,
I
think,
got
assigned
to
this
and
like
she's,
not
around
a
lot
these
days,
you
know.
G
Maybe
what
we're
missing
is
some
kind
of
like
triaging
review
of
what
it
is
what's
going
on
in
the
backlog
just
to
just
to
make
sure
we're
noticing.
If
there
is
an
issue
like
this
one,
that's
just
getting
stuck
in
limbo
so
that
we're
noticing
it
before
the
the
person's
getting
like
super
frustrated,
and
you
know
bothering
dan
about
it.
C
So
I
think
the
response
to
this
one
should
should
be
right
now
that
we
want
to
see
if
there
is
enough
interest,
I
think
that's
a
valid
response.
As
for
the
process
and
whether
we're
following
it
or
no,
I
don't
think
we
have
any
defined
timelines
about
how
quickly
we
should
be
responding.
Maybe
we
need
that
right.
C
We
know
that
what
kind
of
responses
there
should
be
right,
it's
a
yes,
no
or
we
need
more
information
right,
and
this
particular
case.
It's
the
it's
that
the
ladder
right.
We
need
more
information
as
in
we
need
to
see.
If
there
is
enough
interest,
please
show
the
interest
demonstrate
the
interest,
and
so
maybe
the
the
the
workflow
that
we
have
there
needs
to
tell
how
quickly
the
responses
should
happen.
C
L
L
G
But
we,
you
know,
we
we
have
a
thing
about
issues
going
stale
right
so
that
we
don't
have
stalled
issues
hanging
out,
but
the
the
reason
it's
going
stale
is
that
we're
they're
they're
stuck
waiting
on
us.
We,
I
think
that
that
means
you
know
we
we
have
to
be
providing
something
in
those
situations,
and
I
think
it
can
sometimes
happen
where
yeah
like,
for
whatever
reason
you
know
we're
not
noticing
that
that's
happening
and
to
me
that
speaks
to
having
like
just
like
a
triaging,
more
active
triaging,
going
on
the
spec
backlog.
G
C
G
Yeah
yeah,
I
just
I
just
wonder
if
I
mean
I
think
right
now,
we
don't
they're
they're
we've
started
doing,
I
think
pre-agging
for
the
the
collector
backlog
right
and
there
was
a
period
when
we
were
doing
triaging
for
the
spec
backlog.
When
andrew
was
here
to
kind
of
dig
out
from
under
having
a
lot
of
issues,
and
I
recall
that
being
really
helpful.
That
was
when
we
got
a
lot
more
organized
around
using
labels,
and
things
like
that,
so
maybe
something
we're
dismissing
right
now
is
is
having
I.
G
I
think
this
meeting
is
for
like
discussing
spec
issues
and
if
we
do
a
bunch
of
triaging
in
this
meeting,
it'll
probably
be
like
too
much,
but
maybe
one
possible
solution
is
to
you
know
if
there's
a
time
that's
convenient
for
the
the
tc
where
we
can
have
a
triaging
like
30,
minute
triaging
session,
where
we
review
by.
B
G
I
think
we've
been
thinking
about
it.
Maybe
we
should
just
just
act
upon
it
riley.
I
know
that's
something
you're
you're
interested
in
as
well.
F
We
have
the
process,
it's
just
we're
not
executing
towards
the
what
we
documented
here-
and
I
think
one's
interesting
is
there's
some
actions
defined
here,
but
it's
not
clear
who's
going
to
do
it.
For
example,
if
it's
not
properly
responded,
then
reassign
like
who's
going
to
reassign
the
issue.
It's
not
clear.
C
Right
so
for
this
particular
issue,
does
everybody
agree
that
we
want
to
request
more
information,
in
particular
with
regards
to
how
much
interest
there
is
from
companies
from
from
the
open
telemetry
community
before
we
move
forward
with
that,
and
if
we
see
enough
interest,
this
is
likely
to
become
part
of
the
semantic
conventions.
I
I
personally
don't
see.
Why
not
does
that?
Is
it
fair.
F
F
I
agree
and
I'm
I'm
even
willing
to
drive
it
if
we
have
at
least
three
languages
willing
to
do
the
experiment,
because
I
I
feel
without
experiment
just
by
staring
at
the
pr.
I
won't
be
able
to
make
any
decision,
and
this
is
why
I
I
try
to
motivate
the
demo,
the
web
store
diamond
team
to
incorporate
this.
I
just
want
to
see
how
it
works.
C
Okay,
I'll
make
I'll
respond
in
the
in
the
issue
with
this,
and
I
think
the
minimum
we
can
do
right
now
is
at
least
have
three
formal
labels
defined
there
in
github,
so
that
we
can
actually
see
whether
the
particular
issue
is
triaged
properly
according
to
the
workflow
that
we
have,
and
ideally
also
if
someone
can
automate
the
the
like
periodically
poll
the
issues
and
see
if,
if
the
label
is
missing.
G
Yeah,
maybe,
as
a
follow-up
can
the
since
the
the
tc's,
especially
the
essentially
the
spec
maintainers,
I
know
reggie's
willing
to
help
out
tpm
and
try
out
the
backlog.
But
if
you
guys
want
to
find
a
time
that
would
be
have
a
reasonable
chance
of
tc
members
being
able
to
attend,
I
would
consider
adding
a
triaging
session.
B
B
K
Okay,
can
I
make
a
suggestion.
B
K
B
K
Would
I
would
schedule
something
and
then
reach
out
to
the
tc
members
directly
and
just
say,
show
up
and
then
you'll
get
a
response
directly
from
them.
Saying
like
I
can't
write.
You
know
something
like
that,
but
I
okay.
L
K
Recommend
being
a
little
bit
more
up
front
about
just
saying
like
this,
is
the
time
that
you
should
show
up,
because
we're
going
to
do
this
here,
all.
B
Yeah
I
like
that,
just
don't
just
don't
use
the
same
time
slot
as
a
collector
triaging
session
on
fridays,
just
different
timeline
suggestions,
but
yeah,
that's
a
good
one.
Tyler.
E
B
Yeah,
that
makes
sense.
Thank
you
so
much
for
raising
that.
Let's
see
what
can
be
done
on
the
pc
side
as
well
anyway,
moving
forward
for
the
second
time,
johannes,
or
tap
for
messaging
context,
propagation
requirements.
Are
you
around.
L
Yes,
come
around
and
in
the
messengering
work
group
we're
for
some
time
now
being
discussing
like
stabilizing
the
messaging
semantic
conventions.
We
came
up,
we're
working
on
a
drive
throughout
that
that
got
really
big
and
we
decided
to
split
it
up
to
make
it
easier
to
chest
deeper
and
the
first
part
is
the
bonnet
linked
in
the
in
in
the
trender
meeting.
It's
about
context,
propagation
requirements
for
measured
messaging,
and
that
doesn't
really.
This
change
is
proposed.
There
don't
really
change
or
break
anything
regarding
the
existing
semantic
conventions.
L
It
just
makes
some
context
propagation
requirements
that
were
implicitly
made
explicit
and
the
motivation
to
to
do
this
is
just
to
make
it
easier
to
reason
about
future
depths
that
we
are
gonna
submit.
L
I
think
it
will
really
help
to
make
these
requirements
explicit
and
another
important
reason
why
we
should
have
this
is
that
they
are
currently
like
drafts
for
wc
wcc,
trace
context
for
amqb
and
mqtt,
and
there's
also
something
similar
for
cloud
events
which
basically
tries
to
come
up
with
specifications
regarding
context
propagation
for
messaging
protocols
and
having
requirements
from
our
sites
spelled
out
clearly
will
really
help
moving
forward
stabilizing
of
those
of
those
specifications.
L
Orders
are
linked
in
the
old
tab,
so
you
can
have
a
look
and
yeah
a
third
reason.
I
think
why
it's
good
to
have
this
explicit
is
for
customers
who
currently
implement
their
own
ways
of
context
propagation
for
messaging,
because
all
those
mqp
and
mqtt
or
cloud
events
specifications
are
not
stable
also
there.
We
can
then
provide
like
the
key
requirements
that
need
to
be
fulfilled
in
context
propagation
so
that
they
can
kind
of
then
implement
the
messaging
semantic
conventions
accordingly.
L
So
there's
already
some
reviews
on
the
pr,
mostly
from
people
involved
in
the
discussions,
so
it'd
be
great
to
get
there
some
validation
from
like
divider
community
and
some
ice
on
this.
Pr.
As
I
said,
the
pr
should
be
it's
a
pretty
short
pr
should
be
easy
to
review
and
yeah.
Please
have
an
eye
on
it
and
review
a
proof
or
comment.
B
I
I
don't
curiosity
either
so
like
do
you
have
something
or
how
to
phrase
this?
What
did
you
imagine
part
of
this
hotep
landing
in
the
actual
classification?
It
could
be
about
semantic
convention
specific
stuff
or
is
about
writing
up
part
of
this.
For
example,
I
see
some
section
regarding
how
let
me
check
it's
called
yeah
quantity,
propagation,
transport
context.
Propagation,
for
example,
is
that
something
do
you
imagine
landing
in
the
actual
specification.
L
Oh,
there
is
a
so
in
the
old
tab.
There
is
like
the
section.
That's
called
proposed
addition
to
the
messaging
semantic
conventions
that
has
some
explications
and
some
kind
of
normative
requirements.
I
think
that
is
definitely
intended.
That
is
intended
to
end
up
in
the
specification,
so
that's
basically
the
explication
and
then
the
normative
requirements,
the
transport
context,
propagation,
that's
under
future
possibilities.
L
That
is
not
intended
to
be
put
there
with
this
in
in
terms
of
this
others.
Just
like
we
captured
this,
because
that
is
some
also
discussions
that
we
had,
and
that
is
that
this
might
be
some
post,
one
zero
work
for
the
messaging
semantic
conventions
to
kind
of
come
up
with
with
with
a
solution
or
with
a
specification
for
this,
but
that
is
just
basically
captured
in
this
pr,
so
that
our
discussions
about
this
are
not
lost,
but
this
did.
This
can
then
serve
as
a
foundation
for
future
future
outtaps.
B
Perfect
yeah.
Thank
you
so
much.
I
was
a
little
bit
curious
because
I
saw
on
that
part
as
very
small
section
saying
requirements
and
that's
a
very
small
section,
but
I
guess
you
also
want
to
put
there
the
context.
Propagation
case
section.
Sorry,
okay,
that
basically.
B
B
G
Yes,
so
this
is
a
proposal
we've
been
kicking
around
for
a
bit.
I
feel
like
I've
gotten
a
lot
of
feedback
from
people
on
it.
This
is
basically
trying
to
codify
and
organize
the
way
that
we
spin
up
spec
working
groups
and
kind
of
manage
the
life
cycle
of
those
spec
working
groups.
G
The
goal
of
this
proposal
is
mostly
to
make
it
clear
to
everyone
involved
what
the
requirements
are
for
for
getting
a
group
going
so
for
people
who
want
to
create
a
spec
working
group-
and
I
imagine
we're
going
to
get
more
and
more
of
these
created
by
people
who
are
not
already
core
existing
members,
because
you're
going
to
have
a
lot
of
semantic
conventions
and
in
general,
open
telemetry,
is
expanding
beyond
you
know
the
core
of
building
like
a
proper
tracing
client,
for
example,
so
we're
going
to
have
more
new
members
who
who
want
to
define
something,
add
profiling
to
open
telemetry,
add
a
complex
set
of
semantic
conventions,
or
something
like
that
and
so
part
of
what
this
does
is
it
makes
it
clear
for
the
people
who
would
like
to
start
a
working
group
all
of
the
requirements
for
that
working
group
to
have
success.
G
So
what
the
goal
of
the
working
group
is,
what
kind
of
staffing
the
group's
going
to
need,
making
it
clear
to
them
up
front
they'll,
be
expected
to
be
creating
prototypes
in
oteps,
and
so
could
they
identify
who's
willing
to
write
prototypes
in
oteps?
Just
to
make
sure
we've
got
people
ready
to
do
that
if,
subject
matter,
experts
are
needed,
making
sure
we
have
subject
matter
experts
and
then
making
sure
that
two
tc
members
are
assigned
as
what
we're
calling
like
group
sponsors.
G
This
just
means
those
tc
members
are
committing
to
participating
in
the
group,
not
as
like
the
lead
designers
necessarily
and
to
be
clear.
It's
not
even
that
those
tc
members
need
to
be
subject
matter,
experts,
it's
just
to
make
sure
that
that
group
has
a
connection
to
the
the
core
of
this
spec
community.
G
So
there's
someone
there
who
can
help
translate
their
ideas
into
our
existing
specifications
and
requirements
and
explain
that
to
them
explain
the
process
to
them
and
to
also
help
so
one
situation
these
groups
have
had
is
they
do
a
lot
of
work
on
their
own
and
they
build
up
a
lot
of
context
and
then,
when
they
come
to
present
their
work
to
the
the
rest
of
the
spec
community,
it's
sort
of
like
they
have
to
start
from
scratch,
because
no
one
on
the
other
side
of
the
fence
has
had
any
context
built
up
the
way
they've
built
up
context
along
the
way.
G
So
I
think
it'll
also
make
the
process
go
a
lot
faster,
because
you'll
have
some
tc
members
who
are
building
context
around
the
project.
At
the
same
time
that
the
group
is
so,
hopefully
it
will
make
for
just
a
smoother
specification
process
and
then
the
other
part
of
this
proposal
is
to
create
a
project
board.
G
So
the
tracking
issue
for
each
one
of
these
projects
goes
on
the
board
so
that
we
have
a
way
of
recognizing
projects
that
have
been
approved
in
the
sense
of
we're
saying
that
this
is
a
project
we
would
do
if
all
of
the
resources
assemble
themselves
to
to
get
ready
to
do
the
project
projects
with
a
scheduled
start
time.
G
So
we
can
give
people
some
some
lead
time,
so
they
can
clear
their
calendars
and
then
projects
that
are
currently
active
because
we're
actively
assigning
tc
members
to
these
projects
and
scheduling
them
and
kind
of
being
a
little
more
organized
about
when
we
start
them
and
trying
to
keep
them
on
some
timelines.
My
hope
is
that
also
make
help
us
avoid
a
situation
where
we
end
up,
maybe
stretching
ourselves
too
thin
because
we've
over
committed
people
to
to
keeping
track
of
too
many
things.
G
So
hopefully
it
will
also
have
a
back
pressure
effective
being
able
to
explain
to
people
why?
Maybe
we
can't
start
a
certain
project
right
now,
because
we're
too
busy.
So
so
that's
the
hope
of
the
the
process
and
again
riley
and
reggie
have
graciously
offered
to
manage
the
the
the
project
board.
As
part
of
you
know,
tpm'ing
the
the
spec
project.
G
So
I
think,
based
on
my
experiences
with
the
last
round
of
working
groups,
we
spun
up
this-
would,
I
think,
just
solve
issues
both
on
the
the
group
side
for
making
their
expectations
a
lot
clearer,
and
then,
I
think,
also
on
the
the
tc
spec
community
side,
where,
rather
than
getting
like
blindsided
about
a
proposal
out
of
the
blue
and
suddenly
needing
to
like
turn
their
attention
to
to
reviewing
it,
everyone
will
have
more
of
a
heads
up
as
to
when
to
expect
to
to
have
to
review
things
so
hopefully
it'll
just
make
it
smoother
for
everybody.
G
K
So
ted
this,
I
think
this
looks
great
by
the
way,
thanks
for
putting
it
together.
One
of
the
questions
I
had
is
like,
maybe
like
a
meta
project
cycle
here.
I
know
that
in
go.
They
do
very
similar
things
for
like
what
they're
going
to
essentially
work
on
for
their
next
feature,
release
in
the
language,
and
I
think
we
can
do.
I
think
you've
got
something
here
where
it
says,
like
it,
tracks
things
with
issues.
I
think
we
should
also
maybe
have
some
sort
of
like
clear
indicator.
K
K
It
also,
I
think,
is
helpful
to
say
like
every
month
or
every
quarter.
We
do
a
cycle
essentially,
and
I
think
in
that
cycle,
if
you
could
really
well
define
like
you
know,
we
first
start
by
looking
how
much
capacity
we
have
for
new
projects,
and
then
we
have,
you
know
an
evaluation
of
how
many
new
projects
and
from
there
we
come
up
with
a
number
of
things
that
we're
going
to
accept.
K
I
think
it
might
be
really
helpful
and
clear
for
not
only
new
users
looking
for
proposals,
but
also
the
tc
members
and
understanding
like
what's
going
to
be
expected
in
the
future.
As
you
know,
cc
changes
or
things
like
that.
I'm
sorry,
if
you
already
included
that,
but
I
did
a
quick
read,
I
didn't
see
it
so.
G
G
G
One
thing
I
found
with
these
working
groups
is
it's
especially,
as
these
groups
start
to
need
more
and
more
subject
matter,
experts
that
are
not
core
members
of
our
community
already,
for
example,
if
we
want
to
review
and
finalize
the
the
sequel
conventions
part
of
that
means,
we
need
to
get
some
like
sql
subject
matter
experts
if
we
don't
feel
like,
we
are
simple
subject
matter
experts
and
I
find
that
that
part
can
take
a
little
bit
of
time
right
because
there
has
to
be
some
people
have
to
go
out,
find
some
people
that
they
work
with
who
agree
to
do
it.
G
Those
people
have
to
get
some
approval
that
they're
going
to
work
on
the
project,
and
so
there
ends
up
being
a
need
to
kind
of,
like
maybe
schedule
when
these
things
are.
Gonna
start
that's,
maybe
a
little
independent
of
of
us
having
like
some
kind
of
regular
monthly
cycle.
If
that
makes
sense.
G
So
that's
why
the
the
scheduled
projects
is
a
column
on
here,
because
I
think,
having
an
issue
open
like
a
tracking
issue
that
explains
the
the
project,
will
make
it
easier
for
people
to
sign
up,
but
there
will
probably
be
kind
of
a
gap
between
when
a
project
gets
gets
created
and
when,
like
all
of
the
necessary
people,
have
been
able
to
find
time
to
work
on
it.
G
So
I
think
some
of
it
will
be
will
be
around
kind
of
for
all
these
individual
projects,
kind
of
just
keeping
track
of
when
people
are
going
to
be
ready
to
do
it
and
then,
as
as
a
community.
I
think
we
benefit
on
kind
of
trying
to
make
space
for
the
projects
that
have
found
all
the
correct
people
like.
G
K
Yeah,
no,
I
mean
that
makes
sense,
but
I
think
it's
just
like
that's
that
last
point
is
kind
of
like
we
need
to
make
sure
that
those
timelines
overlap
right
like
if
you
have
everyone
is
project
experts
ready
in
august,
but
the
tc
has
you
know
13
things
on
their
plate
and
they
can
really
only
do
five.
Like
you
know,
we
want
to
make
sure
that
we
have
scheduled
time
that
that
aligns
with
those
you
know.
Maybe
then
we
need
to
look
at.
G
Totally-
and
so
I
think
this
can
be
part
of
like
that-
that
triage
meeting
we
were
just
talking
about
setting
up
having
part
of
like
the
triage
is
the
backlog,
but
also
if
there
are
any
updates
or
changes
to
any
of
these
proposals.
You
know
making
sure
we're
reviewing
that
and
and
just
thinking
about
people's
time
and
schedules.
G
M
Ryan,
you've
got
your
hand
up
yeah.
I
just
wanted
to,
I
mean
yeah.
I
think
this
would
be
super
helpful.
I've
been
kind
of
working
with
the
profiling
folks
on
trying
to
get
yeah
getting
a
group
together
talking
about
profiling,
getting
it
supported
as
an
event
type
and
I
think
the
hardest
part
for
us.
So
far
I
mean
there's
been
a
lot
of
interest
from
various
communities
that
are
not
as
familiar.
M
I
would
say
you
know,
or
it
might
be
their
first
time
like
myself,
included
doing
something
in
the
hotel
world,
or
I
got
something
official
and
yeah.
Some
of
the
feedback
we
got
was
like.
Oh
yeah.
You
should
just
make
sure
you
have
a
a
tc
member
helping
out
that
kind
of
stuff
and
I
think
t-ron
was
sort
of
volunteered
just
because
he
happened
to
be
there
on
the
first
day,
but
we
never.
M
You
know
officially
asked,
and
I
don't
know
what
that
process
actually
looks
like
of.
If
there's
like
you
know,
a
formal
like
you
know.
Yes,
I'm
doing
this
or
is
it
just
kind
of
an
informal?
You
know
someone
who
shows
up
to
the
meetings
occasionally
does
it
have
to
be
one
person?
Can
it
be?
You
know
one
person
shows
up
one
week.
Another
person
shows
up
another
week.
I
guess
kind
of
we
just
didn't
really
know
and
still
don't
totally
know.
M
I
guess
what
the
process
is
there
so
yeah
having
more,
you
know,
written
documentation
as
to
how
that
process
works
and
what
we
should
expect
timeline
wise.
All
that
kind
of
stuff
would
be
really
helpful.
G
Yeah
awesome,
that's
yeah
sounds
like
very,
very
good
timing.
I
was
thinking
about
you
guys
a
bit
when,
when
I
was
writing
this
because
I
know
that's
a
group,
that's
just
spinning
up,
and
so
hopefully
maybe
we
can,
if
people
prove
this
process
like
the
profiling
group,
can
be
kind
of
like
the
trial
balloon
for
going
through
it
and
working
some
of
the
kinks
out.
G
B
I
If
there
is
still
time
I
can
maybe
just
plug
an
old
tap,
I
have
submit
submitted,
don't
really
have
a
presentation
prepared,
but
yeah.
What
is
it
that
was
this
old
tip
for
another
kind
of
scoped
attributes.
I
In
the
chat,
it's
all
the
two
207
proposed
context,
scoped
attributes-
and
this
tries
to
address
a
program
that
came
up
several
times
in
the
past,
where
you
want
to
set
attributes
on
all
the
spans
of
a
trace.
Basically
inside
a
service,
we
had
this,
for
example,.
I
With
the
http
application
name
was
one
example:
they
want
to
set
this
on
all
the
spans
that
belong
to
the
same
http
application
like.
If
you
are
in
some
java
egbe
server,
then
you
have
one
jvm.
That
runs
several
http
applications
and
that's
why
you
can't
use
resource
attributes,
so
it
would
normally
be
nice,
but
you
have
more
than
one
application.
It
is
instrumented
in
this
case,
probably
by
the
same
java,
agent
yeah
and
this
otep
tries
to
address
that.
I
Basically,
the
short
of
it
is,
it
proposes
to
store
attributes
inside
the
context,
so
the
context
that
we
already
have
this
telometric
context
object
and
then
each
telemetry
signal,
like
stamps
the
attributes
in
the
context
on
all
signals
that
are
emitted
or
the
context
is
active
like
if
you
start
the
span,
you
look
at
the
context
and
just
set
all
the
attributes
in
the
context
the
span
attributes
and
it
would
also
work
for
matrix
and
logs,
probably.
I
B
Yeah
I
saw
that
traffic
already
commented
that
he
supports
this.
One
even
keeps
details
about
that.
Jimmy
also
mentioned
he's
on
the
call.
Well,
there's
not
enough
time
to
discuss
that.
He
also
show
interest
in
this
one.
So
I
think
that's
that's
a
good
proposal.
What
would
be
interesting,
based
on
what
mentioned
before,
to
have
somebody
that
could
implement
a
prototype,
maybe
for
your
consideration
in
a
different
language.
B
Oh
perfect,
yeah.
Thank
you
yeah!
Okay,
we
have
only
one
minute:
ryan
is
leaving
you
know
from
the
profiling
group
leaving
some
links
in
the
discussion
document.
Please
take
a
look
at
that
one
other
than
that
we
are
out
of
time.
Thank
you
so
much
everybody
for
the
feedback
today,
let's
follow
up
on
that
stay
safe
and
talk
to
you
soon.