►
Description
Presented by E. Dunham, Mozilla
The Servo browser engine, written in Rust, is a Mozilla initiative to test novel approaches to rendering the web and build components to improve Firefox. This talk is a tour through the infrastructure that powers Servo's development, showing how the project leverages GitHub to build a welcoming and highly productive international community. After this talk you'll understand how Servo gets the most out of GitHub and hopefully be inspired to improve your own projects with ideas from our tooling and culture as well.
About GitHub Universe:
GitHub Universe is a two-day conference dedicated to the creativity and curiosity of the largest software community in the world. Sessions cover topics from team culture to open source software across industries and technologies.
For more information on GitHub Universe, check the website:
https://githubuniverse.com
A
Good
morning,
everybody
welcome
to
the
second
day
of
github
universe
and
if
I
could
ask
all
of
you
who
are
sitting
right
on
the
end
of
an
aisle
to
do
me
a
huge
favor.
Could
you
scoot
in
buy
a
couple
of
seats
if
there's
space,
because
we
might
have
some
people
trickling
in
throughout
the
talk
just
a
real,
quick
warning?
One
of
my
slides
late
in
the
Dec
has
a
picture
of
a
scorpion.
A
If
you
don't
want
to
look
at
a
scorpion,
I'll
tell
you
beforehand
and
then
you
can
look
away
and
then
I'll
tell
you
when
to
look
back
it'll
be
fine,
so
we're
going
to
talk
about
building
a
better
browser
engine
on
github
and
first
I'm
going
to
start
with.
Why
are
you
listening
to
me?
So
I
am
the
dev
ops
engineer
for
Mozilla
research.
This
means
that
I
get
to
wear
a
whole
bunch
of
different
hats,
depending
on
the
circumstances.
A
Some
of
these
include
ops
for
us
to
the
programming
language,
ops
for
servo
the
browser
engine
whose
community
I'm
going
to
be
talking
about
today
and
recently
virtual
and
augmented
reality,
which
we
call
mixed
reality.
Of
course,
this
is
a
highly
opinionated
talk
and
the
opinions
are
mine,
not
necessarily
Mozilla's,
well,
the
good
ones
they
can
take
the
credit
for
any
of
them.
You
disagree
with
I'll.
A
Take
the
credit
for
those
I
have
worked
on
project
as
an
ops
person
as
a
developer
and
as
a
community
manager
and
community
member
project
on
and
off
github
through
the
years
and
projects
that
have
been
both
really
good
and
really
less
than
good.
Also,
thank
you
to
dexter
github.com
for
having
fantastic,
octo
cats
that
will
make
the
slides
better
as
we
go
along
so
I'm,
just
curious
about
who
we've
got
in
the
room
today
who
here
uses
software
cool?
Some
of
you
are
awake
most
of
you're,
awake,
fantastic.
A
Who
here,
contributes
to
any
kind
of
software
closed
or
open,
show
a
hands
most
of
you,
fantastic
and
who
here
maintains
software
like
it's
kind
of
your
responsibility,
people
will
get
grumpy
at
you
if
it
breaks
so,
though,
two-thirds
three-quarters,
so
all
that
software
that
you're
involved
with
for
how
many
of
you
does.
It
include
community-driven,
free
and
open
source
software.
So
maybe
a
quarter
third
live
room.
A
A
Once
upon
a
time
there
was
an
engineer,
I'm
gonna
call
him
Graydon,
because
that's
what
he's
called
he
worked
at
Mozilla
and
his
job
was:
writing
a
bunch
of
C
and
C++
code
to
fix,
bugs
and
add
features
in
a
browser
engine
just
like
how
a
compiler
turns
stuff
for
people
and
stuff
for
computers.
The
browser
engine
is
that
thing
in
your
web
browser
that
turns
the
stuff
for
computer
is
the
HTML,
the
CSS,
the
JavaScript
into
the
stuff
that
you
as
a
person
look
at.
A
Grayden
noticed
that
when
he
and
his
colleagues
wrote
say
in
C++
the
language
made,
it
really
easy
to
introduce
all
kinds
of
errors.
You
can
point
your
pointers
at
values
that
they
have
no
business
pointing
at.
If
you
want
to
make
sure
you
return
the
right
type
of
data,
you
have
to
memorize
things
about
very
distant
points
in
the
codebase
and
in
general.
A
This
daunting
task
of
building
this
fast
modern
browser
engine
is
made
even
more
difficult,
because
the
tools,
weren't
helping
great
and
solution
to
this
problem
was
to
try
to
build
a
new
language
that
would
make
it
harder
to
make
these
categories
of
mistakes,
make
it
easier
to
write
good
systems
code
and
more
difficult
to
break
the
rules.
So
he
works
on
this
language
that
ended
up
being
called
rust
and
he
took
this
project
to
his
employer
Mozilla
and
they
were
like
wow.
This
is
a
fantastic
idea.
A
We
need
this,
so
they
paid
him
to
put
more
time
into
it,
hired
on
some
more
people
to
pay
them
to
work
on
it
and
eventually
the
rest
project
has
grown
to
be
a
whole
team.
However,
it
ends
at
its
heart
a
community-driven
project,
because
you
don't
necessarily
want
a
programming
language
to
be
owned
by
a
single
company
for
it
to
be
useful
for
others.
So
the
enthusiasm
of
this
community
shows
in
that
state
of
the
OP
diverse
report
that
we
looked
at
yesterday.
A
This
is
the
first
of
a
whole
lot
of
interruptions
at
yesterday's
keynote
has
put
into
less
otherwise
perfectly
well
planned,
taught
we're
about
number
8
there
on
the
projects,
with
the
most
reviews
in
2017,
hugely
active,
hugely
open
project,
so
rust,
1.0,
this
first
stable
rest
was
released
in
May
of
2015
and
since
then,
a
new
stable
that
crits
compatible
with
all
the
old
ones
has
come
out
every
six
weeks
like
clockwork.
There
was
one
this
morning
because
they
release
every
six
weeks
on
thursdays
and
that's
121.
A
So
rust
is
an
outstanding
piece
of
software,
but
above
and
beyond
just
being
a
piece
of
software,
it's
also
remarkable
as
an
open
source
community
project.
Only
a
few
of
you
might
ever
need
to
write
safe
systems
code
but
omit
almost
everyone
here.
It
gets
involved
with
a
software
project
at
some
time
or
another,
so
to
understand
where
servos
coming
from
I
want
to
highlight
a
few
of
the
things
that
set
the
rest
community
and
project
structure
apart.
A
First
off
the
rest
community
is
pretty
famous
this
I
love.
This
quote,
the
rest
community
seems
to
be
populated
entirely
by
human
beings.
I
have
no
idea
how
this
was
done.
Well,
I
have
several
very
clear
ideas
about
how
this
was
done.
Basically,
you
get
the
right
people
to
opt
in,
and
you
make
sure
that
the
people
who
don't
want
to
work
that
way
opt
outs,
rust,
prioritizes,
constructive,
positive
interaction
and
has
done
since
the
project
started.
A
So
those
who
feel
that
they
need
a
really
combative
environment
or
negative
environment
to
get
work
then
either
opt
out
or
we
help
them
along
and
discourage
them
from
behaving
that
way
in
our
forums.
So,
starting
with
this
base
of
shared
values,
guarantees
that
we
all
have
common
ground
to
build
better
code
on
additionally,
rust
is
an
internationally
distributed
project,
so
most
of
its
communication
is
asynchronous
and
held
in
public
forums.
A
Starting
with
these
really
good
community
habits
means
that
projects
implemented
in
rest
by
people
who
are
and
enjoy
being
in
the
rest
community
tend
to
also
share
those
values
they
trickle
downstream
or
downhill,
and
they
tend
to
have
fewer
of
the
anti
patterns
that
are
often
common
in
open-source
anyways.
We've
got
this
fantastic
language.
Mozilla
is
putting
a
bunch
of
resources
behind
it
and
it
was
invented
to
improve
systems
programming
how
the
heck
do
you
tell
when
your
language
is
doing
what
you
want?
How
can
you
test
a
language
as
it
grows?
A
Our
answer
is
that
we
have
this
flagship
product
written
in
rust
and
that's
Mozilla
servo
browser
engine
servo
is
a
project
to
make
a
highly
parallel.
Incredibly
fast
browser
engine
by
starting
from
scratch,
the
team
has
this
opportunity
to
re-implement
the
most
important
parts
of
the
web's
functionality.
First,
at
the
same
time,
for
the
really
complicated
stuff
or
the
heirloom
stuff
that
you
hardly
need
anymore,
we
can
either
leave
it
out
or
fail
over
to
the
old
browser
engine
and
yet
have
something.
A
That's
super
fast
on
most
of
the
web
pages
that
everyone
cares
about,
as
well
as
offering
thought
leadership
in
mean
technology.
Servo
is
pushing
the
boundaries
of
what's
possible
for
parallelizing
how
the
browser
renders
the
web,
the
servo
project
as
an
open
source
project,
is
holding
its
own
in
the
octave
verse
rankings
as
well.
There
we
are
at
number
9
beating
out
ansible
for
most
discussed
yeah,
that
the
servo
logo
I
was
not
kidding
about
the
memes
someday,
someone
in
branding
might
notice
and
it
might
change,
but
until
now
that
means
servo.
A
So
what's
up
with
the
servo
thing,
I
think
that
servo
is
in
a
really
unique
place,
because
it's
unequivocally
a
corporate
prod.
Its
purpose
is
for
Mozilla
to
explore
possibilities
for
the
next
generation
of
browser
engine
and
build
components
that
can
be
shipped
in
Firefox,
which
were
already
doing,
but
at
the
same
time
as
being
owned
and
directed
by
a
company.
It's
a
really
healthy
open-source
software
community.
A
I've
provided
various
types
of
dev
and
ops
support
to
all
kinds
of
projects
over
the
years
and
servo
uses
a
handful
of
tricks
that
I
wish
everybody
else
did
too
that's
the
ulterior
motive
for
giving
this
talk.
I
hope
that
our
ideas
can
make
development
deployment
and
community
interaction
easier
for
whatever
project
you're
working
on
so
I'm,
going
to
walk
you
through
what
I
consider
the
five
success
strategies
that
I've
seen
servo
using
to
get
to
where
it
is
today
each
of
these
builds
on
the
next.
A
The
advanced
techniques
that
I've
placed
at
the
top
of
this
pyramid
will
do
you
little
good
and
might
even
hurt
your
community
if
you
just
jump
straight
into
them
without
having
the
Foundation's
below
so
for
each
of
these,
if
I
were
the
kind
of
person
who
gave
quizzes
at
the
end
of
the
hour,
I
hope
you'll
be
able
to
answer
what
we're
doing.
Why
we're
doing
it?
How
we
did
it
and
how
you
can
too,
the
first
way
that
we
build
a
better
browser
engine.
A
Is
we
build
it
in
public,
we're
Mozilla
ins,
the
Internet
as
a
global
public
resource
open
and
accessible
to
all
is
core
company
value,
and
it's
tough,
if
not
impossible,
to
build
an
open
web
on
top
of
a
closed
platform,
but
building
in
public
is
not
just
about
the
moral
aspect
of
it.
Coding
and
public
keeps
you
honest.
You
act
differently
when
you
know
that
somebody's
watching
in
any
project
there's
this
pressure
to
make
the
code
work
and
the
pressure
to
write
it
fast
and
without
any
other
constraints.
A
That
will
be
exactly
what
you
get
fast
working
are
quickly
built
working
code,
not
necessarily
maintainable,
not
necessarily
something
that
you
can
be
proud
of.
We
even
keep
our
infrastructure
configuration
code
on
github
and
it's
attracted
volunteers
who
are
pros
of
saltstack,
which
is
our
tool
of
choice.
So
when
you
add
those
people
who
care
about
it
and
are
watching
in
public
into
the
feedback
loop,
it
completely
stops
those
up
yolo
good
enough
for
today
and
for
changes
that
it
would
be
hard
to
justify
not
making.
If
everything
was
closed
in
secret.
A
Why
do
we
code
in
public
on
github
and
github
is
how
we
do
this?
So
servo
made
it
for
three
years
between
the
first
commit
to
the
codebase
and
when
I
came
in
on
board
as
its
first
and
so
far
only
dedicated
ops
person.
This
is
partly
because
the
developers
are
fantastic,
but
they
couldn't
have
done
it
as
well,
without
a
free,
turnkey
code
hosting
platform.
For
us
that
happened
to
me
in
github.
A
Github
is
not
the
only
platform
that
matches
that
description,
and
it
wasn't
even
the
only
option
that
then,
but
it
has
this
one
huge
selling
point
pretty
much.
Everybody
is
already
there.
So
setting
up
a
new
contributor
couldn't
be
easier
whenever
a
project
rolls
its
own
code
hosting
or
picks
something
uncommon,
less
popular.
There
adds
this
barrier
for
entry
to
would
be
drive-by
contributors
who
might
end
up
growing
into
a
core
person.
A
If
you
require
somebody
to
set
up
a
new
account
or
hope
they
already
have
the
account
that
you
want
them
to
use
for
OAuth,
you
are
slowing
them
down
and
deterring
them
from
just
jumping
in
and
getting
involved.
Plus
your
contributors
alternate
often
come
pre-trained
on
the
tooling
you're,
using
from
their
involvement
in
other
projects,
and
when
you
train
a
contributor,
it
then
benefits
everything
else.
They'll
go
on
to
touch
on
the
same
platform.
That's
a
network
effect
that
would
disappear
if
everybody
scattered
into
their
own
custom
thing.
So
that's
how
we're
coding
in
public!
A
How
can
you
especially
if
it's
an
internal
thing
that
others
aren't
supposed
to
look
about
coding
in
public
means
figuring
out
how
to
get
the
most
eyes
on
your
code?
Make
it
easy
for
people
to
look
at
what
you're
working
on
and
ask
questions
about
it?
You
might
only
share
within
your
company.
You
might
be
able
to
share
some
of
your
code
with
the
world
if
you
have
secrets
scattered
throughout
your
code,
that
you
can't
even
share
outside
your
team.
A
That
is
a
huge
problem
that
you
need
to
address
in
order
to
have
sound
reliable
code
going
forward
and
then,
as
you
do,
your
development
do
it
as
if
you
expect
to
be
asked
questions.
This
means
focus
on
better
Doc's,
better
comments,
fewer
ugly
hacks
throughout
it,
even
if
nobody-
but
you
ever
reads
that
code-
your
future
self
will
be
grateful,
but
coding
in
public
isn't
enough.
You
have
to
write
good
code
code
that
works
well
and
can
be
developed
quickly.
A
You
can't
talk
about
any
Russ
project
infrastructure
and
especially
not
servos
without
discussing
the
not
rocket
science
rule
of
software
engineering,
this
term,
the
not
rocket
science
rule
and
it's
phrasing
automatically
maintain
or
a
positive
code
that
always
passes
all
the
tests
was
coined
by
that
cool
insightful
dude
who
also
invented
the
rest
programming
language.
It's
a
core
piece
of
culture
that
permeates
the
entire
rest
ecosystem.
A
A
So
if
you
don't
have
tests
you're
just
going
to
go,
introducing
the
same
bug
over
and
over
or
you're
going
to
rely
on
one
project,
members
memory
to
prevent
that
from
happening
and
what
happens
when
they
leave
if
you're
not
always
passing
all
the
tests.
First
off
you
meaningfully
bisect
through
history,
to
figure
out
where
a
bud
was
introduced
and
it's
generally
hard
to
quantify
whether
a
given
change
made
the
codebase
better
or
worse
I
mean
things
were
failing
anyway,
they're
still
failing
now,
that's
not
really
that
different!
A
Is
it
and
then,
if
it's
not
automatic,
if
you're
manually
maintaining
the
repository
of
code
that
always
passes
all
the
tests,
you
are
introducing
so
much
excess
work
for
whoever
is
doing
that
manual
tasks
which
will
lead
to
not
only
burnout
on
their
part
but
also
hostility
between
them
and
the
people
who
keep
on
putting
that
work
onto
them.
How
do
we
do
this?
A
We
have
friendly
local
robots,
the
first
robot
that
did
this
was
named
monotone
for
helping
monitor,
monotonically
increase
the
code
bases,
quality
and
then
rust
has
a
bot
named
Bors
and
now
servo
has
homo
and
all
that
these
various
iterations
on
fundamentally
the
same
robot
do.
Is
they
wait
for
a
human
to
say?
Yes,
I,
like
this
code,
I
as
a
human
think
it
should
land
and
then
they
figure
out
whether
the
tests
would
pass
if
they
landed
it.
If
the
test
would
pass,
then
they
merged
the
code.
A
If
they
would
not,
they
come
back
and
tell
you
why
not,
and
then
you
fix
it
and
repeat
so,
I'm
pretty
sure
that
automatically
lending
the
code
after
the
tests
pass
after
a
human
gives.
A
positive
review
is
the
only
one
of
the
tools
in
this
talk
that
github
hasn't
obsoleted
with
their
own
tooling,
that
they've
announced
recently
and
over
the
past
year.
So
how
can
you
follow
the
not
rocket
science
rule?
First,
you
cannot
get
the
benefits
of
automatically
maintaining
a
repository
of
code
that
always
passes
all
the
tests.
A
If
you
don't
have
any
tests
to
pass,
you
cannot
get
the
benefits
of
having
a
test.
If
you
don't
run
it
run
your
tests
early
run,
your
tests
often
run
your
tests
automatically.
There
are
so
many
continuous
integration
and
continuous
delivery
tools
available,
at
least
two
of
which
possibly
more
are
set
up
right
here
at
this
venue
who
can
help
you
run
those
tests
either
for
free
or
for
a
fee,
and
then
once
you're
running
your
tests
use
the
results.
Little
then
code
for
you.
A
If
a
test
fails
in
your
tree
and
nothing
happens
as
a
result
of
that
failure
was
the
test
ever
really
there
for
github
projects.
This
means
that
your
tests
or
your
tooling,
should
report
back
to
the
status
API,
so
that
github
knows
what
the
result
was
for
a
given
pull
request
and
once
you're
reporting
to
the
status
API,
you
can
protect
the
branch
as
you
care
about
go
into
your
repo
settings
and
you'll
find
these
check
boxes,
and
you
want
to
configure
this
for
every
branch
that
matters
pick
the
branch.
A
Maybe
it's
master,
maybe
it's
release.
Maybe
it's
even
developed
check.
Yes,
I
want
to
protect.
The
branch,
require
the
status
checks
that
you've
now
configured
to
report,
and
then
things
cannot.
You
cannot
hit
the
merge
button
and
have
it
merge
if
the
status
check
isn't
passing
and
also
require
the
branches
to
be
up
to
date
before
merging.
Otherwise,
you
won't
effectively
be
testing
roughly
what
it
will
look
like
after
landing.
So
this
is
the
most
technical
part
of
what
I'm
gonna
recommend
to
you.
A
But
following
this
not
rocket
science,
rule
of
software
engineering
is
not
enough.
It'll
get
you
consistently
working
code,
but
it
doesn't
guarantee
that
the
code
which
passes
the
tests
is
in
the
bigger
picture,
doing
what
your
project
should
be
doing.
It's
like
hitting
the
gas
pedal
without
worrying
about
where
you're
steering
your
vehicle
and
the
way
you
steer
your
projects.
Improvement
is
through
good
communication.
A
Communication
is
a
huge
topic,
and,
since
this
talk
is
only
40
minutes,
I'm
going
to
skip
a
lot
of
the
more
nuanced
stuff
in
favor
of
some
concrete
takeaways
that
can
go
straight
back
to
your
project
as
a
quick
warning.
If
you
aren't
automatically
maintaining
a
repository
of
code
that
always
passes
all
the
tests,
you
won't
really
know
what's
going
on,
and
so
it
becomes
difficult,
if
not
impossible,
to
communicate
accurately.
How
can
you
tell
somebody
it's
in
that
state
or
the
other
state?
A
A
Here's
a
counter
example:
here's
an
example
of
an
anti-pattern
here.
This
is
an
issue
I
filed
back
on
a
while
back
on
a
repo
that
really
doesn't
have
a
well-organized,
team
or
good
communication
about
it.
What's
wrong
here,
the
me
being
an
owner
happened
later
part
as
part
of
an
initiative
to
fix
what's
up
that
octocat.
That
is
me
that
sad
face
that
is
my
face
when
my
issue
is
ignored
for
more
than
two
years.
A
Radio
silence
on
issues
is
such
a
big
problem
that
github
added
an
entire
feature
to
address
it,
which
is
that
first-time
contributor
badge,
if
I
were
a
first-time
open
source
contributor
instead
of
a
grumpy
old
nerd,
I,
probably
wouldn't
still
be
thinking
about
github.
Two
years
later,
I'd
think
I
must
have
done
something
horribly
wrong.
They're
ignoring
me,
I,
better
leave
how
to
serve
Oh,
prevent
this
kind
of
problem.
A
Before
that
first-time
contributor
badge
was
available,
we
took
advantage
of
github
extensibility
and
added
another
friendly
local
robot,
who
does
basically
the
same
thing.
This
hi-5
robot
not
only
greets
new
contributors
and
shows
them
around.
This
was
pre
issue
in
PR
templates
as
well,
but
it
also
gives
a
list
of
people
who
might
care
about
which
files
got
touched.
That's
another
thing
that
you
can
now
do
through
github.
You
don't
need
a
standalone
robot
for,
however,
having
this
functionality
wherever
you
get
it
from
helps
us
out
a
lot.
A
The
correct
issue
lifecycle
for
your
project,
if
you
want
a
inclusive
distributed
project,
will
almost
always
look
like
file.
The
issue
then
discuss
the
issue
then
implement
the
fix
you
discussed
doing
this
right
leaves
this
easily
searchable
historic
record
for
what
you
are
trying
to
do.
What
you
considered,
when
you
were
doing
it
and
how
you
had
decided
to
fix
it,
what
happens
if
you
mix
it
up?
Maybe
you
come
up
with
a
fix
by
yourself
and
then
you
merge
it.
You
just
skip
straight
to
implement.
A
Maybe
you
skip,
maybe
you
chat
with
a
colleague
over
coffee
and
then
you
PR
the,
and
then
you
file
your
issue
later
and
then
you
PR
the
fix
without
really
letting
anyone
else
chime
in
on.
What's
going
on
well
any
way
that
you
shake
up
this
order,
you
are
excluding
people
you're,
excluding
the
people
who
weren't
there
and
had
something
useful
to
contribute
to
the
discussion.
You
are
also
excluding
everyone
in
the
future.
Who
wants
to
look
back
and
say
how
did
this
happen?
Why
was
that
decision
made?
A
Did
they
consider
this
other
thing
so
so
get
your
issue
lifecycle
in
the
right
order.
If
you
want
to
work
with
people
outside
of
your
immediate
vicinity
or
outside
of
just
yourself
so
starting
out
with
filing
the
issue,
how
do
you
get
people
to
file
issues?
Well,
use
the
templates
that
are
available,
use
your
templates
to
clarify
what
the
discussion
is
going
to
need.
A
A
template
is
a
lot
easier
and
cleaner
than
going
back
and
forth
with
people
asking
them
the
same
five
questions
every
time
someone
makes
a
full
request
or
files
a
bug,
the
standardizing
noting
what
part
of
the
code
it
touches.
That
kind
of
thing
will
make
it
easier
to
do
your
private
investigation
going
back
going.
Okay,
what
are
all
the
issues
that
touch
this
part
of
the
code?
A
For
instance,
the
templates
are
also
an
opportunity
to
cultivate
a
good
culture
by
thanking
the
user
either
for
reporting
or
proposing
the
problem
or
the
fix,
and
they
also
help
set
expectations
about
what
the
user
should
expect
to
have
happen
next,
which
is
a
really
key
way
of
working
well
with
new
contributors.
So
when
you've
got
the
templates
when
you're
ready
to
have
that
discussion,
how
do
you
make
sure
you're
there
for
the
discussion
we've
got
to
make
sure
you
know
that
it's
happening,
there's!
No
one-size-fits-all
solution
for
notifications.
A
You've
got
to
figure
out
what
works
for
you.
How
do
you
personally
need
to
be
contacted
in
order
to
reply
to
issues
in
whatever
manner
you've
decided?
Is
timely
and
appropriate?
Just
as
importantly
as
notifications
on
for
things
you
care
about,
you
have
to
turn
the
notifications
off
for
the
things
that
you
would
rather
ignore.
A
If
you
leave
them
on
from
everything
that
all
of
those
spurious
notifications
are
going
to
train
you
to
ignore
the
emails
or
the
IRC
pings,
or
the
slack
messages
that
come
from
github
and
when
you're
ignoring
all
of
them,
you're
not
going
to
catch
the
stuff
that
you
do
care
about.
So
this
gets
you
a
good
issue,
opened
and
gets
the
discussion
started
once
that's
happening.
Social
processes
come
into
play.
There
is
no
technical
solution
for
managing
the
expectations
of
everybody
who's
involved.
It
is
social
and
personal
otherwise
known
as
a
particularly
hard
problem.
A
However,
the
other
person,
the
person
filing
the
issue,
the
person
contributing
to
the
issue,
giving
you
their
advice
or
asking
their
question-
needs
to
know
what
they
should
expect
from
you.
They
need
to
know
what
they
can
expect
you
to
do
and
when
they
can
expect
you
to
do
it,
if
they
don't,
if
they
have
the
wrong
expectation-
and
you
don't
do
the
thing
they
expected
they're
going
to
be
disappointed,
some
of
them
will
be
disappointed
very
quietly
and
just
sort
of
go
away
and
decide.
They
don't
want
to
be
there.
A
Some
of
them
will
be
disappointed
very
loudly
and
get
mad
at
you
in
public,
but
neither
of
those
is
good
for
your
project
and
as
well
as
setting
other
people's
expectations,
you
need
to
manage
your
own
expectations
as
well.
You
need
to
know
what
you
can
realistically
expect
yourself
to
do
and
when
you
can
expect
yourself
to
do
it
because
without
realistic
expectations,
you
can't
say
no
to
things
at
the
right
times.
Why
should
you
say
no
to
things
in
an
open-source
project?
A
We
have
124
labels,
most
of
which
we
even
use
the
reason
we
got
so
label
happy
is
we
were
using
labels
for
projects
and
milestones
way
before
those
features
were
introduced.
Now
that
you
have
these
tools
in
github,
you
can
probably
spread
the
load
out
and
have
fewer
labels
and
more
project
more
milestones
to
categorize
where
an
issue
is
and
what
it
applies
to,
so
that
somebody
working
on
that
task
can
find
the
right
thing
for
them.
A
You
have
to
bring
new
people
on
board
why
mentor
a
whole
bunch
of
new
contributors
instead
of
just
the
handful
of
people
who
are
gonna,
grow
up
to
be
core
folks,
just
as
you
probably
don't
stick
with
and
become
a
core
person
on
every
single
project,
you've
ever
touched.
Most
communities
interact
with
dozens
or
even
hundreds
of
drive-by
potential
contributors
before
are
for
everyone
who
sticks
and
really
becomes
involved
long
term.
A
We
are
awed
by
contributors
like
Josh
and
Manish,
who
not
only
mentor
people
pretty
much
constantly,
but
even
teach
that
mentoring
as
well
and
not
everyone
in
your
project
has
to
be
a
mentor,
but
everyone
can
show
that
they
value
the
mentorship
by
taking
little
steps
that
make
life
easier
for
whoever
is
doing
the
mentoring.
How
can
you
make
your
project
a
better
place
for
mentors
to
work
their
magic?
A
First,
oh
man.
Thank
you,
slides
tool.
This
says
documentation.
Gardening!
You
can
make
your
life
make
life
easier
for
anyone,
mentoring,
incoming
community
members,
by
keeping
your
Doc's
in
good
shape.
Writing
your
Docs
once
and
then
never
touching
them
again
is
basically
the
same
thing
as
planting
a
garden
in
the
starlit
season
and
then
just
leaving
it
alone
and
hoping
it
grows
beautiful
with
nothing,
invasive,
no
weeds,
nothing,
bad
sure.
You
might
have
a
few
things
that
can
that
are
still
there
at
the
end
of
the
season.
A
Just
like
some
parts
of
your
dogs
will
still
be
accurate,
even
if
you
don't
update
them,
but
abandoned
documentation.
Just
like
an
abandoned
garden
will
get
more
and
more
inaccurate
and
even
dangerous
to
its
users,
as
time
goes
on,
treat
reports
of
difficulty
with
your
dogs
or
inaccuracy
in
them
as
seriously
as
you
treat
reports
of
dead
plants
or
dangerous
infrastructure
in
a
garden
that
you
want
to
keep
welcoming
and
beautiful.
So
the
next
way
that
you
can
help
your
communities
mentors
has
a
mnemonic
that
might
roast
you
out.
A
If
you
don't
like
looking
at
pictures
of
bugs
I
mentioned
this,
because
the
next
slide
will
have
a
picture
of
scorpions
on
it
for
those
of
you
who
aren't
incapacitating
ly
uncomfortable
with
insects.
This
is
what
I
want
you
to
think
about.
When
you
see
what
you'd
call
a
bite-sized
bug,
those
easy
little
fixes
that
you
could
just
whip
out,
commit
it
you're,
fine
I,
don't
this
is
two
lollipops
that
have
scorpions
embedded
in
them.
A
Nice
little
treats
right,
I,
don't
know
about
you,
but
that
doesn't
look
like
something
I
want
to
take,
and
this
is
my
memory
aid
to
say,
leave
the
bite-sized
bugs
for
someone
else
filing
your
small,
easy
bug
as
an
issue
instead
of
just
fixing,
it
yourself
will
allow
a
new
contributor
to
have
a
more
positive
first
experience.
Ok,
the
scorpions
are
gone.
A
You
can
look
now
we're
going
to
talk
about
starters,
the
for
github
solved
the
whole
issue,
aggregation
thing
for
us
with
the
easy
and
good
first
issue
bugs
we
use
this
little
app
written
by
a
contributor
that
finds
the
Help
Wanted
bugs
across
every
repo
in
our
organization,
the
average
life
of
an
easy
issue
in
Cervo.
Last
time
we
ran
the
numbers
on
it
was
less
than
a
day.
A
This
is
a
testament
to
the
accuracy
with
which
core
folks
tag
the
easy
bugs
as
easy
and
not
tag
the
difficult
bugs
as
easy,
and
also
a
testament
to
the
enthusiasm
with
which
newcomers
love
to
fix
them.
So
you're
coding
in
public
you're
automatically
maintaining
a
repository
of
code
that
always
passes
all
the
tests.
A
You've
got
good
communication
going
and
you're
ready
to
mentor
those
new
contributors
as
they
come
in
there's
just
one
last
step
to
take
a
project
from
good
to
break,
and
that
is
opening
the
pipeline
of
contributors
to
open
the
pipeline
means
to
give
more
people
from
all
over
the
world
with
all
kinds
of
different
backgrounds
and
experiences
the
opportunity
to
find
their
way
into
your
project
and
make
it
even
better.
If
you
don't
have
everything
up
through
good
mentorship,
worked
out,
do
not
focus
on
opening
your
pipeline.
A
So
servo
is
this
really
small
project
with
this
really
big
community,
and
that
didn't
happen
by
mistake.
We've
been
making
a
concerted
effort
over
the
five
years
of
the
project's
existence,
to
be
a
great
place
to
join
and
to
share
that
with
others.
There's
two
main
categories
of
ways
to
open
the
pipeline,
but
before
using
either
you
should
double
check
that
you're
actually
an
appealing
place
when
somebody
sees
that
your
project
exists,
that
they'll
want
to
join
and
one
thing
that's
helped
us
out
a
whole
lot.
A
A
So
the
first
way
to
open
a
pipeline,
our
sites
that
I
call
issue
aggregators.
They
make
a
big
old
list
of
relevant
issues
from
a
bunch
of
different
projects,
and
then
people
go
to
them
and
look
for
an
issue
that
they
would
like
to
fix
on
a
project
they
may
never
have
touched
before.
As
we
learned
yesterday.
Github
is
also
becoming
one
of
these
many
issue
aggregators
and
this
month
of
October.
A
If
you
happen
to
have
everything
in
place
to
start
opening,
your
pipeline
digitalocean
is
holding
this
heck
Tober
fest
event
where
they
encourage
people
to
check
out
for
good,
first
PR
bugs
and
make
for
PRS,
and
they
get
people
a
shirt.
It's
highly
motivating
to
some
people
and
as
one
of
many
examples
another
example
if
you're
equipped
to
deal
with
people
who
might
not
only
be
new
to
your
project
but
new
to
software
or
new,
to
open
source
in
general
is
open.
Hats
org.
A
This
goes
all
year
round
and
it's
a
great
place
to
publicize
your
issues
that
you'd,
like
help
on
to
novice,
free
and
open
source
software
contributors.
Open
patch,
is
fantastic.
If
you
have
the
resources
to
mentor,
people
who
might
be
near
to
get
and
might
be
new
to
your
programming,
language
might
even
be
new
to
github.
It
is
less
great
if
you
can
only
take
on
contributors
who
already
have
a
sir
minimum
skill
level.
So
that's
the
first
way
of
opening
the
pipeline.
A
A
Think
about
people
who
are
the
primary
care
giver
for
a
child
or
an
elderly
person
and
might
only
have
a
couple
hours
a
day
to
themselves
to
do
anything,
and
even
if
your
work
is
open
source,
think
about
what
resources
you
have
at
your
disposal
to
pay
people
to
write
some
code
on
it
to
make
it
available
to
to
those
other
groups
another
great
way,
especially
if
you're
working
on
open
source
to
open
that
pipeline
and
pay
people.
In
addition
to
google
Summer
of
Code
is
outreach
formal.
A
You
know
outreach
program
for
women
know
for
anyone
underrepresented
in
tech.
It's
a
great
way
to
find
people
who
can
help.
You
have
bet
so
that
icing
on
the
cake,
the
sweets
at
the
top
of
our
food
pyramid
of
techniques,
is
bringing
more
of
the
world
into
the
wonderful
project
that
you're
working
on.
Let's
recap
how
you
built
it
first,
you
code
like
everyone
is
watching.
It
pressures
you
to
write
better
quality
code
and
make
every
other
step
here
feasible.
A
Then
you
set
yourself
up
for
technical
success
by
automatically
maintaining
a
repository
of
code
but
always
passes
all
the
tests.
Modern
tools
mean
that
the
hardest
part
of
this
process
is
just
deciding
that
you're
going
to
do
it
once
you've
made
that
decision.
There's
a
bunch
of
tooling
out
there
to
help
him
next
to
steer
your
project
collaboratively
and
make
the
most
of
contributors
diverse
perspectives
from
around
the
world.
In
many
time,
zones
maintain
an
issue
lifecycle
of
conversation
before
implementation.
A
And
then
be
a
mentor
for
people
new
to
your
project
or
help
out
those
people
who
do
want
to
be
mentors,
because
a
sustainable
project
always
has
a
gradual
flow
of
new
people
coming
in
and
older
people
coming
out.
Finally,
what's
those
foundations
of
reliable
testing,
good
communication
and
helpful
mentorship
are
established
open
up
your
pipeline
to
more
contributors
to
really
excel
use?