►
From YouTube: 2021-03-09 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
The
pandemic
goes
on,
you
become
more
and
more
an
80s
villain.
Oh
hang
on
my
sound's
off
or
something
tyler.
You
look
like
you're
talking.
He,
he
called
you
an
80s.
B
F
C
C
C
I
don't
know,
I
guess,
moving
into
startup
land,
I
went
from
bonds
to
stocks,
but
yeah
same
same
villainy,
ship.
B
F
C
I
tossed
this
on
there.
This
was
a
thing
we
had
mentioned
doing
in
the
past,
which
was
just
having
an
opportunity
for
people
to
just
you
know
one
minute
or
one
sentence
update
just
so
we're
kind
of
pulse
checking
each
other.
If
people
would
still
like
to
do
that,
I
I
think
it
would
probably
be
helpful.
C
We
tend
to
focus
on
a
lot
of
technical
stuff
in
this
meeting
right
now,
because
we're
bootstrapping
up
projects,
but
the
original
point
of
this
meeting
was
to
have,
like
you,
know,
cross
cross
team
collaboration
and
help
each
other
out.
So
if
that
seems
good,
do
people
just
want
to
speak
up,
or
should
I
call
names?
I
could
start
us
off.
Yeah.
B
So
the
gosig
itself
is
trying
to
get
to
a
1.0
release.
We
have
a
plan
for
a
plan.
We
opened
up
a
project
to
track
all
of
the
specification
into
an
audit
of
it
to
make
sure
that
we're
actually
compliant
with
it
and
all
the
things
we're
not
we're
opening
issues
for
all
the
things
that
we're
not
we're,
opening
issues
or
really
smart,
small
pr's
are
putting
into
our
company
go
project
board.
B
Currently,
the
project
for
the
project
has
21
more
remaining
issues
to
do
for
the
specification
11
done
so
we're
a
little
bit
about
a
third
way
through
something
like
that
for
the
actual
project
board
that
gets
us
to
the
1.0
release.
We
still
have
27
to
do
and
form
project
a
form
project
or
for
in
progress
this
project's
going
on
for
a
little
while
it's
got
205
done
so
in
theory,
we're
like
mostly
way
down
but
yeah
27
is
still
a
big
number
to
get
done.
So
just
a
heads
up.
C
All
right,
I'm
curious,
rightly,
is
there
c
plus
plus,
has
a
lot
of
surface
area,
and
in
the
past
it
was
difficult
to
find
a
way
to
construct
the
api
and
sdk
to
make
like
everyone
happy.
We
had
like
98
people
in
there,
for
example.
Back
in
the
day
is
that
is
that
an
issue
you're
currently
facing,
or
does
it
feel
like?
There's.
G
No,
I
I
think
we're
we're
we're
quite
flexible,
so
we
we
support
abi
flexibility
by
introducing
a
like
a
minimum
version
of
crt.
So
basically,
we
replicate
several
like
core
components
from
stl
and
make
them
platform
independent
and
also
we
support
multiple
build
systems.
G
So
I
I
believe,
that's
okay,
but
one
challenge
we
have
is
in
the
c
plus
fast
group
they're,
just
like
four
or
five
active
developers,
so
it
might
turn
out
to
be
a
surprise
if
later
a
lot
of
developers
join
and
discover
something
that
we
we
haven't
noticed
before.
So,
if
that's
possible,
I
would
encourage
people
to
like
join
the
signature
and
try
out
the
current
version.
C
Right,
I
feel
like
that
dovetails
with
user
research,
which
is
the
thing
we
want
to
get
going
on
and.
G
Another
thing
is
like
we
discussed
last
year
that
for
the
c
plus
plus,
we
only
support
c
plus
plus,
but
we're
not
trying
to
support
c,
so
people
have
different
opinions.
I
know
some
some
folks
ask
about
like
embedded
device
or
like
very
low
end
device,
where
there's
no
c,
plus
plus
runtime
at
all.
Currently,
I'm
I'm
thinking.
G
C
Great,
they
have
like
a
lot
of
other
issues
that
need
solving
in
embedded
device
land.
You
know
128-bit
ids
are
problematic
for
some
people,
so
I
agree.
Don't
don't
focus
on
that?
Okay,
all
right!
Thanks
for
the
check-in
who's
next
java.
H
Yeah
not
too
much
to
update
and
we
released
1.0.0
a
week
ago
week
and
two
days
ago,
everything
seems
to
be
going
fine.
Just
a
couple:
we've
got.
We've
got
a
little
bit
of
feedback
on
documentation.
We've
gotten
some
feedback
on
kind
of
the
error
message
that
are
logged
when
the
collector's
down
and
just
trying
to
do
a
little
bit
of
on
making
things
a
little
easier
for
people
to
debug
when
things
don't
work
right,
awesome
also
trying
to
keep
things
mostly
very
stable
for
a
little
while.
F
D
Yep
yep
I
can,
I
can
talk
to
it
so
we're
we're
moving
towards
1.0.
I
think
we
have
about
ten,
or
maybe
nine
issues
left
on
our
project
board.
They're.
All.
D
F
I
Yeah
we
are
right
now
working
on
our
api
1.0
rc.
We
decided
to
split
the
api
and
sdk
rcs
into
two
separate
steps,
just
so
that
we
can
be
very
focused
on
the
api
and
make
sure
that
it's
absolutely
solid
before
we
do
the
rc.
I
We
even
went
as
far
as
splitting
it
into
a
separate
repository
beyond
that.
I'm
currently
working
on
an
api
documentation,
effort
for
js
right
now,
because
it
was
falling
behind
for
a
while
and
then
yeah
the
sdk
rc
will
be
in
the
following
weeks
after
we
managed
to
release
the
api
rc.
J
Up.Net
yeah
not
much
update,
so
we
released
1.0
two
to
three
weeks
back
and
we
are
now
mostly
focused
on
getting
the
instrumentation
study.
We
have
quite
a
few
instrumentations
which
were
not
being
attended
to.
While
we
were
focusing
on
the
sdk
release,
so
we
are
trying
to
make
them
ready
for
1.0.
J
Whenever
the
spec
says
we
can
release
1.0,
but
that
I
said
I
I'm
trying
to
like
work
on
the
overall
theme
which
ted
posted
last
week
about
improving
onboarding
experience
and
error
handling.
So
we
have
some
pr's
in
that
direction.
It
would
probably
be
part
of
the
1.1
release,
which
would
be
out
in
like
another,
two
or
three
months.
J
That
is
said,
we
are
actually
working
on
the
matrix
prototyping
as
well
like
we
will
be
just
like
tracing
we'll,
be
trying
to
implement
metrics
right
into
the
dotnet
runtime
itself.
So
we
are
collaborating
with
the
dotnet
team
and
doing
some
very
early
prototypes
right
now.
A
C
Cj,
have
you
been
interfacing
with
the
auto
instrumentation
sig.
J
At
all
recently,
not
recently
so
polo
is
like
the
only
common
bridge
between
the
sdk
and
the
auto
instrumentation
sig.
I
I
don't
attend
that
meeting,
he's
the
only
one
who
attends
both,
so
he
might
have
some
update
about
the
auto
instrumentation
yeah.
C
That's
that's
the
only
thing
I
would
flag
over
there
that
auto
instrumentation
group
seems
like
pretty
divergent
from
what
you
guys
are
working
on
at
the
like
sdk
level,
so
figuring
out
a
way
to
knit
that
together
in
the
future
would
be
good.
So
I
just
wanted
to
raise
that.
J
See
uh-huh
yeah.
There
is
no
no
one
comment,
so
I
I
I
didn't
have
like
any
clue
what's
going
on
there,
but
yeah
thanks
for
heads
up
yeah,
I
think
I
I
should
you
like
sing
with
paulo,
because
sometime
back
there
was
a
mention
that
they
are
not
taking
a
dependency
on
the
actual
sdk.
Rather
they
are
building
something
on.
But
that's
the
last
update
I
heard,
which
was
two
three
months
back
and
after
that
I
never
had
the
chance
to
sync.
C
K
For
collector,
the
the
focus
is
on
stabilizing
and
preparing
for
the
ga
for
traces.
We
we
have
a
plan
posted
in
the
collector
repo.
It's
two
chunks
of
work.
Basically
one
is
hopefully,
by
the
end
of
this
month,
we
will
clean
up
the
internal
apis,
remove
unless
we
export
it
stuff
from
there.
The
second
trunk
is
going
to
be
about
stabilizing
the
specific
components
like
otlp
exposure
receiver,
so
the
components
that
we
want
to
make
part
of
the
ga
and
that,
hopefully,
is
by
the
end
of
the
next
month
april.
C
Awesome,
I
would
love
to
take
some
time
outside
of
this
meeting,
to
figure
out
how
to
elevate
the
collector
roadmap.
We've
been
looking
at
the
the
tracing
roadmap
and
like
the
metrics
roadmap
and
like
how
to
elevate
those
and
make
it
more
public
I'd
I'd
love
to
touch
base
with
you
at
some
point
about
how
we
could
do
that
with
the
collector
as
well
so
yeah
sweet.
I.
K
L
Are
you
can
you
hear
me
now
yeah?
Yes,
sorry
yeah,
so
ruby
is
working
through
an
rc
and
currently
there
are
three
open
issues
I
I
wasn't
in
last
week,
so
I
can't
give
you
too
much
update
on
on
the
progress,
but
I
think
there
are
prs
for
at
least
two
of
them.
So
stuff
looks
like
it's
in
pretty
good
shape.
We
do
have
a
1.0
milestone
that
has
additional
things,
but
most
of
the
additional
things
are
our
documentation.
L
M
Yeah
yep
php
is
not
in
good
shape.
We
are
very
far
away
from
a
1.0
release.
We
don't
have
enough
active
maintainers
or
contributors.
We
had.
We
got
a
lot
of
really
good
direction
with
the
user
research
document,
but
we
just
have
to
execute
on
that
vision,
which
is
very
difficult
to
do
without
anybody
actively
working
on
a
project.
M
C
C
At
this,
but
I
feel
like
we
need
to
get
creative.
M
I've
done
a
lot
of
really
creative
things.
I've
reached
out
in
forums.
I've
talked
to
people
from
different
industries.
I've
talked
to
people
at
mailchimp,
I've
reached
out
to
all
of
the
major
companies
that
have
php
developers.
I
have
we've
gotten,
we've
had
interns
both
times
we've
tried
to
do
everything
that
we
can
to
get
active
computers.
It's
just
very,
very
difficult.
M
C
C
I
don't
I
don't
have
a
new
good
idea,
I'm
sorry
bob
right
for
people
who
work
sorry
go
ahead.
I.
C
F
C
Awesome,
okay,
well,
people
on
the
call
who
work
at
larger
companies
are
companies
that
have
some
amount
of
phd
instrumentation.
You
know
in
existence
just
again
a
shout
out
to
go
ask
about
this
internally.
C
I
know:
there's
a
tendency
to
want
to
focus
on
like
the
quote-unquote
big
languages,
like
the
big
companies
like
google
and
amazon,
and
everyone
else
tends
to
be
like
well,
we
got
to
get
java
out
the
door,
but
it
feels
like
those
groups
are
in
good
shape.
So
if
you
can
find
people
who
are
willing
to
work
on
php,
that
would
be
really
really
helpful.
B
B
We
would
like
to
release
those
primarily
for
the
spring
spring
sleuth
community,
where
they
will
want
to
use
library,
instrumentations
primarily,
and
so
that
kind
of
dovetails
into
the
topic
I
left
on
the
next
bullet
point,
which
is
just
just
checking
in
with
folks
here
on
what
progress
is
on
defining
telemetry
stability,
because
from
la
last
week
there
was
agreement
that
we
could
go
ahead
and
release
the
java
agent,
auto
instrumentation
piece,
but
we
should
hold
off
on
releasing
individual
library
instrumentations
until
we
define
telemetry
stability.
C
Okay,
yeah,
I
mean
telemetry.
Stability
is
going
to
be
a
big
bear
bug,
but
it
sounds
like
you've
done
the
best
middle
ground
that
we
can
hit.
C
As
yes,
yes,
we
should
still
be
waiting
waiting
to
declare
those
stable
until
until
we
figure
out
what
stability
means
right
like
like,
we
don't
really
have
a
definition
for
stable
of
those
components.
Yet,
okay,
cool.
C
It's
it
is,
it
is
part
of
the
road
map,
I'm
not
like
actively
working
on
a
an
aspect
of
this,
but
it's
it's
on
the
road
map
to
to
get
it
done.
It's
part
of
the
instrumentation
roadmap,
so
we're
hoping
to
have
an
answer
to
this
by
the
beginning
of
may,
when
we
expect
interns
to
start
showing
up.
So
that's
that's
the
deadline,
we're
aiming
for
so
I'll,
be
trying.
C
I've
got
it
on
the
agenda
here,
like
the
first
one
of
these
project,
proposals
fleshed
out
a
little
bit
more,
but
the
big
one
is
instrumentation,
and
so
we'll
start
booting
that
up
maybe
next
week
start
trying
to
get
that
effort.
A
little
more
organized.
N
Well,
if
not,
I
guess
we
have
people
obliques
other
people
that
could
be
interested.
Please
take
a
look.
This
is
the
idea
we
discuss
last
week.
It
was
proposed
by
riley
originally
about
having
specific
sections
in
the
specification
that
you
know
they
are
owned
by
somebody.
So
we
can
move
things.
Hopefully
don't
faster.
N
F
N
Yeah,
I
don't
know
whether
you
are
interested
or
you
think
that
or
not
disclose
this
one
here
now,
but
this
is
important
enough,
but
your
call.
C
Yeah
well,
does
anyone
have
any
blocking
concerns?
There's
like
a
couple
of
points
on
there
that
I
need
to
like
couple
comments.
I
need
to
respond,
but
I
didn't
see
anyone
raising
like
a
big
blocking
concern.
N
C
Yeah,
so
I
would
say:
that's
that's
actually
the
action
item
here.
I
don't
feel
like
there's
anything
in
this
otep
that
we
haven't
been
discussing
on
this
call,
but
it's
just
basically
trying
to
provide
the
motivation
for
how
provide
a
motivation
for
why
we
have
the
the
requirements
that
we
do
around
stability,
in
particular
clarifying
the
direction
of
stability,
so,
in
other
words,
from
the
api,
the
stability
we
care
about
is
from
the
perspective
of
the
callers.
C
C
Likewise
for
alternative
implementations,
if
someone
writes
an
alternative
implementation,
they're
expected
to
keep
up
the
sdk
in
turn
is
expected
to
offer
backwards
compatibility
to
the
implementers
of
the
interfaces
it
provides.
So
I've
been
calling
these
plug-in
interfaces.
They
don't.
This
doesn't
mean
instrumentation
to
be
clear.
This
means
sdk
plugins
and
by
providing
backwards,
compatibility
there
and
not
breaking
those
that
ensures
that
when
the
sdk
moves
up
to
a
new
version,
users
will
be
able
to
follow
it.
C
If
we
don't
do
it
that
way,
then
we
end
up
in
kind
of
like
a
legacy
hell
scape,
where
we're
having
to
maintain
not
just
old
versions
of
the
sdk
but
old
versions
of
instrumentation
and
like
old
stuff
everywhere.
So
the
proposal,
the
motivating
document
here
kind
of
describes
that
goal
and
and
why
I
believe
it
will,
it
will
work.
C
Basically,
if
we
make
it
smooth
for
people
to
upgrade
to
the
latest
version
of
the
sdk,
then
we
don't
end
up
having
to
actually
maintain
a
bunch
of
legacy
stuff,
just
just
ensure
that
the
legacy
plugins
continue
to
work
with
the
latest
version
of
the
sdk.
C
We've
proposed
a
one-year
window
for
plugins
to
to
upgrade
before
an
sdk
is
allowed
to
remove
a
deprecated
plug-in
interface.
C
Obviously,
it's
not
a
requirement
that
you
remove
them
after
one
year,
but
that's
maybe
the
one
point
is
one
year
a
long
enough
window,
but
but
that's
where
we're
at
and
for
the
api,
we're
we're
saying
three
years
three
year
window
of
deprecation,
but
we're
actually
planning
to
never
break
those
apis,
so
so
that
that's
what's
in
that
doc,
if
that's
confusing
to
anybody,
please
go
read
that
and
and
post
a
question
there
just
so
we
can
get
them
all
into
the
doc
instead
of
here
in
the
meeting
sound
good.
N
For
these
other
topics,
actually
can
we
go
back
bogdan
is
here,
so
I
would
like
to
talk
about
the
ownership
section
that
seems
important
enough.
Even
if
we
just
talk
about
five
minutes,
yep.
N
O
Yeah
I
want
to
to
know
what
does
it
mean
to
be
an
owner?
What
does
it
mean
to
be
an
expert?
What
are
your
attributions,
what
are
your
privileges
or
whatever
you
call
them?
What
do
we
follow
our
specific
process?
Do
we
always
want
the
document
owner
approval,
whatever
it
is,
but
there
is
no
clarification
there
and
we
just
throw
people
under
the
bus,
make
them
approval
owners
or
whatever
is
called,
and
without
anything
that
is
clarifying,
and
how
do
we
choose
them?
How
do
we
become
one
of
that
or
things
like
that?
O
It
was
just
completely
random
coming
from
nowhere.
The
fact
that
we
added
these
concepts
without
clarifying
what
they
are
I
mean.
I
know
we
discuss
about
having
something
like
this:
it's
not
like,
literally
from
nowhere,
but
without
having
an
understanding
of
what
does
it
mean
and
documented.
I
I'm
not
feeling
comfortable
of
starting
adding
people.
O
Is
this
I
don't
know
the
last
pr
that
adds
for
all
of
them,
it's
adding
for
all
of
them,
no
matter
if
it's
stable
or
not
so
has
another
point
like
yeah,
maybe
maybe
for
experimental.
We
do
this
again.
Nothing
documented
and
I
feel
very
bad
on
on
having
these
concepts
to
the
to
the
documents
and
without
having
clarification
of
what
does
it
mean?
What
is
the
role
of
that
person
and
so
on
yeah?
That
makes
sense.
O
G
Yeah,
that
makes
sense,
as
I
told
you
on
friday,
don't
feel
sorry.
I
I
think
that's
a
valid
concern
so
also
in
the
pr
idea
I
said,
and
I
think,
as
ted
mentioned,
we
probably
can
start
with
the
document
that
are
not
stable.
Yet
I
think
the
most
part
like
will
benefit
from
this
would
be
the
semantic
convention,
because
a
lot
of
people
have
the
challenge
like
when
there
is
an
aws
specific
semantic
convention.
They
don't
have
expertise
and
it's
hard
to
just
rely
on
the
tc
members
to
reveal
everything.
G
O
Maybe
the
answer
is
we
create
sub
teams
that
we
make
them
even
code
owner
again?
There
are
a
lot
of
things
to
to
be
considered
and
a
lot
of
things.
I
indeed
there
is
a
problem
really.
Indeed
we
need
to
solve
it.
I
don't
know
if
just
adding
these
terms,
without
maybe
some
setup
or
automatic
setup
of
of
adding
people
to
review
these
may
enforcing
some
kind
of
approval
from
from
these
people.
Things
like
that
there
needs
to
be
something
we
cannot
just.
G
G
I
think
the
first
step
could
be
figuring
out
the
people
and,
if
we
don't
like
the
like
putting
people's
name
in
the
markdown
file,
we
can
probably
start
with
something
else,
but
as
long
as
we
associate
document
with
people's
name,
I
think
the
next
step
is
pretty
obvious.
Once
you
have
the
the
the
name
to
document
metrics,
you
can
either
do
the
pr
of
mention
or
you
can
invent
another
system
and
and
changing
that
part
should
be
easy.
N
Right
yeah,
before
we
move
to
the
next
topic,
I
could
suggest
starting
this
way:
small
suggestion
with
semantic
conventions
and
metrics
like
experimental
stuff
one
we
have
to
find.
We
can
just
try
with
the
rest
and
stuff,
but
that's
up
to
you
guys,
of
course,
just
my
suggestion
all
right.
Thank
you.
Thank
you
so
much
we
can
move
to
the
next
one.
I
guess
morgan.
C
C
There
all
right,
so
this
is
just
just
a
write
up
the
the
first
one
of
these
projects.
We
want
to
kick
off.
Is
this
convenient
api
project?
It's
it's
fairly.
I
think
straight,
the
most
straightforward
of
all
the
projects
we've
proposed,
so
that's
sort
of
why
I
wanted
to
start
with
it,
because
it
would
be
very
helpful
to
users,
especially
hot,
on
the
heels
of
1.0
releases,
but
it's
also.
C
I
haven't
made
a
backlog
board
for
this
yet,
but
I
did
want
to
focus
on
just
defining
what
is
actually
needed
here.
So
there's
a
couple
sections.
The
top
is
just
a
description
ported
over
from
the
roadmap
dock
under
that
are
the
oteps
that
we've
identified
so
far.
That
would
be
required
for
this
project.
I
believe
there
are
two
one
is
suggestions
for
api
architecture.
C
I
don't
want
any
of
this
to
be
required,
since
some
languages
have
already
added
a
certain
amount
of
convenience
and
what
makes
for
convenience
is
again
the
less
standard
than
some
of
the
other
stuff
we're
doing
it's
also
as
long
as
this
stuff
is
high
level,
then
you
don't
have
to
worry
so
much
about
whether
you've
broken
the
model.
C
So
that's
one
one
otep
that
needs
to
get
written,
then
sort
of
a
separate
working
group,
or
at
least
a
separate
otep
or
something
that
can
be
added
to
over
time,
is
just
suggested
method
signatures
for
these
convenience
methods.
C
C
So
those
are
the
two
oteps
I've
assigned
myself
to
these
just
because
they
don't
necessarily
want
to
bother
other
people.
Someone
else
would
like
to
write
one
of
these
oteps
or
take
this
on.
That
would
be
awesome.
Please
just
make
a
comment
in
the
stock
saying
I'd
be
interested
in
championing
this,
but
I
just
sign
myself
just
to
keep
it
moving.
O
So
those
will
be
coming
soon
ted.
Can
you
elaborate
a
bit
on
what
would
be
an
example
of
what
you
get
out
of
this
so
yeah
struggling
a
bit
too
to
talk
in
a
managerial
way?
I'm
struggling
a
bit
to
see
the
the
key
results
of
this.
What
what
do
we
try
to
achieve
at
the
end
of
this
experiment
or
or
this
work.
C
Yeah,
so
the
the
key
results
here
are
basically
taking
user
research
and
user
feedback
around
the
open,
telemetry
api
as
it
stands
today
and
looking
for
ways
that
we
can
simplify
that
experience
from
the
perspective
of
application
developers.
C
What
are
ways
that
we
can
make
that
experience
simpler
and
easier
for
new,
especially
for
new
people
coming
onto
the
project,
so
should
we
should
we
define
the
personas
that
we
are
focusing
this.
O
C
Yeah,
that
would
actually
be
awesome,
good
idea,
so
I'm
gonna
add
some
notes
here
so
sonas.
I
think
that
is
a
good
idea.
Yeah
and
this
whole
process
I'm
just
kind
of
making
up
as
we
go.
I
don't
want
to
over
structure
how
we
approach
these,
but
I
don't
want
to
under
structure
it
either.
So
feedback
like
this
is
is
great,
so
the
persona
in
this
case,
I
would
say,
is
the
application
developer
and
the
the
new
user
who's
just
getting
started.
C
The
things
that
we
know
from
user
research
we've
received
so
far
is
some
constructs
you
know
are,
can
have
a
fair
bit
of
overhead,
for
example,
managing
spans
and
in
some
languages
everything
is
like
well
factored
out
into
a
number
of
smaller
separate
packages,
but
for
new
users
that
can
be
a
little
bit
difficult
because
they
don't
understand
what
open
telemetry
is
or
what
it
does
yet
and
thus
they
they
don't
know
the
structure
so
having
having
things
bundled
up
into
a
single
package
or
otherwise,
grouped
together
in
a
way
that
they
can
leverage
their
ide
and
like
automated
documentation
and
other
things
in
order
to
to
get
a
sense
of
that
structure.
C
But
those
are
kind
of
the
two
ways
we've
seen
feedback
about
how
this
could
be
better,
there's
also
on
different
languages.
There
are
kind
of,
like
higher
higher
level,
constructs
things
that
combine
multiple
steps
into
a
single
step.
C
You
know,
I
want
to
record
an
exception
and
set
the
status
at
the
same
time.
Things
like
that.
So
that's
that's
what
we
want
to
look
at
as
far
as
convenience
like
what?
What
today
makes
the
api
a
little
bit
cumbersome
for
application
developers
and
figure
out
a
way
to
add
that
to
open
telemetry
without
having
to
to
be
messing
with
a
lower
level
api,
it's
a
little
bit
safer
and
easier
to
do
it
this
way.
C
So
that's
part
of
it.
So
I
think
there's
there's
a
two.
I've
factored
this
into
like
two
pieces.
One
is
just
like
convenience
methods
on
an
api
package
or
something
similar.
C
The
other
is
annotations
or
decorators
or
macros
languages
have
some
version
of
that
kind
of
higher
level
programming
construct,
and
there
are
things
you
can
do
with
annotations
that
you
can't
do
with
just
like
a
higher
level
function,
for
example,
leveraging
language
closures
like
method
signatures
can
really
reduce
a
lot
of
code
overhead,
and
so
it
would
be
great
just
to
kind
of
collect
up
in
a
brainstorming
session,
either
synchronously
or
asynchronously,
or
both
just
what
our
ideas
for
methods
that
we
could
add
to
an
api
package
and
also
what
are
annotations.
C
We
could
add
that
would
be
helpful
and
I'm
just
keeping
them
in
two
separate
groups,
because
what
you
can
do
with
things
like
macros
and
annotations
is
a
bit
different
than
what
you
can
do
with
with
just
higher
level
functions.
C
C
If
people
wouldn't
mind
adding
suggestions
here,
based
on
like
stuff
we've
already
done,
or
things
you've
already
seen
as
we
start
getting
user
research
coming
in
we'll
try
to
fill
this
out
more,
and
this
will
motivate
that
second
otep.
So
once
we
get
some
feedback
from
these
brainstorming
sessions
and
user
research
I'll
get
that
second
otep
written
or
at
least
seated,
and
then
we
can,
we
can
add
methods
to
that
thing
as
time
goes
on.
C
So
there
are
a
couple
of
other
tasks
in
here
that
I'd
like
to
point
people.
To
last
time
we
discussed
getting
feedback
from
two
different
sources.
One
source
is
language
experts.
C
C
So,
basically,
so
there's
language
experts
if
people
could
volunteer
themselves
there.
If
anyone
just
knows
a
language
expert
or
feels
like
they
could
get
access
to
someone
to
review.
From
that
perspective,
we
would
welcome
some
feedback
there,
so
that
seems
a
little
scary.
The
feedback
we
really
need
and
takes
a
bit
of
effort
to
get
is
user
feedback.
C
So
one
form
of
this
is
just
asking
co-workers
to
give
it
a
try.
That
is
the
easiest
form
of
feedback.
The
other
is
asking
the
internet
to
to
go
through
this,
and
I've
offered
two
suggestions
here
for
how
we
could
do
feedback
one.
Is
this
user
feedback
walkthrough?
This
is
the
thing
we
wrote
up
a
while
back.
This
is
like
a
more
involved
user
research
session,
so
this
is
asking
someone
to
actually
go
through
a
process
of
setting
up
open,
telemetry
and
using
it
and
and
filling
out
a
whole
form.
C
So
this
is
this
is
like
the
big
ask
version,
asking
someone
to
go
through
a
longer
process
and
then
for
simpler
feedback.
I've
just
created
a
google
form
that
just
is
like
optional
contact
information
and
your
feedback.
You
know
in
a
blob
feedback
in
any
written
form
is
fine.
This
was
just
a
request
from
people
to
like
you
know
if
they
wanted
to
do
a
structured
approach.
Here's
an
example
of
one,
so
this
is
work
that
I
think
it
would
be
great
to
get
started
on
sooner
rather
than
later.
C
So
I
think
my
one
ask
right
now
is
who
who
here
could
feels
like?
They
could
volunteer
to
just
try
to
corral
some
users
and
get
them
to
give
feedback
again,
either
co-workers
or
or
through
some
other
channel
that
they
might
know.
It
would
be
great
just
to
get
a
list
of
names
so
that
we
can
start
start
making
this
effort.
O
C
Yes,
so
this
is
a
maintainer's
call,
so
we've
got
a
number
of
maintainers
here,
so
I
would
say
if
you
are
getting
feedback
through
any
channel
either
just
keeping
that
feedback
in
a
doc
like
just
collecting
it
somewhere
or
just
pasting
it
into
that
form
and
submitting
it.
I
realize.
Actually,
we
should
add
a
field
to
that
form
as
to
what
language
they're
using.
C
C
C
So
this
is
a
rough
proposal
for
how
to
do
that.
If
anyone
knows
how
to
run
a
more
structured
user,
research
or
user
feedback
process
or
wants
to
help
shepherd
this
again,
I
would
welcome
help
on
this
front.
C
C
Yeah
right,
so
I've
created
a
one
form.
That's
just
you
know
paste
your
feedback
into
this.
You
know
text
box,
but
we
could
create
a
another
google
doc,
that's
just
a
bit
simpler
and
less
scary
than
this
one.
That
just
has
some
basic
questions.
So
people
could
make
a
copy
of
that
doc.
Fill
it
out
and
then
submit
it
using
a
form
like
this,
so
you
can
start
collecting
it
that
way
and
yeah.
C
Yeah
yeah,
so
maybe
that's
a
middle
ground.
The
longer
more
involved
thing
is
is
helpful.
I
mean
it
looks
like
a
lot,
but
it's
really
just
structuring
someone
through
through
setting
up
open,
telemetry
and
and
instrumenting
a
single
method
in
their
application.
C
It's
just
it
just
has
props
all
along
the
way
to
help
them
remember
what
happened
when
they
were
doing
making
that
setup.
So
so
it
looks
a
little
involved,
but
it's
not
asking
them
to
do
in
my
opinion,
really
do
anything
more
than
what
they
would
be
doing
if
they
were
just
setting
up,
but
that's
more
for
like
if
you
go
to
someone
you're
like
hey,
can
you
set
up
open,
telemetry
and
try
it
and
write
down
your
process
as
you?
C
P
C
C
Yes,
if
people
can
start
just
giving
them
to
me
or
submitting
them,
I
will
collect
them
in
some
manner
like
just
you
know,
a
dock
that
links
to
them
all
or
a
spreadsheet
and
then
try
to
start
extracting
out
common
themes
from
them.
C
I
kind
of
have
to
see
what
kind
of
feedback
we're
getting
before
I
figure
out
what
the
best
place
to
put
it
all
is.
If
people
want
to
send
private
feedback,
I
would
suggest
just
having
that
be
anonymous
feedback.
I
don't
see
way.
We
could
really
keep
this
feedback
fully
private,
but
if
people
do
want
to
just
say,
I
don't
want
my
name
attached
to
this.
Don't
follow
up
with
me.
I
think
this
is
terrible,
and
let
me
explain
to
you
how
it's
terrible-
and
you
know
don't
call
me-
that's
also
fine.
C
F
A
good
amount
more
once
more
sdk
is
a
ga
just
because
people
be
able
to
take
the
foot
off
the
gas
a
bit
and
have
some
time
yeah.
E
F
Well,
as
that's
when
a
lot
of
vendors,
like
speaking
of
splunk
like
our
customers,
are
going
to
start
using
this,
that's
a
good
funnel
for
us
to
capture
feedback,
and
I
guarantee
we're
going
to
be
funneling
that
feedback
back
to
the
project.
Similarly,
I
know
at
google
they're
looking
at
well.
They
already
use
open
telemetry
a
lot
internally
and
they're
looking
at
using
it
even
more
one
imagines
that
more
feedback
will
come
out
of
that
funnel,
as
well
as
microsoft
and
other
firms.
C
Yeah
yeah
and
I
imagine
a
lot
of
feedback
will
just
start
showing
up
in
the
form
of
issues
yeah
for
maintainers
to
deal
with.
I
think
just
the
question
there
is:
is
there
on
a
higher
level
way?
We
want
to
be
synthesizing
that
feedback,
so
that's
not
just
the
maintainers
dealing
with
issues,
but
you
know
being
able
to
like
pull
out
common
themes
or
reviews
reviewing
user
feedback
as
a
whole
to
figure
out
like
as
a
project
what
what
we
should
be
doing
better.
C
C
So
so
that's
my
my
primary
ask
right
now
is
to
to
just
poke
find
some
low
hanging
fruit
like
coworkers
and
say:
hey,
do
you
mind
just
trying
this
right
now
and
just
just
writing
down
your
feedback
and
if
you
know
a
language
expert
that
you
would
like
to
to
tap
at
some
point
to
say:
hey,
can
you
have
a
look
at
this
and
give
us
advice
on
like
how
we
can
make
this
more
convenient
or
idiomatic?
C
N
Yeah,
actually,
I
I
want
only
to
drop
some
additional
notes
on
that
back
in
open
tracks.
We
had
the
same
situation
and
that's
this
is
where
it
originated.
If
I
remember
correctly,
it
said,
and
the
problem
was
not
people
writing
instrumentation,
like
instrumentation,
for
frameworks
the
problem
where
final
application
developers-
yes.
C
N
This
is
why
exactly
you
know-
and
I
remember
that
back
in
the
day,
I
used
to
think
that
open
tracking
api
was
so
simple
right,
but
this
is
like
to
us,
but
the
final
users
yeah.
It's
you
couldn't
imagine
like
how
you
know
things
were
not
obvious
because
they
were
they
were
not
probably
for
them.
So
this
is
why
it's
especially
important.
C
C
Is
this
one
just
figuring
out
how
we
can
make
the
api
simpler
and
more
pleasant
for
people?
The
other
project
is
coming
a
bit
later
and
that's
the
installation
process.
How
do
we
make
that
installation
bootstrapping
process
simpler
and
friendlier
for
people
so
we'll
be
doing
that
later?
C
So
again,
I
don't
take
up
any
more
time.
That's
the
the
feedback.
I
would
like
it
this
time.
I'm
gonna
start
getting
those
oteps
written
and
start
putting
a
backlog
together,
working
with
maintainers
to
to
figure
out
how
we
can
fit
actually
working
on
this
convenient
stuff
into
their
schedules.
I
know
different
projects
are
at
different
stages.
A
lot
of
groups
are
dealing
with
just
getting
1.0
over
the
finish
line,
but
I
want
to
just
start
charting
that
roadmap
with
people,
but
the
ask
right
now
is
just
to
figure
out.
C
C
Thanks
feedback
ping
me
on
slack
or
or
give
me
feedback
from
the
docs
talk
to
you
later.
E
Yeah
hi,
so
I
wanted
to.
I
know
there
was
some
discussion
about
this
last
week
and
there's
been
some
confusion
about
where
do
docs
live
and
where
authoritative
docs
live.
So
I
wanted
to
hopefully
give
some
background
and
also
or
just
summarize,
the
problem
and
also
pitch
the
solution.
So
the
the
problem.
Thank
you
morgan.
E
So
the
problem
is,
is
there's
several
problems.
One
is
that,
while
I
think
everyone
like
each
maintainer
and
each
tick
has
very
good
documentation
or
it's
somewhere
on
a
spectrum
of
documentation
right,
but
everyone
has
kind
of
the
way
they're
doing
this,
and
I
res
that
totally
makes
sense,
because
I
know
the
python
people
have
like
the
big
read
the
docs
repo.
E
I
know
java
has
a
lot
of
stuff
that
is,
is
kind
of
a
markdown.
C-Sharp
has
its
own
kind
of
way
of
organizing
it
where
you've
got
these
pretty
comprehensive
docs
in
each
subfolder.
The
problem
is,
is
that
you
know
this
is
different
for
every
single
language
right
and
there's
no
consistency
to
it
and
open
telemetry.
Much
like
open
tracing
and
much
like
open
census
is
a
project
where,
at
worst,
you're
gonna
need
to
know
about.
E
So
the
goal
of
the
open,
telemetry
website
right
now
in
terms
of
docs,
is
simply
to
be
an
entry
point
to
the
per-sig
docs,
we're
not
trying
to
say
everyone
needs
to
do
all
their
docs
on
the
website.
We're
not
trying
to
say
you
have
to
do
it
this
way.
What
we're
trying
to
say
is
when
someone
hears
open,
telemetry,
they're
gonna,
go
to
the
open,
telemetry
website
and
they're
gonna
find
something,
and
we
need
to
give
them
something
that
at
least
can
help
them
get
started
and
point
them
to
more
resources.
E
So
I
know
there's
been
some
complaints
about
two
things:
one
documentation
on
the
website
not
being
updated
to
reflect
releases
by
the
sigs.
The
second
thing
is
unclear
processes
on
how
that
gets
done.
So
I
what
I'm
hoping
we
can
do
here
is
we
I've
put
a
proposal,
there's
a
linked
issue,
and
if
everyone
wants
to
go
read
that
comment
on
it,
you
know
thumbs
up
it
whatever.
E
Then
that's
what
we
can
do,
but
the
basic
idea
is
as
a
first
step
what
you
know
if
sigs
want
to
maintain
the
documentation
for
their
repo
right
for
their
language,
then
all
you
need
to
do
is
create
a
website
folder
that
mirrors
the
content
structure.
So
it's
really
just
an
index.
It's
like
a
markdown
file
for
index
and
then,
whatever
you
want
on
there
and
then
write
just
some
basic
getting
started.
Docs
there,
a
pointer
to
another,
you
know
a
pointer
to
your
docs,
your
read
the
doc
site.
E
Your
your
whatever
else
that
you've
got
set
up
is
fine,
just
something.
So
when
someone
jumps
in
they
can
see
like
hey,
here's
docs,
you
can
be
as
comprehensive
or
as
basic
as
you
want.
We
just
need
something
there
to
kind
of
point
people
to
so
they
can
get
that
and
then,
when
you
make
a
release,
when
you
you
know,
when
you
release
a
new
version,
then
you
would
make
a
pr
with
those
files
in
that
website
docs
against
the
website
repo
in
the
future.
We
can
try
to
automate
this.
E
In
general,
there's
it's
challenging
to
create
to
retain
multiple,
independent
versions
of
each
language
docs
on
the
site,
so
we're
just
asking:
can
you
just
make
sure
it's
whatever
the
most
recent
stable
is?
Is
all
we're
asking
for
and
if
you
would
like
someone
from
coms
to
do
that,
that's
fine,
just
ping!
You
just
make
an
issue
and
say:
hey.
We
need
docs
from
this
tag.
You
know
updated.
E
The
thing
is,
please
keep
in
mind
like
there
aren't
a
ton
of
maintainers
in
the
website
and
so
and
I
can't
like
approve
my
own
prs.
So,
for
instance,
like
I
I
know
john,
you
were
saying
there
was
a
thing
with
the
javadocs.
E
F
E
E
Yeah
so
yeah.
If
people
want
to
drop
a
you
know
thumbs
up
thumbs
down
on
that
linked
issue.
472
then
we'd
love
to
hear
from
you
and
then
we'll
be
talking
about
it
at
the
com
sig
meeting
on
thursday.
E
N
I
think
it's
better
to
discuss
that
tomorrow
in
the
specification,
but
I
was
wondering
whether
it
would
be
interesting
for
you
guys
to
take
a
look,
even
even
now,
it's
about
semantic
conventions,
whether
we
should
try
to
stick
to
longer
more
explicit,
clearer
names
or
just
go
with
something
that
is
more
compact.
This
came
because
of
some
changes
that
vienna
proposed
and
there
was
there
was
some
small
discussion
regarding
like
if
we
had
to
choose
between
zone
or
I
remember
what
was
the
location,
something
like
that.
N
I
don't
remember-
and
this
seems
important
enough,
because
once
we
have
we
have
to
define
this
before
we
can
actually
go
start
changing
other
names
and
because
of
this
we
without
this
we
cannot
go
and
merge
a
pair
of
pr's.
So
please
take
a
look.
As
I
said,
this
is
more
like
specification
oriented
but
yeah.
I
think
this
is
interesting
enough,
and
we
can
definitely
talk
about
that
tomorrow.
Yes,.
O
Last
last
thing
I
think,
but
we
can
talk
also
tomorrow.
I
think
we
are
owning
people
1.1
release
of
the
specs.
We
said
that
we'll
do
that
every
first
week
of
the
month,
so
I
think
maybe
tomorrow
we
discuss
that,
but
we
should
do
it
this
week.