►
From YouTube: 2021-05-25 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
C
Looks
like
our
usual
starting
time,
I'm
not
sure
if
we
have
more
coming,
but
I
guess
people
can
trickle
in
as
they
arrive.
C
I
can
jump
into
the
spec,
sig,
hopefully
go
through
it
pretty
quickly,
and
then
we
can.
We
can
talk
about
what's
going
on
in
open,
telemetry
ruby
see
if
there's
been
any
feedback
on
our
rc
yet
and
all
that.
C
So
I
think
we
talked
about
this
a
little
bit
last
week
and
there
was
some
discussion
of
releasing
the
api
ahead
of
the
sdk
and
we
weren't
really
sure
what
that
meant.
C
I
think
this
document
describes
it
a
little
bit
better,
but
it's
it's
talking
about
releasing
an
experimental
version
of
the
metrics
api
spec
at
the
end
of
this
month,
and
then
clients
can
work
on
on
the
a
api
implementation
and
then
it
would
kind
of
be
the
end
of
june,
where
there
would
be
an
experimental,
sdk
spec
to
back
the
api
and
then
kind
of
at
the
end
of
july.
C
C
C
A
That
makes
a
lot
more
sense
when
it's
laid
out
in
a
timeline
like
that,
the
the
the
month
delay
between
the
api
and
the
sdk.
It
makes
a
lot
more
sense.
That
way,
I
think,
when
I
was
confused
about
it,
it
was
I
was
assuming
that
there
would
be
a
longer
gap
and
then
bad
things
could
happen,
but
I
think
a
month
is
actually
enough
time
to
see
if
there's
any
major
major
concerns
that
might
need
to
change
before
they
start
freezing
and.
E
That
looks
good
so
for
the
group
here.
My
questions
are
a
lot
of
this
bleeds
into
the
summertime.
E
How
have
you
traditionally,
like
or
historically
I
should
say
traditionally
historically
like
organize
yourselves
around,
like
does
somebody
volunteer,
try
this
to
spike
out
the
api?
I
know
francis
had
done
this
at
one
point
right
and
so
would
somebody
is
it
somebody
gonna
volunteer
to
try
to
come
up
with
a
draft
or
fill
it
out
or.
B
I
actually
would
I
don't
know
what
the
standard
approaches
I
I
had
been
interested
in
being
more
active
in
the
metrics
api
work,
but
probably
not
able
to
do
the
whole
thing,
because
I
suck
no,
because
I
I
yeah
because
of
bandwidth
constraints,
but
I
want
to
be
a
more
active
contributor
to
the
metrics
but
yeah,
I'm
not
sure
how
how
we
want
to
organize
that
work,
and
I
think
you
bring
up
the
points
because
I
have
a
honeymoon
I
have
to
go
on.
B
I
want
to
go
on
with
my
partner
this
summer.
Congratulations
thanks!
I
got
married
a
while
ago
anyway,
but
thank
you.
I
appreciate
it,
but
yeah
I'm.
What
do
other
people
think.
F
F
Yeah,
so
the
the
api
has
a
few
different
pieces
and
I
think
we
can
reasonably
break
it
up
into
like
break
up
the
work
into
those
pieces
and
tackle
them
somewhat
independently.
F
So
there's
different
instruments,
I
think
they
called
they
may
have
changed
name
since
I
did
this
previously,
but
there's
different
instruments,
for
you
know
like
a
counter
or
a
gauge
things
like
that
they
have
different
terminology,
but
I
think
you
probably
get
the
idea
and
then
there's
some
kind
of
common
infrastructure
behind
those
instruments.
F
So
I
think
at
the
very
least,
we
can
think
about
breaking
up
the
work
into
those
separate
instruments
and
independently
the
infrastructure
behind
it
and
then
figure
out
how
to
glue
them
together.
So
we
don't
need
to
do
this.
Necessarily
as
like
a
big
bang,
you
know
single
person,
effort
to
sketch
out
the
api.
F
A
It
I
think
that
sounds
like
a
good
idea
for
instrumentation
or
per
instrument.
Rather
they
should
be
sort
of
self-contained-
I
think
not
completely,
but
to
enough
point
that
you
could
parcel
it
out
the
way.
I
think
that
sounds
reasonable.
B
Yeah,
if
somebody
wants
to
I'm
not
familiar
enough
with
the
overall
design,
but
I
think
I
have
some
benefits
of
one.
My
colleague
implemented
the
metrics
api
at
the
you
know
support
at
the
and
what's
it
called
at
the
collector
level,
so
I
can
lean
on
them
a
bit.
But
if
you
have
somebody
wants
to
play,
I
don't
know
the
phrase
is
play
like
pm
or
team
lead
in
this
situation
and
assign
tasks.
B
I
would
be
I'm
happy
to
be
a
grunt,
but
I'm
not
sure
I'm
comfortable
enough
with
the
overall
specification
and
design
to
confidently
suggest.
You
know
that
a
higher
level
of
work,
if
that
makes
sense,.
F
C
That
all
sounds
good.
I
know
they.
I
think
we
talked
about
this
a
couple
weeks
ago,
but
they
were
looking
for
a
dynamic
language
or
two
to
kind
of
participate
in
in
the
api
design,
and
I
think
I
think
that
makes
sense.
I
haven't
looked
at
the
api
in
a
little
bit,
but
I
remember
you
know
there
was.
C
C
Maybe
it
didn't
exactly
work
like
that.
Maybe
it
was
in
gauge
and
float
gauge
or
something
something
along
those
lines
and.
C
Whether
or
not
that
makes
sense
for
us,
I
think,
should
be
discussed
and
I
guess
yeah.
The
only
other
thing
I
was
going
to
add
to
the
conversation
is
it
does.
I
think
I
think
the
api
is
a
lot
easier
to
maybe
break
up
and
have
a
few
folks
work
on.
C
I
think
when
it
comes
time
to
the
sdk,
I
think
there
is
like
a
certain
amount
of
machinery
that
needs
to
kind
of
be
built
for
your
instruments
to
pipe
data
through
and
that
could
get
a
little
trickier,
but
I
think
yeah.
I
think
we
can
figure
that
out,
and
I
think
this
is
a
good
discussion
to
kind
of
figure
out
how
we
want
to
try
to
parallelize
the
work
as
much
as
possible.
F
Yeah
for
the
sdk
there's
again
relying
on
my
faulty
memory,
but
there
is
work
that
can
be
split
up
pretty
easily
there
as
well
the
sort
of
asynchronous
instruments
and
the
machinery
around
that
there's
synchronous
instruments
and
machinery
around
that
and
then
there's
the
exporter
interfaces
for
kind
of
pull-based
export,
push-based
export,
so
yeah.
I
I
think,
there's
there's
also
the
default
exporters
that
I
think
everybody
needs
to
support.
So
prometheus
is
probably
one
of
them.
F
The
open,
telemetry
exporter
is
another
and
there
may
be
stats
d
required
there
as
well.
I'm
not
sure.
E
I
saw
you
grimace
eric
when
he
says
that's
d.
B
No,
I
like
s,
that's
he's,
you
know
it's
like
the
language
you,
whatever
you
learn
in
becomes
a
originally
everything
becomes
a
you
know
relative
to
that.
So
for
me,
that's
good.
I
I
am
grimacing
because
I
don't
know
if
there's
some
weird
political
thing
behind
the
scenes
where,
like
people
are
more
important
than
me
and
my
company
are
like
you
know,
trying
to
tell
aws
to
leverage
to
push
that
state.
I
don't
know
I
don't
pay
attention
to
that
stuff.
B
So
I
can't
so
even
if
one
of
six
people
are
later
watching
this
recording,
I
don't
actually
know
but
yeah,
I
can
help
with
the
stat
c
stuff.
Certainly
if
that
does
become
a
requirement,
I
don't
think
it
should
is
my
personal
opinion,
but.
F
Yeah,
I
seem
to
recall:
josh
mcdonnell
took
a
crack
at
statsdee
export
in
his
go
prototype
a
while
back
and
then
couldn't
get
it
working
reliably
and
ended
up
just.
B
Tossing
the
code,
it's
there's
something
there's
there
is
a
contrib
datadog
exporter
for
metrics
floating
around
and
go
that
I
randomly
get
asked
to
handle
escalation,
tickets,
support
tickets
for
and
don't
have
a
good
answer
for
it.
But
there
is
a
receiver
so,
but
I
believe
the
receiver
lives
in
contribute.
C
Well,
maybe
in
the
interest
of
getting
to
the
specs
egg
in
a
shorter
time
than
the
spec
sig
took,
we
could
potentially
move
on.
Is
there
anything
else
we
should
discuss
before
wrapping
this
topic?.
E
Nope,
I'm
again
put
it
out
there,
those
timelines-
I
don't
know
how
people
feel
about
them,
but
we
might
not
be
able
to
keep
up
it's
okay,.
F
Yeah
I
mean
practically
speaking:
open
telemetry
has
been
setting
aggressive
timelines
since
the
beginning
and
has
been
regularly
missing
those
by
you
know
at
least
a
year,
possibly
more
so
I
I
think
the
aggressive
timeline
is
just
there
to
try
to
motivate
people.
I
wouldn't
regard
that
as
kind
of
strict
goal
posts.
You
know,
we've
failed
terribly
if
we
haven't
hit
them.
C
Yeah-
and
I
think
those
timelines
were
more
coming
from
the
from
the
metrics
working
group-
that's
kind
of
their
timeline.
I
think
the
sig
is
the
language
shakes
usually
lag
the
spec
a
tad.
E
Yeah
yeah,
but
I
think,
like
it's
the
feed
to
back
loop,
that
we
want
to
participate
early
in
experimenting
so
that
we
can
give
them
feedback
that
the
api
specification
is
not
amenable
to
being
implemented
in
ruby.
Like
that's
the
that's
where
we
want
to
be,
I
think
so
we
can
influence
that
a
bit.
It
looked
to
me
like
they're
talking
about
the
end
of
them
they're
talking
about
memorial
day.
E
A
E
I
know
I
I
I
I'm
just
like
I'm
exporting
my
what
happens
at
work
to
the
open
source
community
right
now.
I
do.
F
Yeah,
the
the
more
concerning
one,
is
feature
freeze
at
the
end
of
july
that
one's
a
bit
more
challenging.
In
my
opinion,.
C
I
think
all
engineers
should,
I
don't
know,
have
concerns
about
timelines
whenever
time
enters
the
equation,
like
somebody
should
speak
up
but
like
if
it's,
if
any
consolation,
all
these
things
that
say
experimental
means
like
join,
join
the
feedback
loop
join
the
experiment.
I
think
this
is
when
the
experiment
really
starts
to
begin.
I
think
you
know
somebody
has,
you
know
kind
of
been
on
the
forefront
of
like
getting
something
out
that
they
think
is
like
a
good
thing
to
start
getting
feedback
on.
C
But
probably
you
know
you
didn't
really
need
to
join.
Join
the
experiment
before
memorial
day.
C
But
yeah,
as
as
you
approach
these
feature,
freeze
things
that's
when
it
gets
a
little
bit
more
serious
and
you
definitely
want
to
have
your
feedback
in
ahead
of.
C
C
Apparently,
there's
a
lot
of
stale
oteps.
They
should
probably
be
closed.
C
We
normally
go
into
the
details
there.
There
is
a
discussion
about
whether
or
not
a
sampler
can
be
shared
among
multiple
tracer
providers.
C
I
haven't
read
through
this
issue,
so
I
don't
understand
all
of
the
concerns
but
yeah
it
does
seem.
I
don't
know
like
for
a
long
time.
I
complained
about
this
multiple
tracer
provider,
just
situation
to
begin
with,
because
it
seems
like
it's
kind
of
like
an
edge
case
and
you
can
only
have
like
one
global
tracer
provider
registered
for
an
sdk
and
any
other
tracer
provider
is.
C
Something
that
you're
kind
of
managing
on
your
own
and
then
it
just
leads,
like
this
whole,
like
series
of
weird
edge
cases
that
not
everybody
is
thinking
about
because
of
the
fact
that
it's
most
applications
will
just
use
the
global
and
that's
it,
but
it
seemed
yeah.
The
discussion
was
somewhat
around.
C
Wanting
to
have
a
resource
available
in
the
in
the
sampler,
I
think
so
I
think
really
what
it
boils
down
to
is
like.
Does
the
sampler
api
need
to
be
changed
to
pass
in
a
resource?
I
think,
or
could
you
possibly
just
like
look
this
up
off
of
a
tracer
provider?
B
C
Yeah,
I
think
on
this
note
there
is,
I
guess,
another
issue
around
sampling
somewhere
here,
and
I
think
there
was
here
we
go,
there's
an
otep
for
probabilistic
sampling.
That
needs
some
reviews
since
we're
kind
of
talking
about
the
sample.
I
thought
I
would
bring
that
up,
because
the
other
thing
that
was
being
discussed
at
the
meeting
was
whether
or
not
we
should
spin
back
up
the
sampling
working
group.
There
was
kind
of
a
separate
working
group
working
on
sampling
and
I
don't
think
they
ever
fully.
C
C
B
Yeah
sampling
bit
yeah,
I
I
do
think
the
sampling
spec
or
what
we
have
right
now
in
1.0
for
sampling,
is
like
incomplete
to
the
point
of
being
useless,
because
we
don't
propagate
the
the
rate
so
yeah
I
don't.
If
there's
anything,
it
would
be
really
nice
to
propagate
the
rate
other.
It
seems,
like
some
other
folks,
have
just
bolted
on
their
own
sampling
approach
or
formats
or
whatever,
but
it
seems
like
this
is
a
big
gap.
B
If
I'm,
unless
I'm
missing
something
in
my
mental
model,
it's
unclear
to
me
how
sampling
works
at
all
without
the
ability
to
upscale
metrics,
based
on
rate,
if
people
are
familiar
with
a
workaround
or
something
I
would
be
keen
to
hear
it
but
yeah.
This
is
something
I'd
like
to
see
moved
forward
and
I'd
be
happy
to
implement
on
the
ruby
level
if
it
means,
if
there's
work
that
comes
out
of
this.
C
Yeah,
that's
all
good
news
and
like
yeah,
I
do
think
that
there
has
been
a
lot
of
discussions
about
needing
to
propagate
the
rate,
a
between
services
and
yeah,
between
services
for
trace,
but
also
within
a
process
for
the
trace
and
make
sure
that
that
rate
makes
it
on
the
telemetry
coming
out.
C
Is
is
where
to
actually
stick
this
rate
when
you
want
to
send
between
services
how
to
propagate
that?
In
your
contacts,
especially,
I
think
nobody
has
made
this
easy.
I
think
that's
like
the
core
problem
and
even
the
the
w3c
trace
context,
which
should
be
the
most
modern
and
kind
of
standard
way
to
propagate
data
between
services.
C
C
I
think
there
are
some
challenges
there
and
in
that,
like
historically,
that
was
thought
of
as
kind
of
like
a
spot
for
like
a
vendor,
to
stick
their
kind
of
like
information
that
relates
to
them.
But
I
think
we
are
when
you
get
open
telemetry
in
the
mix.
It's
like
it's
open,
telemetry,
a
vendor
and
like
what,
if
you
are
a
vendor
who
is
using
open,
telemetry
like
where
does
that
stuff?
All
kind
of
like
line
up
so.
B
Yeah
yeah,
I,
the
trace
state,
feels
like
both
the
wild
west,
but
also
a
solution
to
all
of
life's
problems
and
closet,
but
yeah.
It
would
be
nice
to
have
a
some
convention.
F
Yeah
you
either
need
to
use
state
or
baggage
for
the
propagation
and
then
samplers
themselves
have
the
ability
to
add
attributes
to
spans.
So
really
at
that
point
you
just
need
some
kind
of
semantic
conventions
for
recording
that
information
in
like
from
the
sampler
onto
the
span.
B
You
know
it's
math
now
it's
it
can
be
wrong
or
something
there's
wiggle
room.
C
But
yeah
it's
good
to
see
that
there's
interest
in
this
and
like
I
do
agree
that
this
is
something
that
needs
needs
some
work.
So
I
think
that
was
that
was
really.
The
ask
here
was
to
chime
in
review
comment.
C
Backtracking
just
a
little
bit
set
status.
We
talked
about
this
the
last
couple
meetings
and
it
seems
like
it's
embroiled
in
controversy,
not
surprisingly,.
C
C
C
So
ultimately,
I
think
the
core
issue
here
is
the
status
api.
C
Really
like,
I
think
there
are
three
statuses,
unset
error
or
okay,
and
the
only
person
that
should
be
able
to
set
okay
is
the
end.
User
and
okay
should
not
be
able
to
be
overridden
by
some
other
source,
and
I
think
that's
how
things
are
stacked.
I
think,
like
the
the
real
issue
here
is
that,
like
that
didn't
work
out
so
well
in
the
real
world,
at
least
for
the
java
auto
instrumentation
group.
C
I
think
it
was
very
hard
to
figure
out
who
was
trying
to
change
the
status
and
it
was
kind
of
violating
this
rule
a
little
bit
and
in
discussing
this
api,
I
think
a
lot
of
people
suddenly
became
aware
of
what
was
specked
and
how
it
was
working.
C
So
I
think
that's
one
of
one
of
the
problems
is
that
the
way
this
api
works
is
not
maybe
the
most
straightforward
or
ergonomic,
and
this
is
kind
of
a
way
to
at
least
make
it
technically
correct
with
the
spec,
so
that
instrumentation
doesn't
accidentally
override
the.
C
Spam
status-
and
I
think
really
the
proposed
solution
is
like
once
spam
status
has
been
set
as
okay,
it's
kind
of
always
going
to
be.
Okay,
anything
else
should
not
take
effect,
because
really
it's
only
the
user
who
should
be
calling
this
the
first
place.
C
B
Yeah,
I
mean
at
least
we
move
past
fighting
over
whether
the
word
ever
has
the
same
semantic,
meaning
as
the
word
exception
or
whatever,
but
yeah.
I
don't
know
we
could
take
a
whole
meeting
and
not
move
forward
on
any
of
this
stuff.
I
think
we
just
deal
with
whatever
respect
ends
up
deciding
ruby's
kind
of
more
flexible
in
our
languages.
C
C
There
was
this
instrumentation
ecosystem.
Otep
I
saw
andrew
was
commenting
on
it
and
oh
hey,
it's
merged.
C
Yeah,
this
is
really
about
how
to
manage
and
document
the
hopefully
growing
ecosystem
of
of
instrumentation
kind
of
do
some
guidelines
here
I
don't
know
anything
super
controversial,
but.
D
C
C
If
you
know
anybody
else,
creating
plugins
or
gems
that
are
open,
telemetry
related
that
we
don't
know
about,
encourage
them
to
put
them
in
their
in
the
registry,
because
that's
kind
of
where
people
should
discover
stuff
and
apparently
there's
a
self-assessment
form
when
you're
adding
something
to
the
registry,
and
I
think
you're
supposed
to
kind
of
chuck
some
boxes
or
fill
some
stuff
out
about
about
the
thing
that
you're
submitting
and
I
think
if
the
thing
filled
out
in
the
self-assessment
turns
out
to
not
be
true.
A
No,
I
from
reading
the
other
tip
there
was
there
was
nothing
terribly
exciting
about
it.
I
I
started
to
have
feelings
about
well.
How
much
process
are
we
putting
on
people?
Is
that
going
to
raise
the
barrier
to
entry,
but
then?
Finally,
when
I
found
the
proposed
checklist,
it
was
basically
like
it
was
very
minimal,
so
I
I
don't
think
it's
very
much.
A
I
think
the
one
thing
that
was
a
little
interesting
to
me
was:
it
almost
feels
like
it's
raising
the
bar
for
contrib
contributions
to
maybe
a
level
that's
too
high,
but
I'm
I'm
not
actually
convinced
of
that.
I
can't
quite
shake
the
feeling,
but
I
also
can't
really
come
up
with
a
good,
concrete
reason
why
it
feels
that
way.
So
I
think
it's
fine
if
it
gets
more
things
on
the
registry
and
the
registry
becomes
really
useful.
I
think
that's
probably
a
good
outcome
of
it.
E
So
tangentially
related
might
be
like
implementer's
guide
for
folks
that,
because
you
know
we
were
having
this
conversation,
I
was
just
typing
up.
The
discussion
earlier
was
about
how
to
deal
with
experimental,
cementing
conventions
how
to
implement
like,
for
example,
using
the
instrument
instrumentation
based
class.
E
What
kind
of
errors
do
you
want
to
output,
just
providing
people
with
meaningful
guidance,
one
putting
together
a
contribution
or
something
that
they
would
like
to
add
to
the
registry?
I
guess.
E
I
wanted
to
see
if
we
can
try
to.
You
know,
put
something
like
that
together
and
I
wasn't
sure
like
where
that
really
belonged,
so
whether
it
belongs
on
in
the
open
telemetry
I
o
site
on
the
documentation
there,
because
right
now
it's
pointing
back
to
our
repository
that
and
do
we
want
to
keep
you
know.
Another
thing
is
like
running
examples
like
do
we
want
to
keep
maintaining
the
examples
as
code
inside
of
the
repository
itself,
or
do
we
want
to
have
like
a
sample
application
similar
to
like
the
hipster
shop?
E
Where
look
at
you
smiling
there
the
so
we
can
provide
some
meaningful
working
examples
for
folks
and
they
can
see
because,
like
you
know,
we
got
the
question
again,
which
is
like
how
do
I
set
this
up
to
export
to
the
collector
and
it's
like?
Well,
we
don't
do
we
just
tell
people,
read
the
specifications
like
and
fill
out
these
environment
variables
to
get
that
working
or
whatever,
or
do
we
want
some
more
of
like
a
tutorial-ish
guidance.
F
Yeah,
I
feel
like
all
of
the
above,
like
we
want
some
simple.
I
don't
know
what
you'd
call
it,
but
just
like
walkthroughs
of
here
are
common
scenarios.
Here
are
the
env
environment
variables
you
would
want
to
set
for
these
common
scenarios.
We
want
larger
examples
like
the
hipster
shop
demo.
F
The
hipster
shop
demo
is
interesting
because
I
think
it's
multi-language,
so
it
has
the
benefit
of
showing
how
everything
is
supposed
to
work
together,
but
it
is
a
larger
example,
and
so
it's
perhaps
a
little
bit
more
challenging
to
absorb,
and
then
we
also
need
simpler
examples,
not
necessarily
fully
fleshed
apps
but
simple
examples
of
common
things
that
people
would
run
into
you
know
so
the
basics
of
okay
right
out
of
the
box.
How
do
I
set
this
up
in
my
application?
What
are
the
first
steps
I
need
to
do
to
make?
F
It
run
possibly
something
a
little
bit
more
substantial
than
the
little
readme
examples
that
we
have.
F
A
really
good
way
of
doing.
That
would
actually
would
be
to
actually
have
a
repo
somewhere.
That
has
an
example
app
and
has
a
pr
that
shows
the
addition
of
open,
telemetry,
ruby
right.
So
it's!
How
do
you
turn
this
thing
on?
Here's,
the
pr
for
that?
How
do
you
add
instrumentation,
here's
the
pr
for
that,
so
that
you
can
point
people
to
these
concrete
code,
examples
that
show
you
know
the
diff
between
simple
application
and
then
simple
application
with
open,
telemetry
and
auto
instrumentation,
and
then
simple
application
with
custom,
instrumentation
added.
A
I
can't
remember
the
name
of
the
of
the
series
of
videos
that
does
there's
some
guy.
Who
does
this
that
makes
it
his
full-time
job,
but
he
posts
the
code
in
that
same
way,
and
I've
actually
used
those
pr's
myself
to
go
and
see
okay
exactly
how
did
he
do
that?
I
found
it
really
useful.
I
think
the
only
real
challenge
is
like
we
could
do
one
for
rails
right
and
that's
really
common
and
popular,
but
then,
after
that,
there's
just
a
million
other
types
of
things.
A
F
You
have
to
pick
something
that
is
hits
a
wide
enough
audience
and
I
think
rails
is
sufficient.
I
don't
think
you
need
to
hit
every
you
know.
Member
of
the
audience
you
just
need
to
hit
a
large
number
of
people,
because
then
that
becomes
just
the
the
default
is
like.
Oh
you're
running
rails.
Go
look
at
this
right,
here's
a
commit
yeah,
and
that
shows
you
everything
that
you
need
to
get
up
and
running.
F
Especially
if
you
have
concrete
suggestions
for
stuff
that
we
should
do
a
lot
of
the
documentation
things
just
kind
of
say.
You
know
we
should
have
documentation
for
x,
as
opposed
to
like
laying
out
here
something
concrete
that
somebody
could
go
away
and
build
as
a
document
or
as
an
example,
and
then
that
becomes
a
useful
task
that
we
can
actually
hand
off
to
somebody.
A
Useful
if
we
got
somebody
outside
of
this
working
group
to
go
through
our
repo
and
look
and
say
how
would
I
do
this
as
a
newcomer
and
then
write
down
all
of
their
frustrations
about
documentation,
because
I
think
I
am
too
close
to
it
now
to
really
know
like
what
are
we
missing?
I
can
come
up
with
some
things
for
sure,
but
I
might
not.
Actually,
I
might
not
have
the
right
context
anymore,
to
even
see
what
we're
missing
would
that
be
useful.
F
E
Thanks
for
letting
that
tangent
go
on
there,
but
I
think
it
I.
I
will
capture
all
this
in
the
discussion
and
then
maybe
we
can
turn
it
into
working
at
a
more
issue
and
then
we'll
follow
through
on
that.
F
B
F
Yeah
that
that'd
be
cool,
and
then
we
can
split
that.
F
C
Yeah,
I
was
just
gonna
say
thumbs
up
to
all
that
too,
I
feel
like
I
feel
like
we
spent
a
lot
of
time,
building
open
telemetry
and
getting
it
to
a
point
where
it's
worth
documenting,
where
it's
not
going
to
change
every
other
day,
and
I
think
we're
kind
of
to
that
point.
So,
like
it's,
it's
a
good
time
to
start
talking
about
this
stuff.
B
C
All
right,
let's,
let's
wrap
up
the
spec
sig,
because
I
think
we
might
have
taken
just
as
long
as
the
specific
to
go
through
it
and
not
really
leaving
much
time
for
us,
but
there's
a
metrics
data
model
spec
that
they
want
to
graduate
to
stable.
C
I
think
they
just
need
to
make
a
pr
that
changes
the
label
to
stable.
They
just
want
to
see
if
there
was
some
other
process
behind
that
we
won't
go
into
all
the
details
of
why
but-
and
then
I
think,
anthony
was
asking
about
a
1.4
release.
C
C
F
So
I
want
to
figure
out
what
are
the
practical
steps
we
have
to
go
through
to
split
out
the
open,
telemetry,
ruby,
contrib
repo?
Are
we
going
to
have
the
same
maintainers
and
approvers
for
that,
or
are
we
going
to
have
a
different
list
of
maintainers
and
approvers,
which
packages
are
we
going
to
split
out?
How
do
we
preserve
the
commit
history,
all
those
sort
of
things?
F
E
I'm
gonna
put
in
votes.
Basically,
we
should
probably
keep
the
same
maintainers
and
approvers
for
simplicity,
and
if
things
get
more
complex
or
people
drop
off
or
add
you
know,
we
can
create
new
groups
second,
which
packages,
I
think
anything,
that's
not,
I'm
sure
anything,
that's
not
included
in
the
specification
by
default
would
go
in
these
this
contrib
repo,
preserving
history.
I
think
that
we
can
do
that.
There's
a
guide
even
on
github,
that
that
allows
us
to
extract
repositories,
some
repositories
from
monolithic
repositories.
E
E
F
E
Yeah
sure-
and
I
know
a
ton
of
people
who
know
git,
so
they
can't
help
me
if
I
screw
it
up.
E
F
I'll
open
an
issue
for
that
or
let's
start
with
the
discussion,
so
we
can
try
to
figure
out
what
we're
missing
and
then
we
take
it
from
there.
E
The
only
thing
that
might
I'm
curious
about
is
if
we
want
to
split
out
issues
and
discussions
into
that
repository
as
well
or
if
we
should
keep
one
repository.
That
is
the
main
repository
to
keep
those
for
the
the
sake
of
project
management.
Be
another
group,
is
this
small
and
we're
not?
E
F
Yeah,
cool,
okay
that
sounds
reasonable,
but
yeah
I'll
I'll,
open
a
discussion
item
about
this,
and
we
can
figure
it
out
there.
We
need
to
ensure
that
we
have
open
issues
for
anything,
that's
blocking
1.0.
F
A
I
didn't
know
that
was
I
thought
that
was
like
a
proposal
I
didn't
know
they
had
settled
on
like
yes,
it
has
to
be
auto-generated.
I.
A
So
I
like
it,
I
mean
there's
dragons
with
parsing
yaml
and
things
like
that,
but
at
least
it
does
sound
otherwise
fairly
straightforward.
F
Yeah,
we
have
a
years
old
issue
about
trying
to
migrate
yaml
that
was
stored
in
my
sequel,
from
psych
to
sick,
or
vice
versa.
I
can't
remember
anyway,
yeah
yeah
well
passing
fun
cool,
okay,
any
other
issues
as
well,
that
you
can
think
of
that
would
block
1.0.
We
should
open
those
and
tag
them
against
the
project
for
1.0,
so
we
know
what's
blocking.
F
There
was
a
pr
that
was
proposing
splitting
out
some
common
helpers
for
http
clients
and
that
pr
was
trying
to
shove
them
into
the
common
package.
I
don't
know
if
that's
the
best
place
for
them.
I
don't
know
whether
we
should
have
them
there
or
whether
we
should
have
them
in
their
semantic
conventions
gym.
So
it's
like
half
generated
and
half
helpers,
or
do
we
stick
them
somewhere
else
but
like
there
are
several
examples
of
things
where
we'd
like
to
have
helpers
from
semantic
conventions.
F
E
I
hate
to
over
engineer
this,
but
the
can
the
semantic
should
the
semantic
convention
gem
only
be
generated
code
and
then
there'll
be
an
additional
gem
that
has
customizations
that
way.
If
you
have
to
like
just
delete
everything
and
regenerate
it,
it's
not
a
big
deal.
E
A
Either
both
I
don't
know
you
could
always
put
this
type
of
helper
stuff
into
instrumentation
base.
I
mean
we're
looking
for
a
junk
drawer
to
shove.
It
in
and.
A
Yeah,
no,
I
mean,
I
think,
there's
two
separate
things
I
like
that.
We
need
the
auto-generated
semantic
conventions,
gem
for
for
spec
compliance,
but
there's
also
like
the
http
helpers
and
which
enforces
compliance
with
the
semantic
conventions
partially,
but
it's
also
partially
to
avoid
additional
reinventing
the
wheel
every
time
so
that
the
the
the
part
that
takes
a
url
like
object
in
this
pr
and
returns
the
right
versions-
and
you
know
sanitizes
things
appropriately
and
creates
semantic
convention
attributes
from
that,
I
think,
could
be
in
a
different
place.
Yeah,
I'm
not.
F
Yeah,
I'm
not
sure
instrumentation
base
is
the
right
place
for
that.
I
kind
of
want
to
keep
that
fairly
clean.
I
think
if
we
want
a
junk
drawer
for
it,
we
probably
want
a
separate
set
of
instrumentation
helpers.
A
I
jim
that
would
be
fine
as
long
as
we
know
what
the
instrumentation
helpers
gem
for
is
here.
Sorry
as
long
as
we
know
what
the
instrumentation
helpers
are
for
and
is,
and
we
know
what
is
different
and
goes
into
the
open,
telemetry
ruby
common
helpers.
You
know
as
long
as
there's
a
we
have
a
good
idea
about
that.
That's
fine.
F
Yeah
commons
being
a
bit
of
a
dumping
ground,
but
it's
also
a
dependency
I
think
of
the
sdk,
and
I
I
don't
want
to
pollute
it
with
a
whole
bunch
of
instrumentation
things
right.
F
Yeah
yeah,
so
that
makes
sense.
Yeah
instrumentation
helpers
is
fine
as
long
as
we
don't
end
up
finding
a
helper's
gem
that
we
want
to
instrument
with
auto
instrumentation.
At
that
point,.
F
Cool
okay,
I'll
I'll,
open
an
issue
for
that
as
well.
I
reached
out
this
morning
to
a
member
of
the
governance
committee
asking
about
the
tc
review
sort
of
pre
1.0.
I
I
haven't
heard
back
from
her
yet
but
we'll
see
what
happens
there.
I
was
asking
for
you
know
some
sacrificial
lamb
to
be
offered
up
to
do
like
a
review
of
ruby
code
because
I'm
pretty
sure
none
of
the
folks.
There
are
rubyists.
F
D
Another
quick
thing
I
just
wanted
to
mention,
because
we
have
a
bunch
of
newly
added
approvers,
which
is
awesome.
I
don't
know
if
it'll
make
more
sense
when
we
moved
to
like
the
information
instrumentation
from
trip,
but
I
think
it
would
be
good
to
encourage
improvers
to
like
open
releases
for
individual
gems.
That's
something
I
didn't
do
enough
is
so
like,
for
example,
the
the
rack
middleware
is
the
one.
I
want
to
use
an
example,
or
it
knows
the
the
rails
injection
of
the
rack
middleware.
D
It
was
fixed
to
be
actually
the
first
thing
in
the
stack
like.
I
don't
want
people
to
feel
like
they
have
to
wait
for
the
maintainer
to
get
it
released.
I
know
the
maintainers
do
have
to
actually
do
the
final
step,
but
if,
like
an
approver,
goes
to
the
actions
tab,
they
can
just
draft
or
release
pr
and
then
anyone
who's,
a
maintainer
can
just
like
make
sure
it
looks
good,
merge
it.
And
that
way,
like
I
don't
know,
I
just
like
the
idea
of
pushing
a
little
bit
more
autonomy
ownership.
D
E
D
Right
so
that's
still
complicated
by
maintainers,
but
once
it
gets
merged
like
say
now,
we
want
that
that
change
to
go,
live
and
be
available
for
everyone.
You
still
have
the
ability
to
go
into
actions
and
then
there's
like
releases.
D
I
don't
know
if
matt
wants
to
show
it,
maybe
and
then
it's
workflows
or
is
it
open
release
request
and
then
it's
run
workflow
and
so,
if
matt,
if
you
click
that
just
they
can
see
it's
the
gem
name
colon
the
version
you
want
to
give
it
and
then,
when
you
run
that
workflow
it'll
create
the
pr
and
then
and
then
a
maintainer
still
has
to
go
through
and
do
it.
But
it's
like
it's
just
that
added
like
guilted
pressure,
like
hey.
D
I'm
trying
to
you
know
be
helpful,
don't
block
me,
so
I
like
the
idea
of
more
people
feeling
like
they
can
do
that,
so
anybody
who
hasn't
been
doing
that
before,
like
yeah,
do
it
yeah.
I
think.
A
D
Yeah,
I
think
it's
definitely
it's
just
like
sometimes
people
forget,
and
so,
if
you're
waiting
on
something
like
the
more
you
could
do
to
push
it
forward.
I
think
is
better
because,
like
once
that
that
that
release
pr
is
up
like
there's
really
nothing
to
do
as
long
as
it's
green,
then
to
make
sure
the
notes
are
correct
and
merge
it
right.
So.
E
Sure,
I
guess
we're
talking
about
now
at
the
point
that
we're
like
incremental
releases
for
things,
because
we're
all
right
with
said
but
said
bug
fix
was
was
nice.
D
C
D
That's
fine,
but
I
also
don't
see
the
harm
like
right
now
we're
on
0.18.0
for
the
rack,
one
like
we
could
do
0.18.1
right
and
then
we
could
just
release
that
right
now
and
the
person
who
committed
it
can
now
just
use
it
right.
They
fix
that
problem.
They
get
to
consume
the
solution
right.
So
I
like
the
fast
turnaround
on
that.
I
don't
I
personally
don't
really
like
like
scheduled
releases.
I
think
it's
like.
If
it's
in
it's
good
release,
it.
F
So
there's
two
situations
where
I
think
you
might
want
to
do
some
batching
one
is
when
you
actually
have
a
few
pr's
in
flight
that
are
touching
the
same
gems.
The
other
one
is
a
little
bit
trickier.
We
have
this
instrumentation,
all
gem,
which
is
basically
just
dependent
on
all
the
instruments,
all
the
auto
instrumentation
things,
and
in
some
cases,
when
you
bump
the
you
know,
like
the
rack
gem
you're,
also
going
to
need
to
bump
the
dependency
in
the
instrumentation
all.
D
B
Yeah
the
collector
releases
once
every
two
weeks
and
definitely
noticed
a
few
times
when
you
know
I
get
something
in
with
13
days
to
go
and
there's
some
frustrated
end
users
so
yeah,
but
I
can.
I
can
see
both
sides.
I
guess
but
yeah,
I'm
happy
to
I'd
like
to
get
better
at
the
the
release
stuff
for
gem.
So
I'd
might
maybe
bug
one
of
y'all
to
shadow
my
first
time
or
two
but
would
be
yeah.
I
think
it's.
What
you're
saying
makes.
F
B
Nothing
burning
I
had
looked
last
night
while
I
was
during
some
insomnia
at
that
http
helpers
pr
yeah,
I'm
curious
what
people
think
generally
about
like
books
and
configuration
options
like
common
config
options
and
whether
one
there's
any
specifications
saying
like
here's
the
right
way
to
expose
common
config
among
instrumentation
to
how
much
we
wanna.
So
it
sounds
like
there's.
None.
F
There's
there's
none,
but
I
do
I
like.
I
wondered
about
that
when
I
was
reading
the
the
pr
as
well.
It's
like
okay,
we've
factored
out
the
helper,
but
now
we've
duplicated
the
the
config
option
everywhere,
and
I
wonder
if
we
want
to
gather
together
config
options
that
make
sense
for
http
instrumentation,
for
example,
and
have
a
way
of
including
those
cleanly
yeah.
B
Yeah
there's
some
bulk,
including
also
like
at
what
level
of
abstraction
do
you
want
to
give
people
flexibility
on
this
stuff
I
tend
to,
and
you
know
part
of
that
is
because
there's
since
there's
no
clear,
happy
path
like
in
my
mind,
you
do
all
this
stuff
at
the
collector,
so
any
obvious
case,
but
that
doesn't
work
for
everyone
because
of
environment
or
because
of
their
setup.
So
it's
like.
Do
we
introduce
performance
implications
if
we
allow
people
to
do
certain
operations
anyway,
but
not
asynchronous
feedback
is,
is
appreciated.
F
My
lunch
specifically
so
I'm
gonna
stop
talking
cool
two
issues
that
were
opened
by
people
from
outside
the
org.
One
is
the
code
coverage
thing
so
adding
a
badge
for
code
coverage.
F
We
still
have
some
scars
from
what
was
a
code
cover
I
o
so
we're
well
at
least
I'm
a
little
reluctant
to
use
them
as
a
badge
for
this,
but
if
people
have
opinions
suddenly
chime
in
there
and
then
the
other
one
was
the
security
scanning
tool.
I
know
andrew
and
ariel
have
been
chatting
in
that
issue.
If
anybody
else
has
opinions,
please
share
them
there.
My
sense
with
both
of
these
is
that
these
are
not
hard
requirements,
or
at
least
they're,
not
part
of
the
spec.
F
These
are
more.
You
know,
people
proactively,
reaching
out
people
proposing
things
to
the
spec
and
then
proactively,
reaching
out
to
people
or
to
the
various
cigs
to
say:
hey.
Can
we
get
this
done,
which
is
cool,
but
it
makes
it
a
little
bit
harder
to
understand
whether
something
is
a
a
hard
requirement
that
we're
not
meeting
or
is
just
a
a
nice
to
have,
or
you
know,
here's
a
good
practice.
B
Yeah,
I
feel
like
there's
a
lot
of
stuff
that
falls
into
this
bucket
of,
like
aws,
wants
to
productize
this,
and
so
how
do
they
get
a
little
bit
of
that
yeah?
And
so,
but
that's
fine
generally.
Their
opinions
are
right
with
this
stuff,
but
yeah.
If
it
were
up
to
oh
I'll
comment,
I
think
we
should
wait
until
we
can
get
the
coq
yeah.
C
E
Yeah,
I
know
we
don't
we
don't
have
a
lot
of
external
dependencies,
but
do
we
have
the
pennavot
configured
for
dependency
scanning.
D
F
Yeah
sorry,
I
was
just
going
to
mention
an
additional
wrinkle
is
appraisals
right
where
we're
explicitly
trying
to
test
different
versions
of
dependencies.
So
sorry.
D
B
F
I
mean
prometheus
stuff,
maybe
but
histogram
support,
for
example
like
if
we
have
to
take
a
dependency
on
like
open,
histogram
or
something
then
yeah,
yeah
yeah,
but
yeah
generally.
I
don't
think
it's
a
lot
of
show,
but.
D
I
kind
of
feel
the
same
way.
Well,
it's
not
the
same,
but
like
it's
the
same
way
of
like
with
our
robocop
rules.
Some
of
them
are
just
there.
We
ignore
them
code,
cov,
vulnerability,
nightmares
aside,
I've
used
it
in
the
past
on
like
projects,
I've
worked
on
and
I've
I've
never
really
gotten
a
lot
of
value
out
of
them.
It
just
like
seemed
like
this
weird
gamification
of
like
you
could
name
plus,
or
you
brought
the
grade
down
and
it's
like
well,
I
need
to
like
make
the
code
this
way
right.
D
C
Cool
yeah,
I
guess
we
can
try
to
see
where
all
this
stuff
is
coming
from
and
what
levels
of
requirement
it
is
to
see
what
kind
of
autonomy
we
have
to
make
some
of
these
decisions.
But
my
my
impression
was
these
were
kind
of
coming
as
like
a
standard
they
wanted
on
on
all
repos,
so
yeah
we
if
we
want
out
of
some
of
these,
we
may
need
to
like
negotiate
our
way
out,
but
I'm
not
totally
sure.
C
Should
we
should
we
call
it
and
see
everybody
next
week.