►
Description
Presented by Eileen Uchitelle, GitHub.
If contributing to open source was only about writing code, it would be easy. In reality open source exposes our insecurities and makes us feel vulnerable. Vulnerability can inspire change, but can also paralyze us for fear of not being good enough. In this talk we'll look at how vulnerability affects open source contributors and explore how maintainers can foster a welcoming community. Contributors will learn how to identify projects with empathetic leaders who value GitHub’s community standards. Cultivating a better environment for contributing makes open source more sustainable for all.
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
A
A
Vulnerability
is
an
inherent
part
of
open
source
and
I.
Don't
think
that
that
feeling
will
ever
go
away
for
me.
I
opened
my
first
PR
on
github
in
2012.
It
was
a
pull
request
to
fix
a
typo
in
a
readme
of
a
project
that
I
was
using.
The
PR
was
never
merged
because
the
project
had
been
abandoned
for
a
few
years,
almost
a
full
year,
leer
I
opened
my
second
pull
request.
Mini
profiler
is
a
database
profiler
for
rails.
A
Apps
I
noticed
that,
while
using
mini
profiler
in
my
application,
there
was
an
extra
space
at
the
bottom
of
the
page.
I
thought
this
is
likely
a
CSS
bug.
Gonna
be
really
easy
to
fix.
I
quickly
found
out
that
it
was
not
CSS
and
it
took
me
two
days
to
find
the
invisible
utf-16
character
that
was
causing
the
displayer.
A
A
After
giving
a
talk
in
2014
at
Mountain,
West
Ruby
I
learned
that
I'd
found
a
bug
in
an
active
record
which
is
rails
database
manager,
iron
Patterson,
a
rails,
core
team
member
asked
me
if
I
wanted
to
pair
with
him
to
fix
the
problem
shortly
after
I
opened.
My
first
pull
request
on
the
Ruby
on
Rails
framework,
even
though
I'd
paired
with
Aaron
and
I
knew
the
fix
was
correct.
I
was
still
really
nervous
about
opening
a
PR
against
a
repo
where
2,000
people
get
notifications.
Every
time
you
open
an
issue
or
a
pull
request.
A
A
The
other
side
of
that
fear,
though,
is
that
higher
you
get
when
your
pull
request
is
merged.
I
continued
to
contribute
to
rails
regularly.
After
that,
first
pull
request.
Maybe
it
was
because
I
had
someone
mentor
me
and
helped
me
understand:
rails
internals.
Maybe
it
was
because
I
had
such
a
good
experience,
contributing
that
first
time.
A
A
This
past
year,
I
worked
on
a
large
feature
for
rails
called
system
tests.
Previously,
my
work
on
Rails
had
been
refactoring
code
fixing
bugs
improving
performance.
This
was
my
first
experience,
adding
a
major
feature
and
by
major
I
mean
it
was
literally
the
highlight
of
the
rails.
5.1
release
working
on
this
project
reminded
me
how
hard
contributing
to
open
source
can
be
I've
been
contributing
regularly
for
over
two
years,
but
I
was
nervous.
Opening
this
PR
I
had
those
familiar
thoughts.
What,
if
everyone
hates
the
feature?
A
What
if
someone
thinks
my
code
is
bad,
even
though
DHH
the
creator
of
rails
rails
literally
asked
me
to
build
this
feature.
I
still
had
to
deal
with
reviews
and
comments
and
defend
my
decisions
when
I
opened
the
pull
request.
I
had
put
three
months
of
work
into
it,
I
had
spent
nights
and
weekends,
and
it
was
personal
to
me
in
the
time
that
the
pull
request
was
open
before
it
was
merged.
Iris,
huge
over
150
comments
and
11
reviews.
A
That's
a
lot
of
other
opinions
to
deal
with
I
felt,
stressed
and
vulnerable,
just
like
I
had
when
I
opened.
My
first
flow
requests,
someone
even
tweeted
about
the
PR,
which
only
drew
more
attention
to
the
work
and
don't
get
me
wrong.
Attention
is
good
and
reviews
are
good,
but
I
was
drained
by
the
endless
bike
shedding
and
picking
of
details.
A
None
of
the
reviewers
met
any
harm.
They
were
excited
about
the
feature.
Still
there
was
a
level
of
discomfort
that
not
at
me,
I
had
been
an
avid
contributor
Terrell's
for
over
two
years,
I'd
released
rails,
5
and
I
had
commit
rights.
Why
was
opening
this
PR?
A
nail-biting
stress
inducing
event
in
my
life,
I
figured
I
figured
I'd
be
over
the
unbearable
vulnerability
by
now,
while
I
was
thinking
about
this.
A
Something
hit
me
I
realized
that,
even
if
we
get
used
to
working
on
open
source,
we
can
experience
vulnerability
when
working
on
a
project
or
a
large
feature.
The
more
time
we
spend
on
open
source,
especially
free
time,
the
more
attached
we
become
to
the
work
that
we're
doing
and
there's
only
one
explanation
for
why
this
happens.
If
contributing
to
open
source
was
only
about
writing
code,
it
would
be
easy.
We
all
know
that
contributing
to
open
source
isn't
easy,
we're
not
just
dealing
with
code
or
ones
and
zeros.
A
Contributing
to
open
source
is
about
our
insecurities
fear
of
being
wrong
and
fear
of
showing
our
work
to
our
peers.
Often
the
thought
of
just
pushing
code
into
a
public
repository
and
cause
anxiety,
given
that,
while
people
are
the
stores
that
have
owner
ability,
they
are
also
essential
to
the
open
source
ecosystem.
A
Let's
take
a
minute
to
think
about
what
open
source
would
look
like
without
people
say
you
write
a
gem
or
library
and
open
sourced
it
sure
it's
public
for
anyone
to
use,
but
if
no
one
downloads
it
is
it
really
an
open
source
project
open
source
doesn't
work
without
users.
Otherwise
you
were
not
really
sharing
your
code
with
anyone.
A
A
Let's
say
you
have
tons
of
users,
but
no
contributors,
sure
you
get
to
completely
control
your
project
and
you
never
have
to
deal
with
any
other
ideologies
or
opinions,
but
is
that
open
source?
If
you
stop
improving
the
project
or
move
on
to
something
else,
your
project
will
kind
of
cease
to
be
useful.
Open
source
cannot
survive
without
contributors.
A
Imagine
for
a
moment
a
world
where
DHH
created
rails
but
had
no
contributors.
Would
it
be
as
robust?
It
is
as
it
is
today.
Probably
not
would
all
of
the
engineers
who
learned
Ruby
and
rip
on
Ruby
on
Rails
and
got
jobs,
not
writing
Java
be
as
happy
as
they
are
today.
I,
don't
know,
I've,
never
written
Java,
maybe
we've
all
would
have
adopted
merb
or
Sinatra
instead,
but
the
community
and
tools
would
be
very
different
from
their
where
they
are
today.
If
rails
had
never
been
open,
sourced
I
never
attracted
any
contributors.
A
A
Vulnerability
can
be
harnessed
as
a
motivator
for
change
or
could
deter
us
from
contributing.
There
are
ways
we
can
foster
a
welcoming
community
and
attract
more
contributors,
rather
than
deter
them
before
we
explore
ways
in
which
we
can
make
better
open-source
communities.
We're
going
to
look
at
ways
in
which
maintainer
x'
make
vulnerability
more
bearable.
A
Vulnerability
can
be
a
deterrent
for
many
new
and
longtime
contributors.
Feelings
of
inadequacy
can
keep
folks
from
contributing
to
your
project,
which
means
maintainers
lose
out
on
changes
from
other
viewpoints
that
could
make
their
project
more
robust
and
usable.
We
want
to
avoid
creating
an
environment
that
fosters
fear
of
contributing
in
favor
of
an
environment.
That's
welcoming
and
inclusive.
We
want
to
create
environments
and
communities
that
cultivate
creativity
and
inspire
contributors.
A
One
of
the
ways
maintainer
x',
deter
contributors
is
closing.
Pull
requests
without
proper
feedback.
Well
maintained
errs.
Do
this,
they
don't
leave
room
for
what
maintainer
do
this?
They
don't
leave
room
for
a
contributor
to
improve
in
the
future.
Maintainer
should
always
explain
why
a
pull
request
wasn't
accepted,
otherwise
contributors
might
take
it
personally.
A
Contributors
spend
a
lot
of
emotional
energy
on
contributing
and
it
can
be
demoralizing
to
not
have
your
poll
request
accepted.
Ask
clarifying
questions
if
you
don't
understand
why
they
want
to
make
a
change
or
what
their
use
case
is
being
dismissive
and
not
giving
feedback
will
cause
contributors
to
feel
like
their
time
isn't
respected
and
they
may
not
contribute
to
the
project
again.
A
Another
way
in
which
maintainer
x'
can
make
contributors
feel
more
vulnerable
is
through
violent
communication.
An
example
of
violent
communication
is
saying
this
code
sucks,
or
did
you
even
try
to
fix
this
problem?
The
communications
this
communication
style
passes
the
blame
onto
the
user
and
shames
them
the
lead
contributors
to
feeling
defensive
and
more
vulnerable.
It
will
deter
them
from
contributing
in
the
future
because
they
don't
feel
respected.
A
If
you
want
to
learn
more
about
nonviolent
communication,
you
should
watch
this
talk
by
Nadia
O'donnell,
my
oh,
it's
called
this
code
sucks
a
story
about
nonviolent
communication.
Her
talk,
explorers
nonviolent
communication.
What
that
means,
and
the
benefits
for
using
that
in
your
communications
network,
often
I
see
bad
behavior
being
tolerated,
because
someone
is
a
high-impact
member
of
a
team,
they
respond
to
lots
of
pull
requests
or
they
send
lots
of
patches.
Even
though
a
contributor
or
maintainer
may
seem
like
an
asset.
A
A
A
power
dynamic
exists
between
maintainer,
x'
and
contributors.
It's
important
to
recognize
this,
because
maintainer
x'
inherently
have
more
power
than
contributors.
This
is
will
always
be
true,
because
maintainer
x'
decide
what
gets
merged
and
who
gets
to
contribute
because
of
the
power
dynamic
between
contributors
and
maintainer
x'.
It's
up
to
maintain,
errs
to
set
and
reset
the
tone
of
the
conversation.
A
There
is
always
going
to
be
who
come
into
your
project
and
demand
free
time
from
you,
but
most
people
come
to
your
project
with
good
intentions
and
they
mean
well.
It
takes
a
lot
of
energy
to
mad
and
rude
back
to
someone.
Wouldn't
maintaining
projects
be
easier
if
we
could
defuse
stressful
situations
instead
of
aggravating
them
as
a
maintainer
myself,
I
have
felt
the
pole
to
tell
someone
off
when
that
happens.
I
try
to
put
myself
in
their
shoes
and
take
a
walk
before
responding,
maybe
they're,
maybe
they're,
just
really
frustrated.
A
Maybe
their
boss
is
breathing
down
their
neck
to
get
something
fixed.
Maybe
they
dropped
a
production
database.
It
is
a
bug,
often
taking
the
time
to
tell
the
contributor
that
I
know.
They're
frustrated
quickly
turns
the
conversation
from
defensive
to
productive.
This
doesn't
mean
giving
contributors
everything
they
want
or
rolling
over.
It
just
means
giving
them
treating
them.
The
way
that
you
want
to
be
treated
when
you're
in
a
stressful
situation.
A
Vulnerability
can
be
harnessed
as
a
motivator
being
vulnerable,
isn't
a
bad
thing.
We've
all
felt
it
before
and
we'll
all
feel
it
again.
Every
single,
maintainer
and
contributor
has
at
one
time
felt
vulnerable
when
we
feel
safe,
being
vulnerable,
we're
more
creative,
more
inspired
and
more
open.
If
we
can
change
open-source
communities
to
be
more
welcoming
and
supportive,
they
will
be
more
sustainable
and
the
vulnerability
will
be
more
bearable.
A
Why
is
it
important
to
create
a
welcoming
and
supportive
open-source
community?
Why
does
it
even
matter
if
contributors
feel
safe
being
vulnerable?
Open-Source
is
a
funnel
at
the
top.
You
have
users,
some
of
those
users
will
become
contributors,
and
some
of
those
contributors
will
become
maintains.
The
more
maintained
errs
you
have
the
more
sustainable
open-source
is
because
you
have
more
back
making
our
open-source
communities
more
welcoming
will
attract
more
users
to
become
contributors
and
more
contributors
to
become
maintainer
x'.
A
If
we
don't
do
this,
then
we'll
end
up
on
an
island
alone,
maintaining
projects
by
ourselves.
This
leaves
the
less
users,
because
you
can't
sustain
a
project
alone,
less
job
offers,
because
no
one
is
using
your
projects
and
less
friends,
because
you're
spending
all
of
your
time
working
on
open
stores
instead
of
having
a
life.
A
Imagine
a
world
where,
instead
of
burning
out
on
that
Island,
the
funnel
didn't
lose
so
many
potential
maintainer.
What
would
the
ideal
open-source
world
look
like?
Maybe
it
looks
like
users
and
contributors
and
maintainer
x'
all
moving
equally
among
roles
in
today's
open
source
world
many
maintainers
stopping
users
of
their
own
product,
some
even
stop
contributing
beyond
merging
and
accepting
pull
requests.
It
doesn't
have
to
be
like
this,
but
I
also
think
my
ideal
world
would
be
pretty
hard
to
achieve
just
because
of
how
open-source
politics
work.
A
So
if
this
ideal
world
isn't
possible,
then
what
is
possible?
A
name
could
be
to
try
to
make
the
funnel
look.
A
little
wider,
like
this
users,
are
still
a
majority
of
the
people
involved
in
your
project,
but
users
are
more
likely
to
become
contributors
and
maintainer.
X'
than
in
the
previous
funnel
there's
less
friction
to
move
from
users
to
contributors
to
maintainer,
zit
back
again,
open
source
needs
contributors.
Without
them,
open
source
will
cease
to
exist
and
thrive.
A
A
So
how
do
we
create
a
world?
That's
more
welcoming
and
supportive
for
open
source
communities
so
that
contributors
join
an
open
source
communities
thrive.
There
are
many
ways
in
which
we
can
make
open
source
a
better
experience
for
everyone.
Healthy
community
communities
benefit
maintainer
contributors
and
users,
one
way
in
which
maintainer
x'
can
attract
and
retain
more
contributors,
as
through
mentorship,
many
of
my
first
contributions
to
rails,
where
there
was
of
pairing
with
Aaron
Patterson,
another
rails,
core
team
member
mentorships,
don't
need
to
be
official
or,
and
they
can
happen.
A
Organically
I
just
met
Aaron
at
a
conference
and
after
my
talk
he
was
like
you
have
a
bug.
You
found
it
and
we're
gonna
pair
and
fix
it
before
I
made.
My
first
commit
to
rails
I,
never
thought
I'd
be
on
the
rails.
Core
team
rails
are
really
a
complicated
codebase
and
it's
difficult
to
get
used
to
working
on.
On
top
of
that,
the
community
is
huge.
It
has
over
2,000
contributors
to
date
and
at
least
2,000
people
get
notifications.
A
Aaron's
guidance
helped
me
navigate
the
codebase
and
the
community,
making
contributing
less
stressful
I
knew
that
he
had
my
back
and
he'd.
Help
me
defend
decisions
that
I
made
in
PRS
mentoring
can
happen
in
many
forms,
from
pairing
to
email,
to
inviting
contributors
to
a
group
chat
with
other
maintainer
'he's
I've
helped
folks
get
their
first
contributions
through
Twitter
DM
was
pairing
and
email
mentoring
doesn't
have
to
be
official
or
time-consuming.
A
The
point
of
mentorship
is
to
act
as
a
guide
for
your
mentee
and
help
them
feel
more
welcome
in
the
community
writing
up
their
guidelines.
For
contributing
can
help
make
contributors
feel
more
welcome
to
your
project.
It's
always
easier
to
contribute
to
a
repository
that
has
explained
what's
expected,
rather
than
guessing
each
project
on
github
has
their
own
rules
for
contributing.
For
example,
the
rails
project
doesn't
accept
feature
requests
on
the
issues
tracker.
A
To
ensure
that
you're
providing
clear
guidelines,
you
can
use
some
of
the
tools
on
github
be
sure
to
add
a
contributing
markdown
file
to
your
github
repository
included.
Any
rules
about
contributing
that
are
unique
to
your
projects
like
requiring
all
pull
requests,
be
a
single
commit
or
not.
Allowing
cosmetic
changes
to
the
code.
A
Github
provides
files
that
allow
maintainer
to
set
up
a
template
for
contributing
to
their
project,
use
this
template
to
guide
contributors
into
writing,
good
bug
reports
or
properly
submitting
a
pull
request.
These
templates
are
fully
customizable
and
our
simple
markdown
file,
so
you
can
setup
the
issue
and
PR
templates
for
your
project
for
the
rails
repository.
We
ask
that
issues
indicate
which
version
of
rails
and
Ruby
that
they're
using
this
helps
us
quickly.
Triage
issues
based
on
what
versions
are
supported
and
but
also
means
that
we
don't
need
to
ask
contributors
for
that.
A
Information
in
the
future.
Using
issue
templates
reduces
anxiety
and
frustration
for
new
contributors.
In
addition
to
templates
rails,
provides
bug
reports
scripts
that
can
be
used
to
replicate
bugs
experienced
in
the
rails
applications.
This
means
that
users
don't
need
to
provide
a
full
application
to
produce
rate
to
reproduce
a
bug.
They're
experiencing
it'll
bug
can't
be
reproduced
by
one
of
our
scripts.
A
This
also
helps
new
contributors
know
that
someone
is
paying
attention
and
will
respond
to
them
soon,
and
it
also
gives
them
a
point
of
contact.
Instead
of
having
to
spam
the
entire
core
team,
we
also
use
a
linter
to
tell
contributors
what
needs
to
be
fixed
which
reduces
bite
shutting
about
small
details,
because
nobody
wants
to
argue
with
a
robot,
because
the
robot
might
answer
you,
everyone
makes
mistakes.
So
if
you
see
a
canoe
contributor,
fail
to
add,
CS
skip
for
a
documentation,
change
or
open
a
feature
request
on
the
issues.
A
Tracker,
don't
shame
them
kindly
tell
them
how
to
contribute
better
in
the
future.
This
will
ensure
that,
even
though
the
contributors
pull
requests
didn't
get
merged
or
their
issue
was
closed,
they'll
feel
welcome
to
come
and
contribute
again
in
the
future.
There's
no
point
in
putting
someone
down
that
will
only
chase
away
contributors.
A
When
you're
a
maintainer
of
a
project,
it's
easy
to
think
you
have
to
do
everything
yourself,
I
think
it's
important
to
know
when
and
how
to
ask
for
help.
The
good
thing
is
that
github
provides
a
clear
place
for
you
to
do
that.
You
can
use
your
read
me
to
document
areas
that
your
project
needs
help
when
I
first
started
contributing
to
mini
profiler
I
knew
exactly
what
Sam
staffer
needed
help
with,
because
he
laid
it
all
out
in
his
project.
In
fact,
he
still
needs
help
in
some
of
these
areas.
A
Contributors
will
feel
more
welcome
to
push
changes
to
your
project
if
they
know
the
work
they're
doing
is
wanted.
This
reduces
vulnerability
and
stress
when
opening
that
initial
pull
request,
asking
for
helping
your
documentation
is
a
great
way
to
get
contributors.
You
need
to
bring
in
contribution
bring
in
contribution,
yeah
contributions
that
you
are,
that
you
need
and
that
they
are
passionate
about
working
on
to
help
your
project
be
more
successful.
A
Another
way
of
asking
for
help
that
can
attract
new
contributors
is
to
label
issues
that
are
good
for
us
first
patches.
Clearly,
labeling
issues
that
are
easier
for
beginners
allows
them
to
work
on
something
they
know
they
can
succeed
at.
If
you
do
this,
you
should
discourage
seasoned
maintainer,
x'
and
other
contributors
from
jumping
in
on
these
issues.
If
they
aren't
urgent,
this
will
allow
new
contributors
to
learn
at
their
own
pace
without
fear
of
someone,
stealing
their
pull
request
from
them.
A
One
of
the
ways
you
can
ask
for
help
is
by
promoting
contributors
to
maintain
errs
where
ELLs
wouldn't
be
as
successful
as
it
is
today.
If
DHH
didn't,
share
the
burden
of
making
decisions,
releasing
new
versions
and
sculpting
the
future
of
rails
with
the
core
team
rails.
Core
currently
has
12
members.
That
doesn't
mean
that
this
means
that
all
of
us
don't
need
to
be
available
all
the
time
for
rails
to
thrive.
We
can
share
the
work
with
each
other,
while
smaller
projects
aren't
likely
to
have
a
team
of
maintainer
x'
as
large
as
rails.
A
A
A
One
of
the
important
things
to
remember
as
a
maintainer
is
to
not
review
pull
requests
before
you've
had
your
morning,
coffee,
if
you're
like
me,
you're
very
grumpy
before
coffee
and
maybe
haven't
even
recovered
from
the
nightmares
that
you
had
the
night
before
I
have
personally
jumped
to
snap
conclusions
when
I
review
flow
requests
before
coffee,
it's
often
more
likely
that
I'm
going
to
be
short
with
the
user
and
dismissed
the
pull
requests
without
a
proper
review.
Take
the
time
to
take
care
of
yourself
before
reviewing
pull
requests.
A
As
we
talked
about
earlier,
employing
non-violent
communication
tactics
is
the
best
way
to
interact
with
contributors.
You
should
probably
employ
non-violent
communication
methods
in
all
areas
of
your
life,
but
right
now
we're
just
talking
about
open
source.
Using
non-violent
communication
will
keep
the
conversation
open.
Remember
that
as
a
maintainer
or
contributor
you
can
set
and
reset
the
tone
of
the
conversation
recently
on
rails.
We
had
a
situation
where
an
issue
got
closed
quickly
without
a
conversation.
This
of
course
resulted
in
the
we're
getting
defensive
because
we
weren't
listening
to
them.
A
I
took
the
time
to
respond
to
the
contributor
and
let
them
know
that
I
understood
how
they
felt
and
asked
them
what
solutions
might
work
for
them.
This
immediately
changed
the
tone
of
the
conversation
instead
of
being
annoyed.
Instead
of
being
annoyed,
we
were
able
to
finally
talk
about
solutions
to
the
problem.
This
does
not
mean
that
the
contributor
is
going
to
get
exactly
what
they
want,
but
they
no
longer
feel
like
we
just
dismiss
their
concerns
or
ignored
them
talks
like
contributors.
The
way
you
want
to
be
talk
to.
A
A
When
you
see
this
badge
give
the
contributor
a
little
extra
time
and
be
a
little
extra
helpful
when
I
see
this
badge
I
take
the
time
to
congratulate
the
contributor
on
their
first
pull
request
as
a
maintainer
of
Rails
I
want
contributors
to
have
a
good
experience,
and
let
them
know
that
I
appreciate
the
time
they
put
into
rails
because
of
this
they'll
be
more
likely
to
contribute
again
in
the
future.
Instead
of
going
to
someone
else's
project.
A
Another
github
tool
that
is
was
recently
rolled
out
to
everyone
is
the
community
profile
which
was
built
by
the
community
and
safety
team
at
github.
The
community
profile
is
a
tool
that
shows
github
is
recommended
standards
for
creating,
welcoming
and
sustainable
open-source
communities.
The
community
profile
is
located
under
the
repository
insights
tab
via
a
link
called
community.
The
community
profile
page
will
show
you
six
items
that
make
a
healthy
open-source
project.
The
description,
a
readme
code
of
conduct,
contributing
guidelines,
a
license
and
issue
and
PR
templates.
A
Each
of
these
items
will
help
make
your
project
more
approachable
and
sustainable.
The
description
is
self-explanatory,
but
next
we
have
the
readme,
which
is
the
instruction
manual.
This
is
the
thing
that
users
need
to
need
to
read
first,
to
understand
how
to
use
your
project,
what
your
project
is
and
where
more
information
is.
If
your
project
doesn't
have
a
ravika
trigger,
won't
know
where
to
start
and
users
won't
know
how
to
use
your
software.
A
Adding
a
code
of
conduct
will
attract
a
new
contributors
because
they
know
that
you're
serious
about
maintaining
a
professional
and
respectful
community
codes
of
conduct
benefit
everyone,
but
people
from
other
underrepresented
groups
are
more
likely
to
feel
comfortable
and
welcome
to
you're
welcome
contributing
to
your
project.
If
you
implement
a
code
of
conduct
and
ensure
that
all
the
maintainer
Zoar
contributors
treat
each
other
with
respect,
if
you
don't
have
a
code
of
conduct,
github
has
added
tools
to
help.
You
add
one
automatically
on
the
community
profile.
A
Page
there'll
be
an
Add
button
that
will
take
you
to
this
page
and
it
will
show
you
a
list
of
code
of
conducts
and
helpful
tips
about
how
to
enforce
a
code
of
conduct,
as
I
mentioned
earlier.
Contributing
guidelines
are
instrumental
in
laying
out
the
rules
for
contributing
each
project
is
different
and
unique
in
what
they
expect
from
pull
requests
or
issues
so
be
sure
to
read
the
contributing
guidelines
before
contributing
where
else
contributing
guidelines
go
over.
A
What
to
do
if
the
bug
is
security
related
how
to
find
duplicate
issues
using
our
bug,
report
templates
and
reproduction
scripts,
as
well
as
installation
and
writing
patches.
If
your
project
doesn't
have
been
contributing
guideline,
it
will
be
difficult
for
contributors
to
send
patches
to
you
or
bug
reports
that
meet
your
standards.
A
license
is
an
important
part
of
open
source
because
legally
a
project
isn't
totally
open-source
until
you
actually
choose
a
license.
A
Lastly,
a
healthy
open-source
project
will
contain
the
issue
and
pull
request
templates.
That
I
talked
about
earlier.
These
are
important
because
every
project
is
different
and
these
templates
tell
contributors
exactly
what
information
maintainer
z'
want
in
the
issues
and
pull
requests
that
they
open.
A
We've
talked
a
lot
about
how
maintainer
z'
can
build
better
communities.
All
of
this
is
to
help
new
contributors
feel
welcome
and
inspired.
The
goal
is
to
help
make
the
vulnerability
variable
for
new
contributors.
Now
we're
going
to
look
at
ways
that
contributors
can
find
healthy,
healthy
open-source
projects
where
their
contributions
will
be
welcomed.
A
One
of
the
easiest
ways
to
find
a
project
to
contribute
to
is
to
look
at
what
tools
you
use
every
day.
If
you
build
rails,
apps,
look
in
your
gem
file
for
ideas
of
projects
that
might
need
your
help.
That's
how
I
ended
up
contributing
a
mini
profiler
contribute
to
the
tools
that
you
use,
because
that's
where
you'll
be
most
useful
in
open
source
users
become
contributors
and
contributors
become
maintainer
zhh.
So,
with
that
logic,
the
easiest
way
to
become
a
contributor
is
to
first
be
a
user.
A
A
Active
projects
have
recent
commits.
Look
at
the
top
are
on
github
to
see
when
the
last
commit
was
projects
that
are
active
should
have
pull
requests
merged
or
issues
closed.
In
the
last
few
days,
two
months
for
larger
projects
like
rails,
there
should
be
activity
every
few
hours
for
smaller
projects.
There
might
only
be
activity
every
few
days
or
months.
A
My
first
contribution
to
open-source
was
for
a
project
that
was
no
longer
maintained
and
had
been
abandoned.
It
didn't
feel
good
to
make
a
contribution
that
would
never
be
accepted.
There
are
a
few
ways
that
you
can
go
about,
making
changes
to
abandon
projects
you
can
offer
to
take
over
maintaining
the
project
or
open
a
PR
with
the
expectation
that
it
won't
get
merged.
If
you
just
want
to
help
other
people
don't
open
an
issue
that
asks
is
this
still
maintained,
especially
if
it's
very
obviously
not
maintained
anymore?
A
Once
you're
sure
the
project
is
active
and
accepting
new
contributors
take
a
look
at
how
maintainer
zhh
respond
to
new
issues
or
pull
requests
subscribe
to
a
few
of
them
and
on
the
project
and
see
how
maintainer
Street
contributors
are.
They
kind
are
dismissive
your
questions
go
unanswered,
or
are
they
helpful?
This
will
help.
You
know
what
to
expect
when
you
open
an
issue
or
pull
requests.
A
Most
maintainer,
czar
volunteers,
so
being
unresponsive
doesn't
mean
that
they're,
rude
they're,
just
busy
or
burnt
out
knowing
the
communication
style
of
maintained,
errs
upfront
can
help
you
be
more
prepared
when
you
open
that
first
issue
or
pull
requests
just
as
most
maintainer,
Zoar
volunteers
and
open
source,
you
are
a
volunteer
too.
You
don't
have
to
work
for
free
for
the
maintainer
or
other
contributors
aren't
respectful
of
you,
it's
okay
to
say
no
planned,
go
work
on
other
open-source
projects.
A
There
are
projects
that
I
use
in
my
applications
that
I
won't
contribute
to,
because
I
know
the
maintainer
x'
don't
treat
other
contributors
the
way
they
should
and
I
don't
want
to
interact
with
them.
In
order
to
get
my
bug
fixed,
there
is
no
requirement
that
you
voluntarily
work
on
open
source
projects
where
maintainer,
x'
or
other
contributors
are
rude
to
you
for
accepted
contributions
and
fixed
issues
observe
to
see
if
maintainer
x'
give
feedback
and
say.
Thank
you.
Instead
of
helping
contributors
wrap
up,
some
maintainer
x'
will
fix,
pull
requests
for
you
and
merge.
A
I
don't
think
this
is
okay.
Yes,
it's
faster,
but
it
won't
help
new
contributors
do
better
in
the
future,
which
means
maintainer,
x'
are
creating
more
work
for
themselves.
If
you
find
a
project
where
maintainer
x'
are
helpful,
give
feedback
and
say
thank
you
for
your
contribution,
keep
working
on
that
project
because
you
found
like
a
good
one.
It
only
takes
two
seconds
to
say
thank
you,
and
it
makes
open-source
way
better
for
everyone
involved.
A
big
part
of
contributing
an
open-source
is
to
learn
how
to
accept
rejection.
A
It's
really
demoralizing
to
not
have
your
poll
request
accepted,
but
often
maintainer
x'
have
a
vision
for
their
project
and
that's
a
big
reason
why
pull
requests
are
accepted
or
rejected.
I've
had
many
pull
requests
get
rejected
and
it's
not
fun.
I
understand
how
it
feels,
but
don't
take
that
rejection.
Personally,
it's
all
part
of
contributing
to
open
source
ask
for
advice
on
how
to
do
better
next
time
and
apply
that
to
your
future
work
once
you
do
find
a
community
to
contribute
to
be
as
respectful
as
you
want.
A
Maintainer
x'
to
treat
you
hitting
a
bug
in
an
open-source
project
is
frustrating,
but
maintaining
a
project
is
really
hard
too.
Most
maintainer
x'
are
volunteers.
So,
while
the
majority
of
this
talk
was
about
how
maintainer
x'
can
do
better
contributors
could
do
better
to
treat
maintainer
is
the
way
you
want
to
be
treated.
If
you
were
a
maintainer
of
that
project,
there
are
a
ton
of
resources
to
help
contributors
and
maintain
errs,
have
better
experiences
and
build
more
sustainable
communities.
First
timers
only
your
first
PR
and
code
triage
help.
A
A
A
It's
our
responsibility
to
build
welcoming
communities
so
that
open
source
is
sustainable
and
inspirational.
We
can
do
this
by
mentoring,
asking
for
help
when
we
need
it
and
demanding
that
we
all
treat
each
other
with
respect.
Let's
build
a
world
where,
instead
of
ending
up
on
an
island
burning
out
for
maintaining
projects
alone,
we
get
to
work
with
bright
minds
and
share
ideas
in
a
healthy,
sustainable
community.
The
benefits
are
endless.
Building
a
better
community
will
attract
more
contributors.
This
makes
open
source
communities
more
stable
and
sustainable.
A
Let's
build
open
source
communities
where
less
contributors
experience
dragwon,
contributing
because
they're,
vulnerable
and
afraid
and
more
contributors
experience
that
high,
because
they
were
inspired
by
their
vulnerability
to
build
something
amazing.
For
your
project,
we
must
work
together
to
create
more
sustainable
open-source
communities.
The
future
of
open-source
depends
on
all
of
us.
I
hope
the
maintainer
x'
in
this
room
are
inspired
to
build
to
go
out
and
build
better
open-source
communities.
A
I
hope
that
the
folks
in
this
room,
who
have
never
contributed
to
open-source,
feel
inspired,
move
past
that
vulnerability
and
contribute
and
I
hope
that
everyone
will
respect
each
other
and
recognize
the
vulnerability
that
every
single
person
needs
to
overcome
in
order
to
contribute
to
open
source
the
job
of
growing.
These
communities
doesn't
lie
solely
on
one
maintainer,
one
contributor
or
one
project
shoulders.
The
responsibility
is
all
of
ours
to
build
the
communities
we
want,
whether
we're
a
contributor,
maintainer
or
user.