►
From YouTube: 2022-08-25 meeting
Description
Instrumentation: Messaging
A
A
And
it's
going
all
right,
this
document
kind
of
a
pain
but.
B
B
C
A
Yeah
yeah,
it's
okay!
Everybody
should
go
to
the
slack
to
pick
up
the
temporary
notes
for
today.
B
Yeah
that
sounds
good
david,
we're
talking
async
just
to
double
check.
Did
you
ping
rahul
by
chance
just
to
see
if
he
he's
around
and
maybe
change
permissions.
B
Okay
did:
did
you
ping
him.
B
Well,
josh
is
on
the
call.
So,
let's,
let's
start
there,
maybe
actually
I
see
that.
Where
are
we
at
we're
two
minutes
in?
I
guess
we
could
probably
start
now,
because
oh
there's
anthony
yeah,
because
I
think
we
see
the
people
that
we
need
to.
At
least
this
is
kind
of
a
a
meta
topic,
at
least
but
yeah.
So,
let's
jump
into
it.
Welcome
everyone.
B
If
you
haven't
already,
I
posted
a
link
in
slack
for
the
new
meeting
notes.
The
meeting
was
updated
to
have
the
new
meeting
notes
and
I
posted
them
in
the
zoom
link.
However,
the
zoom
chat
always
get
refreshed,
so
there
you
go.
I
posted
it
again.
If
you
haven't
seen
the
new
meeting
notes,
they
are
a
temporary
space.
The
first
item
on
the
agenda
is
the
meeting
notes.
The
old
meeting
notes
are
locked.
If
you
have
access
to
them.
B
B
Yeah
I
it
was
like
you
or
rahul
were
the
only
two
that
I
thought
of,
although
technically
I
think
bogdan
was
on
here
and
then
maybe
ben
siegelman
originally,
but
but.
B
B
Well,
definitely,
no
on
ben
he
checked
and
then
I
haven't
heard
from.
B
Okay,
yeah,
I
we
apologize
to
everyone
on
the
call
for
the
confusion
here.
It's
something
I
think
we
talked
about
at
the
project
bill
to
try
to
get
the
gc
to
own
these
sort
of
things,
and
so
this
might
be
impetus
to
to
get
them
officially
moved
over.
So
I.
B
B
I
do
get
that,
I
mean
I
guess
I
could
just
request
it.
I
guess
this
would
go
to
some
email.
C
Right,
that's
fine
it'll
go
to
whoever
owns
it.
I
requested
it.
I
can
also
start
picking
people.
I
don't
think
we're
gonna
get
it
today.
So
maybe.
B
Yeah,
no,
I
I
don't
either
we
can.
We
can
progress
but
yeah.
Maybe
just
isn't
that
yeah,
we'll
copy
yeah
we'll
get
an
action
item
if
you
could
just
follow
up
with
rahul
or
if
you
get
a
response.
B
I
will
also
take
an
action
item
to
be
the
one
to
try
to
follow
up
with
this,
so
it's
resolved
by
next
week
and
I'm
not
the
one
who
owns
it
in
some
one-off
accounts.
This
happens
again.
B
Okay
cool,
so
with
that
we
have
some
administrative
work
out
of
the
way,
and
then
we
can
jump
in,
I
think,
to
the
metrics
sdk
progress,
because
I
had
that
on.
The
agenda
seems
to
be
our
favorite,
let's
jump
in
here,
so
we're
85,
complete,
which
is
pretty
similar
to
what
it
was
last
week.
I
think
it
might
actually
be
backwards
a
little
bit,
but
I
think
that's
just
because
we
have
a
lot
of
stuff
that
was
added
to
the
to
do
and
blocks
column.
B
Do
you
think
that
we
got
a
few
things
merged?
I
took
a
few
days
off
the
beginning
of
this
week,
so
I'm
not
the
most
familiar.
I've
been
trying
to
review
it
this
morning
and
I
think
that
it's
pretty
stable
compared
to
what
I
saw
last
week.
We
still
have
a
very
similar
set
of
issues
that
are
in
progress.
B
Currently
they
implement
the
stubbed
async
instruments
which
is
being
addressed
in
3084
here,
along
with
the
callback
handling
the
otlp
metrics
exporter
is
in
progress.
The
headline
is
this
one,
which
has
reviews-
and
I
kind
of
wanted
to
talk
about,
but
it
may
get
merged
today
and
then
the
open
census
bridge
code,
which
is
in
work.
C
C
B
Yeah,
that's
a
good
question.
Maybe
I'll
I'll
ask
the
group
what
they
think
about
this.
Where,
where
are
we
here?
It
looks
like
I'm
the
only
one
that's
actually
approved
this.
C
Yeah,
no
we've!
So
actually,
if
you
scroll
up
slightly
there's
a
longer
thread,
that's
got
a
bunch
of
options
in
it.
C
There
we
go
we're
trying
to
decide
how
related
it
should
be
to
metric
producer.
B
Okay,
yeah:
I
haven't
taken
a
look
at
this
yet,
but
I
will
I'll
put
this
on
something
to
get
some
eyes
on,
but
that's
a
okay,
so
there
it
doesn't.
Look
like
this
is
ready
to
merge,
is
also
the
takeaway
for
this
spec
right.
C
B
Yeah,
okay,
yeah.
It's
definitely
worth
if
you're
on
the
call,
and
you
would
like
to
help
progress,
not
only
this
sig
but
the
the
larger
open
telemetry
projects
for
their
bridge
support.
I
would
recommend
taking
a
look
at
this
pr
that
I
have
listed
here
in
the
specification
for
two
it'll
help.
I
mean
I
actually
don't
know
how
the
sigs
are
doing
the
bridge
currently
if
they
are,
but
it's
gonna
be
needed
for
our
open
census
bridge
for
backwards
compatible
support.
B
But
then
back
to
your
question
about
whether
you
want
to
merge
something
in
this
thing
or
to
wait
on
it.
That's
a
good
question.
What
do
other
members
can
think
about
this.
A
I
would
actually
be
up
for
pushing
this
to
the
beta.
I'd
prefer
not
to
have
something
some
version
release
where
we
have
something,
and
then
the
next
version
up.
We
change
it
because
that
ends
up
causing
a
lot
of
churn.
If
we
can
avoid
it.
E
Yeah,
I'm
kind
of
on
the
fence
on
this.
I
think,
if
nobody's
clamoring,
for
its
replacement
in
this
sdk,
I'm
with
aaron,
if
someone
has
a
real,
clear
and
present
need
for
it,
it's
still
awful.
We
expect
changes,
so
I
wouldn't
be
opposed
to
including
it,
but
if
we
don't
need
to,
let's
not.
C
I
could
try
and
re-implement
the
old
version,
which
was
sort
of
a
wacky
exporter,
wrapper
thing,
because
that
wouldn't
involve
making
any
changes
to
the
current
interfaces,
or
maybe
we
can
wait
until
someone
asks
for
it.
B
Yeah,
I
isn't
bridge
one
of
the
things
that
opensource
tries
to
specify
as
a
needed
thing.
I
don't
know
what
our
requirements
are.
Installation.
B
Okay,
yeah
I
so
I
definitely
have
the
opinion
that
this
is
an
alpha
release
and
if
the
interface
has
changed,
that's
kind
of
expected.
B
I
also
hear
what
aaron's
saying
from
the
user's
perspective
like
whether
it's
alpha
or
whether
it's
stable,
sometimes
people
just
take
a
dependency
on
it
and
don't
realize
the
severity
of
what
they're
doing
so.
If
we
could
try
to
alleviate
that-
and
you
know
it
doesn't
add
too
much
turn
to
us.
I
think
that's
a
good
idea.
B
I
I
like
the
idea
of
maybe
saying,
like
let's
not
block
the
alpha
release
on
this
open
census
bridge
just
so
we
can
get
something
out
and
you
know
reducing
scope's,
always
a
great
way
as
long
as
it's
not
like
reducing
the
functionality
of
what
we're
trying
to
release-
and
I
think
this
is
a
good
use
case
for
it.
What
do
you.
C
B
Okay,
because
I
think
that
what
the
interface
changes
would
happen,
if
we
went
with
what's
currently
being
proposed
in
specification,
would
be
an
addition
of
interfaces
and
an
additional
functionality.
So
I
don't
see
it
as
that
being
as
a
destructive
change
or
any
disruptive
change
to
you
know
early
adopters
of
the
alpha
sdk,
so
okay,
that
sounds
good
I'll
organize
after
this
to
connection
item
here.
D
B
Yeah,
I
I
was
thinking
about
this
as
carefully
as
I
could
and
I'll
be
honest.
I
thought
about
it
and
I
tried
to
have
a
perspective
of
other
cities,
but
I
do
recognize
that
this
is.
This
is
kind
of
a
big
one,
but
I
also
recognize
the
need.
I
don't
think
it's
something
that
we
could
just
not
handle.
We
need
to
have
a
clear
story
for
cigs
as
to
how
they're
supposed
to
support
open
census.
Like
that's
that's
important,
it
helps
us
with
a
migration
story,
so
it
helps
with
user
adoption.
B
It
helps
us
in
compatibility
and
support.
So
I
definitely
think
this
is
a
it's
something
worth
responding
to.
I
also
know
you're
paying
josh,
because
I
have
many
tabs
open
that
I
just
I
find
like
three
weeks
later
going
like
oh
my
gosh.
I
never
hit
send
on
that.
Okay.
A
The
one
thing
that
I
can
kind
of
see
from
this
proposal
is
one
of
the
difficulties
where
josh
I
know
has
had
in
capturing
go
metrics,
you
know,
go
added
a
number
set
of
metrics.
Some
of
them
are
histograms.
We
have
no
way
of
importing
like
a
histogram
summary
into
our
current
sdk.
A
C
Incorporated
that
so
the
current
proposal
would
be
used
to
produce
summaries.
For
example,
if
you
wanted
cool
yeah.
D
There
seems
to
be
also
a
connection
with,
because
I
remember
writing
these
options
down
myself
for
some
reason,
once
it
was
relation
to
how
you
redefine
and
what
a
reader
is,
but
also
it
felt
like.
There
was
a
standing
question
waiting
around
for
this
debate
about,
if
you're
exporting
to
prometheus,
and
you
have
more
than
one
meter
provider.
C
I
was
wondering
if
there's
a
way
to
ensure
that,
basically
that
you
can't
register
that
a
metric
producer
that,
like
a
bridge
thing,
has
a
name
and
if
it
were
all
funneled
through
one
meter
provider,
the
meter
provider
could
ensure
uniqueness
between
meters
and
metric
producers
so
that
they
they
would
each
have
they'd
each
be
insured
to
have
a
different
scope.
C
B
But
does
this
go
back
to
like
having
global
state
shared
across
all
meter
providers,
then.
C
No,
this
is
for
a
single.
This
would
be
the
idea
of
a
single
meter
provider,
yeah.
B
C
Responsible
for
sdk
or
sorry
is
responsible
for
open
telemetry
instruments,
but
then
also
has
one
or
more
metric
producers.
B
We
gotcha
wow,
that's
a
really
hard
problem.
Well
for
one
I'm
happy
you're
thinking
about
it
to
now.
I
need
to
think
about
the
whole
space
as
well.
That's
good!
That's
a
good
one!
Wow!
Okay!.
B
Okay,
david.
I
will
definitely
take
a
look
at
the
specification.
Pr
again
have
you
did
we
talk
about
that
on
tuesday?
I
wasn't
at
the
spec
meeting.
C
No,
I
was,
I
was
at
the
beach.
So,
okay,
you
know.
B
Okay,
is
it
something
we
can
get
on
the
agenda
for
next
week?
I'd
like
to
talk
about
this:
okay,
cool,
okay,
great,
so
one
of
the
things
that
also
just
kind
of
came
to
my
mind.
If
we're
going
to
be
moving
this
task
to
the
the
beta
release,
what
do
we
think
about
this
prometheus
exporter
code?
Should
that
also
be
moved,
or
is
that
something
we
want
to
include
back
in
the
alpha
release.
F
So
I
just
haven't
really
started
on
this,
yet
I've
had
other
things,
I'm
still
planning
to
get
started
on
it.
If
that
influences
the
plan
for
alpha
or
beta.
B
Thanks
mike
yeah,
I
didn't
see
on
there
sorry
but
yeah.
That's.
B
I'll
be
honest,
I
don't
imagine
this
to
go,
really,
quick
and
so
like.
I
could
definitely
see
it
taking
a
little
bit
and
I
do
think
like
if
we
took
out
the
prometheus
prometheus
exporter
code,
the
open
census
bridge
and
put
those
in
beta
for
one.
It
doesn't
block
us
on
accomplishing
those
tasks
like
if
we
have
prs
that
we're
able
to
submit
to
the
alpha
branch
before
we
want
to
do
this.
B
Merge
task,
like
I
don't
think,
there's
a
blocker
there,
but
I
also
think
that
if
we
get
something
like
the
otp
metric
exporter
involves,
you
can
always
just
say,
like
the
alpha
release
uses
the
collector
to
do
all
of
our
exports
essentially
like.
If
you
want
to
go
prometheus,
send
it
to
the
collector.
B
It's
not
a
great
user
story.
I
think
that
that's
something
that
we
should
fix
in
the
beta
release.
We
should
have
the
exporters
that
we
originally
had,
but
I
I
definitely
think
that,
like
it's
a
usable
like
proof
of
concept
at
that
point,
I'm
just
I'm
just
thinking
about
reducing
scope
to
try
to
get
the
the
iterations
a
little
bit
faster.
B
So
maybe
maybe
that's
a
good
question
mike?
What's
the
timeline,
you
think
you
have
for
this
marine
theatre
sex
board
code?
Are
you
planning
on
working
on
it?
I
guess
this
week's
almost
up
but
like
next
week
or
the
week
after,
or
is
this
something
that
you
know
within
the
month
you're
expecting
to
have
address.
F
I
mean
I
was
planning
to
start
it
actually
this
afternoon
next
week
week
after
is
like
the
time
frame
that
I
want
to
have
it
like
done
by
it
sounds
like
you
think
it's
a
bigger
task
than
that,
though,
but
I'd
be
working
on
it
mostly
next
year,.
B
Yeah,
don't
I
mean
I
that's
just
personally,
I
I
haven't
looked
too
much
at
the
we're
doing
a
bunch
of
push
exporters,
maybe
a
poll
so
there's
there's
just
unique
prometheus
like
details
there.
So
if
you're
very
familiar
with
prometheus,
I
imagine
that
that's
not
going
to
be
the
case,
but
I
may
not
be
as
familiar
so
okay,
so
why
don't
we
just
leave
that
there?
A
So
tyler
about
moving
it
to
the
beta,
I'm
100
for
it,
but
I'd
probably
also
suggest
that
we
try
at
least
some
way
to
get
feedback
on
whether
or
not
this
is
important
to
current
users.
A
Maybe
just
a
message
in
the
slack
at
this
point
of
like
we're
going
to
down
scope
the
open
the
open
census
to
the
beta.
Not
this
current
release,
but
the
alpha
is
anybody
actively
using
it
and
clamoring
to
try
out
the
new
the
new
sdk.
B
Okay,
I
will
also
take
as
an
action
to
communicate
and
slack
the
scope
change
just
to
see
what
sort
of
user
feedback
we
have
on
that.
B
Yeah
right,
yeah,
absolutely
okay,
that
looks
great
so
then
I
wanted
to
touch
base
on
what's
currently
in
progress.
This
is
the
part
where
I
have
been
out,
so
I
don't
haven't
been
the
most
active
on
this,
so
I
know
that
this
looks
like
it
just
got
all
the
reviews
this
morning,
but
I
had
an
outstanding
question.
B
So
there's
this
question
of:
do
we
actually
need
to
be
exporting
this
client
interface
aaron
pointed
out
that
yeah
like
how
do
you
differentiate
between
this
client
for
http
and
geography,
which
is
which
is
totally
valid,
but
one
of
the
things
I
was
also
considering
when
I'm
doing
this
and
actually
re-implementing
is
like.
I
don't
like
this
client
and
exporter
interface
in
the
otp
otlp
metrics
exporter,
for
those,
maybe
who
don't
aren't
familiar
with
the
exact
topic
that
I'm
referring
to.
Currently.
B
What
we
have
here
is
this
client
interface,
and
this
essentially
is
the
way
that
you
transmit
data
and
this
exporter,
which
is
an
implementation
of
like
the
sdk
metrics
exporter,
and
so
this
is
the
thing
that,
like
the
sdk,
is
going
to
be
handed
and
it
wraps
the
client.
So
it
can
send
it
off
to
an
http.
You
can
send
it
essentially
whatever
protocol
you
want
to
write
for
your
own
client.
We
currently
support
http
and
grpc
with
protobufs.
B
The
thing
is,
though,
like
and
actually
maybe
I'm
glad
josh
is
not
here,
because
I'd
like
to
know
why
we
need
this
in
the
first
place,
because
I
I
think
there
was
a
reason
why
we
needed
to
like
create
a
client
and
then
maybe
at
a
later
point
create
an
exporter,
but
I
I
don't
remember
because
like
if
you
think
about
it,
all
this
is
doing
is
is
like
stringing,
two
things
together
and
that's
wrapping
a
client
in
an
exporter,
and
if
you
look
at
all
the
implementations
like
in
grpc
like
this
is
a
good
example
like
that's
all
it
does.
B
Is
it
just
calls
this?
You
know
new
method
with
a
new
client
and
then
just
wraps
it,
and
I
find
that
a
lot
of
the
time
that
I
I
see
uses
of
this
exporter
in
a
single
line.
People
are
just
doing
this
and,
and
they
didn't
realize
that
this
convenience
function
is
here.
So
I
was
just
like
questioning,
like
I
mean,
do
we
even
need
this
exporter
type
at
the
higher
level,
because
at
the
higher
level
like
all
it
does,
is
just
string
things
together?
B
I
think
the
exporter
it's
a
great
way
to
abstract
the
functionality
of
the
exporter,
to
implement
the
interface
into.
I
think
there's
a
few
other
things
you
can
handle,
but
does
it
need
to
be
exported
to
the
user
like?
When?
Does
the
user
actually
need
to
do
this
construction,
rather
than
just
the
user,
getting
some
sort
of
new
function
and
they're
handed
back
metrics
exporter?
D
Don't
see
any
reason
that
I
can
recollect,
I
mean
I've
seen
that
pattern
of
wanting
to
like
create
stuff,
configure
it
and
defer
until
the
error
until
like
something
starts,
but
it's
easy
to
work
around
not
having
it.
I
don't
recall
why
that
was.
E
Done
my
recollection
of
the
reasoning
for
this
was
twofold,
so
that
one
people
can
bring
their
own
clients
if
they
want
to
implement
other
transport
mechanisms
and
two
so
that
the
client
can
be
reused
elsewhere.
So
our
existing
clients
can
be
used
for
things
that
want
to
produce
to
an
otop
receiver
metrics,
but
not
necessarily
use
our
sdk
to
construct
them.
D
I
can
say
the
lightstep
sdk,
which
you
know
is
meant
to
be
temporary
and
is
is
using
using
those
exporters
using
the
client
but
not
the
exporter.
It
was
a
nice
way
for
me
to
build
part
of
a
replacement
sdk
without
using
without
replacing
all
of
it.
I
wouldn't
say
that's
a
requirement.
It
was
very
convenient
for
us.
I
also
believe
that
that's
been
a
source
of
contention
with
stability
guarantees
like
we
have
trouble
changing
the
protocol,
because
that's
a
public
interface
in
some
level-
and
I
I
don't
really
care
for
that
debate.
B
E
B
Right
right
because
this
is
depends
on
the
otlp,
but
it's
also
a
public
interface
that
we're
exporting.
B
Okay,
this
is
all
really
good
feedback.
I
appreciate
it.
I
think
I
will
probably
address
the
remaining
issues
that
david
brought
up
and
try
to
merge
this,
and
if
I
feel
strongly
that
we
should
unexport
that
I
will
try
to
also
create
an
issue
to
track
that
for
the
alpha
release
in
the
next
day
or
two
but
yeah.
That's
I'd
like
to
think.
B
That
was
my
biggest
issue
as
well
this
divergence.
I
also
think
that
our
creation
set
up
for
like
the
grpc
would
have
been
way
better
if
we
just
accepted
a
grpc
client,
instead
of
all
these
other
like
doodads,
but,
like
you
said,
you
can't
really
unring
that
bell
so
yeah.
That's
that's
also
a
really
good
point
anthony.
B
That
is
why
I
originally
just
kept
it
the
way
it
is,
and
I
probably
would
continue
to
keep
it
the
way
it
is,
but
I
I
think
I
want
to
think
a
little
bit
more
about
that.
B
Okay,
I
appreciate
it
cool
we
can
probably
move
on.
I
think
I'll
probably
have
a
good
take
away
from
that
aaron.
I
wanted
to
touch
base
on
this
one.
I
spent
just
a
few
minutes
before
I
dove
in
a
bunch
of
other
things
that
were
coming
up
this
morning.
Where
were
we
at
on
this?
I
know
that
you
addressed
a
lot
of
the
feedback
that
I
gave
and
other
people
have
approved
it.
So
I
just
want
to
like
touch
base.
A
I
just
wanted
to
get
one
final
passover
from
you,
honestly,
is
where
I
was
at
other
than
that
it
looked
good
to
go.
B
Okay,
I
will
do
that
this
afternoon.
That
is
once
I
address
the
exporter.
B
Oh
man,
I
should.
B
No,
it's
myself
I've
taken
three
days
off:
it's
never
easy
to
recover
from
yeah.
I
think
I
should
try
to
prioritize
this.
I
will
do
that
then,
and
I'll
get
another
review,
probably
right
after
this
meeting
or
after
another
coffee,
okay,
cool
with
that,
I
think
everything
else
has
stayed
stable,
so
we
probably
don't
need
to
go
over
the
to-do
or
blocked
we're
looking
good.
I
think
our
timelines
are
still
doing
great,
especially
if
we
can
reduce
the
scope
a
little
bit.
B
I'd
love
to
I'd
love
to
beat
this
date,
so
maybe
we
can
even
get
like
a
beta
out
by
then,
but
that's
ambitious,
to
say
the
least
cool.
B
E
I
just
snuck
that
in
I
saw
this
last
night
and
came
back
and
saw
there's
been
some
more
discussion,
so
I
think
generally,
the
the
the
thought
here
is
good,
like
we're
currently
panicking
if
start
span
is
given
a
new
context
or
a
nil
context,
and
that's
that's
bad.
E
I
don't
know
if
this
is
the
right
answer.
I
don't
know.
If
there's
any
other
answer,
though,
either.
B
Yeah,
that's
a
good
question.
I
I
as
well
took
a
brief
look
at
this
and
I
think
I
think
you're
right.
I
think
I
actually
agree
with
a
lot
of
the
conversation
that
I
think
I
had
the
same
conversation
in
my
head.
That's
going
on
down
here,
where
you
know
go,
probably,
should
have
the
ability
to
you
know
you
shouldn't
be
passing
a
nail
context.
B
That's
kind
of
a
thing
david
correctly
points
out
that
maybe
that's
a
thing
and
go,
but
there
is
a
thing
in
the
open,
telemetry
specification
that
says
we
shouldn't
be
panicking,
which
I
think
is
also
valid
so
yeah.
I
think
anything.
I
I
I'm
with
you
on
that.
The
one
thing
I
wanted
to
take
a
look
at
is
this
function
I
think
like
does
this
need
to
handle
until
con?
Oh,
it
does.
B
Okay,
where
are
we
panicking?
B
E
Yeah,
no,
I
just
figured
we
are
all
here
and
if
there's
discussion
to
be
had
that's
a
good
time
at
least
ask
people
to
take
a
look
at
it
if
they
haven't
already
seen
it.
I
think
most
everybody
here
has
seen
and
commented
on
this.
B
I'm
trying
to
find
out
where
the
panic
would
come
from,
but
yeah
that's
this
looks
good.
I
will
also
it's
also
on
my
agenda
things
to
try
to
do
today.
B
Okay,
I
think
with
that
we
have
all
of
the
agenda
items
addressed.
Erin.
Did
you
add
this
copy?
These
minutes
to
the
old
meeting
notes.
A
Yes,
yes,
I
did
just
as
a
standard
whenever
we
figure
out
the
old
meeting
notes.
Yeah
get
this
over
there.
So.
B
Yeah,
let's
I
just,
I
think,
our
action
items-
I
guess
we
don't.
This
is
new.
We
don't
know
if
they
have
action
items,
but
we
should
probably
have
an
owner
for
them,
and
I
will
just
take
that
as
a
as
a
part
of
resolving
the
meeting
notes
to
make
sure
they're
copied
over
or
archived
in
some
way
like
we
need
to
have
access
to
them,
which
may
be
a
tall
task
now
that
we
don't
have
access
anymore,
but
ideally
yeah.
B
B
Right,
okay
right
at
least
these
notes
will
go
in
yeah,
I'd
be
kind
of
bummed
if
we
lose
all
the
other
ones,
but
I
do
search
through
them
sometimes.
But,
yes,
I
think
you're
right,
okay,
cool!
I
will
just
pause
here,
see
if
anybody
else's
ideas
or
other
agenda
items
that
they
wanted
to
bring
up
that
weren't
listed.
B
Okay,
are
there
any
cool
use
cases
of
open
symmetry
or
uses
you've
seen
out
in
the
wild.
B
Well,
okay,
I
guess
that's
probably
about
it.
Then
we
could
probably
end
it
early,
pretty
excited
to
jump
back
in
sorry
about
the
delay
on
some
of
these
pr's,
but
yeah
glad
to
be
back.
I
will
handle
the
meeting
notes
and
hopefully,
we'll
be
back
at
it
next
week,
thanks
everyone
for
joining.
I
really
appreciate
your
time
all
the
development
effort
so
see
you
all
next
week
same
place
same
time,
bye.