►
From YouTube: 2021-05-10 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
Hey:
hey
yeah,
exciting
news:
they
just
dropped
the
bomb
on
us,
so
we're
all
kind
of
reeling
over
here
a
little
bit
something
yeah
in
case.
Other
people
didn't
hear
a
light
step
is
in
the
process
of
being
acquired
by
servicenow
I'll
admit
when
I
heard
that
my
first
question
was
who
the
heck
is
servicenow.
B
Yeah,
presumably
then
I
looked
at
their
stock
ticker
and
I
was
like
okay,
so
here
we
go.
C
B
B
If
we
were
to
get
acquired
so
yeah,
it
does
seem
like
some
good
synergy
happening
there
at
some
point,
I'll
figure
out
what
exactly
they
do.
Like
most
companies
that
sell
to
big
enterprises,
their
website
is
basically
useless
as
far
as
figuring
out
precisely
what
their
technology
does.
B
B
A
E
Sure
why
not
so
thanks
so
much
for
joining
us,
usually
yeah.
First
of
all,
six
checkup
specification.
We
did
release
1.3
last
week,
thanks
to
armin
yeah.
He
has
a
few
interesting
changes.
Nothing
breaking!
I
think
one
important
thing
that
probably
we
should
discuss
tomorrow,
but
it's
just
something
for
you
guys
to
think
about.
Is
we
have
this
upcoming
change
that
nikita
proposed
for
selling
status
and
we
have
prototype.
We
have
a
prototype
for
daddy.net
in
java.
E
It's
probably
straightforward,
I'm
wondering
if
we
need
a
prototype
in
python
or
some
other
language.
What's
the
overall
feeling
of
that,
we
will
discuss
that
tomorrow.
So
please
consider
going
to
the
pr
I
forgot
to
link
it,
but
you
know
which
one
it
is
yeah,
sorry
daniel
for
not
putting.
I
will
put
it
now.
So
that's
from
the
specification
parts.
The
next
item
are
metrics.
I
don't
know
whether
somebody
from
the
matrix
teams
around.
F
Yeah,
so
the
matrix
data
model-
I
believe,
is
it's
almost
there
and
and
folks
just
released
the
0.9
version
of
the
protocol
last
week
and
for
the
api
spec
we've
decided
to
move
the
new
api
to
the
api
dot
markdown
file.
So
that's
the
latest
version
you
can
see.
The
old
api
document
has
been
removed
and
there
are
a
couple
minor
things
we
want
to
improve,
but
the
api
is
almost
there
and
now
the
the
sig
is
working
on
the
sdk
spec.
F
We
just
had
the
initial
skeleton
of
the
document
for
for
comments,
and
now
there
are
two
languages
doing
the
prototype.
I
guess
go
like,
as
as
j
macd
mentioned,
he
probably
want
to
do
the
gold
prototype
that
makes
us
like
three
languages,
doing
the
prototype
of
the
sdk,
so
we're
on
a
tight
schedule,
but
so
far
it
seems
we're
we're
on
schedule.
B
Do
you
mind
muting,
you
guys,
sorry,
no.
F
C
Yeah
so
for
go,
we
have
an
existing
prototype
based
on
some
of
the
prior
design
work,
and
what
josh
wants
to
do
is
prove
that
we
can
adapt
that
and
translate
it
into
the
current
design
without
too
much
change
for
users
who
may
have
been
using
it
before,
but
as
riley
said
he's
not
yet
committed
to
that.
I
don't
think
yeah.
F
Ideally,
if
you
could
get
one
from
python
or
javascript,
it
would
be
great
for
javascript.
My
understanding
is
that
the
sig
is
currently
ready
for
the
stable
release,
so
they
probably
won't
have
time,
or
at
least
that
that
would
not
help
them
to
keep
focus.
So
I
want
to
ask
explicitly:
would
that
be
possible
to
have
python
or
another
language
like
ruby,.
B
Maybe
when
we
go
through
the
rest
of
the
updates,
reps
from
those
languages
can
give
an
estimate
for
when
or
if
they
think,
they'd
be
able
to
participate
in
a
prototype
and
like
if
they'd
like
to
or
if
that
sounds.
Like
really
painful.
F
E
F
A
E
D
E
Sweet
thanks
so
much
thank
you
for
the
for
the
effort
on
the
status
update
change,
okay,
javascript.
G
Yeah
we're
not
much
has
changed
from
last
week,
we're
just
working
on
removing
the
suppress
instrumentation
from
the
api
in
a
way
that
won't
break
users
that
are
currently
using
it.
So
adding
a
new
api
extensions
package,
like
we
talked
about
last
week
beyond
that,
we're
almost
done
with
the
changes
from
the
spec
review
that
you.
B
E
Thank
you
for
that
bye
tune.
H
Yeah
we're
planning
on
the
1.2
release
this
week
and
just
small
changes
in
book
fixes.
H
Yeah
also
to
address
the
the
metrics
prototype
ask
can,
can
it
be
clarified
what
the
expectations
are
for
this?
Whoever
was
running
this
sorry.
F
Yeah
so
so,
currently
we're
like.
We
have
the
matrix
api
spike,
which
we
we
have
a
good
level
of
confidence
for
the
isdk.
The
the
real
thing
when
you
write
the
isdk
spike,
is
you
have
to
prototype
and
prove
things
work
end-to-end.
So
currently
we
only
have
two
strong
languages
and
what
we're
looking
for
is
some
something
different
than
the
python,
but
not
something
different
than
c
sharp
and
and
java.
So
we
wonder
if
python
or
javascript
or
ruby
or
something
similar
could
help
to
join
the
prototype
work
on
the
isdk.
F
Well,
I
heard
javascript
is
busy
with
the
upcoming
stable
release.
So
I
wonder
if
python
or
ruby
can
commit
sometime
in
may
just
to
do
the
sdk
end-to-end
prototype,
so
the
focus
would
be
using
the
old
tab
146
covering
the
scenarios
and
use
the
api
as
currently
showing
on
the
experimental
spec
and
then
based
on
the
discussion
in
the
metrics
group.
Do
the
isdk
prototype
before
we
start
to
hammer
out
the
spec.
H
I
see
okay,
let
us
go
back
to
the
python
community
to
see
if
anyone
wants
to
are
interested
in
taking
up
this
work.
I
can't
say
currently
the
status
of
that
right
now.
B
F
You
follow
the
scenario
and
as
long
as
you
can
describe
that
in
the
spike
focus
reveal
that
should
be
okay,
but
for
the
isdk
I
think
we
got
to
do
some
real
implementation
and
measure
the
performance
and
see
if
the
end-to-end
scenario,
for
example,
we
have
scenario
where
we
allow
people
to
use,
pull
and
push
model
at
the
same
time,
and
we
also
allow
push
at
different
frequencies
like
one
exposure
can
be
every
five
seconds.
Another
can
be
every
one
minute
and
we
allow
push
and
pull
to
mix
and
match.
F
So
this
requires
some
end-to-end
prototype,
but
it
doesn't
mean
the
prototype
will
be
given
to
the
external
like
folks
to
consume,
so
we're
not
shooting
for
any
alpha
beta
or
release
like
that.
It's
just
write
something
in
that
particular
language
and
verify
the
the
endpoint
flow
plus
performance,
understood.
Okay,
thanks.
E
Okay,
thanks
yeah,
perfect
yeah.
Let's
come
let's
try
to
keep
that
in
mind.
I
don't
know
it
could
be
a
perfect
scenario
to
protect
this
in
python,
but
let's
see
yeah,
let's
play
dodge
for
that.
F
I
think
seizure
is
saying
he's
waiting
for
a
car,
so
it's
okay,
so
I'll
do
that?
There's
no
much
update
inside
folks
waiting
for
the
next
upcoming
release
and
I
I
think
the
goal
is
by
end
of
this
month.
They're
going
to
do
the
beta
3
and
one
important
thing
we
added
is
the
better
support
for
correlation
with
I
logger
the
internet.
I
logger
has
some
like
specific
thing,
called
log
scope
and
that's
the
biggest
change.
F
There
are
other
instrumentation
library
changes,
but
those
are
still
in
the
in
the
pre-release
version
because
we
have
a
dependency
on
the
semantic
convention.
That's
all.
I
Yeah
so
still
working
towards
rc
we're
down
to
three
issues:
to
do
five
in
progress
and
283
done,
yeah
just
keep
going
on
the
of
course.
The
remaining
issues
are
the
hard
ones.
So
hopefully
the
momentum
pulls
us
through
this.
So
I'll
say.
J
Yeah
so
in
plus
place
I
mean
this
week
earlier
this
week,
we'll
be
having
with
zero
sector
alpha
release
and
we
are
gearing
up
for
beta
release,
steady
progress,
we'll
be
doing
1.2
release
candidate
most
probably
end
of
this
month.
J
B
No,
I
was
saying
that's
awesome.
I
did.
I
did
have
a
question,
but
maybe
I'll
take
it
to
the
c
plus
plus
sig.
It's
just
relating
riley
had
mentioned.
There
had
been
a
an
early
on
design
requirement
around
sdks
being
required
to
be
dynamically
loaded,
and
that
was
maybe
like
a
design
constraint
that
was
being
kind
of
painful
on
c
plus
plus.
So
I
wanted
to
check
in
about
whether
that
was
painful.
J
I
can
briefly
talk
about
that.
I
mean
because
that
all
things
started
before.
Ideally,
joint
is
sick,
but
I
know
that
we
didn't
have
plan
for
dynamic
loading.
We
did
have
some
code
ways
in
sdk
in
place,
but
we
didn't
really
work
more
on
that
I
mean
so
as
of
course
that
is
not
part
of
implementation.
B
E
Feel
that
you
need
a
new
review
from
let
us
know
we
can
probably
go
through
the
receive
and
check
if
there's
any
compatibility
or
something
like
that.
Let
us
know
yes,.
J
K
Yeah,
we
are
we're
kind
of
at
the
point
where
we
are
on
the
verge
of
releasing
our
first
rcc
kind
of
at
the
last
sig
meeting
last
week.
We
ran
out
of
issues
to
add,
but
we
wanted
to
give
folks
a
week
to
make
sure
that
we've
addressed
everything.
Another
thing
that
we
were
talking
about
was
considering
talking
to
the
tc
about
a
about
getting
a
review.
We
weren't
totally
sure
we
were
going
to
go
that
direction.
K
I
have
not
checked
with
my
co-maintainer
to
see
what
he
was
thinking
there,
but
we
were
at
least
entertaining
the
idea
and
we'll
probably
make
a
decision
at
tomorrow's
meeting,
so
things
are
looking
in
good
shape
there
in
terms
of
riley's
request
to
do
some
prototyping
around
metrics
sdk.
I
will
bring
that
back
to
the
sig.
I
think
there
there
might
be
some
people
interested
in
that
it's
a
matter
of
whether
or
not
they
have
the
time
to
devote
to
it,
but
I
will
I
will
bring
that
back
to
the
group.
E
L
Hey
yeah
so
we're
working
towards
a
1.0
beta.
I
think
the
only
thing
that
we're
waiting
on
is
a
blog
post
from
nacho,
which
I've
been
asked
to
proofread.
So
once
that
is
ready,
I
think
we're
ready
to
go
and
we'll
send
that
to
ted
or
whoever
to
get
posted
on
the
open,
telemetry
website.
L
E
Nice
nice
indeed,
thank
you
collector,
so
you
wanted
to
say
something:
no,
okay,
collector.
I
don't
know
whether
I
think
splunk
people
are
off
today.
M
Yeah
I
mean
I
can
give
an
update
on
the
collector
since
I've
been
working
closely
with
bogdan
and
tigran
on
this,
so
we
have
been
starting
to
triage.
You
know
the
outstanding
issues
on
the
collector
and
collector
contrib
and
we
are
still
a
bit
behind
on
the
1.0
backlog.
M
M
So
at
this
point
again
I
will
circle
back
and
let
you
guys
know
what
the
status
of
the
collector
is
and-
and
you
know
if
we
can
actually
prune
some
of
the
items
from
the
1.0
list,
to
be
able
to
get
to
one
daughter
sooner
than
later,
as
our
target
is
there,
you
know,
there's
a
phase,
two
backlog
and
a
phase
one
backlog
right
now.
If
you
have
seen
looked
at
it
and
the
phase
two
has
some
items
that
could
possibly
be
done
after
one
daughter.
E
E
I
think
tristan
is
not
around
so
we'll
skip
it
for,
for
today,
okay,
we
can
go
to
the
the
rest
of
the
items.
First,
one
protocol
generation
discussion
on
updates.
Please.
A
Sure,
that's
that's
my
topic.
So
while
I
was
while
we
were
discussing
in
our
sig
meeting
some
of
the
protobuf
generation
and
distribution,
we
talked
about
having
them
vendored
within
our
repo.
We
talked
about
having
them
automatically
generated
all
the
time
so
and
so
forth,
and
so
one
thing
that
we
came
up
with
in
our
sig
and
I
thought
I'd
make
the
larger
group
to
get
validation
or
say
no.
No,
no
is.
E
Yeah,
okay:
we
can
move
to
the
next
one
and
wait
for
bob
to
to
come
back
three
two
one.
We
will
be
going
back
to
that.
Hopefully,
okay,
next
item
price,
trace,
propagation
timing,
disparities.
L
Sorry
I
was
looking
at
my
web
browser
trying
to
give
you
an
example
so,
with
the
mobile,
the
mobile
swift
sdk
that
we're
working
on
I've
noticed
a
really
big
disparity
between,
like
the
the
timing
of
spans
on
the
device
itself
versus
the
back
end
things.
I
don't
know
if
this
is
this,
is
I
couldn't
find
any
tickets
on
this
or
any
documentation,
I'm
probably
just
bad
at
looking.
But
I
was
wondering
if
this
was
something
that
was
documented
or
if
there
were
any
solutions
for.
B
It
I
believe,
you're
looking
at
clock,
sku
yeah,
which
is
very
common
with
mobile
clients.
I
don't
believe
lights
or
light
stuff
open
telemetry
does
not
have
any
kind
of
clock
correction
protocol
built
in
I.
B
My
prior
experiences
with
with
clock
correction
protocols,
is
that
they're
they're
flaky
and
can
be
a
pain
in
the
ass.
If
you
for
these
kinds
of
scenarios,
specifically
where
you
don't
have
control
over
all
of
the
devices,
so
you
can't
you
can't
sync
the
way
you
normally
do
with
all
your
servers.
B
B
L
Okay,
yeah,
I
was,
I
was
wondering
if
they
we
had
some
sort
of
like
what
would
the
word
be
like
a
just
offset
timing
on
on
maybe
a
mobile
device.
I
don't,
I
don't
know
like
and
then
like
pinning
whatever
to
to
the
server
so
that
there's
at
least
one
source
of
truth.
That's
the
problem
right.
I
always
like
the
the
phrase
like
a
man
with
a
watch
knows
what
time
of
it
time
it
is,
and
a
man
with
two
is
never
quite
sure.
B
Yeah
I
mean
so
you
can
make
a
presumption
that
you
know
the
the
start.
Time
of
the
server
span
is
is
slightly
after
the
start.
Time
of
the
client
span.
I'd
be
curious.
If
people
want
to
are
familiar
with
various
clock
correction-
algorithms
that
maybe
they've
implemented
in
the
past
and
have
suggestions
for
ones
we
can
use,
I
can
recommend
one.
I've
tried
in
the
past,
but
yeah
it's
it's.
L
Yeah
well,
and
it's
not
just
like
it
might,
you
know
the
clocks
might
be
off
by
a
few
milliseconds,
like
some
people,
I
don't
know
like
play,
candy
crush
and
try
to
hack
the
thing
by
changing
their
clock
time,
so
it
might
be
like
a
million
years
in
the
past
or
who
knows
you
know,
I
don't
know
it's
kind
of
like
a
unsafe
thing.
So
should
I
open
a
ticket
somewhere
just
to
get
a
conversation
on
this
and
maybe
get
some
ideas?
I
don't
know
yeah.
B
Yeah
I
mean,
I
think
this
would
be.
I
guess
a
spec
issue,
or
maybe
like
an
otep
issue,
would
be
maybe
the
place
to
put
it
since
this
would
definitely
be
otep
territory.
Yeah.
G
L
G
G
So
we
we
experimented
with
a
hybrid
approach
where
we
used
the
the
system,
clock
and
the
monotonic
clock
to
try
to
you
know,
guess
when
we
had
been
paused,
which
turned
out
to
just
be
flaky
and
was
a
bad
idea,
so
we
didn't
do
that.
L
B
Yeah,
at
the
end
of
the
day,
we're
always
going
to
want
to
report
the
actual
time,
but
adding
like
an
an
offset
or
or
some
other
additional
field,
definitely
could
be
a
thing
that
that
we
look
at.
E
Cool
yeah
yeah.
I
suggest
that
we
open
a
ticket
for
sure.
I
think
this
is
something
based
on
what
other
people
have
said.
Now
it's
a
problem.
So,
let's
not
forget
about
that.
Yeah.
E
Thank
you,
okay,
bob
is
back
so
bob.
Maybe
you
can
take
your
time
again.
A
Sorry
y'all,
I
just
must
have
been
something
goofy,
so
we
were
in
our
state
in
the
php's
big.
We
were
talking
about
proto
protobuf
generation
and
we're
planning
on
storing
our
the
generated
protobufs
in
our
repo,
because
that's
just
like
a
standard
php
practice,
I'm
from
what
I
thought
it
seems
like
others
are
doing
that
too,
and
I
was
thinking
when
we
have
the
the
pro
the
protobuf
definition
gets
when
the
protobuf
definition
gets
update.
A
It
would
be
really
slick
if
we
had
a
github
action
that
opened
a
pr
for
each
respective
language,
so
that
we
could
make
sure
that
we
have
up-to-date
protobufs
but
not
auto
merging,
so
that
maintainers
could
have
the
ability
to
look
into
the
new
definitions.
Ask
questions
understand.
I
don't
know
if
anybody
else
had
thought
about
this
already
or
if
this
is
something
on
somebody's
radar.
I
Yeah
so
in
go,
we
actually
store
the
protobuf
definitions
in
their
own
repository
because
there's
a
registration
error
if
you
try
to
register
a
part,
above
definition,
that's
the
same
so
like
if
you
generate
the
otp
in
multiple
different
repositories,
you
can't
actually
like
a
client,
can't
register
it
and
say
the
otp
exporter
can't
register
it.
So
we
wanted
to
provide
like
a
centralized
place
to
do
this.
I
Additionally,
like
the
collector
and
the
otr
and
the
go
sdk
both
depend
on
this
protobuf
definition,
so
kind
of
a
good
idea
to
to
build
a
centralized
location
for
it
and
yeah
we've.
It's
unfortunately,
kind
of
a
secondary
project
right
now,
but
I
saw
mike
goldsmith,
is
also
interested.
I
I
think
he
just
got
added
as
a
maintainer
of
that
particular
project,
to
add
something
exactly
like
along
the
lines
of
what
you're
talking
about
and
just
some
sort
of
auto
completion
pipeline,
given
the
fact
that
it
is
kind
of
like
a
secondary
thing,
so
it
seems
like
something
relevant
to
maybe
some
other
cigs.
Once
that
gets
done,
I
can.
I
can
keep
you
informed.
A
E
B
Yeah,
so
this
relates
to
all
the
different
roles
in
open
telemetry
we've
had
a
lot
of
people
contributing
for
some
time,
and
one
thing
we've
wondered
about
in
the
past
is
whether
it
would
be
helpful
to
kind
of
have
like
a
sort
of
synchronized
review
of
the
roles
to
to
look
at
graduating
people
up.
You
know
to
a
higher
level
of
involvement.
B
You
know.
Maintainers,
of
course,
can
do
this
on
their
own
at
any
time,
but
sometimes
with
it's
helpful
to
have
an
external
trigger.
So
that's
the
thing
I
wanted
to
to
pose
to
the
maintainer
group,
one
just
as
a
request,
if
you
haven't
thought
about
looking
over
the
current
contributor
roles
in
your
project
and
seeing
if
there
are
people
who
who
could
take
on
the
an
approver
or
maintain
a
role
generally
getting
more
people
with
access
to
that,
can
provide
a
higher
velocity
and
two.
B
Is
it
something
that
maintainers
feel
like
you
know
doing
it
in
a
maybe
in
a
synchronized
fashion,
like
once
a
quarter,
for
example?
Would
that
be?
Would
that
be
helpful?
So
I'm
just
curious
what
maintainers
think
about
that
or
how?
What
maintainers
think
about
graduating
contributors
in.
I
General,
I
I
like
the
idea,
mostly
just
because
I
need
more
approvers.
You
know
any
any
way
that
gets
me
that
is
really
ideal.
I've
asked
a
few
people
at
this
point
and
a
lot
of
them
have
a
hard
time
committing
to
the
long-term
commitment
of
the
project.
That
was
the
is
the
thing
that
is
getting
in
the
way
currently
for
me,
but
if
we
can
solve
that
in
some
way.
M
I
mean,
I
can
say
ted
that
you
know
josh
sureth
and
I
have
been
carrying
a
favorite
and
we've
been
working
on
a
proposal
to
at
least
you
know
suggest
some
of
the
some
of
the
things
you
know
to
be
able
to
graduate
groupers
and
and
diversify,
especially
on
the
contrib
components.
M
So
we
will
be
submitting
a
proposal
just
a
short
one,
but
nonetheless,
just
to
you
know
again
have
a
tangible
area
to
discuss
on
and
then
see
how
the
different
maintainers
can
accommodate-
and
this
goes
back
to
you
know
the
discussions
that
we've
had
at
large,
where
it
really
is.
How
do
we
not
get
you
know,
people
contributing?
M
How
do
we
and
at
the
same
time
support
our
maintainers
to
be
able
to
maintain
focus
on
on
the
areas
that
they
want
to
work
on
and
also,
at
the
same
time,
increase
the
pipeline
for
getting
more
people?
You
know
to
become
approvers
and
and
triagers
and
and
graduate
further
yeah.
It
is
a
concern
because
there
are
so
many
third-party
components
and
we
just
are
not
being
able
to
keep
up
basic
reviews.
B
Yeah,
so
so
for
clarity
on
that
front,
there's
a
proposal
coming
around
saying:
hey
for
contrib,
you
know:
can
we
look
at
a
way
to
split
contrib
up
so
that
we
can
have
more
ownership
of
individual
parts
that
contrib,
which
is
a
little
bit
difficult
with
like
code
owners,
and
all
of
that
you
know.
A
B
So
so
that
would
be
a
proposal
around
that,
but
then
also
for
the
the
core
repos,
you
know
the
more
people
we
can
have
paying
attention
to
those
who
are
responsible,
the
better.
I
do
wonder
if,
as
long
as
there's
kind
of
like
a
stable
base
of
people
is
it
of
interest
for
for
people
who'd
be
willing
to
do
the
perform
some
of
those
roles
for
a
time,
but
not
forever.
B
Would
it
make
sense
to
to
give
those
people
approver
access
for
the
time
that
they
can
do
it?
In
other
words,
you
know
maybe
not
making
long-term
commitment
a
requirement.
D
D
C
Yeah,
I
think,
for
the
improver
role.
Absolutely
there
doesn't
need
to
be
a
long-term
commitment.
I
know
in
go,
we've
had
approvers
to
come
and
go.
You
know,
and
some
have
returned
later
on
when
they've
had
more
time
to
be
able
to
contribute,
I
think
for
maintainer
positions.
There
should
be
a
bit
more
of
an
expectation
that
you
are
in
it
for
the
long
term,
you're
thinking
about
the
long-term
health
of
the
the
project
and
your
your
group,
but
for
approvers.
B
Great
so
maybe.
D
D
B
Yeah,
so
maybe
two
action
items
are
one
send
a
shout
out
within
your
own
place
of
work
that
we're
looking
for
more
contributors
and
approvers
and
two,
since
some
people
are
shy,
they're
not
necessarily
going
to
raise
their
own
hand
and
say
I
would
like
one
of
these
roles
just
doing
a
a
review
of
of
latest
contributions
and
see
if
you
can
identify
people
who
have
been
contributing
regularly,
who
it
might
be
worth
while
to
reach
out
to
around
approval
worlds.
J
J
Yeah,
just
just
want
to
talk
about
cps
place
area,
because
I
think
we
are
a
bit
more
challenging.
It's
not
just
getting
enough
code,
reviewers,
approvers
or
the
maintainers
would
it
need.
We
need
people
from
diverse
companies,
I
mean
right
now.
We
don't
want
to
be
a
scenario
where
most
of
our
approvers
are
280
percent
of
from
a
single
company.
So
we
have
a
bigger
challenge
where
we
need
people
from
other
companies,
that's
something
even
both
for
attributes
and
the
maintainers.
I
mean
that
that's
the
challenge
we're
facing.
J
Challenging
foreign,
we
need
people
working
for
long
term
as
an
approver,
doing
good
part
of
being
there
as
a
prover
and
doing
this
part
of
the
design
discussion,
then
only
we
can
pull
it
as
a
maintainer.
That's
a
challenge.
We
have
in
c
plus
plus
right
now.
M
Yeah,
I
mean
that's
a
challenge
in
general
on
the
project
right
I
mean
the
collector
also
has
the
same
issue
and
other
some
of
the
other.
You
know,
language
implementations
also
have
the
same
issue,
so
I
agree
with
you
and
you
know
again:
we
need
to
be
a
bit
more.
Perhaps
you
know
looking
at
encouraging
reviews,
as
well
as
as
much
as
we
encourage
prs.
M
So
maybe
you
know
kind
of
making
that
a
bit
more
obvious
would
help.
B
Yeah
we
could
do
a
shout
out
on
the
website
blog
places
like
that.
Potentially
I
don't
know
totally
how
helpful
that
is.
But
but
if
that's
interesting
to
people,
maybe
we
could
draft
a
blog
post
describing
just
reminding
people
the
way
they
can
get
involved
in
the
project,
and
we
could
maybe
do
some
specific
shout
outs
there
around
some
particular
cigs.
B
So
food
for
thought,
yeah.
If,
if
people
do
feel
like
by
the
way
that
their
sig
is,
is
lopsided
or
is
really
in
need
of,
like
a
particular
role
being
filled,
maybe
chime
in
on
the
maintainers
slack
channel.
Just
so
that
the
the
gc
and
other
groups
can
be
aware
of
that.
D
E
Perfect,
thank
you.
When
did
you
want
to
add
something
else.
B
I
feel
like
that's
it
just
yeah
if
maintainers
could
just
like
review
their
current
situation
regarding
contributors
reach
out
to
people,
if
they
see
people
worth
reaching
out
to
if
they
feel
like
they
have
a
hole
and
no
one
to
potentially
ask
to
fill
it
right
now.
Just
chime
in
on
the
maintainer
slack
channel
and
mention
that
and
we'll
try
to
like
bundle
that
up
into
a
blog
post.
M
Okay
and-
and
I
just
wanted
to
do
a
caller-
just
a
reminder
for
everyone-
again-
we
have
a
whole
slew
of
interns
who
will
be
joining
us
for
the
summer.
You
know
starting
next
week
so
again,
if
you
have
high
priority
projects
that
you
need
any
help
on
which
you
know
again,
good
intern
engineers
can
kind
of
go
after
and
help
you
with
please
reach
out
to.
E
E
Sounds
good
great,
perfect!
Okay!
Yes,
let's
do
that
blog
post.
That
sounds
like
whatever
works
is
good
to
go.