►
Description
Presented by Sara Cope, Engineer, and Courney Brousseau, Civic Digital Fellow, at Code.gov
At the end of the government shutdown, Sara found herself as the single developer responsible for more than 20 open source projects. To keep everything afloat, she needed help from the open source community. This talk will dive in to how to stay sane when you’re a solo team member, conducting usability research on your open source projects and crafting an intentional contributor experience to grow your community.
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
So
code
gov
was
created
out
of
the
federal
source
code
policy,
which
was
actually
released
in
August
of
2016.
Now,
in
that
policy,
it
said
that
federal
agencies
had
to
open-source
at
least
20%
of
their
code,
and
so
code
gov
was
created
in
order
to
house
an
inventory.
All
that
code
was
that
was
being
open
sourced
and
the
point
of
this
was
to
not
only
have
a
place
to
share
it,
but
create
a
place
where
folks
can
come
and
find
that
code
and
reuse
it
and
contribute
to
it.
A
I
actually
joined
the
code.
Gov
team
about
a
year
ago,
at
the
end
of
summer
of
2018-
and
here
we
are-
this-
is
part
of
our
team
that
we
had
a
hackathon
event
for
George
Washington,
University
students.
We
actually
did
several
hackathons
last
year
and
we
saw
some
common
themes
coming
out
from
those
events.
We
would
always
go
through
our
project
repositories
and
provide
those
to
people.
So
if
they
wanted
to
contribute
to
the
code
gov
platform,
they
were
able
to
we'd,
introduce
it
to
them.
A
We've
set
up
some
issues
and
make
sure
there
were
beginning
beginner-friendly
issues
and
ask
folks
to
contribute,
but
we
did
notice
some
problems
there.
So
some
of
the
problems
that
we
had
was
in
the
code
gov
platform.
We
actually
had
a
lot
of
repos.
There
were
more
than
20
available,
not
only
for
the
platform
itself,
but
some
of
the
tools
we
used
and
some
of
the
other
products
and
documentation
that
we
created.
A
A
They
didn't
always
get
it
up
and
running
depending
on
what
operating
system
they
were
using
on
their
machine.
If
they
were
able
to
get
the
platform
up
and
running
locally,
they
sometimes
missed
out
on
a
few
things
that
weren't
clear.
So
if
they
didn't
request
their
own
API
key
or
they
didn't
request
the
design
system,
you
still
weren't
getting
the
full
platform
experience.
A
A
A
A
When
a
government
shutdown
happens,
federal
employees
are
not
allowed
to
work
and
it's
really
gray
weather
that
continues
to
open
source
repos
or
not.
It's
actually
illegal
for
us
to
continue
working
in
a
volunteer
state.
So
we
didn't
make
any
progress
on
the
platform
and
when
I
did
return
to
work,
I
did
so
on
a
smaller
team.
A
The
two
other
engineers
who
are
on
the
code
gov
team,
had
moved
on
during
the
government
shutdown,
so
I
went
from
being
on
an
engineering
team
to
just
being
the
engineering
team
and
while
I
was
super
excited
to
be
back
to
work
at
the
end
of
the
government,
shutdown
to
say,
I
was
absolutely
panicked
and
terrified
would
be
a
super
understatement.
This
is
literally
me
at
one
point.
I
was
also
working
on
three
other
projects,
while
working
on
the
code
of
platform,
I
wasn't
on
the
project.
Full-Time
and
I
was
actually
new
to
react.
A
A
So
I
knew
right
off
the
bat
that
I
had
to
take
a
step
back
and
figure
out
what
I
needed
to
do
to
keep
it
all
together,
I
really
had
to
focus
on
the
small
things
and
ask
myself
every
day.
What
can
I
do
today
to
create
a
better
tomorrow
for
myself
and
a
lot
of
times
that
just
meant
reading
some
more
documentation
adding
another
test,
automating
some
small
tasks
that
make
a
big
difference
in
the
long
run.
I
also
knew
I
needed
to
keep
advocating
for
more
team
members
within
the
federal
government.
A
It
can
be
a
super,
hard
and
slow
process
to
add
members
to
the
team.
So
I
kept
my
voice
up
and
be
sure
to
ask
for
more
team
members.
I
also
asked
for
help
not
only
from
what's
in
our
team
but
from
the
other
engineers
within
our
organization.
We're
lucky
enough
to
have
a
really
great
organization
within
TTS
of
18f
and
innovation
teams.
A
So
I
was
able
to
tap
into
those
folks
and
ask
for
help
and
in
the
end,
I
just
had
to
remember
to
give
myself
grace
if
the
platform
burned
down,
it'll
be
fine
because
we're
open
source
and
we
use
version
control
and
everything's
on
github,
so
I
knew
if
I
published
anything
that
was
bad.
We
could
just
always
roll
it
back
and
that
helped
give
me
confidence.
A
What
do
we
do
right
away?
We
put
a
freeze
on
new
feature
development,
because
new
features
are
great,
but
if
you
don't
feel
confident
and
trust
your
platform,
you
don't
want
to
keep
moving
forward.
At
the
same
time,
we
also
knew
that
we
had
to
keep
doing
our
security
updates,
so
we
are
addressing
any
vulnerabilities
as
they
came.
Along
tests
became
a
much
higher
priority,
adding
more
tests
to
more
platforms
everywhere
and
adding
those
to
continuous
integration
to
automate
them,
and
then
we
also
kicked
off
our
contributor
experience,
user
research.
B
B
These
are
some
of
the
tools
that
the
team
used,
which
we
had
at
our
disposal.
Luckily
to
keep
notes
to
hangouts
and
video
chats
and
advertise
our
user
research
to
get
participants.
Some
of
the
things
that
the
team
learned
that
are
gonna
be
used
going
forward
with
future
research,
or
we
know
that
sometimes
people
don't
have
the
ability
to
use
Google,
Hangouts
or
me
for
whatever
reason.
So
we
always
have
a
backup
ready.
B
So
that's
not
a
last-minute
barrier
to
doing
some
research,
it's
important
to
set
up
some
folders
and
templates
and
documents
beforehand,
so
that
it's
easy
to
keep
everything
organized
as
we
go
through
the
process.
And
finally,
it's
important
to
book
at
least
50
minutes
with
user
researchers.
Research
participants,
anything
less
just
doesn't
get
your
really
valuable
insights,
an
in
terms
of
how
we
could
improve
the
contributor
experience.
B
There
are
four
major
barriers
that
we
identified
that
discourage
people
from
contributing
to
our
projects
or
to
open
source
project
in
general
that
we
wanted
to
work
on
addressing
so
one
of
them
was
if
people
found
a
project
that
hadn't
been
participate
or
hadn't
been
contributed
to
or
changed
in
a
long
time
they
really
weren't
interested
in
contributing
they
weren't
sure
if
their
contribution
was
going
to
be
accepted.
If
it
was
going
to
be
helpful
at
all,
and
so
they
were
definitely
discourage
them
from
participating.
B
We
knew
we
had
some
code
gov
repos
that
were
old
or
archived
that
we
need
to
make
sure
we're
clear
that
they
weren't
active
projects
that
we
needed
help
with
the
second
thing:
is
we
really
needed
to
focus
on
good
documentation?
It's
a
really
important,
but
you
know
frequently
overlooked
part
of
having
a
high-quality,
open
source
project.
That's
easy
to
contribute
to
and
with
our
project,
specifically
with
so
many
different
repos
that
contribute
to
one
platform
having
clear
documentation
about
how
they
all
connect
is
really
important.
B
We
also
found
that
people
really
valued
a
code
of
conduct,
not
just
one
that
was
there,
but
one
that
was
enforced.
So
we
thought
a
little
bit
about
how
to
address
that
concern,
and
finally,
people
were
much
more
likely
to
contribute
to
a
project
when
they
were
other
participants,
contributing
they
felt
like.
That
was
a
signal
that
the
project
was
welcoming
to
outside
contributors
and
that
their
contributions
would
be.
You
know,
seen
valued
merged
and
actually
put
into
production
if
possible.
A
So
thinking
about
those
barriers
to
contribution,
we
decided
to
focus
in
on
four
major
areas
to
tackle
and
I'm
gonna
go
suit
through
some
of
those
today,
but
we
actually
ended
up
with
a
whole
spreadsheet
of
items.
So
if
anyone
wants
that
later,
we
can
connect
and
you
can
share
it.
The
first
area
that
we
focused
in
on
was
documentation.
We
saw
a
huge
issue
with
documentation
on
our
project.
A
Right
off
the
bat.
We
decided
to
set
a
minimum
level
of
documents
that
we
were
going
to
create
and
include
on
each
repo.
That
way,
folks
who
are
coming
recognized
immediately
that
this
is
a
code
dog
or
a
repo.
They
knew
where
to
get
the
documents
they
were
looking
for
and
it
established
some
consistency.
A
We
also
took
the
time
to
redo
all
of
our
tags
across
all
of
our
repos.
So
if
you
went
to
one
of
our
repos,
it
would
have
different
tags
labels
than
one
of
the
other
repos,
which
again
was
super
confusing
to
people,
and
it
didn't
really
help
us
stay
organized.
So
we
used
an
automated
tool
to
create
a
standard,
JSON
file
of
tags
and
upload
those
across
the
VAR
repos.
A
We
also
spent
a
lot
of
time
incrementally
just
making
updates
to
the
documentation
and
re
looking
at
that
with
users,
so
that
it
made
more
sense
how
all
the
pieces
of
the
platform
work
together
and
where
you
needed
to
go
to
do
what
we
also
took
a
look
at
transparency,
so
we
added
some
badges
for
testing
and
continuous
integration
to
our
platforms.
Things
like
circle,
CI,
and
just
one
of
the
things
that
was
surprising
to
us
in
our
research
is
people
really
liked
those
badges.
A
We
also
worked
on
our
release,
notes
and
making
those
more
detailed
and
using
those
more
often
and
publishing
those
not
only
on
github
but
to
our
listserv
into
our
slack,
so
that
people
are
more
able
more
easily
able
to
see
our
updates
in
different
places.
We
also
have
a
product
roadmap
publish
to
code
gov.
So
if
you
go
to
the
footer
of
our
site,
you
can
click
on
our
roadmap
and
see
what
we're
up
to.
A
We've
also
taken
a
look
at
community
engagement,
so
we've
started
explicitly
thanking
our
contributors
and
release
notes.
We
also
have
published
our
mission
and
vision
to
the
home
page
of
our
site
to
help
show
people
what
we're
doing
and
why
the
work
we're
doing
is
important
to
help
them
create
a
connection,
we're
working
to
acknowledge
issues
and
floor
requests
within
24
hours.
Even
if
we're
not
able
to
work
on
those
right
away,
we
want
to
make
sure
people
know
that
we're
active
we're
seeing
their
contribution
and
we
appreciate
it.
B
As
I
mentioned
earlier,
I
joined
the
team
for
this
summer
as
a
civic
digital
fellow.
It's
a
really
cool
program
that
tries
to
bring
college
students
interested
in
mission
driven
work
into
government
as
a
product
manager,
a
designer
data
scientist
or
a
software
engineer.
And
so
as
one
of
the
fellows
this
summer,
working
with
the
code,
gov
team
I
got
to
work
on
some
of
the
projects
that
Sarah
was
just
talking
about.
They
specifically
worked
on
a
project
around
defining
and
tracking
our
engagement
metrics
on
github.
B
I
first
looked
to
see
if
there
was
anything
that
already
existed.
That
did
this,
but
I
was
unsuccessful
in
finding
any
open
source
project
that
did
what
we
needed.
So
I
went
about
the
process
of
creating
a
new
command-line
interface,
which
uses
the
new
graph
QL
github
API,
to
extract
these
metrics
from
all
of
our
different
repos
and
put
them
in
one
CSV
file
that
we
can
import
into
a
Google
spreadsheet
like
all
of
our
repos.
B
This
repo
is
open
source,
and
so,
if
you
want
to
use
this
command
line
tool
yourself,
it's
available
on
our
GSA
github
organization
and
you
can
feel
free
to
contribute
or
fork
it
if
you'd
like.
But
it
really
helps
us
visualize
as
a
team.
How
many
people
are
contributing,
how
many
issues
our
sale,
all
these
different
metrics?
That
really
help
us
understand
if
we're
improving
the
contributor
experience
across
our
platform
as
a
whole.
B
B
The
second
thing
is
that,
as
Sarah
previously
mentioned,
there
was
a
government
shutdown
in
January,
December
January,
and
so
you
can
see
the
impact
of
that
really
clearly
on
this
graph.
Internal
contributors
goes
basically
to
zero
and
we
don't
really
see
a
lot
of
external
contributors
which
we
think
has
to
do
with
the
fact
that
people
didn't
want
to
contribute
if
I
knew
their
contribution
wasn't
going
to
be
seen
merged
soon
and
then.
B
Finally,
we
can
see
that
in
the
last
few
months,
we've
actually
seen
a
lot
of
new,
first-time
contributors
or
more
that
we
didn't.
Then
we
did
in
the
past.
So
we
want
to
continue
to
try
and
get
that
green
bar
to
be
bigger,
have
more
external,
first-time
contributors
and
grow
the
amount
of
people
that
are
making
coke
of
a
great
site
to
host.
All
of
these
other
amazing
open-source
repos.
A
So
for
all
the
work
that
we
have
done
so
far,
we
wanted
to
make
sure
that
we
were
retesting
with
users
and
making
sure
those
developers
could
more
easily
contribute
to
our
platform
and
we
weren't
just
doing
all
these
changes
for
fun.
So
to
follow
up
we're
going
to
be
conducting
monthly
user
interviews
at
a
small
scale.
A
We've
done
one
of
those
in
September
this
year
already
as
an
experiment
and
we're
going
to
continue
that
in
the
new
year
for
these
user
interviews,
we're
just
going
to
be
testing
three
users
on
one
day
once
a
month
will
be
immediately
debriefing
and
gathering
that
information
in
a
one
pager
and
then
adding
those
issues
to
our
github
repos
into
our
backlog
for
action.
The
idea
here
is
to
clear
out
any
major
blockers
that
we
can
identify
with
our
contributor
experience
and
continue
to
iterate
and
make
it
easier.
A
As
a
team,
we'll
continue
to
work
on
small
incremental
changes
every
day,
because
that's
what
public
service
is
about.
We
work
in
public
service
because
we
get
the
chance
to
work
hard
at
work
worth
doing
so.
I
want
to
thank
those
people
who
have
walked
along
this
journey
with
me
along
the
way,
and
thank
you
today.
A
C
D
A
The
question
is:
how
do
we
differentiate
the
experience
between
onboarding
developers
versus
other
folks
who
might
be
doing
UX
or
UI?
Okay,
so,
in
our
two
rounds
of
you
know,
testing
they
weren't
all
focused
on
developers.
Our
first
round
of
testing
was
actually
it
did
include
a
lot
of
tasks.
It
was
more
asking
people
questions.
What
do
you
do?
How
do
you
contribute?
What
things
do
you
look
for?
A
What's
important
to
you
and
then
the
follow-on
research
user
research
we
did
was
more
developer
focused
and
in
the
September
interviews
again
we
had
to
developers
and
one
person
who
wasn't
a
developer,
so
we're
trying
to
not
just
like
shoehorn
ourselves
into
the
developer,
experience
and
get
feedback
from
other
folks
as
well
as
far
as
UX
and
UI.
We
haven't
specifically
focused
on
that
area.
Okay,.
B
A
And
I've
done
a
lot
of
work
with
students
through
a
local
program
and
folks
with
no
developer
experience,
so
I
try
to
approach
our
repos
with
a
very
beginner
mindset
from
the
outside.
So
if
you're
really
new
to
code,
if
you
don't
even
want
to
code,
there
are
still
ways
that
you
can
contribute
and
actually
a
lot
of
the
contributions
we
got
through
October
and
October
fest,
where
documentation
issues
where
folks
could
come
in
and
make
documentation
updates
for
us
any
other.
We.
C
A
C
My
name
is
Garrett
link
I'm
with
Patricia.
Thank
you
very
much
for
sharing
your
insights
on
how
to
make
projects
more
accessible
to
contributors.
The
question
is
whether
you
are
doing
this
for
the
repositories
that
the
GSA
is
responsible
for,
or
also
for
all
of
the
contributed
code
that
is
contributed
to
that
code
platform.
Yeah.
All
the
other
agencies
that
have
to
produce
open-source
yeah.
A
That's
a
great
question,
so
our
initial
goal
was
to
improve
the
code
gov
platform
itself
in
all
of
the
repos
that
we
are
immediately
in
charge
of
and
then
to
follow
that
on
we're
gonna
work
with
federal
agencies
to
improve
their
repos
as
well.
We
wanted
to
start
off
with
code
gov
so
that
we
were
sure
we
were
setting
the
example
that
we
wanted
to
see
in
other
federal
agencies.
A
F
A
Our
original
code
of
conduct
was
in
place
when
I
started,
but
after
doing
some
of
our
research,
we
actually
moved
to
a
more
widely
known
code
of
conduct.
The
contributor
covenant,
if
you're
familiar
with
that.
So
now
we
have
that
honor
repose
and
it
allows
people
to
come
in
and
see
right
off
the
bat.
If
they're
more
familiar
with
that
code
of
conduct,
it
builds
trust
quicker
and
more
easily.
Instead
of
having
something
that
was
more.
E
A
Maybe
Courtney
can
speak
about
the
metrics,
but
I
can
speak
clearly
from
my
observation
from
the
user
interviews
that
I
did
in
September,
we
interviewed
three
users.
Two
of
those
were
developers
and
I
asked
both
of
them
to
pull
down
the
platform
and
get
it
running
locally
on
the
machine
with
like
no
prompting
or
extra
help
for
me,
and
they
were
both
able
to
do
that
within
a
couple
minutes.
A
So
for
us
I
feel
like
that's
a
big
win,
because
before
when
we
went
to
events,
we
had
to
have
an
engineer
on
site
kind
of
leading
people
through
here's
the
platform.
Here's
where
you
need
to
go
and
now
folks
are
able
to
actually
pulled
on
and
get
it
running
locally
on
their
own
without
us,
like
sitting
over
their
shoulders.
Yeah.