►
From YouTube: Rust's Community Automation - CodeConf 2016
Description
Presented by E. Dunham
Rust is a systems programming language that runs blazingly fast, prevents segfaults, and guarantees thread safety. Behind the scenes, Rust is also a community that nurtures new contributors, consistently enforces its code of conduct, and maintains a high-quality codebase. This talk will discuss the implementation details, as well as the social motivations and effects, of the customized infrastructure and workflow practices which allow the small core team to have such a significant impact.
About CodeConf
CodeConf improves the software community by providing a forum for thought-provoking talks and forging social connections. The fourth installment of the CodeConf series took place in Hollywood in 2016. This year's event focused on systems engineering projects, practices, and programs in the open source community.
For more information on this year's CodeConf, go to:
https://codeconf.com/
A
A
There
we
go
and
I'm
here
to
talk
about
the
automations
that
we've
put
in
place
in
the
rest
community.
We're
just
gonna,
mirror
all
of
our
displacement.
Sorry
about
that
now
there
we
have
it
okay,
so
you
can
get
these
slides
at
that
URL
if
there
will
be
a
bunch
of
URLs
in
them
and
they
go
by
fast.
So
I
would
encourage
you
not
to
try
to
take
all
of
the
notes,
but
instead
grab
a
photo
of
that
and
look
them
up
later.
A
You
are
welcome
to
ask
me
any
questions
you
have
on
Twitter
emails,
IRC,
whatever
is
convenient
so
and
as
herman
just
taught
you
about
anyone
who
just
came
in
the
room
and
might
not
know
rust.
It's
a
programming
language
designed
to
be
safe,
concurrent
and
fast,
we've
been
stable
for
just
over
a
year
now
1.0
came
out
on
may
15
2015.
A
You
might
have
heard
of
it,
because
it
was
the
most
loved
language
in
stack
overflows.
Recent
developer
survey,
with
almost
80
percent
of
respondents,
saying
yes,
rust,
is
awesome,
the
rest
community.
You
can
engage
with
us
on
all
of
these
media
and
more,
and
we
have
a
variety
of
automation.
Tools
that
help
us
have.
A
relatively
small
team
managed
a
relatively
huge
community
without
a
lot
of
the
problems
that
I've
seen
before
other
projects.
A
A
Show
you
those
second,
so
the
first
process
that
I've
seen
helps
shape
the
rest
community
and
help
prevent
a
variety
of
problems.
Is
the
incredibly
high
expectations
that
people
have
of
it?
You
can
say
it's
a
bad
thing.
You
can
say
it's
a
good
thing,
but
like
it
or
not,
the
community
is
cold,
our
not
so
secret
weapon.
People
say
the
community
is
populated
entirely
by
human
beings.
I
have
no
idea
how
this
was
done.
Well,
these
these
tools
and
techniques
are
how
it
was
done
and
so
setting
those
high
expectations
makes.
A
It
makes
you
think
twice
before
you
snap
at
a
newbie
who
asks
a
common
question,
makes
you
think
twice
before
you
make
a
comments
that
might
sound
misinterpreted
because
you
know
I'm,
a
member
of
the
rest
community,
we're
famous
for
being
welcoming
the
next
and
probably
the
bedrock
of
the
entire
rest
community.
Is
this
code
of
conduct?
It's
not
a
whole
lot
of
words.
You
can
fit
it
on
one
page.
If
you
don't
mind
a
small
font,
the
first
blurb
is
the
roles
that
we
absolutely
expect
everyone
to
adhere
to
and
the
larger
blurb.
A
A
You
can't
post
on
our
subreddit
without
it
in
a
big
banner
in
your
face,
hey
remember,
code
of
conduct,
something
your
first
three
posts
on
the
forums
which
we
use
instead
of
a
mailing
list,
will
tell
you
how
to
make
a
good
post,
give
you
a
few
suggestions
and
remind
you
of
the
code
of
conduct
and
can't
get
an
IRC
without
seeing
as
well.
So
the
result
of
having
this
from
the
very
beginning
is
that
some
people
are
excluded.
A
There
are
some
people
who
don't
want
to
work
in
the
way
that
the
code
of
conduct
specify-
and
this
is
one
of
their
reviews
of
it.
They
say
the
community
gives
me
a
bad
feeling,
the
tyrannical
they
have
a
moderation
attack
squad
and
the
sets
off
warning
alarms.
We
have
excluded
this
person.
I
would
give
them
credit
for
that
wonderful
quote,
but
unfortunately
they
posted
it
as
anonymous
coward.
A
We
are
missing
out
on
whatever
technical
skills
they
may
bring
to
the
table,
but
in
exchange
we
get
the
technical
skills
of
everyone
who
might
have
been
driven
away
by
the
flame
war
type
behavior.
That
people
who
violently
dislike
codes
of
conduct
often
tend
to
engage
in
for
what
it's
worth
in
over
a
year
now
engaging
with
the
rest
community
pretty
much
all
the
time,
I've
never
seen
a
conversation
that
I
would
describe
as
a
flame
war.
So
another
piece
of
process
that
helps
automate
the
way
we
work
together
is
mandatory
communication
about
design
changes.
A
So
no
one
expects
that
you
can
do
a
big,
refactor
or
add
a
big
new
feature
without
talking
about
it.
First,
because
all
major
changes
go
through
the
request
for
comment
or
RFC
process
in
the
sublet
in
Hubli
pub
that
I've
linked
right
there
and
I
have
a
theory
that
the
more
time
and
energy
and
effort
is
put
into
something
the
worse.
It
hurts
to
get
told.
No,
that's
not
the
direction.
We
want
to
take
things.
A
No,
we
don't
want
that
for
the
thing
that
you
built
it
for
so
the
way
I
see
the
RFC
process
functioning
socially.
Is
that
it
helps
us
catch
ideas
that
won't
work
super
early,
so
that
you've
only
invested
a
little
bit
of
time,
and
so
it
doesn't
bother
you
nearly
as
much
to
have
to
change
it
or
to
be
told.
No.
This
is
the
direction
we're
going,
whereas
I've
seen
a
lot
of
other
communities.
Stay,
pull
requests
welcomed
as
a
way
to
defer
those
design
conversations.
A
Someone
comes
back
in
a
few
months
with
a
fully
formed
feature,
and
then
you
have
to
talk
about.
No,
this
isn't
our
direction
and
that
really
hurt
to
be
told
that
you're
months
of
work
are
a
value
to
the
project,
so
RFC's
helped
with
that.
And
finally,
we
have
this
cultural
habit
in
the
rest
community.
A
That
starts
out
in
the
core
team
and
seems
to
trickle
down
to
most
of
its
projects
of
calling
out
people
with
appreciation
for
them
when
they
do
things
that
stand
out
when
they
do
things
that
go
above
and
beyond
our
this
weekend,
rest
newsletter
and
the
official
blog
will
sometimes
call
out
person
who's
a
friend
of
the
tree,
the
tree
in
this
case,
meaning
the
rest
repository.
This
is
just
someone
who's
done,
something
that
might
not
be
super
well
recognized.
Maybe
they
retry
us
all
of
the
old
issues.
A
Maybe
did
some
nasty
code
cleanups
that
nobody
wanted
to
touch
and
we
publicly
thank
these
people
because
otherwise
they
might
go
unrecognized.
So
this
is
basically
how
the
process
part
the
social
bits
of
the
rest
community
help
make
students
work
more
smoothly
and
work.
Well,
we
set
high
expectations.
We
actively
exclude
people
who
won't
resolve
their
disputes,
their
moderation
who
demand
verbal
trial
by
combat
instead
of
polite
discussion.
A
So
if
you
get
the
chance
to
be
in
at
the
ground
floor,
I
would
strongly
recommend
making
sure
that
you
have
the
processes
that
you're
going
to
want
to
see
later,
like
you
cannot
overstate
the
importance
of
starting
out
with
the
community
values
that
you
hope,
you'll
see
down
the
line.
So
this
brings
us
to
the
robots.
A
They
are
a
variety
of
tools
and
processes
that
literally
do
mundane
tasks
for
us
and
they're
part
of
they
are
part
of
how
such
a
small
main
team,
with
relatively
little
people
hours
to
spend
on
the
project,
get
a
lot
done
and
interact
with
a
lot
of
part-time
community
members
before
I.
Tell
you
about
our
most
important
robot.
We
need
to
take
a
quick
trip
into
history.
A
Great,
the
original
author
of
rust
was
a
software
engineer
for
many
years
and
came
up
with
a
principle
about
how
code
repositories
should
be
managed
that
he
calls
the
not
rocket
science
role
of
software
engineering.
The
not
rocket
science
rule
simply
says
you
should
automatically
maintain
a
repository
of
code
that
always
passes
all
the
tests.
How
many
of
you
by
show
of
hands,
have
worked
on
a
repo
that
automatically
was
kept,
always
pass
all
the
tests,
a
few
people,
maybe
a
quarter
of
the
audience?
A
How
many
of
you
have
worked
on
a
repo
where
you
really
wish
that
it
was
forced
to
pass
the
test
before
you
converge
code?
Yet
just
about
everybody.
So
this
sounds
deceptively
simple
and
it's
quite
a
big
culture
shift
to
say
no,
we
can't
merge
until
we
fix
the
code
or
six
attempts.
Fortunately,
we
have
a
bot
to
help
us
enforce
this.
A
The
way
the
rest
project
enforces,
the
not
rocket
science
rule
is
bot
named
Boris,
who
is
an
underlying
code,
was
rewritten
to
be
more
scalable
and
in
a
project
named
homo,
but
his
account
name
is
still
Boris
because
historical
reasons.
So
what
he
does
is,
after
someone
reviews
the
PR
and
says
yes,
this
should
land
in
our
part
of
that's
an
AR
plus
he
figures
out
what
the
tree
will
look
like
what
the
best
events
will
look
like
after
that
pull
request
has
landed.
A
He
runs
with
yes,
all
the
tests
on
that
and
if
all
of
the
tests
pass,
he
merges
automatically.
He
fast
forwards,
master
to
that
state
that
he
just
tested
now,
if
it
doesn't
pass,
then
he
says
oh
no
got
to
go
back.
Gotta.
Try
that
again,
you
need
to
fix
these
things
and
as
well
as
guaranteeing
that
every
merge
commit
all
of
the
tests
pass.
This
creates
an
interesting
social
dynamic.
A
So
I
was
a
little
surprised
by
when
I
first
noticed
that
happening
Osun
when
you
have
a
gatekeeper
or
maintainer
and
then
a
bunch
of
new
contributors
trying
to
get
code
in
it
becomes
a
kind
of
a
confrontational.
You
versus
me
saying
it
I'm,
not
my
code
in
well
I
want
my
repos
quality
to
stay
up
and
it's
kind
of
an
unpleasant
interaction
to
have,
whereas
when
it's
a
robot
instead
of
a
person
saying
no,
it
goes
from
me
against
you
to
us
against
them,
and
it's
not.
A
A
So
if
you
want
this
kind
of
automation-
and
you
don't
want
to
run
your
own
boards
or
your
own
home,
there
are
a
couple
of
things
that
it's
pretty
easy
to
do,
for
free,
first
set
up
continuous
integration.
If
your
repo
is
public
and
you
have
any
tests,
you
have
almost
no
excuse
not
to
run
at
least
some
of
them.
Whenever
you
can
and
github
has
recently
rolled
out
a
protected
branches
feature
where
you
can
say,
no
one
can
force
push
to
the
sprint
pushes
are
our
pull?
A
Requests
are
only
allowed
to
merge
if
the
checks
that
I've
set
up,
such
as
continuous
integration
have
passed,
and
you
can
require
the
branches
to
be
up
to
date,
which
gets
you
almost
all
the
way
to
what
we
have
with
boards.
I'm,
pretty
sure
someone
malicious
could
construct
a
degenerate
case
where
you
sneak
some
bad
code
in
the
boards
would
have
caught,
but
it
would
be
kind
of
tricky.
So
that's
your
free
and
easy
way
to
get
most
of
the
not
rocket
science
rule
applied
to
your
project.
A
Oh
yeah
I
thought
that
was
cool
a
long
time
ago
now
everything's
it
rotted,
and
then
they
just
kind
of
leave.
So
we
felt
that
problem
with
a
bot
that
says
hi.
It
is
high-five
and
what
hi-5
does
is
twofold
for
every
pull
request
high-fives
make
sure
that
there's
a
reviewer
assigned
and
mags
that
reviewer
to
actually
take
a
look
at
it
and
also
high-fives,
will
check
the
list
of
contributors
to
that
repo.
A
And
if
the
person
submitting
the
pull
request
has
not
got
any
commits
in
the
tree,
yet
they
get
a
special
welcome
message:
saying:
hey
here's,
the
contribution
instructions,
here's
some
answers!
You
might
need
right
now
we're
glad
to
have
you
on
board
and
you
always
get
that
message
within
minutes
of
submitting
your
pull
request
rather
than
having
to
wait.
So
what
can
you
do
if
you
don't
want
to
run
your
own
high-five?
A
First
github
has
recently
rolled
out
pull
request
templates.
You
can
set
a
template
that
says:
hi.
Welcome.
Have
you
done
these
things
that
we
always
need
to
check
on
pull
requests?
Don't
get
your
part
of
the
way
there?
The
other
major
thing
that
hi-5
does
is
nags
us
to
remember
to
actually
take
a
look
when
it's
time
to
review,
so
I
would
strongly
recommend
setting
up
hooks
in
whatever
version
control
system
you're
using
to
nag
you
on
email
or
IRC.
Someplace
you'll
actually
check
it
when
someone
submits
a
pull
request,
so
taking
another
step
back.
A
What
about
those
potential
contributors
who
don't
even
get
as
far
as
a
pull
request?
Who
need
some
more
help
and
need
some
more
mentorship?
We
get
especially
a
lot
of
those
in
rust
and
in
the
survey
browser
engine,
because
there's
such
high
profile
interesting
projects,
people
go
wow.
This
is
a
really
impressive
thing
to
work
on.
A
I
want
to
get
started,
but
how
the
old
fashioned
way
of
handling
this,
what
you
might
still
do
is
you
have
everybody,
has
their
own
kind
of
personal
list
of
bugs
that
they
care
about
that
they
think
would
be
good
for
a
new
contributor
and
depending
on
who
you
ask
you'll
get
a
different
bucket,
might
or
might
not
still
be
a
problem,
and
it's
generally
a
lot
of
overhead
for
project
developers.
Who'd
rather
be
fixing
the
code.
A
So
the
way
we've
solved
this
for
both
rust
and
servo,
is
to
automatically
scrape
various
tags
on
the
issue
tracker
and
provide
a
nice
friendly
approachable
list
of
the
issues
tagged
with
them.
This
obviously
relies
heavily
on
how
well
you've
triaged
your
code,
but
it
also
incentivizes
us
to
do
better
triage
because
it's
not
just
a
label
for
us,
it's
a
label
for
everyone
who
might
come
into
the
project.
A
So
you
can
check
out
rest
starters
if
you're
going
to
fork,
one
of
these
for
your
own
use,
I
would
recommend
forking
from
service
our
instance.
They
have
some
more
cool
features
in
it.
So
far,
another
thing
to
add
this
was
just
written
by
a
community
member
who
thought
it
would
be
a
full
thing
for
us
to
have
this
wasn't
a
full-timer
on
the
project
at
all,
and
so
how
do
you
get
a
thing
kind
of?
Like
starters?
A
Let's
say
you
don't
want
to
spin
one
up,
let's
say
you're
doing
an
open
project
and
you
want
to
pipeline
more
people
in
from
the
get-go.
The
first
thing
you
need
to
do
before
adding
your
issues
to
any
of
these
aggregators
is
going
to
be
make
sure
your
repos
looks
good
when
someone
comes
in
through
the
issue
tracker.
Maybe
contributors
are
usually
funneled
in
through
your
website,
which
links
to
the
wiki
and
the
docs,
or
something
like
that.
A
But
if
you
put
your
issues
out
for
the
world,
people
are
going
to
go
to
the
repo
and
try
to
find
their
way
from
there.
So
make
sure
your
readme
is
up-to-date.
Make
sure
you
have
a
contributing
guide
that
up-to-date
with
who
to
contact
where
to
communicate
with
your
project,
how
to
ask
and
then
once
you're
sure
that
somebody
popping
in
on
an
issue
will
be
able
to
find
their
way
around
reasonably
well
see
about
your
issue.
A
Tags
make
sure
you're
contributing
guide
includes
how
to
tag
issues
correctly
and
how
to
triage
them,
because
if
you
submit
your
project
to
code,
triage
com,
helpful
bystanders,
maybe
a
few
of
the
people
who
see
your
project,
there
will
wonder
through
and
help
you
triage
your
issues
once
your
issues
are
Trina
as
well,
you
can
get
useful
work
out
of
this
variety
of
other
sites,
which
pagers
are
different.
Demographics,
different
levels
of
experience,
but
they're
all
focused
on
helping
people
find
new,
open
source
projects
to
contribute
to
check
them
out.
A
Also,
if
you
are
looking
for
code
to
write
there,
they're
pretty
cool,
so
basically
the
things
I
want
you
to
take
home
about
the
robot
is
that
the
most
important
thing
for
fast
development
that
rest
has
done
is
automatically
maintain
a
repository
of
code
that
always
passes
all
the
tests.
That's
not
rocket.
Science.
Rule,
it's
not
rocket
science,
although
it's
quite
difficult
to
do
in
practice.
Welcome
and
guide
your
new
contributors.
A
This
may
sound
like
an
open
source
specific
thing,
but
even
if
you're
working
on
an
internal
proprietary
project
handled
medium
to
large
company,
maybe
balled
over
an
accounting
has
asked
you
to
teach
him
some
web
diff
stuff.
If
you
can
point
them
as
an
easy
tags
issue,
then
suddenly
you
might
have
another
contributor
on
your
team
and
again
Marc
and
share
your
introductory
bugs.
If
you
have
a
nice
tracker
for
those
introductory
bugs
it
can
even
motivate
you
to
be
better
at
your
code
triage
because
you
get
some
reward
from
having
done
that
triage.
A
So
there
we
go
I
just
think
we
have
time
for
questions,
although
we'll
be
letting
you
go
to
lunch
with
a
minute
to
spare
you're
welcome
to
grab
a
copy
of
my
slides
with
all
of
the
links
that
I've
shown
you
tweet
at
me
or
ask
me
any
rust
or
community
related
question.
I
won't
know
all
of
them,
but
I
will
probably
know
who
to
ask
to
find
an
answer
and
I
like
learning
new
things.