►
From YouTube: 2020-08-03 Spec SIG
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
D
E
F
A
F
F
D
G
F
Hurry
sorry
to
hear
you
sick,
your
champ
or
even
showing
up.
Well,
let's
kick
it
off
nikita.
This
looks
like
you're
already
generating
feedback
here
and
I
would
plus
100
this.
A
A
A
week
ago.
One
pull
request
was
merged
today
week
later,
second
is
still
unmerged
and
that's
exactly
how
to
move
pull
requests
forward.
It's
still
unmerged.
It
has
generated
74
comments,
two
approvals
and
still
unmerged,
so
we
have
agreed.
We
have.
We
want
to
do
this
and
it
still
took
us
a
week
to
merge
one
pull
request
and
we
still
haven't
merged
another
pull
request
of
what
velocity
we
can.
We
can
speak.
H
Star
one
of
the
points
for
a
star
is
that,
like,
for
example,
julie
commented
in
one
of
the
pr's,
he
couldn't
make
it
to
the
maintainers
meeting.
So
what
do
we
do?
We
came
to
an
agreement
here
and
that's
good,
but
what,
if
somebody
who
was
not
here
in
the
meeting
he
disagrees,
we
cannot
control
that.
H
A
Okay,
but
both
pull
requests
requested
attention
from
approvers
and
from
tech
committee
several
times
and
it
they
didn't
get
that
that
attention
so
either.
A
F
State,
so
it's
not,
it
seems
like
there's
two
ways:
things
can
get
jammed
up
the
person
making
the
pr
stops
responding.
People
are
like
this
is
almost
good.
Could
you
tweak
these
couple
things
and
then
they
don't
so
stand
up
that
way
and
the
other
way
that
I
think
is
much
more
common
is
what
you're
saying
is
people
make
a
pr?
F
Maybe
they
get
some
comments,
but
getting
enough
approvals
plus
resolving
all
of
the
comments
is
difficult
right
like
it's.
It's
it's
just
just
difficult
to
get
enough
eyes
consistent
eyes
from
approvers,
either
to.
A
H
That
well
there's
one
reason-
and
this
is
something
interesting
is
that
usually
we
have
tried
in
the
past
is
that
even
if
there
are
no
approvals,
but
somebody
requested
a
change
even
if
it
was
not
explicit.
We
are
waiting
usually
for
that
for
the
author
to
actually
work
on
that.
So
the
question
is
here:
just
imagine
we
have
upr,
there's
already
three
approvals
and
then
somebody
says,
like
me
or
ted,
said
okay,
but
I
still
don't
think
we
should
apply
this
and
that.
H
A
Well,
in
this
case,
it
it
most
probably
the
pr
author
should
somehow
respond
to
that
request.
Yes,
so
that
wasn't
the
case
in
this
case
in
this
particular
case
and
again
currently,
what
I
am
seeing
is
not
the
problem
with
pr
authors,
I
have.
I
have
seen
a
lot
of
problems
with
approvers
maintainers
and
mergers
another
because
another
example
is
that
environment
variables,
pr
666,
which
is
open
like
for
a
month.
F
Yeah
so
I
know:
there's
a
weekly
spec,
triage
meeting,
that's
happening
and
that's
been
really
helpful,
but
that's
just
a
couple
of
maintainers
trying
to
tag
things
and
do
initial
triage.
F
We
don't
really
have
time
to
triage
in
this
or
the
spec
meeting.
It
seems
those
these
times
we
want
to
use
for
debate.
Do
we
need
to
have
just
more
meetings
on
the
agenda
to
get
different
approval
groups
together?
Do
we
need
to
be
bothering
approvers
pager
duty
like.
A
F
A
F
Well,
I
was
just
gonna
turn
it
to
to
maintainers
and
approvers
on
here.
Are
people
struggling
to
one
of
the
issues?
Is
people
are
often
over
committed?
F
Another
issue
might
just
not
be
enough
structure,
so
I'm
curious
for
maintainers
on
the
call
is
the
issue
that
you're
feeling
overwhelmed
or
you're
not
noticing
this
problem
or
you
do
notice
it,
but
you
feel,
like
you,
you
need
more
structure
or
help
from
the
project
in
general
to
keep
on
top
of
stuff.
E
From
from
my
perspective,
I
think
that
we
it's
difficult
to
add
additional
time
and
leverage
to
a
project
when
you're
already
busy,
with
your
normal
workload
and
then
your
specs
workload
and
then
potentially
other,
like
other
approvers
approvals
and
things,
and
I
think
that
adding
another
meeting
would
be
an
anti-goal,
because
you
shouldn't
have
to
show
up
to
a
specific
place
at
a
specific
time
to
work
through
an
issue.
E
That's
like
the
whole
point
of
of
being
able
to
triage
the
issues
through
github,
I
think
potentially,
and
this
this
is
an
idea
that
I've
had
but
I've.
I
hesitated
to
bring
it
up,
but
I
think
it
might
be
helpful
like
have
a
spec
approvers
channel
in
getter.
That
way
people
can
go
like
this
is
where
I
need
to
go
to
be
able
to
determine
whether
or
not
there
are
open
over
open
prs
that
need
to
be
approved.
I
think
it's
difficult,
sometimes.
A
E
I
F
I
think
almost
everyone
who's
tasked
with
reviewing
and
dealing
with
spec
work,
pretty
much
has
not
only
a
regular
job
but
also
another
job
within
open
telemetry
right
like
so
I'm
wondering
if
maintainers
are
struggling
to
pay
attention
to
specs,
because
they're
having
to
jam
out
the
beta
fixes
and
beta
features.
So
that's
that's
sort
of
what
I'm
wondering
is
it.
People
are
overextended
within
the
project.
F
So
it
sounds
like
we
have
to
deal
with
if
it
doesn't
get
enough
approvers.
What
is
this
step
right
and
there
needs
to
be
a
as
part
of
a
triage
process
identifying
stuff
where
it's
just
gone?
Stale
and
stale
needs
to
be
a
very
short
amount
of
time,
but
stale
is
not
getting
comments
from
approvers
or
not
getting
approvals,
so
not
seeing
action.
That's
something
we
can
automate
to
highlight
within
github,
so
just
being
aggressive
around
issues
that
are
not
getting
responses
from
approvers
actively
poking
approvers.
F
Maybe
it's
a
review
of
the
approvers
list
and
getting
people
to
recommit
at
the
same
time,
trying
to
maybe
get
some
commitment
from
if
people
are
being
paid
to
work
on
the
project,
some
commitment
for
for
more
time
to
get
the
spec
and
the
ga
out
the
door.
F
F
A
H
A
H
Okay,
I
I
like
to
disagree
with
you
on
that,
because
I
think
I'm
trying
to
pay
attention
to
the
issues
or
the
prs.
The
problem
is
that,
as
I
said
before,
like
for
example,
you
have
a
pr
and
it
has
enough
approvals,
but
I
still
see
people
asking
so
what
should
I
do
and,
for
example,
even
myself,
I
have
a
pr
agency
specification
and
I
have
two
approvals,
which
means
I
can
merge
it,
but
then
somebody
comes
and
says:
hey.
Please
don't
do
that
and
then
of
course
it's
like
should
I
I
have
enough
approvals.
H
F
I
think
that's
where
the
the
tc
would
need
to
step
in.
We
could
expand
the
tc.
If
there's
not
enough
people
there.
I
have
felt
that
four
is
insufficient
for
the
amount
of
admin
work
that
the
tc
has
to
do,
but,
yes,
being
aggressive
about
labeling
issues
is
stale
so
that
we
know
which
ones
we're
talking
about
and
we
can
find
them.
F
I
think
we
need
to
be
aggressive
about
calling
things
stale
and
then
the
tc
needs
to
be
aggressive
about
either
saying
merge
this
as
is
or
saying,
cut
that
piece
out
and
merge
it
without
the
contentious
piece
and
if
the
person
providing
the
pr
is
not
getting
back,
potentially
someone
else
taking
over
the
pr
for
the
final
merge.
If,
if
it's
really
something
small
like
we
have
approval,
but
can
you
just
change
this
language
and
then
they've
dropped
out?
F
So
I
can
see
a
tc
that
has
a
lot
of
time
to
pay
attention
to
the
spec
being
able
to
to
cat
herd
in
that
manner.
But
again.
F
J
The
tc
having
the
time
right,
because
that
is
a
big
factor.
Can
we
going
forwards,
recommend
that
members
of
the
tc
do
not
take
on
maintainer
roles
in.
I
H
Yeah
you're
the
second
person
who
who
told
me
about
this
idea.
So
probably
it's
worth
considering.
K
If
we
have
some
agreements
instead
of
moving
towards
a
everything
merge
to
master
branch
has
to
be
picture
perfect,
that
we
have
the
merge
to
master
as
at
least
the
step
towards
progress
in
the
synchronization
between
the
spec
in
the
language
sigs
on
the
release
of
a
spec.
So
the
next
version
release
of
the
spec
is
when
it's
actually
a
formal
communication
to
the
language
says
like
okay,.
I
K
It's
locked
down
that
my
hope
is
that
if
we
were
then
to
be
more
free
to
be
able
to
merge
pr's
into
the
specs
and
the
spec
document,
it
could
be
half-baked
but
a
step
towards
the
right
directions
like
yeah
yeah.
K
We
got
this
part
in
and
out
that
part
in
at
least
we're
going
to
merge
it,
and
when
I
got
enough
lg
tms,
I'm
not
going
to
wait
24
hours
boom
and
it
comes
in
but
understand
that
the
next
specific
release
of
the
spec
release
has
to
have
that
cleanup
done
before
that.
K
So
my
proposal
is
in
hopes
of
like
as
soon
as
we
literally
get
the
bare
minimum
agreed
requirement
of
lgm's
and
approvalers
that
it
just
merged
as
fast
as
possible.
After
that,
like
in
order
to
get
the
lgtms,
it
meant
that
it
had
to
have
at
least
waited
that
24
hours
in
order
to
be
able
to
get
like.
K
Global
cycle
of
anyone
be
able
to
put
comments
if
they
didn't
put
in
their
comment,
if
they
weren't
there
for
the
meeting,
if
they
weren't
there
for
the
discussion
and
it
got
merged
before
then,
the
person
who
disagrees
may
put
up
a
a
a
suitable
pr
in
order
to
make
adjustments
towards
it
and
to
be
honest
beyond
then
be
able
to
work
it.
K
So
I
offer
that,
in
order
to
help
with
the
velocity
in
order
to
at
least
make
stepping
stone
step
progresses,
but
we
would
need
to
make
sure
we've
got
more
formal
release
schedule
like
we
had
a
monthly
release
schedule
for
the
spec.
K
Maybe
we
need
to
start
looking
into
that
again
in
order
to
be
able
to
work
with
the
strategy.
C
I
I
have
some
suggestions.
The
first
thing
is,
I
figure
like
in
the
spec
currently
we're
not
in
a
very
good
shape
and
whenever
we
try
to
make
a
change,
because
it
is
hard,
so
the
other
reviewers
or
like
contributors,
they
try
to
take
this
opportunity
to
get
their
ideas
into
that.
So,
for
example,
I
try
to
send
the
pr
clarify
how
we
can
make
progress
on
the
pr,
but
obviously
I
failed
to
do
my
job.
C
It
seems
like
I
don't
know
how
to
make
progress
on
my
own
pr,
and
with
that
I'm
saying
like
I
got
some
approval
initially,
but
then
people
start
to
see
it
it'll
be
great.
If
you
can
add
this,
but
my
favorite
is
that
this
that
will
reverse
the
initial
approval.
Some
some
people
would
come
back
and
say
riley.
You
change
this
pr
significantly
start
adding
new
information.
C
I
need
to
review
the
pr
again
and
that's
over
over
and
over
another
thing,
I
I
think,
as
andrew
mentioned
is
related
to
the
release
schedule
so
sometimes
like
we
don't
want
to
get
something.
That's
not
very
perfect.
I
do
have
suggestions
so
number.
One
thing
I
think
we
have
the
maintainer
role.
The
maintainer
probably
can
be
more
aggressive
by
telling
people
like
this.
Pr
is
good
enough.
It's
not
perfect,
but
let's
move
it.
It's
it's
a
step,
close
closer
to
the
goal.
C
As
long
as
we're
moving
towards
that
goal,
I
think
we
should
make
progress
otherwise
we'll
be
like,
like
they're,
multiple,
like
needles
intertwined,
and
you
cannot
make
progress
at
all
the
second
one.
I
think
what
we
can
do
is
to
have
individual
status
and
the
owner
information
on
spec.
So
I
want
to
share
my
desktop.
This
is
something
I've
done
in
microsoft
and
I
feel
it's
very
helpful.
C
So
can
you
see
my
screen
yep?
This
is
the
this
is
like
the
the
schema
in
microsoft,
so
we
do
have
our
own
schema
and
that
have
been
used
by
many
years
and
when
I
took
this
over,
it
was
a
little
bit
messy
because
there's
no
clear
ownership.
So
what
I
I
did
is
I
put
the
clear
owner
and
who
should
approve
that
and
what's
the
status
and
for
people
who
want
to
make
progress,
they
can
do
whatever
change
they
want.
C
This
is
something
I
want
to
propose
for
our
current
spec
and
also
knowing
like
who
should
approve
in
this
way
like
if
all
the
approvers
approve
the
other
community
members
come
and
contribute
hey,
I
think
it'll
be
great
if
we
can
add
something
we
can
park
this
and
mark.
This
has
approved
and
tracked
the
additional
ask
as
an
issue.
F
So
for
for
draft,
we
we
have
the
otep
kind
of
rfc
process
that
was
partially
to
address
the
the
draft
issue
being
able
to
draft
your
thoughts
about
all
the
changes
you
wanted
to
make.
If
it
was
a
big
change
and
then
get
that
approved
and
then
go
add
it
to
the
spec.
F
So
I
feel
like
we've
got
some
process
there
and
we
there
is
clear
ownership
of
approvers.
We
have
sub-approvers
and
there's
clear
ownership
of
the
spec
in
the
tc.
So
I
do
wonder
if
it's
just
like
what
nikita
is
saying
like
it's
it's
right
now,
it's
clear
the
lines
of
ownership
are
clear.
It
just
needs
more
attention.
F
F
C
Okay,
I'll
give
some
example
and
I'm
not
proposing
that
we
should
use
draft
I'm
trying
to
figure
out
a
way
where
we
can
make
progress,
and
probably
I
want
to
step
a
little
bit
back.
Look
at
the
example
and
see
like,
what's
our
thinking
so
take
a
look
at
this
comment.
So
carlos
mentioned
there's
something
already
mentioned
in
another
spec.
Well,
I
think
that
that's
back
has
a
lot
of
issues,
so
I
think
I
don't
have
energy
to
clean
up.
C
H
Yeah,
sorry,
I
mean
you
know,
I
I
already
approved
that
so
I
have
sorry
yeah
it
was.
I
have
given
it
for
like.
C
For
granted
way
back,
yeah
yeah,
I
understand
so
I
just
want
to
give
a
like.
Please
study
and
know
like
people
are
very
active
on
this,
but
sometimes
it
seems
our
understanding
is
different
and
given
there's
a
social
pressure,
so
colors
saw
some
like
comments
from
the
community
they're
saying
it
would
be
great
to
add
that
and
because
of
social
pressure,
probably
colors
feels
uncomfortable
to
just
go
and
merge
that.
C
So
I
want
to
like
make
sure
we're
on
the
same
page
and
and
make
it
very
explicit
so
so
going
down
for
this
one
like
I,
I
propose
there's
a
big
change.
Initially,
it
was
like
maintainers
converge
that
and
I
figured
if
we
have
the
rule
and
once
it's
approved,
if
approvers
based
on
the
rule,
just
merge
that
I
think
that
will
help
us
to
unblock
the
progress
and
this
one.
C
I
don't
feel
confident
enough
unless
I
got
enough
support,
I'm
trying
to
change
the
game
here,
and
I
don't
want
to
change
the
game
on
my
own
or
just
because
my
my
own,
like
thinking,
so
how
should
we
move
forward
in
this
case?
I'm
happy
to
even
revert
back
this
line
and
say
like
we're
not
going
to
change
anything.
Only
maintainers
can
merge
that.
But
how
should
I
make
progress?
Should
I
ping,
like
the
the
tc
members,
to
get
their
support
or
if
I
got
enough
approver
supporting
me?
Oh
I'll,
be
good.
J
So
carla,
like
back
to
riley's
point
about
sort
of
proactive
maintainers,
I
mean
it
would
have
been
good.
This
last
comment
was
six
days
ago.
If
the
maintainers
were
like
in
other
cigs,
the
maintainers
are
actively
you
know
in
dialogue
with
the
pr's
and
they
would
say
hey
this
sounds
you
know,
let
let's
wait
and
do
this
on
a
follow-up
pr
like
or
let's
you
know
here
I'll,
open
an
issue
for
this.
J
Let's
not
make
it
hold
back
this
pr,
they're
more
proactive,
and
it
feels
like
you
know
and
again
that
maybe
back
to
the
time
issue.
J
But
you
know
the
technical
committee
is
like
this
super
critical
function
for
open
telemetry.
It
feels
like
people
on
the
technical
committee.
Their
employers
should
be
dedicating.
You
know
a
good
amount
of
time
for
them
to
participate
at
the
technical
committee
level
and
to
drive
the
spec
proactively
more
proactively
than
is
happening
currently.
H
Yeah,
I
think
this
is
a
good
point
and
I
would
totally
be
on
the
communication
level
totally
agree
with
you.
My
path
on
being
more
aggressive.
H
H
Sure
sure,
okay,
okay,
see
your
point.
I
thought
I
had
the
impression
that
you
were
talking
about
trying
to
be
more
aggressive,
closing
or
merging
the
issues.
J
Okay,
no
proactive
trying
to
get
consensus,
trying
to
drive
consensus
and
deciding
where
things
can
be
peeled
off
into
separate
issues
how
to
narrow
it.
Yes,
with
the
end
goal
of
you
know
closing,
but
it's
about.
J
We
need
more
proactive
from
the
leadership,
because
people
will
more
listen
to
the
leadership.
The
maintainers.
H
Okay,
that's
great
feedback
on
that
note
yeah,
probably
since
we
could
probably
get
more
people
dtc.
That
being
said
so
yeah
a
good
point,
and
I
will
I
will
take
that
point
into
account.
F
Yeah
and
yeah-
I
don't
know
about
a
draft
status,
but
as
we're
saying
here
for
a
lot
of
these
pr's,
it
seems
like
there
will
be
just
it'll
mostly
be
approved,
but
there
will
be
some
bit
where
people
want
to
either
add
more
or
there's
one
thing
that's
contentious,
and
if
we
can
either
call
that
thing
or
just
create
another
issue
for
that
one
thing
and
close
the
pr
without
it.
That
seems
like
that
would
increase
our
velocity,
ideally
we're
not
creating
actual
issues.
C
Yeah
so
one
example
here
like
I
got
a
comment
and
I
think
that
makes
makes
a
lot
of
sense.
So
in
people
I
got
approval
and
they
make
a
all
of
a
sudden.
They
make
a
change
and
then
the
pr
got
merged
that'll
be
surprising,
so
I
think
it
makes
sense,
but
I
gotta
affair.
If
I
put
that
sentence
here,
it
doesn't
have
enough
clarification.
People
would
ask
like
what
does
it
mean
for
like
a
significant
and
I'm
I'm
backing
to
the
definition
of
what
is
significant
and
it's
hard
in
this
way.
C
If
I'm
going
to
solve
this,
I
probably
will
change
the
system
by
saying
no
matter
what
kind
of
the
change,
even
if
it's
like
just
adding
a
space.
If
it's
changed,
all
the
pr
like
approval,
got
dismissed
and
people
got
to
approve
that
again,
but
people
might
say
like
riley
you're
trying
to
slow
us
down
again,
but
I
figured.
I
C
Yeah,
so
the
in
the
state
start
starter
tab,
so
you
know
class.
I
actually
try
to
try
to
make
sure
we
have
a
very
limited
desire
for
single
pr.
For
example,
we
do
have
interns
trying
to
change
something
and
people
notice.
Oh,
like
the
way
users
suddenly
like
reminded
me
that
we
have
a
fundamental
problem.
There's
a
memory
management
issue,
we're
going
to
fix
that
issue,
that'll
be
like
changing
100
files
and
as
a
maintainer
I
got
to
decide.
C
Okay,
the
current
pr
will
still
have
memory
leak,
but
it's
not
making
things
worse
because
we
always
have
this
memory
leak
just
go
and
merge
that
and
we'll
create
an
issue
to
track
that,
but
that
bar
is
hard
because
sometimes
I
gotta
attack
like
people
are
asking
like
right.
You
approve
a
pr
with
memory
leak.
So
what
are
you
thinking?
And
I
I
think
it's
a
the
maintainer's
job.
You
do
the
job
you
have
to
make
decision
and
you
have
to
take
the
blame.
Otherwise,
you
always
step
back
and
and
try
to
get
everything
perfect.
C
A
One
more
thing
that
I
think
seeing
those
those
comments
like
what
about,
and
that
reminds
me:
it's
like
people
trying
to
scratch
their
own
each
with
your
hands.
I
don't
like
the
thinking
is
paired.
Can
you
please
fix
it
for
me,
because
I
don't
because
I
don't
care
to
submit
full
request
myself
so
wow,
if
you
don't
like
these,
submit
the
pull
request,
they
fix
it.
My
pull
request
addresses
this
concrete,
specific
problem.
It
makes
one
step
in
the
right
direction.
A
H
A
And
and
and
it's
it
has
to
be,
the
maintainers
and
approver
job
as
well
to
protect
contributors
from
that
feature
creep
because
contributors,
essentially
especially
new
one,
they
are
very
susceptible
to
that
feature
creep.
Who
approver
asked
me
to
add
something
I
have
to
do
that
other
other
approvers
and
maintainers
have
to
protect
that
pull
repair
from
feature
clip
one
step.
C
Yeah
and
another
example
here
is
like
I,
I
also
like
the
idea.
I
think
we
probably
can
add
the
maintainers
here,
but
then
we
have.
We
have
two
drivers
and
my
worries.
Whenever
they're,
like
we
mentioned
two
drivers,
it's
like
in
microsoft,
people
send
email
to
like
three
people
and
ask
hey:
would
you
do
this?
Nobody
would
do
that.
You
need
to
remove
two
folks
from
the
to
list
and
make
only
one
there.
So
so
I
do
have
my
opinion,
but,
like
I,
I
got
an
affair.
C
F
Yeah,
I
think
do
that
as
as
a
author
of
a
pr,
I
think,
likewise,
anyone
from
this
group
or
the
greater
group
as
the
pr
author,
it's
also
okay,
to
push
back
on
feature
creep
and
say
like
okay.
Why
don't
we
do
this
as
a
separate
pr
or
that's
interesting,
but
I
just
want
to
get
this
merged.
So
I
think
it's
okay
to
say
these
things
as
the
author
as
well.
F
J
Yeah
a
question
is
carlos:
the
only
spec
maintainer
on
this
call.
C
A
G
A
I
F
C
C
A
F
K
I
put
a
link
to
the
list
of
the
names
in
the
zoom.
I
K
It
is,
I
agree,
it's
not
in
alignment
with
the
other
language
sigs
that
actually
has
the
name
very
clearly
who's.
The
maintainer
of
the
language.
Spectac
is,
unfortunately,
another
md
file.
That's
not
the
readme.md,
it
is
stated,
but
yeah
there's
75
percent
of
the
technical
committee
missing.
I
F
I
honestly
I
mean
we
keep
going
round
and
round,
but
it
it
feels
like
that's
the
core
thing.
We
just
need
the
more
people
on
the
technical
committee
and
people
who
are
on
it
currently
need
to
get
more
time
from
their
employers
to
work
on
this
stuff.
I
could
say
you
probably
yeah.
H
But
you
know
the
situation,
and
this
is
not
talking
from
myself,
because
I
at
least
in
like
seven
I'm
allowed
to
spend
some
time,
although
I'm
probably
spending
too
much
time
between
java
and
specification,
but
from
the
rest
of
the
tc
members,
like
especially
the
future
ones,
is
the
commitment
that
they
are
not
only
good,
but
they
also
have
time
like,
for
example,
I
think
that
tigran
was
is
somebody
who
has
enough
expertise.
You
know
who
come
join
the
tc,
but
the
question
is:
does
he
have
enough
time
free
time
for
working
on
this?
H
You
know
whoever
comes.
There
needs
to
be
at
least
a
minimum
commitment
to
to
spend
some
cycles
on
this.
J
Yeah
I
mean
we've
thrown
around
the
number
for
maintainers
on
other
sigs,
that
you
know
it
requires
50
or
more
of
your
time.
You
know,
I
don't
see
why
the
spec
maintainer
role
would
be
any
different.
H
And
I
want
to
be
more
proactive
by
the
way.
Thank
you
for
the
feedback.
It
was
rough
feedback,
but
it's
valid
feedback,
so
I
will
be
putting
more
more
more
love
into
this
and
yeah,
but
any
any
other
action
items
well.
F
I
would
ask
people
to
before
we
move
on
to
the
next
subject.
I
did
try
to
re
capture
some
of
the
important
action
items.
I
think
people
were
mentioning.
I
haven't
assigned
people
to
this,
but
people
would
like
to
just
review
this
list.
What
I'm
looking
at
based
on
this
discussion
is
we
want
to
aggressively
mark
issues
as
stale
that
could
be
approvers,
not
responding
the
author's
not
responding.
The
tc
needs
to
make
a
decision.
F
F
Code
owner
anyone
with
in
that
code
owner
file,
can
do
that
so.
A
A
F
K
F
A
F
It
would
be
great
to
have
a
bot
do
this,
but
yeah
it
should
be
much
more
aggressive
right.
It
should
be
within
days
of
not
getting
a
response.
Okay,.
L
So
so
who's
going
to
go,
create
the
bot.
A
B
Thank
you,
hey
ted
from
action
item
perspective.
Can
the
governance
committee
lean
a
little
bit
on
the
tc
to
actually
show
up
to
the
maintainers
meeting.
C
I
want
to,
if
I
can,
I
can
offer
more
help
on
being
a
maintainer
of
the
spec
ripple,
so
you
know
like
in
in
the
donated
repo.
It
has
been
there
for
like
two
years
and
and
I
I
think
I
I
did
some
process
change
and
that
really
helped
people
to
move
forward
and
now.net
finally
has
a
beta
and
we're
on
track
for
ga
for
spec.
I
have
done
something
similar
inside
microsoft.
It's
hard
like
drive
for
people
from
windows
office.
This
big
organization
is
to
align.
C
And
given
the
maintainer
doesn't
have
a
microsoft
guy,
I
think
I
I'm
willing
to
do
extra
job
here
and
for
the
c
plus
plus
project,
as
we
just
talked
about.
We
want
the
the
the
maintainer
for
the
spec
to
have
more
time
instead
of
working
on
the
individual
language
as
a
maintainer,
so
for
cpa
plus,
I
I
don't
have
a
full-time
employee
where
I
want
to
grow
him
as
the
maintainer
for
that
ripple,
and
eventually
we
can
get
there.
H
C
Yeah,
but
my
style
is
a
little
bit
different
time,
I'm
more
aggressive,
so
I
try
to
unblock
people
even
knowing
they're
they're,
not
a
hundred
percent
perfect
and
sometimes
like
I
I
do
understand,
like
people
have
a
different
style,
but
sometimes
people
hate
that
style.
So
if
I'm
doing
that
more
on
one
direction,
which
is
different,
then
please,
let
me
know
the
feedback,
so
I
I
kind
of
adjust
myself
sounds
like
sounds
like
from
the
last
20
minutes.
That's
exactly
what
we
need
yeah
so
sometimes
like.
C
I
know
like
a
lot
of
things
like
people
like
in
microsoft,
things
are
not
moving
faster
and
people
put
me
there.
Then
they
start
to
see
like
progress
and
people
like
me,
but
sometimes
I
could
be
causing
damage
because
I
want
to
move
forward.
Even
if
something
is
not
perfect,
then
eventually
people
realize
oh
you're,
moving
too
fast,
there's
no
absolute
definition
of
what's
right
or
wrong.
It's
just
like
your
style,
but
I
got
enough
experience.
A
Yeah,
so
let
me
let
me
ask
that
action
item
add
more
gc
members,
so
we
have
one
one
candidate.
So
first
query
question
what
should
happen
to
that
candidate
be
approved
or
rejected?
Who
who
should
do?
F
F
It's
entirely
up
to
the
tc.
The
dc
votes,
essentially.
H
We
want
more
as
long
as
they
have
enough
time
and,
as
I
said,
tikrang
was,
for
example,
you
was
one
example
of
a
natural
choice,
but
I
think
he's
too
busy
with
the
collector
so
yeah,
let's
go.
Let's
go
one
step
at
a
time,
if
you
can
think
of
in
the
following
days
of
somebody
who
would
be
like
a
good
addition
with
experience
and
also
time.
G
G
F
Do
we
want
to
add
for
these
final
action
items?
One
was
just
avoiding
feature
creep
and
prs
and
another
one
was
for
adding
owner
and
just
more
information
on
how
the
spec
process
works.
F
F
F
K
A
K
K
Okay,
where
are
we
right?
So
we've
gone
through
the
the
initial
phase
of
triaging,
a
crapload
of
issues
and
now
we're
kind
of
like
in
maintenance
of
triaging
issues
as
they
come
in
with
a
double
check
on
the
spec-ish
on
the
spec
meetings
in
order
to
make
sure
they're,
triaged
and
prioritized
and
assigned
on
the
spectrum.
So
I
got
like
a
15-minute
time
block
every
single
spec
sig,
but
to
utilize
tools
that
we
got
and
lined
up.
We
have
on
the
ga
spectrum
now
very
high
level.
K
90
issues
in
queue
that
we've
identified
for
required
for
ga
p1,
p2,
p3
6,
are
in
progress
and
14
have
been
completed.
So
progress
goes,
but
this
is
the
way
which
we
we
we
go
at
it.
If
we
wanted
to
talk
about
label
priority,
p1
24
are
marked
as
p1
3
are
in
progress
and
14
3
have
been
completed
out
of
14
once
it's
done.
K
So
that's
the
progress
we
got,
however
yeah
the
velocity
is
not
as
big,
but
I
mean
I
see
some
common
trends
on
if
you
scroll
down
like
who's
assigned
to
who,
what
and
and
who's
got
one
on
the
plate,
these
empty
ones
that
doesn't
have
enough
an
assigned.
We
will
go
over
at
the
spec
meeting
tomorrow,
but
there
are
multiple,
for
example,
carlos
has
got
a
bunch,
but
also
carlos
is
working
on
a
bunch.
K
So
that's
where
we're
having
some
bottle
neck
in
terms
of
theoretically.
We
can't
have
like
all
90
in
the
in
progress
and
then
expect
everything
to
be
done
like
in
a
week
or
two
weeks
or
a
month's
time
right.
There
is
a
funnel
shape.
That
is
now.
I
don't
know
whether
we
need
to
be
more
granular
than
the
p1,
so
the
p1p2p3
was
a
strategy
in
order
to
like
reduce
it
from
nine
to
nine
he's
like
freaking.
How
are
we
going
to
chop
up
90.
K
so
now
that
we
have
it
locked
down
to
p1
p2
p3
p1
is
still
a
bit
of
a
funnel
shape
of
like
yeah
there's
going
to
be
some
stuff
in
the
backlog.
That's
not
going
to
have
progress
because
we
have
too
many
people
assigned,
so
that's
the
status
of
where
we
are
right
now.
What
would
help
as
if
I
heard
rumblings
that
we're
in
order
to
have
a
concentration
on
spec
related
items?
Morgan?
K
I
don't
want
to
step
on
this
point
if
you
want
to
talk
about
it,
but
that's
the
update
that
I
wanted
to
give
for
for
our
ga
spec
right
now.
L
L
We
should
just
do
a
push
towards
getting
a
first
cut
of
the
tracing
spec
and
either
set
a
date
for
that,
after
which,
like
we
just
start
making
like
very
arbitrary
decisions
or,
alternatively,
just
do
like
a
one
day-
sort
of
tracing
spec
shindig,
where
we
get
the
the
technical
committee
and
the
approvers
to
go
and
sit
down
and
go
through
everything.
L
L
L
Maybe
it'd
be
nice
to
just
get
like
an
rc
of
trade,
at
least
the
tracing
spec
sort
of
done
so
that
the
all
of
these
other
cigs
are
unblocked
from
implementing
that,
then
we
can
turn
the
focus
of
the
metrics
back
again
and
that
also
unblocks
things
like
the
open
tracing
bridge,
the
open
census
bridge,
but
yeah
I'll
bring
it
up
in
the
the
spec
meeting
tomorrow,
because
I
think
that's
the
the
more
relevant.
B
K
Are
they
do
we
need
to
update
the
calendar?
The
maintainer
is
holiday
calendar
as
an
fyi.
F
Mine's
already
in
there
yeah
I
added
mine
as
well
yeah
but
yeah.
Just
a
reminder:
there
is
a
maintainers
vacation
calendar.
So
if
people
are
going
to
be
out,
please
add
yourself
to
that.
It's
also
a
handy
calendar
to
have,
I
think,
that's
it.