►
From YouTube: 2020-11-02 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
A
D
F
E
No,
no,
no,
there
isn't
enough
time
to
drink
before
the
noon
game.
If
you
live
in
california,
those
who.
F
A
G
We
have
that's
not
the
one.
There
we
go
14
in
the
to
do
four
items,
that's
in
progress
with
linked
prs
and
48
that
have
been
completed.
G
I'd
like
to
point
out
that
of
the
ones
we
are
concentrating
on.
In
order
to
conclude
the
trace,
spec
freeze
activities,
we
have
two
that's
in
the
to
do
a
two.
That's
in
the
link,
br
that
have
that's
related
to
trace
they've
made
some
progress,
but
they
need
to
be
finished
up
in
order
to
be
able
to
close
out.
G
There
is
one
more
that
was
found
on
friday
with
the
issue
triage
meeting,
but
that
was
marked
as
a
protocol
issue.
That's
not
related
towards
the
trace
fact
for
you.
Specifically,
it's
got
morgan's
name
on
it
and
it
actually
this
one's
kind
of
in
progress
right.
A
G
So
I
will
also
be
highlighting
the
progress
of
this
for
the
spec
meeting
tomorrow
and
trying
to
pick
a
time
that
would
be
suitable.
I
think
the
conversations
from
the
triage
meeting
on
friday
was
trying
to
pick
a
time
suitable
this
week
in
order
to
go
through
the
concluding
activities
of
freezing
the
trace,
spec.
G
The
vast
majority
of
the
issues
that's
left
are
metrics
issues
so
of
the
14
like
almost
all
of
them
are
are
metrics
related.
So
as
soon
as
we
get
towards
concentration
of
that,
we
can
look
for
the
next
milestone
to
hit
for
related
to
the
spec,
and
also
we
can
start
tracking
how
the
language
sigs
are
implementing
the
trace
spec.
G
Let
me
see
so
that's
the
status
of
our
ga
issues.
I've
got
other
things
related
to
ga,
but
they're,
not
as
important.
I
I
I
put
an
item
down
here
to
talk
about
ga
project
planning
but
looks
like
we've
got
other
more
interesting
stuff
to
talk
about.
First,
there
is
sorry
I'll
just
cover
this
one.
Last
issue
I
mean
there's
one
issue
related
towards
tracking
requests
for
instrumentation
of
the
language
six.
G
So
the
context
around
this
is
we're
coming
across
some
users.
At
my
step,
that's
asking
for
like
hey,
you
know,
is
there
auto
instrumentation
on
this
framework
for
this
language?
I
can't
seem
to
find
it
here
is
there?
Is
there?
Is
it
coming
soon?
Is
it
gonna
be
in
the
release?
Is
it
for
ga
like
what
to
expect
so?
Some
of
these
people
have
may
not
have
worked
closely
with
open
source
before,
but
would
also
like
visibility
into
a
roadmap.
G
G
I
did
a
quick
search
right
now.
You
can
do
an
on
github
search
by
org
and
label
instrumentation.
We
got
some
of
them
like
in
the
python
sick,
and
is
there
another
one?
Okay,
it's
mostly
python,
but
like
I'm
just
proposing
that
as
a
starting
point
in
order
to
be
able
to
track
across
different
repositories.
So
that
way,
it
makes
it
easier
for
a
user
to
be
able
to
discover
requests
for
instrumentation
and
to
also
address
the
roadmap
question
as
to
like
hey.
When
is
this
going
to
come
out?
G
If
it
could
be
then
tied
towards
a
milestone?
For
example,
go
contrib
has
sorry
yeah
go
contrib,
it's
got
a
great
milestone.
This
is
an
example
of
something
that's
like
what
I
think
would
help
users
who's
asking
this
question
right.
It's
got
a
due
date.
It's
got
a
tracking
issue
with
instrumentation.
Oh
this
one's
actually
related
towards
upgrading
that,
but.
H
G
It
it
will
then
be
very
self-serve
for
users
who
want
to
find
out
whether
their
instrumentation
is
available
or
coming
soon
in
a
certain
language
and
in
order
to
filter
through
all
of
these
requests.
I'm
not
sure
how
much
it's
going
to
be
coming
in,
like
I
don't
know
whether
it's
going
to
be
like
a
thundering
heard,
like
a
large
gate
of
like
people
just
filing
like
dozens
and
thousands
or
hundreds
of
issues,
but
in
order
to
make
the
process
a
little
bit
more
manageable.
I'd
also
like
to
take
a
note
from
golang.
G
Golang
has
a
procedure
of
has
some
process
in
order
to
be
able
to
figure
out
like
what
should
we
work
on
that's
most
important,
that
users
are
asking
for
and
so
they're
using
the
github
reactions.
It's
the
emoji
icon
that
you
can
click
on
for
an
issue
in
order
to
do
the
voting.
So
maybe
some
people
already
know
this
but
like
if
you
ever
file
an
issue
in
golang
they're
like
please
do
not
plus
one
or
me
too
comment.
G
Please
use
the
reaction
in
order
to
do
that
in
order
to
be
able
to
vote
on
issues.
You'd
like
to
see
addressed,
for
example,
this
one's
coming
up
in
golang
2.0
has
garnered
a
lot
of
attention
and
I
propose,
like
maybe
just
the
heart
emoji.
G
So
that
way,
the
issue
has
to
be
structured
in
a
way
in
order
to
say,
hey,
I'd
like
to
propose,
we
have
this
framework
instrumented
in
this
language,
something
something
something
something
and
the
reasons
for
it
and
we
can
gauge
and
it
can
help
the
language
maintainers
understand
what
is
most
desirable
by
taking
a
look
at
the
github
reactions
or
the
number
of
git
rehab
reactions,
because
you
can
sort
by
them
go
into
issues
and
sort
by
most
github
reactions.
G
This
is
just
a
management
process
if
it's
obvious,
which
one
needs
to
be
implemented.
It's
like
oh
yeah.
We
should
we
can
get
this
framework
implemented.
Then
maybe
this
is
not
as
helpful,
but
in
order
to
sift
through
a
large
number.
That's
what
I
propose
anyways
want
to
bring
that
to
the
table
here
for
the
language
maintainers
to
consider.
So
that
way
we
can
have
some
of
the
instrumentation
frameworks
implemented.
I
Could
I
suggest,
maybe
in
a
readme
or
wherever
we
list
or
talk
about
the
instrumentation,
we
provide
just
providing
a
link
or
comment
there
for
how
to
submit
requests
for
other
instrumentation
or
see
the
list
of
outstanding
stuff,
just
wherever
we
list
that
we
should
probably
mention
how
people
can
request
new
stuff.
However,
you
want
to
do
that
in
your
sig.
A
Yeah,
I
think
it's
great.
This
is
going
to
bring
a
lot
of
organization
to
these
requests
for
instrumentation,
which,
with
the
tracing
sdk
tracing
api,
is
already
in
release
candidate
mode,
we're
going
to
start
seeing
these
piling
up
soon
and
we
need
a
process
for
all
the
maintainers
on
this
call
to
be
able
to
manage
these,
because
if
we
don't,
I
suspect
many
of
them
are
going
to
feel
pretty
overwhelmed
thoughts
from
anyone
else.
J
I
think
it's
a
good
idea
as
long
as
this
is
only
used
for
instrumentation
suggestions,
yeah.
A
I
see
that,
like
we're,
gonna
have
two
categories
of
things:
sort
of
when
you
think
of
like
road
maps
and
planning
planning.
There's
gonna
be
two
categories
of
things
that
really
pile
up.
There's
gonna
be
general
feature
requests
like.
Can
you
add
logs
to
open
telemetry,
or
can
you
add
profiles
to
open
telemetry?
Can
you
add
this
new
spec
feature
and
implement
it
in
the
sdks,
and
I
think
we
already
have
the
mechanisms
to
handle
those
right?
That's
that's
github
issues.
A
That's
meetings
like
this
one,
that's
the
specs
meeting
and
and
getter,
and
I
think
we
do
a
relatively
decent
job
of
that.
But
the
second
is
these
instrumentation
requests,
and
I
see
these
coming
in
10-fold
to
actual
feature,
requests
or
20-fold
over
actual
feature
requests,
because
this
is
the
real
to
a
lot
of
end
users.
This
is
the
real
value
of
the
project,
and
so
I
I
think
I
agree
both
you
and
andrew,
like
we
don't
need
this
process
for
general
feature,
requests
or
requests
where
people
say
hey.
A
I
want
to
change
this
thing
in
a
specification,
but
we
are
going
to
need
it
for
people
doing
flybys,
saying
hey,
I
want
to
add
spring
support
for
java,
or
I
want
to
add
grpc
support
for
these
three
languages
or
something
else
and
there's
just
going
to
be
so
many
of
those
that
it.
I
think
we
need
a
lot
more
rigor.
A
G
I
guess
the
action
I'm
the
the
first
action
I'm
asking
for
is
like
for
the
instrumentation
label
to
be
available
across
the
language
yep
and
then
from
there
that
that
can
lead
on
to
the
process
of
these
other
two
action
items.
These
other
two
suggestions
right.
E
Should
we
also
create
issue
templates
for
instrumentation
proposals
like
there's?
There's
certain
information,
for
instance,
npm
provides
like
a
weekly
download
count
where
you
can.
You
know
very
quickly
estimate
the
scale,
and
I
I
know
from
experience
that
if
you
don't
have
a
template,
most
people
are
just
going
to
put.
Can
you
instrument
spring
in
the
title
and
then
the
description
will
be?
Can
you
instrument
spring,
and
you
know
if
it's
spring
or
it'll,
be.
A
Yeah,
that's
a
good
idea,
forgive
my
ignorance
can
so
these
I'm
guessing,
I'm
anticipating
that
most
of
these
issues
will
be
filed
against
language
sigs.
Is
it
possible
in
github
to
have
issue
templates
that
span
repos
or
do
we
have
to
go
create
like
one
for
java,
one
for
javascript
one
for
go
and
so
on.
A
A
Okay,
so
in
that
case
I
think
andrew
then
we
add
on
to
this
recommendation
that
language
sig
owners,
what
once
their
sdk,
is
a
release.
Candidate,
create
a
template
for
instrumentation
requests
pretty
quickly,
because
otherwise
they
risk
things
really
piling
up
on.
A
G
H
Yeah,
these
were
a
couple
questions
that
came
up
in
the
ruby
sig
last
week
and
yeah.
Stop
me
if
this
is
not
a
good
place
to
talk
about
them
or.
A
H
Yeah
I
felt
like
this
was
a
good
first
first
stop
and
if,
at
all,
this
seems
like
it's
more
of
a
spec
thing,
let
me
know
and
I'll
at
least
re-raise
it
there.
But
there
are.
There
are
a
couple
situations
where
you
can
end
up
having
potentially
nested
clients,
fans
with
instrumentation,
and
I
just
wanted
to
see
how
other
sigs
are
approaching
this,
and
there
are
kind
of
two
two
ways
I
see
this
happening.
Currently,
one
is
the
situation
where
you
have
http
libraries
that
wrap
other
http
libraries.
H
This
is
pretty
common
in
ruby,
like
net
http.
The
built-in
http
client
is
like
pretty
low
level.
So
the
link
here
is
the
issue.
H
443
kind
of
has
this
proposal
to
essentially
standardize
a
place
in
the
context
to
put
attributes
for
the
ultimate
final
kind
of
http
span,
the
one
that's
really
going
to
be
the
client
span,
because
you
don't
have
access
to
these
things
that
doesn't
exist
yet,
when
you're
operating
on
one
of
these
kind
of
higher
level
wrapping
libraries
and
that
actually,
this
seems
pretty
good
to
me
actually
as
a
good
solution
to
this
particular
problem.
C
I
can
comment
on
javascript
and
java,
auto
instrumentation,
so
first
of
all,
first
of
all
specification
clearly
stay
safe,
that
you
cannot
have
nasty
clients
pass
client
spam
should
have
only
remote
server
span
of
the
child.
There
is
a
sentence
like
that
in
specification,
and
so
when,
in
java
instrumentation
we
try
to
solve
this
nasty.
Both
servers
are
expands
and
client
sides.
There
should
not
be
native
spans.
C
We
we
went
to
like
an
opposite
approach.
As
I
would
say,
we
have
the,
for
example,
if
you
have
aws
sdk
call,
which
underneath
users,
http
client
library,
so
then
aws
sdk
will
create
a
client
spam
and
lower
level
network
level
or
transport
level.
Instrumentations
can
add
attributes
on
already
existing
client
spam.
C
So
we
we,
like
we
push
attributes
from
from
down
from
lower
level
to
upper
level,
where
your
suggestion
does
vice
versa,
from
upper
level
to
low
level.
I
think
this
essentially
both
way
may
work.
The
the
main,
the
main
point
that
you
have
only
one
span
which,
like
aggregates
attributes,
both
from
higher.
B
H
Yeah,
I
think
that
makes
sense,
and
there
was
kind
of
a
part
two
to
this
question
for
me,
which
was
like
well
what
about
like
elasticsearch,
it's
kind
of
a
database,
but
it
uses
http
underneath
so
you
kind
of
want.
You
know,
there's
an
instinct
to
want
to
make
that
elastic
search
span,
a
client's
fan.
But
then
what
do
you
do
about
the
http
request,
but
follow
him.
C
So
because
for
in
java
we
exactly
argued
that
elasticsearch,
that's
a
db
call
and
it
should
have
most
and
foremost
database
semantic
convention,
not
http
semantic
convention.
C
H
C
C
I
I
Seems
pretty
straightforward
to
me
there's
maybe.
I
Where
you
end
up
with
a
bunch
of
stacked
fans
that
are
like
look
kind
of
similar,
but
you
know
that's
fine.
N
C
I
Approaches
I
think
this
has
come
up
before
even
within
http,
as
what
is
the
difference
between
a
sort
of
logical
request
versus
a
mechanical
request
was
maybe
the
language
used
in
the
past.
You
know
even
with
something
like
an
http
client.
I
Like
a
you
know,
request
from
python
it's
possible
that
what
the
end
user
called
was
make
this
request
and
then
under
the
hood
it
made
a
request,
saw
a
503
redirect
made
another
request
so
on
and
so
forth.
I
I
think
that
dyna
trace
folks
were
trying
to
address
this
in
the
past,
but
I
can't
remember
where
that
ended
up
landing,
but
it
seems
to
me
that's
that
this
is
like
we're
talking
about
databases,
but
it's
the
same
separation.
You
have
a
a
logical
request
and
then
underneath
it,
the
maybe
several
multiple
mechanical
or
you
know,
networking
requests
that
actually
occur.
C
I
M
Those
yeah
can
those
sub
pieces
be
events
on
the
span
kind
of
like
the
grpc
modeling.
I
I
The
only
time
it
sounds
a
little
weird
to
me
is
if
we're
talking
about
transactional
things
like
an
http
request,
where
we
we
already
modeled
that
as
a
span,
but
I
kind
of
feel
like
it
probably
depends
on
on
the
what's
actually
going
on
and
whether
or
not
that
would
count
as
like
spam
or
not
effectively.
C
Like
a
per
perfect
perfect
example
with
db,
which
uses
http
as
a
as
a
transport,
so
we
have
a
db
call
like
elasticsearch
or
what
was
that
in
aws
atk?
C
M
M
We
know
sort
of
that
that
client
we
want
that
client
span
to
match
up
to
the
remote
server,
because
that
client
span
has
more
like
it
knows
what
the
database
is,
what
the
target
is
versus
and
they
wanted
that
at
sort
of
that,
that
was
where
the
peer
service
semantic
convention
came
from,
also
of
giving
them
names
and
connecting
the
clients
to
the
server
spans
a
little
bit
at
a
level
that
users
understand
better.
M
On
the
logical,
the
database
span
is
where
they
have
more
more
rich
information
about
what
they're
trying
to
connect
to
like.
Oh
we're,
trying
to
connect
to
s3
here
versus
you
know
at
the
http
layer.
All
they
know
is:
oh
here's
a
you
know
an
ip
address.
I
I
think
the
only
thing
that
comes
two
things
come
to
mind
there.
One
is
certainly
true
that
tracing
works
better
when
you
cluster
all
of
these
attributes
onto
the
the
same
span
right
most
systems
are
able
to
to
index
it
better
if
it's
all
in
one
span,
but
if
you
have
a
situation
where
you're
talking
about
peer,
I
p,
but
under
the
maybe
it
if
it
makes
an
initial
request
to
one
ip
but
then
ends
up
failing
and
making
another
request
to
another
ip
or
something
like
that.
M
Yeah,
I
think,
from
the
modeling
like,
like
a
modeling
perspective
in
the
ui,
the
they
don't
draw
the
line
to
specific
ip
addresses
right.
They
draw
the
line
to
hey
you're
talking
to
s3,
so
that
was
sort
of
the
use
case
that
they
had
in
mind
more
at
the
you
know
what
to
do
with
the
detail
network
info
stack
stuff.
You
know
it's
definitely
interesting
things
that
we
could
capture
so
yeah.
I
don't
know
where
my
the
only
thought
I
had
was
to
put
it.
You
know
into
event
data
as
hey.
M
I
It'll,
be
probably
a
little
bit
difficult
to
make
a
universal
distinction
here,
because
not
every
not
every
client
is
going
to
necessarily
give
us
the
same
facilities,
but
it
does
make
sense
to
me
to
try
to
get
as
much
information
onto
that
canonical
database
span
as
you
can,
but
if
it
is
the
case
that
someone
would,
if
they're
trying
to
get
to
the
bottom
of
some
problem,
they
would
want
to
crack
open
that
network
information.
I
You
know
we
already
have
a
concept
of
measuring
all
that
stuff
with.
If
it's
http
we
have
a
concept
of
doing
that.
All
you
know
with
spans
and
child
spans,
like
we
have
a
pattern
for
that.
So
ideally
I'd
like
to
stick
to
that
pattern.
Unless
that
was
like
onerous
for
some
reason
or
difficult,
if
it
was
difficult
or
or
really
bloaty,
then
I
guess
yeah.
I
Like
events
would
would
maybe
be
a
cheaper
way
to
do
it,
but
it
seems
like
if
we
just
logically,
we
just
follow
the
the
the
model
that
we've
given
ourselves.
Wouldn't
it
be
that
you
know
you'd
have
a
logical
span
and
then,
under
it,
you'd
have
multiple
spans
one
for
each
network
request.
That's
that's.
Basically
the
model
doesn't
seem
like
we
have
to
do
something
special.
There
necessarily.
C
E
C
I
I
I
guess
it
I
would
request,
like
don't
just
don't
break
the
the
model
right
like
if
it's
possible
to
put
this
all
in
one
span,
then
that's
fine,
but
if
that
actually
masks
information
from
the
end
user
about
what's
actually
happening
at
the
networking
layer,
then
you
would
have
to
break
it
out
into
multiple
subspans
that
differentiated
between
the
logical
request
and
the
the
actual
networking
requests
happening
under
the
hood
yeah.
So.
C
M
Oh
sorry,
one
of
the
pro
the
I
think
the
reasons
or
our
thinking
with
only
capturing
the
database
span
is
like
what
you
know
like
you
can
take
this
to
so
many
levels
where
even
a
a
sql
call
right.
I
mean
we
capture
the
sql
call,
but
yes,
there's
lots
of
network.
You
know
back
and
forth
underneath
there
to
you
know
to
send
the
query,
pulling
back
data
and
so
sort
of.
Where
do
you
stop
and
and
also
what
what's
the
most
useful
to
users?
M
I
Well,
one
thing
I'll
say:
if
we
want
to
make
this
stuff
optional,
which
is
kind
of
what
like
that
sounds
to
me
like.
Maybe
you
don't
need
this
information
most
of
the
time,
but
if
you're
trying
to
dig
in
you
want
something
more
like
debug
level.
But
if
that's
the
case,
I
would
say
definitely
use
events.
I
It's
not
a
great
pattern
to
have
a
bunch
of
optional
spans
that
actually
change
the
shape
of
the
trace,
necessarily
it's
better
to
have
optional
events
on
a
just
in
terms
of
like
the
way
tracing
systems
tend
to
look
at
these
things.
I
You
know,
for
example,
if
you
have
a
tracing
system,
that's
trying
to
analyze,
what's
different
about
these
two
request
patterns
and
noticing
one
has
a
different
trace
graph
than
the
other
one
doing
things
like
adjusting
that
with
debug
logs
debug
spans
to
change
the
shape
of
that
trace
would
would
interfere
with
those
kinds
of
tools
or
potentially
confuse
them
a
little
bit.
But
but
when
you
just
add
events
you're
not
really
changing
the
shape
of
the
graph.
I
So
maybe
that's
a
way
to
think
about
this.
If
we're
thinking
about
this
as
optional
information,
that
an
end
user
normally
would
not
need
to
to
debug
their
system,
but
maybe
for
advanced
users
and
edge
cases,
you'd
want
to
flip
it
on
those
sort
of
sound
like
debug
events
to
me.
Does
that
make
sense.
M
Yeah
riley
we
should.
We
should
chat
about
the
azure
stuff,
because
the
azure
cosmos
db.
This
is
exactly
how
we
modeled
it
with
them
for
java
was
as
client
each
database
call
as
a
client
span,
but
then
they
capture
all
this
underlying
network,
essentially
debug
level
network
tracing,
and
we
throw
that
on
as
events
if
the
user
has
opted
into
that
lower
level.
Debug.
N
Depending
on
how
complex
the
problem
is,
for
example,
there's
either
version
like
the
vpn
scenario,
where
it
seems
you're
accessing
an
http
higher
level
operation,
but
underlying
the
vpn
is
doing
a
lot
of
like
crazy
work
and
it
might
communicate
to
the
software
defined
networking
and
that's
another
http
call,
so
it
could
be
nested
in
very
deep
layers,
and-
and
here
I
I
think,
it's
just
hard
to
find.
What's
the
reasonable
balance,
there's
always
more
complex
scenarios
where
people
won't
want
to
go
deeper
and
deeper
yeah
like
it
might
like
on
the
surface.
N
So
I
I
personally
would
just
give
up
like
trying
to
clarify
that
in
the
spec,
because
if
you
try
to
clarify
that
means,
you're
restricting
yourself
to
a
certain
scenario,
you're
telling
people,
I
only
cover
80
percent
20
percent.
I
don't
care
someone
got
to
introduce
a
more
complex
back
and
it's
not
my
problem
in
this
way.
I
would
rather
to
keep
it
a
little
bit
more
flexible
because,
like
in
this
way,
we
cover
80
percent
and
people
who
want
more
complex
scenario.
They
can
use
this
at
the
foundation
and
build
their
story.
I
So
maybe
the
thing
we
need
to
add
to
the
spec-
and
I
agree
with
you-
riley-
that
it's
a
little
hard
to
generalize
this
stuff
because
it
sort
of
comes
down
to
like
what
do
you
need
as
a
as
an
operator,
a
developer
to
to
debug
your
thing,
and
that
gets
pretty
specific.
It's
hard
to
wave
your
hand,
but
the
idea
that
maybe
additional
diagnostic
information
should
always
be
events.
If
this
is
information
that
would
count
as
noise
under
normal
scenarios,
but
you
may
want
it
in
some
scenarios.
I
That's
that's
getting
into
events
and
starting
to
get
into
like
what
I
think
the
log
sig
has
been
working
on
different
log
levels
and
stuff
like
that.
That
that
to
me
is
what
what
that
kind
of
sounds
like.
So,
if.
O
N
The
overhead,
sorry,
if
I
might
be
right
holding
so
like
I
had
some
conversation
with
windows,
kernel
folks,
and
they
have
a
scenario
where
the
actual
like
I
I
see,
a
software
like
routing
layer,
have
a
dependency
on
the
network
driver
and
under
the
network
driver,
they
have
all
kind
of
device
drivers
and
they
want
to
put
events
and
they
want
to
flow
the
trace
id.
So
imagine
that
one
one.
Second,
you
got
million
of
events,
and
I
know
like
for
spam.
Our
event
has
limitation.
N
M
Similarity
on.
You
know
these
kind
of
main
instrumentations
that
we
publish.
N
N
So
my
take
is
for
people
who
have
the
new
requirement:
they
have
the
struggle.
What's
the
right
balance,
they
can
start
an
issue
in
the
spec
repo
and
for
the
other
sdk
repos,
where
people
already
implement
something
they
can
put
their
suggestion,
and
then
people
can
debate
and
figure
out.
What's
the
right
pattern.
K
Another
thing
that
came
up
can
I
generally
jump.
K
Sorry
matt,
I
I
don't
yeah,
I'm
trying
to
hold
off
anthony
kind
of
raised
an
issue,
it's
kind
of
more
of
a
meta
issue
around
being
more
of
a
maintainer.
That's
not
necessarily
related
to
the
sig
it's
too
down,
and
it
deals
with
coc
violations
and
handling
trolls
and
getter.
I
I
feel
like
it
might
be
more
important
to
talk
about
in
this
meeting
and
I
just
kind
of
want
to
have
like
a
point
of
order
to
see.
K
If
we
can
try
to,
you
know,
get
a
vote
on
if
you
can
move
that
up
in
priority,
I'm
fine
with
also
waiting
your
spot
yeah.
I
A
H
N
P
All
right,
trolls
and
coc
violations
and
getter
yeah.
So
the
question
here
is
basically:
what
tools
do
we
have
to
deal
with
these
there's:
a
user
who
asked
a
facially,
neutral
question
the
the
image
that
links
it?
I
don't
know
if
you
want
to
open
that
or
not
because
the
the
avatar
and
the
username
are
both
rather
offensive.
I
find
so.
The
question
is:
what
can
we
do
about
that.
P
D
On
on
gita
before-
and
there
is
a
report
button
for
individual
messages-
and
I
remember
that
I
saw
this
ban
disappearing
quite
quickly,
so
I
could
expect.
I
would
expect
that.
Maybe
if
three
people
report
it
at
once,
they
would
just
delete
it
automatically
or
something
like
that.
D
A
A
I
assume
that
those
reports
go
to
like
like
get
her,
get
hers
on
by
atlassian
now
or
whoever
runs.
O
A
F
Small
question
was:
is
it
just
the
con?
Is
it
just
the
username
and
the
avatar
that's
offensive,
or
do
they
ever
post
any
content?
That
is
offensive,
because
perhaps
maybe
they
just
don't
recognize
that
posting
with
that
avatar
and
username
is,
is
offensive
to
people
and
maybe
communicating
that
to
them
effectively
could
still
make
them
a
positive
contributor.
I
don't
know
if
that's
something
we
want
to
pursue
or
not.
P
While
I
appreciate
the
optimism
in
this
instance,
I
doubt
they're
unaware
bob,
you
poor,
sweet
innocent
child,
they
I'm
not.
This
is,
as
far
as
I
know
the
first
time
they
have
commented
in
this
channel,
the
first
time,
I've
seen
them
and
then
the
kind
of
man
like
the
comment,
like
I
said,
was
facially
neutral,
so
it's
possible,
but
I
highly
doubt
it.
A
No
okay,
so
let
me
think
about
next
steps.
My
suggestion
would
be
to
report
it
because
I
believe
it's
against
the
code
of
conduct.
A
If
it
happens
again,
then
I
recommend
we
take
this
to
the
governance
committee,
because
we've
got
people
like
like
sarah,
for
example,
who
who's
worked
with
the
cncf
very
closely
and
frankly
she
knows
how
to
handle
this
stuff
a
lot
better
than
I
do,
and
I
suspect,
ted,
probably
better
than
you
do
either,
just
because
she's
pretty
experienced
with
this.
D
A
I
But
I
kind
of
presume
they
have
that
avatar
as
as
kind
of
waiting
to
see
if
you're
going
to
respond
to
it
and
then
making
a
deal
out
of
it.
That's
I
mean,
maybe
I'm
I'm
wrong
about
that.
E
I
Good
stuff,
well,
anyways,
I'm
I'm
happy
to
help.
You
can
contact
other
governance
committees,
I'm
sure,
but
I
guess
I
shouldn't
speak
for
other
governance
committee
members,
but
I
will
speak
for
myself
and
say
that
you
can
contact
me
and
we've
talked
about
this
when
we
hit
ga
switching
off
of
gitter.
Thank
god.
I
There
are
some
options
out
there.
I
think
discord
is
the
one
I've
seen
that's
both
the
most
open
and
has
the
most
tools
available
like
administrative
tools
for
dealing
with
this
crap
because
it
came
out
of
the
gamer
community,
so
it
had
to
deal
with
it.
So
we
can
look
at
switching
to
something
like
that
and
you
know
giving
ourselves.
E
A
E
I've
been
just
quickly
trying
to
google
for
getter
tools.
While
we've
been
talking-
and
I
noticed
the
free
code
camp
has
a
getter
moderation
policy
that
says
you'll
be
banned,
which
suggests
that
it's
possible
to
ban
people.
I
just
don't
see.
A
E
It's
pretty
explicit
that,
like
moderators,
will
ban
people
for
the
following
immediately
and
then
they
send.
E
A
Got
it
here,
so
I've
got
the
permissions
open.
The
admins
on
our
getter
are
myself
ben
sigelman
bogdan
drew
to
sergey
kanslev
and
yuri
shikuro,
so
I
do
have
admin
privileges.
I
see
no
way
to
ban
people,
though
anyways.
I
think
I
think
for
this
one.
I
recommend
using
the
report
functionality
in
gitter.
If
we
see
another
instance
of
this,
it
sounds
like
the
action
is
chat
of
ted
and
and
probably
roping
sara
novotny
from
the
government's
committee
as
well
and
they'll.
Take
they'll
take
point
yeah.
I
P
A
A
All
righty
so
matt
we're
going
to
talk
about
framework
specific
issues
at
the
spec
meeting,
because
that's
probably
actually
a
better
better
form
for
that,
and
so
next
is
then
nikita
example
repository
for
vendor-specific
distributions.
O
C
I
Yeah
we
have
one
here.
If
you
would
like
to
look
at
it.
Let
me
find
for
some
reason,
I've
lost
the
notes
here,
the
notes
so
we
have
like
over
at
lifestep.
We
have
like
the
world's
most
basic
yeah
and.
G
I
Just
let
you
know
like
distros
are
something
I'm
working
to
define
at
the
gc
level
right
now
and
once
we
get
some
work
done
there,
we'll
we'll
probably
come
back
down
to
the
maintainers
to
discuss
some
things,
but
I
see
it
as
like.
There's
actually
three
parts
to
this
one.
Is
you
know
what
is
it
what
counts
as
a
distro
you
know
like,
and
that
could
mean
you
know.
How
do
you
like?
Does
it
need
a
certain
github
repository
shape
or
something
like
that?
I
But
it
also
means
like
what
can
you
put
in
it?
What
you
know
are
you
allowed
to
fork
open,
telemetry
and
call
it
a
distro?
Are
you
allowed
to
wrap
the
public
api
in
something
proprietary
and
call
it
a
distro?
The
answer
is
gonna
be
no
to
those
two
things.
So
there's
a
number
of
things
that
have
to
get
defined.
I
I
think
on
that
front
and
then
there'll
be
some
some
legalistic
stuff
around
like
what
can
you
claim
your
distro?
I
Does
that's
going
to
have
to
get
defined
so
there's
a
pile
of
stuff
and
we're
working
with
the
cncf
right
now
to
come
up
with
like
a
a
basic
framework
for
this
and
then
last
but
not
least,
we
certainly
want
to
to
list
these
things
in
the
in
the
registry,
but
in
the
in
the
meantime
I
would
say
you
know,
as
far
as
like
a
repository
structure
or
anything
like
that,
I'm
not
sure
if
that's
necessary,
because
or
I
don't-
I
want
to
be
a
little
circumspect
about
over
prescribing
how
people
might
want
to
set
that
up,
because
I
don't
the
whole
point
of
having
a
distro
is
like
to
make
life
easier
for
yourself
and
your
your
users,
and
I
want
to
avoid.
C
In
java,
auto
instrumentation
we
have,
we
should
desire
to
like
so
users
should
be
able,
for
example,
to
over
overwrite
some
auto
instrumentation
that
we
provide.
How
do
we
show
the
users?
How
should
they
do
that?
I
C
I
C
Yeah
I
can,
I
can
start
doing
that,
but
for
that
I
need
a
repository
in
open
telemetry
organization.
Oh,
I
can
start
doing
that
in
my
own
private
repository.
I
don't
know
so.
That's
that's
why
I
asked
maintainers.
Do
we
have
the
general
interest
in
that
or
do
we
want
to
see
a
poc
of
that
first
and
where
should
they
do
that.
I
I
would
recommend
just
making
it
on
your
own
for
the
time
being,
because
it's
just
a
proposal
in
a
prefa
concept.
I
do
think
this
is
a
thing
like
we
have
to
tackle
and
just
to
let
you
know
at
that
we're
starting
to
to
get
a
framework
for
this
put
together
at
the
gc.
So
so
you
will
see
some
more
advice
coming
up:
okay,
there
are
some
things
around
trademark
and
legal
issues
and
other
stuff
that
we
have
to
sort
out
around
all
of
this.
Yes,
so
do
you
have.
I
I
think
at
the
gc
level,
we'll
hopefully
have
something
put
together
in
a
couple
of
weeks,
and
we
are
now
recording
those
gc
meetings.
I
believe
right.
So
it's
not
like
that
discussion
will
be
happening
in
secret
or
something,
but
in
the
meantime,
yeah
people
wanting
to
make
open
telemetry
distributions-
I
would
say
you
know,
go
ahead
and
make
a
repo
that
works
for
you
and
put
it
out
there.
I
don't
think
you
know
if
we
end
up
having
to
modify
these
things
later
into
some
compliance.
That's
okay!
I
The
things
I'm
more
concerned
about
are
are
people
starting
to
make,
make
claims
and
stuff
about
their
distribution
being
better
than
understandable.
That
kind
of
thing,
so
please,
please
avoid
like
some
kind
of
giant
marketing
campaign
around
something
like
that.
C
A
If
you're
having
these
conversations
with
either
like
community
or
cncf
josh
soreth
on
our
side
of
google,
is
the
the
new
tl
for
our
open
telemetry
team.
He
was
super
interested
in
like
exactly
this.
So
if
you
could
include
him,
that
would
be
fantastic.
A
Josh,
terrell,
yeah,
josh
sureth
who's
on
the
call
currently,
but.
O
I
I
got
it
yeah
yeah,
I'm
happy
happy
to
to
to
rookie
into
this
stuff.
Sweet,
perfect
yeah.
L
I
The
main
thing
we're
starting
to
look
at
are
our
compliance
programs
that
the
cncf
does
so
one
place
to
start
is
just
that
if
people
on
this
call
want
to
get
involved
in
looking
at
this,
have
a
look
at
the
kubernetes
compliance
program
that
they've
put
into
place
it's
large
and
involved,
because
it's
kubernetes,
but
I
think
it's
a
good
example
of
something
that
could
work
for
us.
O
We
we
actually
already
have
someone
looking
at
a
very,
very
modest
compliance
test
for
just
the
collector
that
we'd
be
happy
to
share
as
soon
as
it's
I
mean,
even
even
before
it's
ready
so
yeah.
I
Awesome
yeah,
please,
please
do
and
yeah
feel
free
to
ping
me
directly
about
that
stuff.
You
know
pick
your
your
crappy
flaky
medium
of
choice,
email
or
or
get
her.
I
sort
of
checked
both
of
them.
Okay!
I
Yeah
I'll
bring
this
up
at
the
spec
discussion
again,
but
just
moving
things
forward
on
user
research
and
dog
fooding,
especially
as
we're
going
into
release
candidate.
I
really
really
really
think
we
need
to
do
this
for
ourselves.
I
just
gave
a
series
of
workshops
on
open
telemetry
for
java
go
javascript
and
python
and
yeah.
It
was
definitely
my
experience
going
in
there
that
it's
still
like,
I
think
rough,
for
a
new
user
to
get
get
started
with
our
stuff.
I
A
fair
chunk
of
it
is
is
documentation,
but
I
still
feel
like
when
I
get
things
wrong,
sometimes
like
I
get
mysterious
bugs
or
things
blowing
up
in
my
face
and
I
think
being
able
to
just
surface
all
of
this
stuff
by
putting
ourselves
in
the
end,
user's
shoes
and
kind
of
just
walking
through.
This
would
be
very
helpful.
So
when
I
proposed
this
last
time,
it
was
sort
of
like
check
for
compliance
across
this
huge
matrix,
and
I
think
that
was
maybe
a
little
scary.
I
So
I've
reduced
the
scope
of
this
to
just
the
the
basic
tracing
operations
that
an
end
user
has
to
interact
with.
So
if
you
wouldn't
mind
just
popping
that
open
real,
quick
morgan
since
you're
sharing
the
screen,
actually
I
think
it's
andrew
sharing
his
screen
or
andrew.
Thank
you.
I
So
all
we're
doing
here
is
there's
this
document,
and
if
you
want
to
perform
this
user
research,
you
just
create
a
copy
of
it
and
then,
if
you
you
just
scroll
down
it,
just
walks
you
through
some
very
basic
stuff.
So
if
you
scroll
below
these
are
just
the
setup
instructions.
I
Those
are
the
things
I've
identified
as
the
stuff
users
have
to
know
how
to
do
in
order
to
use
open
telemetry.
Everything
else
is
sort
of
like
advanced
mode,
and
you
don't
really
have
to
touch
it
as
an
end
user
on
your
first
try.
But
but
this
stuff,
you
kind
of
do
and
if,
if
it's
not
obvious
how
to
do
it
or
where
it's
difficult
to
do,
I
think
it's
going
to
be
a
hard
thing
for
new
users
to
wrap
their
heads
around
open
telemetry.
I
So
it
would
be
great
if
we
could
start
by
maybe
just
dog
fooding,
our
own
stuff
and
just
walking
through
this
with
your
own
program
and
just
keeping
notes.
As
you
go.
That's
my
main
request
here.
I
Is
you
just
perform
these
steps
and
under
each
section,
there's
a
little
feedback
area
and
just
filling
in
the
things
you
notice
as
you
go,
and
then
there's
a
form
where
you
can
submit
this,
along
with
a
link
to
your
copy
of
user
research
and
we'll
collect
all
of
them
up
and
try
to
synthesize
this
into
feedback
for
all
the
different
cigs.
I
You
know
we
have
a
whole
lot
of
internal
familiarity
with
so
I
know
this
is
extra
time,
but
I
do
think
this
would
be
very
useful
if
not
critical,
for
us
to
do
before
we
slap
down
something
like
like
a
ga
on
these
things.
I
O
I
So
any
feedback
on
this
is
great,
feel
free
to
leave
comments
on
that
doc,
as
well
with
suggestions,
hey
ted.
K
Yeah,
so
I
think
this
looks
great,
I'm
actually
really
excited.
I
kind
of
want
to
share
this
around
yeah.
K
That
are
really
good-
I
don't
think,
goes
ready
for
feedback.
Yet,
though,
how
do
I
get
that
taken
off.
I
Oh,
I
will,
I
will
take
it
off.
Okay,
I
curiosity
what
what
what's
going
on
in
go
just
so,
I
know.
K
We're
looking
at
api
feedback
and
refactoring
from
a
few
people
in
the
go
community,
and
so
there's
some
some
larger
restructures
there
and
we're
still
kind
of
waiting
on
a
release
to
get
out
plus.
K
With
some
other
things
but
yeah,
I
think
that
you're.
I
I
Some
user
user
feedback,
yeah
yeah,
yeah,
that's
fine
removed
and
anyone
who
wants
to
add
or
remove
just
make
a
comment
on
this
doc.
I've
set
it
to
comment
only
instead
of
editable,
just
because
it's
it's,
I
don't
want
someone
to
accidentally
start
doing
user
feedback
in
the
core
doc,
rather
than
making
a
copy
of
it.
But
if
you
make
suggestions
there,
I'll
just
put
them
in
and
I
I
only
listed
the
languages
that
people
hadn't
mentioned
were
were
ready
so
for
tracing
feedback.
A
Sweet,
thank
you
very
much
ted
yeah
all
right.
We
do
have
two
other
topics,
but
I
think
we're
at
time.
I
can
carry
it
to
the
next
meeting
I'll.