►
From YouTube: 2020-08-24 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
A
C
Yeah
I
can
speak
to
this.
This
came
from
actually
honorable
that
he
asked
us
to
bring
this
up
to
the
maintainer
community.
He
was
finding
this
open
source
dot
guide,
super
helpful
and
wanted.
C
For
both
you
know,
a
lot
of
us
are
first-time
maintainers
on
at
least
on
something
this
project,
this
big,
and
so
there
were
two
particular
pages
that
I
linked
that
I
called
out
in
the
notes:
they're,
building
welcoming
communities
and
best
practices
for
maintainers-
and
you
know
it's
just.
I
know
john
john
read
through
his
john
on
here.
Yet
hey
john
mentioned
that
he
had
read
some
of
this
and
also
found
it
helpful.
C
I
have
not
read
it
yet,
but
thought,
maybe
that
you
know
we
could
like
for
next
week.
If
everybody
reads
this
and
one
of
these
pages-
and
we
could
have
a
you
know,
10
minute
discussion
on
it,
a
little
maintainer
book
club
cool.
This
is
great.
C
No,
I
don't
think
so.
There
was
nothing.
I
think.
Just
there
were
john,
maybe
you
can
did
you.
What
did
you
find
interesting
here.
E
Yeah,
I
think,
as
a
kind
of
as
a
first-time
maintainer
on
something
of
this
scale.
The
learning
to
say
no
section
in
the
best
practices
for
maintainers
was
very
very
helpful,
gave
a
lot
of
good
strategies.
On
that
I
mean
one
of
the
one
of
our
jobs
is
as
maintainers
saying
no
and
saying
this
is
not
something
we're
going
to
do
or
something
we're
going
to
accept
yeah
having
some
strategies
on
how
to
communicate.
That
is
very,
very
helpful
and
valuable.
C
B
C
Yeah
I'll
pass
along
to
honor,
and
this
is
related
to
honorag,
the
and
morgan.
We
just
wanted
to
make
sure
that
the
new
australia-based
java
dev
at
google
knows
that
honorable
john
and
I
meet
on
thursday
at.
B
C
At
6
00
pm
yeah
it's
on
the
public
calendar.
Oh,
I
see
it
yep,
okay,
great,
so
it
would
be
great
to
okay,
the
new
person
and
give
give
them
a
touch.
Point
of
I
will.
B
B
G
F
G
We
kind
of
like
touched
upon
this
a
little
bit
before
in
a
previous
meeting
cameras,
maintainers
meeting
or
the
spec
sig
meeting,
but
yeah
as
stuff
comes
in
for
changes
to
the
spec
as
we
may
be
putting
stuff
in
deleting
stuff
changing
stuff.
G
I
feel
as
though
maybe
a
good
synchronization
point
would
be
spec
release
that
has
the
change
log
and
that
would
be
the
synchronization
point
so
for
the
language
six
to
be
able
to
implement
so
they
know.
Okay,
what's
coming
in,
what's
coming
out
is:
is
it
should
we
start
implementing
this?
Should
we
start
deleting
the
code?
What
not?
So
what
I
would
like
to
suggest
related
to
this
topic
is
we
work
towards
a
spec
release
and
the
change
dog
lists
the
stuff.
G
H
I
think
that
that's
not
a
bad
idea,
but
waiting
for
a
release
before
trying
to
synchronize
there's
just
too
much
stuff.
I've
been
trying
to
go
through
at
least
once
a
week
and
do
basically
this
exact
thing
for
javascript
and
open
up
issues
that
link
back
to
the
spec
prs
and
I
have
to
say,
like
I,
I
had
already
created
issues
for
all
of
these,
except
for
one
of
them.
I
missed
one.
So
I
have
to
say
this
is
super
helpful
to
me
just
to
have
this
list
here.
B
F
Don't
know
if
we
are
consistent
or
not
yeah,
we
should
be
just
yeah,
maybe
maybe
that's
a
feedback
that
we
need
to
pass
to
everyone
to
make
sure
that
we
we
put
things
into
the
change
log
for
for
others
to
easily
monitor
changes.
Okay,.
F
I
I
was
just
going
to
recommend
the
earlier
documentation
on
how
to
be
a
maintainer.
This
is
exactly
what
paul
did
just
said.
J
I
I
I
can
probably
take
this
and
I
think,
besides
the
guideline
document,
we
probably
should
also
update
the
pr
template
to
remind
people
like
in
the
donut.
We
have
a
checklist
in
the
pr
template
where
we
tell
people
like
you
need
to
update
changelog.
J
That
might
be
an
overkill,
so
initially
we
were
trying
to
brainstorm
this
in
the
donatry
pond.
A
lot
of
people
realize
this
like
they're,
just
doing
like
a
style.
Change
in
detention,
like
like,
add
some
like
ci
pipeline,
which
is
not
affecting
the
customer.
So
we
decided
to
only
put
things
that
the
customer
should
care
about
like
if,
if
something
like,
only
as
maintainers,
we
would
care.
We
shouldn't
put
that
in
the
changelog.
H
G
All
right,
this
is
just
a
quick
rundown
of
what
I'll
I'll
dive
in
deeper
on
the
specific
meeting
tomorrow.
But
from
last
week
we
have
based
on
this
status
of
the
ga
spec
burn
down
project.
G
Some
changes
in
the
to
do.
We've
knocked
down
seven
items
in
progress.
We
had
like
11
items
in
progress
we're
down,
for
this
is
net
right.
So
it's
like
stuff
comes
in
stuff
comes
out,
yeah
yeah
done;
we've
increased
it
by
20,
so
this
movement
on
the
in
the
done
column
and
more
specifically,
for
what
we're
trying
to
shoot
for
the
first
week
of
september
and
seven
business
days
by
the
way
yeah
we
have
five
to
do
items
for
party
one
spec
trace
label,
yeah.
F
G
Are
all
issues
issue
issues.
G
I
believe
this
one,
which
I
saw
some
movement
on,
but
I
think
we
will
dive
in
to
deep
on
this
on
the
specs
sick
meeting
on
the
significance
of
this.
But
this
one
is,
I
think,
identified
as
one
as
the
the
most
the
biggest
most
contentious
one
we
want
to
get
in
in
order
to
be
able
to
hit
the
deadline.
So
that's
my
update
for
those
people
have
any
questions.
G
If
not,
I
did
want
to
at
least
touch
up
on
timelines
or
expectations
for
the
next
spec
release.
G
Go
ahead
like
this,
our
game
plan,
for
that,
whether
we
are
trying
to
shoot
for
that
next
week
or
whether.
G
Yes,
once
we
get
the
p
ones
done
for
spec
trace,
what
are
we
calling?
Are
we
calling
an
rc
yeah.
B
The
release
candidate
of
the
tracing
spec
and
and
there
may
be
additional
release
candidates
later,
but
that's
that's
what
this
is
right.
This
is,
we've
got
all
the
p1's
done,
and
the
sdk
groups
and
collector
groups-
and
everyone
else
is
dependent
on
this-
should
take
this
as
a
signal
to
build
this
in
and
start
creating
their
own
tracing
rc
releases.
G
So
then,
there's
some,
I
think,
auxiliary
or
related
action
items
to
go
along
with
that.
You
know
update
of
maturity,
matrix
and
such
and
such
and
then
a
target
for
implementation.
G
B
That's
a
good
question.
I
I
would
suggest
that
we
do
p1's
for
the
other
sort
of
let's
put
metrics
aside
for
a
second,
because
it's
a
different
signal,
but
for
the
spec
areas
that
are
related
to
trace,
whether
that's
correlations
or
metadata
or
others,
and
get
those
done.
So
we
can
have
a
complete
tracing
release.
F
Yeah,
that's
that's
for
sure,
but
what
about
p2s
for
three.
B
So
that's
yeah,
that's
what
I
was
going
to
ask
the
room.
I
I
I
don't
know
how
we
we
stack
up
trace
p2s
with
p1's
for
for
the
other
non-metrics
apis,
I'm
curious
what
people
think.
G
We
could
use
the
same
strategy
of
the
next
label
that
we
choose.
P1
is
like
api
breaking
yeah
changes
that
way
at
least
those
get
in
sooner
or
faster
right,
in
order
to
make
sure
that
that
is
helpful
for
solidify
things
for
ga
and
have
p2.
Just
in
the
background,
although
I
understand
like
the
awesome
thing
I
saw
about
this
exercise
or
this
past
few
weeks,
like
everyone
like
concentrated,
like
crazy
on
people,.
G
That
was
like
fantastic,
and
but
if
we
were
to
concentrate
on
some
things
like
api
breaking
stuff
is
like
the
most
important
thing,
yeah
that
I
think
we
ought
to
be
shooting
for
so.
B
L
Anyway,
sorry
go
ahead.
Yeah
you
go
first,
okay,
one
one
thing
that
we
need
to
do:
maybe.
F
M
M
Yeah
and
my
question
was
going
to
be
like
we
know,
I
know
that
we
are
focusing
on
p1
items
for
tracing,
but
sometimes
I
feel
like
context,
not
correlation
context
or
baggage,
but
context
issues
are
also
important,
maybe
not
all
of
them,
but
a
few,
because,
for
example,
this
one
that
I
was
working
on
last
week,
the
adding
get
our
keys
operation.
M
You
know
it's
context,
but
it
affects
the
support
for
for
checker.
You
know
so
you
know
is
tracing,
so
it's
important
so
yeah.
So
I
don't
know
how
you
guys
want
to
consider
how
important
tracing
is
sorry,
how
context
important
is
related
to
tracing.
B
I
I
think
it's
incredibly
important
so
like
so.
What
we're
saying
is,
is
the
you
know.
As
soon
as
we
finish
up
the
tracing
p1,
then
we
go
to
the
context,
p1,
the
correlation,
p1s
and
all
those
related
apis
right.
The
tracing
p2s
are
not
as
not
as
important
as
the
p1's
over
in
context
and
and
those
other
apis.
G
So
back
to
this
point
of
scrubbing
the
p2
issues
of
spec
trace
to
make
sure
that
they're
really
not
a
p1,
is
I
mean
the
timing
of
that?
B
G
Oh,
I
I'll
be
looking
for
a
new
time
in
order
to
be
able
to
suit
that's
fine
everybody.
I
think
I
was
overlapping
with
the
javasig
and
taking
some
of
their
time.
So,
okay
I'll
work
that
out
in
the
getter,
you
can
move
it.
I
think
you
have
access
to
my
calendar
at
least
for
me:
you've
accessed
my
calendar,
so
you
can.
I
do.
E
E
All
the
maintainers
should
take
the
opportunity
to
fill
in
the
the
matrix
that
t-group
put
together.
It's
important
to
get
all
that
documented,
easier.
F
A
I
Can
you
give
a
little
bit
more
concrete
examples
on
that?
Like
I
I've
I've
got
a
seeking
suspicion.
Do
you
have
some
prs
in
mind?
You
mean
like
you,
need
some
help.
People.
I
Or
do
you
have
something
particular
that
you're
talking
about
like
they
need
more
eyes
I
mean
for
for
for
reference.
We
have
150.
I
K
K
Just
a
quick
question
guys:
have
you
ever
considered
that
we
could
move
from
guitar
to
slack
really
because
the
guitar
is
really
really
bad?
We
have
several.
F
Yes,
it
is,
it
is,
it
is
an
action
item
and
ben
promised
that
will
help
us
once
we
do
the
release
for
for
trace.
D
Yeah
you
can
get
spec
tracing
to
release.
Our
reward
is
escaping.
C
L
B
D
B
We'll
scrub
the
trace
p2s
in
the
meeting
on
friday
and
then
by
next
week,
if
all
things
go
well,
we'll
have
a
release
candidate
for
trace
and
we'll
shift
our
focus
to
the
p1
issues
on
the
other
apis.
So
thank
you
very
much
see
you
later.