►
From YouTube: 2022-11-29 meeting
Description
cncf-opentelemetry@cncf.io's Personal Meeting Room
A
A
B
Yeah
this
was
brought
up
in
the
maintainers
call
yesterday,
and
I
saw
that
it
wasn't
on
the
agenda.
So
I
would
like
to
talk
about
it
here.
I.
In
my
opinion,
it
is
just
way
too
restrictive.
B
B
I
mean
the
way
it's
written
right
now.
It's
not
clear
whether
it
applies
to
only
the
API
and
SDK
or
also
instrumentations,
but
even
if
it
did
apply
to
the
API
and
SDK
I
would
say.
Yes,
one
I
think
that
it's
been
pretty
well
established
that
users
want
like
API,
convenience,
wrappers
and
that's
definitely
the
API
but
I.
What
we
talked
about
before
Thanksgiving
was
that
the
specification
on
the
API
was
meant
to
be
strict,
but
on
the
SDK
it
was
meant
to
be
a
minimum.
C
Just
just
for
clarity
is
it
that
it's
saying
you're
not
allowed
to
implement
any
additional
features?
Is
that
the
part
that's
too
strict,
yeah.
B
C
B
Mean
the
the
part
that
says:
You
must
Implement
any
any
must
or
what,
like
that
seems
fairly
obvious
to
say:
You
must
implement
the
full
spec,
but
to
then
say
you
can't
Implement.
Anything
else
makes
it
impossible
to
prototype
new
features
in
a
spec
compliant
way
and
yeah
I
I
just
think
it's
too.
D
Strong,
so
I
was
one
of
the
approvers
and
the
way
I
read.
This
was
not
as
strict
as
you're
interpreting
it
like.
Basically,
if
you
want
to
prototype
a
new
feature,
you
need
to
clearly
have
it
in
an
experimental
location
or
like
it's
obvious.
It's
not
necessarily
part
of
the
API,
but
it's
an
extension
to
it,
and
then
it's
okay.
D
But
if
you
feel
like
that
would
prevent
this
the
way
it's
worded
I'd
suggest
we
should
change
the
wording,
because
that,
like
yeah
I
agree
with
you,
if
it's
like
you
can't
make
any
changes
outside
of
exactly
what's
specified
in
the
SDK.
That
is
too
restrictive.
I
do
think.
There's
convenience
apis
that
languages
need
it's
just
I've
like
we
kind
of
want
to
be
clear
or
put
them
in
some
place
where
if
the
spec
makes
a
change,
we
don't
break
convenience
features
like
we
want
to
avoid
that,
but
Link
in
the
dependency.
D
That's
the
goal
of
this.
It's
not
to
say
that
you
shouldn't
have
an
elegant
API
for
your
language.
So
if
this
is
preventing
you
doing
that
work,
then
I
think
it
does
need
to
be
fixed,
but
that
wasn't
my
read
of
it.
My
read
of
it
was
just
that
it
needs
to
be
clearly
not
part
of
the
open,
Telemetry
API
and
clearly,
like
an
extension
convenience
thing.
E
Hey
I
was
one
of
the
people
that
commented
on
it
and
it's
good
to
see
all
of
you
in
person
that
haven't
actually
interacted
with
many
people
here.
E
I
think
that
yeah
I
understand
specifically
read
in
different
ways.
It's
one
of
the
things
that
makes
them
challenging
is
trying
to
account
for
all
of
those
different
interpretations,
and
you
know
what
you
just
described.
I
think
is
a
lot.
You
know
it's
something
that
I
wouldn't
worry
about
nearly
as
much
so
yeah
we
could.
It
could
just
be
as
simple
as
we
update
it
to
be
a
little
more
clear
about
what
we
mean
and
then
that
sort
of
takes
care
of
a
lot
of
my
complaints.
E
Really
I
was
worried
that
it
would
just
be
difficult
to
do
it's
not
impossible,
but
a
lot
more
difficult
and
we'd
always
be
in
this
weird
gray
area
of
well
now.
Are
we
out
of
compliance
with
this?
Are
we
in
compliance
Etc,
saying
what
you
described
would
fix
that
and
it's
good
to
have
really
clear
guidelines
about
how
to
do
the
experimental
work.
I
think
that's
a
nice
clarification,
but
also
I
wasn't
in
the
the
maintainer's
call.
So
I
don't
know
I
would
wonder.
Are
there
additional
motivating
cases?
E
Have
we
seen
this
come
up
a
lot
in
the
past
or
or
more
recently,
that
that
would
drive
the
need
for
a
spec
change
about
it?
You
know
it
might
also
be
that
we
wait
to
see
if
there
are
additional
instances
that
would
justify
changing
the
spec
in
this
particular
way
and
I
don't
know
if
there
was
additional
motivating
cases.
Maybe
somebody
has
some
some
clarity
on
that.
A
Basically,
we
have
a
prior
Point
regarding
how
to
handle
and
clear
situations
where
there
is
like
room
for
interpretation
and
that
you
know
that
branches
into
these
yeah.
So
we
basically
we're
trying
to
be
kind
of
preemptive.
You
know
about
making
allowing
things
that
could
you
know,
create
confusion
amounting,
for
instance,.
E
A
Yeah,
okay,
so
in
that
case,
I,
guess
that
my
question
is,
it
sounds
like
the
API.
That's
the
place
we
want
to
take
care
of
what
about
the
SDK.
I
would
like
to
hear
what
George
Stewart
has
to
say
about
the
SDK
part.
What
do
you
think?
Do
you
think
we
should
go
for
that
part
as
well,
or
only
care
about
the
API
part.
D
I
I
think
the
focus
should
be
on
the
API.
There's,
specifically
the
one
of
the
reasons
we
have
flexible,
sdks
and
I.
I
know
this
was
the
thinking
in
the
in
the
Java
seg
as
well.
Is
you
know,
open
Telemetry
provides
a
baseline,
that's
supposed
to
be
general
purpose,
but
there's
should
be
room
for
like
say
a
hyper
optimized.
D
F
I
remember
like
to
talk
about
this
a
couple
weeks
ago,
and
one
of
the
questions
is
certain
language.
They
decided
to
implement
something
in
the
ick
and
later
the
same
thing
got
covered
in
the
specs,
but
in
a
different
way.
What
does
that
mean?
F
Does
that
means
the
SDK
maintenance
vote
decide
to
make
the
breaking
change
by
bouncing
the
major
version,
or
they
will
just
say
full
age.
We
already
Implement
that
in
a
different
way,
so
we'll
keep
it
as
is
or
it
will
require
the
spec
to
give
blacks
by
saying,
despite
encourage
people
to
implement
this
in
the
a
way.
A
E
Yeah
I
was
just
gonna,
say
you
know,
as
someone
working
on
a
language
SDK
if
I
were
to
implement
a
feature
that
was
then
covered
by
the
spec,
but
in
a
different
manner.
Personally,
I
wouldn't
be
offended
or
surprised.
If
I
was
then
required
to
change
my
implementation
to
match
I,
wouldn't
it
could
that
be
annoying.
Certainly
nobody
likes
to
change
code,
but
that's
what
I
would
expect
to
be
required
of
me.
Actually,
I
wouldn't
view
that,
as
particularly
upsetting.
C
The
thing
we
we
really
care
about
and
partially
part
of
the
reason
why
I
think
there's
nervousness
and
desire
to
be
restrictive.
Is
we
really
care
about
strict,
strict
backwards
compatibility
for
the
API
packages
and
we
also
care
about
it,
for
you
know,
SDK
plug-in
interfaces
so
there's
anything
the
users
touch,
especially
if
it's
widely
touched
like
interfaces
that
are
going
to
be
implemented
multiple
times.
C
We
really
don't
want
to
be
thrashing
on
those
in
the
API,
the
instrumentation
API.
We
can't
change
it.
It's
it's
set
in
concrete.
Once
we
put
it
out
there
and
tell
people
it's
stable,
plug-in
interfaces.
We
need
to
have
overlap
like
one
to
three
years.
I
believe
this
is
written
down.
We
could
clarify
it.
So
if
you
decide
you
want
to
change
a
plug-in
interface,
you
need
to
not
mutate
the
existing
plugin
interface
but
add
a
new
one
and
still
support
the
old
one
for
some
period
of
overlap.
C
So
users
don't
get
stuck
in
a
position
where
their
choices,
either
the
plugins
they're
currently
using
or
the
new
SDK,
with
the
security
fix
that
they
want,
believes
a
lot
of
other
surface
area
like
the
stuff
people
use
to
install
open,
Telemetry
the
internals
of
what
the
SDK
is
actually
doing
so
I
wonder
if
that's
one
is
that
the
Nuance.
C
We
need
to
add
to
clarify
to
people
that
it's
the
the
API
packages
and
the
plug-in
interfaces
where
we
really
have
strict
compatibility
rules
and
thus
adding
something
that
might
get
put
into
the
Speculator
means
you
should
probably
go
to
the
spec
Community
before
doing
it,
at
least,
but
that
for
the
other
two
areas
of
installation
and
internals
to
the
SDK,
you
don't
you
don't
need
to
do
that
and
in
fact
you
should
do
whatever
you
can
to
make
those
things
as
Charming
as
possible
in
the
language
that
you're
implementing.
C
Just
like
a
weird
language,
Quirk
right,
they
are,
if
I
could
maybe
go
back
in
time.
I
would
what
we
call
the
API
I
would
more
specifically
call
the
instrumentation
API
so
that
we
could
say
instrumentation,
API
and
plug-in
API.
The
only
Quirk
is
like
you.
Don't
you
don't
put
these
in
the
same
place,
the
plug-in
interfaces
are
not
part
of
the
instrumentation
API.
C
C
More
clear
in
the
spec,
possibly
if
that's
not
clear,
the
difference
between
the
public
interfaces
on
the
SDK
versus
everything
else,
the
SDK
is
doing
internally,
but
I'm
curious.
Whether
this
is
the
actual
problem
being
solved
or
if
what's
causing.
This
change
is,
is
actually
being
motivated
by
a
desire
to
to
change
things
like
plug-in
interfaces
or
or
the
public
API,
or
something
like
that.
I
No,
so
the
thing
that
was
motivating
this
change
was
views
So,
currently
the
way
that
the
specification
had
listed
used
in
the
SDK.
It
was
a
essentially
like
a
prescriptive
way
to
define
a
function's
parameters
and
like
only
a
certain
set
of
parameters,
and
then
it's
only
a
certain
set
of
outputs
and
the
go
SDK
said
you
know,
be
really
cool
if
users
could
Define
that
function
themselves
and
they
wanted
to
expose
that
function.
I
But
then
there's
this
question
of
like
how
does
that
actually
conform
to
the
specification,
and
so
we
were
able
to
find
a
way
where
it
does
Define
a
function
that
does
conform
to
specification,
but
we
also
provide
that
functionality,
that's
external
to
the
users.
So
it's
an
extension.
I
It
ended
up
being
a
case
where
we
conformed
the
specifications.
So
we
saw
it
as
like.
That's
not
a
problem,
but
it
was
a
general
question.
There
I.
D
I
want
to
elevate
this
actually
because
that
specific
problem,
I
just
did
a
review
of
python,
which
I
would
argue,
is
the
only
conformant
exactly
to
the
specification
for
that
function.
Go,
as
you
said,
has
both
the
the
flexibility
for
how
you
do
like
attribute
filters
right,
four
views,
but
sodas.net
so
does
Java.
So
does
JavaScript
right,
like
I,
actually
don't
know
of
a
com.
Anyone
who
directly
complies
with
that
actually
meant
that
method
exactly
the
way
it's
specified,
except
for
Python
and
now
apparently
go
when
I
looked
into
it.
D
I
Yeah
I
I,
agree,
yeah,
I,
agree,
yeah.
I
Guess
so
I
mean
yeah,
I
mean
I,
guess
so
it
I
don't
know
it's
kind
of
details
on
on
specifics
of
code,
but
essentially
it's
like
saying
if
the
specification
says
that
you
know
you're
only
allowed
to
do.
You
know
this
mapping
to
this
mapping
and-
and
we
still
allow
that,
but
we
also
say
like
you
can
Define
whatever
mapping
you
want.
So
it's
essentially
like
a
meta
form
of
that
is
how
it's
I
think
defined.
D
Yeah
yeah,
specifically
the
specifications
like
you
define
a
set
of
labels,
but
everyone,
almost
every
language,
has
defined
a
function
that
takes
a
set
of
labels
and
returns
a
set
of
labels
instead
that
it
takes
as
that
parameter
instead
of
just
a
set
of
labels.
D
So
that's
that's
why
everybody's
more
flexible
and
that
I
should
say
attributes
not
labels.
Sorry
I'm
in
Prometheus
world
too
much
anyway,
yeah.
So
so
that's
what
everybody
did
in
practice
and
again,
when
I
did
the
the
review
to
check
compliance
across
like
python,
C,
plus
plus
Java.
That
sort
of
thing
almost
everybody
is:
has
that
flexible
method
and
like
I,
think
Python's
the
only
one
that
directly
implemented
the
strict
just
set
method
and
that's
it.
D
So
that's
that's
an
interesting,
a
very,
very
interesting
use
case
and
I
think
this
is
also
where
I
do
think.
The
spec
needs
to
be
updated
to
be
more
flexible,
especially
given
I
think,
like
javan.net,
only
allow
the
flexible
method
anyway,.
J
C
There
are
places
in
the
spec
where
defining
implementation
details
because
it's
helpful,
but
the
thing
I
personally
care
the
most
about
is
backwards,
compatibility
and
the
ability
to
maintain
that
and
everyone
who's
a
maintainer
on
this
project.
C
Being
on
like
the
same
page
about
how
backwards
compatibility
works,
I
kind
of
feel,
like
that's
the
Golden
Rule,
and
as
long
as
we're
we're
caring
about
that,
then-
and
you
using
our
judgment
about
whether
or
not
it's
safe
to
to
go
off
and
do
this
without
talking
to
the
rest
of
the
community,
because
you're
going
to
be
able
to
handle
the
any
changes
like
you're
going
to
be
able
to
handle
the
compatibility
you
know
effectively
according
to
the
way
we
want
to
do
it
that
that's
that's
the
way
I
would
like
to
to
see
it
work
personally.
I
Yeah
and
I
think
if
that
was
kind
of
our
our
take
on
that
as
well,
and
in
fact,
I
I
know
in
the
ghost
again
I
think
I've
seen
it
as
well
and
multiple
other
things
is
when
we
have,
you
know,
feature
requests
that
come
in
that
say,
you
know,
please
add
X
and
it's
something
that
is
more
Universal
It's.
Usually
the
response
is
like.
I
We
need
to
add
that
to
the
specification
before
we're
going
to
implement
that
and
go
kind
of
the
stance
that
we
take
for
things
that
are
like
this,
where
it's
a
functional,
maybe
a
beneficial
thing,
I
think
that
we're
more
like
the
only
reason
that
we
wouldn't
want
to
add
is
if
this
book
came
along
and
said
it
explicitly
that
you
must
not
allow
users
to
configure
this,
which
has
not
been
the
general
sentiment
that
we've
seen
and
talked
about
in
the
spec
yeah
I
think
that
we
were
more
open
to
allowing
that
and
not
more.
I
We
were
confident
in
allowing
that,
but
yeah
I
mean
I
think
that
from
a
maintainer's
perspective
like
we
have
that
kind
of
in
line
with
already.
J
Yeah
I
was
in
favor
of
this,
because
I
think
it
codifies
what
you
just
said:
Tyler.
J
So
if
users
come
along
and
ask
for
some
feature
that
doesn't
exist,
we
should
encourage
that
feature
to
be
added
to
the
spec
first
and
not
go
off
implementing
different
features
in
different
ways
and
allowing
the
languages
to
diverge,
and
so
I
I
hope.
This
doesn't
have
the
chilling
effect
that
Daniel
described
I
hope
that
every
language
has
come
up
with
their
own
ways
to
prototype
and
have
experimental
features,
and
you
know
I
I
think
a
good
workflow
is
if
a
new
feature
is
requested.
J
H
B
I
think
it
also
needs
to
be
clarified
whether
this
applies
to
only
the
API
and
SDK
or
also
to
instrumentations,
because
if
it
applies
to
instrumentations,
then
it
is
not
permissible
to
create
any
instrumentations
which
are
not
already
specified
by
semantic
conventions.
A
J
And
and
on
the
point
of
you
know,
I
think
Josh
was
talking
earlier
about
whether
they
should
apply
to
the
SDK
as
well.
J
So
my
rate
of
the
SDK
specification
is
that
the
shoulds
and
musts
in
there
are
describe
what
the
the
reference
implementations,
which
is
what
I
think
the
which
is
what
I
think
of
when
we
talk
about.
You
know
the
open
Telemetry
branded
distributed
versions
of
the
SDK.
If
somebody
wants
to
come
along
and
come
up
with
their
own
SDK
that
you
know
is,
is
you
know
for
their
for
their
vendor
or
something
like
that?
J
A
Okay,
for
the
sake
of
time,
do
we
want
to
take
that
offline?
Really,
you
presented
initial
PR.
Probably
you
can
put
iterate
on
that.
One
yeah.
A
I
can
take
you
over
from
you,
so
let's
talk
offline
yeah,
let's
discuss
and
yeah
I
used
to
speak
that
because
of
the
things
we
were
requesting
here,
we
will
have
to
do
a
few
reviews
over
that.
So
I
will
be
asking
poking
all
of
you
to
go
review
that
until
we
have,
you
know
something
that
satisfies
everybody.
Hopefully
yeah.
F
I
A
Okay,
in
that
case
yeah,
thank
you
so
much
for
that.
The
next
one
tip
process
on
okay.
C
Great,
so
if
we
go
into
this
proposal
here,
what
this
is
a
proposal
for
how
to
tackle
stabilizing
all
of
our
existing
semantic
conventions.
So
just
for
clarity,
we
have
a
bunch
of
semantic
conventions.
They're
listed
down.
H
C
Things
of
that
nature-
and
none
of
it
is
currently
marked
as
stable.
It's
all
marked
as
experimental,
almost
all
of
it
needs
or
not,
almost
all
of
it.
All
of
it
needs
another
pass
before
it
can
be
marked
as
stable.
We
haven't
defined
metrics
for
any
of
these
things,
notably.
C
However,
this
is
so
much
work
that,
if
we
don't
do
it
in
an
organized
fashion,
where
the
working
groups
focused
on
implementing
this
stuff
work
quickly
and
get
attention
at
the
appropriate
time.
In
other
words,
if
we
aren't,
you
know
well
organized
to
to
get
this
stuff
done
and
instead
work
on
it,
as
we
have
been
working
on
it,
which
is
working
groups
meet
once
a
week
fairly,
slowly
produce
spec
proposals.
Those
proposals
get
kind
of
reviewed
on
an
ad
hoc
basis.
C
Of
the
envelope
math,
based
on
how
we've
been
going
it'll,
take
us
about
nine
years
to
get
through
the
remaining
work
and
I'm,
not
exaggerating
doing
it
quickly.
According
to
this
proposal,
we
would
be
done
halfway
through
2024
I
think,
that's,
that's
the
absolute
fastest.
We
could
move
on
this,
so
it's
a
lot
of
work
and
I
think
we
need
to
be
more
organized
and
how
we
go
about
doing
this
work.
Then,
we've
been
with
with
other
parts
of
this
specification
specifically.
H
C
One
of
the
big
hold
ups
that
we
have
often
is
we
don't
feel
comfortable.
Approving
this
work
and
the
working
groups
don't
often
have
a
a
large
representation
of
like
spec,
approver
spec
community
members,
because,
generally
speaking,
we
aren't
a
group
of
subject
matter
experts
on
all
of
these
different
domains.
C
C
So
we
can
feel
confident
that
that
we're,
actually
you
know,
approving
something
sane
for
how
we
should
be
instrumenting
and
monitoring
Cassandra,
for
example,
and
we
want
to
make
sure
that
the
spec
approver
and
like
TC
Community
is
aware
of
this
stuff
has
time
on
their
schedule
to
deal
with
it.
If
we
don't
feel
like,
we
have
enough
domain
knowledge
on
the
approver
side
kind
of
reaching
out
and
making
sure
we
get
that
fixed.
C
So
since
this
is
more
processed
than
we've
ever
had
I've
put
together
a
document
proposing
how
we
should
do
it.
Just
real
quick
just
as
people
read
this
and
provide
feedback
we'll
be
talking
about
it,
I
think
again
and
again,
and
there's
also
the
semantic
conventions
working
group
that
meets
every
other
week,
where
we
talk
about
this
stuff
in
more
detail,
but
just
to
go
over
the
proposal
as
it
stands.
C
Briefly,
it's
a
three-quarter
process,
so
the
first
quarter,
which
is
quarters
12
weeks
by
the
way
first
quarter,
we're
just
gonna
do
preparation.
So
this
is
just
making
it
super
clear
that
we're
announcing
it
to
the
world
that
we're
going
to
be
tackling
one
of
these
domains
and
we
spend
that
time
trying
to
get
subject
matter.
Experts
in
and
the
end
goal
of
this
is
creating
a
specification
pro
project.
If
you
haven't
seen
this,
we
have
a
project
management
doc.
C
We
haven't
really
been
implementing
this
process
because
we
haven't,
we
haven't,
had
a
lot
of
new
initiatives
since
we
wrote
it,
but
this
project
management,
doc
kind
of
explains
how
you
put
together
one
of
these
working
groups,
it's
kind
of
like
a
list
like
a
checklist
to
make
sure
that
you've
actually
defined
what
this
working
group
is
going
to
tackle
and
who's
involved
with
it
in
a
way
that
the
TC
can
then
actually
like,
approve
it
and
get
it
on
the
radar.
C
So
the
goal
of
this
first
quarter
is
to
get
that
together,
which
might
take
a
while,
because
we're
going
to
need
to
organize
subject
matter
experts
and
since
we
want
to
work
in
kind
of
a
concentrated
manner.
That
means
those
working
group
members
need
to
actually
have
time
available
at
most
organizations,
there's
like
a
quarterly
planning
process,
so
it
seems
difficult
to
go
faster
than
than
a
quarter.
So
one
quarter
to
organize
a
working
group,
one
quarter
to
do
the
actual
specification
work.
C
This
would
mean
six
weeks
for
that
working
group
to
prepare
all
of
those
oteps
or
spec
PRS
or
whatever
it
is.
They
think
they
need
to
propose
and
get
those
together
and
then
on
week,
six
or
before,
but
the
TC
can
have
it
and
the
spec
approvers
can
have
it
on
their
calendar
that
we're
going
to
have
a
period
of
public
commentary.
C
So
all
that
work
will
be
ready
to
then
have
a
four
week
period
of
public
commentary
and
if
we
can
work
through
all
of
that,
then
two
weeks
to
actually
clean
up
and
merge
the
spec
PRS
I.
C
Is
way
faster
than
we've
ever
worked
on
these
things,
because
we
tend
to
work
on
a
weekly
meeting
Cadence,
so
this
would
mean
these
working
groups
would
be
meeting
more
frequently
or
working
through
like
a
GitHub
project
or
something
to
to
work
faster.
So
six
weeks
is
a
different
kind
of
working
group.
G
Ted
I
have
a
question
for
you.
We
tend
to
We,
tend
to
not
over
specify
I
think
that's
the
term
that
we're
using
in
all
texts,
so
I
feel
like
only
two
weeks
for
the
specification
where
we
actually
specify
things
like
clearly
specified.
Things
is
to
it's.
It's
a
very
limited
time.
Unless
you
change
the
expectations
that
in
Otep
we
do
a
more
specified
thing
like
yeah
how
to
express
it.
Otherwise,
but
but
but
the
the
tendency
so
far
was
that
Otep
is
the
high
level
thing.
C
Josh
surris
has
brought
this
up
and
and
I
agree.
Whatever
is
getting
proposed,
like
whatever
it
is,
that
gets
approved
in
this
public
period,
and
this
review
needs
needs
to
basically
be
spec
PRS
or
close
enough
to
spec,
PRS
and
yeah.
We
have
this
process
that
kind
of
splits
it
out
where
you
get
the
Otep
approved,
and
then
a
lot
of
things
can
change.
When
you
go
from
Otep
to
PRS,
so
I
agree
we
need
to.
G
So
then,
then
maybe
I
don't
know,
maybe
think
about
an
example
like
in
my
opinion.
Otep
should
then
be
less
work
because
you
just
proposed
a
high
level
you're,
probably
gonna
mention
like
a
couple
of
attributes
or
whatever
something.
H
C
Yeah
I
think
that
that
seems
reasonable
to
me.
I
think
we
have.
We
have
a
bit
of
time
to
to
work
this
out
and
we
have
a
set
of
working
groups
that
are
currently
in
flight,
so
the
stuff
we're
currently
defining
that
we
have
like
active
groups
on
is
HTTP
messaging
and
rum
or
client,
like
the
three
groups
that
are
currently
working.
So
my
recommendation
is
we
try
to
look
at
what's
been
going
on
here
and
see?
C
If
we
can,
we
can
fix
the
the
problems
with
the
current
process,
but
yeah.
This
is.
This
is
something
that's
just
different
than
what
we've
done.
I
think
we
need
to
to
figure
it
out,
and
then
the
third
quarter
is
actually
implementing
this
stuff.
C
This
is
another
thing
we
haven't
really
done,
because
what
we're
talking
about
implementing
here
are
not
core
SDK
components,
but
a
bunch
of
contrib
projects
and
contrib
instrumentation
plugins
things
like
that
and
all
the
different
languages
are,
are
pretty
uneven
currently
in
terms
of
how
they're
managed
and
how
much
active
maintainership
of
them
is
actually
available.
This
is
only
natural.
C
These
plugins
don't
tend
to
be
the
kind
of
thing
that
results
in
like
a
big
maintainer
Community
around
individual
plugins,
but
we
we
do
need
to
to
come
up
with
a
process
for
when
we
actually
change
update
how
you
know,
databases
should
be
instrumented
that
we
then
once
that's
approved,
immediately,
moved
to
to
updating
our
currently
available
instrumentation
to
to
match
the
spec
and
I.
C
G
So
here
here
Ted,
it
will
be
good
to
clarify
a
bit
the
relationship
between
config
repos
and
core
repos,
one
one
thing
that
I
observed
in
the
past
in
couple
of
con
instrumentation
country
artifacts
that
I've
used
from
open
Telemetry,
they
are
far
at
least
in
some
languages.
They
are
far
less
maintained
and
less
quality
than
the
core
ones.
So
here
is
not
to
blame
anyone.
It's
just
that
people
don't
care
that
much
about
those
yeah.
G
So
so
probably
what
one
thing
that
we
can
do,
maybe
is
involve
the
core
maintainers
a
bit
more
into
this
I,
don't
know
but
think
about
a
solution,
because
other
I
I
feel
like
there
is
a
huge
difference
in
quality
and
and
unless
we
fix
some
of
that,
I
I,
don't
know
if
this
plan
will
scale
for
you,
yeah.
C
C
They
aren't
like
a
long-term
member
of
our
community
or
it
was
stuff
that
was
brought
into
open
Telemetry
as
part
of
like
a
one-time
push
like
porting
over
a
pile
of
datadog,
instrumentation
and
other
stuff,
like
that,
traditionally
the
the
spec
language
maintainers,
the
language
maintainers,
have
said
they
don't
have
bandwidth
to
manage
all
of
the
instrumentation
plus
churn
through
you
know
all
of
the
the
SDK
work
that
they
have
to
do,
which
is
reasonable,
so
I
think
on
a
language
by
language
basis.
C
We
kind
of
have
to
figure
out
how
we
do
this,
but
we're
going
to
need
effort
from
the
member
organizations
and
the
community
to
at
least
provide
effort
for
for
doing
the
work
of
of
updating
these
things.
So
I
would
like
to
separate
you
know:
how
do
we
get
these
things
updated
and
how
do
we
make
sure
we're
responding
to
like
issues
in
PRS
long
term.
G
Yeah,
but,
but
something
that
you
need
to
take
care
of,
if
you
are
leading
this
effort,
is
something
that
would
to
to
be
aware
of
this
problem
into
to
propose
a
feasible
solution.
C
My
Hope
Is
that
with
the
main
core
apis,
like
logging,
metrics
and
tracing
being
kind
of
finalized
in
the
spec
that
it'll
be
possible
for
the
language
maintainers
to
to
start
concentrating
on
things
like
you
know
the
contrib
and
how
that
works,
and
you
know
config
files
and
things
like
that.
So
I'm.
C
Maintainers
will
feel
less
Under
Pressure,
like
they
have
a
huge
pile
of
of,
like
large
lifts
that
they're
going
to
have
to
do
in
the
SDK,
but
yeah.
This
is
good
feedback,
okay
and
people.
Please
comment
on
this
and
leave
your
feedback
because
we'll
have
to
I.
Don't
want
to
take
up
the
rest
of
the
meeting
final
thing
just
to
to
go
over
here
is
a
timeline.
We
should
come
up
with
a
rough
timeline
of
when
we're
kicking
these
things
off.
C
This
is
basically
a
question
of
like
parallelization,
like
how
much
of
this
work
do.
We
feel
like
we
can
move
through
this
three-quarter
pipeline
at
the
same
time,
because
this
work
will
stack
up
right.
Everything
we
kick
off
in
q1
next
year
and
Q2
will
be
specifying
that,
while
trying
to
reach
out
for
people
to
join
the
next
round
of
working
groups
and
then
by
Q3
we'll
be
implementing
the
work
that
we
specified
in
q1
and
we'll
be
kicking
off
the
spec
groups
that
we
tried
to
get
together
in
Q2
Etc.
C
B
I
have
a
couple
of
quick
questions.
The
first
is,
how
did
you
come
up
with
this
order
and
and
prioritization.
C
Yeah,
so
again,
this
can
all
be
changed,
but
I
looked
at
was.
This
is
what
we're
currently
doing.
So
we
should
finish
finish
this
stuff
and
after
that,
the
next
core
domain
was
networking
right.
We
have,
we
haven't,
marked
anything
to
do
with
TCP
IP,
like
the
the
networking
section
of
the
semantic
conventions
for
how
you
Define
peer
addresses
and
things
like
that.
That's
all
still
experimental
and
besides
HTTP
we've
defined
RPC.
C
It's
like
the
other
main
thing
related
to
that.
So
this
seemed
like
a
chunk
of
relevant
work
and
I,
wouldn't
want
to
go
in
and
try
to
Define
databases
and
other
higher
level
things
without
first
locking
down
at
least
how
we're
going
to
Define.
You
know
lower
level
networking
questions.
B
B
Yeah,
what
about
work
that
does
not
fall
into
one
of
these
categories?
I'm
thinking
of,
for
example,
the
feature
flagging
is
that
just
on
hold
while
it's
not
in
a
current,
you
know
whatever
we
call
these,
if
it's
not
in
one
of
these
in
the
working
time
like
if
it
is
not
a
network
domain
or
an
RPC
domain,
and
that's
what
we're
working
on
in
that
quarter
then
do
we
just
say
this
is
on
hold
until
it's
approved
later
I.
C
Think
it's
it
I
would
say
for
things
coming
in
to
be
marked
as
experimental.
We
should
we
should
not
hold
those
up
while
we
work
through
stabilizing
these,
but
I,
don't
think
anything
should
jump
the
queue
and
go
straight.
You
know
straight
to
stable
right,
so
I'm
not
sure
how
it.
D
Would
I
I
can
I
phrase
this
a
different
way,
so
the
the
idea
here
is
to
gate
how
many
we
do
concurrently,
based
on
availability
of,
like
spec
approvers,
to
pay
attention
to
what's
going
on
so
like
the
idea
behind
this
process,
it's
like
the.
If
feature
Flags
would
like
to
be
running
concurrently
right.
D
The
question
is:
can
they
get
enough
spec
approvers,
to
make
one
of
these
groups
and
run
through
the
process
at
this
time,
because
the
the
fear,
the
thing
we're
trying
to
avoid
is
not
having
enough
people
who
understand
open,
Telemetry
and
the
subject
matter,
experts
aligned
at
the
same
time
to
drive
the
feature
right.
D
So
what
is
likely
to
happen
is
this
is
kind
of
a
list
of
like
Hey
we're
gonna
go
try
to
kick
these
off
but
like
if
feature
Flags
would
like
to
form
a
group
and
they
managed
to
get
enough
spec
approvers
attached
to
that
group.
We
should
kick
it
off
because
that's
a
sign
that
there's
enough
interest
and
the
community
has
enough
bandwidth
to
handle
it.
D
What
we
want
to
avoid
the
primary
thing
is
about
avoiding
overextending
ourselves,
where
you
know
like
Ted,
was
saying
if
we
can't
get
enough
spec
approvers
to
attach
to
one
of
these
domains.
We
probably
shouldn't
address
it
just
yet,
because
we
won't
be
able
to
pay
attention
to
what
that
group
does,
and
that
has
led
to
friction
and
that's
what
we're
trying
to
avoid
yeah.
B
So
I
I
was
asking
these
sort
of
leading
questions
intentionally.
I
was
going
to
propose
an
alternative
process
which
would
be
that
the
Otep
is
just
essentially
the
charter
for
a
working
group
and
specifies
the
scope
that
they
are
trying
to
tackle
and
that's
it
and
then
in
each
quarter
the
TC
would
approve
some
number
of
these
Charters.
Probably
each
one
would
have
to
have
a
TC
liaison
or
contact
or
whatever
you
call
it,
but
the
the
charter
would
say
this
is
the
group
of
people
we
have
together.
C
C
So
so
for
clarity-
that's
that's
that's
already
in
here
we
we
have
a
process
that
we
defined
for
creating
these
working
groups
based
on
creating
a
project
that
project
it's
a
project
tracking
issue.
All
of
this
information.
C
What
are
the
deliverables?
Who
is
Staffing
it?
How
are
they
planning
a
meet?
What
timeline
do
they
expect
to
hit?
All
of
that
has
to
get
put
into
an
issue
and
then
approved
these
projects,
then
go
through
a
life
cycle
which
is
tracked
in
this
board
here.
We're.
C
So
this
board
here
so
we
should
be
able
to
see
what's
been
scheduled,
what
we're
currently
working
on
and
what's
been
completed
so
so
we
have,
we
do
have
a
process
for
this,
so
I
don't
think
we
need
to
use
oteps
for
it
because
we
have
this
process,
but,
as
is
bugged
and
alluded
to,
we,
we
do
need
to
figure
out
how
to
define
the
deliverables
in
a
way
where
you
know
what
are
these
working
groups?
C
What
do
they
need
to
actually
like
produce
in
this
period
before
public
commentary,
and
then
how
do
we
like
quickly
integrate
that
into
the
spec
once
the
commentary
period
is
over?
So
does
it?
Do
you
think
Dan?
Do
you
think
that,
like
answers
answers
your
concern?
There.
B
D
B
I
have
if
me
and
a
group
of
people
have
have
an
idea
for
some
set
of
command
semantic
conventions.
How
we
get
on
the
schedule
like
what
is
required
of
us.
How
do
we
even
get
in
contact
with
a
TC
member
to
yes
like
that
that
whole
thing
just
it
seems
like
if
you're
not
already
an
Insider,
there's
no
way
you're
going
to
get
this
done.
C
I
totally
agree:
we
do
need
to
figure
out
how
we
publicly
advocate
for
this
stuff,
so
we're
going
to
spend
a
quarter
trying
to
publicly
Advocate.
We
have
this
project
management
workflow,
but
it's
it's
new.
We
Define
this
over
the
summer,
but
then
I
went
away
for
three
months
and
you
know
we
haven't
really
used
it.
B
H
B
Say
it
should
almost
go
the
opposite
way
once
a
group
of
people
with
sufficient
bandwidth
and
motivation
has
gotten
together
and
decided
they
want
to
do
it,
they
should
submit
a
candidate
Charter.
We
are
this
group
that
exists
that
wants
to
to
do
that.
If,
if
you
feel
like
something
is
a
priority
and
you'd
like
to
go
out
and
try
to
build
one
of
those
groups,
anyone
is
welcome
to
do
that
and
we
could
have
a
timeline
for
if
other
groups
have
not
submitted
then
these
are.
B
This
is
the
priority
that
we're
going
to
go
out
and
try
to
build
these
groups
for,
but
I
think
having
the
process
be
more
outside
in
rather
than
inside
out.
D
H
D
Again,
the
way
to
think
about
it
versus
like
the
way
it
reads
initially
and
we
can
update
the
doc
to
reflect
this
here-
are
the
areas
we
think
otel
needs
to
directly
go,
invest
in
as
our
community.
If,
other
you
know,
groups
come
into
us
and
say
Here's
a
semantic
convention,
we
think
it
needs
to
exist
and
we
get
the
required
Staffing.
The
process
should
allow
that
as
long
as
the
required
Staffing
is
there
for
that
effort.
D
I
think
the
the
timeline
is
more
us
asking
ourselves
when
it
comes
to
semantic
conventions
when
it
comes
to
instrumentation.
What
are
the
priorities
that
we
think
we
need
to
focus
on
that
we
can
communicate
externally,
where
we
already
know
like
this
group,
you
know
do
like
we're
focused
on
HTTP
RPC
networking.
Like
communication,
that's
obvious!
That's
like
part
of
distributed
systems
right
cool.
D
We
think
that
that's
a
focus
area
that
we
need
to
actually
go,
invest
in
so
I
I
think
what
I'm
trying
to
say
is
the
way
that
you're
describing
the
process
should
be
exactly
how
the
process
is
it's
about
finding
enough
required
Staffing.
That
second
portion
of
this
document
is
more
if
we
look
at
ourselves
as
open
Telemetry
and
what
we
think
we
need
to
go,
invest
in
now.
D
What
do
we
think
we
go
out
and
try
to
build
enough
Staffing
for
as
I
was
saying,
I
fully
expect
us
not
to
staff
all
of
these
projects
or
be
able
to
in
the
timeline
listed
I.
Think
we'll
be
able
to
get
a
good
bit
and
I'd
love
to
get
all
of
them
for
sure,
but
I
just
don't
think.
That's
fully
realistic.
D
C
And
I
think
that
should
be
also
more
broad
than
just
just
these
semantic
conventions.
The
intention
with
this
project
management
and
this
project
board
is
to
have
all
future
spec
work.
That's
large
enough
that
it
needs
a
group
to
think
about
it
to
like
come
in
through
this
process,
so
that
we
have
a
way
of
basically
managing
our
attention
and
just
clarifying
as
a
group
like
what
what
is
it
we're
doing
and
when,
as
a
community,
are
we
expected
to
pay
attention
to
these
things
and
I'm.
E
C
A
Thank
you
so
much
for
that.
For
the
sake
of
time,
maybe
we
can
spend
there.
Thank
you
so
much
yeah,
the
last
minute
you
know
poking
people
about
what
is
important,
so
I
would
just
mention
very
briefly.
The
one
I
put
their
OTL
PJs
on
stability.
That's
a
PR
that
Tigres
put
together.
You
got
some
reviews.
I
saw
that
book
that
you
commented
something.
So
hopefully
we
can
figure
out
the
last
pieces
there.
A
So
we
can
go
ahead
and
merge
that
probably
the
next
one
which,
because
it's
pretty
quick,
Bogdan
yeah,
he
put
there
that
the
last
week
of
December
we
have
a
few
calls
canceled
just
for
your
information,
so
don't
be
surprised
and
finally,
yeah
George
Suarez
same
com.
D
Yeah
I
think
these
we're
gonna
have
to
take
a
offline
for
sure
there's,
just
a
set
of
conversations
that
I
think
are
somewhat
urgent
and
important
around
declaring
stability
for
semantic
conventions
effectively
we're
prioritizing.
We
have
a
lot
of
understanding
of
spans
and
span
cement
conventions.
Metrics
are
joining
in
and
there's
a
lot
of
things
arising
from
that
we're
also
trying
to
make
sure
we're
compatible
with
Prometheus
in
the
open
metric
spec.
So
there's
been
a
few
things
that
have
been
open.
That
I
think
are
interesting
just
to
highlight.
D
We
use
a
different
specification
for
units.
The
nice
thing
is
this
is
a
general
specification.
It
allows
you
to
internationalize
your
units
and
all
that
kind
of
junk,
but
it's
also
different
than
pretty
much
all
other
metric
systems
outside
of
open
census,
and
so
do
we
want
to
keep
that
or
not
I
want
to
get
pros
and
cons
collected,
and
we
can
have
the
discussion
later.
D
The
other
thing
to
highlight
is
the
man
brain
is
dead,
sorry
using
seconds
instead
of
milliseconds.
There's
a
lot
lot
of
comments
in
that
I.
Think
there's
going
to
be
a
lot
of
discussion
that
needs
to
happen
I'd
like
for
that
to
continue
in
the
bug,
and
we
can
bring
the
highlights
of
that
discussion
here
for
resolution
in
the
next
meeting
and
then
common
attributes
between
metrics
and
spans,
there's,
actually
an
open
question
of
whether
or
not
we
should
share
attributes
between
metrics
and
spans
or
allow
them
to
diverge.
D
The
example
is
HTTP
status
being
like
5xx
in
a
metric
versus
like
500
501
502
and
an
integer
in
the
span.
So
that
is
a
question
that
people
have
raised.
That
I
think
deserves
an
answer
from
this
community
and
so
I.
Just
at
this
point
want
to
collect
concerns
and
issues
from
people
and
then
we'll
Elevate.
The
top
level
General
concerns
for
a
discussion
later,
foreign.
A
Okay,
so
I
think
that's.
We
are
good
by
the
way,
we'll
just
drop
our
last
PR
in
the
dogs
regarding
low
memory,
temporary
preference
thing
we
don't
have
to
discuss
that
here.
Just
please
take
a
look.
Likewise
secretary
reviews,
yeah,
we
just
need
more
ice
on
that
one.
C
Nope,
just
if
everyone
could
please
review
the
doc
and
leave
comments,
any
questions
concerns
confusions.
It's
definitely
going
to
take
some
iterations
to
to
work
out
how
we're
going
to
tackle
this.
So
I
appreciate
all
of
that
foreign.
A
That's
not
enough
time
to
discuss
anything
else.
I
guess!
Thank
you.
So
much
everybody
see
you
around
stay
safe,
ciao.