►
From YouTube: 2022-03-14 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
B
B
Hey
guys,
I
can
leave
the
meeting
in
a
few
minutes,
but
if
someone
wants
to
start
it
sooner.
C
A
People
just
want
to
fill
out.
The
maintainer
notes
give
people
a
couple
more
minutes
to
finish
those
up,
then
we'll
go
through.
If
anyone
has
any
additional
agenda
items
throw
them
on
there.
D
D
A
A
A
Okay
looks
like
everything's
in
let's
get
started
from
the
top
so
specification.
How
are
things
going
there.
D
I
guess
the
elephant
in
the
room
is
metrics.
Sdk
spec
is
about
to
be
stable.
We
think
people
on
this
call
ought
to
pay
attention
to
some
debates.
I
would
say,
if
you're
close
enough
to
the
metrics
sdk,
to
understand
what
I'm
speaking
about
the
debate
that
we're
having
is
how
clear
the
sdk
spec
is
about
exactly
the
interfaces
that
relate
to
components.
So
there's
an
exporter
concept,
there's
a
reader
concept.
D
D
Approvals
are
very
important
and
if
there's
something
clarifying
that
can
be
added,
please
ask
for
it,
because
I
think
at
this
point
the
big
disagreements
are.
We
all
understand
the
spec
document
a
little
bit
differently
and
we
need
to
fix
that.
But
at
this
point
I
don't
think
we're
disagreeing
over
scope
of
the
project.
You
know
the
scope
of
the
sdk,
so
we're
ready
to
call
it
stable.
We
just
we're
not
sure
we
all
understand
this
understand
it
the
same
way.
So
if
you're
close
to
it
help
please.
D
I
am
referring
to
that
discussion.
There
were
three
pr's
put
out
at
first
on
this
topic
to
sort
of
feel
out
the
community
and
what
what
we
want.
2404
is
my,
hopefully,
the
one
that
resolves
it
in
the
end.
I
have
iterated
on
that
several
times,
based
on
the
feedback,
and
my
opinion
is
that
that
lots
more
checks
could
be
helpful,
but
we
don't
always
have
time
to
sit
around
writing
lots
more
text.
D
So
the
questions
that
you
ask
me
will
will
be
very
helpful
to
help
us
get
close
to
the
end
here.
Okay,.
A
A
Looks
like
we
don't
have
a
log
logging
sig
wrapped
here.
Look
at.
It
also
looks
like
maybe
known
for
php,
so
moving
on
to
java.
How
are
things.
E
E
F
A
Cool
yeah,
one
of
the
questions,
I'm
you
know
starting
to
get,
is
what
what
state
are
the
metrics
implementations
in
and
what?
When
will
a
release
candidate
be
out?
So
once
we
stabilize
this
last
bit
of
the
spec
I'd
love
to
work
with
maintainers,
just
to
figure
out
the
best
way
to
give
those
projections
to
to
users.
A
We're
not
there
yet:
okay,
javascript
metrics
work.
A
H
A
Okay,
oh
and
for
js
and
python
yeah.
What
is
it
you
said
experimental
for
python,
but
is
it
like
beta
ready?
Would
you
say.
G
It
is
not
yet
releases
something
official
that
with
an
api
that
we
expect
to
be
backwards
in
part
with,
but
it's
there
already
and
it's
performs
the
most
basic
matrix
things,
so
users
can
actually
use
it.
C
Okay,
so
our
our
most
noticeable
or
most
notable
missing
component
is
the
exporter,
which
is
obviously
important
that
one
for
sure
yeah.
But
beyond
that,
I
would
say
we
are
in
a
similar
place.
C
I
would
not
be
pushing
anyone
to
play
with
it
today,
but
ask
me
again
in
two
weeks
sounds
good.
A
Yeah
yeah
you'd
say
it's
in
the
a
playable
feedback,
giveable
stage
great.
A
Okay,
dot
net.
A
H
Yeah,
that's
in
a
pretty
similar
state.
I
think,
as
java
close
to
close
to
being
completed
waiting
for
these
final
clarifications
at
the
spec
level-
2404,
namely
great
and
then
just
kind
of
final
review,
cleanup
of
things
and
so
on.
It's
kind
of
ongoing,
but
we're
close
awesome.
A
D
Yeah
there's
a
lot
of
metrics
work
going
on.
I
I
am
aware
of-
and
I
will
just
say
this
there's
a
debate
over
the
api
that
landed
in
three
weeks
ago
or
so.
The
debate
is
people
who
weren't
close
enough
to
conversation
when
it
happened,
are
now
kind
of
objecting.
So
I
think
that's
worth
serious
consideration
to
revise
that
as
well.
D
I
Yeah,
I
could
explain
this
a
little
bit
so
the
way
it'll
work
is
that
the
metrics
api
will
not
require
118..
It
will
be
compatible
with
117
and
even
116..
I
I
A
I
I
I
see
okay
and
as
for
the
the
api,
we
don't
yet
have
a
release
with
that
shipped,
but
if
users
are
comfortable
with
using
pre-release
apis
by
changing
their
go
mod,
we
would
love
some
feedback
on
the
api
as
it
exists
on
the
main
branch.
Currently
that
could
feed
into
that
discussion.
That
john
was
or
josh
was
talking
about.
Sorry.
A
I
A
Okay
c
plus
plus
everyone's
working
on
metrics.
It's
so
awesome.
J
Yeah,
so
I
think,
as
it
says,
the
matrix
work
is
ongoing.
You
still
have
few
pieces
to
be
in
place
to
have
an
end
to
end
pipeline
working.
So
probably
we
are
by
the
end
of
the
march.
I
think
that's
a
tentative.
We
are
trying
that
if
we
have
something
experimental
great
which
to
be
play
play
with,
but
that's
not,
that
would
be
something
which
would
be
usable
out
of
the.
A
That's
awesome
and-
and
I
see
you,
you
have
a
milestone
in
github-
that
I
can
point
people
to
if
they're
wondering
about
progress.
G
A
K
H
K
Yeah,
like
everything
most
of
the
work
is,
is
an
open
pr,
so
it
hasn't
merged
in
to
the
repost
there's
no,
no
actual
releases
for
anybody
to
play
with.
Currently,
you
could
try
to
check
out
a
pr
if
you
were
super
adventurous.
A
I'm
gonna
say
not
not
ready
yet
for
playing.
I
think
that's
fine,
fine
place
to
be
just
good
to
know.
Is
there
anyone
from
the
swift,
sig.
A
I
do
want
to
talk
to
the
swift
people
at
some
point
soon,
because
we
have
all
of
this
rum
client-side
instrumentation
work
going
along,
and
I
believe
some
people
from
there
are
talking
talking
to
the
swift
people
and
I
think
they
might
be
talking
to
the
javascript
sick,
but
I
want
them
to
to
start
showing
up
a
little
more
heavily
to
those
groups
soon,
once
we
have
like
an
actual
otep
in
hand
to
discuss
with
people,
because
it's
very
pertinent,
obviously
to
browser
javascript
and
swift,
and
also
android
but
john's,
been
following
that
stuff.
C
Going
on,
we
had
at
least
one,
I
think,
maybe
two
actually
from
that
from
that
sig
joined
the
javascript
meeting
last
week,
nice.
A
A
You
could
set
it
as
a
resource,
but
resources
are
immutable
and
session
ids,
don't
necessarily
show
up
first
thing.
So
that's
I
would
say
that's
like
of
all
the
work
I've
seen
on
going
in
that
group.
We
were
able
to
get
pretty
much
all
of
it
boiled
down
to
just
basic
primitives
that
we
already
have,
but
the
session
session
id
concept
is
like
the
one
thing
that
doesn't
we
don't
have
like
a
box
to
put
that
in
so
just
a
heads
up,
that'll
be
up
some
spec
work.
L
There
is
yep,
so
there
will
be
zero
47's
going
out
this
week
and
that's
that's
really
it.
Okay.
A
I'm
curious
what
what's
the
state
of
metrics
in
the
collector.
I
assume
there's,
like
you,
know,
otlp
metrics,
receiver
and
exporter,
but
are
there
processors
of
any
kind
or
anything
going
on
there.
L
Nothing,
nothing
particular
in
this
release.
I
think
we're
just
continuing
with
the
work.
That's
already
existing,
there's
a
bunch
of
processors,
there's
a
bunch
of
receivers
that
generate
metrics.
This
isn't
anything
new
for
the
collector.
G
A
Rest
rest-
people-
maybe
maybe
not
erlang.
I
don't
see
the
airline
crew,
so
I
think
that's
that
great
moving
on
I
agenda
item,
which
is
just
I
would
love
to
get
some
quick
feedback
from
the
maintain
our
community
that
we
got
on
the
call
thinking
about
improving
improvements.
To
and
clarity,
I
should
say
as
to
how
we
handle
like
the
specification,
backlog
and
oteps
some
experience.
We've
had
from
the
the
spec
sigs
that
we
spun
up.
A
We
spun
up
a
couple
instrumentation
sigs
recently
that
were
like
pretty
disconnected
from
the
core
specification
community.
It
was
like
a
lot
of
newcomers
basically,
and
we
also
get
this
feedback
from
you
know.
A
Basically,
yeah
people
who
are
not
on
say,
like
a
first
name
basis
with
people
who
are
on
the
tc
or
otherwise
you
know
closely
associated
with
with
the
spec
maintainer
crew,
is
that
they
can
get
a
little
lost
about
what
they
should
be
doing
and
how
they
should
be
resolving
prs
and
issues
when
they
get
stuck.
Most
of
our
stuff
we
have
written
down
is
like
it's,
the
owner
of
the
pr's.
A
You
know
responsibility
to
kind
of
like
resolve.
All
the
conversations
and
move
it
forwards,
but
they're
not
always
able
to
know
how
to
do
that.
A
A
The
other
situation
that's
difficult
is
when
they're,
just
like
isn't
consensus,
you
propose
a
change
and
half
people
show
up
say
like
yes,
I
really
want
this
and
the
other
half
people
show
up
and
say
like
yeah.
I
don't
know
about
this
and
it's
not
something
that
boils
down
to
like
a
clear
set
of
like
requests
for
changes
that
they
could
move
forwards,
so
trying
to
think
about
how
we
could
write
some
things
down
in
the
spec
repo
that
clarify
this
process
for
people,
and
I
have
a
pr
out.
A
That's
doing
that.
The
idea
that
I
came
up
with
was
adding
a
concept
called
sponsors,
which
is
basically
there's
someone.
Maybe
it's
the
person
assigned
to
the
pr
or
maybe
it's
someone
who's
gotten
assigned
to
the
spec
sig
or,
if
you've
created
an
issue
that
turns
into
an
otep.
The
sponsor
is
maybe
someone
who
gets
assigned
at
that
point,
but
someone
from
the
tc
or
tc
adjacent
who
would
have
like
the
responsibility
to
basically
be
the
the
point
of
contact.
A
That
would
not
do
the
spec
work
for
you,
but
be
the
person
who
would
help
you
shepherd
it
through
the
process
and
there's,
of
course,
like
questions
about
what,
specifically
that
that
role
should
have
if
we
want
it.
So
I'm
curious
if,
if
people
on
this
call
have
any
feedback
on
that
front,
either
from
their
own
experiences
in
the
spec
repo
or
just
being
a
maintainer
in
general
or
from
like
other
big
projects,
open
source
projects
that
you've
maybe
been
involved
with,
I'm
curious.
A
If
people
have
any
ideas
about
how
to
define
this
sponsor
role
or
an
alternative
to
that,
that
would
help
help
contributors
navigate
our
process
a
bit
because
it
is
more
complicated
than
just
making
a
typical
code
contribution.
C
I
think
in
theory
it
sounds
good,
but
I
worry
about
our
ability
to
follow
through
on
that
and
to
actually
follow
that
process
and
it's
hard
to
draw
the
line
of
like
what's
what's
a
small
change
that
doesn't
require
a
sponsor
and
a
big
change.
That
does
especially
for
a
new
contributor
that
might
not
be
well
equipped
to
distinguish
large
changes
from
small
changes.
C
I
mean,
I
think,
in
other
in
other
projects,
certainly
larger
projects
than
ours,
but
I'm
thinking
of
like
python
kubernetes
stuff
like
that.
If
it's,
if
it's
not
a
bug,
then
it's
a
new
feature
and
the
new
feature
has
to
go
through
the
whole
new
feature
process
like
you
know
what
would
be
the
otep
process
for
us
and
that
discourages
small
feature
editions.
So
I
don't
know
if
we
want
to
do
that
at
this
point,
we're
pretty
early
in
the
project
to
be
really
strict
about
that.
C
I
like
the
idea
of
a
sponsor
as
like,
a
if
you're
new
to
the
project.
This
might
be
helpful
for
you
but
to
enforce
it
in
order
to
get
changes
through
might
actually,
we
might
end
up
in
a
worse
situation
than
where
we're
at.
A
Yeah
thought
about
maybe
breaking
this
concept
up
so,
for
example,
when
it
comes
to
the
spec
things
when
we
spit
out
a
sig
to
work
on
a
particular
part
of
the
specification
like
rum,
for
example,
not
using
the
term
sponsor.
For
that,
just
saying
that
you
know
all
spec
sigs
have
to
have
tc
representation
on
it,
which
I
think
makes
a
lot
of
sense.
It's
just
saying,
like
hey,
the
maintainers
of
the
project
need
to
be
involved
in
any
like
group
who's
like
trying
to
work
through
problems
on
that
project.
A
That
part
seems
like,
like
super
open
and
shut
clear,
because
that's
like
ongoing
work
that
we're
super
committed
to
that's
like
why
we
spun
up
the
sig.
So
I
don't
think
you
need
to
use
the
concept
for
sponsors
to
describe
anything
going
on
there.
It's
just
hey.
If
we
spit
up
a
sig
it
can't
it
can't
just
be
new
contributors
working
on
their
own.
That's
not
gonna,
go
well
they're
gonna
run
into
all
kinds
of
shenanigans
or
even
worse,
do
a
lot
of
work
that
is
like
off
the
mark.
A
Essentially
so
we
could
like
maybe
carve
that
off
and
say:
that's
just
you
know,
don't
spit
up
cigs
unless
we
have
the
bandwidth
to
pay
attention
to
them
and
have
tc
members
on
them
yeah.
I
agree.
C
With
that,
especially
if
something
is
primarily
supposed,
if,
if
spec
work
is
their
primary
output,
if
if
the
project
doesn't
view
it
as
important,
as
you
know,
it's
not
important
enough
to
have
a
tc
member
pay
attention
to
it
regularly,
then
maybe
it's
not
important
enough
to
be
a
sick
yeah,
so
I
I
think
I
agree
with
that.
100.
A
Yeah
and
it's
also
kind
of
a
bandwidth
issue,
I
think
that's
for
me.
Some
of
this
process
is
about
recognizing
bandwidth
like
that's
something
I
think
you
mentioned
dan
was
like.
I
don't
know
if
we're
gonna
have
the
bandwidth
to
like
do
this
for
everyone,
but
in
a
sense
we
want
to
like
actually
get
a
sense
of
what
that
bandwidth
is
and
be
be
like
upfront
with
people.
A
This
is
like
a
thing
we've
discussed,
but
it's
it's
it's
very
hard
in
the
abstract
to
just
like
close,
a
pr
or
close
an
issue
by
saying,
like
yeah,
sorry
sounds
nifty,
but
we
are
not
like
in
a
place
to
to
do
this
right
now
come
back
later,
but
we
definitely
know
that.
That's
like
a
reality
that
we
have.
We
can't
we
can't
actually
focus
on
all
the
initiatives.
At
the
same
time,.
C
Yeah,
I
mean
maybe
better
use
of
like
the
milestone
feature.
Maybe
we
have
a
milestone
per
month
and
we
add
issues
to
them
and
then,
when
the
month
starts,
we
already
know
what
we're
working
on
that
month
and
you
just
don't
you
know
similar
to
at
internal
to
the
company.
We
have
the
sprint
cycle
and
once
the
sprint
starts,
we
don't
add
work
to
it,
decide
how
much
work
we
can
do
and
we
you
commit
to
that
and
at
the
end
you
look
back
and
you
say:
did
I
complete
it
or
not?.
C
M
Yeah,
so
I
have
a
question
how
the
sponsor
would
help
with
the
problem
of
like
conflicting
feedback,
and
that
seems
to
kind
of
be
tangential
to
that
to
the
sponsor
process.
So
I
don't
know
if
you
need
like
to
include
that,
but
that
is
like
a
maybe
a
separate
problem
that
needs
to
be
solved
in
a
different
way.
A
A
We
could
say,
rather
than
that's
the
sponsor's
role
we
could
say
that
is
the
assignees
role
someone
gets
assigned.
You
know
every
spec
pr
an
issue
gets
someone
assigned
to
it
and
right
now
that
rule
is
described
as
being
like
fairly
passive.
A
Like
we
don't
we,
we
don't
really
like
put
a
lot
on
that
person,
but
it's
definitely
true
that
the
one
of
the
big
pieces
of
feedback
we
get
is
people
don't
know
what
to
do
when
their
specs
stalls
out
for
reasons
other
than
they're
just
not
responding
themselves,
and
so
part
of
it
could
just
be
that
the
the
assign
the
signee
just
needs
to
just
be
in
charge
of
moving
moving.
A
Those
things
to
conclusion
right
so,
if
they're
starting
to
go
stale
like
their
responsibility,
is
either
to
poke
poke
people
to
respond
or
make
requests
for
changes
or
if
it's,
if
it's
actually
like
divisive,
try
to
make
proposals
to
to
help
summarize
and
guide
it
like
be
more
of
like
an
active
participant,
and
that
could
do
it.
The
the
main
reason
why
the
concept
of
a
sponsor
came
up.
A
There
was
this,
like
you
know,
in
theory,
a
contributor
can
just
like
see
who's
assigned,
or
they
could
look
up
who's
on
the
tc
and
then
they
could
go
to
slack
or
somewhere
and,
like
you
know,
dm
those
people,
but
in
like
practice
like
human
social
conventions
is
people
are,
are
very
shy
about
reaching
out
to
like
a
group
of
people
or
like
even
like
individuals
who
they
they
just
like,
don't
know
personally,
so
the
id
the
main
idea
of
a
sponsor
there
was
just
going
to
people
and
being
like
hey.
A
This
person
is
your
point
of
contact.
If
you
have
like
questions
or
you're
confused
about
stuff
or
things
get
stuck
like
like
you
can
talk
to
this
person
and
like
they
will
help
you,
but
it
could
be
just
we
say
that
the
assignee
is
is
that
person
and
we
tell
people
that
if
they're
not
getting
any
response
on
the
ticket,
they
could
go
to
slack
like
the
spec
channel
slack
and
ping,
the
the
assignee
there.
M
I
still
don't
know
if
that
really
solves
a
problem
of
like
I
created
an
otep,
and
I
got
two
sets
of
conflicting
feedback
on
that
right.
Like
somebody
wants
it
to
do
it
a
somebody
wants
to
do
it
b.
I
don't
know
how
I'm
supposed
to
really
resolve
that,
and
I
don't
know
if
putting
an
assignee
in
there
would
really
help
with
building
that
consensus
that
we
we
want
to
achieve
there
yeah.
L
M
I
I
think
there
might
be
need
for
some
some
other,
like
release
valve
way
of
of
coming
to
consensus
in
this
in
in
situations
like
that.
But
I
mean
I'm
all
for
having
clear
responsibilities
on
like
who
needs
to
build
that
consensus.
And
why
and
like
where.
M
M
One
of
the
things
is
I've
seen
used
in
other
groups
is
when
you
have
something
like
some
kind
of
conflicting
feedback.
You
can
propose
like
a
vote
of
some
sort
like
a
get
get
some
kind
of
you
know,
here's
a
you
know,
here's
two
different
ways
that
we
could
solve
this
and
then
do
do
some
sort
of
a
vote
or
something
like
that
where,
like
for
very
specific
issues,
we're
voting
just
on
this
portion-
I
I
don't
know
how
effective
that
is.
M
H
D
Yeah
I
want
to
comment
on
the
same
topic
and
and
refer
back
to
what
dan
said
is
about
our
capacity
and
to
actually
find
the
bandwidth
for
all
these
things.
So
I
like
what
was
just
proposed
a
vote
sounds
like
a
solution,
but
we
have
seen
this
happen
enough
times
where
you,
you
have
a
small
group
discussion.
D
Maybe
there's
a
vote
in
a
small
group.
You
move
forward.
You
bring
it
to
the
group,
the
community
at
large
and
all
of
a
sudden
people
don't
like
what
you
did,
but
we
didn't
have
a
way
to
get
the
people
that
didn't
like
what
you
did
into
the
group
to
make
the
vote
happen
with
enough
people.
So
I
want
to
bring
this
back
around
to
like.
I
can't
follow
every
vote
in
open
telemetry,
but
the
proposal
I
heard
dan
say
was
really
great
like.
B
Yeah
I
mean
this
is
I
mean
one
example.
This
is
like
rum
recently
right
like
we
had
the
rum
group
like
sit
down
and
decide
on
some
norms
and
then
during
the
spec
calling
ted,
you
brought
up
some
sort
of
broader,
broader
challenges,
with
the
perspective
that
they
had
that's
one
example
right,
there's
there's
probably
hundreds
of
others.
B
So
I
I
I
do
like
this
idea
of
almost
planning
things
like
a
like
a
sprint
like
I
don't
know
how
far
we
want
to
go
with
it,
but
I
it
would
give
us
a
lot
of
focus
and
decrease
instances
of
that.
B
C
That
are
half
completed,
or
we
start
things,
and
now
we
have
more
things
that
are
half
completed
and
rarely
do
we
ever
complete
things
on
a
sprint
call.
We
always
just
end
the
call
with
10
half
open
items
and
we
say
we'll
talk
about
it
async
and
then
we
show
up
at
the
next
call
the
next
week
and
talk
about
it
again
and
it's
just
constantly
happening
if
we
had
like
10
things
that
were
like
we're.
These
are
the
things
we're
working
on
this
month.
C
A
Yeah
yeah,
I
mean
I,
I
definitely
like
how
that
provides
clarity
to
everybody
about
not
only
what
we
are
working
on,
but
also
like
what
we're
not
working
on
like.
If
your
thing
doesn't
get
picked
up
this
month,
then
it
also
means,
like
you,
don't
have
to
worry
about
it
as
a
contributor
to
a
certain
degree.
C
Solves
another
or
doesn't
solve
but
addresses
a
problem
that
comes
up
periodically,
which
is
we're
constantly
being
asked
about
our
roadmap,
both
short
and
long
term,
and
it
lets
us
say
to
people.
This
is
what
we're
working
on
this
month.
This
is
the
planning
document
for
next
month.
If
you,
you
know,
feel
free
to
take
a
look
at
that.
A
Yeah
yeah
this
is
this
is
great
yeah
because
I
think
often
I
mean
sometimes
people
just
want
their
thing
closed
and
done.
A
Maybe
because
it's
like
urgent,
though
like
if
you
have
something
urgent
and
the
solution
is
a
spec
change
like
you're,
just
kind
of
sol,
because
that's
there's
nothing
fast,
that's
gonna
happen
there,
but
I
think
often
what
people
do
want
is
just
clarity
right
like
either
like
it's
getting
solved
now
or
it's
not
getting
solved
now,
but
we
will
solve
it
later
or
the
third
option
which
is
like
this
is
divisive
or
we
don't
like
it
or
it
doesn't
seem
like
we
can
come
to
a
conclusion
or
whatever,
but
we're
not
gonna
work
on
it,
like
that's,
like
a
third
option
that
maybe
this
would
help
us
be
more
aggressive
about.
A
I
know
there's
like
downsides
to
just
telling
someone
we're
not
gonna.
Do
this
and
close
it
like
if
they
need
it
right,
they're
gonna
like
get
frustrated
and
really
come
back,
so
you
know
be
careful
about
that.
But
but
I
do
think
it's
it's
better
than
leaving
those
prs
and
issues
like
open
like
it
would
be
great.
If
the
backlog,
the
open
backlog
consisted
of
like
the
stuff
that
we
are
actively
working
on
and
the
stuff
that
we've
agreed
is
gonna
go
into
that
monthly
sprint.
But
at
some
like
in.
A
Work
represented
work,
that's
either
untriaged
or
work
that
is
going
to
go
into
that
monthly
sprint
reliably
like
we're
committed
to
chewing
through
it.
We
just
don't
know
when
that
would
maybe
give
us
a
handle
for
when
to
go
back
to
things
and
be
like
yeah.
We're
sorry
like
like
it
just
doesn't
seem
like
we're
gonna,
be
able
to
get
to
this
anytime
in
the
near
future,
so
we're
just
gonna
close
it
out
for
now.
C
So
I
think,
before
we
get
too
far
along
in
this
discussion,
we
should
probably
I
would
propose
that
the
tc
take
this
idea
or
feedback
and
talk
about
it
at
the
tc
meeting,
because
we're
about
to
run
into
the
exact
same
issue
where
we
are
a
group
of
people
who
are
not
the
tc
and
the
tc
at
large
may
have
opinions
about
this
and
say
no.
We
don't
like
it.
So
I
think
that
I
think
that
this
is
something
that
the
t
we
should
probably
just
ask
the
tc
to
address
yeah.
C
A
Committed
to
to
championing
it
like
I
will
I've
made
a
pr,
and
I
will
make
more
prs
with
these
ideas,
so
there'll
be
a
place
for
all
that
feedback
to
go
but
yeah.
I
agree
we
don't
we
don't
get
to
pick
the
answer
here.
You
know
yeah,
you
can
be
the
sponsor
yeah.
It
has
to
get
approved
through
the
the
spec
process
so
cool
this
was.
This
was
really
helpful.
A
That
gets
me
unstuck
from
where
my
pr
had
been
sitting.
Does
anyone
have
other
items
alex?
I
see
you
do.
L
Yeah,
I
just
want
to
quickly
touch
on
the
release
process
that
we
started
using
for
the
collector
a
few
releases
ago.
Here.
Let
me
I'll
just
share
my
screen
here.
It's
pretty
it's
pretty
quick,
but
what
we
have
is
we
have
this
release
schedule
and
we've
assigned
release
managers
for
each
releases,
which
has
been
really
great
for
conveying
to
our
users
what
what
to
expect
as
to
when
the
new
releases
will
go
out.
L
A
No
problem
see
people
at
the
spec
meeting
tomorrow.
Yeah,
oh
happy,
pi
day
see
you
later
see.
You
see
you
later.