►
From YouTube: 2021-08-31 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
B
So
I
think
this
is
complicated.
John,
I
know
you've
been
working
on.
This
is
traditionally
called
rum
and
john.
I
know
you've
been
you've
been
trying
to
work
on
this
issue.
C
I've
been
less
working
on
the
issue
and
more
implementing
it
for
splunk
for
on
for
mobile,
not
for
web
sure-
and
I
think
the
answer
to
the
question
is
their
appetite
is
absolutely
we've
already
got
I've
just
pasted
in
two
examples
of
semantic
conventions,
specifically
for
device
oriented
data,
so
I
think
there's
absolutely
the
appetite
for
it.
C
My
guess
is
that
this
is
more
related
to
the
the
details
of
the
actual
traces
or
spans
that
are
sent
like
what
kind
of
spans
what
kind
of
things
we
want
to
model.
So
it
sounds.
I
think
it's
actually
probably
more
of
a
rum
instrumentation
specification
ted,
so
you
this
might
be
something
we
want
to
fold
into
or
have
an
offshoot
of
the
instrumentation
group.
B
B
We
started
with
three
meetings,
but
on
monday
we
decided
that
meeting
wasn't
not
in
a
good
time
for
europe
or
a
pack,
so
we're
gonna
switch,
stick
to
a
a
thursday
apac
meeting
at
4
p.m
or
sorry,
tuesday,
apac
medium
at
4
p.m,
pacific
and
then
a
thursday
european
friendly
meeting
at
8am,
pacific
and
the
way
we'd
like
to
to
run
these
groups
is
to
focus
on
a
set
of
conventions
where
we
can
get
subject
matter
experts
to
come,
I
think
our
only
rule
is
we
don't
we
don't
want
to
bore
the
subject
matter,
experts
by
say
getting
a
bunch
of
sql
experts
to
show
up,
at
the
same
time
as
a
bunch
of
say,
web
client
experts
and
making
them
sit
through
each
other's
sessions,
but
we're
very
interested
in
tackling
all
these
different
domains.
B
So
if
people
are
interested
absolutely
show
up
to
this
group
and
help
us
out,
we
need
help
thinking
about
a
number
of
these
things
from
the
open
telemetry
side,
not
just
the
not
just
the
what
semantics
should
we
have
there's
actually
some
technical
issues
around
versioning
semantics
and
how
do
we
actually
implement
that
in
the
collector
and
a
bunch
of
other
interesting
topics?
B
So
yeah?
Please
come
to
those
meetings.
Oh
and
there's
morgan,
morgan,
hey
how
you
doing
doing
great.
We
were
just
going
over
semantic
conventions
for
clients.
We
we
do
have
a
little
bit
and
I
was
mentioning
we
do
have
an
instrumentation
group.
That's
just
kicked
off,
but
I
was
wondering
what
is
there
anything
specific
here
around
this
request
at
this
time.
D
Yes,
I
forgot
that's
the
agenda,
so
we
have
a
like
specifically
splunk.
We
have
a
robin
product
that
uses
the
hotel,
js
instrumentation
for
web
browsers,
and
I'm
not
an
expert
on
this.
But
the
team
had
mentioned
to
me
that
they
thought
there
were
some
missing
semantic
conventions
for
how
we
describe
certain,
like
user
interactions
with
the
web
browser
and
like
load
time
to
the
web,
browser
things
like
that
yeah
and
they
were
curious.
If,
if
anyone
else
was
interested
in
defining
these.
B
Yes,
yes,
we
are-
and
I
was
saying
we
have
a
meeting
two
instrumentation
meetings:
4
p.m,
tuesday
and
8
a.m,
thursday,
pacific
time
it
would
be
great
if
they
wanted
to
show
up
to
those
meetings
or
just
come
say:
hi
in
the
instrumentation
slack
channel,
we'd
love
to
to
at
least
get
their
reports
written
down
about
what
they
think
should
be
in
there
and
what's
missing
perfect,
that
is
the
exact
right
form
all
right.
I
will
send
them.
C
Morgan
morgan,
I
know
I
know
a
guy
or
two
who
also
are
involved
with
this.
D
Evo
evo,
the
the
pm
was
also
like.
He
was
the
person
who
brought
this
to
my
attention
and
wanted
to
assist
yeah
if
vivo.
B
C
C
All
right
thanks
folks,
sir
just
our
the
rpm
for
for
on
the
product
side.
A
Perfect,
thank
you
so
much
for
that.
Okay,
next
point:
josh
mcdonald
probabilities
specification
draft,
I
think
he's
not
round,
but
basically
this
is
an
issue
on
behalf
of
two
hoteps
and
basically
the
two
of
them.
What
they're
trying
to
add,
is
the
remaining
portion
for
probabilities,
probability,
sampling
and
how
to
represent
that
on
the
expand
sides
yeah.
Basically,
the
tables
have
been
receiving
a
lot
of
review
from
experts,
but
we
also
need
actual
reviews
and
approvals
from
members
of
this
community.
So
please
we
really
really
ask
you.
A
As
I
said,
there
has
been
extensive
attention
from
experts
like
odmar
from
dana
trace
and
yuri
from
paul
osman,
if
you
remember
correctly
from
honeycomb,
but
we
really
need
more
more
reviews.
So
please
just
go
and
take
a
look
at
that.
I
think
it
makes
sense
yeah.
We
need
your
help.
There.
B
Yeah
we
would
love
to
get
these
oteps
approved
and
because
it's
a
big
subject
rightly,
you
know
josh-
isn't
trying
to
to
rush
people
into
approving
things,
but
at
the
same
time
feels
like
like
we're
not
getting
as
much
feedback
as
we
would
like.
B
A
Totally
yeah
definitely
okay.
Moving
on
really
metrics
spec
update.
E
So
the
api
spec
has
been
feature
freeze
for
almost
a
month
and
we
discussed
yesterday
whether
we
want
to
move
that
to
stable
and
the
conclusion
is:
we
want
to
wait
for
at
least
three
languages
to
reach
beta
to
get
more
confidence.
So
that
brings
the
question.
I
have
to
work
with
a
language
six
to
figure
out
who
will
be
working
on
the
beta
isu.
E
It
will
be
java.net
and
something
else
and
that's
something
else
could
be.
Gold
could
be
python
or
I
I
like
I.
I
just
need
to
spend
some
time
to
figure
that
out,
hopefully
I'll
I'll,
get
a
clear
answer,
but
enough
today
and
regarding
the
isdk
part,
I
think
we're
close
to
be
able
to
cut
the
experimental
release.
There's
a
one
pending
pr.
B
Yeah
and
and
just
to
clarify
as
one
of
the
people
who
is
saying,
we
shouldn't
mark
anything
stable
until
we
have
a
public
beta.
I
don't
think
that
sdks
necessarily
have
to
have
every
feature
implemented
in
order
to
start
a
public
beta.
B
They
just
have
to
be
in
a
shape
where
we
would
feel
confident
supporting
someone
who
wanted
to
try
it
in
production
with
whatever
features
it
has.
If
we're
not.
E
B
I
think
in
the
past
we
had
these
very
long
betas
right
where
we
feel
like
we
kept
switching
things
around.
I
do
feel
like
the
metrics
group
is
working
differently.
This
time
right,
that's
part
of
the
the
big
goal
is
you've
reached
a
point
where
you
feel
confident
that
you
aren't
going
to
really
change
things.
B
So
I
think
that
is
a
good
time
for
sigs
to
start
implementing
this
assuming
the
sdk
spec
is
at
a
point
where
you
don't
think:
that's
really
going
to
be
thrashing
people.
F
I
want
to
call
out
two
things:
one
is
I,
when
you
say
beta
for
the
sdk.
Is
that
a
feature
freeze,
because
I
think
that's
the
important
bit?
Is
we
get
the
sdk
to
a
point
where
all
we're
doing
during
this
beta
process
is
like
correcting
mistakes
that
were
made
in
the
api
or
like
problems
that
occurred
from
users,
but
we're
not
adding
features
unless,
like
absolutely,
the
thing
falls
over
right,
because
we
absolutely
missed
in
a
really
critical
feature.
F
I
think
that
that's
one
of
the
way
things
that
caused
churn
before
was
we
kept
adding
features
to
the
sdk
as
we
were
launching
to
ramp
up.
But
if
we
call
beta
like
this
is
our
first
set
of
features
and
we're
not
adding
any
feature
that
doesn't
have
a
significant
amount
of
like
user,
you
know
request
behind
it.
I
think
that
that
that's
really
what
we
need
there
right
in
the
sdk.
B
So
so
maybe
the
question
there
is:
how
close
is
the
sdk
spec
to
reaching
feature
freeze.
E
B
Great
yeah,
I
think
that's
that's
kind
of
the
purpose
of
feature
freeze
is
clarifications.
Improvements
based
on
you
know,
public
feedback,
but
any
request
to
add
a
new
new
feature.
Functionality
is
going
to
say
no,
not
not
until
we
get
this
release
and
that's
a
great
time.
I
think
that's
what
this
the
sig
maintainers
are
looking
for.
Some
kind
of
indication
like
that.
F
I'd
suggest
in
the
metric
sig
we
make
the
number
one
discussion
be.
Can
we
feature
freeze
after
the
metric
reader
vr.
F
Will
be
death?
Sorry
after
riley's
current
pr,
I
think
it's
called
metric
reader,
but
I
could
have
just
thrown
out
some
random
name
in
my
head.
That's
not
what
it's
actually
called.
I
think
it's
called
metric
reader,
though.
B
And
maybe
sorry,
real,
quick
just
for
people
just
some
terminology
clarification.
We
have
terms
that
define
stability
in
the
spec
and
in
the
code
we
release,
which
are
experimental,
stable,
and
then
we
have
a
flag.
We
call
feature
freeze,
that's
separate
from
whether
it's
experimental
or
stable.
That's
just
a
way.
We
indicate
to
people
trying
to
submit
pull
requests
and
issues,
whether
we're
going
to
accept
them
or
not.
B
This
is
just
a
way.
That's
just
language
and
users
are,
are
used
to
hearing
about
having
a
beta
or
a
trial
period
and
then
a
release
candidate
when
we
think
we're
ready
in
each
sig
to
to
to
have
long-term
support
guarantees
come
in
a
little
confusing,
but
I
think
I
think
that's
the
language
that
we
we
settled
on
for
for
talking
about
this
stuff.
B
A
Cool
anyways,
perfect
yeah
yeah.
Let's
move
on!
Thank
you
for
that.
Johannes
messaging.
Semantic
conventions
work
group
starting
soon.
G
They
are
I'm
here,
as
ted
mentioned
before,
like
we
kicked
off,
instrumentation
sticks
and
work
groups
this
week
and
I
volunteered
to
drive
like
the
messaging
part
of
the
semantic
conventions
in
particular
and
yeah.
I
would
like
start
talking
about
this.
On
thursday,
the
thursday
atm
meeting
there's
a
link
to
an
old
tap
the
it's.
G
So,
if
you're
interested
in
messaging,
please
have
a
look
at
the
old
tap
join
on
thursday,
although
if
you
are
an
sme
or
you
know,
any
smes
or
you
have
some-
you
are
or
mess
or
stable
conventions
are
important
for
you,
then
please
find
find
the
smes
forward
this
and
or
have
or
let
them
have
a
look
at
the
old
tap.
I'm
not
sure
if
they
can
find
a
time
that
fits
for
everybody,
but
we
like
we
will
try
to
keep.
A
A
Okay,
I'm
going
to
the
next
item.
Yeah,
I
put
that
one
there
it's
a
new
item,
but
it
looks
interesting
enough.
It's
about
capturing
http
requests
response
headers
as
spam
attributes.
Please
review
that
yeah.
I
think
this
is
something
splunk
seems
to
need.
It's
still
interesting
for
everybody
else.
A
There
are
some
interesting
details,
so
please
take
a
look.
Likewise.
The
next
one
is
about
exempt
resource
from
attribute
limits.
You
may
remember
that
we
have
attribute
limits
for
expands
and
events
and
but
for
resources.
The
idea
is
that
we
don't
need
that,
and
essentially
one
of
the
things
that
it
seems
that
metrics
may
need
that,
like
you
know,
you
don't
want
ever.
It
seems
based
on
what
I
read
to
actually
shape
the
attributes.
A
So
please
take
a
look
at
that
one
as
well,
and
finally,
I
put
one
of
my
own
interests,
which
is
what
about
adding
service
version
as
an
environment
variable
to
the
spec,
similarly
to
hotel
service
name.
I
know
that
there
was
some
pushback
in
the
past
about
whether
we
should
keep
adding
more
values
or
not.
I
am
adding
these
because
I
know
that
on
the
lightstep
style
we
use
them.
A
We
use
this
specific
service
version
one,
and
so
at
this
moment
we
are
using
your
own,
but
we
would
probably
be
happier
if
we
were
to
use
something
that
is
used
by
the
entire
community.
So
please
just
go
and
take
a
look
at
that
and
leave
your
comments.
There.
A
F
A
Okay,
so
please
take
a
look
at
that.
It's
what's
the
number
of
issue
1782.
A
How
do
I
know
which
resource
attributes
are
important
enough
to
identify
a
promise,
use
metrics
stream,
perfect
yeah?
Let's
keep
actually,
let's
cross
reference,
close
reference
that
in
the
other
issue,
we
can
do
that
or
george.
You
can
do
that
as
well.
After
the
call.
Thank
you
perfect.
Yes,.
A
Okay,
I
think
we're
fine.
There
are
no
more
items
in
the
agenda.
Does
anybody
want
to
talk
about
something
else.