►
From YouTube: 2021-09-01 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
Oh
you're
see
root
you're,
I
think
you're,
muted,
sorry.
B
Nice
to
meet
you
as
well,
what
brings
you
to
the
inaugural
instrumentation,
sig
meeting.
C
So
john
invited
me,
I
work
with
him
at
splunk
in
the
observability
team
and
I'm
really
looking
I'm
just
here
to
learn
a
bit
more
about
the
process
and
the
main
topics
of
discussions
nowadays.
Yeah.
D
Hey
yeah:
well,
let
me
put
my
video
on
feel
rude,
not
having
enough.
I
am
an
engineer
for
atlassian
and
we
actually
use
open
telemetry
and
we
instrument
our
own
kind
of
libraries
and
do
lots
of
stuff
with
it.
So
I'm
just
at
the
moment
keeping
up
with
what's
going
on
and
seeing
how
we
can
contribute
so
yeah,
that's
pretty
much.
What
I'm
doing
at
the
moment
nice
to
be
here
thanks.
B
Awesome
yeah.
I
was
actually
just
before
this
meeting
asking
around
about
what
was
the
best
way
to
contact
atlassian
to
let
them
know
about
this
meeting,
but
it
sounds
like
you
found
it
so
excellent.
D
I'll
I'll,
let
everyone
else
in
my
team
as
well
know
about
it,
because
I
think
it'll
be
useful
for
us,
I'm
from
observability
atlassian,
so
yeah
we
handle
all
the
kind
of
telemetry
going
on
awesome,
yeah
I'll!
Let
everyone
know
about
it.
B
Cool
and
my
name's
ted
I
work
at
lightstep,
but
on
the
open,
telemetry
governance
committee
and
generally
trying
to
help
organize
things
around
here,
especially
this
instrumentation
work
that
we
spun
up
recently
since
it's
one
of
the
last
big
hurdles
to
declaring
stability
for
open
telemetry
with
metrics,
and
I
believe,
logs,
coming
coming
along
at
a
hot
pace.
E
E
B
D
I
think
I
think
hand
show
right.
D
You
about
the
aws
semantic
convention,
stuff,
yeah
yeah.
I
saw
that
conversation
actually
yeah.
B
Cool
awesome
and
john
what.
A
What
brings
you
here
so
I'm
john
watson,
I
work
for
splunk.
I
am
the
maintainer
on
the
front
java
implementation,
mostly
here
as
a
facilitator,
to
help
connect
people
together
who
are
interested
in
instrumentation
awesome.
Currently,
mostly
at
splunk,
I'm
focused
on
mobile
mobile
run
at
the
moment
on
android,
so
I'm
really
interested
in
trying
to
figure
out
how
to
drive
some.
B
Yeah
I'd
make
a
joke
about
rum
driving
one
to
drink,
but
I
won't
I'll
have
some
kombucha
instead
and
johannes
glad
to
see
that
you
could
make
it
do
you
want
to
introduce
yourself
real
quick
to
the
newcomers.
F
Sure
hi,
I'm
johannes,
I'm
working
at
microsoft
and
you
are
currently
trying
to
drive
forward
like
the
messaging
semantic
conventions,
drive
that
to
stability
and
yeah.
That's
the
main
aim
currently
and
how
I
hear
whatever
term
that
I'm
a
tram
an
approver
for
open
elementary
c
plus.
B
B
So
it
might
be
great
as
a
start
to
to
go
over
just
the
different
categories
of
things
that
that
we're
thinking
about
working
on
and
then
kind
of
discuss
meeting
times
for
these
things,
because
one
of
the
things
we
want
to
do
is
get
subject
matter.
B
So,
but
for
everyone
else
feel
free
to
add
items
to
the
agenda.
You
can
add
them
now.
You
can
also
add
them
before
we
meet
totally
open
and
I
see
bart
has
also
joined
us
bart.
Do
you
want
to
say
hi.
B
Awesome
glad
you
can
make
it
cool
beans
so
yeah,
maybe
a
good
overview
is
in
order.
So
as
far
as
getting
things
over
the
finish
line,
we've
identified
a
couple
different
pieces.
So
let
me
get
an
overview
to
this.
There's
hotel,
like
config
and
versioning,.
B
And
one
thing
that
we
need
to
do
is
have
an
understanding
of.
If
we're
going
to
say,
things
are
stable,
then
we're
saying
there
are
rules
about
how
we're
allowed
to
change
them
after
we
declare
them
stable
and
those
rules
allow
us
to
ensure
that
the
people
consuming
existing
instrumentation
aren't
going
to
be
broken
or
they
can
take
mitigating
steps
to
prevent
themselves
from
being
broken
so
that
we
can
live
in
a
place
where
we
can
provide
stability
to
our
end
users,
but
at
the
same
time
continue
to
improve
things
as
surely.
B
B
So,
basically,
every
time
we
publish
the
version
of
the
spec
there's
a
schema
for
all
the
conventions
that
are
published,
that
has
version
number
and
going
forwards.
We
would
like
to
have
changes
to
that
schema,
be
represented
along
with
a
list
of
translation
rules.
So
if
you
do
have
to
change
something
about
the
schema,
you
also
publish
the
translation
rules
along
with
that.
B
Alongside
of
that
as
a
piece
of
engineering,
we
need
to
develop
a
component
initially
in
the
collector
at
a
minimum
that
would
allow
an
end
user
to
programmatically
declare
what
versions
of
the
schema
they're
using
for
what
things
which
would
then
allow
that
component
to
automatically
perform
those
schema
translations.
B
So
that
is
a
technical
challenge,
that's
perhaps
more
on
the
the
open
telemetry
contributors
and
not
on
the
subject
matter,
experts,
but
I
want
to
bring
that
up
because
we
tend
to
just
want
to
talk
about
what
are
the
actual.
Like
schema
values,
that's
important.
B
We
need
to
solve
those,
but
if
we're
actually
going
to
declare
things
stable,
we
actually
have
to
ship
some
component
like
this
first
or
as
part
of
that,
otherwise
we're
we're
kind
of
putting
ourselves
in
a
tight
spot
right,
because
once
we
declare
something
stable,
if
we
don't
have
this
translation
service,
then
we
really
can't
change
anything
about
it
with
tracing.
Maybe
we
can
add
things,
but
where
this
gets
really
complicated
is
with
metrics
right.
When
you
start
talking
about
metrics
label
sets,
it
becomes
very
tricky.
B
Almost
any
change
you
make
is
essentially
a
breaking
change,
so
we
can
focus
on
resources
and
tracing
as
the
first
pass,
but
we
do
need
to
eventually
think
about
how
this
is
going
to
work
for
metrics,
because
we
also
want
to
have
metric
schemas
and
those
are
a
lot
more
brittle
than
than
the
tracing
schemas.
B
So
just
real
quick
does
that.
Does
that
make
sense
to
people?
That's
like
a
important
important
component.
We
got
to
build
cool,
so
that's
one
component,
the
other
component
that
we've
been
talking
about
in
this
group.
That
again,
is
not
the
conventions
and
we'll
get
to
that.
Real
quick
are
a
way
for
people,
library,
authors
and
instrumentation
authors-
and
I
say
library,
authors
because
eventually
open
telemetry
is
designed
to
allow
for
native
instrumentation,
so
a
web
framework
or
database
can
provide
the
instrumentation
themselves
and
maintain
it
themselves
rather
than
instrumentation.
B
B
You
have
to
write
and
there's
actually
a
lot
of
overlap
between
the
attribute
values,
you're
recording
on
your
traces
and
the
label
sets
you're
creating
for
your
metrics
and
given
that,
if
provided
the
user
gives
us
the
data
that
they
need,
it's
essentially
programmatic,
to
generate
the
proper
traces
and
metrics
for,
say
an
http
client
event.
You
have
http
client
span.
We
know
what
data
is
required
to
be
on
that
span.
B
So
I
would
encourage
people
to
to
have
a
look
at
some
of
the
work.
He's
done,
we're
going
to
try
to
recreate
some
of
that
work
in
other
languages,
because
otherwise
it
doesn't
matter
how
good
our
conventions
are
or
how
robust
they
are
if
they
are
sloppily
implemented
across
the
piles
and
piles
of
instrumentation
that
are
going
to
be
written.
B
B
B
So
in
order
to
do
that,
these
conventions
are
divided
up
by
subject
matter.
They
can
be
tackled
independently
to
a
large
degree,
and
we
tend
to
have
you
know,
subject
matter
experts
who
could
probably
give
us
some
advice
on
each
of
the
particular
subjects.
But
I'm
curious
for
the
people
who've
shown
up
here
today.
Are
there
like
particular
areas
or
subjects
semantic
conventions
that
you're
interested
in
working
on
like
james?
Is
there
like
a
particular
part
of
this,
that
you're
interested.
D
In
for
us,
the
semantic
invention
is
actually
quite
important.
I
think
we
are
trying
to
provide
a
kind
of
standard
data
model
for
like
everyone
around
the
company,
and
I
think
you
know
you
can
provide
a
bunch
of
benefits
from
that.
D
Like
you
know,
automatic
visualization
of
various
things
and-
and
you
know,
engineers
leveraging
like
kind
of
platform
level
benefits,
but
I
think
part
like
in
terms
of
specific
parts
of
the
semantic
convention,
we're
kind
of
interested
in
all
of
it
I
mean
the
most
commonly
used
sections
of
it,
for
us
would
be
http,
database
and
messaging
I'd
say
but
yeah,
that's
that's
pretty
much
our
use
case.
I'm
definitely
very
interested
in
that
awesome.
B
Do
you
have
subject
matter
experts
I
mean
you
yourself
might
be
one
I
know
atlassian
has
developed
an
internal.
You
have
your
own
schema
that
you've
developed
around
this
stuff.
So
I'm
curious,
like
do
you
feel,
like
you,
you've
got
stuff
that
you
would
like
to
change
about
these
things.
Yeah.
D
So
well
we
actually
developed
our
own
one
for
metrics,
because
at
the
time
hotels
there
wasn't.
D
So
we
just
decided
to
develop
it
and
we've
like
just
recently.
I
I
got
us
to
adopt
the
tracing
one,
so
we've
adopted
the
tracing
one
and
we've
made
our
own
metrics
one.
Sorry,
what
was
the?
What
was
that?
I
think.
B
The
question
is,
do
you
do
you
have,
or
do
you
think
atlassian
would
be
willing
to
provide
feedback
on
the
existing
conventions
say
for
starting
with
http?
Do
you
think
yeah
100?
We
are.
D
Yeah,
I
know
we
have
yeah,
we
have.
I
I've
been
working
on
it
lots,
so
I
have
a
lot
of
things
to
kind
of
I've,
even
yeah.
I
like
I,
I
kind
of
understand
the
the
yaml
data
structure
now
and
kind
of
get
all
that
and-
and
I
I
do
really
like
the
idea
of
what
you
said-
the
translations-
to
help
the
breaking
changes
kind
of
transition
smoothly.
D
I
really
do
like
that
idea
and
not
something
I
I
thought
about
breaking
changes,
but
I
hadn't
really
thought
about
tackling
it
in
that
way.
So
I
think
that
would
be
that'd
be
useful.
Definitely
in
terms
of
the
the
tracing
convention.
What
feedback
would
I
have
for
that?
I'm
not
sure
if
the
top
of
my
head,
I
think.
B
Yeah
yeah
yeah
yeah.
I
don't
think
we
need
to
to
go
over
it
now.
I
think
we
need
to
be
overview,
but
I
think
maybe
an
action
item
is,
you
know,
maybe
to
go
back
to
atlassian
and
figure
out.
What's
the
most
convenient
way
to
to
give
us
feedback
on
what's
what's
currently.
D
B
Either
you
know
things
that
are
missing
things
that
you
think
should
be
implemented
differently.
B
We're
also
interested
in
not
just
like
the
static
schema
of
what's
here,
but
also
configuration
like
to
what
degree
does
to
what
degree
are
you
frustrated
or
feel
the
need
to
actually
configure
some
of
this
stuff
right?
Because
for
a
lot
of
these
conventions,
that's
that's
instrumentation,
that's
embedded
somewhere
like
in
a
instrumentation,
you
install.
So
if
you
wanted
to
do
something
different
you
don't
you
can't
just
go
change
the
code
right,
you
have
to
configure
it
in
some
way
and
yeah.
B
We
do
hear
people
wish
they
could
configure
things,
but
we
actually
haven't
gotten
a
lot
of
concrete
feedback
on
what
they
wish
they
could
configure
or
how.
D
Yeah,
I
guess
the
way
we
do.
It
currently
is
kind
of
a
a
mix
of
well.
We
have
our
own
kind
of
published
metric
semantic
invention,
and
then
we
use
the
semantic
invention
pub
like
live,
published
library
for
java,
for
instance,
like
there's
a
package
that
we
import,
obviously
yeah,
it's
not
super
automatic.
We
have
to
kind
of
seek
that
stuff
out
for
ourselves.
D
So
if
there's
a
way
to
make
that
more
automatic
than
more
for
it,
yeah
in
terms
of
action
items
providing
kind
of
feedback,
is
it
something
put
on
the
dock
here
or.
B
Yeah
yeah,
I
can
put
it
down
as
as
an
action
item
here,
but
certainly
like
action
items.
Yeah.
D
B
B
We
filing
yours
and.
B
B
So
yeah,
if,
if
it's
just
written
feedback,
that
we
could
get
people
within
atlassian,
I
think
that
would
be
great
if
there
are
people
who
feel
like
they
could
actually
help
write
these
things
and
want
to
actively
contribute
by
filing
issues.
Coming
to
these
meetings
participating
in
the
community.
That's
also
really
helpful.
B
One
thing
we're
just
trying
to
figure
out
is
get
an
understanding
of
who
these
people
are
and
like
what
you
know
time
zones
they're
in
when
they
can
actually
meet
so
that
we
can
see
if
we
can
get
like
a
sql
working
group
together
of
all
the
people
who
want
to
work
on
sql
and
likewise,
a
messaging
working
group
together.
Currently,
the
meshing
working
group,
for
example,
is
8
am
on
thursday,
which
is
probably
not
great
for
anyone
in
australia,
8am
pacific
on
thursday
yeah.
B
But
that's
when
the
europeans
who
want
to
work
on
this
problem
are
meeting
about
it.
So
so
I
guess
that
would
be
the
other
other
action
items
just
for
people
who
want
to
get
face
time
or
come
to
these
meetings,
like
just
understanding
what
subject
they're
interested
in
and
like
when
roughly
they
can
meet,
and
I
can
try
to
help
take
that
information
and
maybe
figure
out
when
we
should
have
some
like,
like
specific,
like
some
schedule,
some
workshops
to
work
on
work
through
some
of
these
specific
domains.
D
Yeah
sounds
great.
Definitely
we'll
get
some
get
some
feedback
going
from
my
side,
yeah.
B
Yeah,
I
guess,
am
I
pronouncing
your
name
correctly.
Sorry.
B
Okay,
likewise,
for
for
splunk,
do
you
feel
there
are
people
at
splunk
who
could
either
contribute
written
feedback
or
ideally
like
help
help
develop
out
some
of
these
schemas.
C
I'm
very
certain
that
a
bunch
of
our
team
is
actually
involved
in
this
already
awesome
yeah,
so
we
we
have
been
contributing,
I
think
actually
splunk
is
one
of
the
biggest
contributors
to
the
overall
project,
or
at
least
it
was
a
few
months
ago.
B
Sure,
oh
yeah,
totally
totally
in
general,
I
just
mean
like
like
for
this
specific
specific
subset
of
stuff.
I
know
it's
something
ivo
cares
about,
or
at
least
I've
talked
to
him
about
it
briefly,
but
I'm
just
curious
if,
if
this
is
a
place
like
splunk
could
put
some
subject
matter,
experts
on
or
or
some
engineering
effort
into
things
like
this
schema
versioning
plug-in
for
the
collector,
for
example,.
E
B
Already
so,
with
all
of
that
said,
maybe
are
there
like
actual
topics
around
the
semantic
conventions
themselves
that
the
people
like
to
dive
into
or
do
people
have
any
overview
questions
at
this
time
or
like,
like
project
overview
info
they'd
like
to
sort
out.
A
Another
question
so
sierra-
and
I
are
really
I
mean
obviously
they're
interested
in
mobile,
run
and
rum
itself-
is
a
really
big
topic.
Yes,
including
of
course,
because
you
probably
won't
include
web
rum.
A
I
was
wondering
if
you
had
any
thoughts
or
ideas
about
how
to
like
how
we
should
approach
this
very
large
topic
and
kind
of
peeling
off
pieces.
Just
it's
sometimes
hard
to
know
exactly
where
to
start.
B
Yeah,
I
mean
I've
even
seen
at
least
one
rum
proposal
flyby
that
was
proposing
to
make
it
an
entirely
separate
signal
of
events
which
I
don't
want
personally,
but
I
think
that
that
just
goes
to
show
how
how
big
of
a
topic
it
is
right,
like,
unfortunately,
I'm
not
super
familiar
with
mobile
rum,
I
mean
I've
done
some
mobile
development,
so
I
do
understand
john.
B
When
you've
talked
about
it
in
the
past,
you
talked
about
how
it's
much
more
of
an
event
reactor
system,
and
so
this
concept
of,
like
transactional
tracing,
doesn't
really
line
up
with,
what's
actually
helpful
when
you're
trying
to
look
at
these
systems,
so
I
think
that's,
that's.
Maybe
part
of
the
barrier
here
is
just
maybe
figuring
out
some
ground
rules
of
like
what
what
is
the
problem
domain
from
and
like
what?
What
are
people
trying
to
do
with
it?
I
don't
much
like
with
sampling
and
some
other
subjects.
B
A
Yeah,
I
was,
I
was
actually
telling
students
almost
exactly
the
same
thing
a
couple
hours
ago,
I'm
like
yeah.
This
whole
community
has
a
decade
plus
experience,
building
out
instrumentation
for
high
high
performance
back-end
servers,
and
this
is
nothing
at
all
like
that,
and
it's
a
totally
different
way
of
thinking
about
the
world.
Yeah
yeah.
B
I
I
think
the
other
thing
I
would
say
is
whenever
we
try
to
integrate
one
of
these
new
signals.
There's
this
kind
of
reflex
action
to
just
take
what
was
already
in
existence,
some
standalone
system
and
just
kind
of
like
pile
it
in
it
would
be
easy
to
say
like
okay.
Well,
rum
is
events
logs
or
events
like
we'll
just
make
a
bunch
of
blog
conventions
for
rum
and
like
on
the
surface
that
might
solve
things.
B
But
a
thing
I
think
we
want
to
do
with
open
telemetry
is
it's
now
an
integrated
data
stream
and
the
value
you
get
out
of
that
is
having
enough
coral
correlative
data
like
having
the
data
structured
in
such
a
way
that
it
is
possible
to
apply
machines
to
understanding
this
data.
I
don't
even
mean
like
ai
ops
or
something
fancy
like
that.
I
mean
just
literally
being
able
to
index
this
stuff
in
such
a
way
that
the
operator
is
not
having
to
connect
the
dots
in
their
head.
B
The
way
that,
for
example,
with
tracing
you
know
when
you're
looking
at
logs.
You
want
to
know
all
the
logs
that
were
in
this
transaction
and
if
you
don't
have
a
trace
id,
that's
really
obnoxious.
That's
like
traditionally,
just
like
an
obnoxious
task,
or
you
have
to
kind
of
hodgepodge
things
in
order
to
do
it
at
any
rate,
and
so
the
advantage
of
having
a
transaction
id
is
now
this
very
common
task
that
the
operator
wants
to
do,
which
is
just
I
got
an
error.
Show
me
all
the
logs
in
this
distributed
transaction.
B
That
related
to
that
error
is
like
just
the
thing
that
the
back
end
can
do
for
them,
and
so
I
think
that
would
be.
My
question
with
rum
is
like
what
are
those
like
common
data
collection
tasks
that
the
operator
is
trying
to
do
and
like
what
data
structure
allows
the
back
end
to
actually
index
things
so
that
it
does
it
for
them.
So
they
don't
have
to
do
that.
Crap
themselves.
C
Yeah,
I
think
we've
developed,
we've
developed
a
reasonable
understanding
of
what
customers
are
looking
for.
I
think
we
sort
of
been
developing
this
product
from
scratch
here,
there's
of
course,
a
lot
of
stuff
out
there
with
firebase
being,
of
course,
the
main
you
know
the
call
it
de
facto
standard
for
have
on,
but
we
have
a
team
that
does
webram
as
well,
and
I
think
we've
learned
a
lot
we'd
be
happy
to
share.
C
You
know
a
broader
view
of
at
least
what
we
believe
people
are
looking
for
to
your
point.
That's
exactly
what
we're
doing
we're
sort
of
a
lot
of
the
conventions
that
we're
using
right
now
have
not
been
ratified,
but
we
are
trying
something
and
we
would
love
to
get
the
community
more
involved
for
sure.
B
No
idea
what
that
even
means
there
isn't
even
a
little
pop-up
thing,
anyways,
whatever
weird
but
yeah.
No,
that
would
be.
That
would
be
super
helpful
to
to
just
get
an
understanding
of.
I
don't
honestly,
don't
even
think
this
is
like
industry
secret
stuff
right
like
like
just
what.
B
What
what
are
the
best
data
structures
to
do
this,
and
maybe
I
should
have
mentioned
not
just
to
to
do
rum
itself,
but
even
though
it
might
be
somewhat
different
from
tracing
and
metrics
you're
still
going
to
want
to
be
able
to
correlate
those
things
and
that's
a
thing
that
end
users
are
probably
not
asking
for
yet
because
nobody
does
it
yet
because
nobody
has
this
like
stream
of
data,
but
just
like
getting
trace.
Exemplars
in
your
metrics
is
a
really
powerful
feature
once
once
the
data
you're
consuming
has
crossed
those
things
with
each
other.
B
You
can
start
building
really
great
tools
that
again
let
the
end
user.
Do
this
really
common
task
they're
trying
to
do
which
is
like
I'm
seeing
all
these
500s
in
my
dashboard
show
me
like
the
examples
of
transactions
that
are
creating
these
500s
they're
they're.
Doing
this
already,
it's
just
like
they
have
to
hunt
around
and
guess,
because
the
data's
not
connected
with
open
telemetry.
Now
it's
actually
connected.
So
that
would
be
the
question
with
rum.
B
A
B
Yeah,
I
I
I
think
I
think
an
otep
would
be
good
it
just
it
might
be
easier
as
a
first
pass
to
put
it
in
as
a
google
doc.
Just
it's
sometimes
a
little
bit
easier
to
get
feedback
or
edit
there,
but
an
otep
is
fine.
I
just
feel
like
the
the
commenting
tools
in
github
are
a
little
clunky
but
they're
getting
better.
I
guess,
as
long
as
you
make
sure,
every
sentence
is
on
its
own
line.
You
know,
but
yeah
either
either
way.
B
I
think
one
thing
I
will
say:
we've
discovered,
that's
a
little
hard
with
oteps
we
just
went
through
with
the
sampling
is
it
can
be
like
is
the
point
of
an
otep
to
like
describe
a
problem
domain
or
is
the
point
of
an
otep
to
propose
a
solution
and
with
sampling
we
kind
of
ended
up
with
these,
like
because
people
needed
all
this
backstory.
B
B
A
B
Yeah
it,
I
think
you
know
it
it's
iterating
these
things
I
find
just
helps
like
in
the
past
I've
just
found,
like
I
start
with
a
google
doc,
I
get
feedback
there.
I
then
like
take
a
stab
at
ot
based
on
that
then,
like
one
or
two
more
stabs,
then
it
gets
accepted.
B
A
There
is
also
a
proposal
floating
out
not
officially
yet
in
the
there's
a
channel,
and
so
you
have
cncs
black
client-side
telemetry
channel
to
start
a
rum
sake
to
actually
get
a
group
of
people
together
because,
like
I
know,
android,
but
I
don't
know
web
and
ios,
but
getting
a
people
a
bunch
of
people
together
who
are
interested
in
rum
to
talk
through
and
probably
championing
all
this
stuff.
A
B
B
I
don't
I'm
kind
of
here
nor
there
I
know
I
mean
this
is
something
some
feedback
we
actually
heard
from
atlanta
atlassian,
which
is
like
there's
like
so
many
cigs
in
meetings.
It
can
be
a
little
like
crazy
making
about
trying
to
figure
out
how
to
do
it.
I
don't
know
how
to
solve
that
problem.
Yeah.
One
of
the
questions
that
was.
A
B
This
instrumentation
sig
is
kind
of
like
the
first
one
of
these,
really,
where
I
mean
well,
I
guess
it's
just
like
all
the
other
spec
work,
we're
trying
to
figure
out
what
what
what
is
standard
across
languages,
that
we
want
to
write
down
in
the
spec,
so
that
there's
some
self-similarity
and
we're
producing
the
same
data
and
kind
of
beyond
that,
it's
sort
of
just
up
to
the
individual,
like
contributors
and
language
sigs,
to
decide
like
we
always
want
to
leave
some
amount
of
space
for
people
to
go.
B
B
Talking
about
specs
and
solutions
like
hits
a
hits,
a
wall
really
fast
and
it's
it's
very
helpful
to
have
prototypes
that
come
along
with
this
stuff
in
a
couple
languages,
because
there's
a
lot
of
people
who
can
then
just
look
at
the
code
or
run
the
thing
and
get
a
better
understanding
than
trying
to
dig
through
a
bunch
of
spec
language.
So.
B
Yeah
so
yeah,
I
would
say
just
a
meeting:
let's
maybe
make
it
part
of
the
instrumentation
sig
for
now,
and
I'm
happy
that
we
can
schedule
meetings
like
whenever
again.
I
think
the
next
step
would
just
be
to
find
the
people
who
are
interested
in
this,
including
having
some
amount
of
engineering
resources
tapped
to
to
be
prototyping.
This
stuff
and,
like
I
know,
java
plus
java
plus
python,
I
think,
is
usually
good
or
python.
Like
thing
python
is
not
at
all
relevant.
I'm.
B
Right
so
to
switch.
A
B
B
A
B
B
B
B
B
Sql
is
like
a
little
bit
special
because
sql
actually
is
a
protocol,
and
so
even
though
there
is
some
variation
between
what
the
different
sql
implementations
do,
it
does
make
a
lot
of
sense
there
to
be
like
here's,
the
general
sequel
stuff
and
here's
the
you
know.
Here's
the
like
extensions
for
the
different
kinds
of
sql
systems,
like
here's,
the
postgres
extensions
to
that,
and
I'm
just
kind
of
curious
do
people
have
like.
D
I
something
we've
discussed
a
little
bit
in
my
team
is,
for
example,
there's
the
database
convention
and
what
was
kind
of
a
bit
a
little
bit
confusing
to
us
is
database,
and
then
it
lists,
like
you,
know,
all
the
different
database
types
that
it
recognizes.
D
You
know
postgres
and
you
know
all
the
sql
ones
and
then
like
dynamodb,
and
you
know
all
those
all
those
databases
and
then
but
then
there's
like
kind
of
like
the
flip
side,
where
there's
an
aws
kind
of
like
section
of
the
convention,
or
I
guess
it's
kind
of
extending
the
convention.
I
know
anna.
You
worked
on
that
and
I
think
to
us.
It
was
a
little
bit
unclear
like
okay,
which
part
of
the
convention
do
we
implement
in
our
in
our
stuff.
D
Do
we
use
the
aws
section
of
the
convention
or
do
we
use
the
database
section
of
the
convention
because
they
both
define
database
like
they
both
define
dynamo
db
as
part
of
it?
Is
that
a
problem?
Maybe
it
isn't
a
problem?
I
don't
know,
but
it
kind
of
does
tap
into
that
specific
first
general
kind
of
problem.
B
Yeah,
I
think,
if
you
look
at
at
these
conventions,
I'll
post
them
into
the
the
chat
here
for
quick
access,
you
can
see.
There
are
some
cases
where,
like
with
cassandra,
for
example,
there's
like
a
cassandra
namespace
and
a
bunch
of
cassandra
specific
stuff
goes
under
there,
and
that
makes
a
lot
of
sense
to
me.
B
But
there
isn't
a
lot
of
information
about
how
should
more
generic
aspect
attributes
be
implemented
for
cassandra,
and
maybe
it's
just
obvious
what
you're
supposed
to
put
in
db
connection
string
for
cassandra
or
does
it
even
use
that?
But
it's
it's
sort
of
like
undefined.
It
feels
like
a
hole
in
the
spec
and
then,
if
you
look
at
the
the
sequel
stuff
it
kind
of
has
like.
B
D
But
it
looks
like
those
my
sequel
examples
are
kind
of
non-specific
to
to
my
sequel.
I
don't,
if
I'm
with
the
right
thing,
but
they
kind
of
have
oh
well,
they
they
have
db.system,
but
that's
really
kind
of
general,
like
that's
a
general
attribute
and
db.connection
string.
I'm
sure
that
also
applies
to
all
databases,
essentially
yeah.
B
The
the
fact
that
they're
examples
to
me
is
like
a
smell
if
I'm
trying
to
implement
a
schema
and
instead
of
just
having
a
schema
for
my
sequel,
I'm
looking
at
like
a
single
example
and
trying
to
smell
what
it's,
what
it
should
be
this
it
just
feels
like
like
one.
I
think
we
just
need
to
flush
all
this
out
and
just
be
even
if
we
do
have
generic
attributes
for
every
popular
type
of
system.
B
We
should
add
a
section
to
this
that
says
specifically:
here's
how
you
should
do
it
for
my
sequel
and
postgres,
and
this
will
get
very
big,
but
I
think
that
that
pedantic
specificity
is
what
we
need
to
be
doing
here
and
that
will
also
maybe
at
least
show
us
if
there
are
places
where
we're
really
overloading
these
generic
values
or
just
like
places
where
that's
that's
kind
of
breaking
down.
Where
we
end
up
having
to
have
a
like.
B
I
think
you
were
mentioning
where
we
end
up
having
to
have
a
database
specific
value,
but
that
kind
of
mirrors
a
more
generic
value.
So
you
feel,
like
you,
end
up
having
to
double
report
it
in
some
way
or
or
how
would
a
back
end
interpret
one
of
these
being
present
versus
the
other
that
that
that
just
seems
like
like
detail,
work
that
that
we
have
to
do,
and
I
worry
a
little
bit
about
whether
we're
going
to
discover
that
process.
B
Some
of
these
some
of
these
more
generic
things
are
actually
just
kind
of
like
loosey-goosey
and
maybe
just
like
shouldn't,
even
be
there
or
or
should
be
factored
out
differently,
in
which
case
that's
a
breaking
change,
which
is
why
I
don't
want
to
declare
any
of
this
stuff
stable
until
we've.
We've
really
gotten
through,
like
that.
D
Yeah,
perhaps
if
we
do
find
some
attribute
to
be
too
general,
then
you
can
perhaps
I
split
it
up.
Almost
I
don't
know
if
splitting
it
up
is
the
right
word
to
use,
but
as
you
say,
we
probably
need
that
resistance
to
breaking
change.
E
D
B
Yeah
yeah
this
stuff
looks
way
more
flushed
out
here.
Obviously
I
think
you
know
we
just
had
some
questions
on
the
call
where
it
doesn't.
B
I
think
maybe
the
same
thing
we
see
in
the
cassandra
details
where
it
goes
into
all
of
the
the
specifics,
but
maybe
there's
the
common
attribute
table
is
like
incomplete.
B
Or
at
any
rate,
doesn't
describe
like
maybe
there's
like
a
need
to
be
kind
of
complete
with
these
tables.
Even
if
the
answer
for
some
of
these
values
is
we
don't
use,
this
don't
fill
this
out
when,
when
implementing
this,
this
database
type,
that
probably
would
help
clear
things
up
for
for
implementers
just
just
to
have
all
of
these
be
complete.
F
B
D
Yeah,
I
think,
like
I
mean
I
don't
know
the
details
of
of
every
single
attribute
here
but
like
if
there
is
an
opportunity
that
say
a
db.cassandra
attribute
could
just
be
a
general
attribute
like
or
map
at
least
map
to
like
just
a
commonly
used
one.
Then
I
don't
think
there's
like
a
need
to
have
like
cassandra
specific
attributes
if
it's
something
that
can
be
kind
of
generalized,
but
I
think
I
think
that's
kind
of
beneficial,
because
then
you
get
more
things
emitting
a
common
like
at
least
closer
data
to
each
other.
D
B
Yeah,
I
I
think
what
we
found
is:
there's
there's
like
three
kinds
of
attributes:
there's
general
attributes
that
are
basically
universal.
I
guess
they're,
not
even
they
don't
even
tend
to
be
generic
honestly.
They
tend
to
be
just
like
shared
protocols
like
ip
addresses
and
stuff
like
that,
but
then
there's
general
attributes
that
relate
to
a
switch
statement.
B
B
I
think
we
don't
tend
to
like
like
spell
that
out
in
enough
detail
in
these
conventions
right
now,
but
but
that
would
generally
work
right
like
if
you're
saying
the
statement
goes
here,
how
you
parse
it
depends
on
whether
this
is
you
know
cassandra
or
my
sequel
and
then,
if
the
back
end
has
like
a
db
type
value
that
it's
never
seen
before
or
just
doesn't
understand,
it
can
then
fall
back
to
doing
something
semi-specific
with
that
information
where
it's
like.
B
B
Yeah,
so
so
that
might
be
just
like
a
basic
way
as
like
a
first
pass
for
each
one
of
these,
schemas
is
to
say
we
want
to
go
in
and
for
every
supported
database
complete.
B
The
mapping
like
make
a
make
a
pull
request
that
goes
into
that
section
of
the
spec
and
just
literally
adds
like
completes
the
table
so
that
the
top
of
every
table
starts
with
all
the
generic
attributes
and
what
you
do
with
them
like
every
single
one,
including
saying
like,
don't
use
it
and
then
goes
into
all
of
the
extensions.
So,
when
you're
looking
at
implementing
this,
it's
just
a
single
table
with
everything
in
it
and
someone
could
make
a
pr
for
each
each
individual
database
type
until
we
get
those
completed.
B
That
might
be
like
just
practically
like
a
a
good
way
to
to
start
chewing
on
this
elephant.
D
Yeah,
it's
it's
a
it's
a
it's
a
big
one!
Isn't
it
yeah
because,
like
I'd
personally,
I'd,
be
very
scared
to
try
and
write
that
kind
of
thing?
When
I
don't
really
know
the
specifics
of
each
database,
you'd
kind
of
want
someone
yeah
to
to
know
each
database
yeah.
B
But
this
would
maybe
be
an
easy
task
to
farm
out
to
subject
matter.
Experts
be
like
well.
If
you
want
to
get
involved
like
step
one.
Could
you
just
like
complete
filling
out
this
table
like
we've
got
some
generic
attributes
up
here?
Could
you
just
fill
out
the
my
sql
table
to
include
how
all
those
should
be
handled
and
if
you
run
into
any
ambiguity
or
confusion,
then
like
bring
that
up
with
the
group
like?
B
Yeah
and
it's
five
pacific
time
so
we're
we're
kind
of
at
time
here.
So
these
all
sound
like
good
next
steps,
if
we
could
get.
I
think
the
thing
we're
looking
for
here
are
engineers
to
help
with
some
of
the
open,
telemetry
stuff,
subject
matter:
experts
who
are
willing
to
take
a
crack
at
completing
these
convention
tables
for
their
area
of
expertise
and
maybe
even
just
general
feedback
from
atlassian
and
other
organizations
just
to
just
to
get
us
rolling
on
what
we
need
to.
B
Cool
sounds
good
alrighty
for
people
who
are
awake,
thursday
8
a.m,
pacific
we're
gonna,
hopefully
dig
into
messaging
stuff.
Specifically,
so
if
anyone
can
make
those
meetings,
I
will
see
you
there.
Otherwise,
I
will
see
you
all
next
week
and
in
the
meantime,
join
the
hotel,
instrumentation
slack
channel,
and
we
can
talk
there.