►
From YouTube: 2021-05-11 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
B
C
C
This
one
I
already
see
reply
from
tigran,
so
the
ask
is
basically
hey:
we
have
specific
data
model
for
metrics
and
logs
for
choices.
It
will
be
great
to
have
that.
It's
not
a
blocking
issue
kind
of
nice
to
have
so
I
I
think
this
is
something
we
can
do
at
additive
change,
and
I'm
not
sure
if,
if
tom
is
here
seems
not.
A
Yeah,
I
think
this
is
this
can
be
very
useful
and
obviously
it's
not
a
change
in
the
sense
that
there's
no
semantic
change
right,
it's
more
like
adding
whether
there
if
there
are
any
missing
bits
or
just
extracting
the
the
bits
that
exist
from
the
the
document
that
we
have,
that
the
overview
there
right.
So
it's
kind
of
like
having
the
most
dedicated
document
for
the
model.
I
find
it
very
useful,
yeah.
C
C
C
I've
seen
several
issues
opened
by
the
same
people
and
hi.
Do
I
pronounce
your
name
as.
C
D
Welcome
so,
while
building
the
real
user
monitoring
solution
using
open,
telemetry,
jes
sdk
have
stumbled
upon
at
splunk
have
stumbled
upon
kind
of
issues
where
the
semantic
conventions
are
not
really
fully
applicable
to
the
to
model.
The
the
way
the
browser
side
of
the
world
works
and
looking
for
experts
in
the
in
the
area
in
the
companies
here
who
have
maybe
faced
similar
issues
or
are
looking
for
converging
into
open
telemetry
with
with
with
their
ram
offerings
as
well
to
understand
how
these
should
be
represented.
D
C
C
I
I
believe
the
semantic
combination
part
we're
trying
to
divide
and
conquer.
So
if
you
want
to
take
a
lead
on
this,
there's
a
like
channel
on
slack,
where
we
talk
about
instrumentation
and
semantic
convention
is
a
blocking
issue
for
instrumentation
library
to
become
stable.
So
my
suggestion
is,
I
continue
the
discussion
here
while
say
hi
on
the
slack
channel
instrumentation.
If
you
couldn't
find
it,
you
can
ping
me
offline,
yeah
I'll
point
you
to
that,
and
there
there
are
many
folks
who
who
want
to
work
on
different
parts.
E
If
I
can
make
a
request,
one
of
the
things
we're
looking
for
is
is
to
to
test
it
out
without
actual
instrumentation,
if
you're,
if
you're
designing,
if
you're
designing
the
semantic
conventions
here,
it
would
also
be
great
to
be
writing
a
javascript
module
or
forking
an
existing
one
to
to
bake
in
the
actual
capture
of
these
metrics.
Just
to
to
make
sure
that
that
it's
cohesive.
E
It
a
lot
easier
to
to
evaluate
once
we're
doing
conventions
for
things
that
don't
strictly
match
like
a
protocol
like
http,
you
know
we
have
to
make
sure
it
actually
works.
So
thank
you.
D
C
I
I
see
so,
do
you
think
he
will
have
energy
to
take
a
lead
on
this
and
drive
this.
I
mean
there,
there
will
be
people
who
are
interested
and
ultimately
will
try
to
spread
the
the
workload
among
people.
So
if,
if
you
have
like
better
domain
knowledge
on
this,
we
might
rely
on
you
to
drive
this
while
seeking
the
other
experts
to
join
the
discussion.
D
A
Yeah,
I
think
that's
definitely
doable
even
we
can
work
together,
but
I
I
would
also
very
much
look
for
others,
people
from
other
companies
not
from
splunk,
to
also
help
us.
If
it's
just
me
and
you,
then
we
wouldn't
need
to
discuss
it
here
right.
So
we're
essentially
looking
here
for
others
who
are
interested
in
the
topic
to
join
us
and
to
work
on
this
together.
But
I'm
definitely
here
to
help
you,
though,
so
I
guess
what
I
the
question.
C
F
Fantastic,
thank
you
so
much
for
that.
The
first
item
is
for
me
just
a
long-term
reminder
that
we
have
have
on
a
rated
note
semantic
convention
prs,
and
sometimes
we
don't
have
enough
people.
F
F
A
Do
so
this
is
the
we
have
the
otep,
which
is
approved,
the
telemetry
schemas.
Now
I
am
kind
of
extracting
the
bits
and
portions
from
the
old
tap
and
merging
them
to
the
relevant
parts
of
the
specification.
So
this
is
the
the
first
one
that
goes
to
to
the
spec.
A
It's
a
tiny
modification
backwards,
compatible
modification
of
the
api,
the
tracer
api
and
and
also
a
corresponding,
very
small
addition
to
the
otlp.
Please
do
review
formally.
I
have
the
required
number
of
approvals,
but
I
don't
want
to
merge
it
until
I
see
I.
I
have
a
lot
more
eyes
on
this,
because
it's
a
minor
impact
for
every
individual
person
taken,
but
overall
it
affects
end-to-end
a
lot
of
things
in
in
open
telemetry,
the
api,
the
sdk
the
protocol.
A
So
I
definitely
would
want
to
see
to
have
more
people
actually
seeing
this
change
happening,
maintainers
as
well.
All
of
the
maintainers
they
will
need
to.
They
will
need
to
do
small
amount
of
work,
but
they
will
need
to
do
that
right.
All
of
the
six
will
need
to
do
that.
So
please
have
a
look
and-
and
I
also
started
draft
changes
in
the
go
sdk,
so
I
will
be
working
with
co-maintainers
on
this.
F
Yeah,
actually,
I
think,
that's
very
good.
That's
one
of
the
things
that
I
have
seen
that
it's
very
important
and
we
forget
quite
often
that
we
need
to
prototype
something,
at
least
in
one
language
before
it
goes
into
the
specification,
and
this
is
something
important.
You
know
yeah
yeah,
that's
pretty
high
yeah.
A
I
do
have
a
personal
prototype
and
I
now
started
actually
upstreaming
that
to
to
the
actual
go
sdk,
I'm
working
with
co-maintainers
right
now
I
have
drafts
open
and
I
think
that
will
help
the
others
to
also
see
what
is
necessary
changes.
It's
not
a
ton
of
changes.
The
amount
of
volume
is
small,
but
all
of
all
of
the
languages
are
affected.
So
that's
why
I'd
like
to
see
more
more
people
approving
reunions.
F
G
F
Yeah,
perfect
yeah,
please
everybody!
If
you
have
time
check
it
out,
it's
a
small
change,
but
we
need
more
eyes.
Essentially
what
we're
trying
to
say
and
correct
me
if
I
am
wrong
nigita
is
that
once
the
user
said
mark
I
span,
the
status
is
okay,
that
that
remains
like
that.
That's
a
plan!
F
Thank
you.
Okay
and
the
last
yeah,
the
next
one,
which
is
probably
the
last
one,
is
also
not
mine,
but
it's
important
enough
hotel
service
name
nikita
as
well.
G
Yeah,
so
here
so
the
the
original
idea
of
pull
request
was
to
close
one
of
the
issues
which
was
about
introducing
about
extracting
one
of
the
resources
one
specific
resource
attribute
into
its
own
environment,
variable
for
for
for
sdk
or
the
service
name,
because
that's
quite
it's
de
facto
required
attribute
for
for
back-ends.
A
similar
attribute,
similar
environment
variable
exists
in
almost
every
vendor,
so
from
the
end
user
perspective,
it's
very
convenient
to
have
one.
G
The
the
only
negative
feedback
that
I
got
on
that
pull
request
is
why
only
these
resource
attributes.
Why
not
why
this
specific
is
is
special.
I
think
it
is
special,
but
anyway
we
can
add
more
resource
attribute
as
a
specialized
environment
variables.
If
we
think
this
is
useful
and
convenient,
the
only
question
for
me
probably
will
be:
how
can
we
decide
which
ones
so,
okay,
service
name
is
logical.
First
step
service
version
is
logical
or
obvious.
G
H
G
So
that
was
that
was
why
this
issue
was
created
in
the
first
place
almost
a
year
ago,
and
this
pull
request
is
just
closing
the
issue.
If
we
think
that
we
have
to
add
more
resources
to
be
rude,
but
as
well
other
environment
variables,
we
certainly
can't
do
that.
Do
we
should
we
do
that
in
all
in
one
pull
request,
or
so.
I
F
Yes,
exactly
remember
that,
well,
I
could
you
wanted
to
add
that
this
is
this.
Concern
is
related,
but
I
don't
think
it's
totally.
I
think
we
could
work
on
one
without
the
other
one.
I
think
that
what
you
want
to
do
anthony
is
something
that
we
need
to
experiment
and
we
need
more
evidence,
but
I
I
have
the
impression
that
this
change
proposed
by
the
key
that
could
still
be
merged
in
my
opinion,
and
we
can
just
work.
I
don't
know
to
the
details.
B
Sure
my
thinking
is
that
if
the
environment
resource
attributes
are
declared
as
the
the
ultimate
priority
right
that
they
have
the
highest
priority,
then
this
attribute
or
this
environment
variable
becomes
unnecessary
because
you
specify
it
through
the
resource
attribute
in
the
environment,
as
you
would
any
other
resource
attribute,
and
we
don't
have
to
have
conversations
about
what
else
should
have
its
own
environment.
Variable.
F
Yeah
and,
for
example,
in
in
like
step,
we
have
this
thing
called
launchers,
which
is
some
small
abstraction
on
top
of
the
six
code,
and
in
our
case
we
are
overriding
that,
but
of
course
we
took
that
for
granted,
but
yeah.
We
need
a
clarification.
H
I
I
want
to
clarify
this
so
for
me,
I
do
understand
that,
for
some
backends
service
name
is
very
important,
maybe
for
others
is
not
as
important
correct
and
the
fact
that
we
made
it
kind
of
required.
This
service
name
was
driven
by
the
fact
that
jager
requires
a
service
name
correct,
so
so
because
of
that,
I'm
now
seeing
two
environment
variables,
one
for
service
name
and
one
for
generic
resource
attributes
for
configuring
resources
in
general.
H
So
I
am
worried
that
by
providing
this
will
confuse
user
first
user
may
use
only
this
environment
variable
because
it
seems
so
important
that
this
is
the
only
thing
to
use,
instead
of
actually
adding
all
the
the
things
that
we
want
about.
The
service
like
namespace,
like
instance,
id
like
version,
like
other
things
that
we
may
want
it's
for
me
for
me,
the
fact
that
we
specialize
on
on
this
one
it
has
to
be
super
important
to
be
specialized,
but
it
doesn't
seem
to
be
that
super
important.
H
G
At
least
all
from
service,
okay,
then
second,
so
you
said
that
this
service
name
may
be
important
for
some
backends,
not
important
for
others.
As
a
comment
in
that
issue
shows
every
major
vendor
using
open,
even
not
everything.
Every
major
vendor
of
open,
telemetry
and
observability
has
a
specific
variable
service
name
like
lightstep
signal
effects,
datadog
new
rally,
honeycomb
splunk
everybody.
G
So
it
seems
to
me
that
service
name
is
important
for,
like
everybody
here
correct,
I
I
am
not
against
adding
the
whole
service
name
space
as
environment
variable,
so
I
I
can
do
that.
I
certainly
know
not
against
that.
Should
I
do
that
in
the
same
pull
request
and
re-ask
for
review
from
all
approvers,
or
should
I
do
a
next
one?
A
follow-up
poll
request.
E
It
it
should
be.
I
think
these
things
should
here's
the
issue
with
putting
it
all
into
one
spot,
especially
with
something
that's
a
required
variable
like
service
name.
Is
you
you
you
can
get
into
these
pipeline
problems
which
I've
I've
seen
in
real
life
where
you're
trying
to
set
this
hypocritical
thing,
but
you
don't
necessarily
know
how
to
calculate
all
of
those
resources
right.
So
if
you
start
bundling
all
of
these
resources
up
together
into
a
single
environment
variable,
then
you
run
into
trouble.
H
Wait
so
the
fact
that
the
backhand
chooses
only
service
name
to
be
the
required
and
not
service
namespace.
I
may
argue
that
is
wrong,
so
so
why
again
I'm
talking
about
the
entire
service
definition
and
stuff,
not
not
about
everything
and
now
what
it,
what
it
means
a
service.
The
fact
that
the
service
is
uniquely
identified,
just
by
name,
is
a
convention
that
different
backends,
including
splunk,
adopted.
H
But
I
would
I
would
argue
that
the
presence
of
a
namespace
is
very
important
in
real
world,
because
if,
if
I'm
talking
about
a
service
called
kafka,
I'm
pretty
confident
that
multiple
teams
will
deploy
kafka
and
I
don't
want
to
see
them
as
one
thing
and
by
convention.
I
don't
want
to
encourage
people
to
name
the
service,
kafka,
fu
and
kafka
bar.
I
would
encourage
to
have
a
namespace
called
foo
and
kafka
as
a
service.
E
Yeah,
but
just
to
be
clear,
I
I
would
maybe
I
misinterpreting
you.
I
think
you
were
asking
whether
or
not
that
should
be
a
set
of
environment
variables
or
a
single
environment.
Variable
with
like
a
some
kind
of
parsible
structure.
Is
that
that
what
you
were
saying
it
should
be
one
environment
variable
I
mean
okay.
H
G
G
J
But
well
actually,
in
the
resource
attributes,
the
notion
of
required
is
different
because
it
says
at
the
very
top
that
if
you
set
anything
within
one
of
the
sections,
then
at
least
these
attributes
have
to
be
set.
So
you
can
specify
service
dot
version
without
service
dot
name,
but
you
can
just
set
none
of
both
and
it
would
be
just
as
fine
yeah.
F
E
But
that
that
default
is
like
I
mean
that
ensures
that
back
ends.
Don't
have
like
a
literal
failure
to
ingest
the
data.
It's
it's
not
helpful
to
have
every
service
name
unknown
service.
So
I
I
think
what
nikita
is
trying
to
say
is:
can
we
can
we
not
let
perfect
be
the
enemy
of
good?
Can
we
define
this
one
and
then
continue
to
define
out
the
rest
of
the
service
environment
variables
because
namespace
and
versions
like
these
all
they
all
seem
valuable,
but
I
think
not
version
for
me.
E
For
me
the
instance
is
more
important.
Sure
I
mean
my
point:
is
they
they
all
have
they
all
have
value?
I'm
not
saying
one
is
more
valuable
than
the
other
except
service
name
is
the
one
where
if
systems
don't
have
it,
then
they
they
literally
have
a
problem,
whereas
the
other
ones
do
definitely
unlock
features
in
various
systems.
If
you
don't
have
version,
then
it's
kind
of
hard
to
do
regressions
across
versions,
for
example.
E
That's
very
useful
feature:
name
spacing
again,
like
you
said,
is
useful,
because
otherwise
people
have
to
do
silly
things
with
their
service
name,
so
so
they're
all
they're
all
useful.
We
could
define
them
as
separate
environment
variables
and
I
think
for
a
practical
matter.
That's
actually
helpful,
because
the
person
who
has
one
piece
I
in
my
experience
operator
that
information
may
not
be
centralized.
You
may
be
pulling
some
of
this
information
like
name
space
from
from
a
different
stage
of
the
pipeline.
Then
you've
got
the
service
version.
E
This
is
a
thing
I've
seen
in
the
past,
with
having
an
environment
variable
for
operators
to
fill
out
this
like
a
json
blob.
So
I
guess
the
only
thing
I
was
saying
is
it's
probably
helpful.
If
we're
going
to
call
these
out
as
like
special
environment
variables
or
sorry
special
resources,
the
service
stuff,
if
we're
gonna,
do
that,
having
them
be
separate,
environment
variables
would
be
a
better
design
than
blobbing
it
all
together,
and
if
we're
going
to
do
it
as
separate
environment
variables,
then
it's
okay
to
to
do
it
progressively.
H
H
E
That
you're,
here
too,
I
was
just-
I
was
thinking
of
saying
the
same
thing
that
you're
trying
to
say,
which
is
like
I
totally
agree
simplicity
is,
is
nice.
This
is
when
it
comes
to
configuration
you
you
end
up
with
this
chain
of
stuff,
almost
anyways
like
the
the
pile
of
like
one
unified
environment
variable.
E
That
seems
to
me
to
be
something
that
would
then
map
to
say
a
configuration
file
that
I
can
see
coming
in
our
future
as
well
for
these
kinds
of
systems,
you
do
often
end
up
with
this
hierarchy
of
different
ways
to
set
these
things,
and
that's
simply
because
the
the
reality
of
different
kinds
of
deployment
systems
and
more
complicated
operational
environments
means,
like
you,
end
up.
E
I
can
say
this
from
experience
on
cloud
foundry,
where
you
know
we
built
a
platform,
and
I
had
to
to
support
operators
and
all
these
different
kinds
of
big
enterprises
and
other
places
both
as
far
as
them,
deploying
their
apps
onto
the
system
and
also
deploying
the
system
and
and
this
kind
of
stuff
did
did
come
up
so
that
I'm
not
saying
we
shouldn't
take
like
a
comprehensive
approach
like
you're,
saying,
to
make
sure
we're
doing
this
in
a
clean
manner,
but
for
this
one
particular
environment
variable
service
name.
I
don't.
E
H
Does
that
line
of
logic
make
sense?
No,
the
fact
that
you
said
we
should.
We
should
be
careful
about
adding
new
things,
but
in
this
case
it's
fine,
I
feel
like
you
are.
You
are
applying
two
different
rules,
so
for
me
for
me,
I
wanna,
I
wanna
teach
people
that
not
teach.
I
wanna
tell
people
that
I'm
very
willing
to
say
no
for
for
for
things
that
are
not
uniform
with
others
and
and
the
fact
that
this
is
this
is
the
first
one
that
comes
from
nowhere.
H
In
a
way
I
mean,
I
know
it's
an
issue,
but
comes
from
nowhere
in
a
way
that
from
if
you
read
the
configuration
right
now,
it's
it's
just
the
the
outlier
out
of
everything
else.
That
is
the
moment
when
we
have
to
have
a
debate,
because
if
we
accept
this
tomorrow,
somebody
will
do
another
one
for
service
na
a
knee
space
and
you
will
have
to
accept
it
because
otherwise
you
will
be
bad
for,
for
the
the
the
whole
like
you
have
double
double
standards
in
these
things.
I
I.
E
Think
the
argument
that
I
I
totally
hear
you-
and
I
want
us
to
be
to
to
to
be
thoughtful
about
this.
I
guess
why
I
feel
confident
about
this
particular
one
is
because
it
is.
It
is
the
one
thing
generally
speaking,
users
have
to
set.
It
needs
to
be
set
correctly.
There
needs
to
be
a
way
for
the
operator
to
do
a
final
override
of
everything
else,
and
so
having
that
particular
one
have
an
environment
variable
to
do
that
operationally.
E
That
seems
very,
very
useful,
so
you
don't
necessarily
have
to
extend
this
to
everything
else.
It's
just
really
improves
like
say
the
getting
started
experience
and
it
gives
operators
a
way
to
override
this
one
extremely
critical
piece
of
resource.
That's
the
only
reason
why
it
seems
good.
H
To
me,
okay
for
getting
started,
I
don't
buy
it
because
for
getting
started.
You
will
not
have
that
complicated
environment
where
you
have
to
detect
dual
pens
and
stuff
just
for
getting
started.
I'm
pretty
confident
that
you
can
write
a
stupid
example
up
or
whatever
and
and
have
that
in
the
resource,
and
it's
not
gonna
help
too
much
just
for
getting
started
because
so
far
what
I've
heard
was
that
this
is
coming
from
different
places
and
it's
hard
to
to
to
merge
environment
variables
and
so
on
which
I
can
buy.
K
One
thing
I
want
to
also
just
like
kind
of
point
out
is
you
asked
this
question
a
little
while
ago,
but
like
it's
yeah,
it
is
you,
like.
You,
have
too
much
information.
You
have
too
much
knowledge
at
this
point.
In
fact,
I
think
everyone
on
the
call
does
because
we
understand
that,
like
in
the
semantic
conventions
there's
this
thing
called.
K
You
know
service,
dot,
name
and
you're
supposed
to
set
that
and
like
that's
like
the
magic
key
that
eventually
all
these
vendors
are
going
to
use
to
like
highlight
things
and
like
a
new
user
that
comes
to
the
project
they're,
like
I
don't
know
what
that
is,
I
don't
even
know
like
how
that
structure
of
the
resource
attribute
environment
variable
works.
Right,
like
I
think,
if
that's
also
something
to
keep
in
mind,
is
like
the
the
new
user
experience.
There's.
K
Things
that
have
already
been
said,
but,
like
I
think
like
one
perspective,
is
to
have,
is
to
like
keep
in
mind
that,
like
the
average
user,
that's
going
to
be
using.
This
doesn't
really
understand
a
lot
of
these
deep
concepts
and
like
okay,
so
there's
this
thing.
Where
do
I
go
put
those
things
and
do
they
have
to
match
a
certain
thing
like
there's
a
lot
of
confusion
there
for
the
users.
E
For
this
this
reason:
it's
a
thing
that
I've
I've
just
seen
from
doing
user
research
and
sitting
down
with
users
and
trying
to
get
them
started
having
it
tangled
up
and
all
that
other
stuff
really
did
did
make
it
harder,
and
it's
true
you
can
give
them
poppy
pay
stuff,
but
we
actually,
like
I,
I
agree
with
tyler
like
this-
is
a
thing
we've
actually
seen
in
the
real
world
for
the
the
minimal
stuff
you
need
to
get
started.
E
Having
that
be
easily
explainable
to
people
really
does
help.
I
bring
up
the
other
point
about
what,
as
far
as
the
order
of
things,
this
should
be.
E
This
environment
variable
should
be
able
to
override
everything
else
again,
because
I've
seen
that
from
operators
having
the
ability
to
to
override
key
key
pieces
of
configuration
without
having
to
know
the
the
rest
of
the
configuration
is,
is
definitely
a
thing
I've
encountered.
Since
this
is
the
one
piece
of
configuration
we
require.
E
H
H
Again
so
we
need
to
document
which
are
the
required
fields
or
us
pretend
to
be
particularly
required.
We
have
that
documented.
So
then,
if
somebody
comes
and
put
me
a
variable
called
aws
lambda
id
or
something
like
that,
I
can
say
no
to
that
because
for
good
or
for
bad
is
not
in
that
list,
because
otherwise
I
I'm
forced
to
say
yes,
because
there
is
a
precedence.
E
E
Right
so
so
you're
saying
that
okay,
I
see
what
you're
saying
so
we
could
add,
like
you,
know,
a
header
to
the
the
resource
conventions
right
like
it
like
just
describing
that,
like
overall
structure
when
you're
when
you're
creating
a
resource
like
service
name
like
like
you're
saying
there's
no
top
level
description,
that's
saying
like
here
are
all
the
different
resource
types.
However,
service
resource
type
is
really
important
and
out
of
that
service
name
is
required,
like
like
calling
that
out
is
saying
like
this
is.
E
This
is
something
that
that
has
to
be
set
when
you're
creating
so.
H
H
E
I
think
we're
saying
the
same
thing,
I'm
saying
I'm
saying
you're
right,
like
we
do
say
section
by
section,
other
things
are
required,
but
we
don't
have
an
area
where
we're
where
we
lay
out
what
we've
just
been
discussing,
which
is
that
you
know
you
you're
not
required
to
put
the
fast
stuff
in
if
you
aren't
running
function
as
a
service,
obviously,
but
no
matter
where
you're
running
no
matter
what
you're
doing
like
there's
this
minimal
set
of
stuff,
that's
required
right
now,
it's
just
service
name.
E
H
No,
you
have
to
make
this
the
whole
service
required
and
then
hence
service
name
becomes
globally
required.
Because
of
that
I
see
yeah.
That
makes
a
lot
of
sense.
So
so,
unless
you
put
something
like
that,
I
don't
see
any
reason
why
this
is
special,
but
so
and
again
let.
G
Can
I
can,
I
ask
again,
we
already
single
out
service
name
in
the
semantic
convention,
as
the
only
attribute
that
hdk
has
to
provide
default
value
for
without
any
explanation.
Why
exactly
this
attribute,
and
only
this
does
exactly
the
same
case,
why
we
have
singled
out
the
first
name
for
sdk
default
values,
and
that
was
okay,
but
it's
not
okay,
currently
to
single
data
out
for
environment.
J
G
H
E
That's
a
great
point,
bogdan
and
honestly,
I
think
when
it
comes
to
specifying
this
is
the
thing
in
general,
we
probably
need
to
do
more
of
which
is
document
the
the
reasoning
behind
this
stuff
right
like
this
is
one
example
of
we
understand
how
these
things
are
linked
together,
because
we've
had
these
discussions,
but
we
haven't
actually
written
that
down
in
the
spec
like
the
reason
behind
linking
these
things
together
and
and
called
that
out
in,
like
a
special
section,
I.
H
Don't
I
don't
need
the
reason
I
had
a
discussion
with
george
surett
yesterday,
like
don't
put
the
reason
into
specification.
Put
the
the
what
not
why
or
okay.
That's
that's
fair.
H
H
Yeah
the
what
means
we
have
to
say
that
that
service
name
is
a
special
thing
or
just
the
whole
service
resource
is
special
and
highly
recommended
or
required.
Hence
we
specialize
on
the
service
name.
That's
that's
the
only
thing,
the
the.
Why
reason
it
can
be
in
a
design
dock,
an
issue
or
whatever
we
have
it,
but
the
the
result
should
be
documented,
which
is
the
fact
that
service
name
is
special,
which
is
not
documented
right
now
we
we
just
find
in
places
like.
Oh,
this
has
a
default,
but
also
instrumentation
name
has
a
default.
H
G
Okay,
so
action
item
who
is
going
to
submit
that
pull
request
with
that
special
selection?
Should
I
do
I
can't
do
that,
but
I
I
don't
exactly
understand
what
should
I
put
into
that
back
down?
Are
you
willing
to
do
that
because
you
you
understand?
What
do
you
want
to
see
from
that
section?
I
suspect
not
I'm,
not
I'm
not
willing.
H
Because
I'm
against
having
this
special
thing
but
yeah
on
making
this
special,
then
I'm
fine
accepting
this
pr,
because
we
agreed
on
making
this
service
special
in
the
in
the
the
thing.
So
so
it's
a
reason
it's
a!
I
have
a.
I
have
a
a
hypothesis,
so
the
result
is.
I
need
to
have
this
environment
variable,
but
for
the
moment
I'm
just
having
the
result.
I
don't
have
the
hypothesis
okay.
Why
why
this
becomes
that?
So
I.
G
F
A
F
E
F
F
A
A
F
A
F
A
A
Backlog,
you
guys
does.
Does
anybody
want
to
take
the
lead
on
that.
F
Riley,
maybe
you
are
interested
because
you
already
have
been
showing
sorry
doing
the
triaging.
C
C
C
So
number
one
is
for
all
the
new
issues
that
are
coming.
We
use
this
meeting
and
seven
minutes
time
box
to
make
sure
they're
properly
attacked.
At
least
it
will
go
to
some
specific
sig,
for
example,
metrics
or
traces
or
resource
for
any
old
thing.
I
I
think
some
of
the
issues
have
very
long
discussion
it.
It
won't
work
here,
even
if
it
looks
one
issue
there
might
be
like
hundreds
of
discussions,
I
I
don't
know
how
to
run
that.
C
H
Okay,
so
that
that's
good
second
is
who
is?
Who
is
doing
the
trace
part?
I
mean
you
are
doing
that
for
metrics,
but
who
is
doing
the
tracing
issues?
H
H
I'm
not
saying
do
you
want
the
technical
committee
to
do
the
decisions
by
themselves,
or
do
you
want
to
have
that
with
others.
C
It's
a
question
for
me
or
for
everyone
here
for
everyone,
including
you
yeah,
so
my
take
is
similar
like
the
other
language,
six,
the
maintainers
in
this
case
the
tc
members-
should
go
and
triage
all
the
issues,
while
the
others
are
involved
in
individual
issues.
They
can
discuss
with
the
tc
member
sure,
but
this.
H
C
C
H
C
C
Like
we,
we
try
to
not
meet
too
much
right.
That's
the
problem,
because
if
you
look
at
the
total
contribution
and
the
activity
on
the
spike
ripple,
it's
much
more,
comparing
to
the
other
language
six.
I
think,
for
example,
like
the
donut
stick
that
I
join.
Sometimes
it
has
a
weekly
meeting
and
they
reveal
all
the
new
issues
and
they
discuss
things
and
make
proper
triage
and
still
that
I
figure.
Sometimes
they
run
out
of
time.
C
H
But
we
have
two
other
meetings
related
to
that
repo
one
is
called
maintainers
meeting
and
the
other
one
is
specification
meeting.
So
we
have
at
least
two
meetings
plus
we
have
metrics
meetings,
so
we
have
two
or
three
meetings
related
to
that
repo
per
week.
The
fact
that
we
privately
don't
meet
weekly.
I
don't
think
it's
a
problem.
A
Maybe,
but
I
I
think
what
what
riley
is
saying
is
that
in
this
meeting
we
probably
have
more
people
than
we
necessarily
need
for
triaging,
and
a
lot
of
people
are
probably
not
interested
in
spending
time
on
that.
I
think
I
I
get
that
we
still
can
maybe
use
the
remaining
time
and
people
can
drop
off
if
they
are
not
interested.
That's
one
possible
option.
The
other
option
is
maybe
yeah
again.
A
We
can
have
another
separate
meeting,
but
I
don't
see
like
what's
the
difference
right,
if
we
need
the
same
people
that
we
already
have
here
today,
we
could
just
use
this
time
right.
Whoever
is
not
interested
could
drop
off.
In
addition
to
that,
there
is
one
more
thing
that
I
think
we
should
be
doing.
We
discussed
that
briefly,
is
to
assign
a
facilitator
to
the
spec
issues
like
we
do
for
prs.
A
We
don't
do
that
for
the
issues
today
and
I
think
it's
important
to
do
as
part
of
the
triaging,
so
not
just
labeling
and
figuring
out.
What's
the
priority
or
the
area,
but
also
assigning
one
person,
either
a
dc
member
or
a
spec
approver
to
each
issue
to
facilitate
to
help
move
it
forward
or
or
maybe
close
it
if
it's
not
relevant
or
appropriate,
and
I
think
we
should
do
that
as
part
of
that
triaging
session.
A
Is
this
the
right
meeting,
I
think
so,
but
riley
I
I
get
your
point
right.
There
is
people
who
do
not
necessarily
want
to
be
here
are
not
interested,
I
think
that's
fine.
They
can
just
drop
off
we're
done
with
everything,
with
everything
that
we
need
to
discuss
for
certification,
the
remaining
whatever
10
15
20
minutes
remaining.
We
could
just
use
for
for
triaging.
I
think
that's
reasonable
yeah.
C
And-
and
I
I
agree
with
what
you
mentioned
like
we
should
start
by
ascending
the
issues,
so
one
thing
I
remember
andrew
did
like
last
year
was
very
efficient.
Is
that
we
we
just
look
at
all
the
old
issues,
split
them
by
the
number
for
them,
who
are
saying
anything
that
started
with
like
100.
C
C
C
And
just
spread
that
across
the
tc
members
and
let
them
do
the
the
initial
round
and
and
people
who
create
the
issue
will
respond
if
they
care
about
the
issue
right.
If,
for
example,
if
I
don't
have
enough
knowledge,
but
I
based
on
my
judgment,
I
think
this
issue
is
already
solved,
that
close,
that
if
another
person
wouldn't
agree,
we
can
still
reopen
the
issue
that
could
help
us
to
reduce
90
percent
of
the
issue
and
therefore
that
really
works
the
discussion
here.
C
A
Okay,
okay,
I
think
yeah,
I
agree
with
you.
There
is
no
need
for
a
lot
of
people
to
be
present
in
the
discussions.
The
only
I
guess
part
that
I
don't
quite
see
is
the
assignment
part.
If
the
issues
all
of
the
issues
need
to
be
assigned
to
someone
who
facilitates
them,
let's
say
I
am
doing
the
triaging
and
I'm
doing
it
solitary
right,
I'm
looking
at
the
list
of
issues
and
I
need
to
assign
it
to
someone.
How
do
I
do
that?
A
C
C
A
C
A
C
A
Right,
yeah,
not
just
races,
that's
right!
Okay,
so
I
guess
carlos.
We
can
maybe
go
back
to
the
original
round-robin
assignment
idea.
Maybe
should
we
do
that.
F
A
So
what
we're
seeing
here
for
the
others
we
want
to
for
every
new
issue,
we
want
it
to
be
assigned
randomly
around
robin
to
tc
members
and
to
spec
approvers,
that's
having
10
people,
and
then
they
take
care
of
figuring
out.
What
to
do
with
that
issue.
Are
they
facilitating
it?
Do
they
need
another
assignage
who
is
more
experienced
in
that?
Is
it
the
right
area?
Is
it
labeled
correctly?
So
one
person
takes
care
is
responsible
for
every
new
incoming
issue
and
then
they
they
take
it
from
whatever
is
necessary
to
do
with
that.