►
From YouTube: 2021-03-02 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
A
A
B
A
A
The
the
prior
ot
I
worked
on
was
operational
transforms.
So
whenever
this
I
see
these
collisions,
I'm
like
all
right.
A
I
think
I
just
like
things
with
initials
ot
we
should
we
should
get
started,
looks
like
we
have
a
pretty
full
agenda
today.
I
don't
see
josh
on
the
call,
so
we
can
bump
him
to
last.
He
has
a
whole
meeting
after
this
meeting
to
talk
about
metrics.
So
we
can
talk
about
these
other
things
in
the
meantime
and
so
tyler.
Why
don't
you
kick
it
off.
B
Probably
some
other
sigs
at
this
point
are
doing
an
inventory
of
their
implementation
of
the
specification
to
make
sure
that
they
meet
the
1.01
specifications,
so
they
can
do
a
release,
and
so
we've
divvied
up
a
lot
of
the
tasks
to
do
that
inventory
based
off
of
the
specification
compliance
matrix,
but
we're
also
finding
that
it's
not
really
meeting
our
needs
in
many
areas,
it's
stale
subsets
of
the
requirements
are
actually
included,
there's
actually
a
lot
more,
sometimes
in
the
specification
in
some
places,
it's
diverged
from
the
specification
itself
so
we're
finding
that,
like
it's,
not
really
like
an
adequate
way
to
find
and
discover
all
the
normative
requirements.
B
One
thing
I
didn't
actually
include
here
is
like
so
then
we're
also
having
to
go
through
the
specification,
which
is
you
know
not
like.
I
can't
complain
too
much
about
that
like
it's
specification,
which
is
great
compared
to
just
going
green
building
things,
but
it's
a
little
tough,
sometimes
disentangling
what
those
requirements
are.
We've
done
a
pretty
good
job
at
like
using
some
standards
to
identify
those
requirements.
C
B
English,
isn't,
I
think,
written
by
a
native
speaker,
so
it's
a
little
tough
to
disentangle
what
those
meanings
are,
and
so
I
was
just
kind
of
wondering,
like
it'd,
be
really
helpful
if
we
had
a
centralized
place
to
have
those
requirements
laid
out
and
they
could
be
like
unified
on
it's
there's
a
pr
that
I
linked
here
that
originally
proposed
this
back
in
november.
It
didn't
gain
much
traction.
I
didn't
see
it
just
reopened
recently,
but
it
looked
like
an
idea
to
solve
this.
B
There's
obviously
going
to
be
that,
like
endemic
problem,
if
you
try
to
like
give
an
overview
of
a
specification
which
is
the
source
of
truth
at
that
point,
but
I
was
just
kind.
B
If
the
group
has
kind
of
solved
this
problem
or
in
in
another
way,
I
know
the
javasci
just
released
that
1.01
I'd
be
interested
to
understand
like
what
they
did
in
their
audit
of
the
specification.
And
so
I
just
kind
of
wanted
to
ask
that
question
to
the
group.
A
Yeah
there's
a
couple
things
to
unpack
there,
maybe
but
yeah.
You
asked
a
question
to
maintainers
about
what
they're
currently
doing.
So,
let's
cover
that
first.
C
Well,
I
would
say
that
I
didn't
base
it
on
the
on
the
my
the
audit
on
that
table.
At
all,
I've
been,
I
just
tracked
every
single
spec
change
and
have
been
creating
issues
in
java
whenever
there
was
a
spec
change
made,
and
so
when
all
those
issues
were
done,
I
assumed
that
we
were
at
the
at
whatever
the
spec
was,
rather
than
trying
to
use
them
use
that
matrix
as
a
guiding.
It
was.
C
That
was
that,
for
me,
that's
more
of
a
check
the
boxes
to
make
sure
we
haven't
missed
anything
big,
rather
than
looking
at
all
the
nitty-gritty
details.
B
Okay,
yeah,
so
definitely
not
a
tour
de
force
like
john
over
there,
so
I
definitely
did
not
keep
up
with
all
the
changes,
and
I
imagine
there's
a
few
other
maintainers
that
haven't
kept
up
with
those
changes
as
well,
so
it'd
be
kind
of
nice.
If
there
was
like
a
you
know,
especially
given
the
fact
that,
like
there
were
so
many
changes,
some
of
which
were
regressions
that
you
know,
maybe
we
could
have
you
know.
B
Given
the
fact,
we've
made
a
release,
some
sort
of
mark
in
the
sand
as
to
like
this
is
actually
what
you
need
to
pay
attention
to,
because
this
is
what
you're
actually
releasing.
I
haven't
I've
seen
the
proposal
that
bogdan
made,
I
haven't
read
through
the
entirety
of
it.
I
do
think
that's
really
nice.
B
I
think
it'd
also
be
really
helpful
to
bogdan
or
to
remember
that
on
the
tc
comes
and
has
to
do
an
audit
of
the
gosig,
but
right
we
can
point
them
to
all
of
the
issues
that
we've
actually
done
this
audit
on,
and
I
imagine
in
other
things
that
could
be
a
very
useful
tool
as
well,
but
yeah,
that's.
Okay.
That's
that's
helpful.
F
Yeah
one
thing
that
might
be
helpful
for
those
of
us
who
aren't
keeping
up
as
on
top
of
it
as
john,
is
the
change
log
for
the
sig,
so
that,
if
we
know
we
were
current.
As
of
this
point,
we
could
look
at
the
change
log
and
say:
okay,
here
are
the
things
we
may
need
to
address
to
get
to
the
next
milestone.
A
Yeah
there
is
a
change
log
in
the
spec,
but
unfortunately,
I
think
prior
spec
releases
were
like
so
largely
chunked.
People
were
kind
of
following
head
of
master
for
a
while,
so
I
don't
know
totally
how
useful
that
change
log
is.
But
if
you
do
look
there,
it
is,
it
is
in
at
least
an
order.
So
that's
one
place
to
to
have
a
look.
B
So
it
looks
like
daniel
also
put
in
chat
that
he
as
well
is
not
as
strong
as
john
and
fell
behind,
but
did
an
audit
just
by
reading
the
tracing
spec
itself
as
well.
C
I
was
not
actually
doing
audio,
I
was
just
oh,
I
got
you
yeah,
that's
all
you
feel
sure
like
I
just
like
there's
no
way
I
could
imagine
keeping
up.
If
I
didn't
do
it,
and
so
it's
more
like
I
ground
it
out,
rather
than
any
moral
character
benefit
there.
B
So
I
kind
of
wonder
just
to
move.
The
conversation
forward
is
to
like
the
next
question
was
kind
of
like
the
purpose
of
the
specification
compliance
matrix.
It
sounds
like
it
was
kind
of
like
a
big
ticket
items
and
that
kind
of
thing,
but
like
the
nitty-gritty
details,
are
kind
of
important
as
well
we're
going
to
release
the
something
that
implements
the
specification,
and
I
have
some
ideas.
B
But
I
also
like
I
I've
been
doing
a
lot
of
prs
this
spec
compliant
matrix
under
the
assumption
that
it
was
like
here's
what
the
normative
requirements
are
going
to
be
taking
but
like.
If
that's
not
the
case,
I
don't
want
to
like
be
conflicting
with
people,
let
alone
like
having
the
wrong
intent
and
maybe
there's
a
better
place,
because
I
do
think
there's
other
sigs
that
are
going
to
follow
on
after
us.
I'd
like
that
process
to
be
easier
for
them
than
it
was
for
us.
Hopefully,.
A
I
I
certainly
would
say
updating
that
compliance
matrix
based
on
the
work
you've
done
in
the
go.
Sig
would
be
helpful
and
good.
It
seems
like
there's
two
things
needed.
One
is
like:
is
there
like
kind
of
the
short
version
which
ideally
should
be
in
depth,
but
like
just
a
checklist
version
which
is
kind
of
what
I
see
the
spec
compliance
matrix
kind
of
is
doing?
It
was
kind
of
high
level.
It
was
also
more
to
get
a
sense
of
like
where
the
different
sigs
were
at
the
time.
A
A
The
longer-term
fix
is,
of
course,
making
the
spec
more
readable
right
like
there
can
really
only
be
two
things
there
can
be
like
a
checklist.
You
know
that
doesn't
cover
everything
there's
like
the
short
short
version
and
then
there's
like
the
spec
itself
and,
as
anthony
mentioned,
a
changelog
and
ideally
more
frequent
releases
of
the
spec,
but
also
sigs,
starting
to
feel
like
they
can
target
a
version
of
of
the
spec.
A
So
I
think
I
think
that
combination
of
things
will
help
the
releasing
the
spec
more
frequently
is
something
we've
committed
to,
hopefully
after
1.0
it'll
be
possible
for
for
groups
to
to
get
up
onto
a
version
of
the
spec
and
not
be
chasing
head
master
anymore.
A
A
As
far
as
a
second
draft
of
the
spec
itself
that
sounds
kind
of
intimidating,
I
think
we
would
have
to
figure
out
how
to
eat
that
elephant
while
still
moving
forwards
with
all
the
other
work.
We're
doing.
B
Yeah,
so
I
don't
know
particularly
about
a
second
draft,
I
think
there's
two
things
there.
Sorry
I'm
trying
to
wrap
things
up.
There's
a
lot
left
to
go
on,
but
like
there's,
definitely
I
think
some
language
that
could
be
unified
in
the
specification
or
clarified,
even
and
so
maybe
like
in
the
same
way
that
the
w3c
has,
like
a
you,
know,
a
non-substantive
change
time
period.
That
could
be
kind
of
the
same
thing.
That's
going
on
with
our
specification
and
then
the
other
thing
was
just
that.
B
Like
idea
of
adding
a
a
requirements
section,
there
was
like
a
way
to
explicitly
make
that
like
clear.
I
don't
know
if
I'm
necessarily
in
favor
of
adding
another
doc
for
requirements,
but,
like
you
know,
just
just
a
proposed
idea,
I
guess
or
something
to
think
about,
so
maybe
other
people
can
comment
on
that
pr.
I
just
saw
it
so
I
commented
yeah
just
killed
it.
D
Can
I
can
I
call
out
one
metapoint
before
we're
done
right
now.
I
think
that
spec
compliance
matrix
is
completely
derivative
from
the
specification
and
it
requires
a
human
to
understand
the
entire
specification
to
create
the
spec
compliance
matrix
and
that
might
not
be
scalable
in
the
long
run,
so
the
pr
proposes
tooling,
which
I
think
actually
automates.
Some
of
that
I
think
could
be
really
really
really
helpful.
D
It
just
also
requires
us
to
build
out
tooling,
so
I
think
it's
it's
a
good
direction
to
look
into,
and
I
think
it
could
help
alleviate
this
issue
of
one
person
needs
to
know
the
entire
freaking
spec,
which
is
the
limiting
issue
right
now
for
those
of
us
who
can't
follow
the
whole
thing
all
the
time
right.
A
Okay,
so
for
clearly
josh
what
you're
saying
is
write
the
spec
in
a
normative
fashion,
so
that
something
like
a
requirements
matrix
could
be
extracted
from
it.
Is
that
so
you
mean
by
tooling.
G
And
and
ted-
I
think
you
know
this
has
been
discussed
before
and-
and
I
know
that
we
discussed
this
yes
last
year,
also
because
we
were
trying
to
figure
out,
you
know
how
to
actually
map
an
auto
generation
of
the
template.
G
For
you
know
what
exactly
tyler
is
trying
to
do
with
the
com
matrix
from
the
spec
itself,
and
I
remember
at
that
point
bogdan
had
mentioned
we
should
we
should
actually
figure
out
the
tooling
so
that
there's
a
one-to-one
one-to-one
correlation
with
the
sections
and
you
know
really
deriving
each
of
the
dependencies
based
on
each
section.
So
if
we
can
spec
it
out
again,
it's
a
something
that
an
you
know,
new
engineer
can
even
build
out.
So
that's
that's.
Definitely
plus
one.
A
Yeah
we
did
this
for
the
semantic
conventions,
and
that
was.
G
A
Helpful
yeah
so
tyler
you
seem
to
have
your
head
kind
of
in
this
game.
Would
you
like
a
stone?
Would
you
be
able
to,
like
I
mean,
or
at
least
write
up
like
it
sounds
like
you
have
some
thoughts
like
they
get
like
written
written
down?
If
you
have
a
proposal,
I
don't
want
to
dump
work
on
your
plate.
If
all
you
can
do
is
like
get
the
spec
compliance
up
to
date
and
that's
it
for
now,
then
then,
that's
great.
B
So
I
would
totally
be
up
for
like
opening
an
issue
I
think,
but
I'm
trying
to
get
go
to
a
release,
and
I
think
that's
probably
my
priority.
I
couldn't
I
couldn't
take
this
on.
I
do
know
that
you
had
in
your
timeline
that
we
had
some
like
interns
coming
on,
hopefully
in
the
summer,
so
that
maybe
like
that
could
be
something
yeah.
E
E
H
H
A
Yeah,
if,
if
this
is
what
I'm
looking
for,
if
there's
like
just
something,
we
can
grab
like
an
approach
that
ideally
even
has
some
tooling
already.
That
would
be
awesome
and
then
we
can,
someone
can
progressively
just
take
a
pass
it
at
converting
the
language
over.
H
A
H
Regarding
the
the
metrics,
my
thinking
is
it's
very
it's
a.
It
was
a
very
good
thing
at
that
time
like
last
year,
but
as
we
are
having
more
and
more
language
six,
it
will
be
unmanageable,
like
just
imagine
somebody
sending
pr
and
resolve
all
the
merge
conflicts.
So
once
we
have
this
number,
we
can
probably
also
generate
that
and
different
language
six.
They
can
always
grab
the
generated
templates
to
merge
with
their
specific
thing
and
for
the
language
say
they
probably
should
maintain
the
status
in
their
language
report
instead
of
this
spec
ripple.
B
Riley
I
I
had
a
lot
of
questions.
You
seem
to
have
a
lot
of
really
good
solutions,
and
you
said
the
word
of
like
create
a
script
in
a
day
which
sounds
untenable
to
me,
so
I
would
love
it
if
you
could
help.
I
mean
somebody's
throwing
me
under
the
bus,
I'm
happy
to
throw
you
in
the
place
but
sure
yeah.
B
H
B
G
A
get
it
built,
you
know
and
work
with
bradley
on
it.
Yeah.
H
A
Okay
and
yeah
it
I
mean
it
sounds
like
you're
already
doing
it,
but
it
does
seem
entirely
like
the
short
term.
Ask
for
me
is
just
you
found
egregious
things
wrong
with
that
compliance
matrix.
If
you
haven't
made
a
pr
to
fix
those
egregious
problems.
Would
you
mind
like
doing
that
part
because
yeah.
B
A
I
Sure
yeah
it's
going
to
be
quick,
so,
as
the
you
know,
prometheus
working
group
we're
working
on
the
prometheus
support
and
there
are
a
couple
of
phases.
I
There
are
a
couple
of
things
that
you
know
may
affect
the
data
model
or
you
know
slide
improvements
and
such
so
one
of
the
ideas
was
there's
no
source
of
root
of
what
what's
going
on,
plus
what
are
the
phases
and
what
the
compatibility
looks
like.
So
I
thought
that
maybe
it's
a
good
idea
to
kind
of
like
put
it
in
the
spec,
because
we
have
a
compatible
section,
at
least
as
a
draft.
You
know
what
is
the?
What
is
the
current
promise
in
limitations
and
gotchas?
I
So
you
know
we
can
use
it
as
a
as
a
way
to
communicate
to
the
users.
Is
there
any
any
any
any
concerns
about
that?
Do
you
think
that
it's
a
it's
a
good
place
to
put
this
type
of
thing
on
or
it
could
live
outside
of
the
spec.
J
Yeah
I'd
say:
prometheus
should
have
a
compatibility
spec
and
we're
going
to
talk
about
data
model
in
the
next
hour.
So
I
don't
know
if
we
want
to
try
and
get
all
this
tracing
stuff
out
of
the
way
and
then
start
talking
metrics.
But
yes,
it
should
have
a
compatibility
section
and
I've
been
working
on
a
document
that
talks
about
translating
otlp
into
the
prometheus
time
series
model
so
that
there's
a
compatibility
there
should
be
compatibility
there
as
well
anyway.
I
don't
want
to
start
discussing
metrics
in
depth
if
everyone's.
A
I
I
do
think
you
have
a
good
question
of
where
to
put
this
information,
I
feel
like
we
have
a
bunch
of
spec
work,
we're
doing
right
now
around
metrics
that
we
don't
want
like
in
the
actual
spec,
necessarily
in
the
sense
of
like
what's
in
the
spec,
should
be
what
people
are
implementing
when
it
gets
released.
I
don't
think
we've
figured
out
where
we
want
to.
If
this
is
like
work
in
flight.
Like
you
know,
research
and
work,
that's
ongoing.
It
would
be
great
to
have
that
centralized
in
place.
A
J
A
That's
totally
true,
like
oteps
are
a
place
to
do
it,
but
given
that
there
might
be
like
a
long
timeline
here
for
some
of
these,
I
imagine
it
might
be
helpful
to
start
compiling
multiple
things
into
a
place.
So
I
don't
have
an
exact
solution
but
oteps,
and
I
don't
think
it's
wrong
to
have
a
portion
of
this
spec,
be
where,
like
our
latest
design,
work
is
happening,
or
at
least
a
page,
with
like
a
link
to
all
the
google
docs
or
wherever
it
is
yeah.
I
That's
sort
of
like
the
idea,
I
think,
like
you,
know,
a
source
of
fruit,
something
digest
at
least
kind
of
like
hey.
We
can
point
people
and
like
they
know
that
that's
the
like
latest
thing
going
on,
because
I
think
all
of
the
material
is
between
different
documentations
or
in
between
people
or
on
issues.
Right,
like
I
don't
know
like
it's
kind
of
not
really
helping
me
right
now.
Definitely
not.
A
Would
you
mind
like
taking
a
a
revamp
that
experimental
section
is
just,
I
think,
contains
some
ideas.
Some
interns
had
from
last
summer.
That's
literally
all
that's
in
there
right
now,
and
so
that
could
just
get
rearranged
into
something
more
more
useful
and
then
like
on
the
table
of
contents
right
there
in
the
readme.
Just
like
a
link
to
that.
So
it's
it's!
It's
just
discoverable
I'll.
I
Take
a
look,
maybe
I
should
write
a
draft
if
you
think
that
it's
it's
not
suitable
for
the
you
know
experimental
repo,
we
can
move
it
somewhere
else
or
you
know
we
can
move
it
on
a
dock
or
we
don't
have
to.
You
know,
write
anything
like
that.
It's
just
let's,
let's
let
me
write
something
to
give
you
an
idea,
cool
all
right.
J
Yeah,
by
the
same
token,
I'm
working
on
a
draft
data
model
spec
and
I'm
I'm
trying
to
get
fast
feedback
on
it.
So
I've
been
sharing
google
doc
with
people,
but,
as
josh
said
in
the
last
time
of
this
meeting,
we
should
start
moving
it
into
markdown
and
I
think
the
same
topic
will
apply.
We
don't
want
to
start
having
a
half
big
metric
spec
in
this
in
getting
in
the
way
of
the
people
understanding
tracing.
So
I
think
whatever.
G
Okay
yeah
now
we
could
kick
started
the
dock
that
you
proposed
in
the
work
group
repo
and
then
move
it.
I
I
Some
of
them
are
minor.
Some
of
them,
like
people
are
pushing
hard
against
them
because
they're
major,
but
you
know
it
might
be
useful
to
actually
like
do
the
work
right
now,
rather
than
waiting.
You
know
longer,
since
everything
is
experimental
in
the
semantic
conventions
like.
Is
there
a
good
way
to
like
communicate
the
changes
like
one
of
the
like
things
that
we
I
was
thinking
about,
there's
a
number
of
different
things
going
on,
but
I'm
not
expecting
people
to
you
know
just
kind
of
subscribe.
All
the
changes
is
it.
I
Maybe
it's
a
better
idea
to
kind
of
like
do
all
those
like
stuff
and
then
kind
of
like
file,
an
issue
on
the
you
know
the
languages
to
kind
of
like
take
a
look
and
see
the
compatibilities.
The
other
thing
that
I
was
wondering
is:
are
we
only
generating
any
of
these?
Like
you
know
keys,
you
know
semantic
convention
keys
because
that
may
help
some
of
this,
like
you
know,
just
being
able
to
catch
up
with
things.
Maybe
it
could
be.
I
You
know
something
in
the
future
as
an
improvement,
I'm
not
super
sure
about
the
analystic
case
and
like
if
they're
generating
any
of
the
semantic
conventions.
At
this
point.
G
John,
do
you
use
a
tool
tool
for
that
or
do
you
have
like?
Did
you
build
the
script.
K
So
we
have
the
build
tools
repository
in
our
organization
in
open
telemetry
and
that
one
hosts
the
markdown
generator
and
the
java
constants
generator
is
just
yet
another.
Another
template
that
is,
that
is
being
used
for
generating
those,
and
basically
everyone
should
be.
Everything
should
be
able
to
provide
their
own
template
added
there
and
then
generate
their
own
constants.
I
Maybe
I
should
file
an
issue
on
everybody.
You
know
suggesting
this.
It
could
be
a
long-term
improvement,
but
we
should
you
know,
do
it.
K
Yeah
and
that's
something-
that's
that's
really
helpful,
and
also
at
this
point,
if
there
are
breaking
changes,
and
now
it's
experimental,
so
we
can
can
totally
do
that.
We
could
remove
a
constant,
for
example,
and
then
also
all
instrumentations,
using
that
constant
would
no
longer
compile
and
would
be
able
to
to
figure
it
out
that
that
something
changed
there
and
one
thing
in
addition
to
that.
K
What
I
really
like
about
the
java
seek
release
notes
is
that
there
is
a
big
section
in
the
release,
notes
with
a
with
a
dangerous
sign
and
everything
that
says,
experimental,
no,
breaking
changes,
and
that's
also
something
we
could
point
out
more
clearly
in
our
spec
changelog,
because
now
it's
just
a
bunch
of
pr's
and
and
it's
not
much
better
than
than
looking
at
the
commit
history
actually.
K
A
Yeah
going
forward,
in
particular,
we
have
both
patch
changes
and
and
minor
changes
right,
like
so
being
able
to
identify,
which
is
which
and
yeah
you
mentioned
yeah,
maybe
also
specifically
mentioning
what
broke
or
what
not
just
like.
This
was
a
minor
change,
but
this
is
something
that
is
now
outdated,
so
people
have
a
handle
on
it.
C
A
Okay,
when
we
do
the
next
spec
release,
let's
let's
aim
for
for
something
more
like
what
john's
doing
here
so
technical
committee
people,
I
see
carlos
on
call.
G
A
I
think
the
tc
like
as
a
group
like
think
about
that
next
upcoming
release
and
maybe
get
get
a
bit
of
a
plan
together
for
that,
since
we're
kind
of
changing
our
cadence
and
changing
our
approach.
A
Okay,
are
you,
are
you
good
jana
on
this
topic.
A
Awesome.
Okay,
so
I
would
like
to
talk
about
the
convenience
api,
so
I'm
gonna
add
a
link
to
the
roadmap.
A
Let
me
get
a
link
okay,
so
that
is
added
to
the
doc.
So
this
is
a
high
level
road
map.
I
guess
I
can
share
my
screen.
A
I
will
be
breaking
these
out
into
like
an
actual
project
document
per
project,
but
the
the
timeline-
that's
that's
shaping
up
is
working
on
convenience
api
for
the
next
six
weeks,
while
beginning
to
kick
off
discussion
around
how
we're
going
to
wrangle
our
instrumentation
ecosystem
with
the
goal
of
getting
that
instrumentation
ecosystem
work
done
in
time
for
the
interns
to
show
up.
A
So
those
are
the
projects
we're
going
to
be
working
on
right
now
and
we're
going
to
try
to
besides,
you
know,
doing
1.0
support
and
cleaning
up
for
1.0
releases.
This
is
where
I'd
like
the
maintainers
and
the
spec,
this
spec
group,
to
focus
for
the
next
two
months
when
may
hits
ideally
we'll
have
time
box
this
work
effectively,
so
that
people
feel
like
they.
A
They
got
in
a
good,
coherent
group
of
changes
to
their
implementation
and
then
we'd
like
to
move
on
to
simplifying
the
installation
experience
while
kicking
off
people
writing
more
instrumentation.
A
So
that's
from
the
communication
I've
had
with
people.
People
seem
to
be
liking.
This
approach,
I
want
to
dig
into
how
we're
going
to
kick
off
the
convenience
api,
but
before
I
do,
is
there
anyone
who
has
major
concerns
about
this
road
map
that
they'd
like
to
voice.
K
One
thing
that
I'm
missing
here
is
the
semantic
conventions.
When
do
we
expect
those
to
be
considered
stable?
I
suppose
that
we
would
like
people
to
start
building
instrumentations
to
start
figuring
out
where
instrument
giving
them
a
reality
check
and
figuring
out
where
we
need
to
adapt
something
as
long
as
we
can,
but
also
in
a
similar
time
frame,
we
would
probably
want
them
to
be
stable
enough,
so
that
people
feel
confident
in
writing.
Instrumentations
that
that
will
be
stable.
Then
right.
A
Yeah,
yes,
so
that's
instrumentation
design,
so
we
want
to
have
that
work
sorted
out
by
the
beginning
of
may
so
that'll
be
part
of
this
instrumentation
workflow
because,
like
you
said,
like
that's
part
of
like
getting
ready
for
people
to
write
instrumentation,
it's
one
part
stabilizing
what
instrumentation
people
should
write
that
semantic
conventions
plus,
I
think
some
higher
level
concerns.
A
John
and
other
people
have
noticed
around
questions
around
http
requests,
and
you
know
what
there's
some
like
corner
cases
and
some
questions
that
come
up
when
we've
done
this
in
the
real
world.
The
other
big
part
of
this
is
figuring
out
how
we're
gonna
manage
all
of
this
instrumentation
going
forwards,
so
I'll
get
a
doc
together.
Each
one
of
these
projects
has
a
short
discussion
piece
here.
A
So
please
leave
your
comments
here.
If
you
see
something
important
about
one
of
these
projects,
that's
missing
and
I
will
try
to
flush
these
out
into
more
of
a
fuller
dock
per
document.
Doctor
document
polar
a
more
complete
road
map
per
project
still
working
out.
What
is
the
best
format
for
doing
these
things,
but
does
that
answer
your
question
about
instrumentation.
K
A
Yes,
I
think,
there's
basically
are
we
happy
with
with
the
conventions
that
we
have
there's
another
form
of
stability
which
is
around
telemetry
like
let's
say
we
do
want
to
change
this
stuff
in
the
future.
What
what
is
out
of
bounds
versus
inbounds?
A
That's
a
little
bit
of
a
tricky
subject
in
open
telemetry,
because
we
talk
to
a
lot
of
different
backends,
so
it
we
can't
do
the
thing
that
prior
projects
may
have
been
able
to
do
where
they
change
the
instrumentation
and
change
the
back
end.
At
the
same
time,
we
also
can't
say
we're
not
going
to
change
anything
ever
because
that
seems
like
too
tight
a
straight
jacket,
so
I
think
we
just
have
to
to
pick
something
there
when
we
say
it's
stable,
just
just
so.
People
understand
what
what
that
means.
A
But
ideally
also
we're
satisfied
with
the
conventions
that
we
have
and
that
our
plan
will
be
moving
forward
to
simply
add
more
conventions
and
not
be
deleting
or
changing
the
meaning
of
the
existing
conventions.
K
A
Always
add
more,
that
have
version
numbers,
but
you
know
we.
This
is
the
the
main
thing
we
have
to
sort
out
before
the
interns
arrive
in
may
begins
is.
Is
this
piece
for
sure
yeah.
K
Makes
sense
just
one
thing
that
I
want
to
make
people
aware
there
are
certain
things
that
we
can't
version
so
something
like
a
parent-child
relationship
or
spend
kind
and
those
things.
Yes,
we
have
to
be
really
sure
about
these.
At
the
time
we
mark
it
stable,
because
we
can't
say
yeah
now
the
the
parent-child
relationship
will
be
entirely
different
or
stuff
like
that.
So
we
will
have
to
sort
this
out.
First
yeah,
but
attributes
are,
are
the
easy
part
there.
A
There
is
a
an
extensible
portion
here
which
are
links
so
parent
child,
I
think,
are
pretty
well
established,
but
just
to
mention
this
an
area
there
are
you're
mostly
been
thinking
about
synchronous
transactions
and
when
it
comes
to
modeling
things
like
caches
or
message,
queues
and
pub
sub
batch
processing
event.
There's
like
a
number
of
other
patterns
that
I
don't
think
we've
dug
into
as
far
as
how
we're
going
to
model
them.
A
D
A
H
The
question
for
jana
I
I
saw
you
have
some
pr
that
are
like
cloud
specific.
So
my
question
is
previously
we
talked
about.
Do
we
want
to
have
the
owner's
name
listed
in
every
single
spec
document
so,
for
example,
like
cloud
some
people
might
have
expertise.
They
know
whom
to
find.
Currently
we
don't
even
have
the
code
owner
enforcement,
so
I
wonder
if
we
should
yeah.
I
That
sounds
like
a
good
idea.
I
think,
like
at
least
domain
expert
is
wise,
like
you
know,
you're
still
thinking
about
like
having
the
maintainers
and
plus,
like
maybe
an
owner
who
understands
the
domain,
and
I
can
kind
of
provide
that
feedback.
Or
do
you
think
that,
like
the
you
know,
the
person
who
has
expertise
should
also
doing
all
the
maintenance.
I
mean,
I
think,
both
options,
sound
good
and.
H
The
current
state
I
would
propose
in
each
markdown
file
we
have
like.
In
the
beginning,
we
have
a
section
saying:
who's,
the
owner
and
who's.
The
approver
owner
will
do
all
the
grounding
work
like
if
there's
some
additional
like
clean
up
or
just
like
reformat.
The
document.
The
owner
should
be
responsible
for
the
document
experts
and
they
should
participate
in
the
the
change
review.
I
Yep
yeah,
that
sounds
like
a
good
idea.
Do
you
wanna,
do
you
wanna
take
an
action
on
this
like.
H
I
can't
I
just
want
to
support,
because
I
know
any
pr
in
the
spec
is
is
taking
very
long
time.
So
I
wanted
to
step
by
step
approach
and
also
finding
all
the
owners
for
each
document
would
be
taking
a
long
time.
So
I'm
willing
to
volunteer
myself
like
for
the
metrics
api,
spec
and
probably
for
semantic
commission.
I
would
volunteer
you
yana
and
for
the
others.
H
Okay,
so
I'll
create
a
pr
just
for
the
matrix
part
and-
and
please
help
to
reveal
and
once
you
think,
like
we're
aligned
go
ahead
for
the
semantic
convention.
Okay,
you
can
tell
people
to
follow
that
moving
forward
and
for
existing
thing.
I
think
it's
going
to
take
some
time
to
cannot.
K
Awesome
yeah
having
a
list
of
domain
experts
is
a
great
idea
in
in
some
instances
let's
say
someone,
it's
a
pr
for
aws
semantic
conventions
and
it's
already
jana
then.
I
know
that
I
can
add.
Unrock
is
a
second
review
from
aws,
but
that's
just
by
chance.
We
don't
have
any
any
proper
directory
to
look
up
stuff
like
that.
So
that's
a
great
idea:
yep.
A
Awesome:
okay:
this
is
great
and
we'll
continue
I'll,
try
to
rough
out
like
a
dock
around
this
instrumentation
project,
but
yeah
we'd,
love,
input
from
yana
and
armin
and
others
as
to
what
exactly
it
needs
to
be
in
there.
In
the
meantime,
there's
like
just
a
short
short
version
here
feel
free
to
add
suggestions
or
comments,
or
otherwise
help
flush.
A
This
portion
out,
if
you're
interested
by
the
way,
I'm
mostly
driving
this
just
because
I
feel
like
some
someone
needs
to
kind
of
put
this
together
and
drive
it,
but
I
I
welcome
help
and
advice
on
how
to
do
this.
A
So
moving
on
to
the
convenience
api,
this
is.
I
would
like
to
use
our
remaining
time
to
discuss
how
we
want
to
approach
this.
This
is
something
that
we
know
is
important
from
user
feedback
when
you're
an
application
developer
using
open
telemetry
the
apis
we
have
are
not
always
the
most
convenient,
simply
because
they're
designed
to
work
in
a
variety
of
environments,
you
may
or
may
not
have
a
current
span
in
your
context.
A
Things
like
that,
and
we
know
that
there
are
idiomatic
ways
in
different
languages
to
to
make
a
number
of
common
tasks
more
like
one-liners
or
at
least
having
an
api.
That's
more
like
a
single
interface
that
has
all
of
the
commands
there.
So
it's
easily
discoverable
and
your
ide
these
kinds
of
things.
My
impression
is
that
that
maintainers
and
sigs
have
a
good
idea
of
like
what
would
be
the
most
comfortable
thing
to
do
in
their
language,
since
they've
been
working
on
it
for
a
while.
A
So
I
see
this
project
as
having
two
parts.
The
first
part
is
simply
giving
maintainers
and
sig
space
from
now
to
the
end
of
april
to
plan
out
a
backlog
of
work.
They
would
like
to
do
on
this
that
fits
that
amount
of
time
and
then
chew
through
that
work
on
their
own.
Using
this
meeting
and
our
slack
channel
to
raise
questions
to
the
group
as
questions
come
up,
perhaps
keeping
this
work
on
an
experimental
branch
while
you're
working
out
the
details.
A
If
it's
not
clear,
the
other
part
is
what
amount
of
front
loading
as
far
as
stuff
that
should
actually
be
literally
in
the
spec
on
this
subject.
Do
we
want
to
do?
A
I
personally
feel
like
we
don't
want
to
over
specify
this
part,
because
this
is
where
things
get
idiomatic
and
that's
like
sort
of
the
point,
but
I
have
heard
requests
from
some
maintainers
that
there
should
be
something
in
the
spec
regarding
this
subject,
and
so
I'm
curious
in
terms
of
writing
up
a
proposal
for
this
and
getting
some
spec
work
in
in
time
for
this
meeting
next
week.
A
A
So
I
would
say
one
strong
suggestion
is
annotations
or
macros
or
whatever
the
equivalent
is
in
your
language.
The
the
other
portion
is
helper
methods,
things
that
are
just
a
conveniently
stacked
together.
Multiple
low-level
commands,
like
one
example,
is
with
span
that
you
know
allows
you
to
start
a
span,
make
it
the
current
span
and
then
end
the
span
when
the
closure
completes
or
some
equivalent
in
your
language,
as
far
as
where
those
methods
go.
A
That
is
a
good
way
to
factor
things
in
terms
of
cleanliness,
but
that
does
that
is
difficult
for
new
users,
because
it
means
they
have
to
first
understand
the
structure
of
the
project
and
what
it
does.
So,
I
would
say
if
you
don't
currently
have
something
like
a
single
package
that
just
has
all
of
the
methods
in
it
maybe
on
separate
objects.
A
A
M
The
only
thing
that's
important
to
me-
and
I
think
I've
been
one
of
the
ones
that
you
talked
about
that
was
complaining
about
there
being
no
spec
is
so
you
ju
is
that
the
between
different
languages,
it
just
needs
to
be
consistent
where
you
just
said
with
span,
would
start
a
span
and
set
it
as
active.
If
I
had
implemented
with
span
yesterday
before
you
said
that
I
would
not
have
made
it
start
a
new
spam,
so
I
I
just
want
it
to
be
consistent
between
the
languages.
M
That's
the
most
important
part
to
me
is
that
it
just
needs
to
be
specified
somewhere
before
I
feel
comfortable
implementing
it,
because
if
I
had
implemented
with
span
yesterday
and
then
a
spec
was
introduced
today,
that
said,
oh
no,
it
needs
to
start
the
span.
Then
my
implementation
is
not
spec
compliant
and
that's
a
breaking
change
right,
but
this
is
actually.
A
I
I
agree:
I
completely
agree
with
that.
Different
languages
need
different
conveniences,
like
it's
just
really
impossible
to
maybe
unify
the
entire
thing,
like
the
entire
reason.
The
conveniences
api
is
happening
is
because
you
know
the
api
is
too
low
level.
It's
been
represented
in
a
very
particular
way
in
every
language,
so
you
just
we're
building
this
convenience
and
there
are
different
ways
to
provide
convenience
in
every
different
language.
So
I
think
that
you.
I
To
unify
is
just
the
you
know,
the
counter
example
I
mean
we
shouldn't.
Do
it.
A
And
I
should
mention
part
part
of
why
I
feel
comfortable
with
that
is
because
these
are
higher
level
apis.
So
if
we
just
add
to
the
spec
that
all
this
convenience
should
never
be
directly
implemented,
in
other
words,
these
should
be
implemented
entirely
in
the
api
package
by
calling
other
api
methods.
So
it
never
goes
under
the
hood.
Then
you
know
you've
never
accidentally
violated
the
model
and
the
spec
that
we.
I
Yeah
one
of
the
like
interesting
ways
to
drive
this
work
would
be
like
documenting
cases
that
we
want
to
provide
convenience
for,
like,
for
example,
for
metrics.
What
we've
been
discussing
is
like
hey,
where's,
my
counter
where's,
my
histogram
right,
like
if
you
give
me
a
convenience
to
answer
that
question.
Maybe
that's
that's
sort
of
like
you
know,
that's
what
the
spec
is
like.
You
know,
listing
those
use
cases.
A
So
so
we
could
just
list
examples
and
use
cases,
but
just
stress
that
these
are
these
are
just
examples
and
use
cases,
and-
and
really
it's
just
whatever
seems
to
be
convenient
in
this
language.
You
should
do
I'm
concerned
this
still
might
make
daniel
and
others
uncomfortable
because
they
might
feel
like
if
they
call
something
with
span
and
ruby
calls
with
span
something
different
and
java
calls
it
something
different
that
might
confuse
users.
J
I
feel
like
I
want
the
semantics
to
be
close
enough,
so
that,
if
there's
a
name
being
used
for
a
convenience
or
an
idiom
in
one
language-
and
I
like,
I-
can
step
back
and
use
the
same
name
for
the
same
type
of
idiom.
Even
though
the
mechanics
are
different
in
every
language,
it's
not
going
to
look
exactly
the
same
okay,
so
that,
if
you
call
with
span
the
high
level,
description
should
be
the
same.
Regardless
of
what
the
actual
code
looks
like.
Okay,.
M
A
B
Josh,
can
I
maybe
throw
a
wrench
in
some
of
that?
Our
ted
sorry,
I
said
josh
ron,
wrenches
yeah.
The
an
interesting
thing
was
just
like:
go
used
to
have
a
wispan
as
well,
but
we
found
that,
like
a
lot
of
users,
didn't
really
like
the
function,
signature
that
we
have
there
and
it
didn't
serve
their
purpose.
B
You
know
as
best
as
they
would
like,
and
so
we
ended
up
just
removing
it
with
the
anticipation
that,
like
in
the
long
run,
we
should
have
more
user
studies
to
understand
like
how
we
build
out
that
api
and
how
like
it
should
actually
look
in
the
long
term,
and
so
I
think
this
is
a
really
good
discussion.
I
think
there's
a
lot
of
demand
for
community
safety,
guys
already
but
like.
B
I
do
want
to
make
sure
that,
like,
if
we're
going
to
dog
pile
some
like
things
on
there,
they're,
like
user,
informed
in
some
way
that
it's
not
just
like
developers,
have
been
doing
this
for
you
know
years
at
this
point
coming
up
things
rather
than
like
new
people
who
are
like
with
a
fresh
eye.
I
guess
that
that
is
a.
A
Very
very
good
point,
so
I
think
that
should
be
something
we're
gonna
we're
we're
gonna
need
to
get
on
that
quickly.
If
we're
going
to
do
that,
I
do
think
it
is
a
good
idea,
maybe
in
tandem
with
that,
we
should
recommend
when
groups
start
building
these
out,
put
put
it
on
a
branch
or
otherwise
in
an
experimental
place.
Don't
don't
shove
it
straight
into
stable
just
yet.
I
I
wonder
if
we
can
bring
some
like
you
know,
language
experts
to
you
know,
review
those
things
you
know
like
there's
a
couple
of
like
companies
in
this
call
who
actually
has
like
you
know
language
experts
in
you
know
employed
so
like
for
each
language.
If
we
can
designate
one
person
to
take
a
look
or
help
about
the
you
know,
the
conventions
idioms
cd
and
so
on.
That
would
be
a
very
useful
thing.
I
I'm
too
biased
about
this
project
at
this
point,
because
I
know
too
much
but
ian
from
the
go
team
is
very
interested
in
might
be,
you
know,
giving
have
some
bandwidth
to
you
know,
give
something
we
love.
D
So
I
I
think
the
language
expert
thing
is
really
good.
I
think
at
a
minimum
the
specification
just
the
only
thing
I
heard
any
kind
of
consensus
on,
or
at
least
lack
of
unconsensus
is
that
a
word.
That's
a
word
was
the
fact
that
the
convenience
api
should
call
the
api,
and
it
should
not
call
the
sdk
theoretically
or
is
that?
D
Okay
right,
I
think
let's
make
a
specification
of
what
convenience
api
means
and
what
it's
allowed
to
call
and
what
it's
not
allowed
to
call,
because
I
think
that's
actually
super
important
and
that
should
be
specified
before
the
work
kicks
off.
I
think,
like
from
what
I
understand
that
that
bit
also
can
happen
yeah.
I.
A
I
A
I
A
Yeah,
I
I
think
the
main
thing
to
be
wary
of
is
is
changing
the
the
meaning
of
open
telemetry,
but
I
do
agree
if
you're,
maybe
implementing
something
like
an
annotation,
like
maybe
at
least
in
theory.
It
should
be
like
these
should
be
broken
down
into
like
this
convenience.
Api
does
the
following
things.
So,
if
you're
an
end
user-
and
you
know
what
the
following
things
are,
then
you
know
what
this
convenience
api
is.
A
I
definitely
think
people
should
run
it
by
the
group
if
they're
looking
at
adding
things
that
couldn't
be
implemented
in
that
fashion,
maybe
I
won't
say
don't,
but
that
those
are
areas
where
I
think
we
should.
We
should
raise
an
issue
because
it
sounds
potentially
like
changing
the
model.
F
I
think
it's
it's
certainly
possible
and
probably
valuable
to
have
convenience
apis
for
both
the
api
and
the
sdk,
but
it
should
be
one
or
the
other
right
if
you've
got
a
convenience
method
that
interacts
with
the
api.
It
only
interacts
with
the
api
and
if
you've
got
convenience
methods
for
setting
up
the
sdk,
it
only
interacts
with
the
sdk.
A
Oh
yes,
totally!
Sorry
if
I
misinterpreted
this,
yes
for
the
the
sdk
setup
and
things
of
that
nature,
there
should
totally
be
more
convenience
there.
A
I
was
thinking
about
some
of
that
as
far
as
like
simplified
installation,
design
and
things
like
that,
but
yes,
absolutely
things
that
make
setting
up
the
sdk
more
convenient
would
also
be
great.
C
K
And
as
for
the
discussion
or
decision,
if
we
should
include
all
in
one
package
which
makes
it
easier
to
use
or
separate
packages,
we
should
also
think
what
stability
guarantees
we
want
to
offer
for
these
convenience
apis,
because
those
will
likely
not
be
the
same.
As
for
the
for
the
basic
fundamental
api
right.
A
Yes,
I
think
these
would
fall
under
the
same
stability
guarantees
as
any
other
api
code.
A
So
if
you're
planning
on
breaking
it
or
continuing
to
change
it,
it
needs
to
be
experimental,
which
means
it
needs
to
be
on
a
branch
or
in
another
package
or,
however,
your
group
has
decided
to
handle
experimental
code
and
once
it
gets
added
to
a
repo,
that's
declared
once
it
gets
added
to
a
module,
that's
declared
stable.
Then
it
has
to
abide
by
those
stability
guarantees
like
any
other
api
code.
A
A
We're
just
about
at
time
do
user
studies.
This
seems
to
be
a
big
bug,
bear
a
lolita.
I
know.
You've
we've
talked
about
user
studies,
but
we'll
we'll
have
to
move
on
this
quickly.
If
we
want
to
get
feedback
in
time,
so,
ideally
we
we
should
also
make
a
call
out
on
the
open,
telemetry,
twitter
and
other
places,
but
this
is
maybe
a
social
media
ask
for
people
next
week.
A
We'll
get
this
stuff,
maybe
put
together
a
little
bit
more,
but
if
people
could
start
shouting
out
in
various
places
and
looking
for
people
to
give
us
feedback
so
that
we
at
least
get
start
getting
a
list
of
names
now
would
be
a
good
time
to
do
that
we
can.
G
G
No
and
and
ted
just
you
know,
echoing
that
I
fully
intend
to
and
have
been
actually
starting
to
work
with
folks,
on
our
end
to
get
feedback
and
then
also
get
user
feedback
through
aws
channels
and
from
customers
and
also
you
know
hope
that
others
can
too.
But
we
will
definitely
help
here.
G
A
A
I
know
how
the
engine
works,
but
I
very
rarely
drive
the
car,
even
though
we
are
like
so-called
domain
experts
in
the
sense
that
we
know
how
this
thing
works,
I
feel
like
we
don't
necessarily
go
out
there
and
try
to
like
grab
a
sample
application
and
add
instrumentation
to
it,
and
so
that's
the
thing
we
can
do
as
as
maintainers
and
developers
of
open
telemetry
there's
plenty
of
applications
out.
There
grab
one
in
your
language
and
start
trying
to
instrument
it
and
discover
what
you
wish.
A
You
had
already
added
to
your
thing:
okay,
we're
we're
at
time
we'll
continue
this
discussion
next
tuesday
great
seeing
you.