►
From YouTube: 2021-12-16 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
C
A
C
So
a
couple
prs
I
need
to
sign
up.
Is
this
hugo
one?
C
C
C
Cool
all
right,
so
nothing
huge
pr
wise
we're
waiting
on
issues
the
biggest.
C
So,
to
kind
of
catch
people
up
philip
from
honeycomb,
worked
on.
He
made
a
bunch
of
issues
for
this,
which
is
the
ones
from
like
two
weeks
ago,
which
was
documentation,
tasks
that
they'd
kind
of
done.
Some
feedback
gotten
some
feedback
from
users
who
were
trying
to
use
the
hotel
docs
and
found
like
conceptual
content
that
didn't
exist
in
our
docs.
B
C
C
C
Yeah,
it's
like
you're
gonna,
put
the
docs
content
somewhere
else
right,
phil,
oh
philip,
is
coming.
Let
me.
B
So,
while
we're
waiting,
yeah.
A
A
Like
peanut
butter
cups,
oh.
B
C
B
A
Not
right
now,
I'm
I'm
with
new
relic.
I
just
joined
the
open
telemetry
team
a
few
weeks
ago,
and
so
I
kind
of
just
wanted
to
attend
some
cigs
and
just
kind
of
meet
people
and
see
what
people
are
talking
about.
Yeah.
C
Nice
yeah
yeah
from
introductions
of
my
part,
I'm
austin.
I
work
at
lightstep
and
I'm
kind
of
the
maintainer
of
the
website,
although
I
should
point
out
that
I
am
not
like
irrevocably
attached
to
that
title.
I
just
sort
of
fell
into
it,
because
I
was
the
maintainer
of
the
open
tracing
website
and
yeah.
The
big
kind
of
things
were
we're
working
on
are
the
big
big
thing.
C
We're
working
on
right
now
is
trying
to
get
a
unified
information
architecture
for
the
site
for
the
docs
on
the
site,
with
the
eventual
goal
of
next
year,
at
least
or
kind
of
the
vision
for
the
site.
Right
now
is
that
the
problem
we
run
into
is
that
everyone
all
of
our
lovely
employers,
except
patrice's?
C
I
guess
all
decided
to
land
rush,
open,
telemetry
keywords
on
google
and
kind
of
do
their
own
open,
telemetry
docs,
which
is
great
in
terms
of
hey,
there's
a
bunch
of
people
adopting
this,
but
not
great
in
terms
of
kind
of
giving
people
a.
C
And
hopefully
that
means
that
all
of
the
wonderful
vendors
that
support
open
telemetry
are
freed
up
from
having
to
kind
of
do
a
lot
of
duplicate,
duplicate,
duplicative,
work,
writing
plain
old
docs
and
can
just
refer
their
customers
to
the
open,
telemetry
docs,
and
then
they
can
keep
whatever
specific
kind
of
stuff
that
they
need
for,
like
here's,
how
you
use
open
telemetry
with
us.
So
here
you
know,
lightstep
could
have
here's
the
stuff
you
need
to
know
about
using
opensunday
lightstep
and
the
new
reality
could
have
here's.
C
What
you
need
to
know
about
using
opengl
with
new
relic
and
honeycomb
could
have
done
right.
So
that
a
lot,
but
if
you're
not
using
those
and
you're
using
just
completely
open
source
stuff,
then
we
will
make
sure
that
you're
getting
the
same
quality
of
docs
as
someone
that's
using
a
vendor
or
a
commercial
solution
right.
So
that's
kind
of
the
big
picture,
vision.
C
All
right,
thank
you,
so
yeah,
hello,
philip,
we
were
just
introducing
ourselves
to
rhys.
D
C
On
yeah,
so
I
was
just
getting
patrice
up
to
speed
with
the
issues
you
opened
about
sort
of
the
doc
gaps.
Those
are
all
pretty
rad.
C
Yeah
I
and
then.
C
There's
a
topic
on
here
about
proposed
outline
from
the
ruby
folks.
Does
anyone
know
what's
up
with
that.
D
Yes,
I
put
that
on
there
yeah
so
so
two
weeks
ago,
when,
when
you
sort
of
highlighted
like
the
four
areas
and
like
that
spreadsheet
square
card,
we're
like
hey,
these
are
probably
like
a
first
set
of
like
issues
to
just
go
after
that's
what
I've
been
doing
and
which
should
this
come
as
no
surprise
to
anyone.
Every
language
repo
has
their
own
quirks
about
how
they
handle
docs
and
on
the
hotel,
ruby
side.
D
There
there's
kind
of
like
an
information
architecture
there
that
I
very
much
don't
agree
with,
but
I
can
see
why
they
want
to
keep
it
until
there's
like
a
full
proposal
for
like
what
the
shape
of
the
language
sdk
doc
should
look
like
and
so,
rather
than
like.
Try
to
force,
like
my
opinion,
on
of
of
like
what
that
should
look
like
into
a
pull
request.
That
is
about
like
updating
how
you
get
a
current
span
or
something
like
that
chatted
with
just
on
github,
ariel
or
ariel.
D
I
don't
know
how
he
pronounced
the
name,
but
about
that
and
sort
of
his
feedback
was
hey.
I
am
down
for
any
and
all
like
changes
that
that
try
to
make
the
structure
better
and
try
to
you
know
make
introducing
these
concepts
better
to
people.
D
There
was
a
first
stab
at
that
that
he
and
somebody
else
took
like
many
months
ago
and
it's
sort
of
what
they
arrived
at,
and
he
thinks
that
like,
if
there's
a
pretty
rough
like
outline
of
how
it
should
generally
look
for
each
language,
then
he's
open
to
making
that
adjustment
on
the
ruby
side,
but
until
such
a
time
he
kind
of
wants
to
hold
off
on
like
adding
a
whole
lot
of
concepts
and
like
potentially
ordering
them
a
little
bit
differently.
D
So
like,
for
example,
today
span
events
are
like
called
out
very
prominently
on
the
ruby
docks,
but
creating
a
span
is
not,
and
I
feel
like
that
should
probably
be
inverted,
but
that
then
calls
the
question
of
okay.
Well,
what
should
we
call
out?
First,
like?
Should
we
lead
with
auto
instrumentation?
First,
should
we
lead
with
like
just
a
console
span
exporter
that
creates
a
single
span
first
and
then
go
into
auto
instrumentation
and
and
so
on.
So.
C
Yeah,
I
could
have
sworn
I
had
put.
C
So
in
last
year,
wow
last
year,
I
did
a
template
or
suggested
kind
of
template
for
how
to
do
for
basically
that
for
like
what
should
be
in
kind
of
the
each
thing
if
we
wanted
to,
we
could
actually
work
off
of
these
templates
and
turn
in
terms
of
making
issues
and
making
edits
to
them
so
that
at
least
there's
something
to
start
off.
C
More
obliquely
like
we,
this
isn't
a
churrocracy
and
we're
not
going
to
be
able
to
get
absolute
consensus
from
every
single
sig
on
one
thing
like
there's
going
to
be
winners
and
losers
and
there's
going
to
be
like
whatever,
but
we
need
to
figure
out
what
is
kind
of
the
minimal
set
or
maybe
not
middle
minimal
set.
I
would
actually
say
like
what
is
the
maximum.
C
Point
solutions
right
that
we
need,
because
my
thought
was,
is
you
know
the
the
line
I've
taken
with
what
I
kind
of
I
think
wrote
in
that
java.
Docs
comment
was
basically
look
really.
All
of
your
docs
should
be
here
in
the
website
repo,
if
you're
already
gonna
have
you're
gonna
split
your
stuff
out
anyway,
and
the
argument
for
well
maintainers
just
need
one
thing
to
check
out
or
what
people
just
need
one
source.
It's
like
well,
okay,
they're,
not
going
to
have
that
at
this
point
anyway.
C
D
C
B
C
B
I
mean
that
reminds
me
that
when
I
had
met
with
ted
earlier
on,
maybe
a
couple
of
months
ago
he
had
opinions
about
what
the
introductory
material
should
look
like.
So
I
don't
know,
has
he
weighed
in.
B
B
My
feeling,
philip,
was
that
initially
you're
identifying
holes
in
the
documentation
and
trying
to
add
content,
and
I
think,
as
you
know,
there's
we
have
site
information
architecture,
rework
issue
in
in
progress.
B
D
That
yeah,
that's
that's
sort
of
it.
There
was
ariel,
was
saying,
like
he
had
a
little
bit
of
hesitation
on
about
expanding
the
manual
instrumentation
dock
to
because,
like
so
there's
plenty
of
gaps
on
that
side
about,
like
just
general
things
that
you
can
do
that
people
tend
to
want
to
do
and
so
he's
like.
D
Well,
you
know
we
basically
he's
like
okay,
so
the
philosophy
that
we
have
so
far
is
push
people
towards
automatic
instrumentation
first,
and
that
should
suffice,
like
they
shouldn't
need
manual
instrumentation
for
pretty
much
most
cases.
I
would
disagree
with
that,
but
that's
that's
their
position
and
then
and
then
number
two
in
priority
order
is
explaining
what
context
propagation
is.
I
thought
that
was,
I
think,
like
that's
valuable,
but
I
thought
it
was
also
a
little
strange
because
it's
turned
on
by
default,
and
so
it's
like
you
do
you.
D
D
Oh,
I
want
to
write
some
logs,
but,
like
you
know,
we
should
push
them
towards
span
events
instead,
instead
of
that
which
I
I
could
potentially
see
that
and
then
finally
getting
into
manual
instrumentation,
and
so
he
sounded
pretty
open
to
switching
that
around.
But
he
wanted
that
to
be
like
more
of
a
formal
proposal.
Rather.
A
D
Just
somebody
coming
in
and
adding
a
whole
bunch
of
content
to
the
thing
that
he
thinks
is
like.
Fourth,
on
the
priority
list.
B
Are
that
makes
sense,
makes
a
lot
of
sense
and
I
think,
as
austin
was
pointing
out,
we
may
not
have
to
have
or
expect
to
have
uniformity
across
all
language.
Sigs.
C
I
can
historically
for
some
historical
context,
like
I
can
tell
you
what
our
thought
process
was
when
we
did
open
tracing
docs
in
a
very
broad
sense.
We,
the
project
kind
of
felt
like
the
that
developer,
that
a
developer
audience
expected
to
go
and
find
some
code
that
they
could
kind
of
copy
and
paste
and
run
right.
So
a
lot
of
the
like
how
do
these
docs
get
written
was
from
from
the
standpoint
of
okay.
I
heard
this
open
telemetry
thing.
I
want
to
go,
write
some
open,
telemetry
code.
I'm
sorry!
C
You
know
I
was
like.
Oh
I
heard
of
this
open
tracing
thing.
I
want
to
write
some
open
tracing.
You
know
that
had
a
lot.
There
was
a
lot
of
like
problems
with
that
approach,
but
that's
what
led
that
that's
kind
of
where
you
got
to
the
okay?
Well,
the
first
thing
you
do
is
create
a
span.
Now
you
gotta
span,
that's
the
building
block.
C
Now
you
can
add,
you
know
logs
and
tags
to
it,
and
then
you
gotta
end
the
span
and
then
you
have
to,
but
before
all
that
you
got
to
create
a
tracer,
because
you
need
to
actually
have
something
right.
So
there
was
that
kind
of
iterative
you
need
to
do
x,
then
you
need
to
do
y.
Then
you
need
to
do
z
and
at
the
end
of
it
you
press
run
and
you
get
a
span.
C
It's
a
lot
easier
to
kind.
You
know
that
elides
so
many
of
the
details
that
it
and
it
makes
it
easy
to
you
know
it
shortens
the
time
to
value
or
whatever,
because
just
like
okay,
you
go
in
you
import
this
stuff,
you
add
a
console
logger
and
then
you
press
run
and
you
look
in
your
console
and
hey
here's
all
these
spans
that
you
created
yay,
yay
right
like
good
on
you,
you've
done
something
and
you've
proved
that
it
works.
C
I
think
where
it
gets
tricky
is
that,
like
you
said
I
don't
I,
I
would
tend
to
maybe
disagree
a
little
bit
on
like
the
importance
of
like
manual
span
creation.
You
know
creating
your
own
spans
and
janitoring
those
I
would
also
say
like
well.
If
that's
you
know
from
that
logic,
isn't
it
actually
more
important
to
talk
about
intra
process
propagation
rather
than
extra
process
right,
because
I,
if
I'm
using
auto
instrumentation
for
my
servers
and
clients,
then
context
prop's
handled
for
me.
I
don't
need
to
worry
about
that,
but
I
do.
C
To
pass
context
from
function
a
to
function
b
so
that
I
can
create
a
new
span
in
function
b,
et
cetera,
et
cetera,
et
cetera,.
C
C
There's
a
lot,
there's
an
infinite
amount
of
devils
and
an
infinite
amount
of
details,
because
that
exact
thing
is
so
different
from
language
language
language
like
if
and
that
I
don't
think
we
have
a
good
answer
to
is
how
do
we
come
up
with
something
that
encompasses
the
breadth
of
how
you
do
that
in
12
different?
D
Yeah,
it
kind
of
makes
me
wonder
if
so,
I
think
there
there's
definitely
a
lot
of
benefit
to
consistency,
because
a
lot
of
devs
are
writing
in
multiple
languages,
and
so,
if
they're
used
to
one
way
of
looking
up
how
to
do
something
in
one
language,
they
go
to
the
docs
for
the
other
one
and
like
the
structure
is
pretty
similar.
Like
okay
cool,
I
I
know
the
concept.
I
just
need
to
know
like
what
what
the
code
looks
like
here.
D
They
can
find
it,
but
the
getting
started
thing
is
totally
gonna
vary
from
language
to
language
like
go
being
super
explicit
and
ruby
being
like
as
automatic
as
possible.
Definitely
present
different
philosophies
on
how
you
get
stuff
done.
I
think-
and
I
would
definitely
like
I
would
personally
look
for
the
language
sig
maintainers
to
like
provide
what
they
think
the
best
entry
point
is
for
that
kind
of
stuff.
D
But
then
I
would
perhaps
propose
that
like
when
it
gets
into
the
nitty-gritty
of
using
the
open,
telemetry
apis
to
do
stuff,
there's
just
sort
of
like
a
set
structure
in
terms
of
how
it's
presented
in
the
docs
and,
like
you
know,
maybe
one
is
like
more
used
in
one
language
than
another
in
another
language,
but
at
least
it's
like
very
easily
searchable
and
findable
across
languages.
B
In
the
meantime,
and
then
just
see
what
how
many,
whether
ruby
is
that
exceptional
or
not,
and
if
we
get
10
out
of
12
languages
that
want
to
do
things
their
own
way,
then
maybe
that'll.
That
proposal
won't
work.
But
if,
if
there
is,
you
know
80
of
the
languages
that
it
makes
sense
to
have
the
same
structure,
even
though,
as
you
point
out,
the
emphasis
could
be
different
per
language.
B
C
Else,
actually,
I
had
a
question
for
you
patrice.
How
flexible
are
we
about
all
right?
I'm
I'm
pretty
sure.
The
answer
to
this
is
that
hugo
is
that
it's
pretty
straightforward
to
modify
templates
down
a
pat
or
modify
yeah
modify
templates
down
a
path
in
hugo,
so
you
could,
for
example,
have
a
wildly
different
templating
and
document
types
for
ruby
pages
versus
javascript
pages.
B
I
think
so
so
we
can
set
up
layouts
per
section
and
we
can
drill
down
as
specific
as
we
need
to
yeah
for
a
section
to
create
templates.
C
I'm
sure
amy
will
yell
at
me
at
some
point.
Intricacies.
B
C
Yeah,
I'm
just
thinking
like
if
you
spin
this
out
far
enough
and
you
get
like
really
specific
requests
from
like
well.
We
need
to
we.
We
want
our
section
to
look
this
way
or
like
we
need
something.
That's
not
just
content
but
display
driven
an
example
might
be
not
necessarily
code.
Not
code
blocks
are
highlighting,
but
things
like
tabs,
although
I
think
we
have
tabbed
blocks
yeah,
so
that
wouldn't
be
a
huge
thing.
C
A
C
Like
we
should
strive
to
have
some
level
of
consist
like
we
should.
Consistency
is
a
virtue
here
that
the
more
we
can
make
everything
the
more
that
the
same
information
can
appear
in
the
same
general
place
regardless
of
the
language.
C
D
Okay,
so
I
I
do
I
so
I
do
like
the
idea
of
not
spending
too
much
time
on
the
ruby
side
right
now,
largely
because
I've
found,
especially
with
java
and
javascript,
it's
really
easy
to
just
add
more
content
and
get
it
updated
and
get
it
viewed
and
so
forth.
And
if
there's
like
a
pretty
consistent
structure
between
the
two,
it
seems
like
that'll,
probably
happen
with
go
as
well
and
start
getting
into
the
weird
ones
with
like
python,
where
it's
just
hosted
on
a
totally
different
site.
But.
C
D
It's
it's
it's
one
of
those
where
I
found
so
far.
It's
really
easy
to
just
to
like,
add
and
modify
content
like
they're,
really
quick
to
approve
and
eventually
merge,
but
yeah.
The
format
is
gonna,
look
different
and
all
that
stuff,
but
at
least,
if
we
get
three,
I
think
that
have
a
pretty
consistent
structure
on
the
hotel
site,
then
anything
that
that
is
either
directly
in
the
hotel
site,
repo
or
sub
modeled.
In
there's
a
pretty
strong
argument
to
say
that
you
know
they
should
all
follow
it.
Roughly
the
same
structure.
A
C
Say:
look:
here's
exactly
what
we're
wanting
here's,
why
you
know
and
then
your
code
samples,
whatever
else
put
those
wherever
you
want
them,
they
can
be
in
your
main
repo.
They
can
be
in
a
separate
repo.
We
don't
care,
but
your
docs
should
be
here.
They
should
live
here.
We
have
versioning
for
them.
We
can
translate
them.
C
C
C
I
look
very
charming
right
now.
I
think
that's
a
good
discussion,
though,
does
anyone
else
have
anything.
B
I
was
just
looking
quickly
at
analytics
to
see
whether
that
could
help.
I
don't
know
if
you'd
be
interested
in
getting
some
feedback
there,
philip,
I
think
when
I
had
ordered
the
get
started
buttons
on
the
home
page.
It
was
in
the
order
suggested
by
the
analytics,
so
you've
been
working
on
java
and
javascript.
B
C
C
D
Yeah
I'd
say
so.
I
also
wonder
if
there's
similar
data
in
the
the
honeycomb
instance
that
we
have
set
up
that
slurps
in
some
of
the
there
is
like
stuff
yeah,
but
it's
probably
nowhere
near
as
good
as
an
analytics
tool.
Yes,
yeah.
C
C
Yeah,
it
would
be
good
to
have
someone
other
than
me
and
you
on
that.
Just
because
also
philip,
are
you
you're
not
on
the?
Are
you
on
the
tee.
C
C
B
C
Thing
so
next
january,
let's
talk
about
getting
some
more
people
in
as
approvers,
and
so
that
that
can
I
can
be
less
of
a
block
there.
Next
meeting
will
be
canceled.
This
is
the
30th
enjoy
the
holidays.
Reese.
Thank
you
for
coming.
It's.
I
would
like
to
say
it's
not
normally
like
this,
but
this
is
usually
how
these
things
go.
Just
a
lot
of
rambling
but
purposeful,
rambling,
and
if
you
want
to
come
back,
we
would
love
to
have
you.