►
From YouTube: 2022-02-01 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).
C
D
So
we
discussed
last
week,
there
are
some
clarification
vrs
about
the
like
how
how
do
we
handle
multiple
callbacks
and
so
far
the
proposal
is
to
make
an
additive
change
to
the
api
spec
and
add
further
clarification
in
the
id
case
back.
So
all
these
changes
are
not
something
which
blocks
the
sdk,
stable
release
and
and
even
like
we've
been
working
on
the
matrix
back
for
very
long
time,
and
it
seems
the
language
maintainers
are
making
good
progress.
So
I
made
the
second
attempt.
D
This
is
the
pr
I'm
trying
to
see
if
this
community
is
ready
to
mark
the
spike
as
stable.
Meanwhile,
like
the
like,
the
api
improvement
can
happen
in
parallel.
It
seems
so
far.
There
are
some
concerns
from
the
javascript,
so
we
we
can
give
some
time
for
people
to
like
figure
out
like
please
comment
in
the
in
the
pr
see.
If
you
think
example
is
a
blogging
issue,
I'm
I'm
hearing
different
perspectives
depending
on
like
which
company
you're
working
for
or
like
which
language
sig
you
are
in.
D
So
I'm
I'm
trying
to
collect
more
information
and
carlos.
Maybe
you
can
help
to
to
give
people
some
clarification
about
the
expectation
on
the
timeline
maybe
like
we
can
sit
back
and
on
this
friday
we
try
to
collect
the
feedback
and
and
then
make
this
year
or
we
wait
for
the
next
tuesday
meeting
to
make
it
this
year.
D
Yeah
and
my
suggestion
is
if
something
is
going
to
take
a
long
time,
we
don't
have
a
good
estimation,
then,
let's
scope
down.
First,
we
make
sure
we
can
release
the
rest
of
things
that
we
have
reasonable
confidence
for,
since
we
need
more
time,
then
it
can
happen
even
after
the
stable
release,
as
long
as
we
mark
them
as
feature
priests
and
and
call
that
out
in
the
in
the
spec,
which
is
a
mixed
state.
E
D
They
can
run
in
parallel,
they
don't
have
to
block,
which
means
if
the
three
like
the
three
issues
like
related
pr,
can,
can
make
great
progress.
Then
it
is
a
okay
to
have
them
before
the
stable
release.
So
if
you
look
at
the
spec
issue,
I
think
there's
a
attack
that
we
invented
when
we
try
to
release
the
the
tracing
part
which
is
required
for
ga.
D
So
if
that
something
is
taxed
for
required
for
ga,
which
that
would
mean
without
this
pr
being
merged
or
the
issue
being
resolved,
we're
not
going
to
release
a
stable
version,
but
there
are
also
issues
tagged
with
like
it's
okay
to
be
part
of
the
ga,
but
not
not
necessarily
being
a
blogger.
Maybe
we
can.
We
can
use
that
to
clarify
this
state.
E
E
D
E
E
D
E
Cents
in
there,
okay-
I
I
certainly
don't
think
you
know
we
should
block
people
implementing
like
core
metrics
features.
You
know
in
the
name
of
getting
trace,
exemplars
complete
so
long
as
what
we're
marking
so
long
as
you
feel
confident
there
isn't
going
to
be.
There
isn't
going
to
be
some
kind
of
strong
cross
interaction
between
what
you're
marking
stable
today
and
yeah.
E
D
E
If
you
people,
maybe
proactively
reach
out
to
potential
contributors
who
are
going
to
want
to
have
a
say
on
this,
potentially
not
everyone's
on
this
call,
we
want
to
make
sure
we
actually
get
make
good
use
of
this
coming
week.
Poking
people
actively
would
be
good,
so
maybe
everyone
who's.
C
Perfect,
thank
you.
So
let's
try
to
go
for
next,
tuesday
and
yeah.
So
let's
see
how
that
goes.
Thank
you.
So
much
for
that.
Shall
we
move
on
then,
because
I
see
more
items
coming
so
bogdan.
Is
you
have
an
item
you
want
to
discuss.
H
Yeah,
let's
start
with
the
second
one
at
the
beginning
of
the
dock,
there
is
a
subsequent
section,
and
there
are,
there
is
one
errors
link.
Is
that
still
happening.
E
Yeah,
that's
fine,
okay,
and
we
should
probably,
I
can
add
the
there's
several
cigs
that
should
be
added
there.
Instrumentation
messaging
and
client-side.
B
H
H
Thank
you
and
the
other
one
is
a
continuation
of
the
discussion
from
last
week,
which
I
was
not
present
because
I
was
on
pto,
but
I
was
trying
to
read
the
the
issue
that
others,
sorry,
the
pr
and
the
comments
in
the
grants.
H
Pr
and
kind
of
I
I
made
my
own
version
of
what
I
understood
and
I
want
to
make
sure
we
all
agree.
That
kind
of
this
is
the
path
we
want
to
go
to
and
maybe
maybe
define
the
the
final
state
where
we
want
to
be
in
one
year
and
or
two
years
and
then
do
the
the
necessary
steps
that
we
need
to
get
there.
A
I
think
it's
good
that
they
posted
there
there
is.
There
are
two
things
that,
where
your
summary
deviates
from
what
we
were
discussing
in
the
past,
one
is
that
you
suggest
to
have
a
generic
collection
of
attributes
for
the
scope,
whereas
our
previous
thinking
was
that
it's
going
to
be
an
instrumentation
library,
name
version
and
sub
scope,
so
three
fixed
attributes
instead
of
arbitrary
number
of
attributes.
I
think
it's
definitely
worth
thinking
about
having
more
generic
set
of
attributes
hard
to
tell
like
do.
A
We
have
other
use
cases
which
can
help
with
that.
If
we
do
see
the
use
cases,
I
think
it's
worth
doing
that.
So
I
think.
H
I
think
that
matches
a
bit
more
looking
at
the
new
structured
logging,
the
new
code
scope,
things,
people
tend
to
to
add
more
informations
about
the
code,
scope
or
or
component
scope,
or
whatever
we
call
it
the
scope
than
just
the
name.
They
tend
to
add
extra
informations.
H
To
that,
that's
why
I
I
was
like
if
we
have
a
scope,
name
and
a
set
of
attributes
as
a
final
state.
The
the
library
instrumentation
that
we
right
now
have
can
become
just
a
semantic
convention
in
the
attributes
list
and
we
can
change
to
have
the
scope
name
as
the
primary
thing
there
anyway.
That
was
my
idea
of
how
to
to
address
this,
but
I
would
like
to
during
this
exercise
what
I
learned
for
me
was.
H
A
Yeah,
I
think
it's
reasonable,
so
it
would
be
good
to
post
some
examples
there,
how
what
what
a
scope
can
look
like
there,
but
I
think
the
idea
sounds
definitely
interesting
to
me.
The
second
thing
where
you,
your
proposal,
is
somewhat
different
from
what
we
were
discussing
is
that
I
think
you're
still
suggesting
to
change
slightly.
A
The
semantics
of
the
existing
tracer
acquiring
function
that
trace
proprietor
get
function
to
allow
passing
scope,
the
generic
scope
instead
of
the
library
name
and
version,
and
I
think
the
arguments
I
heard
against
doing
that
was
that
this
is
a
stable
api.
We
are
changing
the
semantics
of
a
stable
api
in
a
way
that
and
that
results
in
emitting
data,
essentially
where
we
put
a
field
which
a
value
in
a
field
which
was
supposed
to
carry
the
library
name,
which
is
no
longer
in
the
library.
So
so
so.
H
A
H
Okay,
sure
sure,
but
is
it
a
breaking
change
to
assume
that
the
first
parameter
that
we
called
we
we
said
in
the
api.
We
said
that
this
should
be
instrumentation
name
now
can
be
a
scope
name
and
one
of
the
possibilities.
Instrumentation
name,
it's
still
a
string.
It's
still
the
same
thing.
I
don't
think
that's
a
breaking
change
for
in
any
way.
I
think.
A
H
I
H
It
doesn't,
I
don't
know
if,
if
we
need
to
be
forward
compatible,
I
feel
like
we
are
backwards
compatible,
but
we
are
not
forward
compatible.
I
I
think
it's.
H
J
J
I
think
the
this
is
the
same
problem
I
have
with
trying
to
change
the
instrumentation
library
level
of
otlp
to
scope.
I
think
what
I
had
suggested
last
week
was
more
akin
to
adding
a
set
of
attributes
to
the
instrumentation
library
layer
of
otlp,
rather
than
changing
it
entirely
to
a
new
structure.
H
J
H
A
different
story
from
I
I
think
we
should
not
combine
user
like
a
collector,
is
a
user
of
that
data
model.
Let's
first
step
like
let's
first
agree
on
the
data
model,
then
then,
as
a
user
of
that
data
model,
I
will
figure
out
and
we
will
figure
out
what
to
do
with
that.
Are
we
going
to
change
the
names
or
not?
Are
we
going
to
do
other
things
or
not?
I
I
think
I
think
for
me.
I
want
to
to
to
isolate
the
problems.
That's
why
we
have
separate
artifacts.
H
K
J
mcd
can
I
okay.
I
just
want
to
say
what
bothers
me
about
this
conversation.
I
feel
like
very
few.
People
are
actually
comprehending
that
there's
a
intended
to
be
a
semantic
difference
between
scope,
name
and
instrumentation
library,
and
so
we're
having
this
conversation,
where
very
few
people
are
like
what
the
heck
is,
the
difference
here,
okay
and
then
the
rest
of
us
are
like.
We
really
want
to
make
this
change,
but
I
think
what
anthony
just
said
is
really
key.
H
K
J
And
I'm
not
saying
that
we
should
have
different
meanings.
I'm
saying
we
should
have
the
exact
same
meaning
there,
but
we
should
have
additional
fields
where
we
can
put
additional
meaning
if
loggers
want
to
have
some
value.
That
is.
That
means
a
thing
other
than
instrumentation
library
name.
Then
they
would
be
able
to
use
that
okay,
so.
H
H
J
H
H
H
Are
we
do
we
guarantee
that
using
the
api
version
1.3
and
as
a
back
like
of
a
1.2
sdk
like
in
the
same
language,
should
work.
H
So,
if
that's
not
the
case,
if
that's
not
the
case,
I
think
we
can
change
together
the
the
the
things
that
we
have
right
now
there
and
the
things
that
we
put
on
the
wire,
and
I
think
we
can
make
an
atomic
change
that
will
will
work
and
even
if
we
change
the
meaning
of
that
field,
the
the
idea
is.
If
we
change
the
first
string
to
be
the
scope
name,
we
say:
okay
for
the
the
next
version.
This
is
more
generic.
H
H
A
H
Okay,
oh,
I
will
propose
something
exactly
how
I
think,
but
I
think
it's
very
important
to
not
have
that
stream
as
a
different
meaning.
That
logging-
which
I
was
there
two
years
ago
when
I
proposed
the
components
and
everything
and
everyone-
and
everyone
was
against
that,
and
I
think
we
are
going
back
to
the
same
problem
that
that
we
are
failing
on
this.
A
Okay,
I
just
want
to
say
that
I
I
totally
understand
your
point.
I
don't
think
it's
a
huge
deal.
I
don't
think
it's
a
total
failure
or
whatever.
I
think-
and
I
agree
with
with
daniel
and
anthony
here-
that
it's
preferable
to
keep
the
expectations
of
the
recipients
of
this
data
unchanged.
H
He
will
not
be
people
will
not
put
there.
I
mean
even
anthony,
who
is
now
against
this
told
me
three
weeks
ago
that
he
would
put
class
name
there
in
an
example
when
we
asked,
if
you
would
put
class
name
there,
people
said
they
would
put
class
name
there,
so
that
it's
it's
a
failure
already.
We
are
not
following
that
contract.
K
A
K
J
Not
sure
that
they
are,
though,
like
so
in
if
I
were
using
a
logging
api
that
looked
like
the
trace
api
and
I
had
get
logger
and
it
expected
an
instrumentation
library
name.
I
would
do
the
same
thing
I
did
with
my
tracer
and
my
meter
and
provide
the
package
name
of
the
instrumentation
library.
J
H
J
K
I
said
it
already.
I
just
I
feel
like
there's
only
one
concept,
that's
useful
here
and
it
seems
to
be
going
by
different
names,
and
I
I
don't
find
the
differences
to
be
semantically
all
that
important,
but
I
would
I
would
and
if
no
one
in
logan
can
come
up
with
an
instrumentation
library
name.
I
think
we
should
end
this
discussion.
H
H
H
A
What,
if
we're
talking
hypothetically,
then
somebody
may
have
built
a
dashboard
that
shows
all
their
libraries
by
version
numbers
that
they
are
using
right.
Something
like
that
now
you're
starting
to
pollute
that
dashboard
with
some
streams
which
are
not
library
names
at
all.
A
H
K
K
K
I
would
I
would
I
would
not
be
able
to.
I
think
it
would
be
a
mistake
if
I
was
to
like,
send
you
half
a
batch
of
data
for
one
instrumentation,
librarian,
half
an
instrument
batch
for
another
like
second
batch,
because
I'm
like
literally
breaking
apart
data
that
belongs
to
in
a
unit.
So
I'm
curious,
if
there's
anywhere
in
logging,
where
there
is
a
concept
of
instrumentation
library
that
somehow
belongs.
That
would
be
several
logger
names
like.
K
I
have
a
whole
hierarchy
of
packages
now
and
like
there's
10
packages
underneath
this
directory
and
all
of
them
have
different
logger
names,
but
I
consider
them
to
be
one
instrumentation
library
and
I
want
to
make
sure
that
my
logs
are
bashed
together
in
one
instrumentation
library,
or
you
know,
like
the
concept
of
instrumentation
library,
when
I
remember
being
introduced
was
like.
I
want
to
turn
off
all
the
logs
for
that
instrumentation
library,
which,
incidentally,
is
how
people
use
logging
names.
A
I
don't
think
that's
true.
The
logging
world
is
somewhat
different.
The
logger
name,
the
acquisition
of
a
logger
by
loggername,
is
not
in
the
code
that
we
write
as
instrumenters
of
libraries.
It's
in
the
code
that
an
application
developer
wrote
somewhere
else.
They
control
what
they
pass
as
the
logger
name.
It's
not
the
library
name
of
them
and
you
don't
do
not
control
that.
A
A
H
H
Somewhere
else,
we
are
the
call
side
if
we
are
writing
an
interceptor.
The
way
how
we
write
to
right
to
create
spans
to
create
log
entries.
We
are
the
interceptors,
it's
just
like
people.
People
tend
to
to
see
that
the
fact
that
that
developers
of
the
libraries
are
doing
embedded
logging
inside
the
library
that
will
happen.
H
That
will
happen
with
metrics
and
traces
as
well.
And
when
that
will
happen,
they
will
use
the
same
name
for
the
logger,
for
the
tracer
and
for
the
meter,
because
it's
muscle
memory,
because
it's
the
same
concept,
it's
a
meter
from
a
provider.
It's
a
meter,
I'm
gonna,
use
the
same
name
as
I
use
for
for
for
for
that.
J
I
think
that's
that's
exactly
go
ahead.
If
we're
going
to
assume
that
users
are
going
to
misuse
the
library,
why
do
we
need
to
change
anything
anyways,
then?
Why
can't
we
simply
say
this
is
how
it's
intended
to
be
used.
You're
going
to
use
it
go
for
it.
The
the
people
who
receive
the
data
will
figure
out
what
to
do
with
that.
K
K
We
just
gave
it
more
symmetrics
than
we
needed
to
a
year
ago
and
now
we're
arguing
ourselves
that
we
had
that
we
had
to
do
that
or
we
have
to
do
something
because
of
that
mistake
a
year
ago-
and
I
mean
this
is
just
a
a
way
to
identify
who's
doing
the
instrumentation,
so
you
can
shut
them
off.
That's
how
I
see
it.
A
A
A
H
I
would
not
put
that
string
so
so
there
are
now
how
what
can
break
so
on
the
wire.
I
would
not
put
that
string
once
we
relax
that
I
would
make
a
change
atomic
to
not
put
that
string
in
that
id
in
the
proto
for
better
or
forwards.
If
people
were
using
it,
they
should
accept
an
empty
they're,
already
accepting
an
empty
instrumentation
name.
So
we
can
say
that
hey
this
field,
no
longer
is
populated
or
whatever
we
can
find
a
solution
to
to
not
break
the.
A
H
A
That's
a
specific
example
of
what
will
break
there.
If
you,
if
you
do
not
maintain
backwards,
compatibility
on
the
wire
that
will
break?
Oh!
No,
if
you
do
what
you
suggested
like
on
meet
the
library
name
totally,
that
will
be.
That
will
be
exactly
a
break.
That's
that's
for
logging,
correct!
That's
for
profiling!.
A
B
H
E
Is
this
something
we
can
confirm
with
people
who
are
currently
consuming
this
data?
I
kind
of
agree
with
tigran
in
the
sense
of
if
what
people
are
need
there
is
that
it
be
filled
out.
You
know
with
a
unique
string
and
the
way
they're
currently
consuming.
It
would
be
fine,
whether
or
not
that
precisely
matched
up
to
a
library.
H
By
the
way,
by
the
way,
sorry
to
say
if
the
profiling
people
are
using,
that
for
profiling
events
to
identify
profiling
events,
that's
definitely
not
an
instrumentation
library.
The
way
how
we
defined
it
so
give
me
a
break
about
about
about
keeping
backwards,
compatible
right
and
making
that
making
that
not
a
scope
like.
E
But
but
I
mean,
but
did
you
see
what
I'm
I'm
saying
baghdad
it's?
If,
if
the
case
is
that
people
are
not
are
using
that
field,
but
are
not
depending
on
it
being
specific
to
an
instrumentation
library,
then
relaxing
those
semantics,
but
keeping
it
in
that
field
would
be,
would
be
the
least
breaking
change.
We
could
do
right
like
that.
H
E
Great,
if,
if
it's
the
case
where
this
is
actually
breaking,
people
are
really
really
depending
on
that
string,
matching
some
kind
of
library
format,
which
I
can't
imagine
being
the
case
at
this
point,
yeah.
That
would.
A
J
Know
one
of
the
concerns
I
have
with
saying
you
know
we're
going
to
completely
remove
any
restriction
from
this
field.
Put
whatever
you
want
in
there
is
that
at
least
right
now,
with
the
recommendation
that
it'd
be
an
instrumentation
library,
name
and
certainly
in
ingo,
and
I
expect
that
it
would
be
this
way
and
others
that
there
is
some
sort
of
hierarchy
and
scoping
that
allows
for
natural
distinguishing
between
different
libraries,
where,
if
you
say
put
whatever
you
feel
like
in
there
and
two
people
say,
I
want
to
call
it
bob.
H
H
J
It's
used
really
for
d
duplication.
I
think
I
I
don't
know
that.
There's
anything
that
actually
breaks
that
apart,
you
know
like
for
for
go.
Maybe
it's
a
dns
based.
You
know,
package,
name,
dns
and
then
hierarchy
similar
to
url
right,
I
don't
know
of
of
anything
that's
actually
making
use
of
the
hierarchical
nature
of
that
other
than
it
provides
a
natural
way
to
avoid
duplication
of
names,
duplication
of
names.
But
again
I
I
do
not
understand.
J
A
J
J
A
We
don't
have
that
as
a
feature,
let's
say,
but
that's
that's
a
very
typical
feature,
even
in
the
logging
libraries,
where
you
can
do
filtering
based
on
the
prefix
or
stuff
like
that.
Okay,
but
today
it's
purely
for
global.
The
global
uniqueness.
Is
that
what
you
care
about?
That's
what
you're
seeing.
J
H
No,
I
think
there
has
to
be
a
recommendation.
Sorry
dania,
I
think
we'll
still
need
to
have
a
recommendation
of
how
to
fill
that
field,
but
but
there
is
no
guarantee
about
uniqueness
right
now,
so
more
than
just
recommending,
I
don't
think
we
can
do
it.
I
So
that
use
case
that
anthony
was
was
talking
about
is
the
use
case
that
we
have
also
right
now.
If
you
use
the
field
correctly,
it
is
unique
because
there
is
only
theoretically
one
library
with
that
name
right
and
if
we
change
it
to
be,
you
know
more
of
a
similar
semantic
to
the
logger
name.
Logger
names
typically
name
the
thing,
that's
being
instrumented,
not
the
thing
doing
the
instrument
thing
and
it's
it's
an
important
distinction,
and
it's
it's
the
opposite.
It's
not
just
different.
It's
literally
the
opposite.
H
No,
it's
not
the
opposite,
because
nobody
will
nobody
names.
So
loggers
are
more
used
directly
into
that
library.
People
are
not
tend
to
write
instrumentation
for
logging.
What
I
mean
here,
people
are
not
writing.
Grpc
interceptor
interceptors
to
do
logging,
because
if
I
would
have
to
write
grpc
interceptor
to
do
a
login,
I
would
still
call
the
rocker
name
as
interest
like
hotel,
interceptor,
full
logger
name.
I
would
not
call
it
grpc.
H
I
H
I
think
logging
is
mostly
using
used
by
the
library
itself.
Tracing
and
metrics
are
mostly
used
by
third-party
instrumenting,
the
libraries
correct,
but
right
now,
yes
right
now,
okay,
so
that's
why
that's
why?
But
but
logging,
if
it
stays
as
it
is,
which
is
whatever
library
is
doing,
the
instrumentation?
That's
the
name
that
you
are
using.
You
will
be
the
same.
I
mean
you
will
not.
If
I
write
an
interceptor,
I
would
not
use
the
name
of
the
logger
grpc.
I
would
say
auto
interceptor.grpc.
H
Again,
I
never
seen
people
not
using
their
class
or
their
package
in
the
logger
name,
even
though
that's
an
interceptor.
So
I
I've
seen
multiple
times
during
an
interceptor
right
for
grpc
people
needed
to
do
some
logging,
for
whatever
reason
for
to
lock
their
errors
or
something
they
were
not
using.
The
name
grpc
they're
using
the
name,
still
their
class
name.
I
I
H
J
J
H
J
If,
if
they
do
that,
are
they
going
to
end
up
doing
something
different
than
putting
the
instrumentation
library
name
there?
If
they're
the
first
party
and
the
instrumentation
and
instrumented
library
are
the
same
and
they
put
the
instrumented
library
name
there?
That
is
also
the
instrumentation
library
name,
if
they're
an
interceptor
and
they
put
their
name
there.
That
is
also
the
instrumentation
library
name,
correct.
J
I
I
guess,
I'm
not
understanding
the
reason
to
need
to
say
that
we're
relaxing
anything.
It
sounds
like
you're
saying
that
people
are
going
to
naturally
use
the
instrumentation
library
name,
even
if
they
don't
understand
that.
There's
a
distinction
between
instrumentation
and
instrumented
library,
not
the
library.
A
A
A
A
Do
you
aim
for
compatibility
with
muscle
memory
with
existing
logging
apis,
or
do
you
aim
for
more
strict
version
of
that
which
says
it
still
needs
to
be
fully
qualified
name
globally,
unique
which
is
different
from
that?
And
if,
if
that's,
if
we
do
that
other
than
do,
we
still
accept
this.
This
arbitrary
strings
as
longer
names,
tracer
names,
meter
names.
Do
we
allow
that.
H
H
H
Let
me
let
me
give
you
another
example,
because
I
had
a
debate
on
java
about
if
I
write
an
implementation
of
slf
4j.
Remember
that
debate
tigran.
So
there
was
an
implementation
of
slf
or
j
appender
or
block
4g
as
a
pender
or
something
correct,
and
they
put
the
library
name
there,
the
the
name
of
the
append
and
for
me
now
now
daniel.
H
That's
last
name
of
the
attender
yeah
the
class
name,
and
I
remember
I
had
a
long
discussion
with
this
and
I
said
that
that
should
be
the
is
the
the
sdk
part
of
the
resource,
the
sdk
thing,
and
because,
because
you
are
not
the
producer
of
that
telemetry,
you
are
just
an
implementation
of
a
logging
api.
J
H
H
A
H
G
C
By
the
way,
I
think
we
have,
we
only
have
two
minutes
left,
so
we
discuss
it
enough.
I
suggest
we
continue
on
the
actual
issue.
Please
walk
down.
Try
to
poke
people.
Try
to
guide
this
conversation.
We
have
three
more
items,
let's
probably
just
mention
them
a
little
at
least
so.
Thank
you
so
much
for
the
discussion.
The
first
one
is
the
otlp
http
json
serialization.
F
It's
it's
not
about
the
loyalty
http
it's
about
the
sterilization
format
on
the
file.
So
it's
it's
using
this
oltp
http
format,
but
it's
also
sterilizing
json
to
file.
So
it's
just
a
wrapper
for
that
and
yes.
F
C
Yeah
they
could
be
good
to
paste
it
here.
So
I
think
that
you
already
got
the
review,
but
I
agree
that
more
people
should
be
paying
attention
to
this.
F
F
C
E
E
We
created
a
team
that
has
all
the
members
from
that
working
group
who
are
willing
to
do
semantic
convention
reviews
either
as
subject
matter
experts
or
as
ensuring
that
a
subject
matter
expert
is
in
there
to
review.
So
please
look
this
over
tc
members
and
approve
it.
If
this
code
owner's
file
layout
looks
good
to
you.
If
you
want
to
see
something
different.
H
C
Perfect
yeah,
I
see
that
that's
separated
by
signal,
which
is
a
good
idea,
and
finally,
you
wanted
to
mention:
what
can
we
do
to
be
more
public
about
the
development.
E
I
I
think
we
have
to
table
this
discussion
for
for
maybe
next
week,
but
just
a
thing
to
think
about.
You
know
we're
trying
to
get
more
public
about
what
we're
up
to
so
that
includes,
you
know
more
frequent
blog
posts
about
things
being
released.
You
know
having
a
better
status
page
on
the
website,
and
the
third
part
to
me
is
when
we
have
things
in
flight
right
like
when
we're
in
the
process
of
developing
parts
of
the
spec
that
we're
trying
to
focus
on
like
logs
or
whatever.
E
What
can
we
do
to
push
that
into
the
public
in
a
way
that
would
get
us
more
of
the
attention
that
we
want
without
making
it
sound
like?
We
want
everybody's
opinion.
I
guess
so
just
think
think
about
what
people
would
feel
comfortable
with
as
far
as
like
tweeting
and
social
media
and
stuff,
but
we'll
talk
about
next
week.
E
Okay,
I
poked
there
is
an
issue
open
for
it,
I'll
poke
it
again.
Yeah.