►
From YouTube: 2020-10-20 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).
A
B
B
Okay,
I
guess
we
can
wait
one
more
minute.
I
see
a
few
items,
so
we
have
enough
stuff
to
discuss.
Well,
let's
wait
one
minute
for
more
people
to
join,
although
we
have
20
already,
okay,.
B
B
Okay,
so
we
can
start
with
andrew
and
the
current
progress.
D
And
I've
got
a
few
agenda
items.
D
Some
of
them
are
just
fyi.
Just
letting
people
know
just
want
to
share
this
because
it
helps
put
some
things
in
context
perspective
on
our
progress,
since
we
started
tracking
issues
that
are
required
for
since
we
started
tracking
and
tackling
issues
for
hotel
ga
back
in
july,
we
identified
83
issues
at
one
of
the
spec
sig
meetings.
D
Today,
three
months
later,
we've
resolved
111
issues
for
ga,
there's
still
15
more
to
tackle,
that's
been
tagged
as
required
for
ga
and
we've
moved
121
issues
to
after
ga.
D
So
I
just
wanted
to
highlight
that,
even
though
some
of
the
sentiments
back
in
july
was
like-
oh,
my
god,
80
issues
or
90
issues
at
one
of
the
meetings
like
we're
never
going
to
get
through
that
like
we
tackled
111,
so
I
think
that's
kind
of
fantastic
in
terms
of
our
progress
we
still
have
stuff
to
do,
but
that's
where
we
are
in
general
and
the
show
ain't
over
after
we
get
to
ga.
We
still
have
121,
which
we
think
you
know
are
worthwhile
to
consider.
D
They
aren't
closed
they're.
Still
things
they're
like.
Oh,
maybe
we
should
do
something
after
ga,
so
that's
that
context.
I
also
want
to
throw
an
fyi
to
the
blog
post.
That's
scheduled
to
go
out
tomorrow:
nine
a.m.
It's
only
25
hours
morgan's
been
editing
it.
D
I
I've
been
putting
some
changes
into
it
as
well,
in
order
to
properly
represent
the
milestones
of
the
spec,
spec
freeze
and
also
the
subsequent
milestones
of
implementation
of
the
spec
to
follow,
and
I
encourage
people
to
have
a
look
have
a
gander
so
that
way
people
understand
where
our
direction
is
going.
D
I
won't
repeat
the
stuff
from
our
maintainers
call.
We
discuss
it
there
and
there's
notes
in
in
the
agenda
there.
Okay,
so
I'll
move
on
to
the
time
box
items
of
the
issues
that
we
have
see,
we
have
only
a
few
issues
that
need
to
be
triaged.
D
B
B
E
B
E
E
E
That's
trace.
We
don't
want
to
have
that
on
all
matrix.
H
Yeah,
I
think
this
gets
into
distros
right.
Are
we
going
to
include
a
lot
of
vendor-specific
plug-ins
directly
into
the
core
of
open,
tracing
or
open
tracing
wow
open
telemetry,
or
does
that
not
scale?
And
I
kind
of
feel
like
it?
It
doesn't
scale
for
everything
like
that
to
go
into
core.
H
So
that's
my
really
only
concern
with
trying
to
to
put
vendor
specific
stuff
in
there,
one,
the
the
maintainability
of
it
and
and
to
the
scalability
of
it,
and
I
would
prefer
to
approach,
try
to
find
a
more
like
packaging
or
distro
approach
to
this
problem,
where
we
make
it
easy
to
package
up
open
telemetry
with
some
pre-configured
plug-ins
and
other
things,
and
make
that
try
to
normalize
that
approach
to
deploying
open
telemetry
rather
than
trying
to
kitchen
sink
approach
where
just
everything
has
to
go
into
core,
because
otherwise
it's
too
hard
to
get
started
to
open
telemetry.
H
So
I
don't
think
we
it's
required
for
ga
to
have
a
concrete
plan
there,
but
I
do
think
prior
to
ga
at
least
having
a.
If
we
have
some
agreement,
that
we
want
to
go
with
the
distro
model
and
we're
thinking
about
it
and
maybe
talking
about
it
publicly
before
ga.
But
I
don't
know
if
we
have
to
completely
get
it
together
before
ga.
H
Yeah,
but
I
guess
what
I'm
saying
is
I
I
I
disagree
with
this
specific
approach
that
makes
sense
like
I
think
we
should
sort
out
how
to
do
open,
telemetry
distributions,
ideally
before
ga,
but
I
I
personally
don't
think
it
scales
to
try
to
keep
putting
all
the
vendor
specific
stuff
in
the
core
there's
some
things
that
are
like
open
standards,
there's
like
jaeger
and
zipkin
stuff,
and
that
makes
sense,
but
once
you
start
becoming
really
vendor
specific,
it
there's
a
maintainability
issue
of
like
if
it's
out
of
date
or
breaks
like,
are
we
responsible
for
it
or
is
it
some
other
group,
and
then
we
have
to
poke
them
and
then
what
happens?
H
If
they
don't
do
it
and
then
the
other
issue
is
like.
Will
this
quickly
turn
into
just
some?
Some
favored
vendors
can
have
their
stuff
in,
but
others
aren't
denied,
because
we
can't
put
everything
in
there,
so
it
seems
like
it
would
be
better
to
have
a
way
for
people
to
get
pre-packaged
versions
of
open
telemetry
that
have
the
vendor
specific
plugins
and
things
you
would
need
already
installed,
and
at
lightstep
we've
already
built
a
prototype
of
this
they're
called
the
open
telemetry
launchers.
H
You
guys
can
check
them
out
they're,
very
simple
and
straightforward,
but
it's
an
example
of
how
you
could
build
a
feel
free
to
use
them
as
a
base
to
to
build
your
own
distro.
If
that's
what
you're
interested
in
doing.
I
So
ted,
that's
again,
I
agree
with
many
of
your
ideas,
because
I
do
think
that
that's
a
need
that
users
have
and
are
you
in
the
launchers?
Are
you
specifically
just
making
available
the
build
scripts
or
or
docker
images?
Or
you
know,
what's
your
idea
of
a
distribution
because
that
can
be
a
source
distribution
or
it
can
be
a
binary
distribution.
H
Yeah,
I
mean,
I
think,
I'm
not
even
sure
if
there
needs
to
be
standardization
there,
what
what
we
offer
is
is
just
the
open.
Telemetry
distributions
aren't
really
any
different
different
than
how
we're
distributing
the
sorry,
the
launcher,
distributions
or
no
are
not
distributed
any
different
than
the
core
open.
Telemetry
distros
are
today
it's
just
packages
and
various
package
manage
language.
Specific
package
management
systems
and
light
step
currently
doesn't
require
any
plugins
like
we.
We
don't
require
plug-ins
per
se,
but
we
do
require
some
configuration.
H
That's
really
obnoxious
to
do
like
you
have
to
set
a
grpc
header
on
the
otlp
exporter
and
just
the
boilerplate
of
getting
it
set
up
with
lightstep
was
was
kind
of
annoying.
I
wrote
a
blog
post
about
this.
I
can
you
can
post.
H
And
so
that's
I
mean
I
think
it
would
be
great.
We
can
use
the
registry
and
other
things
to
like
promote
them
and
make
it
clear
that,
like
hey,
if
you
want
to
work
with
amazon
and
amazon,
you
know
requires
you
to
have
a
special
sampling,
plugin
or
something
like
this.
It's
not
easier
to
get
started
that
way.
Hopefully
it's
easier
to
get
started
with
the
amazon
specific
distro
than
saying.
Oh,
you
want
to
use
open
telemetry
like
that's
easy.
It's
all
baked
in
just
copy
paste.
H
I
H
It'll
all
be
there,
but
everyone
will
have
to
like
swiss
army
knife,
configure
it
rather
than
encapsulating
all
that
configuration,
because
most
of
that
configuration
is
actually
about.
Are
you
trying
to
talk
to
this
back
end
versus
that
back
end
yeah,
then,
once
you've
made
that
choice,
the
amount
of
configuration
you
have
to
do
is
like
way
smaller,
and
so
it's
easier
to
encapsulate
after
you've
made
that
decision.
It's
not
very
easy
to
encapsulate
before
you
make
that
decision.
J
Looking
at
experience
here
so
so
number
one
thing
I
I
think
I
started
to
mention:
we
shouldn't
either
render
specific
thing
into
each
like
sdk
release,
because
the
problem
is
it's
impossible
to
maintain
going
forward
and
it
creates
a
bias.
The
second
thing
is,
I
think,
each
language
has
their
native
way
of
doing
distribution,
for
example
in
javascript.
I
would
imagine
for
web
browsers,
like
big
companies
like
microsoft,
amazon,
google,
they
probably
would
just
put
a
cdn
url,
tell
the
user.
Just
add
this
script
into
your
html
pages
and
you're
done.
J
I
Well,
even
if
you
did
you,
you
still
have
to
have
an
agreement
from
the
project
with
the
vendor
to
clearly
maintain
it
right,
because
there
is
a
compatibility
issued
and
a
compatibility
matrix
that
will
build
over
time
as
we
build
reach
releases.
J
D
In
the
interest
of
time
for
getting
through
the
triage
issues,
I
ask
that
these
some,
like
you,
know
suitable
ideas,
maybe
added
to
the
comments
to
this
issue.
D
K
C
L
Been
shifted
up,
I
think
we
can
word
this
out.
It
shouldn't
be
done
in
this
meeting,
though
we're
gonna
try
to
change
the
metrics
api
and
I
think
it'll
be
a
group.
D
G
Yeah,
so
in
in
this
one,
most
of
the
attributes
and
cementing
conventions
are
singular.
So
it's
problem
solved,
but
we
found
a
case
where
we
have
a
singular
attribute,
but
actually
sometimes
it
might
represent
a
collection
of
items.
So
there's
a
question:
if
we
should
make
a
copy
of
this
singular
attribute,
with
a
plural
plural
attribute,
or
maybe
we
should
use
only
plural
attribute,
or
maybe
some
other
solution
so
yeah.
This
might
be
an
interesting
discussion.
E
N
E
E
G
Yeah,
if
we
have
an
attribute
that
is
singular
right
now
and
it
can
point
to
plural
to
collection
of
items
and
it
should
be
plural,
then
it
needs
to
be
fixed.
But
then
right
now
we
identified
only
one
or
maybe
two
attributes
for
kubernetes
attributes.
So
I'm
not
sure
if
this
is
really
really
urgent.
N
E
E
Yeah
one
of
them
is,
for
example,
we
say
for
messaging,
we
say
message
payload
size,
but
then
afterwards
http
attributes
were
added
and
there
we
already
have
the
well
established
content
length
header.
So
we
use
that
one
as
the
natural
name,
but
well
in
the
end,
now
they
don't
align
with
each
other
yeah.
H
We've
gotten
several
complaints,
I
think,
actually
from
a
couple
beyond
pluralization.
I
think
the
dotted
name
spacing
also
gets
some
irritation.
I've
noticed
from
some
end
users
we've
seen
at
least
some
issues
about
hey
you're,
not
particularly
consistent
about
the
name
spacing
within
the
semantic
conventions.
H
I've
seen
some
of
those
issues
float
around
is
that
true,
I've
seen
that
I
don't
recall
the
issue,
but
someone
was
pointing
out
that
there
was.
I
know
about
whether
or
not
there
was
like,
like
how
many
levels
of
dotted
stuff
are
there,
and
it's.
H
Me
but
I
did
notice
some
people
were
nitpicking
that
our
semantic
conventions
were
not
wholly
regular.
I
don't
know
how
much
it
matters
like
same
thing
with
pluralization
like
it's
just
a
key.
You
copy
paste,
but
you
know
if
we're
saying
we're
standardizing,
then
the
the
the
the
standardization
nitpickers
are
going
to
come
out
with
a
standardization
rules
ruler
and
be
like
this
isn't
particularly
regular.
H
L
Yeah
this
looks
like
a
duplicate.
We
have
a
documentation
already
about
a
metrics
processor
component.
It's
just
got
a
lot
of
to
do's
in
the
sdk
spec
and
I've
already
written
a
comment
on
this
issue,
so
this
can
be
required
for
ga.
I
think
we've
already
got
this,
but
I
think
it's
right,
but
it's
it's
it's
already
there.
So
really
we
just
have
to
there's.
N
I
think
it's
a
bit
different
george
than
that
that
one
and
the
listening
is
different
because
they
want
to
to
to
extract
things
from
packages
and
make
them
labels
for
that
measurement
and
stuff.
And
I
don't
think
our
measure
our
metric
processor
was
intended
for
that.
L
Okay,
let's
discuss
this
offline
you're
right,
there's
more
functionality.
We
could
specify
a
standard
behavior,
but
at
least
in
the
go
sdk
there's
already
an
interface
you
will
use
for
that.
D
L
That
was
a
lot
of
words.
Make
this
a
an
editorial
I'd
say
we
need
to
finish
documenting
our
sdk.
D
D
I
E
D
And
that
is
it
for
new
issues
that
have
been
that
have
come
in.
So
let's
change
some
of
the
numbers
in
my
next
item
of
where
we
are
in
terms
of
the
spec
burndown.
D
Overall
for
the
ga,
we
have
these
numbers,
but
we're
concentrating
on
the
p1's
to
freeze
the
trace
spec,
and
we
had
one
interview,
one
in
progress.
N
Which
one
is
to
do.
D
C
I
think
we
exhausted
the
issues
that
were
required
for
the
spectres
freeze
declaration.
I
think
it's
time
to
do
that.
Probably
the
easiest
way
would
be
to
say
that
the
trace
specification
files
should
carry
a
label.
I
guess
that
says
that
they
are
not
frozen.
Probably
I
guess
formally,
the
label
should
be
something
like
1.0
rc
one
or
something
like
that
right,
and
that
would
be
the
indication
that
this
is
the
release
candidate
for
trust
specification,
which
means
that
there
is
no
more
substantial
major
changes
allowed
unless
we
discover
something
is
totally
broken.
N
Yeah
there
are
two:
there
are
three
more
things
that
may
influence
the
phrase,
so
the
the
hotel
sampling
probability
a
variable,
that's
an
indication.
I
will
not
worry.
I
will
even
put
it
because.
L
C
E
From
creating
the
pr
or
if
there
were
any
substantial
changes,
there
are
a
new
another
two
days.
I
think
it
even
says
business
days,
at
least
I
hope
so.
That's
written
in
the
community.
N
I
mean
andrew-
let's-
let's
not
we'll
figure
out
after
after
this.
If
that
is
possible
to
to
merge
or
not
okay,
somebody
has
to
look
at
that,
but
so
you
mentioned.
C
Something
about
version-
I
don't
know
yeah,
I'm
asking
about:
how
do
we
label?
How
do
we
record
officially
the
fact
that
trace
spec
is
no
longer
accepting
substantial
changes
so
somewhere
right?
We
want
to
label
it
somehow.
Let's.
C
Exactly
that's
what
I'm
proposing
so
under
the
title
of
the
spec
trace
specification,
other
label,
which
indicates
that
how
do
we
want
to
indicate
that?
I
think
something
like
do?
We
say
that
this
is
1.0
release
candidate
one?
Is
that
sufficient
or
we
want
it
to
be
indicated
in
some
other
way,.
N
J
N
N
Sure,
but
I
think
we
need
to
to
document
what
does
it
mean?
Remember
we
have
this
continuous
discussion
on
the
protocol.
What
does
it
mean
that
is
stable?
I
think
we
need
the
document
to
document
whatever
words
we
use
and
what
does
it
imply?
Yes,.
C
B
By
the
way,
there's
as
a
small
large
issue
that
may
impact
this,
it
may
or
it
may
not-
and
it's
about-
and
it's
included
in
the
agenda
about
the
renaming
from
spam
context
upon
reference
which
some
people
didn't
like.
But
anyway,
we
can
discuss
that
in
a
bit.
N
A
Yeah,
so
I
I'm
just
thinking
that
it
may
be
good
to
have
a
version
of
v1
spec
that
can
be
easily
referred
to,
maybe
github
pages
or
maybe
separate
folder
would
be
very
useful,
so
sdks
can
refer
to
v1,
specifically.
N
So
what
you
are
saying,
okay,
I
think
this
is
probably
we
can
do
it
after
tomorrow
and
think
about
how
do
we
structure
the
things
in
in
version
directories?
Maybe
we
should
we
should
follow
something
I
think
w3c
has
something
similar
with
that.
Maybe
we
can
do
that.
C
D
C
How
to
link
to
the
version
how
to
plug
the
version
in
the
sense
how
to
label
the
version
that
right,
how
to
we
label
the
specific
files
that
are
already
part
of
the
part
of
the
trees
right,
so
that
it's
clear?
What's
frozen?
And
what's
not?
Okay,.
D
I'm
trying
to
be
wary
of
all
these
other
items
on
the
list
are
some
of
them
that,
like
really
important
to
just
talk
about
for
the
trace,
spec
freeze,
because
my
next
topic
item
might
take
a
few
minutes
and
that's
to
finish,
scrubbing
the
metrics
issues.
B
B
Okay,
so
yeah!
First
of
all,
christian
about
should
sample.
N
F
Correct
yeah,
but
I
think
if
we
move
that
we
would
first
moving
that
is
after
ga,
I
guess
and
then
I
guess
we
could
introduce
a
new
callback
for
that.
Like.
F
N
Very
good
also,
maybe
now
that
you
said
this:
maybe
the
name
should
be
or
whatever.
No
don't
don't
do
too
many
but
yeah.
I
think
I
think
the
context
should
be
available
there.
The
entire
context
should
be
available.
F
Yeah
like
there
was,
is
also
this
issue
with
the
that's
not
for
ga,
but
that
could
be
made
after
ja
with
this
change.
That
b3
has
this
debug
flag.
That
is
not
exactly
like
the
w3c
sampled
flag,
and
you
could
put
this
in
the
context
and
then
read
it
back
in
the
sampler.
If
the
sample
receives
the
full
context,
yeah.
Q
Sharing
screen
actually
sure
posting
the
issue.
F
H
But
I
have
it
already
just
I
think
some
people
might
not
be
totally
clear
what
the
reasoning
is.
F
F
E
N
I
think
it's
a
it's
a
good
change,
because
people
may
look
at
the
baggages.
For
example,
people
may
look
at
different
other
properties
in
the
context
to
make
the
sampling
decision.
So
I
think
it's
it's
a
good
good
choice
to
give
the
entire
context,
so
they
can.
They
can
extract
different
things
in
their
samplers
and
do
better
decisions
if
they
want.
P
N
H
B
Okay,
and
the
next
item
is,
I
put
this
in
it's
about
some
stuff
that
matt,
what
matt
put
together
about
v3
clarification
it
just
trying
to
document
what
we
have
now
saying
that
we
don't
support
advanced
options
and
those
options
can
be
added
after
ga,
math
arguing
the
call
he's
not,
but
in
general
the
the
pr
itself
is
in
a
good
situation.
B
I
think
because,
as
I
said,
it's
basically
stating
what
most
implementations
are
doing
at
this
moment
and
andura
who's
is
relatively
very
well
involved
with
with
the
sleeping
community
he
gave
his
blessing.
So
I
think
we
are
in
a
good
position
for
that
and
given
the
fact
that
we
have
already
two
reviews,
I
will
merge
it
it
by
the
end
of
the
day
today
or
early
tomorrow.
As
I
said,
it's
not
good.
Yes,
carlos.
N
N
B
There
you
go
there,
you
are
so
basically
this
is
the
one
it's
basically
mostly
about
the
devops
lab
empire
in
spanish,
which
we
are
not
using
at
this
point.
This
is
more
or
less
how
it
looks
basic
yeah.
Basically,
you
know
it's
basically
just
expanding
what
we
have
there
and
you
can
see
that,
for
example,
not
reuse,
this
one
most
pressure,
the
flag
we
are
not
using,
it
will
try
to
preserve
it,
then
don't
don't
propagate
par
in
spanish.
N
Sounds
good
everyone
please,
please
review.
I
think
this
is
mostly
clarifying
a
lot
of
things.
So
don't
I
think
it
should
be
more
soon.
Yeah.
N
Yeah,
I
would
now
move
to
the
next
topic
and
jump
a
bit
and
call
the
span.
Reference
virtual
span
context
discussion
because
I
think
that
may
have
the
biggest
impact
of
the
freeze.
N
I
still
hear
everyone
complaining
about
that
or
not
a
bunch
of
people
complaining
about
that
can,
and
I
heard
that
some
of
the
carlos
you
mentioned
that
you
have
some
some
feedback
about
this.
Can
you
start
the
discussion
and
give
us
more
details
or
yeah.
B
L
Yeah
and
I've
taken
an
interest
in
this
because
I
think
it's
really
an
interesting
question.
Some
of
these
questions
were
assigned
to
me
as
to
help
get
these
resolved
and
onorag
who's.
Not
on
this
call
because
he's
in
the
wrong
time
zone
has
filed
a
lot
of
those
issues.
I
had
proposed
that
we
joined
this
call
of
those
of
you
who
can
at
the
four
o'clock
apac
time
slot
to
discuss
it
with
honorable,
because
I
think
he's
raised
really
legitimate
questions.
I've.
L
H
L
Will
post,
I
think
there
are
three
or
four
of
them
and
I
think
well:
1075
is
probably
the
most
important
of
them
but
yeah
and
I
think
honorable
was
hoping
to
to
talk
to
us
about
it
about
them.
L
L
L
B
N
L
L
N
But
I
think
this
is
blocking
correct
because
it
may
blow
everything
up.
N
Yeah,
no,
I'm
fine,
I'm
fine
with
that,
but
we
need
to
better
explain
the
difference.
Compared
with
open
sensors.
Open
tracing
for
open
foreign
is
the
same
as
it
was,
but
for
open
tracing
was
a
bit
different
because
he
was
carrying
baggages
and
other
things
compared
with
the
with
the
the
current
thing.
R
Yes,
I
wondered
why
I
didn't
know
that
about
open
tracing
now
I
get
some
context
about
the
context
discussion
and
maybe
it
makes
more
sense
to
change
the
name.
N
I
don't
know:
let's:
let's
tristan,
can
you
join
that
discussion
because
you,
you
have
a
good
input,
usually.
N
I
would
also
encourage
everyone
to
look
at
open
tracing
spam
context
and
the
here
there
open
sensor
spanner
context
and
maybe
brave,
trace
context,
which
is
completely
different
than
the
two
of
them
just
for
for
having
something
in
mind
and
understand
better
how
the
three
projects
use
completely
different
terms
and
different
things
doing
different
yeah,
it's
a
bit
of
a
problem
there,
but.
L
B
Okay,
for
the
sake
of
time,
you
guys
can
probably
do
that
offline
or
later
after
this
call,
we
have
two
issues,
one
from
armin,
please.
E
Yeah,
so
we
don't
have
any
responsible
disclosure
guidelines
for
security
issues
yet,
and
there
has
been
a
pr
waiting
for
a
month
now
for
reviews.
So
if
anyone
is
more
familiar
with
that,
please
take
a
look
and
review
and
also
I
would
like
to
have
someone
from
the
governance
committee
to
review
it
as
well
would
be
nice
so
nothing
to
do
in
this
car,
but
to
have
a
look
at
offline.
B
Thanks
sweet
okay,
now
on
to
distros.
H
Yeah
we
already
talked
about
this.
I
just
I
posted
something
in
the
issue
that
tristan
created
about
vendors
and
I'm
just
linking
here
to
the
reasoning
and
an
example.
H
P
B
Okay,
if
that's
all,
then
I
guess
we
can
talk
about.
We
can
give
some
time
for
andrew
for
metrics
issues
destroying.
B
D
B
D
Okay,
so
this
was
a
result
of
this-
is
left
over
from
our
issue
triage
meeting
on
friday
scrub
through
a
good
number
of
issues,
and
we
just
need
to
go
over
these
new
metrics
issues
to
make
sure
they
apply
towards
our
understanding
of
p1
p2
p3.
Some
of
them
are
old
where
we've
said
required
for
j,
but
it's
like
p3
and
I
think
we've
scrubbed
some
of
them,
but
we
have
to
go
through,
and
so
I
can.
D
D
Let
me
see
this
is
after
ga,
spec,
so
I'll
leave
that
one
after
ga,
after
ga
required
for
gap2
okay.
So
this
one
needs
to
either
be
set
to
p1
or
put
it
as
allowed
for
ga.
L
L
I
think
a
lap
ga
is
okay.
This
is
this
has
been
a
hot
issue,
it's
kind
of
hard
to
reconcile
p3
with.
L
This
continues
to
be
a
like
a
really
frequent
question.
John
watson
has
sort
of
done
the
most
work
on
trying
to
finish
this
item.
I'd
say
we
could
have
sent
it
to
him.
I
think
this
is
also
a
lot
of
work,
but
probably
there's
something
that
we
need
to
get
in
the
ga
because
of
open
census,
compatibility
promises
that
were
made
a
year
ago.
L
I
think
that's
great,
that's
totally
fine,
there's
several
documents
out
there
already.
We
just
need
to
gather
ourselves
and
decide
what
we're
gonna
do.
N
O
I
think
always
with
no.
I.
L
D
N
Okay,
perfect:
we
should,
by
the
way
everyone
friday
will
probably
go
another
round
over
all
of
them
to
be
prioritized
or
increase
priority
for
some
of
them.
We
don't
have
time
right
now,
but
friday,
during
the
the
scrub
meeting
and
stuff,
we
may
do
a
revisit
of
everything.
Probably
I
don't
know
but
encourage
everyone
who
is
interested
to
to
come
to
the
third
event.
D
D
N
Yeah
thanks
everyone.
I
think
there
are
so
fyi.
We
filled
a
bunch
of
context
text
things
to
the
issue
of
spam
context
versus
spam
reference.
Please,
please
read
it
before
before
tonight,
meeting
or
evening
meeting
anything
urgent.
There
were
a
couple
of
items.
We
skipped
from
the
agenda
anything
urgent
that
we
need
to
discuss.