►
From YouTube: 2022-01-27 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
A
A
Let's
go
hello,
hey
ted,
I
guess
we'll
go
ahead
and
get
started
and
phillip
will
join
and
we
can
kind
of
jump
to
his
agenda
item.
Okay,.
A
D
B
Yeah,
not
in
quite
a
while
hi
it's
nice
to
meet
you
do
I
pronounce.
Your
name
is
patrice.
D
B
I
can
kick
it
off
hello,
so
I
have
been
working
with
a
couple
of
folks
on
just
the
concept
of
how
to
provide,
like
some
good
community
community
op
opportunities
for
collaboration
with
end
users,
who
don't
have
some
of
the
like
resources
or
time
to
really
ingrain
deeply
within
any
particular
open,
telemetry
sig.
B
And
so
I
am
here
because
I
was
chatting
over
my
proposal
with
ted,
and
he
let
me
know
that
a
lot
of
some
of
the
work
that
I
was
trying
to
do
falls
within
the
communication
sig
and
we
would
have
a
lot
of
coordination.
And
so
I
put
a
link
to
the
issue
on
github
in
the
meeting
notes
and
just
kind
of
wanted
to
talk
through
what
I'm
thinking
and
what
you're
thinking
and
how
we
might
work
together
on
it.
A
Yeah
has
that
just
out
of
curiosity
has
everyone
else
read
or
everyone
that
cares
to
read
the
proposal?
Have
they
read
it
yet
I
know
ted
has.
I
have
teresa.
E
B
Okay,
so
I
mean,
I
think,
fundamentally,
one
of
the
goals
really
is
to
help
make
open,
telemetry
more
accessible
for
end
users,
and
so
there's
some
potential
examples
of
work
streams
that
could
be
helpful.
Some
of
them
fall
under
communication
sig.
Today,
some
of
them
don't
fall
under
anywhere
within
the
open,
telemetry
community
yet
but
might
fall
under
like
at
the
cncf
level.
I've
tried
to
chat
with.
B
B
Okay,
but
we
haven't
been
able
to
connect
on
this,
because
I
know
that
cncf
has
an
end
user
group
as
well,
but
I
think
this
is
really
more
specifically
targeted
towards
users
of
open
telemetry
specifically
and
as
an
emerging
tech,
at
least
the
the
origins
of
this
is
I
work
in
new
relic.
B
A
Yeah,
my
only
my
comments
are
just
like
yeah
two
thumbs
up.
I,
this
is
some
stuff
that
I
had
really
well
when
we
originally
rebranded
the
website
sig
to
comms,
you
know,
sig,
comms
or
whatever,
like
a
lot
of
the
things
you've
pointed
out,
are
super
in
that
mission
statement
or
in
sort
of
a
portfolio
we
we
I
outlined
when
that
happens.
So
I'm
glad
to
see
someone
taking
some
initiative.
A
I
tend
to
agree
with
you
that,
like
we're
targeting
something
slightly
different,
like
I
think
the
cncf
end
user
groups
tend
to
be
a
bit
more
like
maybe
a
level
up
or
two
from
where,
like
they're,
not
it's
not
really
the
practitioner
level.
Necessarily
it's
more
at
the
like
leadership
level.
I
don't
know
ted.
Would
you
I
think,
that's
an
accurate
characterization,
but
you
might
have
a.
E
Yeah
yeah,
I
think
I
think
that's
that's
accurate
like
when,
when
it
comes
to
to
end
users,
we
there's,
like,
I
think,
like
a
a
couple
places
we
we
tend
to
want
to
point
them,
and
so
far
when
it's
been
like
hey,
we
have
like
a
bunch
of
feedback.
We
want
to
give
the
project.
It's
usually
been
the
governance
committee
that
has
you
know
basically
set
up
a
a
private
meeting
with
that
group,
and
you
know,
heard
their
thoughts
and
issues
with
adopting
open,
telemetry
and
have
tried
to.
E
Then
you
know
funnel
all
that
feedback
into
the
right
place
and
usually
involves
also
getting
that
group
involved
in
in
open
telemetry
in
some
way.
So
like
the
big
example
here
would
be
atlassian
right
where
they
were
like.
We
have
some
issues,
and
most
of
it
was
just
being
able
to
explain
to
them
what
a
road
map
was,
and
then
part
of
it
was
for
the
stuff
that
they
really
cared
about,
which
was
like
the
semantic
conventions
like
what
is
the
data
that
open
telemetry
emits
and
when
is
that
going
to
be
stable?
E
We
made
sure
that
the
group
talking
about
that
had
a
apac
friendly
time
zone
to
meet,
because
that
was
kind
of
their
big
issue
they
raised
is
like
we're
in
australia,
and
none
of
your
meetings
work
work
for
us,
so
it's
hard
for
us
to
commit.
So
that's
how
it's
been
done
in
the
past,
but
I
feel
like
there's
still
definitely
some
room
when
groups,
I
think,
want
to
have
like
a
private
meeting,
so
they
can
feel
like.
A
A
They
are
communicating
back
up
to
their
paid
support
channels
or
you
know
whoever
and
then
that
feedback
is
getting
filtered
and
drips
and
drabs
into
individual
cigs
or
to
individual
signal
maps
or
whatever.
So
I
like
the
idea
of
having
this
as
a
place
that
one
we
can
that
everyone,
I
think
it
serves
two
purposes
one.
It
takes
sort
of
the
people
that
aren't
in
that
hey.
I
I
have
a
vendor
relationship
that
can
leverage
that
I
can
leverage
to
sort
of
induce
change.
A
We
can
kind
of
give
people
that
are
outside
that
ecosystem,
a
way
to
come
in
and
have
their
voice
heard.
Secondly,
it
gives
us,
as
you
know,
gives
our
our
employers
the
ability
to
kind
of
be
like
well,
hey,
here's,
maybe
the
better
avenue,
to
take
your
feedback
rather
than
like,
expecting
us
to
solve
all
your
problems.
For
you,
the
one
thing
I
do
like
I,
I
honestly
have
no
problems
with
this
has
written
like.
I
think
the
idea
of
having
the
meetings
on
that
be
off
weeks
is
good.
I
would
actually
probably
expand.
A
Maybe
not
right
now,
but
I
definitely
expand
the
scope
of
this
to
include
things
like
hotel
tuesdays
or
if
we
want
to
do
start
doing
like
more
like
podcasts
or
other
sort
of
media
things
like.
I
think
that
this
would
be
a
great
pool
to
draw
from.
I
love
the
office
hours
idea.
The
one
thing
I
would
just
to
get
on
the
record
is
that.
A
I
do
think
there
will
be
like
I
think
we
just
have
to
be
careful
on
how
we
in
the
promises
that
we
make
to
people
that
give
their
feedback,
because
this
is
you
know
this
is
a
confederacy
of
projects.
A
Not
everyone
appreciates
that
or
likes
that
idea,
but
that's
kind
of
how
it
is
so
as
long
as
we're
not
you
know
as
long
as
we
aren't
and
I've,
but
I
think
as
long
as
we
say
like
hey
this
is
you
know
where
this
is
a
way
to
collect
all
this
stuff
right
this,
if
you're
a
maintainer
this
takes.
This
takes
the
target
off
your
back,
because
you
can
just
be
like
hey.
You
can
come
here,
here's
the
official
channel
for
this.
A
This
sort
of
aggregate
feedback
right
like
if
you
have
a
bug,
report,
cool,
that's
something
I
can
deal
with.
If
you
say
I
don't
like
it,
because
it's
the
wrong
shade
of
blue,
then
you
can
go
over
here
to
these
people
yeah
and
yeah,
hopefully,
by
being
a
funnel
for
that
they'll,
the
maintainers
will
actually
be
more
likely
to
adopt
their
recommendations
because
they
won't
be
mad
about
having
to
deal
with
the
people
that
think
it
should
be
different.
Color
of
blue.
E
Yeah-
I
guess
maybe
to
jump
in
on
that.
I
I
feel
like
it's
important,
to
try
to
point
people
at
like
the
correct
processes
within
open
telemetry
when
they
want
change.
E
Maybe
do
some
things
on
their
behalf
if
it's
like
opening
an
issue,
but
I
think
we
should
be
wary
about
saying
like
we
hear
you
and
we're
gonna
make
x
happen
when
x
is
really
something
the
governance
committee
needs
to
make
happen,
or
the
technical
committee
needs
to
make
happen.
I
think,
like
the
correct
things
to
do
in
those
situations
is
to
say,
like
that's
a
an
issue
for
this
group.
E
You
know
we'll
facilitate
you
talking
to
them,
but
you
know
you.
You
really
should
talk
to
them.
If
this
is
critical,
but
I
will
say
like
most
of
the
time
what
people
actually
really
want
is
information.
More
often
than
not
it's
not.
We
really
need
the
way
things
are
being
run
to
be
changed.
It's
more
like
we
are
confused.
E
A
Yeah
so
shower,
I
guess
from
us:
what
would
you?
What
do
you
need
for
your
next
steps.
B
B
We
we
ask
for
feedback,
but
we
don't
get
it
and
so
like
how
we
can
create
some
of
those
processes
to
help
just
bring
the
the
project
forward
and
help
focus
on
end
user
needs
and
just
get
them
the
feedback
that
they
need
to
make
good
prioritization
decisions
is
one
of
the
things
that
I
want
to
do,
and
I
think
all
of
you
have
different
perspectives
on
how
to
effectively
do
that
and
if
we
sh
how
we
coordinate
with
the
communications,
sig
and
potentially
the
technical
or
governance
committees
as
well.
C
A
Well,
I'm
totally
down
with
you
taking
the
having
specific
meetings
on
this
on
sort
of
the
off
cycle
weeks
so
and
I'll
be
happy
to
show
up
at
those.
So
you
want
to
say
your
first
one's
going
to
be
next
would
be
to
well.
Do
you
want
2
3,
or
do
you
want
2,
17
or
whatever.
B
I
think
I
was
imagining
217,
but
we
could
yeah,
let's
just
say.
A
217.
just
yeah
and
then
te
meet.
I
just
take
first
ted
ted.
Can
you
help
char
get
that
on
the
calendars
yeah.
E
Yeah
I
can
get
that
put
on
the
calendar
and
yeah.
It
would
be
great
to
I
I
see
this.
A
lot
of
this
work
is
like
closing
the
loop
on
like
the
comms
side
right,
where
we're
setting
up
making
sure
that
people
actually
like
hotel
tuesday
and
some
of
these
other
things
where
we
are
giving
out
information
and
there's
like
opportunities
for
people
to
chat
with
us
and
ask
questions
just
making
sure
like
that.
E
E
And
then
like
for
various
orgs
like
having
a
set
office
hours
they
can
come
to
is
not
always
like
that
great
for
them,
because
it's
at
a
time
they
can't
can't
make.
So
it's
just
like
it's
great,
I'm
really
happy
to
see.
You
show
up
and
there'd
be
people
like
being
able
to
like
actively
iterate
on
these
things.
E
Likewise,
I
should
mention
matt
mccleary.
I
think
I
don't
know
if
you've
seen
the
user
survey
he
put
together,
he
put
together
a
very
comprehensive
user
survey,
but
I
think
the
issue
there
is
somebody
cat
hurting
all
the
various
vendors
and
organizations
to
like
actually
hand
that
user
study
out
to
people
and
to
get
people
to
actually
fill
it
in
you
know.
The
php
group,
for
example,
did
this
and
got
a
lot
of
great
feedback,
but
you
know
it's.
A
In
the
interest
of
times
we're
coming
up
on
10
minutes,
we
do
have
other
stuff.
So
I
put
a
pin
in
this
and
then
also.
A
Chat
about
stuff
async,
so
great,
let's!
Thank
you.
No
thank
you.
I
think
this
is
gonna,
be
really
exciting.
Yeah,
let's
get
to
philip
python
doc's
refactor.
D
F
Yeah
so
yeah,
so
when
I
was
putting
together
a
scorecard
for
concepts
that
are
documented
with
a
copy-pastable
code
sample,
typically
as
it
pertains
to
tracing
across
all
the
languages.
On
the
python
side,
I
found
that
their
their
docs
on
read
the
docs
are
actually
pretty
damn
comprehensive,
they're,
just
kind
of
organized
in
an
odd
way.
I
think,
like
like
they
have
a
good
article
on
how
to
use
the
automatic
instrumentation
agent,
for
example,
but
it's
kind
of
tucked
away
and
like
I
had
two
people
be
like
hey.
F
I
don't
know
how
you
do
automatic
instrumentation
in
python,
I'm
like
oh
well,
the
article's
just
right
there.
It's
like
okay!
Well,
two
people
can
find
this
immediately
then,
like.
Maybe
it's
not
organized
correctly
and
there's
there's
like
a
lot
of
good
stuff
kind
of
embedded
in
this
umbrella
of
getting
started,
but
like
they're,
covering
very
specific
things
like
how
to
create
nested
spans,
how
to
set
attributes
on
spans
how
to
do
that
kind
of
stuff.
F
So
I
proposed
hey
well
instead
of,
like
writing
a
whole
bunch
of
new
code
samples
that
does
this.
Why
don't
we
just
shuffle
some
of
that
stuff
around
in
the
existing
docks,
because
it's
pretty
close
to
covering
everything
that
we
need
and
the
python
sig
they
met?
They
said
yep.
That
sounds
great.
I
had
like
a
proposed
outline
for
how
it
would
look
and
they
said
that
sounds
great.
Go
ahead
and
start
contributing
just
make
sure
that,
like
links
are
not
broken
or
anything
like
that,
so,
like
all
right,
sounds
reasonable.
F
The
problem
is
it's
sphynx
and
read
the
docs,
which
is
a
little
harder
to
work
with,
and
I
then
I'm
like
okay
well,
if,
if
I'm
going
to
go
on
a
little
quest
to
reorganize
all
of
their
docs
well,
we
have
this
overarching
issue
in
the
docs
repo.
That's
like
pull
the
docks
from
the
language
specific
stuff
into
the
docs
repo
and
so
like.
F
There
would
have
to
be
a
level
of
reorganization
that
that
would
have
to
happen
if
we
were
to
do
that
anyways
so,
rather
than
getting
started
with
that,
like
I
have
things
set
up,
and
I
think
I
have
the
new
package
that
allows
redirects,
which
they
don't
have
in
there.
I
figured
hey
what,
if
we
we
swoop
in
and
say:
hey,
can
we
steal
the
dogs?
F
Please,
and
I
have
not
brought
that
up
with
them
in
their
sig,
but
it
I
think
it's
an
appropriate
time
to
have
the
conversation,
because
if
I'm
gonna
churn
their
docks,
then.
F
It's
manually
maintained
the
stuff
that
is
automated,
so,
okay,
so
there's
a
couple
things:
there's
auto-gen
api,
docs
and
that's
stuff.
I
have
no
intention
of
changing.
They
have
some
conceptual
docs
strewn
about
in
an
faq
section
and
a
getting
started,
doc.
That's
really
long,
and
then
there
are
code
samples
in
there
which
are
brought
in
and
those
are
like
parsed
during
build
times
so
that
you
don't
have
broken
python
code
samples
so
like
it
would
be
a
regression
to
pull
them
in
as
markdown
from
their
perspective.
A
I
mean,
obviously,
I
think,
there's
a
consensus
among
this
group
at
least
that
we
would
like
high
level
documentation
to
live
on
the
website.
So.
A
If
you
would
like
to
start
that
issue
and
tag
me
or
ted
or
whoever
on
it
or
I
will,
we
will
gladly
go
in
and
support
you.
E
A
A
Now
your
docs
live
over
here,
but
we'll
see
yeah
totally
go
for
it.
I
would
definitely
like
make
the
proposal
and
maybe
do
a
branch.
A
Maybe
I
it
might
be
better
to
do
at
least
like
a
proof
of
concept
and
then
do
a
pr
than
like
run
a
pr
so
that
you
can
show
them
like
what
it
would
look
like,
like
you
know,
don't
fill
out
everything,
but
at
least
do
your
architecture
in
the
website
that
would
show
kind
of
like
okay.
This
is
how
everything
would
look
and
then
be
like
hey
here's,
the
netify
preview.
A
D
Believe
they
get
built,
if,
if
you
submit
it
and
let
it
go
switch
it.
A
D
D
Of
read
the
docs
is:
is
that
your
impression
phillip.
F
Yeah,
the
stuff
that
we
have
it's
an
old
copy,
the
stuff
in
read
the
docs
has
since
been
updated.
I
was
one
of
the
people
who
did
some
updates
there,
but
yeah
it's
it's
definitely
like
there's,
there's
the
autogen
api
stuff
and
there's
a
lot
and
then
yeah
there's
like,
for
example,
a
folder,
a
subfolder
called
examples,
and
each
of
those
has
like
auto
instrumentation
basic
context:
basic
tracer,
distro
django,
all
the
kind
of
stuff
that
I
think
would
make
sense
to
be
on
the
website.
D
D
D
A
Check
with
that,
it
might
be
good
to
just
have
like
a
conversation
with
at
least
one
of
the
maintainers
on
slack
or
something
to
see
what
they
think
would
be
the
most
successful
way
to
do
it
and
just
see
if
there's
like,
if
we
need
to
have
a
meeting
or
we
need
to
have
a
chat
on
slack
or
something
like.
Let's,
let's
do
that,
I
don't
really
want
to.
A
A
It's
basically
saying
like
look.
You
either
get
like
an
index
page
that
points
to
your
read
the
docs
stuff
or
you.
You
can
get
kind
of
this
other
thing
which
lets
some
of
it.
I
don't
know
if
it's
going
to
be
like.
I
know
that
read
the
docs
probably
does
like
versioning
for
them.
I
think
he
can
do
internationalization
for
them.
So
I
don't
know
how
much
interest
there
is
but,
like
I
said,
we
should
start
by
talking
to
them
kind
of
informally.
F
Yeah
yeah,
I
agree
with
that
yeah
I
just
checked
to
see
if
there's
a
spanish
version
and
there's
not
so
at
least
they're,
not
using
internationalization
for
spanish
but
yeah,
I
think
it's
a
little
more
complicated
than
the
java
side,
because,
like
the
java
side,
there
was
just
like
really
just
kind
of
a
pure
downside
to
having
those
docs
live
in
the
repo
that
they
wanted
it
to
live
in
for
a
bit,
whereas
there
are
some
clear
benefits
to
using
the
docs
system
that
they
have
today.
F
That
would
no
longer
be
present
if
it
were
markdown
files
in
the
docs
rebuild.
Now
I
would
my
belief
is
that
the
benefits
of
having
people
who
care
about
docs,
focused
on
the
doc
site
is
gonna
outweigh
those
those
other
benefits.
But
that's
certainly,
I
guess
a
nuanced
conversation
to
have
with
them
probably
best,
not
as
like
a
five
paragraph
github
issue.
A
Yeah,
I
really
do
think
we're
gonna
have
a
little
bit
more
success,
just
kind
of
with
a
soft
informal
touch
at
first
in
the
interest
of
time.
Or
do
you
have
everything
you
need
philip.
F
F
Things
over
there
and
be
like
there
you
go,
and
then
we
could
start
a
conversation
with
them.
Yeah.
A
Let's
run
through
the
issue
burn
down:
10
38.
I
assign
myself
to
that
we'll
I'll
figure
something
out.
D
E
Yes,
no,
I
realize
I
just
I
just
when
I
wipe
this
mac
put
some
default
garbage
into
my
git
config,
so
I'll
just.
E
A
Yeah,
let's
take
a
look
at
that
and
go
from
there.
A
D
Hope
things
get
better
in
terms
of
of
that.
Actually,
when
you
come
back
to
the
page.
D
We
I
go
back
to
your
main
comment,
so
you're
saying
this
might
be
a
point
of
con
contention,
my
understanding
that
it's
inaccurate
to
call
it
automatic
instrumentation,
since
it
describes
how
to
initialize
the
instrumentation
libraries
well,
how
much
more
what's
missing
so
that
it
would
actually
be
called
automatic.
Instrumentation
is
my
question.
Yeah.
F
That's
the
message
that
I
got
from
the
go
folks
when
I
contributed
to
their
docs
was
so
I
I
called
you
know:
hey
here's
how
you
do
automatic
instrumentation
for
http
calls
and
they
were
like.
No,
it's
not
automatic
instrumentation.
That's
instrumentation
libraries
like
what
do
you
mean
they're,
like
automatic
instrumentation,
is
when
you
make
no
code
changes.
These
are
code
changes
and
I
felt
like
it
was
a
little
pedantic,
but
I
wasn't
gonna
fight
that
battle
at
that
point.
So.
A
My
okay
well
as
a
person
that
wrote
the
book
and
distributed
choices,
I
don't
get
to
use
this
one
a
lot.
I
say
anything
that
involves
automatically
instrumenting
underlying
code
which
or
that.
A
I
think
automatic
instrumentation
is
like,
maybe
not
the
most
sure.
Maybe
it's
not
like
technically
correct
in
the
sense
that
it's
you're
making
zero
code
changes,
but
the
effect
is
that
you're
automatically
getting
instrumentation
by
importing
and
then
configuring
this
stuff
right
like
there
is
no.
A
There
is
nothing
so
automatic
that
it
doesn't
require
you
to
do
anything
right
like
even
a
new
relic
agent.
You
gotta
install
the
stupid
thing.
Even
I
mean
honeycomb
calls
b-lines
automatic
instrumentation,
don't
they
and
go
yeah.
F
Yeah
we
do
changes
and
well
and
and
customers
who
are
using
hotel,
refer
to
instrumentation
libraries
as
automatic
instrumentation.
A
B
A
E
I
I
lost
this
battle
within
light
step,
yeah,
it's
just
better
to
call
it
auto
instrumentation
and
then
refer.
I've
been
really
trying
hard
to
refer
to
the
individual
packages
as
instrumentation
libraries
yeah
for
what
it's
worth,
not
calling
them
plugins,
because
that
confuses
people
with
like
exporters
and
stuff
like
that.
A
Yeah
yeah,
I
think,
from
a
I'm,
pretty
sure
everything
I've
written
has
been
consistent
with
this
at
least,
and
I
haven't
written
everything.
Automatic
instrumentation
is
any
sort
of
instrumentation
library
or
an
external.
Like
I
mean
that's
kind
of
the
thing
where
you
get
like
the
python
like
python's,
auto
instrumentation
stuff
is,
like
you
run
it
as
or
or
java.
A
D
Does
that
give
you
enough
ammunition
or
or
give
you
enough,
fill
it
for
potentially.
C
D
The
title
change
so
that
again,
my
my
perspective
was
trying
to
get
some
sort
of
uniformity
and
austin
is
kind
of
confirming
that
we're
not
trying
to
to
look
only
for
extreme
automation
but
anyways.
I
like
the
way
you
characterized
it.
You
put
it
well,
and
I
think
that
would
allow
us
to
retitle
that
page
so
that
we
get
consistency
across
languages
and
we
have
automatic,
instrumentation
and
manual
instrumentation
separately.
A
Conceptually,
I
think
it's
more
important
for
someone
that's
coming
into
the
docs
without
a
bunch
of
background,
to
see
uniformity
across
all
these
different
language
verticals,
so
that
if
they
go
to
automatic
instrumentation
they're
going
to
get
the
same
result,
regardless
of
the
language
right
they're
going
to
get
something
that
makes
it
easier
for
them
to
instrument
their
code
or
instrument
library.
You
know
to
instrument
the
critical
path
of
the
code.
F
So
I
think
that
the
one
so
I
I
I'm
actually
very
comfortable
and
prefer
that
that
definition
of
automatic
instrumentation,
the
one
piece
that
I
guess
is
sort
of
weird
with
it
is
in
the
in
the
spec.
This
is
what
it
was
linked
to
saying
refers
to
cylinder
collection
methods
that
do
not
require
the
end
user
to
write
or
access
application
code
to
use
the
open,
telemetry
apis
and
that
by
definition
of
the
spec,
that
would
definitely
not
be
automatic
instrumentation.
But.
A
I
do
want.
I
want
to
point
out
one
thing,
though:
technically
you
said
open,
telemetry,
apis
and
auto
instrumentation
does
not
the
go
libraries
all
that
stuff,
even
the
dot,
even
the
java
ones,
or
the
dot
net
ones.
You're,
not
ins
like
you,
don't
have
to
interact
with
the
open,
telemetry
api
outside
of
like
the
initialization
part,
but
even
that
initialization
part
is
specific
to
the
instrumentation
library
itself,
not
to
the
underlying
into
the
underlying
telemetry
generating
feature
features.
F
A
I
mean
like,
if
you
assume
the
open,
telemetry
api
specifically
stuff
in
the
open
in
opentelemetry.api.net,
for
instance,
the
stuff
that
you
shove
in
your
asp.net.
You
know
your
in
your
core
server.
I
services,
whatever
the
hell
like
that's,
not
defined
in
the
ap
in
the
spec
api,
because
that's
an
sdk
implementation,
detail,
ergo.
F
All
right
yeah-
this
is
more
than
enough
for
me
to
yeah.
If.
A
Don't
think
of
this
from,
like
a
you
know,
step
back
from
like
technical,
correct,
maintainers
position
for
a
second
and
think
about
like
what
does
it
look
like
if
you're
a
developer
that
hasn't
heard
of
any
that's
coming
to
the
website?
Like
you,
click
on
go
and
you
see
instrumentation,
and
then
you
click
on
java.
You
see
automatic
instrumentation
and
you're
like.
Why?
Is
there
a
difference
right,
but
conceptually
these
libraries,
all
kind
of
do
all
are
meant
for
the
same
purpose.
A
Thus
you
know
we're
trying
to
we
website.
People
are
trying
to
make
sure
that
external
developers
coming
in
people
new
to
the
project
whatever
come
in
and
they
get
routed
to
the
conceptually
correct
thing,
even
if
that
means
that
some
technical
details
may
have
to
be
alighted
or
otherwise.
You
know
less
technically
correct
from
certain
perspectives.
C
A
Mine
is
getting
off
to
hell
to
start
man,
but
hopefully
they'll
figure.
Doctors
will
figure
out
what
the
hell
is
going
on.
I'm.
D
A
Yeah,
you
know
there's
a
thing
about
seven
month
olds,
there's
really
no
relaxation
time
you
don't
get
to
take
sick
days
from
your
kids
weirdly
enough.