►
From YouTube: 2022-08-08 meeting
Description
Open Telemetry Meeting 1's Personal Meeting Room
C
D
C
Happy
monday,
it
works
better
if
I
turn
on
the
other
lights,
because
it.
D
D
C
D
A
It's
all
for
appearance,
but
cool,
so.
A
A
So
we
have
a
pretty
small
agenda
today,
so
we'll
do
some
feature.
Work
updates,
oscar.
I
know
you
wanted
to
do
kind
of
like
a
in-depth
pr
review
on
the
front
end,
and
I
agree,
I
think,
that'd
be
a
great
use
of
our
time
to
get
that
pushed
forward.
Pierre
had
a
small
item
around
attribute
naming
just
so
we
could
get
that
unified
across
the
different
services
and
then
mikko,
and
I
think
ping
han
have
also
raised
like
doing
some
documentation
improvements.
A
I
know,
like
our
readme,
is
kind
of
a
bear
right
now
and
also
has
a
bit
of
overlapping
information,
so
we
can
talk
about
that.
And
finally,
if
we
have
some
time
we'll
also
just
review
some
repository
issues
and
see
if
anything
needs
like
further
discussion
or
anything
like
that,
any
other
potential
agenda
items
from
anyone.
A
E
Hey
guys,
yes,
first,
I
want
to
see
if
you
can
hear
me
well
because
I'm
from
the
airport,
so
I'm
going
to
show
you
how
my
independent
quality
right
now
my
microphone
communicates
with
me.
E
Okay,
so
I've
been
looking
at
through
the
the
comments
that
what
I
got
from
from
julian.
E
So
I
went
to
all
of
this.
I
think
we
started
walking.
So
actually
it's
not
available
today,
but
I
went
I
basically
fixed
whatever
he
was
saying
on
in
terms
of
what
they
composed
in
terms
of
having
my
single
file
like
kind
of
stuff,
and
I
post
the
latest
changes
and
everything
that
I
that
I
was
remaining
and
yesterday
so
I
didn't
have
the
internet
for
the
video,
so
there
everything
that
was
requested
has
been
changed
and
applied.
E
What
I'm
looking
to
see
now
is
that,
for
some
reason,
these
checks
are
not
being
always
been
executed,
and
since
I
require
like
a
one,
throw
a
flu
or
something
like
that,
so
this
pr
starts
like
reporting
those
validations.
E
So
what
I
would
like
to
know
is:
if
someone
can
help
me
with
this,
so
I
can
focus
on
everything
that
may
be
failing
and
after
I
I
should
start.
I
would
like
to
use
those
things
like
next
next
steps
and
yeah
next
steps.
A
Great
question,
so
I
just
triggered
the
workflows,
so
it
should
run.
I
think
it's
just
because
you're
a
new
contributor
and
it
requires
like
maintainer
approval,
so
this
workflow
should
be
processing
right
now,
we'll
see
if
anything
fails,
but
yeah
I'll
hand
it
back
over
to
you
for
feedback.
E
Sure
so
I
guess,
aside
from
that
I'll
require,
I
don't
know
who,
who
would
be.
You
know,
leading
the
afterward
process
for
this
pr.
So
I
can
guess
like
what
we
are
pushing
directly.
E
E
Actually,
I
think
I'm
going
to
be
working
on
that,
even
if
this
player
is
immersed,
I
will
I
will
kind
of
continue
working
on
whatever
it
is.
Instrumentation.
A
Okay,
so
so
it
sounds
like
outside
of
or
at
least
on
your
pr
you've
resolved
all
the
comments,
you're
just
waiting
for
the
checks
to
throw
any
issues,
and
it's
ready
for
kind
of
that.
That
final
review
of,
like
just
the
front,
end
itself,
no
instrumentation,
just
the
server
for
the
app
right.
A
Okay,
cool!
Well,
you
know
everyone
on
the
call.
Has
a
call
to
action,
go,
go
check
out
the
the
front
end
app.
You
don't
have
to
do
it
today.
Oscar
looks
like
three
or
four
checks:
we're
failing
mainly
around
like
markdown
links
and
french.
E
A
And
things
like
that,
so
it
should
be
fairly
easy
to
clean
up
but
yeah.
I
guess
everyone
on
the
call.
If
you
take
a
look
at
the
front
end
and
give
oscar
some
final
feedback,
that'd
be
great.
Getting
the
front
end
in
place
will
allow
us
to
do
baggage
and
close
out
of
other
a
lot
of
other
items
too.
So
this
is
a
great
to
finish.
C
B
Yeah,
I'm
with
awesome
on
that
one.
Let's,
let's
get,
let's
get
this
build
and
running
so
that
we
can
all
enjoy
the
fruits
of
this
labor
from
the
main
branch,
and
we
could
then
act
to
redo
the
the
instrumentation
where
it
makes
sense.
I
think,
ultimately,
we're
going
to
break
it
down
to
two
different
things:
instrumenting,
the
browser
side,
as
well
as
instrumenting
or
instrumenting,
the
the
sda
portion
of
it
as
well
as
instrumenting.
The
few
back-end
api
calls
that
are
being
made
or
front-end
api
calls.
Whatever
you
want
to
call
it.
A
Yeah
makes
sense,
makes
sense
to
me
and
we'll
probably
want
to
do
a
version
release
again
after
we
add
some
basic
instrumentation
to
the
front
end
and
also
release
it.
I
think
it
probably
makes
sense
as
like
kind
of
a
cut-off
point
it
seems
like
you
know,
I
think
we
released
our
last
version.
What
like
a.
C
C
C
When
the
major
items
come
in,
then
that's
a
release
so
yeah
I
feel
like:
let's
get
the
ui
in
let's
burn
through
open
prs,
let's
cut
a
release.
I
do
think
we
need
to
be
pretty.
C
Yeah,
I
think
we
either
this
week
or
next
week.
Maybe
next
week
like
we
need
to
really
look
at
cut
or
keep
on
what
1.0
is
going
to
look
like,
because
we
are
getting
pretty
close
to
september
and
I
want
I
would.
I
think
that
we
need
to
if
we're
going
to
have
this
like
demo,
ready
or
like
demo,
ready
ready
by
kubecon,
then
you
know
our
actual
factual,
like
it's
got
to
be
done
done.
A
A
Well,
as
far
as
I
know
so,
kind
of
we
just
enumerate
some
outstanding
items
so
front
end.
Php
admin
service
are
missing
and
then
final
tracing
and
really
most
of
metrics.
It
remains
those.
D
C
We
can
probably
wind
up
pushing
some
of
the
metric
stuff
because,
like
the
only
thing
that
really
has
metric
like
like
java,
I
think
is
really
the
only
language
with
like
pretty
full
metric
support.
Right.
A
I
think
maybe
five
languages
either
have
a
ga,
sdk
or
they're
close
to
it
and
have
some
sort
of
like
beta
a
release
candidate
or
something
like
that,
so
it
would
definitely
not
be
all
services
would
need
metrics.
I
know.net
has
a
premature
bachelor
of
story.
I
don't
think
that
would
be
like
a
tough.
C
I
believe
are
both.
Let
me
look
it
up
real,
quick,
actually.
D
A
B
C
Yeah
and
java
seems
to
be
pretty
complete,
go
or
dotnet.
Obviously,.
C
Yeah,
I
think
job
I
think
we
should
strive
to
get
java
in
too.
A
C
But
yeah,
if
we
can,
you
know
that
baggage
do
we
want
to
add
in
any
failure
scenarios
or
anything.
A
B
Yeah
we
need
for
feature
flags,
we
should
pre-loading
the
rules
or
the
the
flags
is
all
we
need
to
really
get
done.
We
can
discuss
that
as
well.
There's
still,
some
gotchas
on
the
feature
service
is
not
quite
working
yet
freeing
up
people's
time.
B
I
I
might
get
to
a
better
state
this
week
or
in
the
next
couple
days,
but
really
tricia
needs
to
dedicate
time
to
redoing
how
the
future
flags
gets
built
with
docker,
because
we're
not
pulling
in
the
right
protofile
and
that
was
really
causing
all
the
issues
before
tristan
has
a
little
bit
of
a
a
bandwidth
time
issue.
B
D
A
That
makes
sense.
Well,
we
do
have
a
little
bit
of
time,
so
it's
the
first
week
of
august,
let's
just
keep
keep
a
pulse
on
it
and
that'll
be.
B
I
think
we'll
we'll
be
able
to
close
it
out.
It'll,
just
I'll,
be
able
to
get
us
over
the
edge
here
in
the
next
couple
days
or
probably
even
today,
just
to
unblock
the
other
things
that
depend
on
future
flag
service
working.
But
ultimately
we
need
to
figure
out
a
better
way
to
package
this
thing
and
it
needs
to
pull
the
proto
from
the
top
level
not
have
it
specified
within
itself.
A
Okay,
could
you
make
a
an
issue
to
track
that
if
you
haven't
already.
B
Something
yeah
yeah,
something
came
up
over
the
weekend.
Yeah
chatting.
A
With
christian
about
it,
yeah
just
easy
to
put
that
in
a
bucket
for
now
cool
okay,
any
any
other
comments
on
potential
like
big
rocks
for
our
release.
These
are
kind
of,
in
my
mind,
our
like
to-do
list
a
little
bit,
but
would
love
to
surface
in
the
others?
E
Okay,
before
we
move
on,
could
you
hear
the
workflow
they
were
approved?
There
was
no
actions
from
the
piano
I
just
wish.
I
could
make
good
day
with
the
champion
pitches
yeah
sure.
A
D
A
The
approved
group
okay,
so
I
should
be
running
again
in
the
background:
cool.
B
Maybe
I
should
just
push
a
branch
that
I
have
sitting
here
and
you'll
see
where
I
was
trying
to
get
at
but
effectively
when
it
comes
down
to
it.
We
use
what
should
be
the
exact
same
thing
in
different
services
and
they
have
different
names.
So
it's
really
just
going
through
and
standardizing
our
names,
we're
close,
but
we're
just
not
perfectly
it's
like
stop
scrolling
right
here.
App.Ordered
our
shipping
costs
is
the
same
thing
as
app.shipping.cos.total
from
the
email
service
and
the
checkout
server.
So
it's
the
same
thing.
B
We're
just
naming
them
two
different
things
and
we
should
go
making
sure
they're
all
named
they're
all
named
appropriately.
I
also
have
a
pr,
that's
redoing,
all
this
into
tables,
so
we're
going
to
have
an
attribute
name,
a
type
and
a
short
description
with
each
one.
B
B
I
don't
think
so
yeah
and
then
there's
probably
a
little.
You
know
you
mentioned
it
repo
cleanup
in
some
cases,
I
noticed
that
the
attribute
was
not
actually
coming
across
properly,
like
the
service.
Has
this
concept
of
whole
dollars
and
nanos,
and
that
the
nanos
conversion
is
not
being
done
properly
each
time.
B
But
yeah,
that's
what
I
meant
about
attribute
naming.
Do
we
have
any
general
opinions
on
like
you
want
me,
just
go
at
it
and
have
a
I.
I
guess
it's
going
to
take
two
things
right.
We
need
to
go
through
each
service
or
we
need
to
identify
the
ones
that
are
colliding
and
then
we
need
to
figure
out
who
wins
or
and
then
go
into
the
the
offending
service
and
change
it.
D
B
Yeah
they
don't
have
a
service
resource
attribute.
I
think
what
we're
trying
to
do
here.
These
are
the
attributes
for
a
thing
part
of
the
app-
and
I
know,
there's
maybe
confusion
before,
because
some
things
feel
like
they're
service
names,
but
they're.
Really
it's
it's.
The
thing
just
happens
to
be
a
service.
Does
a
lot
with
that
thing
and
has
that
same
name
but,
for
example,
right
here
on
the
front
end,
we've
got
request
id
session
id
user.id.
Those
have
nothing
to
do
with
they're,
just
things
that
have
attributes
on
them.
C
B
C
C
So
like
may,
in
some
of
these
cases
that
might
be
making
a
decision
but,
like
I
would
say,
for
email
service
like
none
of
those
like
really
like
what
is
the?
What
is
this?
How
does
this
like
help
you
from
an
attribute
perspective
right,
like
other
than
I
don't
know,
checking
to
make
sure
that
the
number
didn't
change
between
service
and
service
b.
B
B
You
know
service
owner,
you're,
probably
responsible
for
your
own
service,
but
then
you
have
the
sr18
costs
around
the
entire
thing
and
although
an
attribute
might
be
used
in
three
or
four
different
services,
if
you're
searching
your
traces,
you'd
want
probably
one
common
attribute
name
across
all
services.
For
that
thing,.
B
Sure
sure
yeah
I
get
that
I
think
we
for
the
sake
of
the
demo,
were
adding
attributes
in
spots,
where
probably
it
shouldn't
make
sense,
it
probably
does
maybe
I
don't
know,
but
we're
just
trying
to
really
show
examples
here
at
the
same
time.
Well,.
C
B
C
Yeah,
okay,
then,
in
that
case
I
would
say
the
service
where
it
is
defined
logically
wins.
D
C
Us
to
de-duplicate
more
than
normalize
some
of
this,
but
maybe
I'm
also
like,
I
guess
the
flip
side
of
this
is
I'm
also
thinking
about
this
from,
like
a
light
step
perspective
or
like
how
our
queries
work,
you
know
or
like
what
we
like,
and
so
I
I
wonder
how
much
of
this
is.
You
actually
do
need
it
duplicated,
because
other
people's
query
engines
work
differently.
D
B
And
I
yes,
I
coming
from
a
vendor
does
tracing.
I
am
suffering,
but.
C
I
do
want
us
to
avoid
in
my
perfect
world
we
avoid
making
these
we
we
avoid
making
these
attributes
or
any
of
the
telemetry
coming
from
this
un
usable
for
forks
right.
I
don't.
I
think,
the
thing
that
we
can
provide
as
a
project
to
the
rest
of
the
community
is
like
hey.
This
will
always
be
up
to
date
and
the
more
that
this
kind
of
becomes
too
s.
C
It's
really
tight.
It's
a
tightrope
I
feel
like
because
it's
either
it's
too
specialized
or
it's
too
general,
and
if
it's
too
specialized
and
people
have
to
make
changes
to
it,
and
if
it's
too
general,
then
people
also
want
to
make
changes
to
it
and
the
more
changes
you
make
the
harder
it
is
for
us
to
update
it
and
have
people
take
those
updates.
B
B
I
still
think
we
probably
end
up
with
some
attributes
that
show
up
in
more
than
one
service
yeah
and
then
we
should
then
go
through
and
normalize.
The
names
yeah
like.
B
C
B
C
Yeah
or
just
I
mean
yeah
like
I'm,
just
trying
to
think
you
know
if
we
could,
if
we
had
to
put
it
in
a
ranked
list,
it's
like
you
need
the
cross,
the
the
transaction
id
like
the
generic
form
of
transaction
right.
C
So
you
need
the
order
id,
because
everything
is
unique
order
id
and
you
need
that
to
be
able
to
be
able
to
say,
like
show
me
all
spans
equal
for
order,
id
food
yeah
to
anything
that
the
service
generates
or
it's
responsible
for
needs
to
have
an
attribute
that
it
emits
and
then
the
third
priority
would
be.
C
It
has
like
a
relationship
like
like
I
can
see
for
currency
service.
Maybe
there's
like
oh
no,
nothing
else.
That's.
B
A
Yeah
pierre,
I
left
your
other
documentation
improvements
too
putting
the
tracing
and
metrics
on
the
table.
What's
the
bigger
proof
note.
B
Yeah,
as
you
can
see,
I
decided
to
go
down
a
doc
thing
last
week
I.
B
I
I
got
another
pr
for
some
reason.
I
lost
my
file.
Now
I'm
going
to
go,
dig
it
out
of
time
machine,
I'm
sure,
but
I'll
I'll
I'll
ship
over
the
pair
for
this
and
I'll
push
it
I'll,
show
the
branch
at
least,
but
it
converts
the
entire
page
into
a
series
of
tables.
B
It
just
feels
easier
to
consume.
That's
all.
A
Nice
yeah
love
it.
Okay,
speaking
of
docu
documentation
improvements
mikko,
I
know
you
mentioned.
You
were
potentially
interested
in
working
on
cleaning
up
our
repo.
Have
you
had
any
kind
of
like
initial
thoughts
on
what
you
might
want
to
do,
or
I
guess
are
you
looking
for
suggestions
from
the
group
as
well.
D
E
D
Which
yeah,
which
was
kind
of
raised
up,
that
it's
rather
long
and
if
you
need
to
explain
let's
say
the
install
instructions
for
docker
compose
and
then
different
kubernetes
options.
It
gets.
It
might
get
many
pages
long
and
then
it's
hard
to
find
anything
else
there.
So
yeah.
I
was
commenting
there
that
yeah,
maybe
some
some
more
structure
could
be
added
but
yeah
other
than
that.
No
okay,.
D
A
Michael,
do
you
have
do
you
have
anything
today?
I
know
you've
been
doing
a
lot
of
work
on
the
test
and
looking
into
the
code
coverage
too,
and
I
think
you
potentially
had
a
blocker
on
the
docker
code
coverage.
C
I
mean
from
a
github
actions
perspective.
It's
just
you
just
run
it
like
the
doesn't
it
already
set
up
the.
D
C
C
C
C
Because
if
you
see
this
is
the
this
is
what's
running
this,
this
checks,
ammo,
is
what's
running
the
pr
checks,
so
if
you
added
it
to
here,
then
it
would
get
run
whenever
someone
makes
a
pr
now,
depending
on
how
like
long
it
takes,
then
I
maybe
it
should
only
be
added
to
release.
I
don't
know.
D
Yeah,
I
can
try
that
the
main
thing
I
was
wondering
is
just
like:
can
I
actually
run
docker
compose
up
from
like
a
github
action
and
then
yeah
run
the
tests
like
after
it's
like
been
set
up.
C
C
C
So
it
would
run
in
the
same
thing
or
you
could
do
it
as
part
of
the
make
command
to
do
your
docker
up
and
then
wait
for
docker
up
to
complete
and
then
run
the
tests
against
the
containers
or
you
could
containerize
the
tests
themselves
and
have
a
docker
container
for
that
actually
might
be
the
easiest
way
to
do
it.
I'm
not
sure
exactly
but
yeah.
C
Yeah,
like
you,
could
build
all
the
tests
into
a
container
and
then
use
and
then
do
like
compose
build
with
your
test
compose
file
and
then
have
all
have
the
test
container
be
dependent
on
all
the
other
containers
starting
up
and
then,
if
the
test
and
then
just
have
the
test
container,
be
shell
scripts
or
whatever,
or
you
know,
whatever
your
api,
you
know
whatever
you're
doing
your
test
through
yeah,
if
it.
C
D
C
It's
not
the
so
in
this
github
action
gmo
there's
steps
and
it's
just
like
a
pipeline,
so
step
one
will
pass
like
whatever
you
do
in
step.
One
is
passes
up
two:
it's
it's
if
you're
in
a
different
name
or
whatever,
like
oh
a
different
job,
so
it's
jobs
and
jobs
have
steps
so
within
a
job.
It
shares
the
same
execution,
environment.
D
C
C
A
I
think
josh
lee
he's
on
the
slack
channel,
at
least
michael
on
your
suggestion.
I
think
said
something
very
similar
to
what
y'all
were
talking
about
was
separated
into
a
separate
docker
compose.
So
maybe
he
has
some
more
advice
on
that
too.
D
A
Okay,
let
me
go
back
to
the
agenda.
I
think
we
already
talked
about
documentation
improvements.
We
could
talk
about
some
repository
issues
quickly.
I
don't
think
we
have
about
five
minutes
left
here.
You
at
least
had
an
item
on
like
find.
The
address
is
already
in
use
for
the
payment
service.
A
Do
you
want
to
quickly
talk
about
that?
I
think
we
have
two
port
binding
questions.
B
Yeah
we're
just
binding
to
port
7000
mac
airplay,
for
whatever
reason
I
don't
even
know
what
I
was
doing,
but
all
of
a
sudden
it
was
binding
that
porn
and
it
stopped
working
for
me,
it's
you
know
and,
generally
speaking,
anything
in
the
I
don't
know
whatever
the
range
is
it's
like
47
000
below
whatever
that
number
is.
There
are
things
that
could
register
and
and
belong
and
own
those
ports,
and
we
should
probably
just
avoid
them.
B
B
E
Yeah,
that's
actually
one
of
the
changes
that
juliano
requested
was
to
because
the
first,
the
first
version
that
I
had
was
exposing
every
single
ports
for
the
gear
pc
services
that
the
front
thing
was
using.
So
what
I
did
instead
is
just
the
back
end
as
the
back-end
side
of
the
nexus
application
is
connected
to
those
earpieces
services.
You
don't
need
you
don't
need
to
bind
them
to
the
local
hospital
right.
You
can
just
use
them
discovery
names
so
in
I
think
we
don't
need
to
find
the
local,
the
local
board
anymore.
C
B
C
I
can
see
why,
like
you,
would
want
to
do
explicit
like
I
can
see
both
sides
of
the
argument
a
little
bit,
but
I
think
from
the
perspective
of
trying
to
make
it
run
smoothly
for
as
many
people
as
possible
than
avoiding
port
bindings
and
just
letting
everything
discover
each
other
using
its
built-in.
You
know
whatever's
also
I
mean
with
like
kubernetes
like
that's
easier,
because
kubernetes
will
just
tell
you
where
things
are
like.
D
B
C
B
Yeah
apis
won't
run
both
on
http
as
well
as
a
ui,
and
then
they
need
another
port
for
grpc.
C
Well
feature
flag
also
needs
to
be
bow.
Oh,
that's.
Fine,
then,
right
because,
like
only
humans
would
use
http.
C
I
think
it
would
just
work,
I
think
something
else
trying
to
make
a
grpc
connection
would
like.
Maybe
you
would
have
to
how
would
that
work?
If
there's
two
ports,
if
there's
only
one
port,
then
you
would
just
say
whatever
you
would
just
say,
feature
flag
and
then
feature
flag
that
local
and
the
other
thing
would
do
it.
But
I
don't
know
how
that
would
work
for
internal
versus
external.
C
It
might
be
smart
enough
that,
if
you
say
8081
is
bound
to
localhost
and
then
8082
is
exposed
and
then
something
from
the
overlay
network
asks
for
feature
flag.local.
Then
it
gets
the
internally
facing
port.
B
D
C
B
While
we're
thinking
about
it,
should
we
pick
a
good
port
for
the
feature
flag,
ui
and
I
get,
and
I'm
gonna
bet
that
the
php
admin
ui
will
also
need
a
fancy
port.
C
B
C
I
feel
like
if
we
just
open,
if
we
just
rather
than
do
the
assignment,
if
we
just
like
chop
it
off,
and
we
just
say
like
like,
I
think,
to
try
this
out.
We
could
probably
just
do
this
in
the
docker.
Compose
file
is
just
chop
off
the
second
part
the
instead
of
doing
colon,
whatever
we
just
say,
add
service
port
and
see
if
it
works.
C
D
B
C
C
Where
they
well
or
they're
running
or
they're
like
us,
and
they
work
off
of
docker
and
they
don't,
and
they
just
use
the
defaults
for
their
work
right,
because
that's
so
we
need
we
should
just
may
have.
We
should
have
it,
set
up
a
hotel,
demo
overlay,
and
then
we
launch
whatever
we
want
to
in
there,
and
the
only
thing
that
that
makes
like
that
only
makes
life
hard
from
the.
B
C
B
Okay,
so
from
the
port
perspective,
then
we
should
absolutely
look
at
adding
a
network
overlay
here
and
removing
the
explicit
bindings
for
a
lot
of
these
things.
Even
in
jager
it
binds
to
like
everything
that
it
doesn't
need
to.
We
really
only
need
the
jager
ports,
which
I
think
is
16
686
and
14
250..
Maybe
it's
14
260.
I
can't
remember
which
one
it
is,
but
we
don't
need
all
these
other
ports
like
their
zipkin
bindings
and
jagger.
C
B
Basically,
just
reduce
its
surface
yeah
support,
surface
level
and
for
the
ui
things
will
go.
Eighty.
Eighty
eight
eighty
one
to
eighty
eighty
two.
D
C
Hopefully,
my
schedule
will
I
really
appreciate
it
by
the
way.
I
really
appreciate
everyone's
work
on
this,
and
I
think
we
are
doing
a
really
good
job.
You
know,
I
think
we're
going
to
have
something
like
super
important.
C
So
this
is
hugely
valuable
work
that
we're
doing
for
the
project,
and
I
really
appreciate
everyone's
efforts.
B
I
will
continue
on
that
one
that
we're
also
improving
open,
telemetry
community
docs
with
all
this,
because
if
there's
a
docs
gap,
we're
able
to
report
that
up
and
they're
able
to
adjust
it,
I've
been
trying
to
work
off
docs
almost
solely
to
do
any
of
the
instrumentation.
So
if
it's
not
documented
yeah,
it's
a
problem.
C
And
also
from
a
open,
telemetry
phasing
perspective,
this
is
also
going
to
be
extremely
useful
for
the
docs
writers
and
in
shaping
the
next
generation
like
the
next
iteration
of
the
like
instrumentation
docs,
because
now
we
will
have
like
code
to
point
people
towards
where
we
just
say
like
well,
hey
look
at
how
we
did
it
over
here.
You
know
so
this
this
is
really
good
stuff.
We're
doing.
C
I
appreciate
everyone's
hard
work
on
it.
I
just
I
wish
I
had
more
time
to
contribute,
but
I
have
oh
boy.
Management
is
a
lot.
I.