►
From YouTube: 2021-04-29 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).
B
D
E
C
No,
I
think
we
only
went
like
10
or
15
minutes
past
when
he
left
so
yeah
yeah.
Not
a.
I
appreciate
the
time
you
can
contribute.
You
know
yeah.
I
totally
get
the
fact
that,
like
a
lot
of
people,
yeah
can't
make
this
one
and.
C
D
Hey
aaron:
well,
it's
well!
It's
early!
I
just
want
to
apologize
and
thank
you
for
you've,
been
a
really
patient
good
sport
on
that
patch
of
yours
that
got
merged.
D
I
felt
like
we
could.
We
could
easily
easily
argue
for
at
least
both
if
not
more
approaches.
So
I
it
feels
like
one
of
those
things
we'll
keep
coming
back
to
and
saying
what
do
we
decide
on
this.
A
C
Pepper
in
some
context
there
you
are
100
right,
steve
that
we
could
have
like
multiple
more
discussions
about
that,
because
we
did
in
the
original
pr
that
originally
added
like
and
they
changed
new
to
like
the
new
with
attributes
and
the
new
with
detectors
was
like.
It
was
like
this
whole
thing
like
there
was
a
large
discussion
there
as
well.
It
already
happened
so
yeah.
C
I
think
that
yeah,
it's
nice
to
have
summaries
like
aaron
kind
of
put
just
to
say
like
where
were
the
things
that
actually
led
us
to
this
discussion
and
not
like
lose
that
in
the
conversation
yeah
another
again
another
another
one
that
really
stands
out
is
the
error
options.
I
think
we
took
those
away,
and
then
anthony
pointed
out
that,
like
we're
literally
adding
back
the
same
things
now
that
we
have
like
a
different
purpose
for
him,
so
yeah
fun,
stuff
hugging,
our
get
history
yeah.
It's.
C
I
think
that
that's
like
the
understated
thing
is
that
I
remember
listening
to
a
few
talks
with
people.
I
think
it
was
like
the
go
authors
talking
like
this,
where
they
think
that,
like
you
know,
a
lot
of
people
come
to
the
community
going
like
you
know
they
made
that
choice
with
like
bias
or
some
sort
of
like
you
know,
seriously
well
understood
plan
as
to
where
it
was
going
to
go,
and
they
don't
really
quite
understand
like
how
you
know
we're
trying
to
like
figure
out
what
the
best
approach
is.
C
C
C
I
think
we're
all
set.
Actually,
I
think
we
have
a
full
with
quorum,
as
I
will
say,
well
cool,
so
yeah
with
that,
I
guess
we
can
start
to
jump
into
it.
I
wanted
to
start
off
by
going
over
the
open,
sound
stream
go
rc
project
board
at
a
high
level.
We've
made
some
really
great
progress
in
this
past
week,
down
to
five
issues
to
do
which
was
a
big
leap.
I
think
that
might
also
help
that
we
stopped
adding.
C
I
don't
think
we
added
any
more
issues
to
this,
so
we're
in
a
good
spot.
Yeah
turns
out
the
there's
two
ends
to
the
pipe
there
and
the
in
progress
on
the
three
review:
progress,
three
up
12
and
the
done
column,
so
yeah
definitely
some
activity,
fantastic
contributions
this
past
week.
So
I
appreciate
all
the
help
here
to
jump
in.
I
wanted
to
go
over
kind
of
what
we've
been
doing
over
the
past
few
weeks
seems
to
be
pretty
helpful.
C
This
one
I
want
to
talk
about
in
a
little
bit
as
a
separate
agenda
items.
Maybe
we
can
kind
of
go
down
the
list
here
of
things
that
are
actively
in
progress.
I
know
some
of
these
are
just
moving
in
so,
and
one
of
them
might
actually
be
able
to
leave.
So
I
want
to
make
sure
this
is
clear.
I'm
still
working
on
this.
I'm
not
gonna
open
this
up,
because
I've
gotten
done
this
choice.
Two
weeks
in
a
row,
it's
a
big
issue.
C
It's
been
well,
it's
gone
for
quite
a
long
time,
I'm
still
working
through
a
lot
of
the
details
and
the
changes
here.
This
issue
here
was
actually
split
off
from
the
changes
that
were
originally
included
here.
So
I'm
trying
to
break
this
off
into
like
participle
things
and
looking
at
some
like
alternatives
or
looking
at
some
like
I've
gone
through
these
changes,
probably
five
times
now
so
yeah,
I'm
still
thinking
about
them,
as
I
want
to
like
before.
C
I
want
to
submit
them,
but
hopefully
have
something
out
within
this
next
week
to
resolve
this
issue.
I
think
that
we're
pretty
close,
if
not
there,
to
get
an
issue
out
to
result
or
get
a
pr
out
to
resolve
this.
C
With
that
said,
you
can
jump
into
this
issue
here
aaron
and
you
had
this.
I
wanted
to
double
check
if
this
is
still
needs
to
be
open
or
if
we
can
resolve
this.
C
So
I
thought
too,
I
just
wanted
to
double
check.
I
feel
like
I
should
know.
Given
I
opened
this.
Oh
yeah.
Definitely
I
think
so.
Yeah
that
looks
like
you
should
resolve
it.
C
Oh
man,
these
are
ones.
I
don't
know
whether
I
should
be
crying
or
laughing
yeah
definitely
have
like
a
little
construction
logo
in
there,
as
well
with
emoji,
cool
and
then
anthony.
I
just
saw
you
just
oh
move
this
into
the
in
progress
columns.
I'm
guessing
you
just
started
this.
If
you
have
any
look
at
this
already
put
up
a
pr.
F
Okay
about
30
seconds
before
joining
the
meeting,
largely
this
is
just
copied
some
stuff
in
from
the
spec
regarding
the
spain
creation
process,
to
make
it
clear
that,
since
we
have
an
explicit
context,
we
construct
a
new
context
with
the
span
and
how
the
the
span
parent
will
be
determined.
If
there's
one
in
the
past.
In
the
context
you
pass
in
we'll
use
that
unless
you
explicitly
say
not
to.
C
Right
right,
yep,
okay,
I
remember
this
now
cool
yeah.
This
looks
pretty
straightforward
if
you're
on
the
call,
even
if
you're,
not
an
approver,
if
your
first
time
joining
this
community,
we
love
having
your
reviews
so
go
on
and
jump
in
there
and
put
your
two
cents,
hopefully
give
it
an
approval,
looks
pretty
straightforward,
so
yeah
great,
I
will
look
at
this
right
after
the
meeting
cool.
C
I
think
if
that,
with
that
we
could
jump
into
some
of
the
other
ones
here
we
only
have
five
left
in
the
to
do
column.
So,
oh
five,
yeah,
okay,
that's
accurate.
I
kind
of
wanted
to
jump
in
here
because
I
I
one
of
the
things
I
noticed
was
gustavo
you're.
I
think
you're
on
the
call
you
don't.
C
I
don't
think
you
have
anything
left
and
there's
a
few
things
in
here
that
made
they
have
a
signees,
but
I
don't
know
if
they
actually
have
a
signees
one
of
them
that
stands
out
is
this
issue
here,
probably
I'm
just
gonna
like
clear
evan
from
this.
I
don't
know
if
evan's
on
the
call
I
see
evan's
on
the
call-
I
don't
know
evan.
If
you
have
the
time
to
work
on
this
or
if
I
can
clear
your
name
from
the
assignment
here,.
G
Sorry,
yes,
I
do
actually
have
time
to
work
on
this.
I
I
realized
now
that
I
had
not
been
looking
at
this,
but
yeah
I'm
happy
to
go
and
work
on
this
opening.
Okay,.
C
Yeah,
that's
fine
too!
That
works
great.
I
will
leave
that,
as
is
this.
I
signed
to
myself
only
because
it's
probably
gonna
take
a
a
pr
to
the
specification
which
I
have
not
done
yet
officially
like.
I
don't
think
this
actually
needs
to
be
assigned
to
me.
I
would
I'm
happy
to
pick
it
up,
but
if
someone
else
wants
to
take
the
charge
just
know,
it's
gonna
be
a
complex
issue.
Robert.
I
see
you're
on
the
call.
Can
we
move
this
to
the
in
progress?
C
H
As
we
are
here,
so
the
dogs
are
already
merged,
and
now
I
just
you
know
there
is
one
pr
just
for
one
option
personally,
I
think
it
will
be
easier
for
reviewing
if
I'll,
just
even
create
a
lot
of
pr's
like
for
each
options.
Tracked,
that's
my
opinion,
because
if
I'll
do
it
for
one
repository
and
change
it
everywhere,
I
think
it
everyone
will
just
sleep
or
just
you
know,
it
will
be
impossible
to
review.
C
Yeah
this
is
this:
is
the
age-old
question
right?
How
do
you
reduce
the
overhead
of
organizational
structure
to
get
the
pr's
reviewed
at
the
same
time?
Have
it
comprehensible
and
have
something
that
like
people
can
actually
review?
I
think,
if
that's
a
a
pretty
good
approach,
there
are
a
lot
of
options.
H
F
So,
if
we're
doing
this,
it
has
to
be
done
soon,
but
I
think
I
probably
actually
would
prefer
that
we
do
it
as
a
single
pr,
so
that
if
we
have
discussion
and
feedback
that
ends
up
changing
the
approach,
it
gets
taken,
it's
easier
to
ensure
that
it
gets
applied
consistently
across
the
board,
and
we
don't
end
up
with
one
pr
that
got
forgotten
when
everything
went
back
and
got
changed.
H
F
Where
we
have
to
get
to
1.0
faster
with
contrib,
I
think
we
we've
got
some
flexibility
to
push
out
calling
some
of
those
1.0
but
yeah-
and
I
I
saw
this
this
was
on
the
agenda
to
discuss
later.
I
wanted
to
bring
up
that.
It
is
kind
of
late
in
the
game
to
be
making
api
changes,
so
this
has
to
be
a
little
wary,
but
if
it's
just
this,
the
stuff
that
was
in
the
contributing
dock
that
you
submitted.
H
F
Last
week
it's
it's
it's
on
exporting
some
fields
right,
that's
my
understanding
is
where
we're
taking
the
apply
or
fields
methods
right
and
not
exporting
them.
So
I'm
probably
okay
with
that,
but
again,
because
it's
changing
api
and
we're
late
in
the
game,
I'd
like
to
keep
it
all
together,.
H
C
C
The
other
thing
is,
some
of
them
also
use
just
a
function
type
as
well,
instead
of
the
interface
approach
that
we
had
originally
done.
So
that
was
like
a
part
of
this
issue
was
to
try
to
find
all
of
those
and
unify
here.
H
F
H
G
F
C
Okay,
cool
robert:
did
you
have
a
clear
understanding
of
what
we're
where
we're
going
with
this
one
yep
cool
deal
I
saw.
I
was
still
assigned
to
this.
I
thought,
but
it
is
all
you
free
and
clear.
C
The
tr
develop
and
implement
a
plan.
Take
some
interfaces
yeah.
I
still
think
it
should
probably
be
ours.
F
Yeah,
I
I
plan
to
spend
some
time
on
this
tomorrow.
Okay,
I've
got
some
time
that
I
should
be
able
to
spend
on
that
tomorrow.
C
Awesome,
I
think
we
have
a
shared
understanding,
but
I
just
I
just
want
to
make
sure
that,
like
it's,
this
documentation
part
it's
really
kind
of
yeah.
F
C
E
F
C
I
will
I'll
just
take
josh
off.
He
can
add
himself
that
controls
awesome,
okay,
cool.
I
was
thinking
about
that
exact,
same
transition
as
well.
So
I'm
glad
that
you
agree
cool,
I
think
that's
it
for
the
project
board.
Doing
really
good.
Look
at
that
the
meeting
we
went
from
five
to
three
just
non-stop
progress.
This
group
is
making
awesome
so
back
to
the
actual
agenda.
C
One
of
the
things
that
over
one
of
the
issues
that
we
were
talking
about
earlier,
is
this
move
this
event
type
from
api
to
sdk.
That's
done!
That's
this
part!
If
you
really
want
to
read
about
it.
The
other
thing
that
I
identified
in
this
was
like.
C
C
The
thing
is:
there's
some
parity
here
with
there's
this
link
type
also
in
the
api,
but
it
is
being
used
it's
being
passed
to
this
with
links,
option
here
and
that's
a
span
option.
So
that
means
that
I'm
not
100
sure
where
all
the
spam
options
are,
but
I'm
pretty
pretty
sure
it's
just
the
start
of
a
spanner
or
at
the
end
of
a
span,
but
that
might
be
a
life
cycle.
I
don't
know
it
goes
through
the
span,
essentially
at
some
point
and
what
you
do.
C
Is
you
pass
in
this
link
structure
itself
as
as
a
type
here,
and
if
we
remove
the
link
from
the
api
like
it
doesn't
really
seem
to
make
any
sense.
Why
we're
passing
it
this
way,
because
we
use
functional
arguments
in
every
other
space?
Why
would
we
do
it
here,
although
that
may
be
a
false
statement?
C
What
I
just
said
just
trying
to
give
you
some
ideas,
the
context
of
like,
what's
going
on
here,
there's
a
lot
more
information
here
as
well,
but
the
idea
is
like
do
we
actually
need
the
link
type
in
the
api,
or
could
that
just
be?
You
know
similar
to
the
event,
get
moved
to
the
sdk
itself,
so
there
went
through
a
few
different
options
here.
C
First,
one
was
just
move
both
the
event
and
the
link
type
to
the
sdk,
and
you
update
with
links
to
be
something
that
is
more
of
this
well
supposed
to
be
singular
like
a
with
link
option
where
you
would
pass
the
spam
context
and
then
you'd
pass
the
attributes
pros
here
being
it,
you
know,
resolves
that
asymmetry
and
it
unifies
this
api
function
pattern
argument.
One
thing
I
did
think
was
like.
C
Maybe
this
is
an
anti-pattern,
because
we're
kind
of
forcing
the
functional
argument
here,
and
it
does
mean
that
then
you're
gonna
like
not
be
able
to
extend
this
in
the
future
with
the
other
side
of
the
thing.
So,
if
and
in
the
future,
the
specification
came
along
and
said
like
yeah.
Well,
you
want
to
pass
a
span
context,
a
link.
You
also
want
to
pass
passwords
to
a
link,
but
you
also
want
to
pass
say
a
type
like
you
know.
C
Maybe
this
is
a
you
know:
a
q
system
link
type
or
maybe
this
is
a
a
remote
span
type.
Something
like
that.
We
wouldn't
be
able
to
extend
this
function
that
way,
we'd
have
to
make
a
break
and
change
or,
as
anthony
pointed
out
down
below,
we
could
provide
some
other
functional
method
to
actually
make
this
happen.
C
So
I
think
if
there's
like,
I
actually
don't
think
it's
as
dire
as
I
made
it
sound
here,
but
it
becomes
a
little
harder
and
I
also
don't
know
if
the
specification
is
ever
to
make
that-
and
I
might
just
be
tilting
at
windmills
in
this
con.
So
keep
that
in
mind.
I.
F
Think
the
as
it
is
as
well,
it's
not
extensible
because
it
uses
a
struct
and
you
can't
add
a
field
to
a
struct
without
breaking
backwards,
compatibility
because
structs
can
be
constructed
without
naming
their
fields.
D
All
right,
unless
it
has
an
unexported
field,.
C
B
F
Yeah,
I
think
the
the
only
way
to
keep
the
door
open
for
extensibility
is
one
of
the
the
approaches
with
either
having
with
lakes,
take
a
second
functional
option
for
link
options
which
would
be
attributes
and
whatever
comes
along
after
that
or
potentially
wrapping
that
with
link
option
with
with
typed
link
or
whatever
comes
along
next,
and
I
I
think
that
that's
probably
the
the
the
better
way
to
keep
the
door
open
because,
as
you
say,
I'm
not
sure
that
the
spec
is
going
to
add
anything
to
links
either
and
it
doesn't
seem
like
there
would
be
anything
that
would
be
added
that
wouldn't
be
representable
as
an
attribute.
F
Even
a
link
type
probably
should
just
be
represented
as
an
attribute.
You
know,
with
the
semantic
conventions
governing
the
name
of
the
attribute.
C
Yeah
that
was
kind
of
what
I
was
thinking
as
well.
Those
pesky
specification
authors,
though
you
never
know
that's
a
little
play,
I'm
one
of
them
and
anthony's
welcome,
but
yeah.
So
I
think
that's
a
good
point.
I
I
agree.
Actually
I
I
like
that
approach
now
that
I'm
thinking
about
it
in
conversation
like
this
okay,
just
I
want
to
make
sure
that
everyone
else
is
aware
of
the
other
two
options
that
we
came
up
with
and
then
well
actually
there's
three
more
options.
C
The
other
one
was
just
move.
The
event
type
leave
the
link,
as
is
which
is
the
current
state
of
the
repository.
This
keeps
the
asymmetry,
but
it
allows
the
link
to
be
extended
in
the
future,
which
we
just
discussed
is
not
necessarily
true.
So
don't
listen
to
that.
The
other
one
is
update.
The
add
event
method
to
essentially
go
the
opposite
direction,
leave
the
event
type
in
the
api,
and
then
you
know,
go
the
opposite
direction
and
start
like
extending
everything
and
using
the
event
type
in
the
api.
C
I
didn't
really
like
this
approach
and
pretty
much
just
counted
it
right
away
because
it
splits
the
api
further.
It's
accepting
functional
arguments
as
well
in
some
places
configure
arguments
in
another,
so
that
was
kind
of
like
the
opposite
approach.
I
put
it
there
for
continuity,
but
I
didn't
really
consider
it
and
then,
as
cassava
pointed
out
down
here,
another
option
I
considered
but
didn't
document
appropriately.
Is
this
idea
that
like
well?
C
We
could
also
have
the
with
links,
option,
take
options,
and
so
you
could
also
pass
in
like
a
link
option
here
which
would
fit
our
pattern.
I
thought
this
was
a
little
bit,
maybe
harsh
in
my
a
judgment,
but
I
was
just
like
well
having
an
option
taken.
Option
seemed
a
little
excessive,
but
I
was
also
like
you
know.
Maybe
that's
not
a
bad
idea.
You
know
I
I
feel
bad.
C
I
didn't
you
know
included
in
the
documentation,
but
I
think
that's
kind
of
that
point,
and
hopefully
somebody
made
sense
that,
like
what
I
was
talking
about
here
is
like
you
know,
you'd
have
something
like
this.
Where
you
start
a
span,
you
pass
into
with
links
and
that
with
links
would
also
have
some
sort
of
like
option
here.
But
then
maybe
there'll
be
more
options
here.
It
may
get
a
little
bit
ridiculous,
but
I
don't
know
so.
F
I
look
at
functional
options
as
similar
to
builder
patterns
as
well.
When
initializing
objects,
I
mean,
I
think,
we've
got
other
places
where
we've
either
had
or
still
have
options
that
take
options.
I
think
there's
a
an
open
pr
right
now,
where
I
actually
just
asked
about
it.
Can
we
try
to
avoid
this
in
a
slightly
different
way?
Let
me
see
if
I
can
find
that
one
I
think
it
was.
It
was
one
that
wanted
to
take.
Oh,
it
was.
F
It
was
the
it
was,
the
one
for
error,
record
error,
yeah
yeah,
and
it
ended
up
adding
a
with
with
lifecycle,
option
or
with
event
option
attribute,
and
I
thought
we
could
probably
avoid
that
by
using
some
introspection.
You
know
trying
to
course
that
into
the
if
we
could
take
an
event
or
an
error
option
and
towards
it
into
an
event
option.
We
could
use
that.
I'm
still
not
sure
that
that
actually
works,
but
having
having
those
implements.
F
The
error,
option
interface
and
just
do
their
work
there,
rather
than
keep
them
separate,
might
be
the
way
which
would
that
would
be
the
same
as
what
we.
What
we
would
end
up
doing
with
with
attributes
in
with
link
in
the
in
the
outline
you've
given
there
right,
because
with
link
with
attributes,
we
need
to
add
an
apply
link
method
right,
be
usable
as
a
link
option.
C
Yeah
exactly,
I
think,
we
kind
of
highlight
some
of
this
in
our
contributing
documentation,
which,
every
time
I
go
to
the
stock,
I'm
like
we
need
to
split
this
up
into
its
own,
like
style,
guide,
doc,
but.
C
Yeah
where's
this
thing:
oh
yeah,
something
like
this,
where
you'd
have
an
option,
implement
both
like
two
different,
essential
interfaces
and
then
you'd
have
independent
ones
here,
but
you
might
be
talking
about
something
a
little
bit
different.
Maybe
I
think
this
is
similar.
I'd
have
to
look
at
the
details,
though,.
F
F
Implement
both
life
cycle
option
or
span
option
and
and
link
option.
I
think
part
of
the
reason
why
that
that
wrapping
option
might
have
been
there
is
to
have
the
the
option
generator
return,
that
option
type
rather
than
return
a
concrete
type.
C
C
It
would
leak,
I
think,
the
internal
implementation
details,
but
especially
if
it's
un
exported
option.
F
C
F
Of
the
day
right,
but
they
would
be
able
to
someone
needed
to
construct
a
slice
of
link
options
or
span
offs
is
they
can
still
do
that?
Because
the
interface
that
it's
implementing
is
is
exported
yeah?
They
would
have
to
cast
it
though
first
right
or
would
that
be
implicit?
F
C
H
C
C
I
kind
of
agree
like
I,
I
I'm
thinking
this
or
leave
it
and
I'm
leaning
towards
this.
I
like
this.
Just
it
also
has
some
some
symmetry
to
like
a
record
error,
setup
or
I'm
sorry
set
set
status,
not
recorder.
You
know
where
there's
just
like
there's
two
things
that
are
going
to
be
composed
of
the
status,
and
this
is
what
they
are
and
yeah.
C
We
aren't
positioned
if
the
future
somebody
decides
like
a
status
should
also
include,
I
don't
know
an
emoji
about
how
you
feel
about
it
but
like
like.
I,
I
think,
that's
just
something
we
have
to
address
when
that
happens,
because
right
now
like
this
is
concretely
like
what
we've
decided
a
link
is-
and
I
think
like
based
on
what
the
specification
defines
the
link
to
be
like
this
should
be
comprehensive
and
we
could
probably
solve
things
as
like.
A
Just
a
quick
thought:
do
we
have
any
apis
to
add
links
to
spans
after
they
are
created,
or
is
it
only
going
to
be
span
start
and
end
is
for
bowdoin.
C
Yeah,
it's
a
good
question,
you're,
not
alone,
but
there
are
some
people
have
some
very
strong
opinions
about
that
and
it's
only
a
span
creation
that
that
should
be
happening.
F
F
Can
be
created
or
can
be
used
at
start
and
life
cycle
options
can
be
used
at
start
and
end,
which
I
think
are
things
like
status
and
time
timestamp,
but
link
can
only
be
used
at
the
start.
B
G
This
does
make
it
difficult
in
some
cases.
I
actually
had
a
case
where
I
did
want
to
add
a
link
option
which
I
could
only
get
after
I
sort
of
started
doing
the
operation.
So
basically
you
have
to
save
the
time
and
then
later
on,
create
the
span
with
that
time.
G
F
It's
the
same
thing
you
have
to
do.
If
you
need
to
specify
attributes
up
front
for
a
sampler
yeah,
you
need
to,
as
you
say,
stash
the
start
time
away
somewhere
get
all
the
information
you
need
and
then
start
the
span
with
an
explicit
time
stamp.
It's
some
extra
hoops,
but
that's
there
are
things
that
the
spec
says
can
only
happen
right
at
start,
and
so
that's
how
it
has
to
be
yeah.
C
I
don't
know,
did
this
change,
I
might
I'm
a
lightsaber
like
doing
this
live.
I
may
not
be
reading
this
correctly,
but
I
don't
think
that's
actually
implemented
that
way.
I'm
also
not
seeing
the
life
cycle
options
here
like
did
we
get
rid
of
that.
F
C
Yeah
actually
they're
not
used
anywhere
in
here
that
might
have
changed,
so
I'm
gonna
need
to
look
at
that.
Okay,
oh
I
wanna
move
on
because
we've
been
talking
about
this
for
a
while,
but.
F
C
And
we
can
definitely
we
need
yeah.
I
need
to
double
check
that
one
as
well,
but
we
definitely
should
add
that
to
a
list
of
things
to
do.
Okay,.
E
C
Cool,
I
wanna
keeps
going
we're
28
minutes
in.
I
don't
want
to
take
up
all
the
time
on
this
one.
It's
a
really
good
issue,
so
just
kind
of
want
to
like
circle
back
and
say
like
what's
everyone's
opinion
like
if
I
put
in
this
issue
and
say
like
we're
going
to
go
with
this
approach
that
anthony
outlined
here
add
or
replace
this
with
the
width
link
option,
although
I
would
change
this
exported
type
to
be
a
specific
option.
If
we're
going
to
go
this
way,
would
that
ever
be
okay
with
that.
C
Well,
yes,
spoke
for
all
of
us
thanks,
gustavos,
okay
cool.
I
will
comment
on
here
and
then
probably
open
up
a
pr
to
address
that
change
sounds
good.
Next
thing
I
wanted
to
ask
about.
Was
this
there's
a
span
id
tricity
key
value
and
other
structures
cannot
be
on
marshall
from
json.
It
was
a
little
while
ago
anthony
had
this
point
and
it
hasn't
been
really
responded
to
I've
been
thinking
about
it,
and
I
don't
really
have.
I
have
a
lot
to
think
about.
C
I
don't
know
if
I
wanted
to
like
write
something
here,
but
the
idea
is:
is
that
like
currently,
if
you
try
to
export
the
span
that
has
these
values
in
the
in
them,
when
you
try
to
marshal
them
and
then
unmarshal
them,
it
won't
actually
be
a
reversible
process
currently,
because
I
don't
think
that
they
actually
are
marshaled.
C
Anthony
pointed
out
that,
like
maybe
that's,
not
something
we
want
to
provide,
as
the
standard
exporter
isn't
really
intended
for
this
interoperability,
it's
more
for
like
testing
and
debugging.
I
I'm,
and
I
don't
know
one.
The
first
thing
I
always
think
about
is
like
I'd
really
like
to
see
the
standard
exporter
refactored,
to
take
some
sort
of
like
a
translation
layer,
maybe
even
like
a
driver.
C
So
you
could,
like
you
know
we
could
provide
like
a
standard
set
of
like
a
json
drive
or
a
gamble
driver
or
even
or
something
I
don't
know
something
like
that,
and
then
you
can
provide
your
own
custom
one
and
essentially
you
could
do
whatever
you
want
with
that
driver.
But.
D
A
A
H
A
F
Yeah-
and
this
that's
very
much,
the
point
that
I
was
trying
to
make
here
as
well
is
that
this
is,
you
know,
internal
stuff.
It's
not
intended
to
be
a
communication
protocol.
It's
not
intended
to
ever
be
deserialized
right.
It's
for
you
to
say,
am
I
getting
output,
and
does
it
look
generally
like
the
thing
that
I
expect
it
to
be?
I
I
think
I
don't
know
if
adding
a
standard
outer
io
writer
out
to
the
otop
exporter
would
be
the
way
to
go.
F
I
think
I
would
lean
more
towards
how
tyler
described
it
make
the
or
enable
the
standard
out
exporter
to
take
an
I
o
writer
or
some
other
interface,
probably
just
an
I
o
writer
right,
because
you
can
implement
an
I
o
writer
then
well.
You
know
that
you
have
to
be
an
ira
writer
and
a
marshaller
right,
so
you
have.
F
Yeah
and
then
you
would
need
something
like
the
the
marshaller,
that's
in
the
otlp
hdp,
which
could
implement
that
interface
as
well,
which
takes
the
the
span
and
produces
bytes.
And
then
those
bytes
can
be
written
to
the
I
o
writer.
F
A
Then
I
can
still
see
so
so
what
you
would
need
from
that
is
something
that
would
translate
from
our
internal
span.
Types
of
the
sdk
span
types
to
something
else,
then,
to
bytes,
then
to
the
writer
right
and-
and
my
concern
is
that
very
first
step
where
we
have
the
sdk
spans,
which
I
don't
want
to
see
those
go
directly
onto
the
wire
and
then
have
the
responsibility
of
being
able
to
re-serialize
them.
After
the
fact,
those
are
meant
to
be
translated
into
something
specific
for
going
over
the
wire.
A
A
No,
no,
there
is
a
translation
to
like
otlp
or
to
zipkin
or
to
prometheus.
Well,
where
is
the
json
coming
from
here?
So
this
is
just
using
just
default
names
from
json
these.
These
aren't
even
oh,
it's
not.
C
Tagged-
and
this
is
why
there's
this
issue-
that's
open
right
because,
like
these
things
are
internal,
and
I
think
that
some
of
them
are
even
embedded
and
so
like
these.
C
Don't
work
when
that
happens
right,
so
you
have
custom
marshallers.
A
Or
something
like
that
yeah,
that's!
That's
what
I
ran
into
with
the
span.
Ids
trace
ids
those
have
custom
marshallers,
so
they
don't
unmarshal
properly.
C
So
I
think
that's
actually
a
really
interesting
point
that
I,
like
I
hadn't
thought
about,
but
like
this
idea
that,
like
since
our
translation
from
the
sdk
to
the
otlp,
is
a
very
well
defined
translation
and
it's
going
to
be
consistent.
It's
going
to
be
like
you
know
something
that
people
can
actually
rely
on.
C
Hence
why
the
collector
exists
like,
if
that's
an
interesting
proposition
to
say
like
well
yeah
like
this,
this
standard
exporter
just
used
for
testing
and
debugging,
but
like
how
helpful
is
it
if,
like
we
come
along,
we
say
like
okay,
like
we
don't
really
like
how
this
is
formatted,
so
we're
gonna
change
it
a
little
bit
here
and
then
like
yeah,
like
the
testing,
you
have
to
update
two
sides
and
it
could
work
but
like
it's
not
really
like.
You
know
the
most
consistent.
C
If
we
were
to
just
say
like
use
the
otlp
exporter
and
you
know
pipe
pipe,
the
json
version
instead
of
http
json,
you
do
standard
out
json
or
something
like
that,
and
you
can
pipe
it
to
an
I
o
writer
or
whatever
you
want.
I
think
that's
a
really
interesting
and
powerful
idea
because,
like
this
has
been
like
the
habitual
problem
is
like
every
time
there's
updates
to
this
exporter.
Everyone
always
argues
over
the
format,
and
it's
like
you
really
like
you're
missing.
The
overarching
question
is
like
the
format
itself
is
a
topic
of.
D
A
That's
why
I
want
to
provide
a
different
option
that
that's
somewhat
easily
used
like
that.
That's
one
of
the
reasons
why
I'm
kind
of
on
the
side
worked
on
a
driver,
an
otlp
driver
that
plugs
in
instead
of
grpc
or
hdp.
It's
a
writer.
It
takes
a
writer
for
metrics
and
a
writer
for
traces,
and
it
just
writes
the
json
or
the
protobuf
line
by
line
as
it
receives
the
batches
yeah.
D
I
could
see,
though,
where
somebody
might
start
emitting
this
stuff
start
collecting
it
and
want
to
write
an
analysis
program
post
talk
and
they
would
reach
for
our
types
again.
At
least
I
think
I
would,
if
I
were
saying
I'm
going
to
write
a
parser
for
this
now,
because
I
want
to
be
able
to
write
a
program
that
analyzes
these
logs.
D
C
That's
a
good
question,
and
I
think
that
also
comes
back
to
this
idea
that,
like
you
in
theory,
you
could
take
the
otlp
and
return
it
back
to.
You
can
use
the
utilities
of
the
collector
right
because
they
have
auto
generated
like
functional
things
that
like
translate
it
back
otp
to
some
sort
of
data
structure.
I
think
currently
the
open
session
open
census
data
format,
I
think,
is
what
you
know.
C
F
Similar
to
the
otlp,
but
it's
what
the
collector
operates
on
and
this
topic
came
up
earlier.
Someone
opened
an
issue
this
morning
as
well,
asking
about
being
able
to
set
time
stamps
on
metrics
with
the
use
case.
It
sounded
very
much
like
wanting
to
be
able
to
receive
data
that
was
generated
somewhere
else,
run
it
through
our
sdk
and
process
it
and
send
it
out
to
an
exporter
which
use
case,
I
think,
really
is
best
served
by
the
collector
right.
F
If
someone
were
to
to
generate
spans
through
our
sdk
and
export
them
to
standard
out
through
whether
it's
a
standard
out
that
has
a
formatter,
that's
otlp,
protobuf
or
json,
or
the
the
otlp
exporter
with
a
standard
out
writer
or
an
I
o
writer
driver,
then
I
don't
think
that
they
should
be
looking
to
bring
them
back
into
our
sdk,
because
our
sdk
is
for
instrumenting
applications.
It's
not
for
processing
metrics!
F
C
Yeah,
I
completely
agree.
After
reading
this
issue,
I
was
trying
to
find
the
words
to
say
exactly
what
you're
saying
like
you
know
like
that,
if
you
want
to
do
that,
like
put
it
into
the
otlp
and
put
it
to
the
collector
because,
like
you
just
said
like
this
project
is
really
about
instrumenting
your
code
and
then
having
that
you
know,
get
funneled
and
use
as
a
remote.
You
know
information,
collection
or
site
and
then
sending
it
somewhere,
not
about
like
taking
it
from
somebody.
H
Can
I
interrupt
you
guys?
I
have
just
one
question
if
you
have
already
told
about
it.
Sorry,
because
my
my
english
is
not
so
good
as
yours,
because
you're
you're
telling
why
you
sh
it
should
be
not
used
right,
why
you
should
not
march
on
a
marshall,
but
I
would
maybe
ask
a
question
why
it's
not
working
because
it
may
you
know
there
may
be
something
wrong
inside
and
it's
just
a
side
effect
or
not.
It's
not
this.
This
thing.
F
F
That's
that's
one
of
the
the
issues
we've
seen
and
the
other
is
that
they
just
simply
don't
have
an
unmarshal
and
thus
can't
be
unmarshaled.
Properly,
like
I
think,
trace
id
is
a
slice
of
bytes
which,
on
marshall,
json
by
default,
will
try
to
read
into
from
base64
encoded,
or
I
know
marshall
will
I
I
don't
know
how
that
works
on
marshland
right,
but
taking
a
hex,
encoded
string
and
dropping
into
a
slice
of
bytes
is
not
going
to
give
you
the
right
thing.
D
Yeah
it
sounds
like
the
current
behavior
is
expedient
or
possibly
opportunistic
like
it's.
It's
an
easy
way
to
get
this
stuff
translated.
Without
even
say,
you
know,
tagging
the
struck
fields,
but
I
forgot
that
there's
even
this
natural
behavior
that
that
goes,
json
and
coder
will
do.
H
C
Yeah-
and
I
think
that's
the
key
thing
to
take
home-
is
that,
like
the
standardized
exporter
was
written
primarily
for
us,
like
the
developers
of
this
project,
to
validate
things
and
to
understand
things
and
the
format
that
it
exports
is
kind
of
just
like
whatever
was
helpful
to
us.
C
It
wasn't
really
an
agreed
upon
like
most
useful,
most
concise
or
most
like
performant
structure,
like
data
format,
so
like
in
that
sense,
like
it's
kind
of
an
ad
hoc
thing
that,
like
we
keep
around
just
so
for
things
like
steve,
pointed
out
like
when
you're
like.
Why
is
this
even
working?
You
can
plug
it
in
and
go
like?
C
Oh
I'm
seeing
things
and
yeah,
maybe
sometimes
you
can
get
some
useful
information,
but
like
that
data
that
it
comes
out
that
format
that
it
comes
out,
we
never
really
structured
in
a
way
that
we
intended
to
be
reversible.
We
never
even
thought
about
that.
It
was
just
kind
of
like
an
ad
hoc
thing,
yeah
and
I
don't
think.
A
C
So
yeah
it
was
and
or
it
wasn't
you
know
like
some
things
were
like
we
wanted
to
validate
certain
parts
of
the
sdk
and
so
like
we,
you
know
like
this
stands
and
snapshot
was
developed
long
after
the
standardized
exporter
right.
So
a
lot
of
the
the
ways
that
we
validate
this
are
not
using
the
standardized
exporter
anymore.
C
You
know
it
was
something
I
think
for
demos
or
stuff
something
I
think
for
like
testing
you
know,
but
like
we
just
stopped
using
it
essentially
for
that
and
we've
started
to,
like
you
know,
hook
into
other
places
for
the
testing.
So
it's
not
really
like
it's
something
I
think
more
for
show
than
it
is
actually
for
you
know
functional
use
in
a
production
system.
I
guess
it's
a
good
way
to.
D
See,
I
think,
one
one
quick
thing
I
gotta
admit
I
got
a
little
lost
on
the
discussion
about
otlp
to
the
collector
ecosystem,
but
the
lp
and
otlp
is
lime
protocol
right,
and
so
I
think
that
we,
I
I'm
a
little
concerned
about
stretching
it
to
like,
and
then
it
has
this
sort
of
pretty
printed
version,
and
you
know
it's.
I
understand
it's
also
an
information
model
at
this
point
because
of
the
protocol
buffer
message,
definitions,
so.
C
It
is
not
line
protocol,
it
is,
it
is
otl
and
then
protocol.
The
l
is
whatever
you
want
it
to
be,
it
could
be
loquacious,
but
it's
in
it's
implicitly
said
that
it's
not
a
line
protocol,
because
you
have
things
like
json
right
which
are
not
going
to
be
like
they
could
be
serialized
into
a
line
protocol,
but
they
could
also
not
be
right.
So
yeah,
that's
a
little
it's.
It
is
a
contentious
system.
C
D
C
Yield
yeah,
but
that's
the
idea.
It's
a
data
format,
I
think,
is
it's
it's
a
protocol
that
you
would
you
know.
Encode
data
into
some
sort
of
format
is
a
good
way
to
think
about
it
that
can
then
be
sent
over
the
line.
It
can
then
also
just
be
presented.
I
think
that's
the
best
way
to
think
about
the
otlp.
C
F
I
would
I
would
like
this,
the
standard
exporter
to
have
a
marshaller
interface
that
takes
in
a
span,
snapshot
and
exports,
a
slice
of
bytes
to
be
written
and
then
also
to
take
an
I
o
writer
to
direct
those
bytes
to,
I
think,
the
having
a
standard
out
or
an
I
o
writer
driver
for
the
otl
lp
exporter
is
also
good,
and
I
think
that
if
there's
enough
overlap
between
those
marshaller
interfaces,
the
the
give
me
a
span
snapshot
and
output,
a
slice
of
bytes.
F
F
What
is
it
no
glp
proto
message
and
that
exports
that
as
a
slice
of
bytes,
so
then
you
just
need
the
front
half
of
that,
which
is
to
expand
snapshot
to
proto
message,
which
is
also
there
right,
combine
those
two
together
and
then
you've
got
the
interface
that
the
standard
or
the
the
io
writer
generic
exporter
would
expect.
A
Well,
we
could
then
expose
the
transform
that's
internal
to
otlp,
so
there's
a
in
otop
there's
the
internal
package
that
has
transform
underneath
it,
which
is
doing
that
translation
for
internal
sdk
types
to
otlp,
proto
messages.
F
Yeah
and
I'm
not
sure
right
now
that
I
have
a
strong
opinion
on
whether
it's
better
to
keep
that
internal
to
otlp
and
expose
something
that
goes
from
span
snapshot
to
bytes.
For
the
benefit
of
this
I
o
writer,
standard
writer
exporter
or
to
expose
that
and
let
it
be
used
for
other
things,
there's
potentially
utility
in
exposing
that
to
others
who
want
to
get
otlp
out
of
a
span
snapshot
but
not
send
it
to
the
otlp
exporter.
Maybe
I
don't
know.
C
Well,
one
thing
is:
we
could
also
abstract
that
I
think
it
already
is
abstracted
into
an
internal
package,
just
move
it
to
the
level
we
want
and
then
eventually,
if
there's
enough
user
desire,
we
can
you
know,
answer
that
question
there,
but
that
would
be
exposing
it
across
modules.
C
F
Of
what
the
otlp
writer
does,
though,
right
it
has
a
method
that
converts
the
proto
message
into
some
marshalled
format,
which
is
either
json
or
protobytes,
and
and
so
we
would
probably
expose
one
up
to
expose
that
up
to
the
the
I
o
rider
the
user
can
choose
which
one
they
want,
probably
by
default.
We
would
want
to
configure
it
to
expose
json
because
that's
going
to
be
the
most
useful
most
often,
but
I
could
also
see
a
situation
like
aaron.
F
I
think
you
were
working
on
embedded
devices
where
you
wanted
to
be
able
to
get
the
data
off.
You
write.
It
write
it
out
to
an
I
o
writer
and
then
get
it
off
and
use
it
later,
and
for
that
you
probably
want
the
proto
encoding,
because
it's
going
to
be
more
compact.
A
They
were
embedded
vm,
they
were
vms
and
the
compactness
wasn't
that
big
of
a
deal
but.
G
A
I
have
a
prototype
lingering
around
somewhere
of
the
otlp
part
of
it.
We
could
probably
work
to
get
it
to
be
a
more
generic
one
for
standard
out
with
a
marshaller
interface,
but.
C
I
like
that
idea.
One
thing
to
keep
in
mind,
though
this
fan
snapshot
idea
for
the
marshall
interface
is
only
for
spans.
I
don't
know
if
that
makes
a
difference.
We
can
iron
out
the
details,
but
we
probably
want
to
like
think
about
ways
to
extend.
Actually
this
might
be
the
best
way
to
do
it.
So
you
have
a
you
know:
a
trace
marshaller
that
works
with
the
trace
setup,
and
then
you
have
like
a
metrics
marshaller
or
log
marshaller,
or
something
like
that.
C
Comment
we
have
taken
up
so
much
for
this
time.
I
apologize
if
somebody
else
has
something.
That's
super
critical.
What's
the
next
thing
I
added
here?
C
Oh,
this
is
related
to
what
we
just
went
over.
This
is
the
same
thing
yeah.
This
pr
was
going
to
essentially
add
a
marshall
json
to
the
link.
Oh,
my
god,
this
is
there's
just
so
many
dependencies
here
which
we
may
just
be
removing
entirely,
and
I
I
think
the
conclusion
was
to
remove
the
link.
So
I'm
just
we're
going
to
skip
over
this.
I
don't
want
to
waste
anybody
else's
time
anthony
you
have
the
next
thing
on
the
agenda.
Semantic
convention
generation.
F
Yeah,
so
the
semantic
conventions
are
recorded
in
yamo
and
there's
a
desire
to
have
implementations
generate
their
constants
for
referring
to
these
semantic
inventions
from
that
yaml
and
a
set
of
templates.
So
there's
this
semantic
convention
generator
tool
that
takes
jinja
templates
and
will
render
out
whatever
you
make
that
template
do
that
it
would
be
desired
to
have
all
of
the
sdks
used
or
apis
used
to
generate
their
semcom
standards
or
constants
and
variables.
So
I've
started
playing
around
with
this
and
it
looks
like
it's
going
to
be
doable.
F
My
concern
is
that
we
may
end
up
renaming
a
whole
bunch
of
semantic
convention
constants
and
variables,
because
we've
kind
of
created
them
manually.
To
this
point,
I
think
many
of
them
are
in
line
with
what
will
be
generated
by
this.
But
it's
I,
I
think,
an
effort.
That's
gonna
have
to
be
undertaken.
C
Yeah,
I
took
a
look
at
this
as
well
on
a
friday
afternoon
and
it
is
going
to
take
way
more
than
a
friday
afternoon,
as
I'm
sure
that
you're
finding
out
as
well,
it
does
seem
that
it's
extremely
extensible,
so
we
may
be
able
to
like
put
in
some
like
one-off
cases.
One
of
the
things
that
I
really
was
worried
about
was
documentation.
So
a
lot
of
our
things
don't
follow
exactly
what
the
documentation
and
the
specification
are,
and
I
want
to
make
sure
that
that's
like.
C
Sometimes
it's
not
useful
documentation
in
the
specification,
but
we
have
like
applicable
stuff
in
the
go
one
and
then
yeah
kind
of
like
what
pointing
out
is
some
of
like
the
naming
or
some
of
like
the
paired
key
value
types
are:
that's
gonna
be
hard
to
generate.
We
might
have
to
do
like
some
ad
hoc
things,
yeah.
C
So
one
other
option-
and
this
is
just
maybe
a
really
bad
suggestion.
We
could
write
our
own.
It's
yaml
and
this
is
great,
but
maybe
it
doesn't
serve
us
completely
and
we
want
to
generate
go
code.
So
there's
you
know,
the
standard
library
has
ways
to
parse
the
syntax
tree
and
then
build
a
syntax
tree
right.
You
may
just
be
able
to
do
that.
These
are
some
ideas
I
thought
of.
I
don't
know
if
they're
good
ideas,
yeah
we're.
F
We're
absolutely
not
required
to
to
use
this
generator.
I
think
the
the
goal
is
to
have
us
use
the
yaml
and
generate
our
code
from
that.
Whether
we
use
this
or
not
is
up
to
us.
This
is
something
that's
provided
for
convenience
of
the
implementers
I've
I've
been
able
to
to
get
like
the
the
paired.
F
You
know
the
the
variables
that
are,
you
know,
here's
a
key,
and
then
these
are
predefined
values
for
that
key
I've
been
able
to
make
that
work
using
these
templates,
at
least
as
far
as
I
can
tell
so
I
I
don't
think
that'll
be
too
much
of
a
problem,
but
the
documentation
and
and
getting
the
the
right
values
up
into
the
first
part
of
the
doc
block
and
making
that
you
know
read
naturally,
is
one
of
the
things.
That's
still
an
open
issue
for
me,.
F
C
Yeah,
I
agree
as
long
as
they
are
not
like
super
unidiomatic,
I'm
not
opposed
to
that.
Just
for
consistency.
Everyone
keep
in
mind
that,
like
the
collector,
is
also
looking
to
use
this
package.
If
we
do
generate
it,
so
it
would
be
consistent
across
multiple
ecosystems,
which
would
be
helpful
but
yeah.
C
F
A
Kubernetes
has
a
pattern
for
this.
They
actually
have
a
large
list
of
acronyms
that
are
always
capitalized
in
their
api
in
their
generation
code.
So
it
might
just
be
something
that
we
do.
F
That
sounds
useful
and
what
I
was
thinking
when
tyler
just
mentioned,
you
know,
go
parsing
and
ast
and
generating
code
as
well
is
that
we
always
have
a
two
pass
process
too
right.
We
can
use
the
the
generator
with
ginger
templates
to
get
us
most
of
the
way
there
and
then
once
we've
got
some,
you
know
valid
go
that
we
can
parse.
We
can
parse
it
out
and
rewrite
it
with
some
go
code
that
we
write
ourselves.
C
Yeah,
I
think
if
that
might
be
the
best
approach,
especially
initially
you
know,
maybe
the
long
term
we
wanted
like
unify-
or
I
don't
know
like,
but
yeah.
If
that
sounds
like,
if
you
can
get
90
of
the
way
there
and
then
the
next
ten
percent,
like
you,
can
just
do
with
go
code
like
yeah,
which
I
think
something's
better
than
nothing.
C
F
The
spec
for
semcomp
isn't
stable
just
yet.
That's
the
other
concern
that
I
have
right
now.
Okay,
so
I
think
that
currently,
the
stemcom
package
is
part
of
the
top-level
module
which
would
be
included
in
the
stable
yeah.
There's
no
go
mod
here,
so
we're
left
with
a
question
of.
F
Can
we
can
we
pull
in
unstable
semcon?
Knowing
that
I
don't
know
if
they're
going
to
be
changes
to
the
names
of
existing
convention
or
existing
keys
or
not
right,
that's
the
sort
of
thing
that
would
be
really
nice
to
have
locked
down
before
we
call
that
package
stable
and
if
we
can't
get
a
guarantee
of
that
out
of
the
spec
that
you
know
it's
only
unstable
because
they
expect
to
be
adding
more
which,
in
which
case
it
should
probably
be
called
stable.
F
Then
we
may
need
to
split
this
package
out
into
a
separate
module,
and
I
don't
know
if
we
rely
on
it
anywhere
that
we
would
have
to
call
stable.
We
probably
do.
C
We
do
I
the
first
thing
that
comes
to
mind.
Is
the
error
exception
type
like
that's
a
that's
a
scientific,
yeah
yeah.
Here
you
go
right
like
yeah.
That's
we're
back
see
this
full
circle.
Is
there
and
it's
falling
out
okay
zero
days.
C
So
this
is
also
something
that
so
this
name,
the
the
string
may
change.
I
think
that
that's
the
unstable
part,
what
we
could
do
is
it'd
be
nice
to
have
this
be
consistent
with
this,
but
what
we
can
also
do
is
provide
like
a
deprecated
field
going
forward.
So
if
this
name
ever
did
change,
we
could
change
it
in
a
positive
direction.
Essentially,
like
you
know,
exception
type
gets
changed
to
just
I
don't
know
exception
types.
C
So
then
we
also
add
a
constant
called
exception
types
key,
and
we
alias
it
to
this
as
well,
which
remain
and
the
underlying
string
value
can
change.
That
is
always
going
to
happen.
I
think
is
the
idea
that
might
just
be
the
we
have
to
go
stable
because,
like
we're
just
going
to
depend
on
it
as
a
stable
part
of
the
sdk
or
the
api,
I
think
sdk
and
so
like.
C
F
Yeah
and
I
had
been
generating
the
constant
name
from
that
value,
so
right
now,
they'll
all
be
the
same,
and
I
don't
know
if
there
are
separate
fields
for
name
and
value
at
that
level.
I'll
have
to
look
at
the
data
model
again,
but
if
there
aren't
then
yeah
we
we
just
need
to
there's
a
deprecation
notice
or
a
mechanism
for
indicating
that
things
are
deprecated
in
in
the
conventions,
so
we
at
least
have
some
utility
of
that
and
I
think,
there's
a
way
to
link
them
together,
which
may
also
provide
us
information.
F
We
need
to
generate
aliases,
okay,
I
will
get.
F
To
track
that,
though,
and
yeah
I'll
start
working
on
that
as
well,.
C
Awesome
thanks.
We
are
running
short,
but
if
you
want
to
just
maybe
point
these
issues
out.
H
C
That's
that's
fair.
The
contributor,
I
think,
you're
doing
the
right
thing
you
need
to
come
in
here,
sometimes
just
focus,
because
it's
not
a
main
focus
but
yeah.
I
think
we
can
try
to
focus
on
getting.
C
It
okay
cool.
So
if
you're
on
the
call
you
are
tasked
by
robert
to
go
review
those
pr's,
okay,
everyone,
we
are
pretty
close
to
time-
I
don't
know
if
anybody
else
has
something
else
they
want
to
talk
about.
We
did
make
it
through
all
the
way
the
agenda
kind
of
rushed
us
a
little
bit,
but
I
just
want
to
open
up
the
floor.
C
Steve's
shaking
his
head
steve
will
make
it
the
whole
time
this
time.
So
that's
a
plus,
well
cool
awesome
thanks
everyone
for
joining,
then
I
think
we
can
probably
call
it
for
the
day
and
thanks
again
for
all
the
like,
really
amazing
work.
Over
the
past
week,
we've
had
a
lot
of
great
progress.
Let's
get
to
that
rc.
I'm,
like
super,
excited
to
see
this
like
we're.
Actually,
we
might
actually
make
it
so
yeah.
C
I'm
pretty
excited
thanks
everyone
for
contributing,
and
I
will
look
forward
to
talking
with
you
again
all
next
week.
Okay,
bye,
everyone.