►
Description
A meeting held on 2020-05-14 to discuss proposed changes to the RFC procedure to introduce a stronger sense of staging.
A
That
comes
earlier
right.
So,
rather
than
intercepting
at
the
point
where
someone
is
already
written,
a
full
RFC,
and
it's
done
a
lot
of
work,
it's
possibly
in
the
direction
that
we
want
to
go,
and
sometimes
they
wouldn't
have
ever
gotten
to
that
stage.
We
were
at
the
like.
There's
the
high
level
idea.
A
I
want
to
pursue
and
the
goals
I
have
within
that
stage,
probably
somewhere
between,
like
that
first
internals
post,
maybe
not
that
early,
but
you
know
more
like
when
the
internals
thread
or
when
you
feel
like
you've
got
a
good
idea
around
how
it
should
actually
work,
and
this
is
that
workflow
we
had
imagined
that
there
would
be
laying
team
repository.
You
would
file
an
issue
on
it.
A
Just
kind
of
decline,
the
idea,
which
would
basically
mean
saying
yeah.
No,
that
doesn't
seem
like
the
direction
that
we
want
to
go
right
now
or
if
people
are
into
it,
we,
if
there's
some
liaison,
then
this
liaison,
which
means
so
raise
this.
If
someone
is
into
it,
the
idea
is
there
should
be
somebody
from
the
team
who
wants
to
pursue
it
and
that
maybe
maybe
indeed
the
one
who
filed
the
issue
in
the
first
place-
I
think
that's
okay,
but
the
then
they
would
either
kind
of.
A
If
it's
a
small
and
simple
idea,
maybe
it
can
just
be
done
by
discussing
making
a
small
proposal
right
up
and
opening
a
PR
that
happens
fairly
regularly.
It
seems
like
that
there
are
small
extensions
to
the
language
that
can
be
covered
in
at
PR,
but
if
the
idea
is
more
complex,
then
we
would
kind
of
go
through
this
idea
of
making
a
stream
dedicated
to
the
idea.
That's
basically
a
project
group
to
talk
it
over
and
do
the
design
and
develop
one
or
more
RFC
s
kind
of,
like
we've
been
doing.
A
The
there
are
a
few
things,
I
think
might
be
good
to
talk
about
like
what
kind
of
the
details
of
what
it
means
to
do
these
steps.
What
does
it
mean
to
charter
a
project
group?
How
is
it
gone?
Our
attempts
to
do
it
so
far,
and
do
we
like
that?
One
thing
I
wanted
to
talk
about
in
particular.
Is
this
idea
of
managing
proposals
and
visualizing
the
backlog?
The
idea
here
is
that
we've
got.
A
We
would
have
a
sort
of
sort
of
prod
of
things
that
we're
pursuing
as
a
team
sorted
into
three
groups
incoming
which
is
like
newly
filed
things
active,
which
are
things
that
were
actively
doing
and
then
back,
but
your
things
that
we
want
to
do
but
they're
not
currently
like.
We
don't
have
time
to
do
them
so
they're
in
this
pending
state.
A
A
Okay
like
Egoscue
has
got
five
things
in
it.
Josh
has
one,
and
Taylor
has
none
like.
Maybe
it's
a
better
idea
if
all
three
of
them
are
interested,
maybe
maybe
Taylor
should
pick
it
up
or
whatever,
so
we
can
kind
of
bow
it
balanced
across
each
other,
because
I
think
that
will
be
the
other
idea
is
that
we
try
to.
A
C
Or
the
incoming
queue,
obviously
it
could
move
to.
Once
the
language
team
has
looked
at
an
incoming
proposal,
it
could
either
move
to
the
backlog
or
to
the
active
column.
But
if
should
the
list
of
let
that's
sort
of
the
happy
path?
Should
the
rejection
path
be
flushed
out
at
all
like?
Should
there
be
a
previously
rejected
archive?
Should
there
be
you
know
not
now?
Should
there
be
yeah.
A
A
We
have
things
that
we
really
want
to
be
moving
along
and
we
want
to
focus
attention
on
right,
and
that
seems
like
what
there
are
so
you're
positive.
Yes,
however,
it
would
be
even
so
in
some
sense
I'm,
not
that
worried,
but
I
think
it's
worth
keeping
in
mind
like
we
should
I,
don't
know
exactly
how
aggressive
we
want
to
be
with
closing,
but
I
think
it
might
be
a
good
idea
to
have
a
kind
of
time-based
closing
mechanism,
that's
sort
of
a
non-judgmental
close
after
a
certain
amount
of
time
if
there
hasn't
been
activity.
A
That's
just
like
this
is
evidence
that
there
isn't
enough
energy
to
move
this
along
right
now
and
that's
okay
and
it
can
be
reopened
in
the
future.
You
know
when
things
do
change,
why
could
even
see
doing
it
with
a
bot
like
after
a
month,
I
think
there's
a
certain
question
about
what
kind
of
tooling
we
should
be
using
or
something
for
people
who
haven't
seen
it
in
the
compiler
team
right
now.
We've
got
it
so
that,
thanks
to
Marco,
maybe
he's
on
this
called
data.
A
When
a
new
issue
is
filed,
it
creates,
for
example,
a
top
I
can
assist
in
a
specified
zoo
lips
cream.
So
there
can
be
discussion,
and
then
you
can
sort
of
a
second
to
a
proposal
and
stuff
like
that
in
just
those
changes
make
a
huge
difference
right.
These
kind
of
automatic
creation
of
places
they
talk,
but.
A
I
would
really
like
to
github
issues
to
be
more
alike,
highlights
than
all
the
details,
so
we
I
think
it
would
be
worth
digging
a
little
bit
and
alike.
That
was
this.
Other
thing
I
had
document
a
little
bit
into
the
workflow
at
that
level
like
when
an
issue
is
filed,
I
could
see
that
maybe
maybe
filing
a
proposal
is
enough
or
definitely
should
be
enough
to
make
a
topic
right.
A
It's
probably
some
stage
where
somebody
says
like
I'm
interested
in
nothingness
that
I
want
to
go
forward
with
the
group
which
might
be
enough
to
make
a
zoo
lips
clean,
but
then
it
has
to
be
a
bigger
decision.
I
think
it
says
yes,
which
one
is
committed
to
you've
figured
out
what
the
problems
we
want
to
attack
are,
and
we
figured
out
the
general
shape
of
the
solution.
We
want
to
create
auditory
and
like
make
this
or
an
activity,
and
that
would
be
like
this.
A
B
D
B
If
leaving
something
around
as
a
like
active
area
of
discussion,
and
even
if
we're
not
doing
on
it
like
some
of
these,
things
seems
like
they
are
active
or
at
least
come
up
so
regularly
that
I
don't
know
that
saying:
hey!
It's
closed
is
gone.
It's
sort
of
like
there's
a
I'm
thinking
of
just
as
a
little
example.
Fru
with
Nani
FRU
with
non
copy
stuff,
has
come
up
like
seven
different
times
and
I.
B
E
Personally
would
be
fine
with
auto
closing
things
after
a
certain
amount
of
time,
if
there
are
no
comments
and
it's
ountry
ozt.
So
it's
been,
you
know
three
or
four
weeks
and
nobody
from
the
language
team
has
categorized
or
commented
or
otherwise
done
anything
with
it.
Closing
it
and
making
it
easy
for
people
to
reopen
would
be
fine.
Maybe
we
could
make
the
tooling
have
a
message
when
it
closes
saying.
E
B
A
Step
because
I
think
it's
good
to
talk
about
what
the
purpose
of
these
issues
are
like.
Do
we
intend
coming
back
to
what
Scott
was
saying
about
long-running
discussions?
Do
we
intend
for
that
to
be
taking
place,
like
I
kind
of
think,
it's
okay
for
that
to
be
taking
place
in
in
Turtles
and
outside,
and
this
the
goal
of
these
things
should
be
more
like
really
to
direct
action.
A
I
wanted
to
point
out
one
other
thing
which
I
think
it
would
be
useful
for
us.
I
only
have
this
one
example,
but
you
know
when
we
have
long
conversations
I
would
like
to
have
a
space.
Maybe
this
isn't
the
right
answer,
but
where
we
kind
of
collect
details
like
here's,
a
topic
so
that
when
people
pick
it
up
again,
they
can
be
pointed
at
it,
and
I
would
imagine
that
we
might
do
similar
things
for
topics
like
FRU
like
if
there's
some
long,
internals
thread
that
explored
an
issue.
F
Going
to
them-
oh
I'm,
just
gonna,
say
there's
like
also
an
awkward
third
category
separate
from
there
like
no
one
from
the
lane
team
comments
on
it
and
we're
not
like,
which
is
the
stuff
that
got
sort
of
too
controversial
to
move
forward.
I
think
there
are
a
bunch
of
RFC's
that
are
kind
of
in
this
category,
of
like
things
that
are
still
open,
that
nobody
really
wants
to
talk
about.
I,
don't
know
if
those
like
should
also
be
covered
under
sort
of
an
auto
clothes.
So.
E
To
clarify
something:
I
didn't
mean
no
comments
ever
from
the
lang.
Team.
I
meant
no
comments
recently.
So
if
something
goes
a
month
and
nobody
touches,
it,
then
I
think
it's
real
reasonable
to
have
a
realistic
reflection
of
its
current
status.
By
closing
it
saying
it
looks
like
this
probably
won't
get
dealt
with
for
a
while.
You
can
do
this
if
you
want
to
reopen
it.
If
there's
new
information,
that's
just
reflecting
the
current
status
so
that
the
lists
become
doesn't
become
unmanageable.
E
A
A
Think
I
would
I,
don't
know
where
I
would
put
that,
but
I
think
one
place
might
be
like
having
these
kind
of
notes,
like
I
mentioned,
if
something
feels
blocked
for
now
until
we've
caught
it
as
far
as
we
can
with
there's
some
other
developments
they
needed,
then
maybe
we
just
mothball
it
right
out.
What
we
think
is
the
right
approach
and
whatever
block
done
and
move
on,
I
think
controversial
things
like
I,
don't
know
feel
like.
F
I
guess
then,
it
reaches
a
sort
of
scary
point
for
whoever
has
to
look
at
reopening
that.
But
maybe
that's
a
good
thing
and
we
should
just
not
like
we
should
just
not
do
controversial
things.
I
wouldn't
say
that,
but
yeah
I
also
wouldn't
say
that,
which
is
why
I'm
sort
of
like
pushing
on
this
as
I
feel
like.
It
is
also
important
to
do
controversial
things,
but
I
understand
like
what
can
cause
those
things
to
be
stalled
out
and
have
you
know,
feeling
increasingly
sort
of
insurmountable
it.
A
Might
be
worth
that's
a
little
bit
touching
on
the
the
other
document
that
I
didn't
open
up
yet
of
like
shaping
conversations
a
little
more,
and
maybe
we
should
talk
about
that.
So
I
think
that's
relevant
I
think
a
lot
of
the
problems.
We
have
a
controversies,
come
about
or
Tim
I'm
about,
because
but
can
be
better
managed
by
setting
expectations
for
what
is
happening
at
this
moment.
I
think
what
kind
of
comments
and
so
forth
makes
sense.
A
So
I'm
I'm,
not
sure
if
this
is
just
my
tea
I
just
want
to
ask
I
have
I.
Have
this
feeling
like
okay,
it
seems
like
what
we're
saying
is
you
would
open
issues
they
would
get
closed
after
a
certain
amount
of
an
activity
with
a
non-judgmental
close,
probably
there's
a
message.
First,
it
does
like
hey.
We
haven't
seen
a
lot
of
activity
here.
This
will
be
closed
in
one
more
week.
A
B
The
the
thread
there
of
okay-
we
don't
want
the
issue
of
open
if
it's
not
actually
working
on
it,
but
we
do
have
the
section
of
the
markdown
file
or
something
of
progress
that
was
made
towards
blah
as
a
like
thing
that
we
can
link
from
ILO
the
next
time
it
comes
up
or
something
like
that.
I
like
that
thought,
yeah.
A
I
think
that
could
be
really
useful
and
I
think
we
should
encourage
people
to
like
go
ahead
and
log
their
progress.
They're
like
well,
we'll
take
it
we'll
try
to
organize
a
little
bit
I,
don't
eventually
I
may
become
overwhelming
that
I,
don't
particularly
like.
We
currently
have
the
RFC
issues
and
they
sort
of
play
that
role
like
on
the
RFC
repo
they're
issues.
They
like
random
conversation,
started,
read
comments
and
controversies,
and
that
doesn't
seem
good.
B
E
B
A
I
think
that
would
be
welcome.
I
wanted
to
say
that
I
think
it's
probably
worth
digging
a
little
into
what
we
expect.
A
proposal
to
contain
in
that
I
would
I
would
think
it
should
be
actionable,
so
it
should
have
a
sort
of
would
not
be
once,
but
you
know
at
least
some
imagine
so,
but
I
think
it
should
also
be
focusing
a
lot
on
why
right
or
on
motivation,
then
on
mechanism.
As
the
point
is
this
yeah
I.
G
Think,
just
going
back
to
the
idea
of
it
being
like
that
the
format
is
like
a
PR
then
gets
Auto
murder
into
this
like
incomplete
proposals
when
you're
talking
about
like
the
idea
that
you
know
as
part
of
closing
there's
gonna
be
this
summary
that
explains
things.
My
reaction
to
that
is
I
feel
like
people
won't
do
that
like
if
you
know
the
proposals
getting
closed,
why
would
you
like
put
in
the
work
to
write
the
summary
and
so
having
the
summary,
be
written
up
front
when
it
seems
like
it?
G
A
A
G
G
A
H
A
A
I
D
Reopening
procedure
should
be
something
like
you
file
the
request
against
the
existing
file.
Elaborating
on
the
summary,
you
know
the
presume
that
something
new
has
changed
and
say
you
know
this
is
the
new
development
and
the
main
team
always
sort
of
considers
the
whole
proposal,
not
just
a
dip
in
the
pool
request
and
if
there's
interesting
great
and
if
not
well,
we
generated
some
more
sorry
yeah.
A
B
Really,
like
the
point
in
there
that
you
made
that
that
separates,
hey
I
still
want
this
from
something
has
changed.
That
concretely,
should
make
you
consents
differently
now,
because
it's
that
would
solve
the
there
are
some
irlo
things
that
particular
people
just
bring
back
up
again
every
four
months
or
so,
when
really
not
anything
is
different
about
what
they're
proposing
or
what
the
landscape
is.
But
if
that,
if
the
PR
is
just
empty,
then
it
would
be
my
easier
for
us
to
say
sorry.
It
looks
like
nothing's
changed
and
we're
still
not
interested.
A
E
What
one
variant
of
that
I
don't
know
that
we
should
necessarily
auto-close
things
that
are
dispositioned
in
some
way
by
the
lengthy
m--
I
I
was
imagining
auto-close
as
being
something
for
things
that
haven't
been
dispositioned
yet,
ideally,
we
should
be
making
a
call
on
any
given
thing,
either
in
the
problem
space
or
the
solution
space
and
saying.
Well,
we
might
say
we
like
that
this
problem,
we
think
it's
an
important
problem.
We
would
like
to
see
a
solution
and
then
we
can
tag
it
accordingly.
E
It
might
stick
around
in
the
list
of
things
that
somebody
ought
to
work
on
one
day
just
like
we
have
a
wish
list,
and
we
may
wish
to
keep
that
list
in
github
or
we
might
want
to
keep
it
in
markdown.
But
that's
separate
from
the
concept
of
nobody's
bothered
to
triage
this,
yet
nobody's
bothered
to
make
a
decision
on
this,
yet
I
think
it's
reasonable
to
actually
have
those
stay
open
until
we
either
say
we
don't
want
this
or
we
do
want
this
I.
Don't.
A
E
I'd
be
really
hesitant
to
Auto
merge,
pull
requests,
if
only
because
then
it
will
kind
of
fail,
open,
I
can
very
easily
imagine
somebody
submitting
a
full
request,
that
makes
say
an
inaccurate
summary
or
a
adding
a
pile
of
here's
a
for
what
could
be
politely
described
as
noise
in
terms
of
here's.
My
random
reason
why
I
really
want
this,
and
sometimes
we
just
don't,
have
the
spoons
to
triage
that
right
away
and
I
wouldn't
want
to
see
it
Auto
merged.
A
G
E
A
Mean
we
don't
have
to
Auto
merge,
necessarily
right,
we
might
just
get
a
stale
and
then,
like
I,
think
we
should
be
able
to
keep
up
a
little
bit,
but
I
think
the
main
idea
is
that
was
really
valuable.
Here
is
that
for
some
amount
of
automation
to
help
us
tag
it,
but,
secondly,
that
we're
we're
bringing
in
the
ideas
and
we're
landing
them
somewhere
just
in
a
place.
This
was
an
idea
that
was
had
and
that
something
to
point
out
later
they
can
be,
but
that
isn't
like
not
a
discussion
thread
right.
A
It
is
a
summary
of
some
kind
and
the
reason
I
said
earlier
that
judge
that
I
thought
we
shouldn't
force
ourselves
to
make
a
judgement.
It's
just
that.
Sometimes
that's
harder
didn't
like
it.
I
think
it's
okay,
that
there
are
things
that
are
gray
areas
where
we
don't
actually
know
if
we
want
it
or
not.
Circumstances
might
change,
there's
disagreements,
but
we
do
know
that
we're
not
acting
on
it
in
the
short
term
and
I.
Think
it's
fine
to
just
let
that
happen.
Saying
yeah,
that's
fact,
is
there
hasn't
been
enough
motion,
it's
obvious.
E
Sure
to
clarify
I
was
saying:
we
should
disposition
it.
Somehow
one
possible
disposition
could
be
like
we
I.
Don't
we
don't
know
how
to
deal
with
this
right
now,
but
whatever
it
is
we're
going
to
throw
the
spaghetti
down
the
road.
That's
an
acceptable
disposition.
I
think
that
would
be
enough
to
say:
okay,
let's
close
or
summarize
and
close
or
something,
and
then
we
can
just
Auto
close
things
that
don't
even
have
that
from
us.
That's
all
I
was
getting
at.
G
E
G
Like
I
think
that
it's
like
this
is
sort
of
a
filter
where
we're
going
to
pull
out
some
of
these
ideas
to
work
on
but
like
in
general.
These
ideas
are
not
going
to
make
progress
past
this
stage,
just
because
right,
yep,
we
get
several
ideas
every
day,
close
to
internals,
for
example.
Right
most
of
those
just
will
never
go
anywhere,
because
we
don't
have
time
on
right.
G
B
I
think
part
of
the
part
of
the
auto
close
to
me
is
expressing
a
desire
free,
like
low
effort,
no
prejudice
project.
If
you
know
what
I
mean
there
a
bike,
there
are,
as
you
just
said,
there's
so
many
things
that
come
up
if
we
have
to
explicitly
say
something
about
every
single
one
of
them.
Maybe
that's
bad,
but
I
don't
know.
Maybe
maybe
it
can
be
a
tag
that
we
just
go
through.
That
is
easy
to
add
quickly
where
we're
not
like
SC
peeing
this
tag
or
something
that
still
says
hey.
D
C
C
E
D
E
A
E
A
B
A
G
A
A
E
We
just
agree
that,
yes,
this
is
a
thing
we'd
like
to
see
a
proposal
on
which
puts
it
roughly
at
the
same
status
of
our
various
wishlist
items.
I
think
that
we
may
want
to
have
a
process
for
saying
it.
Yes,
if
somebody
makes
a
proposal,
we
like
and
then
record
it
somewhere
like
on
our
wish
list
of
things
we'd
like
to
see.
A
A
A
A
Process
it
gives
a
certain
amount
of
leeway
to
people
to
pursue
ideas
that
they
like,
without
having
the
consensus
of
the
whole
group
like
it's
one
thing:
if
that
people
are
really
dancing
against
it,
but
should
be
enough,
yeah
I
think
this
is
a
good
idea
to
explore
a
little
bit,
see
flesh
it
out
and
then
come
back
with
its
like.
Okay,
here's
a
sketch
of
the
problem
space.
A
The
solution
we
think
is
best
and
here's.
Why?
And
at
that
point
or
maybe
even
a
couple
of
solutions,
that's
kind
of
the
Charter,
and
it
should
be
enough
to
be
like
alright,
the
team
is
ready
to
commit
to.
We
want.
You
know
all
the
particulars
of
that
solution,
but
we
want
to
solve
that
problem
when
we
think.
I
For
inline
assembly
do
we
think
that
this
sort
of
process
was
working
correctly
because
there
was
sort
of
a
state
where,
among
you,
had
sort
of
completed
an
initial
implementation
and
written
out
like
a
really
detailed
RFC.
But
there
was
still
debate
about
whether
the
working
group
for
inline
assembly
or
the
project
group
for
inline
assembly
yeah.
J
I
H
A
A
B
Okay
and
I
think
in
some
ways
the
beginning
of
the
RFC
in
is
perhaps
that
initial
PR
that
we've
been
talking
about
it,
the
the
problem
space
that
we
wanted
to
explore
anyway.
Hopefully
it
isn't
actually
substantially
more
work
than
just
going
straight
to
an
RFC,
because
you'd
need
those
pieces
of
it
anyway,
you.
H
Know
wanted
to
ask
for
this
problem.
Space
thing
I
saw
on
the
note.
I
know:
I
misfired,
the
meeting
and
I
saw
I
know
it's
earlier
that
it's
this
problem
space
versus
proposal,
there's
like
a
oh,
it
says,
welcome
under
it.
So
I
assume
it
means,
like
the
distinction
is
welcome,
but
we
haven't
defined
what
it
is
and
I
was
particularly
curious
in
the
end
that
the
flow
graph
that
the
overview
that
with
the
nice
graph,
that
is
in
the
hack,
MD
there's
this
box.
H
It
says
language
team
list
of
proposals,
we'd
like
to
see
I'm,
assuming
that's
actually
two
boxes
or
something
went
like
the
list
of
problems
that
we
think
needs
solving
versus
the
you
know,
list
of
hypothetical
proposals
that
we
haven't
spelled
out
but
would
be
used
to
solve.
Some
of
those
problems
is
that
nots
and
it's
worth
trying
to
spell
out
more
particularly,
more
specifically
I.
A
A
D
A
E
J
D
A
B
F
F
A
F
For
some
of
the
things
that
you're
you're
bringing
up
it
sounds
to
me
like
this,
the
steps
for
the
middle
path
seemed
like,
like
those
types
of
PRS
tend
to
be
the
ones
where
it's
like
you're,
not
really
concerned
about
fix
or,
like
you
know,
CFG
used
to
work
this
way,
but
that
was
weird
and
konkey.
So
I
fixed
it
up
a
little
bit
like
here's,
a
PR.
F
A
To
start
I
think
those
things
can
just
be
a
PR
I'm
trying
to
say
that
or
I
think
that
wasn't
my
open
questions,
maybe
but
I
I
feel
ok
with
it
like
there
could
be
PRS
and
they
just
start
there,
but
sometimes
I
think
there
will
be
proposals
that
are
like
people
won't
know
and
they'll
start
with
a
proposal
and
we
definitely
get
RFC,
sometimes
where
we're
like
yeah.
That
was
okay.
That
could
just
be
a
PR.
You
don't
really
need
an
RC
for
this
right
and
I.
F
D
One
potential
area
where
it
sort
of
makes
sense
to
have
a
proposal,
even
if
it's
a
relatively
simple
change,
is
things
like,
for
example,
the
float
in
conversions
that
we
recently
landed,
I
would
have
probably
in
in
the
new
world
one
see
a
proposal
mostly
less,
because
it's
sort
of
there's
lots
of
options,
but
more
so
so
that
we
have
a
documented,
like
don't
on
some
website
that
we
can
point
at
and
say.
This
is
the
reasoning
for
why
we
made
the
change
instead
of
just
to
github
comment.
But
you
know,
like
you,.
F
A
A
A
Sounds
good
thanks
for
explaining
this
time.
I
was
gonna
say
that
a
few
minutes
ago
I
was
gonna
interject
that
maybe
the
next
step
is
I,
don't
know
what
the
next
step
is,
but
I
think
we've
kind
of
got
a
proposal
of
a
proposal
here.
I
had
thought
to
write
this
into
an
RFC
and
the
main
reason
I
thought
to
do.