►
Description
Presented by:
Kat Fukui, Product Designer, GitHub
Mike McQuaid, Software Engineer, GitHub
GitHub is powered by its open source community. In this session, we’ll talk about what makes an open source project successful, and what workflow tools for communities we’ve been building to help them be happier places.
Whether you’re a maintainer, existing open source contributor or looking to make your first ever contribution, this session will help you make the most out of the open source community on GitHub.
At Satellite 2017, attendees came to exchange cutting edge practices on how to bring together the people and tools you need to build great software. Watch the recordings to find out what GitHub's been working on, and hear how other teams use the GitHub ecosystem to customize the way they work.
We'll be getting together again in San Francisco on October 10th-12th for GitHub Universe. We hope you'll join us for three days filled with the creativity and curiosity of the largest software community in the world.
For more information, go to githubuniverse.com.
B
A
We're
going
to
walk
you
through
today
like
a
couple
of
different
things,
and
so
firstly,
what
open
source
project,
what
open
source
software
is
on
github,
how
to
create
some
inclusive,
open
source
communities
on
github
and
how
to
improve
the
interactions
within
those
open
source
communities,
whether
you're
doing
so
as
a
user
as
a
contributor
or
a
maintainer.
So,
firstly,
let's
start
by
having
a
wee
look
at
what
opens
to
our
software.
A
It
looks
like
on
Yelp
and
to
do
that
we're
going
to
break
down
the
repos
that
are
on
github
today,
so
github,
you
probably
saw
in
Chris's
talk
earlier.
We've
got
21
million
developers
roughly
today
and
roughly
about
58
million
repositories.
So
as
I'm
sure
you
all
know,
repositories
can
be
either
public,
which
means
anyone
can
access
them
or
private,
which
means
they're
restricted
to
a
smaller
number
of
users.
A
A
Things
like
that
and
I
think
open
source
for
github
is
our
most
one
of
our
most
important
attributes
and
we
really
like
to
kind
of
talk
about
and
think
about
what
happens
with
open
source
projects
at
scale,
because,
as
we're
going
to
talk
about
in
this
talk,
I
think
there's
various
interactions
in
open
source
communities
which
are
fine
on
a
small
scale.
But
then,
as
projects
get
bigger
and
bigger,
become
potentially
problematic
or
at
least
difficult.
So
here's
some
examples
of
for
open
source
projects
that
I
think
are
really
really
successful.
On
your
hob.
A
So
obviously,
when
you're
a
project
at
these
sort
of
scale,
you're
going
to
have
different
problems
to
a
project
that
has
ten
contributors
or
hundreds
of
commits
and
I
think
what
makes
these
projects
really
special
is
they're
ones
that
we
have
specifically
recognizes
projects
that
are
welcoming
to
new
contributors.
Despite
the
fact
that
they've
got
so
massive
and
despite
the
fact
that
they're
used
by
millions
of
people
daily
to
kind
of
learn
how
to
code
to
work
on
production
software
systems
and
for
some
people
just
mess
around
and
play.
A
B
Question
Mike
well,
I
think
the
key
to
success
lies
in
first
understanding
that
open
source
on
github
is
not
just
about
the
software.
It's
about
the
people.
So
how
can
we
scale
a
single
positive
interaction
in
a
community
such
as
rails
or
node
to
up
to
thousands
of
people?
So
let's
talk
through
a
typical,
open
source
string
and
github.
So
here
we
go,
we've
got
a
developer
and
she
uploads
her
code
on
github
and
it
starts
getting
attention.
So
maybe
people
on
Twitter
are
talking
about
it.
B
Maybe
it
starts
trending
on
github
and
people
are
cloning.
It
forking
it
and
starring
it.
So
there's
this
turning
point,
though,
where
it
becomes
from
an
open
source
project
to
a
community
and
that's
when
it
gets
his
first
issue
or
pull
request
for
a
non
collaborator,
so
this
person
might
not
be
in
the
same
time
zone.
She
might
not
know
this
person
in
real
life
and
that's
really
exciting,
but
in
order
to
scale
from
that
point
from
that
very
first
issue.
Yet
to
think
you
know,
if
I'm
doing
one
or
two
bug
visits
this
week.
B
What
if
that
scales
up
to
50
issues-
and
you
know
50-
pull
requests
that
I
need
to
do
code
review
at
that
point,
it's
really
crucial
to
find
repeat
contributors
and
that's
the
key
to
scaling
up.
You
need
to
find
people
who
are
being
converted
from
users
to
repeat
contributors
and
contributors
that
are
now
turning
into
maintainer
and
those
are
all
positive
interactions
that
creates
this
community.
But
on
the
flip
side,
if
there
are
some,
it's
not
so
positive
interactions
that
can
happen.
B
So,
let's
go
through
a
journey
nice
where
that
could
be
possible
so
same
journey
but
she's
looking
for
some
repeat
contributors.
Unfortunately,
maybe
there
was
a
bad
first
impression
by
this
new
potential
contributor,
for
example,
maybe
it
took
a
while
for
her
to
respond
to
this
person's
first
issue
in
PR,
if
you've
ever
contributed
to
open
source
for
the
first
time.
You
know
that
it
can
be
really
intimidating
and
it
doesn't
feel
that
great.
Maybe
there
were
some
rude
interactions.
Maybe
unconstructive
criticism
on
the
floor
quest
and
maybe
the
contributing
guidelines
weren't
relevant
'add.
B
So
this
poor
quest
wasn't
set
up
for
success
and
was
ended
up
being
closed
out,
but
also
doesn't
feel
really
good
and
when
you
don't
have
that
help
to
scale
your
community.
That
really
leads
to
maintainer
burn
out
all
of
the
time,
and
you
know
this
also
doesn't
feel
great.
So
how
can
we
keep
encouraging
more
positive
interactions
in
communities
to
create
more
inclusive,
open
source
spaces,
and
right
here
is
a
cycle
of
success
that
we
are
really
building
a
framework
around
of
github
and
it
can
determine
if
a
community
and
scale
or
not?
B
So
it's
really
important
in
order
to
maintain
the
code,
the
growth
of
documentation
and
also
a
user
base.
But
in
order
to
do
that,
you
need
to
have
sustainable
growth,
but
also
have
a
mechanism
to
moderate
the
users
that
are
coming
into
your
project,
so
you
saw
earlier
in
those
examples
there
are
over
a
thousand
contributors
at
that
point.
You
need
to
be
able
to
do
every
single
stage
in
this
cycle
and
if
there
are
enough
resources,
a
community
can
really
struggle
at
that
point.
B
So
in
the
maintaining
stage
we
just
released
this
last
week
and
it's
the
add,
a
code
of
conduct
tool
to
your
posit
ory
tada,
so
for
some
context,
a
code
of
conduct,
the
document
that
explains
the
baseline
of
behaviors
and
expectations
of
your
project.
So
here
we
have
some
templates
like
you
can
choose
from,
and
it's
super
super
easy
to
fill
in
your
information
and
adopt
it
right
from
there
out-of-the-box.
And
why
do
we
think
this
is
really
important
for
your
community?
Well,
it
really
helps.
B
You
know,
first
of
all,
understanding
that
everyone
that
contributes
has
to
have
a
certain
behavior
and
that
we
want
to
foster
this
really
positive
social
atmosphere
and,
in
the
end
it
can
help
reduce
the
fatigue
that
meant
a
nerds
have
with
dealing
with
human
to
human
interactions
and
sometimes
I
think
it's
harder
to
maintain
those
human
interactions
than
maintaining
code.
So
here
it
is
in
action,
super
easy.
B
B
This
is
it
and
it's
a
way
to
see
how
your
community
compares
to
open
source
standards
and
for
the
first
iteration.
We
have
this
awesome
checklist.
That
shows
you
how
the
Trinity
stands
up
to.
Having
a
readme
a
code
of
conduct,
contributing
guidelines
and
a
license
so
say:
you're,
not
sure
when's,
the
right
time
to
add
a
contributing
guideline
into
your
community,
and
maybe
you
don't
know
how
to
write
one.
We
want
to
be
there
with
you
at
every
step
of
the
way
as
you're
growing,
and
this
was
really
you
know.
B
That's
the
reason
why
we
built
this,
because
we
understand
that
a
community
has
different
needs
as
it
grows,
and
we
want
to
be
there
with
you
to
help
you
build
the
best
community
possible.
So
right
now
it's
an
early
access
beta,
but
it
will
be
available
in
the
next
two
weeks
or
so,
and
another
shiny
new
thing
that
we've
been
working
on
in
the
moderating
stage
are
the
temporary
interaction
limits,
and
these
are
ways
to
force
like
sort
of
a
cool-down
period
in
your
repository,
so
you
can
actually
limit.
B
Who
is
interacting
so
commenting,
opening
up
issues
and
pull
requests?
You
can
limit
it
to
existing
users.
So
in
this
example
right
here
say,
someone
has
been
creating
a
lot
of
sock
puppet
accounts
and
maybe
even
spamming
or
harassing
any
members
on
your
community.
So
you
can
limit
it
to
people
who
are
prior
users
and
preventing
people
who
have
just
created
a
new
account
from
interacting
with
your
repository
and
you
know,
even
internally,
at
github,
because
we're
actually
a
remote
in
a
synchronous
company.
B
We
understand
that
it's
really
easy
to
misunderstand
people
through
a
text
based
medium
completely
online
I
mean
we're
all
human
and
it
happens.
So
sometimes
it's
good
to
restrict,
who
is
like
communicating
in
the
repository
to
you,
know,
give
everyone
space
think
about
it.
Calm
down,
come
back
fresh
and
you
know
attack
it
from
there,
but
also
dealing
with
the
harassment
that
is,
that
sometimes
happens
in
repositories
collections.
B
So
you
can
go
to
your
repository
settings
and
it's
in
there
in
the
toggles
every
24
hours,
and
this
is
also
in
early
access
and
leave
rolling
out
in
the
next
week
or
two
so
going
back
into
how
all
of
the
new
features
play
into
this
model
of
success.
We
release
the
code
of
conduct
tool
to
help
you
maintain
your
community's
expectations
and
also
the
interactions
from
users.
We
have
the
community
profile
and
make
first-time
contributor
edge
to
help.
B
A
A
Think
the
socialist
solutions
I'm
going
to
talk
through
are
looking
at
a
different
way,
perhaps
of
interacting
with
open-source
projects,
whether
you're
a
user,
whether
you're
a
contributor
or
whether
you're
a
maintainer,
I,
think
there's
little
things
you
can
do
whether
you're
in
any
of
these
groups
and
again,
you
may
well
find
yourself
in
different
groups
for
different
pieces
of
software.
I'm.
A
And
someone
who's,
not
a
maintainer
ie
someone
who
doesn't
have
commit
access
to
that
project
and
can't
make
changes
or
close
issues
or
whatever.
So
this
is
something
where
I'm
interacting
with
this
software,
primarily
because
it's
something
I'd,
probably
use
or
my
company
uses
or
I'm
trying
to
learn
it
and
I'm
just
trying
to
make
sure
that
that
is
a
positive
interaction.
So
I
think
the
first
thing
is
setting
your
expectations
accordingly.
A
That
might
not
be
that
obvious
and
as
a
result,
if
you
just
set
them,
maybe
a
little
bit
lower
than
you
might
do
for
a
commercial
project
of
the
same
level.
I
think
that's
reasonable.
When
I
say
expectations,
I
don't
mean
the
quality
of
the
software,
but
I
mean
the
quality
of
perhaps
the
support
experience
you
get,
for
example,
homebrew,
which
is
a
project
I
work
on
and
one
of
the
main
Tainos.
For
that
you
know
we're
entirely
run
by
volunteers.
A
So
when
someone
comes
along
and
it's
using
Humber
to
do
their
job,
I
understand
that
it
can
be
quite
frustrating
for
them.
Apron
boot
doesn't
work
the
way
they
want,
but
at
the
same
time,
when
I'm
answering
their
messages
at
9
p.m.
in
my
evening
off,
there
are
four
days
of
work
that
work.
I'm
not
gonna,
be
able
to
give
quite
the
amount
of
time
and
energy
to
that.
That
I
might
be
able
to
give
where
it's
something.
A
That's
part
of
my
job,
so
that
the
next
thing
that
kind
of
relates
to
the
prior
one
is
everyone
just
helping
out.
However,
they
can
so
if
you
use
a
piece
of
software
for
a
non-trivial
amount
of
time,
then
you're
going
to
become
more
knowledgeable
than
someone
who
just
used
it
on
day.
One
so
I
think
again
a
good
thing
with
open
source
to
think
about.
It's
like
everyone
is
capable
with
helping
out.
You
may
not
be
able
to
spend
lots
of
time
doing
things
you
may
not
be
able
to
spend.
A
You
know
lots
of
effort
or
whatever,
but
if
you
go
and
if
you
need
help
from
someone
else,
if
you'd
help
from
the
open
source
project
and
you
notice,
while
you're
doing
that
that
there's
someone
else
who
needs
help
and
someone
else
has
a
question
that
you
could
maybe
answer
then
like
I,
would
really
encourage
you
to
think
about
doing
that.
Like
I,
think
it's
a
really
great
thing
about
open
source
communities,
because
these
interactions
are
in
the
open.
A
The
if
I'm,
asleep
and
I
can't
answer
a
question
for
someone,
because
of
that
that
someone
else
in
the
community
can
go
and
come
and
help
them
and
answer
their
question.
Maybe
before
I
woke
up,
and
even
within
that
as
well
as
sometimes
if
you
do
this
and
like
a
considerate
and
careful
and
can
and
I
guess,
an
empathetic
way
trying
to
encourage
people
to
have
more
positive
interactions
themselves,
so
someone
might
submit
a
bug
report,
I'm
sure
if
you're
a
software
or
you've
seen
one
of
these
and
the
bug
report
is
more
or
less.
A
A
So
in
an
open-source
project,
for
example,
like
the
ones
we
saw
before
and
where
you
have
thousands
of
contributors,
you
have
millions
of
users
and
many
cases
and
maintainer
is
in
some
cases
with
some
of
these
projects.
There
may
only
be
single
or
double
digits
where
the
maintainer
is
so
as
a
result,
not
every
maintainer
can
help
every
user
with
every
issue
they
have
and
as
a
result,
if
you're
expecting
help
from
people,
then
you
need
to
try
and
do
a
little
bit
of
homework
yourself.
A
Do
some
of
the
legwork,
maybe
go
and
say:
okay,
here's
what
I've
tried
already
to
fix
my
problem?
Here's!
What
I
looked
here's?
What
I!
You
know
my
kind
of
inkling
on
what
the
problem
might,
because,
again,
all
these
things
they
just
help
to
mean
that
someone
else
is
able
to
solve
your
problem
quicker.
A
So
moving
on
the
contributors
now,
as
I
mentioned
before,
I
consider
a
contributor
to
be
anyone
who
has
at
least
attempted
to
submit
a
commit
or
a
pull
request
or
to
a
project.
So
I
think
the
thing
with
contribute.
Their
interactions
is
that
we're
trying
to
think
about?
How
can
we
get
our
stuff
accepted?
Is
it's
kind
of
desirable
to
the
project
and
it's
useful
to
us
and
it's
useful
to
them
like?
What
can
we
do
to
maximize
our
chances
of
success
and
also
again
consider
the
time
riverfront
who's
working
on
it?
A
So
a
good
starting
point
is
just
make
sure
you
kind
of
read
and
for
the
project
guidelines
in
general.
You
know
we
have
in
software
development
as
a
whole
issues
with
sometimes
not
writing
as
much
good
documentation
as
we
should
and
equally
I
think
we
have
issues.
I
know
I'm
guilty
of
this,
sometimes
of
like
not
reading.
All
the
documentation,
I
mean
you'll
need
to
read
online
about
the
problems.
People
have
with
assembling
IKEA
furniture
to
know
that
sometimes
reading
the
manual
is
not
always
the
first
thing
that
jumps
to
mind.
A
So
when
you
continue
to
an
open
source
project,
some
projects
don't
have
a
lot.
Some
projects
do
have
a
lot,
but
try
and
at
least
read
everything
that's
available
to
you.
Projects
now
on
github
have
issue
templates,
pull
request,
templates,
there's
a
contributing
MD
file
in
which
report
goes
and
just
try
and
make
sure
you've
read
through
them
and
follow
all
the
steps,
if
you're,
if
somebody's
contributed
before
try
and
make
sure
that
you
just
double-check
that
that
hasn't
changed,
there's
been
no
process
changes
or
whatever
and
again.
A
This
is
just
about
helping
yourself
to
like
maximize
the
chances
of
success.
Also
like
helping
prioritize
the
time,
someone
else
took
the
time
to
write
that
documentation.
So
it's
probably
beneficial
to
you.
If
you
take
the
time
to
read
through
as
well,
the
next
thing
is
deferring
to
maintain
errs
now.
That
sounds
a
little
bit
weird,
but
like
what
I'm
trying
to
say
here
is
not
that
antennas
are
always
right
or
anything
like
that.
A
What
I'm
trying
to
say
here
is
that
they
will
reach
a
point
in
any
perhaps
conversation
on
an
open-source
project
where
a
contributor
and
maintainer
is
arguing
on
whether
a
feature
should
be
in
a
project
or
not
in
a
project
or
whatever,
and
at
the
end
of
the
day,
you
need
to
accept
that
the
maintainer
is
the
ones
who
for
better
or
for
worse
or
running
the
project
on
a
day
to
day
basis.
So,
ultimately,
all
conversations
will
reach
a
point
where
even
maintainer
says
look.
A
This
is
kind
of
how
it
is
this
way,
or
this
way
like.
Hopefully,
you
can
kind
of
give
them
a
certain
amount
of
deference
that
you
can
say
well.
Okay,
you're
running
this
project.
I
may
disagree
with
you
on
this
instance,
perhaps
but
I'm
going
to
kind
of
defer
to
your
knowledge
on
this
and
hopefully
kind
of
have
a
positive
interaction
with
that
way
anyway,
and
the
final
thing
I've
encouraged
contributors
over
supplies,
the
users
as
well,
it's
stepping
outside
your
comfort
zone
so
to
serve
a
personal
anecdote.
A
So
I
guess
it
was
about
eight
years
ago
now,
I
kind
of
was
dabbling
with
the
homebrew
project
and
I
kind
of
knew,
a
guy
who
worked
on
it
and
stuff
like
that.
I
was
kind
of
trying
to
suggest
some
stuff
to
him
to
say:
hey,
maybe
it'd
be
better
with
this
without
the
other
and
he
kind
of
poked
me
to
say,
okay.
A
Well,
maybe
you
should
go
in
and
submit
a
pull
request
and
I
said
well,
I've,
never
written
any
Ruby
before
I,
don't
know
any
review
whatever,
and
then
you
fast
forward
a
few
years
later
and
now,
like
I'm
one
of
the
remain
Tanner's
and
I
write
Ruby,
mainly
as
my
job.
You
know
the
way
I
learned,
Ruby
is
through
open
source
and
through
contributed
penumbra,
originally
and
I.
A
So
I
was
able
to
write
some
fairly
horrendous
Ruby
that,
although
terrible,
was
still
useful
to
the
project
in
some
ways
and
I'm
able
to
kind
of
understand,
stuff
and
learn
from
that
and
get
better,
and
that
learning
process
has
made
me
better
for
homebrew,
and
it's
also
made
me
made
my
career
better,
and
it's
made
me
kind
of
better
for
future
employers
as
well.
So
I
think
it's
it's.
How
beneficial
for
everyone
to
try
and
like
take
that
step
outside
your
comfort
zone.
A
It
can
occupy
an
awful
lot
of
your
time.
I,
look
awful
lot
of
your
headspace,
sometimes
and
I.
Think
part
of
dealing
with
that
is
recognizing
a
couple
of
things.
Firstly,
an
open
source
project
without
any
maintainer
is
anymore,
is
basically
dead.
You
know
it
may
be
like
a
tree
that
is
died
from
the
outside,
like
it
looks
okay,
but
like
it's
going
to
rot
and
it's
going
to
fall
over
eventually.
A
So,
as
a
result,
you
need
to
prioritize
yourself
and
you
need,
as
a
maintainer
on
an
open
source
project
above
those
of
contributors
or
users.
Again,
that
sounds
harsh,
but
that's
the
realistic
reality
of
open
source
projects,
an
open
source
project
with
no
maintainer
is
cannot
receive
any
future.
Development
cannot
accept
any
pull
requests
and
will
eventually
fall
over.
So
on
a
personal
level.
A
So
it's
important
to
realize
and
set
those
boundaries.
The
next
thing
I
think
is
acting
as
a
force
multiplier
again.
Stepping
back
to
the
example,
I
said
before
before
I'd
ever
worked
on
homebrew
and
that
guy
Najd
me,
okay,
we'll
try
and
learn
some
Ruby
try
and
do
this,
so
he
could
have
sat
down
with
me
every
step
of
the
way
and
tried
to
kind
of
walk
me
through
all
this
stuff,
but
that
wouldn't
have
actually
been
the
best
use
of
his
time.
A
They
can
have
little
checks
like
rubric
or
whatever,
like
that
kind
of
guide
them
in
the
right
direction
and
the
other
fun
little
fact
I
found
personally
on
this
as
well,
is
that
people
respond
way
better
to
bot
telling
them
like
to
change
stuff
than
they
do
humans.
People
are
fine
with
pedantic
bots,
whereas
people
don't
like
pedantic
humans
very
much
and
then
finally
I
think
it's
considering
how
all
your
changes
within
a
project
affect
90%
of
users.
A
So
that's
just
a
number
I
pulled
out
the
top
of
my
head,
but
I
think
again,
the
verb
prints
was
protect.
It's
very
easy
to
get
kind
of
stuck
in
the
details
on
a
particular
pull
request
and
someone's
maybe
put
a
lot
of
time
into
a
pull
request
and
you
feel
kind
of
bad,
maybe
about
not
merging
it
or
about
not
accepting
it,
but
I.
A
Think
for
me
this
is
the
thing
I
always
come
back
to
is
like
how
is
this
feature
can
affect
90%
of
users
and
if
this
is
a
feature,
that's
going
to
be
used
by
5%
1%
0.1%
of
users
of
this
project.
But
if
that's
you
know
a
massive
code,
change
say
or
a
massive
refactoring
underneath
it
or
whatever
that's
going
to
have
consequences.
That's
going
to
have
its
own
bugs
it's
going
to
have
time
that
you're
going
to
have
to
spend
maintaining
the
stuff
and,
as
a
result,
for
90%
of
new
users.
A
A
So
that's
like
a
little
brief
walkthrough
of
some
of
the
ways.
I
think
that
are
beneficial
with
open
source
projects
to
kind
of
interact
better.
Obviously
you
could
talk
about
this
for
days.
I
do
but
I
would
really
recommend
you
going
to
work
if
you
haven't
already
seen
open
source
guide.
This
is
a
website
that
kind
of
getup
released
with
help
from
the
community,
help
from
I
think
maintainer
Jean
Mustafa's,
not
all
of
the
open
source
projects
I
mentioned
earlier
I'm.
A
Just
thinking
about
like
how
do
you
do
open
source
and
what
a
you
know
you
can
see
in
the
top
left.
You've
got
kind
of
the
most
kind
of
starting
from
kind
of
some
basic
things
of
like
how
do
you
even
contribute
their
interest
if
you're
someone
who's,
never
done
it
before?
Okay,
there's
guides
on
how
to
create
a
pull
request
and
stuff
like
that,
but
like?
A
How
do
you
find
a
project
that
you
want
to
work
on
and
thinking
through
these
types
of
problems
and
we've
tried
to
make
it
this
documentation
so
that
people
can
go
and
learn
about
this
stuff
and
also
a
higher
level
like?
How
do
you
maintain
successful
open
source
projects?
What
are
some
of
the
legal
issues?
Maybe
around
open
source?
And
things
like?
How
do
you
like
find
financing
and
sponsorship
for
your
open
source
project?
A
These
are
all
things
that
are
within
these
guides
and
the
other
cool
thing
about
the
guides
is:
they
are
themselves
open
source
projects
if
you
click
through,
if
you
could
scroll
to
it,
I
think
it's
at
the
bottom
of
the
page
you
can
collect
into
the
github
repository
people
are
submitting
pull
requests.
Are
there
I
think?
A
In
the
last
couple
of
days,
someone
submitted
Spanish
translation
of
the
entire
side
of
the
guides,
so
it's
kind
of
cool
to
see
these
documents
evolving,
and
it
means
that,
unlike
if
we
published
this
in
a
book
or
write
as
some
static
site,
that
was
just
maintained
exclusively
by
people
from
github.
This
documents
going
to
evolve
as
the
best
practices
and
open
source
change
and
as
github
itself
changes
and
I
really
encourage
you
as
a
safe
to
check
them
out,
and
if
you
have
wisdom
in
there
that
isn't
already
there,
please
submit
a
support
request.
A
A
So
yeah
so
today,
we've
kind
of
talked
about
a
couple
of
things
and
so
I
can
give
you
give
you
a
overview
of
like
what
is
the
open
source.
That's
on
github
and
stuff,
like
that.
Talking
about
how
you
can
kind
of
create
successful,
open
source
communities
and
how
you
can
improve
those
interactions
can't
walk
through
various
of
the
features
we've
added
to
get
hub
to
try
and
make
it
easier
for
you
to
have
those
positive
right,
Shenzhen,
different
source
communities
and
then
I
kind
of
talk
through
a
little
bit
about
for
users.
A
Contributors
and
maintainer
is
what
are
the
best
ways
to
interact
on
open
source
communities
and
I
just
wanted
to
say.
If
you
have
any
other
thoughts
on
this
stuff,
let's
say:
submit
a
pull
request
of
the
open
source
guides
or
feel
free
to
ask
us
any
questions
afterwards.
We'll
be
kind
of
hanging
around
sat
like
today
or
on
that
sort
of
Twitter
accounts
feel
free
to
head
us
up
that
way.
I.