►
From YouTube: 2022-04-06 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
Just
posting
a
link
to
the
agenda
in
case
reggie
riley,
don't
have
it.
A
How
to
get
like
the
rest
of
this
backlog
kind
of
like
over
the
the
finish
line,
since
most
of
it
is
at
this
stage
at
this
point
where
it's
sort
of
like
this
group
has
like
kind
of
like
done
the
work
and
like
boiled
it
down
to
the
the
prs
that
are
out
there
right
now,
and
so
the
next
step
is
just
to
make
sure
we
can
get
community
feedback
processed
and
any
you
know
all
these
decisions
finalized.
A
F
That's
fine,
like
I'm
still
working
with
take
around
on
the
schema
processor,
so
we're
getting
that
underway.
F
Nice
how's
that
going
it's
still
on
the
initial
like
initial
pr
for
the
collector,
but
it's
some
really
good
communication
back
and
forth
and
ideas
with
tigran
but
like
I'm,
really
excited
for
it.
A
So
this
is
a
useful
piece
and
oh
just
to
introduce
everybody.
We've
got
riley
yang
on
the
call
riley's
part
of
the
tc
works
at
microsoft.
I
think
dennis
you
can
probably
see
him
from
where
you
sit
and
we've
also
got
reggie
who's.
A
An
engineering
manager
at
lightstep
and
reggie
managed
most
of
the
light
step,
contributors
to
open,
telemetry
and
he's
interested
in
helping
stand
up
like
a
spec
project
management
backlog
kind
of
process
to
help
make
this
whole
process
of
like
getting
all
the
spec
work,
we're
doing
lined
up
so
that
we
can
get.
You
know
attention
from
the
community
at
the
appropriate
point
when
we
need
it
and
help
kind
of
like
make
it
clearer
to
everyone
involved
in
the
spec
work
kind
of
like
what
the
overall
spec
backlog
looks
like.
A
So
I'm
excited
about
that
work,
a
lot,
because
I
think
once
we
start
doing
some
process
like
that,
we're
going
to
be
like
how
did
we
ever
get
this
far
without
it
and
riley
has
actually
done
a
great
job
of
this
in
the
past,
with
the
metrics
work
coming
up
with
like
backlogs
and
milestones
and
goals,
things
like
that
so
excited
to
have
them
on
the
call.
A
A
Awesome-
and
I
think
the
project
sean
mentioned
is
like
a
good
starting
point.
A
So
the
thing
we're
doing
in
these
these
instrumentation
spec
groups
is
trying
to
finalize
the
semantic
conventions,
basically
designing
what
data
open
telemetry
should
emit
for
all
of
the
places
where
we're
providing
instrumentation
for
things
like
standard
protocols
like
http
and
sql
and
messaging
systems
and
stuff,
like
that,
one
of
the
aspects
of
being
stable
is
that,
once
we
declare
that
data
stable,
we
don't
want
to
break
anybody's
dashboards
or
any
tooling
that
they've
set
up
to
consume
that
data,
and
that
means
we
can
still
change
and
improve
the
data
being
emitted
by
these
systems.
A
But
the
one
requirement
after
it
becomes
stable
is
that
their
needs
to
any
changes
we
make
either
have
to
be
just
completely
additional
or.
A
A
Things
like
that,
so
just
ensuring
that
we
have
we're
offering
our
end
users
like
a
coherent,
stable
model
which
is
trickier
for
open
telemetry
than
other
systems
in
the
past,
because
other
systems
in
the
past
were
totally
vertically
integrated
right,
and
so
you
kind
of
had
maybe
more
control
over
this
stuff.
More
places.
On
the
back
end,
where
you
could
you
could
roll
out
these
processors,
but
for
us
we
got
to
put
them
in
the
collector,
and
so
sean
is
working
with
tigran.
On
on
that
piece
of
the
puzzle,
we
do
have
like
a
schema.
A
Versioning
protocol
for
way
of
identifying
what
schema
things
are
coming
in,
but
we
don't
actually
have
like
something
in
the
collector
today
that
does
this
kind
of
schema
schema
conversion.
So
that's
an
important
practical
tool
we
need
to
have
in
place
before.
Ideally
before
we
start
declaring
things
stable,
we
could
start
declaring
things
stable
before
that
is
done,
but
that
means
we're
going
to
have
like
potentially
like
an
uncomfortable
moment.
A
If
we
want
to
make
any
further
adjustments
to
anything,
we've
declared
stable
because
that
that's
the
required
piece
so
they're
working
on
that
dennis
has
been
one
of
the
champions
of
our
actual
http
specification.
A
So
we've
been
reviewing
how
we
currently
describe
http
and
open
telemetry,
and
we've
made
a
bunch
of
improvements
and
dennis
has
led
a
lot
of
that
work
along
with
ludmilla.
A
And
speaking
of
that,
let
me
start
sharing
my
screen
here
and
we
can
have
a
look
at
the
backlog
that
we
currently
have
so
we've
kind
of
broken
our
backlog
down
into
well
stuff.
We've
already
done
the
things
that
we
want
to
get
done
in
order
to
declare
this
stuff
stable
and
things
that
we
think
are
important,
but
can
be
added
added
after
stability,
so
that
there's
actually
a
number
of
different
groups
who
are
kind
of
like
really
waiting
for
us
to
declare
this
work
stable.
A
So
we
feel
a
certain
amount
of
urgency
in
getting
these
last
remaining
issues
resolved
because
we
have
people
picking
us
on
a
regular
basis
asking
when
it's
going
to
be
done.
A
A
That's
not
currently
reflected
in
this
project
board,
but
that's
a
another
piece
that
this
group
would
need
to
kind
of
like
shepherd
to
completion
on
some
level,
but
just
to
go
over.
What
we
currently
have.
A
The
main
final
piece
is
just
around
the
current
http
semantic
conventions
are
kind
of
like
a
little
muddled.
They
have
a
number
of
different
ways
of
allowing
you
to
describe
the
same
thing.
So
if
we
jump
into
this
issue
here.
A
There's
things
like
http
url
can
be
broken
down
into
scheme
host,
name,
hostport
host
target,
there's
just
a
number
of
different
ways
to
break
down
some
aspects
of
reporting,
http
and
the
spec
currently
doesn't
doesn't
specify
kind
of
like
which,
which
you
should
do
in
some
cases,
and
so
part
of
what
we
want
to
do
is
actually
just
kind
of
clean
all
that
up
and
and
regularize
it,
and
to
also
differentiate
more
firmly
between
what
http
clients
should
do
versus
http
servers.
A
C
A
It's
part
of
it
in
the
sense
that
there
are
some.
You
know
some
some
aspects
of
networking
that
you
know
http
is
built
on
top
of
a
stack
and
the
way
our
semantic
inventions
work
is
some
things
that
are
common
like
port.
A
What
not
just
happen
to
be
under
a
different,
a
different
name
space,
in
other
words,
they're,
not
http,
specific
things,
and
we
don't
want
to
be
reporting
this
data
in
duplicate
and
we're
also
trying-
and
I
think,
more
and
more,
as
these
groups
do
spec
work,
we're
trying
to
avoid
situations
where
the
person
consuming
the
data
has
to
write
a
big
pile
of
complicated
switch
statements
to
be
like
well,
the
data
might
be
in
this
field,
or
it
might
be
in
this
field,
or
it
might
be
in
this
other
field.
A
A
We're
basically
saying
like
we're
getting
rid
of
that
optionality
and
say
actually
just
do
it
this
one
way
and
in
some
cases
some
cases
some
edge
cases
that
might
require
more
processing
on
the
part
of
the
instrumentation
library,
because
you
might
have
to
parse
something
or
glue
something
together,
but
we
think
those
are
rare
and
we
think
in
general,
it's
better
for
open
telemetry
to
to
be
as
regular
as
possible,
and
so
this
this
is
really
kind
of
like
the
final
bit
of
stuff.
A
The
harder
work
we've
already
done
around
just
defining
like
span
structure
and
how
retries
and
redirects
and
things
should
be
handled,
and
so
this
is
just
kind
of
like
the
last
little
bit
of
just
like
cleaning
up.
What's
already
in
the
spec.
That
was
a
little
messy
essentially.
A
So
I
won't
go
over
like
all
the
details
of
what's
in
this,
I
think
you
know,
I
request
that
you
read
it
up
with
the
ludmilla
has
done
like
a
great
job
of
actually
auditing
like
what
our
instrumentation
currently
does.
So
these
recommendations
come
on.
The
back
of
you
know
actually
doing
doing
a
lot
of
groundwork
to
figure
out
what
the
what
the
implement
implications
would
be.
So
so
we
in
this
group
actually
feel
pretty
confident
about
the
changes
that
we're
making.
A
A
A
Spec
approvers,
to
approve
it
and
getting
getting
that
attention
is,
is
a
little
difficult,
and
so
instead
we
end
up
with
these
big,
like
air
gaps
where
stuff
just
kind
of
like
languishes
and
then
in
the
background
me
usually
or
somebody
else
goes
around
and
just
like
pokes
people
to
like
respond
but-
and
we
even
somewhat
officially
say
there's
like
a
policy
of
like
if
you
propose
an
issue,
it's
kind
of
like
your
job
to
to
go
around
and
poke
people
and
get
them
to
respond.
A
But
that's
that
really
puts
a
lot
of
burden
on
the
contributors,
and
I
actually
think
it's
more.
The
responsibility
of
like
the
maintainers
and
approvers
to
to
have
a
bit
more
of
an
organized
process
around
this
stuff,
especially
the
work
that's
coming
out
of
the
spec
sigs,
if
we're,
maybe
a
little
slow
to
respond
to
pr's
or
issues
that
just
kind
of
like
come
out
of
the
blue
and
are
like
totally
unrelated
to
like
the
the
main
trunk
of
work.
A
We're
doing
you
know,
but
but
for
the
stuff
that,
like
we're
actively
working
on,
is
like
spec
working
groups,
we
need
to
to
figure
out
a
way
to
just
be
raise
like
awareness
of
this
pipeline
of
work
so
that
when
it
hits
this
stage
like
the
maintainers
and
approvers
are
kind
of
like
ready
to
catch
it,
and
people
are
kind
of
like
have
an
awareness
that
this
is
the
week
they
should
be.
A
C
C
A
Yes,
this
this
board
should
just
be
killed.
Okay,
let
me
see
if
I
can
even
just
do
that
right
now.
I
use
under.
C
Whole
problem,
I
I
can't
follow
up
on
that
number
two
like
if
we
agree
this
is
the
board
that
will
will
be
using
it,
since
we
just
created
that
one
whatever
board
we
agreed
to
use.
I
I
think
someone
who's
leading
this
effort
like
this.
This
group
should
reserve
some
time,
maybe
just
five
minutes
in
the
in
the
every
week,
spec
meeting,
just
to
give
you
an
update
where
we
are
and
what's
the
expectation
from
the
community
yeah
wow.
C
A
Totally
yeah,
I
agree,
bringing
this
to
the
main
spec
group
would
be
good
and
we
actually
like
just
made
just
made
this
project
board.
Recently,
we
weren't
even
using
one
and.
C
A
Yeah
exactly
those
those
old
boards
we
created
a
while
back,
but
then
they
weren't
actually
connected
to
any
particular
bit
of
work.
I'm
not
totally
sold
that
having
individual
boards
per
group
are
helpful.
This
might
be
helpful
for
like
the
group
to
have
a
board
for
us
keeping
track
of,
but
I
think
I
think
this
is
maybe
a
little
bit
different.
A
I
think
that
the
other
thing
we
need
is
more
for,
like
like
just
like
a
a
spec
backlog
that
maybe
doesn't
have
to
include
work.
That's
at
the
early
stages.
I'm
not
I'm
not
sure
the
best
way
to
do
this,
but
certainly
I
think
the
part
that
it
needs
to
cover
or
is
when,
when
issue
with
penny,
be
quiet.
A
A
But
I
think
the
main
thing
we
need
to
figure
out
is
that
main
group
of
like
maintainers
and
approvers,
like
what
does
that
group
need
to
be
paying
attention
to
this
week
and
then
expanding
that
out
into
having
some
amount
of
like
foresight
right.
The
next
step
would
be
feeling
like
we
know
next
week
or
the
week
after
will
be.
A
That
group
will
be
available
to
say
review
the
rum
client
instrumentation
stuff,
which
would
then
let
that
working
group
know
that
they
have
until
that
week
to
get
their
proposals
like
finalized
within
the
working
group
and
ready
for
review.
So
there's
this
more
of
this
just
like
just
getting
rid
of
these
kind
of
like
air
gaps,
basically,
where
everyone
kind
of
gets
like
surprised
by
the
work,
somebody
else
is
doing.
C
C
And
surprisingly,
I'm
not
so
the
fact
that
I'm
here,
the
other
tc
members
are
interested
in
this
topic
or
not.
Here
is
a
problem
that
we
can
fix
so
either
they
verify
that
they're
not
interested
in
this
effort.
They
should
remove
this
from
the
area
of
interest
or
they
should
come
to
this
meeting
simulate
metrics.
C
C
Like
me,
I
I'm
new
by
metrics
a
year
ago
we're
trying
to
help
but
we'll
make
mistakes,
and
we
need
those
people
who
are
more
experienced
to
come
and
we
have
to
adjust
the
time
to
make
sure
the
the
stakeholders
or
people
who
have
great
experience
can
actually
join
and
make
the
meeting.
Otherwise
we'll
just
have
a
small
group
of
people
making
our
own
decision
and
then
later
folks,
who
are
more
experienced
to
come
and
explain
to
us.
Then
we
start
to
understand
we
head
towards
a
different
direction.
A
Yeah
totally,
and
I
think
something
similar
the
the
two
people
who
have
like
semantic
conventions.
A
Well,
the
people
who
have
semantic
conventions
like
josh
is
out
on
like
family
leave
and
then
both
carlos
and
armin
are
are
in
the
eu
and-
and
this
working
group
has
a
lot
of
australian
participants,
so
you
know
so
sometimes
there's
there's
some
issues
there.
Also,
like
you
know
they
just
put
down
they're
interested
in
semantic
conventions.
That
doesn't
mean
they
have
like
expertise
in
http
but
yeah
in
general.
I
think
we
need
to
have
that
sorted
out.
A
I
did
drop
my
sponsorship
proposal
for
like
having
oteps
and
things
be
sponsored,
but
I
do
think
a
thing
we
learned
is
just
when
we
have
these
working
groups
like
there
needs
to
be
like
there
needs
to
be
tc
involvement
or
awareness
like
there
needs
to
be
a
tc
member
coming
to
the
meetings,
and
I
think
honestly,
even
if
that
tc
member
is
not
necessarily
the
expert,
it's
more
just
like
there's
an
aspect
of
the
tc
being
aware
of
like
where
the
the
pipeline
is
at.
A
A
So
I
don't,
I
don't
think
the
tc's
involvement
always
has
to
be
that
of
like
the
software
architect
or
the
technical
lead.
But
it's
more
just
this
aspect
of
solidifying
like
our
pipeline
and
having
that
be
more
coherent,
I
think
you
called
it
earlier.
Riley's,
like
part
of
it,
is
just
that
the
people
who
might
care-
or
it's
important
for
them
to
be
there
or
they're
going
to
have
to
review
the
next
stage
are
not
not
always
aware
of
like
the
work
that's
going
on
and
so
so
most
of
what
yeah.
A
C
I'm
hoping
with
the
logging
data
model
and
the
matrix
ick
swag
being
stable.
Then
we
should
have
more
energy
to
help
here
and
and
I'll
bring
this
topic
to
the
next
people
and
and
see
like
like.
Oh
I'll,
ask
these
guys
who
who
mentioned
their
interest
in
cementing
convention
like
why?
Are
they
not
joining
this
meeting?
Is
that
because,
like
just
want
to
make
sure
it's
very
clear
like
whether
it's
a
time
conflict
when
we
should
reschedule
this
meeting
to
make
sure
it's
available
care
about
this
or
like
care
about
something
else?
C
A
Yeah-
and
I
think
you
mentioned
like
priority
there
and
I
think
that's
a
thing
as
a
group-
we
have
to
start
defining
because
one
of
the
issues
I've
had
with
the
current
model
of
just
trying
to
back
channel
and
like
ping
individuals
is,
I
get
a
lot
of
response
of
like
well,
I'm
not
personally
interested
in
that
at
the
moment,
but
at
the
same
time
we
agreed
to
like
spin
out
a
working
group
to
get
it
get
it
done.
So,
there's
there's.
A
Part
of
the
issue
sometimes
is
like
it's
not
that
like
tc
members
are
like
totally
absent
or
something
it's
actually
that
like
people
are
really
busy,
but
even
knowing
that
side
of
it
right
like
like,
for
example,
I
think
if
these
working
groups
knew
that
they
weren't
going
to
be
able
to
get
a
review
in
march
because
of
the
metrics
work
and
like
other
stuff,
but
they
could
get
one
starting
in
april.
A
That
would
like
help
these
groups.
Then
you
know
organize
their
work
and
also
like
help
a
lot
with
like
expectation
management,
so
yeah,
but
but
we
don't
have
like
a
process
actually
like.
We
don't
have
any
process
for
doing
that
right
now.
It's
it's
actually
been
a
little
right
like
like
in
the
ether,
if
you
show
up,
like
we
kind
of
know,
generally
what
our
priorities
are.
A
But
we
haven't
like
like
turned
that
into
like,
like
an
official
process,
so
yeah,
that's
next
and
reggie's,
like
I
mentioned
available
to
he's
very
graciously
offered
to
help,
do
some
of
like
the
tpm
technical
project
management
side
of
that.
A
Cool
well,
that's
kind
of
where
we're
at
and
yeah.
We
actually
don't
don't
have
too
much
else
in
our
backlog.
Unless
we
want
to
start
sort
of
moving
on
to
some
of
the
v2
issues
like
context
propagation,
I
will
mention
one
thing
we
moved
to
v2
riley
was
we
were
using
links
to
describe
the
relationship
between
retries
and
redirects,
because
it's
possible
for
machine
analysis
to
maybe
like
infer
retries
and
redirects
by
by
analyzing.
A
You
know
patterns
in
the
data,
but
we
wanted
to
go
a
step
further
and
rather
than
like
force,
people
to
write
heuristics
to
do
that.
Just
just
add
links
within
the
trace
so
that
it's
a
hundred
percent
clear
that
there's
a
a
retry
link
between
like
this
span
and
the
span
and
the
span,
but
we
actually
haven't
used
links
for
much
of
anything
and
this
use
of
links
is
like
pretty
different
than
the
sort
of
original
use
that
links
were
designed
for
which
were
for
kind
of
like
fan
out
fan
in
situations.
A
So
we
punted
on
that
for
for
v1
because
it
seems
like
it
got
bundled
up
in
like
a
broader
discussion
that
also
the
messaging
group
and
like
other
instrumentation
groups,
are
wanting
to
use
links
for
various
things,
and
so
that's
an
example
of
something
where
we
actually
need
to.
A
We
need
like
tce
like
like
spec
maintainer
involvement
around,
like
you
know,
making
sure
in
general.
The
way
we're
using
links
are
is
coherent
and
and
kind
of,
like
figuring
out
like
like
a
general
model
for
for
for
how
links
should
work
and
if
we're
gonna
use
them
for
different
use
cases.
How
do
we
differentiate
those
use
cases
things
like
that?
A
So
we
punched
on
that
for
v2,
but
that's
a
great
example
of
something
where
getting
that
into
the
like
main
spec
working
group
backlog
to
like
figure
out
some
time
where,
like
as
a
community,
we
can
just
like
hash
out
this
whole
like
links
stuff,
so
that
you
know
all
the
different
subgroups
can
can
finish.
Their
work
would
be
helpful.
E
Yeah,
but
before
before,
we
move
to
v-necks.
Actually
I
maybe
want
to
ask
us
to
like
maybe
today
on
this
meeting,
to
identify
like
which
particular
steps
we
want
to
define
to
make
sure
we
know
what
to
do
to
close
on
the
first
version
to
make
it
stable.
So
as
it
did
mention
like
we
have
this
ego
open
by
the
miller,
and
basically,
we
already
have
a
proposal
or
like
this
draft
pr
to
the
spec
needs
to
be
reviewed.
So
basically
we
just
need
to
this.
E
We
need
to
have
some
tc
members
to
review
this
particular
vr,
and
it
looks
like
carlos
and
antigran.
They
are
interested
in
reviewing
this.
E
It
might
be
tough
just
because
the
chan,
the
amount
of
changes
is
kind
of
it
can
be,
can
be
big,
so
we
can
just
figure
need
to
figure
out
like
what
exactly
what
what
which
which
amount
of
changes
we
want
to
merged
merged
to
be
merged
like
into
the
first
version
and
what
we
can
like
a
postponed
for
v2
or
we'll
be
next,
but
still
like
this.
C
Yeah,
I
totally
agree,
and
I
will
question
for
for
dennis-
would
it
be
possible
that
we
give
you
five
minutes
in
the
every
tuesday
spec
meeting
and
you
represent
this
school
to
report
back
where
we
are.
E
That's
definitely
possible
for
the
next
several
weeks.
The
thing
is
that
I'm,
not
I'm
not
really
sure
about
the
can.
I
commit
to
like
a
be
present
every
time
or
not.
So
that's
something.
That's
like.
I
still
need
to
figure
out
with
my
team.
C
Freedom
like
matrix,
I
made
it
very
clear,
I'll
I'll
handle
the
20
minutes
time
box
in
the
spec
meeting.
If
not,
if
I'm
not
there
I'll
work
with
gmacd
or
just
storage
like
last
year
or
whoever
we
had
like,
we
had
an
agreement
offline
that
we're
going
to
take
20
minutes
and
we're
going
to
support
each
other.
So
do
you
feel
like
there's
anyone
who
can
who
can
back
you
up
here
or
we
simply
don't
have
the
car
on.
E
That's
a
good
question:
we
can
probably
discuss
it
offline
with
several
folks.
Currently,
I
cannot
like
a
call
any
name,
so
what
I
I
can,
what
I
can
do.
Actually
I
I
can
make
like
a
I'm
pretty
sure
that
it
will
be
possible
for
me
to
do
that
like
a
five
minutes,
every
every
meeting
on
on
tuesday,
like
8
a.m,
to
make
sure
that
we're
done
with
b1
so
for
for
for
this
particular
milestone,
I'm
pretty
sure
I
can
do
it.
E
So
if
we
can
do
it
like
in
this,
let's
say:
roadmap
saying
that
we
can
focus
on
the
v1
and
make
sure
we're
done,
and
then
we
can
somehow
reorganize
and
probably
have
another
people
who
can
be
helping
and
leading
all
this
stuff.
Then
it
works
for
me
for
sure.
A
And
if
we
can
make
that,
I
think
you're
right
riley
having
a
like
a
standing
block
in
the
main
spec
meeting
for
talking
about
instrumentation
every
week
is
a
great
way
to
to
get
the
kind
of
attention
we
need
and
we
could
make
it
just
like
a
generic
instrumentation
block
so
that
this
group,
as
well
as
like
the
rum,
client
instrumentation
group
and
like
the
messaging
group,
all
know
that,
like
you
know
when,
when
they
that
that's
the
place
to
to
to
send,
send
somebody
from
the
group
to
to
be
able
to
talk
through
and
raise
awareness
about
the
work
they're
doing.
A
D
Yeah
I
agree,
finding
ways
to
just
communicate
with
the
community
is
is
what
we
want
to
try
to
do
and
to
board
one
aspect
of
that
and
then
being
able
to
come
to
the
spec.
Sig
meeting
is
another
aspect
of
that.
I
think.
C
Yeah
and
let
me
ask
a
question
about
the
overall
products
state,
so
is
there
any
tc
member,
for
example,
carlos
or
tigran,
or
arming
aligned
on
the
overall
scope
like
the
v1
scope,
or
this
v1
scope
is
just
proposed
by
this
sig,
never
revealed
by
the
tc?
C
Okay,
well,
more
more,
the
latter
yeah.
So
I
I
feel
maybe
the
the
first
like
the
five
minutes
that
we
take
is
to
give
people
like
this
is
the
scope
that
we
we
we
want
to
like
focus
on,
for
we
want,
and
I
guess
the
outcome
could
be.
People
are
saying
yeah
we
agree
or
not,
or
someone
from
the
tc
is
going
to
follow
up
and
make
sure
we're
aligned
or
they're.
C
Saying
oh
actually,
there's
a
bigger
effort
in
this
fact
somewhere
else
like
the
versioning
or
how
do
we
organize
these
things
and
that
that
must
be
resolved?
Let
me
kind
of
debate
or
we
can.
We
can
sort
that
out,
or
maybe
people
can
give
suggestions
saying
this
is
actually
a
much
bigger
scope.
We
should
further
scope
down
and
let's
just
release
0.5
so
for
for
matrix.
I
I
think
it
probably
took
like,
like
four
meetings,
just
to
agree
on.
C
What's
the
scope,
because
people
are
talking
about
hey,
we
need
the
bond
api,
we
need
hint
api,
we
need
exponential,
two
histogram
they're
loud
and
we
we
have
to
control
the
scope
for
for
this
group.
I
I
guess
the
challenge.
Maybe
it's
not.
The
control
scope
like
http
is
already
a
very,
very
concrete
thing.
I
guess
the
challenge
is:
is
there
any
additional
work
in
the
specs
that
people
consider
as
a
blocker,
for
example,
like
the
night
part?
C
We
even
think
the
next
part
is
a
must-have
for
http,
or
it
can
be
a
separate
thing
and
even
for
hdp
do
we
need
to
have
every
like
what
about
like
anything
out
like
we
mentioned
something
they're
optional?
What
about
like?
We
just
forgot
about
optional,
just
get
the
required
thing
done
and
then
we
can
add
up
because
it's
optional
right.
C
Maybe
we
can
just
add
the
optional
things
later
so
so
this
might
be
some
challenge
from
the
tc,
because,
from
my
experience
working
on
metrics
I've
seen
most
of
the
tc
members,
they
try
to
be
conservative
and
they
try
to
scope
down
you
guys.
Looking
at
http,
you
have
better
idea
whether
like
people
ask
you
like
just
forget
about
the
optional
thing
focus
on
required.
Would
that
be
okay
or
you
think
that's
not
acceptable.
C
E
Actually
we
also
like
to
spend
some
time
within
this
group
to
identify
the
scope
and
what
exactly
should
be
done
for
we
want
and
what
we
can
do
for
like
a
next
version
so-
and
I
just
shared
the
the
link
to
the
chats
to
this
particular
out
app,
so
we
just
made
it
as
a
part
as
a
in
in
form
of
like
in
shape
of
auto
tap
to
capture
all
the
all
the
considerations
there
and
also
bring
some
links
to
some
another
open
issues
that
we
have,
and
this
is
something
that
was
approved
by
dc.
E
So
since
we
already
have
the
master,
our
main
main
branch
in
upon
telemetry
all
taps,
it's
already
there.
Probably
it
will
be
good,
really
good
idea
to
also
like
a
reiterated,
discuss
it
during
these
five
minutes
next
tuesday,
and
make
sure
that
we,
like,
I
have
the
same
understanding
regardless
it
was
approved.
We
can
just
you
know,
reiterate
it
once
again
and
make
sure
that
we
are
on
the
same
page,
and
this
can
be
the
good
starting
point
for
sure.
E
E
So
maybe
we
can
do
it
as
a
spiral
like
agreeing
on
the
scope
or
like
just
confirming
that
this
scope
is
that
how
we
define
it
but
still
make
some
progress
on
the
open
items,
because
it's
still
in
scope,
it's
something
that's
been
discussed,
really
heavily
and
that's
something
that
we
still
need
to.
I
mean
it
needs
to
be
solved
anyway,
so
we
started
a
discussion
today
morning.
E
So
that's
basically
my
proposal
like
to
make
sure
that
we
agree
on
a
scope
with
tc
members
who
want
to
participate
here,
but
in
the
same
time
also
make
sure
that
we
are
not
only
agreeing
on
something
but
also
like
a
moving
forward.
Yeah
yeah.
A
Or
something
like
that
and
riley
yeah,
I
do
think
this
is
in
you
know
better
shape
than
the
kind
of
like
issues
metrics
has
I
mean
metrics
was
pretty
epic
for
one,
but
also
like
there
has
been
a
lot
of.
There
has
been
a
lot
of
round
and
round
feedback
with
this
stuff.
So
it's
not
it's
not
totally
out
of
left
field,
and-
and
actually
at
this
point
you
know
we're
basically
down
to
one
pr
left
to
get
it
declared
stable.
A
So
so
it's
not
a
yeah,
we're
kind
of
like
actually
in
that
stage
where
it's
not
like
this
huge
road
map
of
work,
it's
more
of
like
we've,
been
kind
of
like
held
up
getting
this
last
last
bit
just
kind
of
like
looked
at
for
like
practical,
practical
purposes,
yeah.
A
Yeah,
but
I
I
have
more
faith
that
this
is
not
going
to
to
get
a
big
radical
rewrite
the
way
metrics
did.
I
I
think
metrics
is
like
a
special
special
beast
in
that
regard,
but
but
at
any
rate,
yeah
the
the
in
terms
of
like
moving
forwards,
while
also
having
this
like
broader
discussion
of
getting
people
up
to
speed
with,
like
you
know,
what
should
the
scope
be,
and
you
know
how
do
we
you
know?
How
do
we
project
manage
this
stuff
yeah?
A
The
the
practical
next
step
would
just
be
to
get
tc
approver
feedback
on
that
one
pr
that
ludmilla
has
out
there.
I
saw
you,
I
think
you
had
it
marked
as
a
draft
food
miller.
Is
that
it's
still
it's
in
a
state
where
you
want
feedback
right
now,
though,
yeah.
B
Yeah,
I
still
want
feedback
and
I
think
I
marked
it
this
draft,
because
I
cannot
change
all
the
tooling
behind
it.
So
it's
it's
like
the
agree.
I
want
to
agree
on
the
concept
before
we
get
into
the
weeds.
C
And
probably
army
as
well,
because
army
has
a
lot
of
experience
on
the
spending
like
the
tooling
part,
from
what
I
heard
from
from
tigran
this
morning,
I
I
he's
a
little
bit
anxious
about
the
scope.
It
seems
we're
increasing
the
scope
like
it
seems
we're
a
little
bit
stuck
here,
we're
slow
and
we
try
to
accomplish
something
and
the
way
we
try
to
accomplish.
That
is
not
by
reducing
the
scope,
but
in
turn
we
try
to
increase
the
scope.
A
Yeah
yeah
we're
we're
practically
done
we're
like
inches
away
from
the
finish
line
here
so,
but
I
do
think
yeah
having
this
a
process
in
place
for
for,
like
the
remainder
of
the
work
because
yeah,
some
of
it,
like
you
said
riley,
does
involve
broader
discussions
right
like
around
links
and
things
like
that,
where
it's
like,
not
good
for
like
a
working
group
on
http
or
something
like
that
to
go
about
defining
some
of
that
stuff
on
their
own
right.
A
Like
some
of
the
work
we
do
like
raises
broader
questions,
and
so
we
need
to
get
that
on
the
roadmap.
But
those
are
also
examples
of
where,
if
we,
if
we
had
had,
I
think
tc
involvement
in
these
working
groups,
as
they
were
going
on,
then
that
that
awareness
would
be
would
be
happening
a
little
more
more
naturally.
So,
but
I
have
faith,
I
think
we
we've
got
some
interest
in
getting
that
whole
that
whole
pipeline
sorted
out.
So
so
I
think
that's
that's
most
of
what
we're
talking
about
going
forward.
A
I
think
could
get
solved
in
the
context
of
of
trying
to
build
out
some
kind
of
pipeline,
but
certainly
having
you
here
is
like
really
helpful.
Likewise,
if
we
can
start
getting
a
tc
member
to
join
the
rum
working
group
on
wednesdays
and
the
messaging
working
group
on
thursdays,
that's
just
like
a
good
concrete
step.
So
you
know
at
least
somebody
on
the
tc
is
getting
some
direct
experience
with
that
group
and
that
group's
getting
to
know
somebody
on
the
tc.
B
C
Here
to
facilitate
the
progress
like
I'm
treating
myself
as
expert,
don't
expect
me
to
be
expert
on
any
semantic
convention
like
I've
been
driving
the
common
schema
in
microsoft,
and
I'm
tired
of
that
I
so
I
take
this.
Mental
convention
is
a
very
subjective
thing
and
it's
not
hard,
like
any
people
can
put
their
opinion
and
in
microsoft,
I've
seen
people
fighting
each
other
I'm.
So
I'm
tired
of
that.
C
I,
I
don't
think
I'll
do
a
great
job
in
driving
people
to
agree
on
something,
but
I
can
certainly
help
to
see
what
are
the
issues
we
can
solve
and
maybe
by
just
aligning
the
right
people
here,
we
can
move
forward.
That's
my
goal,
so
I
I
won't
spend
my
time
reviewing
every
single
pr
here,
but
if
you
need
me
to
point
other
folks
or
I'm
saying
like
we're,
stuck
just
to
get
the
clarity,
whether
the
tc
members
are
really
like
available
here
or
the
same,
it's
not
important
just
delay
the
effort.
C
You
know
like
the
like
the
matrix
part,
we
have
the
like
the
bond
api.
I
think
one
thing
I
hope
this.
I
made
it
very
clear
for
everyone.
If
bangla
api
is
important,
then
people
who
are
saying
it's
important.
They
must
come
to
the
meeting
and
talk
about
that
and
make
decision.
C
A
Thanks
yeah
and
yeah
for
the
record,
I've
been
asking
riley
to
show
what,
mainly
because
armin
and
carlos
who
are
more
interested
in
semantic
conventions,
just
can't
they're
both
in
the
eu.
So
they
can't.
They
can't
practically
come
to
this
meeting,
and
we
want
to
keep
this
meeting
in
the
afternoon
so
that
the
australian
participants
can
remain
involved
and
yeah.
Like
riley
said.
I
think
it's
just
important
that
at
minimum
somebody
from
the
tc
is
is
in
each
working
group
to
help
make
sure
things
aren't
getting
dis
disjointed
in
some
way.
A
Yeah,
so
I'm
excited,
I
think
things
are
going
to
get
better.
We
had
kind
of
like
a
big
learning
curve
in
like
q4
around
this
stuff,
where
we
spun
up
like
these
groups,
but
they
were
a
little
disconnected
from
from
like
the
core
there's
like
a
lot
of
new
contributors.
A
Basically,
and
they
did
a
lot
of
good
work
but
yeah,
then
we
kind
of
it
started
to
lay
bear
the
fact
that
our
process
was
like
really
informal,
because
now
we
had
a
bunch
of
new
contributors
and
it
wasn't
clear
how
to
then
like
move
the
work
out
of
out
of
the
working
groups
and,
like
you
know,
into
the
spec.
So
I'm
excited
to
get
get
that
kind
of
like
sorted
out
over
the
next
month.
A
And
on
that
note
I
don't
know
just
got
a
couple
minutes
left
ludmila.
Did
you
have
any
questions
or
things
you
wanted
to
discuss
specific
to
your
pr
like
any
feedback
you
wanted
from
us,
or
are
you
all
good
there.
B
E
Yeah,
since
we
had
this
call
out
from
from
tc
members
like
carlos
and
aman,
probably
I
can
just
put
this
link
to
the
pr
to
the
notes,
just
because
folks
we're
like
talking
about
that,
they
will
follow
up
with
notes
from
from
this
meeting.
So
maybe
we
can
just
put
it
as
an
explicit
item,
so
they
can
know
that
we
are
waiting
for
their
feedback.