►
From YouTube: 2022-04-19 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
B
So,
just
to
reiterate
on
the
notes
from
the
previous
meeting
so
last
time
we
agreed
that
I
will
reach
out
to
carlos
tigran
or
armin
to
get
commitment
if
they
want
to
participate
in
this
particular
group
and
the
like
the
way,
our
path
for
everyone.
B
So
today
I
was
joining
the
spec
meeting
and
asked
this
question
explicitly
prior
and
actually
it
was
was
done
as
this
issue
in
open
source
specification
repo.
So
I
just
like
just
captured
all
the
stuff
that
we
discussed
and
we
already
have
and
several
in
several
different
places
and
the
the
answer
was
that
tc
will.
B
Basically
it's
not
not
that
dc
work
to
actually
approve
or
make
it
stable
or
you
know,
do
something
with
some
particular
specification,
but
it
was.
It
was
a
suggestion
by
tigran
that
we
need
to
reach
out
to
all
the
maintainers
of
all
the
instrumentation
libraries.
B
So
we
can
get
kind
of
explicit,
I
would
say
approval
or
agreement
agreement
with
them
that
they
are
fine.
You
know
with
all
the
stuff
that
we
have
in
the
specific
in
this
http
convention
specification
as
of
now,
and
it's
ready
to
be
to
be
turned
like
a
stable.
B
So
that's
the
the
outcome
and
the
question
is
now
like
how
we
want
to
proceed
with
this,
as
as
a
group,
so
do
we
want
to.
You
know
somehow
attend
maintainers
meeting
on
monday
or
we
want
to
or
in
like.
In
addition
to
this,
we
also
want
to
create
issues
for
every
single
repo.
Just
you
know
linking
them
to
this.
One
saying
that
we
need
your
approval,
so
basically
looking
for
suggestions
from
this
group
as
well.
C
Yeah,
I
think
attending
the
maintainers
meeting,
if
allowed
to,
I
guess,
would
make
sense,
because
you
can
kind
of
just
address
all
the
maintainers
at
once
right.
B
Do
I
I
would
say
it's
something
that
we
should
do
probably
as
a
group.
So
since
we
have
these
consensus
within
this
group,
we
can
just
you
know,
involve
more
people
from
different
pieces
of
the
project
from
different.
You
know
parts
of
the
project
and
basically
looks
like
this.
This
will
be
our
way
to
to
make
it
stable.
C
Yeah
great,
so
are
you
suggesting
do
both
of
those
things
go
to
the
maintainers
meeting
and
also
make
issues
in
each
like
sdk,
repo
or
instrumentation
repo.
B
That's
a
good
question,
and
actually
I'm
I'm
on
a
fence
about
this.
So
maybe
we
can,
you
know,
collect
some
some
feedback
from
riley
as
well,
so
because
riley
was
participating
in
the
my
dinners
meetings,
probably
previously
so
riley.
Do
you
think
it
makes
sense
to
do
this
like
to
do
both
or
to
start
with
some
something
else
like
some
to
some
start
with
attending
this
meeting
first
and
then
continue
with
the
issues
or
something
something
else.
A
So
sorry,
what
do
you
plan
to
do
with
the
maintainers
meeting.
B
Basically,
as
a
part
of
the
this
meeting,
the
goal
is
to
get
explicit
approval
or
agreement
with
the
with
the
scope
and
yeah,
basically
that
that's
it
so
like
we
need
to
have.
We
need
to
receive
some
feedback
on
the
scope
and
we
need
to
maintainers
of
open
source
libraries
providing
us
this
this.
This
information,
like
do,
they
agree
with
the
scope
for
v1
or
they
want
to
modify.
Let's.
B
For
v1,
yes
for
the
for
the
for
the
for
the
stable
version,
yeah.
B
Right
but
it
is,
it
was
discussed
there
today
right
on
the
spec
meeting.
This
was
explicit
item
that
I
put
to
to
the
slack
so
here
in
the
specification
I,
like
I
reached
out
to
to
these
people-
and
the
item
was
added
to
to
the
agenda
today
and
it
was
discussed
today
and
the
the
feedback
was
that
we
should
reach
out
to
two
maintainers.
C
I
think
the
point
is,
I
think
the
point
is
that,
in
order
to
mark
the
semantic
convention
stable,
we
probably
want
the
the
blessing
of
the
instrumentation
authors,
the
maintainers
of
the
instrumentation
itself.
A
Yeah
then
it
feels
it's
not
about
scope,
so
I'm
confused.
If
you
talk
about
the
scope,
then
I
think
the
sphag
sit
is
the
right
place.
If
the
scope
is
something
that
people
agreed
on
and
once
you
have
the
proposal,
you're
saying
I
have
everything
according
to
the
scope,
but
then
I
need
three
language
maintainers
to
work
with
me
on
a
prototype
and
make
sure
it's
supported.
So
we
can
change
this
to
stable.
Then
it's
about
the
actual
implementation,
that's
the
maintenance
meeting.
A
I
don't
think
the
maintenance
meeting
is
supposed
to
cover
the
spec
scope
so
which
one
are
you
talking
about
to
clarify
the
scope
that
you
might
change
it?
You
want
to
get
feedback,
I
think
that's
a
spec
meeting
or
you
think
the
scope
is
already
pretty
clear
and
nobody
should
have
questions.
You
just
need
the
language
maintainers
to
implement
that
or
work
with
you
on
the
implementation.
B
A
A
C
A
Yeah,
so
if,
if
you
believe
there
shouldn't
be
any
outstanding
argument
about
the
scope,
it's
just
like
the
spike
is
almost
there.
You
need
more
confidence
from
the
language.
Maintainers
now
say
whatever
suggested
here
makes
total
sense.
You
should
work
with
the
maintainers
you
whether
you
join
that
maintainers
meeting
or
you
work
with
maintainers
offline.
It
doesn't
matter
or
you
can
use
the
slack
channel
as
long
as
you
get
few
language
like
like
for
metrics
my
experiences.
A
B
That
makes
sense
that
makes
sense
for
implementations.
Definitely
that's
kind
of
for,
for
the
specification
is
slightly
different,
but
it
also
related
to
the
to
the
maintainers
and
the
the
sdk
implementation
of
this
specification
so
yeah,
it's
still
not
really
clear,
at
least
for
me
like
what
does
the
process
looks
like
so
since
we
never
did
it
as
a
part
of
open-source
project
to
to
you
know,
to
make
some
specifications
stable,
looks
like
it's,
it's
still
so
foggy.
B
So
when
you're
saying
like
a
three
or
four
languages,
do
you
think
it
will
be
enough
to
got
to
get
this
feedback
about
the
the
current
state
or
the
current?
Let's
say,
scope
of
semantic
conventions
and
if
yes,
like,
which
maintainers,
which
which
languages
we
need
to
reach
out
first.
C
Yeah,
I
think
we
need
to
like
figure
out
what
we
need
from
like
the
instrument
is
like
what
what
questions
do
we
need
to
ask
them
like
what?
What
do
we
need
to
take
off
on
kind
of
thing.
A
I
shared
one
link
in
the
chat.
This
is
what
I
did
for
metrics.
This
seems
to
be
working,
although
I
I
didn't
consider
myself
doing
great
job
like
the
sdk
spike
stabilization
actually
delayed
for
for
several
months,
but
at
least
I
tried
to
calls
you
can
see
like
the
languages
that
we
agreed,
that
we
must
do
during
prototype.
A
And
even
that,
when
I
try
to
move
the
ick
to
stable
people
are
saying,
go
is
important.
We
want
the
goal
line
to
shift
the
stable
version.
Then
I
have
to
point
them
here
saying
this
is
something
great
a
year
ago
and
then
people
disagree
with
that
and
there's
no
such
governance.
I
can
tell
them
no.
We
have
to
stick
with
what
we
agreed
on.
A
A
We
have
to
negotiate
again,
so
even
that
clarity,
you
can
still
see.
We
have
some
struggle
with
the
community.
With
the
current
clarity,
I
figure,
maybe
there's
some
something
that
you
you
need
to
think
about,
like
just
make
sure
you've
done
the
part
to
make
it
as
clear
as
possible
and
you
you
make
it
hard
for
people
to
tell
you.
This
is
not
clear.
That's
my
suggestion.
C
A
D
A
D
A
Start
with
by,
like
start
by
holding
people
accountable,
whoever
agreed
on
that
old
have,
they
should
be
the
stakeholder
here.
They
should
be
actually
joining.
The
discussion,
give
you
support
if
what
they
agreed
previously
and
now
they
all
move
to
somewhere
else.
Nobody
is
supporting
you,
then
I
I
think
you
will
be
stuck
here.
D
D
We've
been
using
this
meeting
to
go
over
the
work
items,
you're
saying
we
should
make
sure
that
the
people
who
had
originally
agreed
on
the
scope
are
present
in
this
4pm
meeting,
which
clearly
today
many
are
missing
right
and
then
I
didn't
understand
the
part
when,
like
the
morning
meeting
8,
am
that
happens?
That's
the
specification
meeting.
A
C
So
it
seems
like
we've
done
that
right,
like
dennis,
did
that
today
and
he's
got
a
couple
of
actions.
I
think
we
just
need
to
discuss
how
to
execute
those
actions.
So
the
two
actions
well,
the
main
action
seems
to
be
talk
to
sdk
maintainers,
instrumentation,
maintainers
and.
C
A
A
So
I
want
to
avoid
a
situation
where
you
work
with
maintainers
and
you
got
support
from
the
maintainers.
Then
you
come
back
to
the
spec
meeting.
Then
you
got
another
suggestion
from
the
tc
saying.
Oh,
the
scope
is
not
clear.
You
have
to
rework
on
the
scope
so
just
to
make
sure
it's
very
firm
that
the
scope
is
something
people
already
agreed
on.
They
won't
change
the
scope
unless
the
maintainers
are
saying.
No.
C
Yes,
so
so
the
scope
is
agreed
from
the
maintainers.
Like
I
mean
I
can't
remember
who
who
agreed
on
the
scope
back
when
the
otep
was
merged,
but
yes,
I
basically
fought
with
those
people.
A
Yeah,
so
my
suggestion
is
to
make
it
very
explicit,
like
in
the
meeting
notes,
can
you
write
down
like,
for
example,
in
the
spike
meeting
notes?
I
would
expect
something
like
more
clear:
like
can
you
write
down?
These
are
the
three
like.
If
we
can
get
three
language
maintainers
agreeing
with
this
approach,
then
we
should
have
no
other
problems.
We
should
just
go
ahead
and
merge
the
pr.
Can
you
get
something
as
concrete
as
that?
A
C
Right
so
maybe
maybe
we
do
need
some
more
breadth
of
languages
across
this
agreed
on
this
kind
of
thing.
Yeah.
Maybe
mating
is
a
good
way
to
to
do
that
and
get
that
yeah.
A
B
So
riley
you're,
suggesting,
like
a
to
add
explicit,
like
explicitly
add
some
languages
like,
for
example,
this
yeah.
B
A
C
A
No,
I
like
actually,
no,
I,
I
feel
what
what
he
the
feedback
you
got
from
from
this
morning
meeting
is
that
the
tc
is
asking
you
to
get
the
three
language
maintainers
to
implement
the
spec
make
sure
they
can
deliver
the
actual
thing
before
they
feel
comfortable
of
marking
this
as
stable.
B
Well,
I'm
not
sure
about
the
implementation
part
to
be
honest,
and
the
thing
is
that
so
let
me
yeah
so
here
in
the
in
this,
and
this
pull
request
done
by
lanila.
B
Actually,
she
did
a
really
great
research,
like
a
witch
attributes,
were
implemented
to
each
language
so
and
two
to
which
to
which
server
to
go
to
each
kind
of
or
server
or
client
for
some
particular
languages.
So
it
was
stated
somewhere
here.
Yes
exactly
so,
it's
like
a
java.net
python
go
and
javascript.
B
So
the
thing
is
that
the
whole
specification
it
was
already
implemented.
It
might
be
implemented
differently
in
a
way
that
some
attributes,
as
you
see
here,
some
attributes
were
added
somewhere.
Not,
but
it's
it's.
It's
I'm
pretty
sure
that
http
convention
specification
was
already
implemented
by,
if
not
most,
if
not
older,
but
most
instrument,
like
is
the
case
right,
because
http
is
the
protocol
which
is
widely
used,
and
there
is
like
a
high
demand
for
this,
so
I
believe
we
can.
We
can
just
skip
this
part
saying
that
it
is
already
implemented.
B
So
the
only
thing
which
we
need
to
agree
is
like
a
do.
We
think
that
all
the
stuff
which
already
which
we
already
have
in
in
the
in
the
specification
and
will
be
changing
with
with
this
pull
request,
is
enough
to
to
call
it
stable
so
that
that's
the
only
question
and
yeah
as
as
for
as
per
tigran's
comment
or
suggestion.
B
We
need
to
reach
out
to
maintainers
and
if
you're
saying
that
it
might
be
enough
to
reach
out
to
like
a
not
not
to
all
maintainers.
But
let's
say
major
is
the
case.
For
example,
we
can
reach
out
to
exact
same.
F
B
That,
what's
done
by
the
miller
here
right,
so
this
might
be
also
enough.
So
what
I'm
going
to
do
and
like
correct
me
if
I'm
wrong
but
looks
like
it
will
be
sufficient
for
us
if,
like
we,
just
put
this
plan,
as
we
just
discussed
to
the
comment
here
explicitly
tagging
tigran
here
saying
that
tc
just
asked
us
to
to
go
to
maintainers
and
we
decided
to
go
to
this
particular
people.
B
Maybe
explicitly
tagging
them
in
this
issue,
and
this
can
be
something
that
we
can
be,
can
be
super
clear
about
like
what
exactly
going
we're
going
to
do
right
now,
yeah
and
who
we
want
to
you
know,
involve
yeah.
A
A
If
that
happened,
then
tigran,
you're,
okay,
with
merging
this
pr
as
stable.
Is
that
correct
and
once
he
confirmed,
then
you
work
with
the
maintainer
saying
this
is
what
I
worked
with
the
tc
member
tigran
and
he
agreed
on
that.
Here's,
my
ask
specifically.
I
need
you
to
confirm
something
all
right.
I
need
you
to
click
a
button
to
approve
something
whatever
thing
that
you
can
clarify.
B
C
So
I
I
don't
know
if
it's
it's
just
early
for
me
a
little
bit,
but
I'm
I'm
still
kind
of
unclear
of
what
exactly
we
need
from
the
maintainers
like
do
we
just
need
them
to
say?
Yes,
we
ye,
like
basically
just
put
yes
on
this
issue.
That
you've
got
here
just
say
yes
from
xyz
maintainers
or.
E
A
So
is
your
ask
for
the
maintainers
to
agree
on
a
scope
or
ask
for
the
maintainer
says:
hey
heads
up,
there's
some
scope
that
we
already
agreed
on,
and
I
have
this
pr
following
the
scope
that
we
agreed
on.
I
just
need
you
to
give
me
support.
Give
me
okay
and
make
sure
like
you
can
implement
that
so,
which
is
your
ask
I
think.
C
A
A
B
B
So
riley
gave
us
great
points,
so
do
you
think
something
would
be,
can
do
extra
or
improve
the
current?
The
current
way
of
thinking.
B
So
we
have
two
two
things
actually,
as
I
see
as
a
next
step.
So
the
first
thing
is
to
agree,
or
basically
you
know
get
the
explicit
confirmation
that
people
agree
with
the
current
state
of
the
spec
and
with
the
upcoming
changes
that
we
captured
here.
So
that's
the
first
thing
and
when.
B
Yeah,
we
can
start
with
dot
net
java
and
python.
So
exactly
the
same,
what
riley
was
tj's
suggestion
here,
so
the
first,
the
first
step
will
be
to
reach
out
to
tigran,
because
it
was
his
suggestion
right
to
reach
out
to
tigran,
saying
that
we're
going
to
reach
out
to
these
two
two
maintainers
of
these
languages.
B
Do
we
like
are
ready
to
to
get
it
to
get
it
to
stable
so,
and
this
will
be
the
immediate,
the
immediate
step
that
I
will
be
doing
just
today
and
let's
see
what
what
tigran
says
on
behalf
of
a
technical
committee.
C
B
C
So
can
we
can
we
like
write
this
down
on
the
on
the
page
on
the
like
meeting
notes,
so
I've
started
here,
but
so
I've
written
down
explicit
confirmation
that
people
agree
on
and
what
exactly
are
they
agreeing
on
that
issue
that
you
had
on.
B
Yeah
so
basically
on
the
current
state
of
the
http
spec
plus
changes.
B
Okay,
so
that's
the
first
thing
and
we're
going
to.
A
E
E
And
that's
from
a
tc
perspective,
right,
you're,
trying
to
make
sure
that
you
have
appropriate
sponsorship
from
someone
in
the
tc
yeah.
E
F
C
B
Yeah
we
can,
we
can
start
with
these
three
languages
because
it
was
you
know,
also
done
by
by
riley,
and
I
see
that
miller
did
the
same
previously
in
in
her
pr
here,
but
that
java
python
he
she
also
added
go
into
mgs,
but
this
three
is
here
as
well,
so
we
can
at
least
we
can
start
from
from
this,
and
we
can
get
a
explicit
confirmation
from
tigran
that
this.
This
will
be
enough
if
he
suggests
like
something
else.
We
can,
I
mean
to
add
some
some
more
languages.
C
B
Yeah,
so
basically
that's
that's
the
good
question
that
we
can
ask
them.
E
I
think
that's
going
to
comply
and
you
can
go
and
you
talk
to
tigran.
You
can
kind
of
follow
up
with
this
as
well,
but
I
would
mean
getting
to
the
maintainers
meeting
right
and
announcing
this
particular
issue
that
you
want
there,
particularly
those
three
areas
to
be
able
to
look
at
it
and
review
it
and
provide
their
agreement.
B
Yeah
that
can
be
done,
probably
extra,
so
yeah.
So
the
the
thing
about
the
about
the
meaning
is
that
there
are
too
many
people
there
and
it
might
be.
Actually,
you
know
confusing
to
asking
these
kind
of
questions.
B
B
B
Yes,
exactly
so
once
we
involve
these
these
guys
at
least
these
three
groups,
then
we
can,
you
know,
make
it
more.
You
know
ask
ask
ask
this
question
within
within
that
group
having
support
from
from
these
guys,
so
I
believe
that
that
can
be.
This
can
be
done
better.
C
C
Maybe
we
can,
maybe
you
can
edit
that
issue
to
kind
of
give
instructions
for
those
maintainers
or
or
I
don't
know
we
just
kind
of
need
a
yes,
it's
not
it's
not
really
a
pr.
It's
kind
of
more
of
an
agreement
which
is.
B
E
E
It
needs
to
be
a
documented
type
of
of
of
review
and
and
and
acceptance
on,
the
part
of
whichever
the
three
is
that
it
can
be
recorded
effectively
right,
so
ask
him
if
he
has
a
recommendation
on
that.
C
Cool,
I
think
that's
definitely
some
clarity
that
we
need
so
that's
very
useful
for
us
yeah.
I
think.
E
Yeah,
I
think
you
know
just
getting
it
before
the
the
different
eyes
and
and
being
able
to
communicate
hey.
This
is
where
it
is
and
trying
to
continue
to
move
it
forward
makes
the
the
discussion
happen
right,
as
opposed
to
just
sitting
on
the
shelf
some
place
and
the
more
conversations
you
can
had
about
it.
Hopefully
it
will
allow
it
to
move
forward
effectively.
B
Yeah,
it
sounds
fair
to
me
as
well,
so
just
just
to
reiterate,
like
we
have
this,
this
suggestion
about
slack,
but
I
don't
think
slack
is-
is
like
a
reliable
platform
or
something
that
we
can
use
for
tracking
yeah.
So
it's
just
mostly
about
the
you
know
taking
people
notifying
people,
but
I
think
all
this
stuff
should
be
done.
Yeah.
C
Yeah,
I
think,
yeah.
I
think
this
specifically
the
the
reaching
out
to
tigran
and
getting
the
confirmations
is
yeah
best
done
on
github,
just
because
it's
a
more
formal
process.
B
Sounds
good,
so
let
me
do
it
just
today
and
let's
see
what
will
be
the
recommendation,
then
from
tigran,
so
yeah,
if
you
guys
can
can
also
like.
I
keep
an
eye
on
this
this
issue
and
it's
the
comments.
That's
people
was
there
just
great
help.
You
know
moving
this
forward.
It
will
be
really
helpful.
C
I've
turned
on
the
bell
for
the
for
the
issue:
cool.
B
C
Because,
right
now
the
semantic
invention
has
yaml
and
that
yaml
generates
the
spec
tables
for
the
tracing
convention.
I'm
trying
to
get
that
going
for
the
metrics
convention
as
well.
That's
just
something
I'm
doing
in
the
background
at
some
point
I'll
need
some
some
metrics
smes
to
have
a
look
at
it,
but
yeah,
that's
just
basically
something
else
related
to
the
cement
convention.
That's
going
on,
but
yeah
that's
doesn't
really
need
discussing
here.