►
Description
Wondering why your open source project is struggling to turn users into contributors? Frustrated by how intimidating and opaque your favorite project is? Overwhelmed by your issue backlog? Open source projects are often focused on the shiny technical features, but investing in transparency, contributor onboarding and clear task prioritization is often the single most productive thing you can do. This talk covers fundamental strategies for project management, and discusses how to adapt them to the unique challenges presented by open source teams, large and small.
A
A
So,
no
matter
what
the
size
of
your
project
is.
You
need
to
take
project
management
seriously
if
you've
been
around
open
source,
you'll
notice
that
once
promising
projects
can
start
to
sicken,
if
you
have
poor
onboarding,
if
your
prioritization
is
unclear,
if
your
decision
making
is
bottlenecked,
your
project
is
going
to
suffer.
A
A
If
your
project
has
a
small
team,
you
might
end
up
just
stalling
out,
as
no
one
can
figure
out
how
to
help
or
to
agree
on
the
direction
that
the
project
is
going
to
take.
And
if
your
project
is
huge,
like
my
beloved
bevy
or
rust
itself,
you
might
end
up
with
a
massive
pr
backlog
and
dozens
of
competing
high
impact
projects
to
tackle
all
at
once.
A
A
A
A
A
Second,
your
team
is
distributed
all
over
the
world
working
strange
hours.
Your
work
must
be
incremental.
You
must
create
durable,
artifacts
and,
most
importantly,
your
decision
making
needs
to
be
asynchronous
and
transparent
meetings
are
exclusionary,
only
use
them
when
collaborating
on
small
pieces
of
work.
A
Finally,
and
most
importantly,
you're
leading
a
team
of
volunteers,
fascination
and
frustration
are
the
twin
driving
forces
of
open
source.
If
an
issue
is
neither
aggravating
nor
interesting,
it
will
be
neglected.
It
will
build
up
in
your
open
in
your
issue.
Tracker
and
you'll
have
an
issue
to
fix
this
small
but
kind
of
paper-cutty
bug
from
10
years
ago,
and
even
if
it's
not
hard
volunteers
are
particularly
sensitive
to
annoyances
in
your
process.
They
disappear
and
reappear
basically
at
random
and
you
if
you're
lucky
you'll,
get
even
a
day
of
warning
or
communication.
A
As
a
result,
the
critical
lesson
is
simple:
you
are
not
the
boss
as
a
project
manager.
Your
job
is
to
listen
to
and
support
your
team
not
to
tell
them
what
to
do.
This
is
doubly
true
in
open
source,
quarterly
goals.
Sprints
gantt
charts,
all
those
acronym-laden
cya
methodologies,
throw
it
out
you're,
not
overseeing
projects,
you're,
organizing
them
tiny
bugs,
will
reveal
fundamental
problems
and
cool
new
pr's
will
advise
as
if
by
spontaneous
generation.
A
If
you
want
to
bring
order
to
the
repo,
you
must
embrace
its
chaos
as
a
project
manager,
you
have
three
goals.
The
first
one
is
to
make
sure
that
all
the
brilliant
people
on
your
team
actually
talk
to
each
other.
Make
them
talk
about
what
they're
doing
make
them
ask
stakeholders
for
input,
make
them
ask
for
help
when
they're
stuck
engineers
are
remarkably
remarkably
resistant
to
talking
to
people
and
just
be
friendly,
talk
to
them,
convince
them
that
it's
okay
and
valuable
and
a
good
use
of
their
time.
A
A
So
I
like
to
joke
that
the
trick
to
successful
open
source
quadratic
management
is
exactly
the
same
as
when
you're
playing
factorio
automate
everything
your
time,
your
energy,
your
decision-making
juice,
it's
all
precious.
The
core
lesson
that
I
have
for
you
today
is
that
automation
is
not
just
code.
It's
not
just
ci!
It's
not
just
build
system.
It's
not
just
tests!
A
A
So
if
you've
worked
with
me,
you'll
know
that
documentation
is
my
favorite
form
of
automation.
If
you're
teaching
a
new
user,
how
your
api
works.
That's
time,
you
can't
get
back
if
you're
answering
questions
about
the
internals
for
a
contributor.
That's
time,
you
can't
get
back
if
you're,
trying
to
account
an
informal
design,
discussion
and
digging
through
chat
logs
on
zulip
or
discord
for
notes.
That's
time
you
can't
get
back,
stop
repeating
yourself.
Your
goal
is
to
empower
your
team
and
minimize
coordination
overhead.
It's
just
it's
just
like
just
like
writing
parallel
code.
A
A
A
A
A
So
let
your
team
help.
You
start
small
leave
good.
First
issues
open,
wait
for
feedback
on
your
pr's,
make
sure
there's
a
place
for
users
to
help
each
other,
as
you
start
to
trust
the
regulars
align
with
them
on
project
vision
and
then
hand
out
some
willpower
give
them
triage
rights.
Ask
for
the
reviews,
make
them
feel
included
and
welcome
and
important,
and
when
you're
both
ready
hand
over
some
great
permissions
and
make
watch
them
make
incredible
things.
It's
okay,
really
trust
your
team.
A
A
The
process
is
pretty
simple:
we
make
it
clear
to
our
community
that
anyone
can
review
any
pr
that
they
have
feedback
on
and,
secondly,
that
their
concerns
and
approvals
count
for
something.
This
has
three
effects.
First,
it
helps
reviewers
and
authors
learn
to
write
better
clearer
code,
docs
and
pr
descriptions.
A
A
So
I
love
this
system
because
of
the
incentives
it
creates.
We've
been
working
with
this
for
several
months
and
it's
vastly
improved
our
process
on
our
flow
and
the
incentives
that
it
creates
are.
If
you
want
your
po
merge
quickly,
you
clearly
explain
why
it's
valuable.
You
follow
conventions
and
you
keep
the
scope
small.
It's
exactly
what
you
want
out
of
all
of
your
pis
and
you
you
just
say
here's
the
easy
path.
You
could
take
the
easy
path
or
you
could
take
the
hard
path
and
everybody
chooses
the
easy
path
whenever
they
can.
A
That's
great
because
the
fine
print
when
I
signed
up
for
your
speaker
says
that
I
need
at
least
one
slide
singing
virtues
or
they'll.
Never
invite
me
back
so
to
satisfy
that
that
checklist,
we're
going
to
talk
about
classical
automation,
ci
build
systems.
All
of
that.
So
what's
my
number
one
tip
to
make
your
code
more
reliable
and
your
pi
is
easier
to
review.
A
It's
actually
genuinely.
I
swear
to
god.
Why
didn't
rust,
so
the
biochakra
is
great.
The
type
systems
are
great.
The
enums
are
especially
great.
Oh
my
god
use
enums
everywhere
in
your
code.
Whenever
you
can
rust,
has
this
remarkable
if
it
compiles
it
works
properly,
and
in
my
experience
it
actually
is
true.
We
can
put
a
tremendous
amount
of
trust
in
incredibly
complex
projects
from
people.
A
We've
never
met
before
if
they
have
good
tests,
if
they
have,
if
their
code
compiles,
because
the
language
helps
you
build
correct
code
so
alongside
west,
there
are
a
few
tools
that
I
love
to
use
shout
out
to
the
cargo
team,
in
particular,
cargo
format,
coco
clippy
and
cargo
test
are
all
fantastic.
These
are
the
best.
These
are
some
of
the
best
tools
set
them
up
on
all
of
your
projects
and
slowly
refine
and
iterate
on
them.
You
can
clean
up
your
code.
You
can
reduce
bike
shedding.
A
One
of
if
a
robot
is
complaining
about
something
that's
trivial
to
fix
trivial,
it
should
be
trivial
to
fix
if
you
have
a
failure
in
code
that
you
didn't
touch
like
this,
that
blocking
your
api,
this
sucks
so
much
dude.
I
hate
it
dead,
link,
dead,
link,
checking
if
any
of
you
guys
have
played
around
with
that
is
atrocious.
It's
that's
one
of
the
things
where
you
have
to
be
very
careful
about
how
exactly
you
set
it
up.
A
So
I'm
going
to
talk.
Finally,
in
terms
of
concrete
stuff,
I'm
going
to
talk
about
the
bits
of
project
management
that
software's
a
service
company,
try
and
sell
you.
So
this
is
the
tools
that
you
can
use
to
organize
work.
The
stuff
I
mostly
use
github,
but
these
are
the
these
are
the
organizational
tools.
So
there
are
four
tools
that
I
really
love
and
I
think
you
should
be
using
so
the
first
one
is.
A
I
think
you
should
be
using
labels
for
your
issues
and
your
for
your
priors
they're,
so
useful,
they're,
so
versatile.
They
should
be
the
first
thing
that
you
reach
for
define,
think
about.
Think
about
your
needs,
define
a
set
that
meets
them
and
just
just
slap
them
on
there
hand
out
triage
right.
Super
super
aggressively,
like
everybody
who
is
has
contributed
to
your
project,
should
have
triage
rights.
You
can
use
them
for
a
search
tag.
You
can
use
them
for
for
importance
and
difficulty
management.
A
You
can
use
them
for
okay,
where
is
this
through
the
process?
They're,
fantastic
and
but
think
about
and
customize
your
workflows
there.
So
the
next
suggestion
I
have
is
issue
and
pr
templates.
These
are.
These
are
fantastic
spend
some
time
by
chatting
by
shutting
it.
We
do
switch
in
there,
but
they
allow
you
to
get
really
consistent,
really
consistent
information
from
you
from
your
team.
Without
remembering
okay.
What
do
I
need
to
actually
include
in
this?
What
what
makes
a
good
issue?
What
makes
a?
A
A
The
next
suggestion
is
to
use
milestones,
use
milestones
and,
in
particular,
use
train
releases.
What
we'd
like
to
do
is
we
like
to
say?
Okay
here,
are
all
of
the
cool
things
that
we
would
like
and
you
you
just
stick
them
in
the
milestone
and
let
the
orgs
say
let
the
contributors
as
a
whole
say
here
are
the
things
that
I
think
would
be
cool,
cool
the
land
and
then
go
and
shape
them
and
figure
out.
Here's
the
stuff
that
fits
together.
A
Here's
what
we're
gonna
make
and
do
not
make
them
promises.
You
are
a
team
of
volunteers.
Do
not
ever
ever
ever
make
promises
about
timelines,
especially
not
when
you
have
a
fixed
scope.
You
you
do
not
want
to
be
working
overtime
on
a
team
of
volunteers,
and
that
includes,
if
you
have
a
project
of
one,
you
are
also
a
volunteer.
A
A
So
when
we're
thinking
about
these
tools,
I
really
like
to
think
about
user
stories.
I
like
to
think
about
what
who's
using
this.
What
are
they
trying
to
do,
and
how
can
we
automate
automate
this
to
improve
friction?
It's
don't
just
say:
okay,
we're
going
to
go
and
we're
going
to
add
a
we're
going
to
add
this
new
process.
It's
going
to
be
great,
like
actually
think
through
your
needs
think
through
what?
What
can
we
replace?
How
can
we
consolidate
it?
How
can
we
keep
this
organized?
A
So
this
is
fun.
I
hope
I've
convinced
you
that
your
open
source
repo
should
have
a
project
manager
or
should
have
put
some
thought
into
it.
Wear
that
hat
sometimes,
but
a
question
that
I
often
get
is
great.
I'm
sold.
I
want
a
product
manager.
How
do
I
get
one?
If,
if
you're
a
team
of
volunteers,
you
need
to
attract
product
managers
by
communicating
that
you
need
a
project
manager?
This
is
a
critical
first
step,
but
is
often
often
neglected.
A
Like
talk
to
your
community,
put
in
an
announcement
saying:
hey
we're
looking
for
people
who
need
project
management
work
and
especially
communicate
that
they
don't
need
to
be
the
smartest
most
technical,
most
most
adept
person.
They
can
be
new
to
the
project
and
they
can
still
do
an
effective
job
doing
project
management
work.
A
Second,
you
need
to
give
you
need
to
empower
this
your
product
managers
and
make
it
clear
that,
as
the
maintainer
as
the
as
the
tech
lead
that
they
have
your
blessing
to
do
this
work,
you
need
to
you
need
to
make
sure
that
your
team
trusts
them
and
and
communicates
through
them
whenever
like
or
when.
That's
helpful,
their
job
isn't
to
make
decisions.
A
It's
to
gather
the
information
needed
to
make
decisions
next,
having
a
solid
existing
process
that
you
can
train
them
on
that
they
can
hook
into
this,
helps
them
so
so
much
to
get
started
if
you
all
that
stuff
from
before,
if
you're
a
single,
if
you're
a
single
maintainer
project
or
just
very
small
team
starting
to
scale
up,
get
that
right
first
and
then
say:
okay,
I
want
to
train
you've
been
a
great
great
contributor.
You
have
you
seem
like
you
have
strong
organizational
skills.
A
A
So,
in
conclusion,
let's
pull
this
together.
What
does
my
shiny
future
for
open
source
projects?
Look
like
so
the
first
we
start
by
building
a
class
of
empowered,
technically
fluent
team
members
that
are
doing
project
management
work.
These
may
be
classical
project
managers-
these
maybe
technical
members
who
are
coming
in
and
saying
okay.
I
want
to
take
on
some
of
this
work.
These
may
be
fresh
college
grads
who
are
like
man.
I
really
wish
I
had
a
career
in
project
management,
but
nobody
will
hire
me
without
experience
these.
A
These
people
are
focused
on
improving
processes
on
teaching
and
on
communicating
between
teams.
They're
not
focused
on
deadlines,
they're
not
focused
on
reports
and
by
providing
by
focusing
on
these
well-scoped
areas.
They
can
build
expertise,
provide
continuity
of
knowledge
and
slowly
organize
and
shepherd
the
work
in
order
to
do
so,
they're
going
to
need
to
work
closely
with
others
they're
going
to
need
to
work
closely
with
the
folks
writing.
A
Docs
they're,
going
to
be
working
with
the
ci
team,
they're
going
to
be
onboarding
new
contributors,
they're
going
to
automate
away,
friction
and
make
sure
the
human
side
of
your
organization,
as
we
talked
about
in
one
of
our
keynotes,
can
scale
effectively
and,
as
a
result,
all
of
the
wonderful
open
source
contributors
that
we
already
have.
The
brilliant.
The
brilliant
tech
nerds
can
focus
on
those
fascinating
and
frustrating
problems.
They
can
be
have
work,
that's
nicely
defined,
nicely
scoped
and
say
okay.
A
This
is
this
is
what
it
means
for
this
to
be
done
and
they
can
actually
complete
work.
They
can't.
Then
you
want
to
try
to
make
sure
that
if,
if
somebody
gets
stuck,
if
a,
if
somebody
has
has
to
go
away
that
you
can
actually
complete
the
task
and
actually
deliver
value
to
as
a
as
a
package,
an
open
source
project
manager
is
a
force
multiplier
by
improving
processes
and
gathering
information
into
the
one
right
place.
We
can
help
domain
experts
and
the
community
actually
make
decisions.
A
So
I'll
be
taking
I'll
be
taking
questions
in
a
little
bit
in
discord.
I
I
currently
do
bevi
full-time
as
as
an
open
source
maintainer,
I'm
currently
funded
by
github
sponsors.
So
if
you
guys
are
like
that
was
great,
I
I
wanna
tip
you
like
go
ahead
and
also,
if
you're
a
company
and
you're
like
wow.
That
was
great.
I
wish
on
my
processes,
work
that
smoothly.
Send
me
an
email.
A
I
do
consulting
work
so
a
little
bit
about
the
projects
that
I
work
on,
so
I'm
actually
maintaining
of
two
two
open
source
projects
and
they
work
really
differently,
and
I
want
to
talk
to
you
a
little
bit
about
them
to
show
you
that
these
lessons
can
apply.
Basically,
no
matter
what
scale
you
are
so
bevy
is
the
exciting
one.
This
is
an
ecs
first
west
game
engine.
A
The
wonderful
project
leads,
saw
that
and
says:
okay,
you
know
what
you're
going
to
become
an
official
maintainer
and
I've
been
helping
out
all
the
tech
side
and
merging
emerging
pis
and
so
on
too
so
at
large
skills.
This
is
invaluable,
like
this
is
essential.
You
will
just
you,
will
just
choke
and
you
will
struggle
so
so
much
and
your
contributors
are
going
to
get
fed
up
and
you
usually
be
like
okay.
A
Well,
what
about
this
change
like
and
your
maintainers
are
going
to
burn
out,
but
even
if
you're
small,
it's
this
product
management
work
is
really
valuable.
It
helps
attract
contributors,
it
helps
make
them
feel
welcome.
It
helps
make
everything
run
smoothly
and
it
allows
you
to
maintain
side
projects
without
spending
all
of
your
time
shepherding
and
teaching
people.
So
the
other
one
that
I
the
other
project
that
I'm
working
on
is
taffy,
which
is
a
pure
glass,
ui,
layout
library.
A
So
things
like
things
like
flexbox,
css,
squid,
more
experimental
stuff
and
what
we
did
is.
I
collaborated
with
the
dioxis
ui
team
to
fork
and
resurrect
a
a
version
of
an
abandoned,
vc-backed
crate
and
it's
it's
a
wonderful
little
project,
but
it's
very
very
different
from
bevy.
It's
quiet,
it's
thoughtful!
A
It's
principled
and
again
these
skills
and
these
practices
work
really
well
there,
because
you
you
allow
you
allow
it
to
to
take
up
less
of
your
time
and
you
will
you
make
it
so
much
easier
for
people
to
just
jump
in
and
get
started
and
submit
small
fixes
so
anyways,
if
you
guys
have
any
questions
I'll
be
on
discord
and
then
afterwards
I'll
be
over
there
and
I'd
love
to
chat
with
you.
If
you
guys
have
have
questions
about
product
management.