►
From YouTube: Rust governance - Ryan Levick - EuroRust 2022
Description
Ryan Levick
Principal Rust Developer Advocate at Microsoft
The Rust project is a globally distributed collection of hundreds of individuals who all have different reasons for dedicating various amounts of time and energy in service of making Rust a great programming language. Despite (or maybe because of) this unique constellation of motivation, perspectives, and backgrounds, complex technical and organizational decisions get made every single day. But how is all of this coordinated?
In this talk, we’ll explore the inner workings of Rust project governance. We’ll dive into the unique features and challenges associated with Rust’s distributed and consensus oriented decision-making process, and we’ll try to form an understanding of what makes one of the largest and most complex open-source projects tick. By the end, you’ll have a better understanding of what makes open source at scale so challenging, and you’ll be better prepared to engage meaningfully in discussions about how the Rust project can and should be run in the future.
A
A
So
if
you
know
nothing
about
how
the
rust
project,
governance
Works,
hopefully
by
the
end
of
this
talk,
you'll
you'll
be
a
little
bit
more
up
to
date.
But
before
we
get
started,
I'd
like
to
talk
a
little
bit
about
who
I
am
I'm.
Ryan
I
work
at
Microsoft
as
a
developer,
Advocate
focusing
on
rusts
full-time,
and
you
can
find
me
on
Twitter
or
on
zulup,
under
rylev
and
or
sorry
Twitter,
Ryan
underscore
Levick
and
GitHub
and
zulup
eidenreitlev,
unfortunately,
just
couldn't
make
it
all
work
all
right.
A
It's
also
important
to
know
who
I'm
not
or
at
least
who
I'm
not
for
today,
so
today,
I'm
not
going
to
be
representing
the
project
I'm,
not
talking
on
half
of
rust
project
leadership,
I'm
just
talking
with
me.
These
are
my
ideas,
but
I've
been
talking
with
other
people
in
the
project
a
lot
about
this
stuff.
So
hopefully,
it's
not
coming
from
left
base.
A
Another
disclaimer,
because
this
thing
needs
to
have
lots
of
disclaimers
in
it-
is
that
rust
project
governance
is
in
flux
and
an
RFC
is
currently
in
works.
So
if
you're
watching
this
in
the
future
on
a
recording,
hello
future,
some
of
this
might
not
be
fully
correct,
but
that's
fine,
so
real
quick
raise
of
hands
from
those
in
the
audience
who
here
has
ever
contributed
to
anything
under
the
rust
Lang
GitHub
organization
before
all
right.
Quite
a
few
people.
A
Anybody
here
not
done
that,
but
would
maybe
like
to
at
some
point:
yeah:
okay,
that's
like
basically
everybody
in
the
room.
So
for
everybody
in
the
room.
This
talk
is
actually
pretty
important
to
you
because
we're
talking
about
governance
of
the
rust
project,
but
wait.
What
does
governance
actually
mean?
A
I
could
give
you
some
Wikipedia
definition
of
governance
or
something
like
that,
but
I
think
I'll
explain
it
like
this
in
the
rust
project.
We
work
on
the
Russ
language,
the
Russ
compiler
core,
tooling,
like
cargo
rust
up
crates.io,
so
on
and
so
forth,
and
all
of
that
is
kind
of
deeply
technical
work.
But
then
there's
a
bunch
of
other
stuff
that
happens
to
make
sure
that
that
work
can
get
done,
and
most
of
that
is
governance.
We
are
governing
the
project,
so
I
have
a
couple
of
goals
for
today.
A
Some
are
altruistic
and
others
are
maybe
a
little
bit
more
devious.
I'll
start
with
the
altruistic
ones.
The
key
to
good
governance,
to
making
sure
that
the
project
runs
well,
is
accountability
and
all
of
you,
in
the
room
and
out
there
on
the
internet,
are
holding
the
the
project
the
rust
project
accountable.
A
But
you
can't
just
do
that
by
screaming
on
Twitter.
That's
not
a
good
way
to
do
it.
In
order
to
do
that,
you
need
to
be
informed
informed
about
what
governance
is.
What
is
needed
for
good
governance,
how
governance
in
the
rest,
project
actually
works,
and
so
that's
the
goal
of
today
is
to
inform
everybody
a
little
bit
about
how
governance
in
the
rust
project
works.
A
So
here's
my
hot
take
for
today
at
the
end
of
the
day.
Basically,
all
problems
in
the
rust
project
are
governance
problems.
So
we're
just
talking
about
problems
on
problems
on
problems
today,
unfortunately,
we
won't
really
get
into
Solutions.
That's
for
another
talk,
but
I'd
love
to
talk
to
you
about
Solutions
afterwards
as
well.
A
A
We
have
teams
in
the
rust
project
that
are
in
charge
of
certain
things.
They
have
their
purview,
for
instance
the
Lang
team
or
the
language
team.
They
are
in
charge
of
the
rust
language,
so,
at
the
end
of
the
day,
they're
the
ones
that
decide
what
gets
into
the
language
and
what
is
not
a
part
of
of
rust.
Now
this
happens
through
Community
involvement.
Rfcs
has
anybody
here
opened
an
RFC
to
change
the
language
itself
before
yeah?
A
We
have
a
few
people
here
so,
and
that
is
a
community
driven
process,
but
at
the
end
of
the
day,
it's
the
Ling
team.
That
decides
whether
to
say
yes
or
say
no
and
the
Lang
team
can
have
sub
teams
that
are
involved
with
it.
So,
for
instance,
a
newly
formed
team
is
the
style
team.
The
style
team
is
a
offshoot
of
what
was
Rus
format.
Rust
format
continues
to
exist
as
the
tool,
but
the
style
team
now
makes
all
those
fun
bike
shedding
decisions
of
how
to
actually
style
rust.
A
What
are
the
rules
for
styling
rusts?
The
rust
format
will
go
ahead
and
implement,
and
the
link
team
can
have
several
other
teams
and
does
have
several
other
sub
teams,
and
there
are
a
lot
of
other
teams
like
Lang.
Then
there
are
teams
like
the
devtools
team,
which
in
and
of
itself
is
not
incredibly
active.
It's
more
there
to
group
a
bunch
of
teams
together.
A
A
The
core
team
is
a
sort
of
support
structure
and
all
the
other
teams
are
our
core
teams
to
the
project,
but
are
not
the
core
team
themselves,
hopefully
we'll
make
that
a
little
less
confusing
in
the
future
and
then,
in
addition
to
teams,
you
have
Ace.
If
you
have
working
groups,
and
these
working
groups
are
sort
of
in
charge
of
domains
that
are
not
specific
to
the
rest
project,
but
are
some
kind
of
collection
of
things
that
you
do
with
rust.
A
For
instance,
the
async
working
group
is
a
working
group
that
works
on
the
async
programming
model
and
and
rust,
and
these
these
working
groups
have
kind
of
looser
ties
to
various
teams.
For
instance,
they
think
working
group
has
a
connection
to
the
Lang
team.
They
make
suggestions
to
the
Lang
team,
maybe
even
open
rfcs
and
things
like
that
and,
of
course
the
link
team
then
makes
decisions
about
what
actually
gets
into
the
the
language,
and
all
of
this
all
together
forms
the
rust
project.
A
A
So
the
Russ
foundation
and
the
rust
project
are
two
separate
entities
from
it,
which
is
differs
from
some
other
open
source
communities
and
the
foundation
is
in
charge
of
sort
of
Financial
and
legal
support
for
the
project
and
what
I've
painted
here
is
kind
of
the
neatest
version
of
all
that
there's
a
whole
bunch
of
complexity
and
kind
of
messiness
that
we'll
touch
on
a
little
bit
today.
That
makes
some
of
this
a
little
less
confusing
or
a
little
more
confusing
in
practice.
A
So
what
are
pros
and
cons
of
the
way
that
we
currently
do
governance
and
rust?
Well,
we
have
autonomous
teams
and
rusts,
which
is
a
really
great
thing.
These
teams
can
be
in
charge
of
their
own
section
of
the
project
and
and
work
on
that
relatively
independent
of
each
other,
and
they
don't
have
to
go
to
some
centralized
Authority
to
to
get
kind
of
say
on
whether
something
is
okay
or
not.
A
So,
for
instance,
the
Lang
team
or
the
compiler
team
get
to
work
on
their
section
of
the
project
and
get
to
be
and
get
to
own
their
section
of
the
project,
and
what
this
means
is
that
this
promotes
ownership
by
experts,
so
those
who
are
closest
to
what
they're
working
on
are
the
ones
who
actually
own
that
thing,
and
this
also
means
there's
no
single
point
of
failure.
So
if
one
team
kind
of
goes
off
the
rails
and
does
something
that
they
shouldn't
do,
that
doesn't
mean
that
the
entire
project
falls
down.
A
We
don't
have
to
do
a
ton
of
coordination
between
things,
so
everything
can
move
quickly
and
and
easily
and
at
the
end
of
the
day,
it
prevents
consolidation
of
power,
which
is
always
a
tricky
thing
to
talk
about
in
open
source.
But
you
know,
sometimes
people
want
to
have
ideas
for
something
and
they
want
to
take
it
a
certain
way.
Our
governance
system
make
sure
that
no
one
really
can
do
that.
We
are
all
in
this
together,
but
there
are
some
cons
to
how
we
do
things.
A
A
It's
hard
to
coordinate
each
team
is
moving
independently
and
sometimes
they
don't
talk
to
each
other,
even
when
they
should.
You
end
up
repeating
work
between
teams,
because
because
each
team
is
working
independently,
they
might
have
problems
that
are
similar
between
themselves,
but
they
don't
really
talk
and
solve
those
problems
together.
They
each
individually
solve
those
problems.
That's
not
really
great,
and
this
all
makes
cross-domain
work
harder.
A
So
it
means
that
when
some
problem
needs
to
involve
multiple
teams,
it
ends
up
not
really
involving
them
or
makes
working
these
teams
working
together
a
bit
a
bit
harder
and
at
the
end
of
the
day,
this
favor
is
work
done
by
what
I
like
to
call
heroes
or
of
motivated
individuals.
So
it's
kind
of
between
teams.
You
have
several
people
on
the
project
who
are
have
just
been
there,
a
long
time
and
seemingly
have
eight
days
a
week
and
30
hours
a
day
to
work
on
Rust
and
they
do
a
lot
of
work.
A
But
that's
not
good,
that's
not
good,
because
it
leads
to
burnout.
It
leads
to
kind
of
knowledge
siloing,
where
a
few
individuals
are
having
an
outsized
impact
instead
of
being
able
to
share
in
that
impact
with
others
all
right.
So
the
status
quo
of
rust
governance
is
that
in
general,
rust
has
a
solid
base.
I'm,
not
here,
to
tell
you
that
rest
is
about
to
fail
tomorrow.
That's
not
the
case.
We
have
a
solid
base
of
for
governance
in
the
project,
but
the
strength
of
that
governance
is
within
teams.
A
A
So
now
I'm
going
to
go
through
several
situations,
sort
of
kind
of
play
along
and
see
what
you
would
do
in
these
situations.
How
you
think
rust
governance
models
should
handle
certain
things,
so
the
first
situation
we're
going
to
talk
about
is
a
compiler
change.
A
member
of
the
compiler
team
wants
to
change
how
some
internal
piece
of
the
compiler
works.
Well,
what
happens?
Let's
talk
about
the
decision
here.
This
decision
impacts
the
compiler
team
and
not
really
anyone
else.
A
Of
course
you
know
if
there's
a
bug
or
something
like
that,
it
will
impact
everybody,
but
how
the
compiler
is
organized,
how
it's
factored
that's
a
compiler
team
decision.
They
don't
really
need
to
involve
others
in
that
decision
making
process,
because
at
the
end
of
the
day,
it's
usually
pretty
reversible.
If
somebody
makes
a
mistake
and
how
they've
Factor
the
compiler,
they
probably
can
reverse
it,
even
though
it's
not
always
easy
in
practice-
and
this
is
like
squarely
in
the
charter
of
the
compiler
team,
the
compiler
team
is
in
charge
of
the
compiler.
A
A
A
But
it's
still
squarely
in
the
Lang
Teams
Charter.
They
they
were
formed
in
order
to
make
these
types
of
decisions
and
it's
not
really
reversible.
Once
something
gets
into
the
language
backwards,
compatibility
means
we
can't
take
it
out.
So
these
are
high-stakes
questions
here
and
it
needs
broad
buy-in.
So
if
everybody
in
this
room,
even
if
you're
not
on
the
link
team
hates
the
decision,
then
it's
probably
a
bad
decision,
funneling
team,
but
this
also
means
that
every
it
gets
a
lot
of
Engagement
from
the
community.
A
But
now,
let's
focus
on
a
couple
of
of
situations
where
that's
not
so
clear
what
we've
talked
about
so
far
is
kind
of
the
best
case
we
have
that
handled.
This
is
the
core
of
what
we
do
in
the
rest
project
and
we
do
it
pretty.
Well,
that's
good,
but
what
happens
when
you
have
something
like
a
licensing
issue,
so
a
contributor
opens
a
PR
that
adds
support
for
a
proprietary
game
system
and
this
change
might
violate
patent
law
could
get
actually
the
rust
project
in
legal
trouble.
What
happens
then?
A
Well
something
about
this
decision.
This
decision
is
technical.
It
has
to
do
with
adding
support
into
a
compiler,
but
it's
also
legal
as
well
and
I.
Don't
know,
I,
don't
believe
there
are
any
lawyers
involved
in
the
the
rust
project
or
at
least
on
the
compiler
team,
but
it
impacts
the
entire
project.
So
if
something
goes
wrong
here,
this
could
put
rust
itself
in
jeopardy
and
it's
not
really
reversible.
A
If
so,
if
you
bring
the
the
change
into
the
compiler,
and
then
somebody
says
whoops,
that
was
not
actually
legal
to
do
well,
you
know
it's
kind
of
passed
and
we
might
still
face
the
consequences
and
most
people-
probably
don't
really
care
about
this.
Like
you
know,
if
you're
not
building
I,
don't
know
games
for
the
Nintendo
switch
or
something
like
that,
then
you
don't
really
care.
A
You
know
whether
there's
support
for
that
in
the
compiler
or
not,
but
some
people
really
really
really
care
like
so
much
that
they
might
get
very
angry
if
something
doesn't
go
their
way,
and
this
brings
me
to
my
first
law
of
governance.
Most
people
don't
care
about
governance
until
they
really
really
really
care
about
governance,
and
that's
the
challenge
at
the
end
of
the
day
is
making
sure
that
when
everything
is
going
fine,
you
do
the
right
thing
and
you
don't
end
up
in
situations
where
you
have
people
beating
down
your
door.
A
A
A
A
So
what
is
the
Project's
policy
for
enforcing
trademarks?
The
decision
here
again
impacts
the
entire
Community.
It's
kind
of
core
to
the
question
of
what
is
rust
and
that
feels
like
a
very
important
question
right.
What
is
rust
is
something
that
we
really
should
have
a
handle
on,
but
it's
not
really
urgent
right.
We
don't
have
a
ton
of
people
kind
of
knocking
down
our
door
and
saying
you
we,
you
know,
want
to
use
the
name
rust.
A
What's
the
the
trademark
policy,
although
that's
changing
with
each
day,
and
so
at
the
end
of
the
day,
who
makes
this
decision
about
what
the
trademark
policy
is?
A
lot
of
people
on
the
project
are
too
busy
to
do
the
Urgent
work
that
the
project
needs.
So
what
about
this
non-urgent
work
and,
in
fact,
if
we
get
to
a
point
where
we
actually
really
do
need
a
trademark
policy,
it's
probably
already
too
late.
We
should
have
had
one
to
begin
with.
A
It's
not
really
in
the
charter
of
any
existing
team,
except
for
core,
but
even
then
that's
not
really
kind
of
we're
not
really
sure
how
to
handle
stuff
like
that.
This
kind
of
brings
me
to
my
second
law
of
governance
here.
The
hardest
problems
in
governance
are
the
important
ones
that
are
not
urgent
and
these
end
up
kind
of
sitting
there
until
it's
too
late,
and
you
end
up
having
issues.
A
Okay,
let's
move
on
to
a
collaboration
issue,
an
issue
with
a
project
member
who's,
not
violating
the
code
of
conduct.
So
this
is
not
a
a
contributor
who's
doing
something
really
horrible,
but
they're,
just
frankly,
not
that
great
to
work
with
they
might
exhaust
others.
They
don't
have
the
best
style
of
collaboration.
A
This
decision
is
tough
because
it's
sensitive
and
draining
it's
hard
to
tell
other
people
you're,
just
not
that
fun
to
work
with
right.
It's
often
easier
to
just
avoid
conflict.
Well,
I,
don't
like
working
with
person
X,
so
I'll
just
go
work
on
something
else,
and
that's
also
not
really
great.
We
should
be
professional
in
the
rust
project.
A
We
should
be
able
to
give
each
other
feedback,
be
constructive,
make
others
in
the
project
better
make
ourselves
better,
but
who
has
the
authority
to
comment
on
someone's
Behavior
if
I
tell
you
that
you're,
not
that
fun
to
work
with
you
might
go?
Who
the
heck?
Are
you
to
say
that
that's
not
very
nice
I'm
here
as
a
volunteer
and
really
at
the
end
of
the
day
we
do
all
of
our
work
in
public
or
most
of
our
work.
A
In
public-
and
this
can
encourage
bullying,
so
if
somebody's
not
that
fun
to
work
with
and
I
say
they're,
not
that
fun
to
work
with
and
then
500
other
people
say
yeah
they're,
a
real.
That's,
that's
not
good
right.
That's
probably
too
much
of
a
response
for
what
that
person
actually
did.
So
we
have
to
figure
out
a
way
to
give
feedback
in
a
constructive
way
that
doesn't
end
up
making
people
feel
terrible
or
actually
be
the
targets
of
online
harassment.
A
So
who
makes
the
decision
about
how
to
handle
this?
We
have
a
moderation
team,
but
this
isn't
code
of
conduct,
violation,
it's
something
much
more
subtle
and
we
need
to
coordinate
these
efforts
so
that
we
don't
end
up
dog
piling
on
this
person
and
there's
not
really
training
out
there.
This
is
something
that
open
source
in
general
really
struggles
with.
So
how
do
we
get
better?
A
It's
the
same
issue
as
most
quote-unquote
non-technical
work
in
the
project.
Folks
are
volunteering
usually
for
technical
reasons
they
want
to
hack
on
the
compiler.
They
want
to
work
on
cargo.
They
want
to
think
about
language,
changes
and
stuff.
They
don't
normally
contribute
to
open
source,
to
manage
people
or
to
help
with
people
problems,
but
there's
a
whole
heck
of
a
lot
of
people
problems
in
the
rust
project.
We
need
more
people
who
can
do
this
stuff,
but
we
don't
really
welcome
them
into
the
project
as
much
as
we
should
all
right.
A
What
about
getting
input
from
to
to
the
foundation?
So
the
foundation
needs
project
input
on
some
public
initiative
that
they're
working
on,
maybe
with
some
sponsorship
money
or
something
like
that,
and
this
project
has
project
wide
consequences.
It
will
affect
the
rust
project
as
whole,
so
identifying
stakeholders
here
is
really
really
hard.
Who
does
the
foundation
actually
talk
to
who's
in
charge
of
the
thing
who
must
be
consulted?
A
The
the
foundation
can
do
the
try
to
do
the
right
thing
and
talk
to
as
many
people
as
possible,
but
it
would
be
really
nice
to
be
able
to
tell
the
foundation
staff.
These
are
the
stakeholders
that
must
be
consulted
on
this
decision
and
sometimes
that's
hard
to
answer
when
the
governance
layout
is
not
so
clear.
A
So
who
makes
this
decision
this
really
strikes
at
the
heart
of
who
speaks
for
the
project?
Who
is
rust?
What
people
are
rust
and
certain
decisions
also
have
this?
Who
is
the
language
team?
Who
is
in
charge
of
the
language
who
is
in
charge
of
the
compiler
who's
in
charge
of
rustup
who's
in
charge
of
the
trademark
policy?
A
So
what
does
rest
governance
need
then?
Well,
we
need
to
keep
some
things.
We
want
to
keep
independent
and
autonomous
teams.
We
want
some
centralized
leadership
so
that
work
that
spans
across
the
project
has
a
place
to
go
and
be
sought
about.
We
need
this
to
keep
flexibility
that
we
have
and
we
want
to
have
as
little
bureaucracy
as
possible,
because
you
know
who
wants
to
spend
their
time
working
in
a
bureaucratic
mess.
I,
certainly
don't,
but
we
need
a
lot
more
of
some
things.
We
need
more
across
team
collaboration.
A
So
what
do
we
keep?
We
want
to
keep
independent
autonomous
teams.
We
want
to
maintain
this
flexibility
and
we
want
little
bureaucracy,
and
what
do
we
need?
More
of.
We
need
more
cross-team
collaboration,
more
accountability
and
a
more
understandable
structure,
but
there
are
plenty
of
failure
modes
that
we
could
run
into
here.
We
could,
just
frankly,
not
find
people
who
are
excited
about
working
on
project
management
or
administrative
work.
That's
not
always
a
given.
A
We
might
lack
accountability
for
our
leadership.
We
might
have
project
leadership,
that's
detached
from
the
problems
of
the
project,
which
is
not
great
as
well,
and
we
might
end
up
with
the
leadership.
That's
overwhelmed
with
the
problems
of
the
project
and
feel
like
they
don't
have
the
support
that
they
need
in
order
to
work
through
those
issues
we
might
lack
delegated
authority.
A
This
is
sort
of
related
to
the
previous
point,
where
we
don't
end
up
giving
others
this
say
and
what
they're
working
on
and
we
try
to
centralize
that
decision
making
in
a
few
small
people.
That's
not
good.
We
might
lack
some
transparency,
and
this
is
my
third
law
of
governance.
Everyone,
literally
everyone,
including
myself,
underestimates
how
hard
transparency
is.
Transparency
sounds
great.
A
A
It
might
not
hurt
tomorrow,
but
it
could
hurt
really
really
badly
in
the
future.
So
I'm
going
to
give
a
whole
lot
of
thanks
to
everybody
here
for
listening
to
a
talk
about
open
source
governance,
you
did
it.
Thank
you
very
much.
I
also
want
to
thank
everybody
in
the
rust
project
leaders
in
the
rest
project,
who
were
happy
with
me,
giving
this
presentation
and
representing
some
of
the
views
of
that
leadership.