►
From YouTube: Live Panel: Maintainer Forum
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2021 Virtual from May 4–7, 2021. Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Live Panel: Maintainer Forum
The maintainers of many OpenTelemetry SIGs will be available to give a status update and take questions about the project."
A
So
right
now
we're
starting
the
maintainer
forum.
I'm
really
really
excited
to
be
here
and
learning
from
everything's
covering
up
everything
else.
To
learn
from
these
awesome
contributors,
who've
made
some
significant
contributions
to
open
plumber
tree,
so
let's
go
around
and
have
each
of
our
panelists
introduce
themselves,
starting
with
tyler.
B
Cool
yeah,
not
normally
the
first,
so
yeah
hi,
I'm
tyler.
I
work
at
a
new
relic
as
a
software
engineer
and
I'm
a
maintainer
of
the
the
go
special
special
interest
group
of
the
sig,
as
we
call
it
in
the
optometry
project
and
I've
been
working
in
open
sumtry
for
just
about
a
full
year.
At
this
point
pretty
much
every
day
and
working
with
these
other
wonderful
folk
in
the
community.
B
C
D
Yeah
hi,
I'm
tristan,
I
work
at
postmates
and
I
maintain
the
erlang
and
elixir
implementation.
The
sig
and
I
started
with
open
telemetry.
I
guess
over
a
year
ago
now
I
was
maintaining
the
yearling
elixir,
open
census,
implementation
before
that
and
so
segued
into
open
telemetry
when
the
projects
were
merged.
E
Everyone,
my
name
is
tigran,
I'm
an
open,
telemetry
maintainer
and
a
technical
committee
member.
I
have
been
with
open
geometry
since
the
very
beginning.
Actually
before
that
consensus,
a
little
bit
most
of
the
work
I
do
is
on
opportunity
collector
and
on
the
specification,
and
primarily
it's
the
tracing
and
logging
parts
of
it.
Let's
saw
the
metrics
yeah.
F
Hi,
my
name
is
bogdan,
I'm
one
of
the
person
that
is
guilty
for
all
this
mess
that
we
created.
I
started
when
I
was
back
in
google.
I
started
the
opencensus
project
as
a
open
source
initiative
coming
from
google.
We
did
make
a
lot
of
contributions
in
that
project
and
tristan
was
part
of
that.
Tigran
was
part
of
that
effort
and
then
at
one
point
we
decided
that
you
know
what
I
think
we
are
doing
something
wrong
for
the
community.
We
are
competing
standards
between
open
tracing
and
open
sensors.
F
A
Thank
you
and
I'm
shelby
spees.
I
am
a
developer
advocate
at
honeycomb,
and
I'm
just
here
to
help
moderate
and
ask
some
questions.
Ask
questions
from
the
chat.
I
also
want
to
mention
that
anyone
who's
a
maintainer
on
open
telemetry
is
encouraged
to
participate,
so
go
ahead
and
raise
your
hand
in
the
in
zoom
and
we
can
have
you
contribute
and
answer
questions.
So
with
that,
I
will
share
the
first
question:
what
has
been
your
experience
as
an
open,
telemetry
maintainer,
and
what
are
the
challenges.
B
Yeah,
we
could
probably
just
start
in
the
same
order-
I
think
is
probably
the
best
way
and
then
bogdan
can
laugh
at
me.
I
guess
so
yeah.
I
think
it's
actually
kind
of
ideal
to
kind
of
talk
from
my
perspective,
because,
unlike
some
of
the
other
maintainers
on
this
board,
I
didn't
come
from
the
world
of
already
contributing
and
already
building
the
census
or
open
telemetry.
B
C
B
Is
actually
a
really
positive
element
about
contributing
in
the
open
source
world
and
I've
really
appreciated
that
that
dynamic
of
it?
It
also
moves
at
its
own
speed,
which,
coming
from
a
very
close
source
world
is,
is
not
the
speed
that
essentially,
I'm
used
to
so
it's
kind
of
fun
to
try
to
to
get
up
to
that
new
kind
of
model
of
operating.
B
F
D
F
D
F
G
E
C
A
A
E
Yeah
yeah,
that's
a
good
question.
I
think
we're
doing
pretty
well
in
the
specification
seek.
We
have
just
frozen
the
portion
of
the
specification
which
defines
how
tracing
is
supposed
to
work,
so
we're
we're
very
near
the
the
finish
line
for
the
specification,
and
we
know
that
the
language
maintainers
language,
sdk
maintainers,
are
also
ready
to
give
us
the
implementations.
E
According
to
the
specification,
I
would
say
we
are
now
very
close
to
the
finish
line
through
1.0
release,
so
I
feel
very
good
about
what
we
have
done
so
far
with
the
tracing
part
and
the
metrics
josh
was
talking
about
that
a
bit
earlier
is
coming
pretty
soon
after
that.
So
we're
doing
well
in
all
of
the
regards
here.
B
C
B
Think
it's
I
think,
we're
going
along
in
the
the
ghost
thing
I
can
speak
specifically.
Obviously,
the
metrics
side
of
things
and
the
specification
is
still
a
work
in
progress,
but
we
are
making
progress
on
that,
and
so
it's
more,
I
think,
from
the
gosak's
perspective,
an
interesting
thing,
because
now
we
are
really
coming
to
the
end
of
the
the
tracing
specification.
Saying
like
this
is
going
to
be
the
release
candidate
so
really
go
make
it.
You
know,
implement
the
specification
sounds
cool.
B
At
this
point,
like
it's
absolutely
critical
and
we're
trying
through
many
different
ways
of
requesting
feedback
through
forms
or
through
other,
like
direct
access
to
other
users,
to
get
some
feedback
into
those
language
implementations
and
trying
to
iterate
them
on
those
fast
going
forward.
But
yeah,
it's
still
a
work
in
progress,
and
I
think
that
we're
going
to
be
asking
and
trying
to
do
a
lot
more
of
that
going
forward.
B
G
A
G
Yeah
sure
so
awesome
so
yeah
as
an
end
user.
I
came
to
the
project
I
think
fairly
early
on
because
we
were
just
starting
a
new
application
development
project
where
we
expected
development's
gonna
last
two
to
three
years
and
we
were
looking
at.
How
do
we
instrument
this
and
we
saw
well
open
tracing
open
census
are
they're
coming
together,
they're
merging
so
two
to
three
years
from
now,
when
we're
ready
to
go
into
production
with
this
they're
not
going
to
be
there.
I
guess
that
means
we
got
to.
G
G
The
documentation
had
changed
between
the
time
that
I
pulled
the
code
and
the
time
that
I
went
to
look
at
the
documentation
to
see.
Why
that
what
I
tried
to
do
from
the
example
wasn't
working,
but
things
have
gotten
a
bit
better
from
there
and
the
community
was
incredibly
welcoming.
So
as
soon
as
I
jumped
into
the
getter
and
started
asking
questions
and
saw
that
there
were
gaps
in
the
capabilities
that
the
instrumentation
had
that
I
could
offer
offer
up,
you
know
help
with
the
http
instrumentation
and
things
like
that.
G
F
Secondly,
I
think
at
this
moment
it's
it's
very
critical
for
us
when
we
talk
about
rc,
when
we
talk
about
ga
that
now
more
and
more
end
users
will
help
by
trying
our
projects,
I
think,
even
though
you
don't
do
pr's
contributions,
helping
us
by
by
using
our
our
work
and
trying
our
our
apis,
our
implementation
and
provide
feedback
is
probably
more
valuable
at
this
point
than
anything
else.
So
please
help
if,
if
you,
if
you
want
to
help
with
this
you'll,
be
greatly
appreciated.
D
D
A
Thank
you
so
much
and,
and
definitely
like.
I
was
really
excited
to
see
the
talks
this
morning
on
just
how
to
how
to
get
involved
and
how
welcoming
the
community
is
and
and
from
from
what
I've
been
learning.
You
know
just
the
past,
like
six,
eight
months
of
being
even
aware
of
the
open
telemetry
community,
I'm
really
excited
to
dive
in
and
start
contributing
in
my
own
way.
So
thanks
everyone
for
just
you
know,
making
the
community
so
great.
A
F
So,
first
of
all,
I
think
I
I
saw
during
the
the
life
of
this
project
different
ways
to
to
give
feedback.
I
saw
certain
people
coming:
writing
some
small
google
docs
or
whatever
some
documents
with
the
which
incorporate
the
feedback
and
share
that
with
us
that
that's
a
very,
very
nice
way,
and
I
think
we
we
treated
all
of
them
very
seriously,
and
I
think
we
from
there
we
filed
issues
and
and
so
on.
So
we
we
took
that
in
consideration
and
I
think
go
has
a
good
experience
with
that.
F
Tyler
can
can
explain
more
about
that.
The
other.
The
other
way
that
I
saw
people
doing
this
is
via
issues
so
simply
create
issues
with
with
your
with
your
problem,
with
your
feedback.
Try
to
to
to
explain
the
problem
that
you
are
trying
to
solve
and
try
to
to
give
actionable
item
out
of
that
issue.
So
somehow
how
we
can
help.
F
I
think
overall,
any
channel
any
way
that
trans,
that
that
makes
a
transfer
or
translation
from
from
your
head
to
our
head
is
good,
doesn't
matter
how
it
is
as
long
as
we
we
transferred
this
information.
Somehow
it's
it's
very
good
and
I'm
I'm
happy
with
any
way,
but
some
some
other
maintainers
may
have
other
preference,
but.
A
Yeah,
thank
you
and
from
what
my
understanding
is.
There's
there's
the
getter
get
get
channels
for
each
language
and
and
the
different
sigs,
and
as
well
as
the
cncf
channels,
is
that,
like
sort
of
year-round
that
you
can
participate
in
the
cncs
slack
and
ask
questions
there,
the
github
repositories
opening
issues
there
but
yeah.
I
I've
certainly
have
my
moments
where
I'm
just
like
man.
A
C
C
E
One
one
small
comment
on
github
usage:
please
use
the
public
runes
the
direct
messages
they
are.
They
are
not
visible
to
anyone
else.
Right,
obviously,
you'd
want
to
use
that
if
it's
something
you
want
to
keep
confidential.
Otherwise,
please
use
the
public
room,
so
there's
visibility
for
everyone
else.
Others
can
participate
as
well
and-
and
you
can
you're
also
very
welcome
to
come
to
the
sig
meetings.
They
are
open
for
participation.
E
A
Apologies,
I
had
the
wrong
window,
clicked
technical
difficulties.
Here's
my
next
question,
though
I
know
I
know
lots
of
people
have
been
talking
about
this
today,
but
my
question
started
out
is
how
do
you
see
open
telemetry
evolving
over
the
next
year?
But
I
think
I
really
want
to
know
is
what
what's
the
most
excited,
most
exciting
evolution
besides
ga
or
besides
your
release
candidate,
that
you're
excited
about
in
this
upcoming
year.
G
So
I
think
one
of
the
things
I'm
most
excited
about
is
seeing
what
the
the
end
user
community
does
once
they've
got
a
ga
release
that
they
feel
comfortable
taking
and
running
with.
We've
got
a
lot
of
great
instrumentation.
That's
been
added
to
the
go
contrib
repo,
but
I
think
it
covers
just
a
tiny
slice
of
what's
out
there,
and
so
I'm
really
interested
to
see
how
people
instrument
other
libraries,
what
libraries
they
instrument
and
and
where
it
goes
once
we
hit
that
real,
taking
off
point
of
having
a
ga
release.
E
I'd
like
to
expand
a
bit
on
what
anthony
said,
I
think
it's
very
important
for
us
once
one
point
always
released
to
focus
on
our
attention
and
actually
making
open
telemetry
popular.
We
want
that
inflammatory
to
be
widely
used
right.
I
want
to,
I
personally
want
to
see
every
software
library
every
piece
of
popular
software
database
management
system,
web
frameworks
to
to
have
to
be
instrumented
by
mobile,
telemetry
right
and
and
so
that
that
instrumentation
is
also
maintained
as
a
first-class
capability
by
the
authors
of
the
library
and
the
film
framework.
E
Obviously
this
is
a
very
big
goal
right.
It
will
take
years
to
be
there,
but
I,
I
think
it's
very
important
for
us
maintainers
contributors
to
open
telemetry,
to
to
think
about
this
and
make
this
about
our
vision.
We
want
to
make
sure
that
open
planetary
is
attractive
to
developers.
It's
easy
to
use,
so
we
we
need
to
spend
time
on
popularizing
our
contention
to
sellers.
F
Net.Net
shipped
with
open,
telemetry
or
a
subset
of
open
telemetry,
and
they
keep
adding
new
functionality
the
other
by
the
way,
another
work
that
we
did
was
with
the
spring
community,
with,
with
the
spring
salute
community.
Thanks
to
to
marching
one
of
the
the
maintainers
of
the
spring
tracing
artifact
there.
He
he
made
a
huge
contribution.
A
B
Right,
sorry,
I
didn't
to
cut
you
off.
I
think
we
also
have
contributions
in
the
the
go
redis
library
itself
directly,
which
was
a
really
awesome
thing
to
see,
and
it's
a
pretty
cool
just
to
see.
Like
a
you
know,
very
organic
adoption
at
that
level
and
that's
in
addition
to
all
the
contrib
repos
that
we
host
internally,
which
are
essentially
plug-in
models
which
have
also
seen
contributions
from
outside
developers
to
help
progress.
Those
so
you're
getting
a
lot
of
community
involvement
there
as
well.
C
D
F
Yeah
talking
about
vendors,
this
is
a
good
point,
I'm
starting
to
see
more
and
more
vendors
trying
to
make
the
canonical
way
a
recommended
way
to
be
open,
telemetry,
which
means
more
and
more
contributions
will
come
to
the
to
the
project,
because
once
a
vendor
starts
selling
this,
they
have
to
to
contribute
more.
They
have
to
make
it
more
robust,
they
have
to
increase
quality
and
everything.
So
I
think
this
is.
This
is
definitely
a
good
point.
B
Yeah,
I
just
kind
of
wanted
to
to
go
back
to
the
original
question
of
also
like
how
we
see
it
evolving.
I
think
that
we've
done
a
really
good
job
talking
about
like
how
we
see
the
code
evolving,
but
I'd
love
to
kind
of
just
follow
on
what
bogda
was
kind
of
leading
into
it.
As
like
I'd
love
to
see
that
community
become
you,
know,
bigger
and
continue
on
in
its
path
to
the
inclusivity
that
we
try
to
engender
in
our
community.
I
think
that's
a
really
awesome
thing.
C
A
And
then
we
have
a
question
for
the
audience
and
I
would
love
to
get
some
answers
in
the
chat.
What
do
you
want?
What
do
you?
What
do
people
want
to
see
from
the
project
in
the
next
year
that
that
you
haven't
heard
about
today?
What
is
something
that
you're,
just
like
itching
for
to
for
the
maintainers
to
start
prioritizing.
A
Well,
I
know
my
answer
is
more
sort
of
like
introductory
materials
or
like
helping
helping
people,
especially
you
know
whether
you're
developers
or
infrastructure
engineers,
or
whatever,
like
you
probably
haven't,
had
to
think
about
instrumentation.
This
way
before
or
a
lot
of
people
have
a
lot
of
people.
Don't
have
experience
with
this
sort
of
thing
and
what
I've
found
in
the
observability
community
is
we're
very
good
at
talking
about
instrumentation
we're
very
good
about
talking
about
telemetry
and
most
of
our
end
users.
A
Don't
think
about
that
every
day
right,
and
so
we
tend
to
be
very
focused
on
that
part
and
and
less
able
to
like
reach
out
to
the
people
who've.
You
know
this
isn't
their
day-to-day
work,
and
now
I'm
seeing
lots
of
answers
in
the
chat.
So
I
will.
I
will
read
those
loud
so
liz
fong
jones.
My
colleague
feels
that
we
need
to
do
more
outreach
workshops
now
that
the
api
is
stable
and
that's
something
that
that
we've
been
working
on
austin
and
liz.
A
F
G
Yeah,
I
can
say
from
the
end
user
perspective
and
getting
an
organization
on
board
the
two
things
that
I
found
critical
were
one
making
it
as
easy
as
possible
for
the
developers
to
get
started,
and
I
think
some
of
the
vendors
are
starting
to
go
down
this
path.
With
the
distributions
concept
of
you
know,
here,
here's
an
easy
way
to
get
everything
configured.
G
I
ended
up
internally
writing
a
set
of
libraries
that
made
it
easy
for
you
to
hand
us
an
http
handler
and
you
get
back
a
server
that
is
instrumented
and
all
of
the
trace
providers
and
metric
providers
are
configured
for
you.
So
it
becomes
very
easy
for
a
developer
to
take
an
existing
service
and
get
it
onboarded,
and
the
second
thing
is
showing
them
the
value
showing
them
why
they
want
to
go
in
and
add
their
own
custom
spans
and
attributes
to
those
spams.
G
We
were
working
on
some
back
end
services
and
things
were
fairly
opaque
to
to
the
end
users,
but
I
was
able
to
say:
okay,
you
had
a
question
about
how
this
was
working.
Why
this
happened?
I
can
now
show
you
here's
a
jager
waterfall
view
where
I
can
show
you
all
of
the
things
that
this
request
did.
While
it
was
processing
and
here's
how
it
ended
up
getting
to
that
result,
and
not
only
the
end
users,
but
also
developers,
then
we're
like.
Oh.
B
G
A
B
I
I
could
take
a
stab.
I
think
I
think
this
is
in
the
go
space
just
based
on
some
terminology
and
some
of
the
known
issues
that
we
have
there
in
the
github
org
yeah.
So
one
of
our
things
is
obviously
in
go.
It's
a
very
concurrent
language
and
in
a
lot
of
other
languages,
like
concurrency
patterns,
are
really
important
for
performance,
let
alone
just
overall
programmability
and
support
across
like
other
applications.
B
A
If
you
want
to
start
supporting
supporting
open
telemetry
for
for
users
more
easily
like
how?
How
can
on
the
on
the
product
side
like?
How
can
you
prioritize
like
otlp,
is
a
good
idea?
We
want
to
support
that
natively
and
then
what
advice
would
you
give
as
well
for
actually
sitting
down
and
implementing
it?
What
what
what
should
people
expect.
E
That,
on
the
tracing
side,
I
would
say
it's
relatively
straightforward,
because
the
the
mental
model
of
the
traces
or
spans
in
otlp
is
quite
similar
to
what
other
protocols
are
using
jager
or
consensus.
There
is
no
mismatch
or
surprising
new
semantics
or
concepts,
or
very
little
of
anything
that
is
completely
new
in
oklahoma's
portion
of
it.
E
If
you're,
if
you're,
especially
if
you're
familiar
with
a
particular
protocol,
you
can
have
a
look
at
the
translations
codes
in
the
in
the
optical
energy
collector,
which
will
show
you
precisely
how,
for
example,
jaeger
concepts,
map2
or
otp
concepts
from
traces
for
metrics.
It's
a
bit
more
complicated.
If
you,
if
you
were
in
the
presentation
that
josh
gave
earlier,
there
is
going
to
be
more
complications,
particularly
coming
from
the
fact
that
there
is
more
new
types
of
metrics
available
in
open,
telemetry
and
and
correspondingly
in
rtl
key,
which
have
different
semantics.
E
So
that
may
require
your
back
end
to
to
be
expanded
right
to
support
those
those
types,
those
types
of
metrics.
I
think
we
will
have
more
clarity
on
that
when
the
specification
on
the
metrics
is
finalized
and
I
think
the
matrix
it
will
have.
You
have
also
probably
the
recommendations
and
definitely
there
will
be
clear
semantic
definitions
in
the
specification.
What
the
what
the
particular
metric
types
are
intended
to
reflect
and
that
will
drive
your
implementation
in
the
metric
portion.
F
My
two
cents
here
by
the
way,
if
somebody
would
start
a
completely
new
open
source
backend
for
for
all
these
three
pilers,
that
we
we
produce
matrix
traces
logs.
I
would
encourage
them
to
start
thinking
from
the
what
we
call
resource
perspective
so
model
from
the
resource
and
then
from
there.
They
can
use
their
imagination
to
to
build
the
ux
experience,
but
that
would
be
just
a
free
advice
for
for
somebody
who
who
wants
to
to
build
the
new
open
source
backend
about
this.