►
From YouTube: Mozilla - How Rust Does Open Development - June 13, 2018
Description
How Rust Does Open Development
A
So
I
am
nico
misaki's,
and
this
is
aaron,
turin,
here's
some
outdated
pictures
of
us,
or
at
least
of
me
from
github,
but
one
of
the
things
you
know
when
we
when
the
rust
project
started,
it
was
originally
and
always
envisioned
as
an
open
project
right,
but
the
definition
of
open
is
kind
of
a
little
or
a
little
up
in
the
air
and
and
the
reasons
to
be
open
or
maybe
not
entirely
obvious.
Right,
I
mean
I.
A
Think
for
us
here
at
Mozilla,
it's
kind
of
clear
that
we
should
be
open
because
that's
what
we
do
and
it's
part
of
who
we
are
but
I,
think
there's
also
a
very
practical
benefit
to
developing,
especially
a
programming
language,
but
really
any
project.
Probably
in
the
open
I
mean
for
rust.
It
means
that
we
get
to
have
the
the
input
from
his
wider
variety
of
people
as
possible
and
also
that
we
get.
A
We
have
a
better
chance
of
getting
a
lot
of
people
using
rust,
which
then
means
that
if
we
use
rust
in
Mozilla,
then
they're
able
to
contribute
and
help
us
with
patches
and
whatever
else
right.
But
one
of
the
things
we
found
is
that
open
is
also
just
harder
than
you
might
expect
and
there's
a
lot
of
unexpected,
at
least
for
me,
things
that
arose
over
time
and
that
we
had
to
adjust
and
change
our
strategy.
A
One
of
the
things
that
we've
been
progressively
trying
hard
to
do
with
rust,
especially,
is
to
push
the
open
approach
to
as
many
aspects
of
the
of
running
a
project
as
we
can
do
as
many
things
and
as
wide
and
community
oriented
away
as
possible,
and
so
it
started
out.
I
think
the
most
obvious
things
are
like
discussing
the
design
over
a
mailing
list
or
in
public
hacking
on
the
compiler,
having
PRS
on
tools
and
other
things,
and
maybe
library
development.
A
But
you
can
go
way
past
that
there's
lots
of
stuff
that
that
we
are
now
running
kind
of
in
the
open
and
in
community
oriented
way
right.
So
things
like
running
our
infrastructure
and
our
release,
process,
website
maintenance
and
also
things
like
organizing
of
meetups
and
conferences,
and
the
list
goes
on
and
on
right-
and
this
didn't
happen
all
at
once
and
in
the
way
that
we
ran
the
Russ
project
has
evolved
a
lot
over
the
years.
A
In
the
very
beginning,
things
like
when
I
started
with
2011,
we
kind
of
had
a
core
nucleus
of
four
or
five
employees,
and
we
had
this
mailing
list
where
we
would
talk
about
stuff
most
of
the
time,
and
we
had
these
work
weeks
where
we
would.
The
employees
would
get
together
in
hack
on
stuff
and
sometimes,
and
there
were
also
PRS
coming
from
the
outside,
but
I
think
a
lot
of
the
work
was
really
driven
both
design
and
implementation
by
the
employees
and
one
of
the
things
that
happen
is
even
amongst
ourselves.
A
If
you
try
to
scale
that
up
so
the
whole
internet,
you
can
imagine
that
it
starts
to
fracture
one
of
the
specific
things
we
had
that
we
found
was
sometimes
problematic
that
we
would
get
PRS
aiming
to
change
the
language,
so
a
pull
requests.
Basically,
people
would
go
and
implement
a
feature
that
they
wanted,
and
it
wasn't
necessarily
a
feature
that
we
thought
would
be
good
for
rust
as
a
whole
right.
A
It
wasn't
necessarily
following
a
coherent
design
and
these
people
might
come
from
the
community
or
sometimes
it
might
be
just
one
of
us
kind
of
going
help
on
their
own
right.
This
could
happen,
and
so,
in
around
around
the
1.0
time
frame,
we
made
a
big
change,
one
of
the
sort
of
very
consequential
change,
or
we
introduced
this
RFC
process,
which
is
basically,
if
you
want
to
make
a
big
change
to
rust.
A
There
was
a
formal
way
to
where
to
post
it
and
how
to
get
feedback
and
make
a
decision
on
whether
to
embark
on
that
change
or
not
before
our
SES
were
something
we
did,
but
it
was.
It
was
much
more
much
less
formal.
We
would
just
send
a
link
to
the
mailing
list,
and
this
was
a
great
success.
We
no
longer
got
these
random
PRS,
but
we
did
have
this
problem
that
now
we
started
to
get
kind
of
random.
A
A
For
example,
we
introduced
Russ
teams
which
are
essentially
deep,
growing
the
leadership
tremendously
so
that
we
can
keep
up
with
more
RFC's
and
we
can
have
more
input
going
way
beyond
employees
to
just
people
who
have
been
working
very
in
the
project
for
a
long
time
and
had
kind
of
accumulated
a
lot
of
wisdom,
and
we
introduced
things
like
final
comment
periods.
We'll
talk
about
some
of
the
details
here
later,
but
I
think
in
terms
of
the
the
random
RFC
problem.
A
One
of
the
big
things
we
did
was
move
to
introduced
a
roadmap
which
is
essentially
a
special
RFC
at
the
beginning
of
the
year.
That
kind
of
sets
the
agenda
and
lets
the
community
decide.
What
are
our
priority
is
going
to
be
going
forward
and
then
helps
us
to
decide
on
the
other
RFC's
and
things
that
come
up
during
the
year
and
it's
not
the
end
right.
This
is
what
we've
been
doing
so
far.
A
I
expect
we're
going
to
keep
changing
and
tweaking
our
process
and
our
procedures,
but
you
can
see
this
is
a
graph
of
the
number
of
people
and
the
rust
governance
teams,
starting
when
they
first
were
established
and
going
to
the
present
day,
and
you
can
see
the
effects
of
all
these
changes
now,
each
time
we
we
kind
of
improve
the
way
that
we
interact
with
the
community.
The
teams
grow,
bigger
and
bigger,
and
more
essentially,
the
the
number
of
participants
is
leaping
and
we're
really
happy
with
that.
A
We're
very
proud
of
it
and
I
think
it's
pretty
interesting
to
see
this
comes
up
to
over
a
hundred
here,
and
there
are
seven
employees
included
in
that
list
and
the
rest
come
from
the
outside
right.
So
that's
pretty
great.
So
that's
kind
of
the
intro
from
here
I'm
going
to
hand
it
over
to
Aaron
and
he's
going
to
talk
about
this
first,
two
sections
of
why
wasn't
I
consulted
and
articulate
the
vision,
so
each
of
these
sections
is
kind
of
a
little
catchphrase
that
we've
come
up
with
that
kind
of
summarizes.
B
You
go
again
thanks,
Nico
yeah,
so
the
structure
of
the
rest
of
the
talk
is
basically
going
back
through.
You
know
the
timeline
that
Nico
just
outlined
and
digging
into
some
of
the
formative
stories
and
and
ideas
that
we
pulled
out
of
them
that
you
know
now
constitute
part
of
Russ
governance.
So
the
the
first
lesson
that
we
learned
happened
in
the
run-up
to
rust,
1.0
around
the
time
that
we
were
starting
to
play
with
this
RFC
process
and
I
think
I
joined
the
project
right
up.
B
So
a
big
part
of
my
job
was
developing
a
process
where
the
community
could
come
together
and
actually
make
these
final
decisions
about
what
would
ship
and
I
made
some
missteps
in
the
beginning
of
that?
So
this
particular
story,
one
of
the
first
sort
of
interesting
community
experiences.
I,
had
you
know
we
we
had
developed.
You
know
the
beginnings
of
this
library
process
and
went
through
it
for
certain
api's
and
if
you've
used
rust,
you've,
probably
heard
of
unwrapped
and
we
were
proposing
to
rename
it
to
assert.
You
probably
have
opinions
about
this.
B
If
you
use
rust,
and
so
we
we
followed
this
process
that
we
had
laid
out
and
I
made
a
pull
request
and
then
I
started.
Getting
all
these
interesting
comments
on
the
pull
request,
basically
saying
wait.
A
second
like
you're
renaming
this
fundamental
thing.
When
did
this
happen,
and
also
you're
you're
pointing
to
these
guidelines
over
here
that
are
justifying
this
change,
but
you
wrote
those
and
committed
those
to
like.
B
What's
going
on,
you
know
and
being
you
know,
might
at
the
time
very
naive,
so
the
stuff
I
was
saying:
well,
we
had
a
process,
you
know
as
a
community,
we
decided
there.
We
were
going
to
do
this
thing
and-
and
we
had
a
meeting
and
in
the
meeting
we
talked
about
all
the
points
that
people
were
making
on
this
thread
and
we
came
to
this
decision
and
then
you
can
guess
what
happens
right.
B
So
if
you've,
if
you've
been
spent
any
time
on
the
Internet
in
any
kind
of
comment
forums,
you
will
have
seen
the
kind
of
explosion
that
that
can
happen
with
you
know,
with
this
kind
of
course
of
events,
so
older,
wiser,
Nico
stepped
in
and
saved
my
butt
and
basically
after
80
comments
on
this
thread
said
all
right.
We
hear
you,
we
understand
that
you
know
people
didn't
feel
like
they
had
sufficient
input,
so
we're
gonna
go
back
to
the
drawing
board
and
use
a
sort
of
more
broadcast
process.
B
With
this
request
for
comments
where
it's
very
clear,
like
okay,
this
is
under
discussion
now
here
is
the
place
to
you,
know,
state
your
opinion
and
and
weigh
in
and
we'll
reach
a
decision
there,
and
it
was
fascinating
if
you
look
back
at
this
thread
the
moment
that
nico
said
that
all
of
these
people
who
had
been
complaining,
you
know
we're
first
of
all,
grateful
but
also
expressed
like
a
sense
of
trust
in
the
rust
process
and
not
that's
a
recurring
theme
as
we
go
through
things
here.
So
of
course,
I
can't.
B
Let
nico
come
off,
looking
like
the
good
guy
here,
so
fast
forward,
a
bit
to
now,
just
a
few
months
before
1.0,
and
by
this
time
we
had
gone
through
the
vast
majority
of
the
standard
library
we
had
gotten.
You
know
pretty
good
at
at
this
process
and
other
parts
of
the
language
too,
but
there
are
a
lot
of
details
to
get
nailed
down
before
shipping.
So
there
was
this
one
particular
issue
of
what
we
called
certain
integer
types
and
the
details,
don't
really
matter,
but
it
was
something
we.
The
leadership
of
rust,
knew.
B
As
far
as
the
community
was
concerned
right
there
was
this
whole
thread
and
then
leadership,
steps
in
and
says:
we've
read
your
thread
over
here
and
we
believe
we've
come
to
a
decision
now
and
same
story.
She
massive
explosion
and
I'm
forever
indebted
to
a
member
of
the
Russ
community
Gabor,
who
has
consistently
held
our
feet
to
the
fire
and
but
Gabor.
There
was
a
pivotal
moment
in
this
story
where
he
really
articulated
the
problem
with
how
things
were
progressing,
and
it's
basically
that
we
have
this
two-level
system
of
discussion.
There's
the
community.
B
You
all
can
you
know,
talk
over
here
in
this
thread,
but
then
the
leadership
that's
actually
going
to
make
decisions.
They
don't
have
to
make
the
arguments
beforehand
in
this
thread.
They
can
kind
of
swoop
in
and
and
just
handle
hand
them
down,
and
that
didn't
feel
right
to
people
and
indeed
I
think
it
leads
to
worse
outcomes
right.
So
so
you
who
died
here
was
the
savior
in
this
case
and
basically
same
story.
We
we
stepped
back.
B
So
and
that's
not
just
you
know,
because
we
were
trying
to
please
the
community
like
we
actually
worked
through
the
debate
and
came
to
agree.
So
so
those
are
those
are
sort
of
some
background
stories
and
I'm
sure
you've
seen
similar
stories
play
out
and
communities
you've
been
involved
in
there's,
a
great
essay
called
the
web
is
a
customer
service
medium
and
by
Paul.
Ford
and
part
of
the
idea
of
this
essay
is
that,
as
as
a
kind
of
media,
the
thing
that
the
web
is
uniquely
good
at
is
answering
the
question.
B
Why
wasn't
I
consulted
okay,
like
when
people
get
really
passionate
about
the
Internet?
It
tends
to
be
around
these
kinds
of
open
forums,
fandoms
communities,
where
there's
a
sense
of
empowerment
that
you
actually
have
a
voice.
You
can
actually
have
influence,
and
you
know
there
you
can
see
this
in
a
few
lights.
On
the
one
hand,
it's
amazing
to
get
such
a
diversity
of
input.
You
know
and
we'll
talk
later
about
how
much
that
can
help.
B
On
the
other
hand,
I
think
there
is
sometimes
a
sense
of
almost
an
entitlement
that
well
my
you
know
my
opinion
that
I
came
up
with
in
five
minutes
matters
as
much
as
you
know
these
people
who
have
been
thinking
about
it
for
weeks
right.
So
it's
a
it's
a
tough
balance,
but
for
better
or
worse,
I
think
this
is
indeed
a
fundamental
part
of
life
online
and
life
in
the
open,
and
so
any
open
source
project
has
to
grapple
with
this
problem.
B
So
in
the
Rust
world,
we've
already
sort
of
started
talking
about
the
ways
that
we
tackle
consultation.
So
the
big
idea
is
the
request
for
comment
process
and
there's
been
a
an
arc
over
time
where
more
and
more
kinds
of
decisions
come
under
the
the
RFC
process.
So
you
know
it
started
just
for
court.
Language
features
then
included
library
things
and
now
we
use
it
for
talking
about.
You
know
what
web
browser
is.
Kraits
IO
should
support,
or
you
know,
community
events
even
or
you
know
all
kinds
of
things.
Anything
is
fair
game
anytime.
B
We
need
to
make
a
decision
together,
and
so
the
goal
is
you're
getting
your
inviting
input
from
the
whole
world,
which
is
very
chaotic,
and
you
know
hard
to
structure
well,
but
we
have
these
teams
that
are
the
ultimate
decision
makers
in
each
of
these
areas,
and
part
of
their
responsibility
is
to
help
guide
the
discussion
productively.
And
so
the
goal
is
not
that
everybody's
opinion
necessarily
gets
the
same.
B
In
fact,
that
usually
doesn't
happen,
but
at
least
we
agree
on
the
contours
of
the
decision,
and
at
that
point
then,
the
we'll
sort
of
start
to
head
toward
a
decision
proposed
to
move
a
certain
direction
either
accepting
or
rejecting
the
RFC
and
then,
as
a
Nico
mentioned,
there's
a
final
comment
period,
one
last
advertisement
for
to
make
sure
we
didn't.
We
don't
cause
any.
B
Why
wasn't
I
consulted
problems
and
then
a
key
lesson
with
all
of
this,
and
this
is
coming
from
those
earlier
stories,
especially
the
great
int
debate
is
that
when
the
team
does
finally
make
a
decision,
that
decision
has
to
be
based
on
argument
that
already
played
out
on
the
threat
it
can't.
You
can't
simultaneously
make
a
decision
and
be
making
brand
new
arguments
that
nobody's
had
a
chance
to
respond
to.
B
So
you
know
the
Apache
Software
Foundation
has
a
lot
of
guidance
around
how
to
run
up
in
source
projects,
and
they
talked
in
explicit
terms
about
doing
something
very
unlike
what
we're
doing
in
rust,
where,
basically,
you
contribute
just
by
you
write
some
code,
you
you
think
you
have
an
idea,
you
think
you
know
what
the
community
wants.
You
write
some
code
and
if
nobody
sees
the
code
and
it
lands,
congratulations
like
nobody
objected
it's
fine
and
then
and
the
the
rationale.
B
If
you
read
these
documents,
they
say
it's
all
under
source
control,
so
you
know
if,
if
people
get
upset
later,
you
can
back
it
out
and
me,
you
know
like
I
say
this
may
work
for
some
communities,
but
we
could
never
get
away
with
this
and
rust
Norman
or
would
we
want
to?
And
so
in
some
sense,
the
RFC
process
is
the
diametric
opposite
of
this.
It's
eager
consensus
around
all
major
decisions
and
it's
a
lot
of
work
but
I
think
for
for
us
we're
really.
B
So
that
was
the
lead
up
to
1.0
and
some
of
those
basic
lessons,
but
we
had
a
lot
more
to
learn
even
after
we
shipped
the
first
version
of
rust
and
I.
Think
a
big
part
of
what
we
had
to
learn
was
how
to
effectively
herd
cats,
and
of
course
this
is
a
common
mimin
and
open
source,
and
it
ties
back
with
you
know:
people
sending
random
PRS
in
rfcs
and
so
on,
but
I
just
I
distinctly
remember
in
the
months
after
1.0
this
feeling
of.
B
What's
next
like
as
a
community,
we
had
enormous
energy
around
shipping.
1.0
is
a
clear
goal
and
then
after
we
did
it,
there
were
so
many
things
we
could
work
on
it
and
it
was
really
unclear
what
should
happen
and
the
community
felt
this
as
well.
This
is
just
you
know,
a
tiny
smattering
of
posts
that
were
going
around
at
this
time
and
I
love.
You
know
these
put.
This
is
very
typical
right.
Somebody
comes
in
and
they're
like.
Why
is
this
entire
project
not
focused
on
my
number
one
priority?
B
I,
don't
understand,
and
of
course,
then
there
you
know
post
of
the
same
type,
arguing
for
a
completely
different
priority,
and
you
know
it
was
kind
of
a
mess.
So
I'm
gonna
pick
on
Nikko
again,
you
know
so
recognizing
this.
We
thought
well
as
the
leadership
team.
We
have
a
better
perspective
on
all
of
this,
so
clearly
we
can
write
one
of
these
posts
and
that'll
fix
it
right
and,
and
indeed
we
did
see
a
bigger
picture
than
most
of
the
other
people
that
were
complaining,
but
that
was
kind
of
the
problem.
B
B
You
can't
tell
them
what
to
do,
but
I
think
you
don't
have
to
be
fatalistic
about
this.
This
doesn't
mean
you
just
have
to
accept
that
people
are
gonna
come
in
with
random
stuff
and
you
got
to
figure
out
how
to
plug
it
in
we
try
to
sort
of
you
know,
thread
the
needle
I
guess
between
having
a
clear
direction
and
vision,
but
still
being
inclusive
to
everybody's,
individual
motivations,
and
so
that
that
comes
down
to
this
idea
of
articulating
the
vision
and
in
a
way
this
is
a
counterpoint
to
the
RFC
process
right.
B
B
So
and
again,
this
is,
in
contrast
to
show
me
the
code.
You
know
this
approach
of
everybody
should
just
write
code.
That's
all
that
matters
so
to
make
this
a
little
more
concrete
and
we
started
doing
this
around
1.0,
where
we
had
a
whole
bunch
of
blog
posts
that
had
this
shape
X
without
Y
and
there's
a
lot
of
reasons
that
that
works
well
for
rust.
But
these
these
were
pithy
slogans
that
captured
big
chunks
of
what
rust
was
about
in
a
way
that
people
could.
B
Three,
the
idea
being
fast
and
reliable
were
like
the
themes
of
1.0,
and
now
we
want
to
add
productivity
right,
and
so
you
compare
that
kind
of
slogan
to
this
miles.
Long
post,
you
know
that
we
started
out
with
after
1.0
and
I
think
this
is
just
far
more
effective
and
so
Nikko
already
mentioned
was
it
was
a
nice
poster?
B
Nikko
already
mentioned
the
the
roadmap
process
and
that's
the
way
that
we've
formalized
this
idea.
So
you
know
I
mean
there's,
there's
a
lot
of
vision,
articulation
that
happens
separately
from
this,
but
we
come
together
each
year
as
a
community
and
set
out
some
high-level
slogans.
Basically,
some
really
product
focused
and
goals
that
we
want
for
a
given
year,
and
that
sets
the
stage
for
the
RFC
process
throughout
the
rest
of
the
year.
B
And
so
the
idea
is,
if
you're,
effective
and
inspiring
people
this
way,
then
they
will
naturally
have
sort
of
itches
to
scratch
that
fall
along
these
same
dimensions
and
if
they
don't.
You
have
a
much
easier
time
saying
no
or
not
yet
right
that
this.
This
proposal
makes
sense,
but
it's
not
part
of
our
2018
focus
and
that's
that's
a
really
hard
thing:
an
open
source.
You
know,
if
you
have
a
huge
community,
how
do
you
actually
stay
focused
you?
You
only
have
so
much
design
bin
width.
B
You
can't
take
everything
and
we
use
the
RFC
process
itself
to
determine
the
road
map
and
there's
one
more
sort
of
aspect
to
to
all
of
this.
That
I've
been
thinking
about
a
lot
recently,
which
is
you
know,
despite
there's
this
tension
right,
that,
on
the
one
hand,
we
want
a
highly
inclusive,
diverse
community
and
to
reach
a
variety
of
audiences.
B
That
fundamentally
means
not
everybody's
going
to
have
the
same
values
or
interpretations
of
shared
values,
but
at
the
same
time,
it's
really
important
that
the
product,
at
the
end
of
the
day,
has
a
clearer
and
coherent
vision
right
and
so.
Balancing
between
those
two
things
is
pretty
tricky
and
the
idea
is
the
way
we
handle.
This
is
basically
by
having
the
teams
that
are,
you
know,
informally,
articulating
the
vision
and
then
formally
at
the
end
of
the
process.
B
A
It's
it's
in
one
sense
the
leaders
articulating
it,
but
it's
also
the
community
echoing
or
not
echoing
it
back,
and
then
she
and
leaders
you
know
shaping
it.
So
together
we
are
finding
what
the
vision
is
and
putting
it
into
practice
and
I
think
that's
important
to
see
that
it
goes
both
ways.
It's
not
just
top-down,
but
when
this
section
of
the
talk
I
want
to
talk
about
the
path
to
leadership-
and
this
means
a
lot
of
things
as
we'll
see-
I
mean,
but
basically
it's
about.
A
If
there
are
people
who
want
to
contribute
and
get
involved
in
the
community,
how
can
we
make
sure
that
it's
as
easy
for
them
as
possible?
How
can
we
put
as
few
roadblocks
in
their
way
and
take
whatever
energy
they
have
to
invest?
Can
we
find
a
place
and
a
way
to
channel
it,
so
that
they're
having
a
good
time
and
are
satisfied
and
the
project
is
making
progress
right
and
I
think
this
begins
sort
of
at
many
levels?
A
The
most
obvious
one
is
something
like:
how
do
you
help
someone
who
wants
to
contribute
like
a
patch
or
a
PR
and
I?
Think
many
of
us
who
have
experimented
with
open-source
projects
have
probably
at
some
point
had
the
experience
of
like
I'd
like
to
learn
how
this
works.
Let
me
go
clone
it.
Okay,
there's
a
lot
of
code
here,
you
know
maybe
I'll
look
for
main
and
then
main
is
in
a
macro
and
you
can't
actually
find
main
and
I
don't
know
like
venues.
A
They're
armed
to
go
just
I'll
go
play
a
video
game,
I,
don't
know
whatever
something
else,
and
it
applies
to
issues
right.
So
if
you
have
an
issue,
you
can't
really
read
this,
but
it's
talking
about
something
properly
named
the
exposed
memory.
Constant-
and
the
point
is:
if
you
have
an
issue
that
just
says
what
the
problem
is,
it
doesn't
give
any
hints
about
how
to
get
involved.
It's
kind
of
the
same
scenario
when
someone
wants
to
fix
this.
A
They
have
to
just
find
out
where,
in
the
code
to
go-
and
hopefully
they
know-
and
actually
one
there's
a
really
great
contributor
to
the
compiler
who
works
a
lot
on
Diagnostics,
estaban
coober
and
one
of
the
things
he
told
me
was
the
reason
he
works
on.
Diagnostics
is
because
he
can
go
to
the
issue,
find
the
error
message:
that's
not
good
and
grep
through
the
source
and
like
have
a
place
to
start
right,
and
that's
just
like
way.
Better
than
many
other
issues,
but
we
can
solve
that
problem
even
if
there's
no
string
right.
A
So
this
issue
is
actually
by
Olly
who's
right
there
and
he
didn't
stop
it
here.
He
kept
going
and
he
gave
some
instructions
on
how
to
fix
the
problem.
You
know
he
says:
look.
We
should
rename
this
variable
to
that
and
so
forth
and
sure
enough.
Just
a
few
days
after
filing
the
issue,
somebody
opened
up
ER
and
fixed
it,
and
my
experience
has
been
you
can
have
an
issue
with
no
instructions.
It
will
sit
there
for
years
easily
and
nobody
touches
it.
You
put
instructions,
it
will
get
closed.
You
know
possibly
within
hours.
A
It's
tough.
It's
happened
to
me,
so
it's
just.
It
really
makes
a
light,
a
night-and-day
difference,
right
and
I.
What
I'm
trying
to
do
now
is
well
not
just
me,
but
what
I
would
like
to
see
happen
is
is
to
push
beyond
just
instructions
in
issues,
because
often
when
you
write
those
instructions,
what
you
realize
you're
doing
is
essentially
documenting
the
code
explaining
a
sort
of
slice
of
the
code.
Here's
how
this
part
of
it
works.
A
If
you
compare
say
this
directory
listing
of
the
compiler,
which
is
kind
of
what
you
get
now,
if
you
want
to
get
an
overview
of
how
it
works
this,
this
markdown
document
with
a
table
of
contents,
you
can
already
get
a
feeling
for
how
much
more
manageable
it
feels.
Even
even
me,
who's
been
working
on
the
compiler
for
six
years.
When
I
look
at
this
table
of
contents,
I'm
suddenly
feel
like.
Oh
there.
It
is
it's
right
there.
A
It's
all
laid
out,
it
makes
sense,
and
so
that
I
think
I
hope
we
can
keep
finding
new
ways
to
kind
of
make
it
easier
to
get
involved
right,
but
does
some
extent.
This
is
like
conventional
wisdom,
right
and
I.
Think
I
don't
know
if
you're
actually
doing
this,
but
this
is
how
I
would
react
if
I
were
in
the
audience,
and
someone
was
telling
me
when
I'm
telling
them
telling
you
and
I
was
told
last
night
when
we
gave
a
dry
run
of
this
talk,
sort
of
at
the
RUS
meetup.
C
A
To
hear
this
anymore,
after
all,
honestly
I
learned
a
lot
of
this
from
people
who
are
in
the
audience
like
Josh,
Matthews
right
and
many
other
people
who
write
on
the
internet
and
so
forth,
and
so,
for
example.
This
is
the
bugs
ahoy,
a
website
that
Josh
and
others
pioneered,
and
it
helps
you
find
places
to
contribute
to
Firefox
and
we
have
similar
things
like
find
bugs
and
so
on.
But
these
problems,
a
lot
of
this
stuff
here
is,
is
actually
just
kind
of
the
first
step
right.
It's
all
oriented
it.
A
A
How
can
I
keep
keep
it
enjoyable
and
keep
them
engaged
right
and
and
to
move
on
to
becoming
a
sort
of
regular
contributor,
and
for
that
I've
been
thinking
a
lot
or
we've
been
we've
been
working
on
this
kind
of
working
group
idea,
and
the
idea
is
that
we
have
essentially
a
group,
that's
dedicated
to
producing
two
things.
First,
a
piece
of
code
or
a
goal
that
they're
trying
to
achieve,
and
secondly,
a
community
around
that
around
getting
that
done.
A
People
who
know
how
that
code
works
or
people
who've
helped
each
other
to
get
it
done
and
there's
a
lot
of
question
marks
still
on
just
what
a
working
group
should
be
and
how
it
should
function
and
I
think
we're
all
experimenting
with
different
strategies
here.
But
some
parts
seem
clearer
all
right.
A
You
want
to
have
like
a
leader
that
or
leaders
they're,
essentially
looking
for
laying
out
the
overall
strategy,
is
looking
for
opportunities
to
to
break
up
tasks
into
smaller
tasks
and
farm
them
out
and
doing
a
lot
of
mentoring
and
helping
people
to
grow
expertise.
The
idea
is
that
if
you
do
several
PRS
in
the
same
area,
several
different
contributions,
they're
kind
of
building
on
one
another
right
and
you're,
using
the
knowledge
you
had
from
the
previous
time
to
push
you
on
to
the
next
one.
A
You
want
to
have
regular
meetings
so
that
people
can
collaborate
and
have
a
sort
of
shared
channel
that
that
that
is
dedicated
to
this
working
group.
I
found
text-based
meetings
is
the
best
because
of
language
barrier
issues,
basically,
and
also
just
video
sync
is
hard
to
arrange.
But
basically
all
of
this
stuff
is
kind
of
up
in
the
air
as
I
said.
A
So
it's
essentially
like,
if
you
think
about
the
compiler
as
a
whole
or
Firefox
as
a
whole.
That
might
be
very
intimidating.
But
if
you
think
about
some
specific
part,
that
is
what
you
work
on
and
you
own
that
there's
a
very
different
feeling
right
and
that's
what
we're
shooting
for.
And
there
are
some
techniques
that
have
come
up
basically
like
strategies
for
subdividing
tasks
out.
So,
for
example,
a
quest
issue.
A
If
you
have
a
task,
which
is
not
that
hard
to
do,
but
it
has
to
be
done
many
many
many
times,
you
can
distribute
this
relatively
easily
by
writing
up
some
instructions,
making
up
a
checklist
of
all
the
places
it
needs
to
be
done
and
then
kind
of
putting
out
a
call
right
and
it's
a
great
way
to
get
people
involved.
Because
usually
these
tasks
are
like
low
barrier
to
entry.
A
It
doesn't
really
handle
all
the
hard
cases
and
you
leave
those
and
try
to
mentor
them
out
and
get
people
to
work
on
them
and
fill
them
in
and
and
basically
work
towards.
The
goal
of
this
thing
actually
working
for
real
and
along
the
way
documenting,
helps
and
other
steps,
and
this
is
proven
pretty
successful.
So
in
the
rust
compiler,
for
example,
I
think
the
mirror,
which
is
our
new
intermediate
representation,
not
so
new
anymore,
so
feels
new
to
me.
A
The
transition
to
mirror
kind
of
worked
in
this
way,
so
we
got
a
fake
PR
that
could
handle
like
hello
world
got
that
landed.
That
was
just
sort
of
me
and
maybe
Eddie
I
forget
kind
of
pushing
through
and
then
from
there
people
started
jumping
in
and
we
didn't
really
have
this
idea
as
formally
then
it
just
happened
organically
that
there
were
these
holes
and
people
wanted
to
help
and
they
started
filling
them
right,
but
it
can
be
a
really
effective
technique
and
this
stuff
starts
to
apply.
I.
Think.
A
A
This
raises
this
question,
and
this
part
of
the
talk,
I
think
is
definitely
sort
of
very
much
a
work
in
progress
trying
to
figure
out.
How
can
we
we
have
some
ideas?
You
know
that
that
are
well-known
from
from
rust
and
elsewhere
on
how
to
get
people
involved,
help
them
write
code
or
contribute
or
or
do
whatever
tasks
they're
trying
to
do,
but
can
we
distribute
this
leadership
this
top
level,
the
ones
who
kind
of
parcel
out
the
tasks
or
set
this
up
and
I?
Think
there's
really
not
a
super
easy
answer
here.
A
I
mean
some
of
it
is
leadership
takes
a
lot
of
time
and
if
you
have
volunteers,
they
don't
necessarily
have
that
time
to
put
in
so
maybe
helping
people
to
advocate
it.
Their
jobs
for
time
to
work
on
the
project,
so
forth
is
a
good
strategy,
but
that's
hard
to
do
another
thing,
though
I
mean
that's
all
things
we
would
love
to
do,
but
we
found
that
there
are
some
simpler
steps
you
can
do
that
are
also
effective.
A
If
you'd
asked
me,
then
who
is
our
release
and
kind
of
infrastructure
or
management
team
I?
Would
say:
oh,
that
was
Alex
Crichton.
He
did
all
that
and
that's
because
Alex
is
an
amazing
multitasker.
He
can
do
a
lot
of
things,
but
you
know
it
was
tiring
for
him
and
if
you
ask
that
same
question
now,
these
are
our
teams
right.
We've
built
up
two
teams
of
contributors
and
volunteers
and
they're,
led
by
respectively
simulacrum
and
Aiden
HS,
which
is
their
user
names.
A
A
We
kind
of
thought
that
was
something
nobody
would
want
to
do
and
therefore
Alex
had
to
do
it
and
it
turns
out
it's
an
interesting
task
with
a
lot
of
details
and
a
lot
of
room
to
improve,
and
actually
our
process
is
much
better
now
than
it
was.
You
know
two
years
ago,
because
we
have
all
these
creative
people
working
on
it
and
we've
been
doing
that
kind
of
across
the
board.
So
the
RUS
team
structure
started
out
fairly
flat.
A
We
had
this
core
team
and
then
a
laying
and
a
compiler
and
docks
and
libs
I
were
like
five
teams,
I
think
maybe
six,
but
now
we've
been
adding
level
and
levels
right.
So
just
on
this
slide,
which
is
not
even
complete,
remotely
complete,
I
have
I,
don't
know
10
or
something
there
are
lots
and
lots
of
teams
and
working
groups,
and
each
one
of
them
has
leaders
and
people
involved
right
and
by
making
more
levels
more
people
come
because
there's
more
space
for
them
to
fill.
A
So
this
is
a
really
important
lesson
that
we've
learned
it
I
think
another
place
where
we
use.
This
was
in
the
language
design
area.
So
the
team
that
kind
of
makes
those
decisions
traditionally
had
a
pretty
simple
structure.
There
was
like
people
who
commented
on
threads
and
RFC's
and
stuff,
and
then
there
were
the
members
of
the
team
right
and
there
were
these
two
levels
and
some
people
commented
a
lot
but
and
every
once
in
a
while.
A
Someone
would
join
the
team,
but
we
didn't
have
kind
of
roles
in
between
formal
roles
that
people
could
play,
and
so
now
we've
been
working
on
creating
some.
So
we
have,
for
example,
in
a
given
area.
We
might
have
a
meeting,
and
in
that
meeting
we
don't
invite
just
the
members
of
the
team.
We
take
the
members
of
the
team
who
care
about
that
area
and
we
take
the
people.
Who've
been
commenting
a
lot
and
making
him
cite
for
comments
about
that
area
and
bring
them
together
and
just
focus
on
that.
A
It's
kind
of
like
a
sub
informal
sub
team
right
there
right
or
we
have
a
shepherd
role
for
people
who
aren't
on
the
team
fully
but
they're
helping
to
guide
conversations
and
they
join
the
meetings
and
and
kind
of
participate
as
equals,
and
this
has
been
a
good
way
for
us
to
grow.
The
team
I
think
we
could
do
more
of
this,
but
overall
the
key.
The
key
point
is
that
we
need
to
make
and
think
about
the
paths
from
which
people
enter
the
project
and
that's
not
just
the
first
PR.
A
It's
not
just
the
second
PR.
It's
kind
of
all
the
way
as
far
as
they
are
willing
to
go.
Ideally
right.
We
would
like
them
to
go
as
far
as
they
as
they
can
in
terms
of
leadership
and
and
being
involved,
and
that
might
not
be
always
the
same
path.
So
some
people
might
start
by
writing
code
and
go
from
there
to
organizing
and
leadership.
But
there
are
other
people
for
whom
they
might
go
directly
to
kind
of
organizing
and
leadership
right.
A
The
takeaways,
basically,
is
that
put
yourself
in
the
shoes
of
someone
who's
contributing
think
about
the
paths
turn
them,
ideally
from
not
just
cow
path,
sort
of
but
actual
roads
that
are
really
easy
to
paddle
down
and
the
more
structure
you
can
give
I
think
a
certain
extent,
the
better,
because
people
will
feel
invited
to
participate
right
and,
in
particular
think
also
about
going
beyond
just
contributing
in
code
and
other
ways
that
people
contribute.
This
has
been
what's
been
really
helpful
for
us
so
now,
I'll
leave
it
to
Aaron
to
have
the
depressing
low
note.
B
Yeah
so
I
think
one
interesting
facet
of
all
of
these
lessons
we've
been
talking
about
is
they've,
created
new
batches
of
problems
that
we're
not
even
possible
before
and
they're
good
problems
to
have,
but
they
are
nonetheless
problems
and
you
know
I
think
this
is
one
you
know
for
those
of
you
involved
in
the
rest
community.
This
kind
of
thing
will
ring
true,
like
oK.
We've
got
this
great,
open,
inclusive
RFC
process,
where
we
want
to
hear
everybody's
opinion.
B
Well,
when
it's
working,
there's
a
lot
of
opinions
and
it's
just
a
huge
amount
of
work
to
try
to
Shepherd
these
discussions.
To
you
know,
distill
down
the
details
and
I
mean,
what's
amazing
to
me-
is
most
of
these
threads.
All
of
these
hundreds
of
comments,
they're.
Actually
most
of
them
are
saying
interesting
things.
It's
not
just
you
know,
people
giving
essentially
thumbs
up
thumbs
down.
B
I
mean
there's
some
of
that,
but
it's
just
a
big
scalability
problem
and
I
think
the
this
is
one
of
the
things
where
we're
wrestling
with
the
most
right
now
and
it
shows
up
in
a
few
different
guises
right.
So
one
of
them
is
RFC
threads
and
in
fact,
there's
been
one
of
these
runaway
threads
that
I've
had
to
step
in
on
this
week.
So
this
is
definitely
not
a
solved
problem,
but
there
are
other
facets
of
scaling
issues
that
we
don't
really
have.
The
answers
for
I.
B
Think
one
thing
that's
been
hard
in
rust
for
a
long
time
is
it's
such
a
big
project
with
so
many
different.
You
know
layers
and
aspects
tools,
ecosystem
and
so
on.
The
amount
that
happens
in
any
given
week
is
more
than
anyone
can
keep
up
with,
and
so
we
have
layers
and
layers
and
layers
of
ways
to
help
people
keep
up
with
this
stuff
right.
We
have
a
weekly
newsletter
this
weekend
rust.
You
know
we
have
yearly
roadmaps
and
six-month
check-ins
and
biweekly
newsletter.
B
You
know
to
make
sure
that
people
are
hearing
the
things
that
matter
to
them
and
we
we've
had
some
incidents
recently,
where
you
know
we
had
a
feature
that
was
multiple
years
in
the
making
had
gone
through
every
phase
of
the
processes
we've
been
talking
about
advertised
final
comment
periods
and
everything,
and
then
it
shipped
and
then
somebody
said
why
wasn't
I
consulted
at
the
very
end
of
that
and
they
actually
wrote
an
RFC
to
try
to
unship
the
feature
which
you
know.
We
we
shut
down
immediately
and
you
know
I
think
it
was.
B
It
was
frustrating
because
we
felt
like
okay,
we
can't
possibly
be
any
more
transparent
about
what
we're
doing
like
there's,
not
the
process
itself.
You
know
is
maxed
out
on
that
front,
so
the
problem
is
is
somewhere
else
and
and
it's
connected
to
clear
communication
and
status,
tracking
and
I.
Think
a
lot
of
this
comes
back
to
what
Nico
was
talking
about
in
the
last
section.
You
know
when
I
look
at
the
Russ
project
as
a
whole
and
I.
B
B
You
have
to
be
deeply
technical,
you
have
to
know
your
stuff,
but
if
you're
so
deeply
technical
and
you're
doing
this
as
a
volunteer,
you're,
probably
going
to
have
a
lot
better
time
like
doing
the
technical
work
right
there,
it
takes
a
special
kind
of
persons
who
want
to
do
this
kind
of
coordination,
work
and
in
their
free
time,
and
they
do
exist,
we're
finding
them
and
trying
to
figure
out
how
to
form
them.
But
well,
you
know,
because
of
the
this
kind
of
contribution
we
have
a
hard
time
keeping
things
up
to
date.
B
B
You
know
comparing
two
different
perspectives
on
open-source
maintainer
centric
perspective
and
a
community
centric
perspective,
and
you
can
guess
which
one
rust
falls
on,
but
I
think
one
of
the
insights
in
this
article
is
about
the
problems
of
successful
projects
right.
So,
if
your
user
base,
if
your
community
is
growing
exponentially,
the
only
way
to
keep
up
with
that
is
to
grow
the
maintainer
group
exponentially
and,
generally
speaking,
the
only
effective
way
to
do.
That
is
to
turn
that
growing
user
and
community
base
into
the
maintainer
Xin
to
the
leaders
right.
B
So
you
have
to
sort
of
feed
and
make
sure
that
the
the
you
know
the
the
growth
that's
causing.
The
problem
is
also
its
own
solution
and
that's
why
we
put
so
much
thought
into
these
leadership
pipelines
and
so
on,
because
it's
our
only
hope,
there's
no
other
way.
We
could
ever
keep
up
with
the
amount
of
growth,
but
as
as
Nico
was
saying,
this
is
the
sketchiest
part.
We,
you
know,
we've
added
a
lot
of
teams
in
in
recent
months
and
it's
definitely
helping,
but
we're
not
all
the
way
there
yet.
B
So,
if
you
know,
certainly
this
is
an
area.
If
any
of
you
have
experiences
or
insights
about
how
to
do
this.
We'd
love
to
hear
about
it.
Okay,
so
I
won't
spend
a
great
deal
more
time,
so
we
tried
to
boil
down.
You
know
these
lessons
into
these
succinct
slogans
that
you
can
kind
of
keep
in
your
head,
and
you
know
we
definitely
use
this
this
shorthand.
B
B
A
It
doesn't
have
to
be
that
there
is
a
clear
answer.
Basically,
it's
okay
to
say
both
of
these
seemed
pretty
reasonable,
but
you
know
we
decided
to
go
this
way.
It
usually
it's
good
if
you
can
justify
it
a
little
better
than
that.
But
if
it's
at
the
end,
it's
you
know.
If
you,
if
the
reason
is
you
think
it's
hard
to
tell
and
you're
going
to
try
it.
D
B
So
I
guess
I
have
a
slightly
different
perspective.
I
think
there
are
two
so
I
think
this
is
a
really
important
question
and
the
tension
between
this
drawn-out
decision-making
process
and
a
need
to
ship
is
one
of
the
hardest
things
that
rests.
Leadership
faces
I,
think
there
are
two
things
that
help
mitigate
this
one.
B
We
need
to
have
reached
a
decision
by
such-and-such
time
in
the
year
and
it's
it's
delicate
like
if
you
try
to
force
it
and
there's
not
enough
buy-in
that
you
can
get
into
big
trouble,
but
I
definitely
don't
think
debates
should
just
be
open
forever.
As
a
matter
of
course,
I
hate
something
really
important
that
you
can
show.
There's.
A
B
Yeah,
so
there's
not
there's
not
like
a
black-and-white
formula
for
sure-
oh
sure,
repeat
the
question
yeah,
so
that
the
question
is
basically:
are
there
any
sort
of
formal
timelines
around
the
various
parts
of
the
RFC
process?
And
the
answer
is
basically
no.
So
the
final
comment
period
itself.
That
is
a
fixed
length
of
time
it's
ten
days,
and
there
are
various
reasons
for
that.
But
you
know
this
is,
to
some
degree
an
unsolved
problem
where
people
will
write
excellent
rfcs
that
are
like
looking
way
into
the
future
and
I.
B
B
So
I
think
that
one
of
the
ideas
we
have
about
trying
to
improve
the
scaling
issues
and
so
on
is
to
basically
narrow
the
scope
of
rfcs
or
have
a
more
clear
delineation
of
like
these
are
just
discussions,
and
these
are
like
actually
in
the
RFC
pipeline
and
there's
sort
of
a
gate
to
step
into
that.
So
the.
A
Actual
process
just
to
answer
that
I
think
you
asked
what
it
was
is
that
we
have
someone
proposes
the
especial
comment
that
we
accept
or
reject,
and
they
give
a
summary
of
the
discussions
and
the
key
points
and
arguments
for
either
side
and
then
there's
a
checklist
or
the
members
of
the
team
and
when
enough
of
them
I
think
it's
all.
But
three
or
something
have
checked
off
that
they
agree.
A
So
the
question
is:
have
we
thought
about
alternatives
to
github
issues
and
PRS?
And
the
answer
is
endlessly
I
also
find
them
very
dissatisfying.
But
it's
we
haven't
yet
found
an
alternative
that
we
find
like
unbalanced,
better
but
I
think
there's
definitely
room
for
improvement,
especially
shifting
away
from
encouraging
lots
of
small,
very
fast
back-and-forth
comments
and
towards
a
sort
of
more
deliberative
style.
A
B
So
the
the
question
was
basically,
this
seems
great
for
rust.
How
adaptable
is
it
to
other
kinds
of
projects
bigger
or
smaller
and
I
I?
Don't
think
we
thought
to
too
deeply
about
this.
To
be
honest,
we're
very
focused,
but
I
think
you
know.
Certainly
the
level
of
bureaucracy
that
we
have
now
is
not
appropriate
for
early
stage,
but
the
core
themes
that
we
tried
to
pull
out
in
this
talk
of.
Why
wasn't
I
consulted
articulate
the
vision
path
to
leadership?
B
That's
the
real
part
of
this
and
I
think
those
ideas
apply
to
any
scale
of
project
and
there
are
lots
of
ways
you
can
codify
them
into
processes.
So
one
place
you
can
see
this
happening
actually
is
in
rust,
libraries
in
the
open
source
ecosystem.
You
know
they're
part
of
the
russ
community,
they're,
often
trying
to
mimic
rust
processes
to
some
degree.
So
many
of
them
have
some
kind
of
RFC
like
process,
but
it's
really
boiled
down.
You
know
it's
much
simpler,
but
they're
still
just
a
very
clear.
Oh
here's,
a
big
decision.
B
A
So
the
question
was
about
the
path
out
of
leadership
as
well
and
I.
That
has
been
on
our
minds
lately
and
you
had
a
great
post
about
it,
but
I
we've
definitely
had
people
transition
out
and
the
usual.
What
I
tell
people
when
they're
coming
in
is
basically
I
would
like
you
to
join
the
team.
You
can
at
any
point
say:
I
need
a
break
and
you'll
go
to
alumni
status
and
you're
on
alumni
status
until
you
choose
to
come
back
and
it's
kind
of
up
to
you
right,
but
and
that's
a
very
simple.