►
From YouTube: From Storming to Performing: Growing Your Project's Contributor Experience- Matt Butcher & Karen Chu
Description
Don’t miss out! Join us at our next event: KubeCon + CloudNativeCon Europe 2022 in Valencia, Spain from May 17-20. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
From Storming to Performing: Growing Your Project's Contributor Experience - Matt Butcher & Karen Chu, Microsoft
The early days of a project seem so clear. Write some code, author some documentation, & post it on GitHub. Then wait for those GitHub stars! But OSS is as much about people as code. We’ll take an honest look at the contributor experience for a sustainable open source project. We apply the form/storm/norm/perform model as a way to approach growth. With stories, examples, & our own experiences, we share practical guidance on how you can set your open source contributor community on a course to not just survive, but thrive. Part 1: Form — Tackling first tasks together *Code *Website *Messaging *Docs Part 2: Storm — Gaining trust & sorting things out *Resolving disputes *Code of Conduct *Governance *Coding standards *Contributors are not employees/coworkers Part 3: Norm — Sharing responsibility *Issue management *Delegating work *Standardizing communication channels Part 4: Perform — Optimizing for the long haul *Retaining maintainers *Maintainer turnover & recruiting *Emeritus status
A
Thank
you
to
all
the
thousand
fans
here
in
our
live
audience.
The
tens
of
thousands
of
you
joining
online.
We're
happy
to
be
here
today,
yeah,
so
we'll
be
talking
about
from
storming
to
performing
growing
your
project's
contributor
experience,
I'm
matt
butcher.
I
lead
a
team
at
microsoft,
called
deus
labs.
We
do
a
lot
of
open
source
development,
have
done
a
lot
of
community
work,
we
built
helm
and
brigade
and
cnab
and
porter
and
a
whole
litany
of
other
projects.
A
B
Hi,
I'm
karen
I'm
a
community
program
manager
at
microsoft.
Externally,
I
do
a
lot
of
work
in
the
cncf
space,
I'm
a
member
of
the
kubernetes
code
of
conduct
committee
and
I'm
also
a
bootstrap
member
of
the
cncf
tag
focused
on
contributor
strategy
and
then
at
microsoft.
I
am
a
community
manager
for
matt's
team.
Like
you
mentioned,
we
worked
on
the
illustrated
children's
guided
kubernetes
box
series
together
and
you
can
find
me
on
twitter
at
caring,
h2.
A
So,
where
we're
going
to
start
today,
isn't
necessarily
with
how
you
get
started,
writing
your
open
source
project.
We
really
wanted
to
start
more
with
once
you
have
a
project
and
you
start
turning
your
attention
toward
community
building
and
how
you
start
to
get
those
first
contributors
and
how
you
kind
of
work
your
way
through
this
process,
we've
done
it
ourselves
many
times.
A
More
importantly,
we've
learned
from
a
lot
of
other
people
around
us
how
to
do
things
well
and
and
how
to
get
people
highly
involved,
but
where
we
wanted
to
start
today
and
the
kind
of
framing
for
our
presentation
was
with
a
psychologist
who,
in
1965,
bruce
tuckman
surveyed
the
psycho
psychological
literature
on
how
groups
form
and
then
how
they
become
productive
and
tuckman
analyzes.
All
of
this
literature
and
at
the
end,
sort
of
believes
that
he
sees
a
pattern
that
is
common
to
almost
all
kinds
of
groups
that
form-
and
he
says
there
are.
A
There-
are
four
very
distinctive
phases:
it's
forming,
followed
by
storming,
followed
by
norming
and
concluding
with
performing
now,
if
you've
read
any
literature,
unlike
getting
a
company
started
up
or
how
to
do.
Group
therapy,
or
things
like
this-
you
are
likely
to
at
least
run
into
this
theory
somewhere
along
the
line,
but
we
thought
it
might
be
fun
to
just
kind
of
see
how
it
applied
to
open
source
projects.
So
that's
what
we'd
like
to
talk
about
today
and
we'll
go
through
each
of
these,
so
in
the
forming
phase,
this
is
the
first
one.
A
A
A
But
during
this
phase
the
thing
you
want
to
do
to
foster
this
kind
of
forming
phase
is
to
say,
is
to
get
get
yourself
all
psyched
up
to
to
create
a
welcoming
and
open
atmosphere
for
those
kinds
of
things,
because
those
represent
people
who
are
using
your
software
and
then
and
then
who
want
to
help
you
get
better.
We
had
some
rules
when
we
were
doing
helm
where
we
we
acknowledged.
A
We
agreed
the
helm
core
maintainers
agreed
in
those
early
days
that
each
time
a
new
pull
request
would
come
in,
even
if
the
pull
request
was
in
pretty
rough
shape.
We
would
try
and
lead
off
with
a
good
positive
comment,
because
we
felt
like
that
helped
us
as
contributors
say.
Look
we
recognize
that
our
main
our
main
job
as
a
core
committer
is
to
get
people
involved
and
it
helped
validate
for
them.
Yes,
we
recognize
that
you
just
put
in
a
lot
of
time
on
this.
B
This
is
something
you
want
to
figure
out
early
on
and
be
intentional
with,
because
once
you
kind
of
set
up
these
channels,
you're
a
bit
committed,
we've
had
a
few
or
I've
worked
on
a
project
before
where
we're
like
we're,
like,
oh,
like
we'll,
do
our
own
slack,
org
right
and
then
later
on,
we're
like
no.
It
makes
more
sense
for
us
to
move
this
into
the
cncf
slack
and
with
that
we
definitely
lost
some
people
having
to
migrate
our
community
over
so
again.
A
Documentation
is
another
good
thing
to
do
for
your
community,
and
maybe
that
sounds
self-evident,
and
I
I
hope
it
does
actually.
But
again,
you
know
in
those
early
days
of
getting
the
project
going,
it's
a
good
time
to
frequently
revisit
at
least
a
couple
pieces
of
documentation.
The
quick
start
guide,
carolyn
von
sleeves
now
I
can't
pronounce
her
name
von
slick
on
our
team
is
great
about
reminding
us
hey.
A
The
the
the
less
fun
topic
is
the
storming
phase,
so
every
group
starts
out.
You
know,
enthusiastic
and
you're,
starting
in
that
building
phase,
but
inevitably,
at
some
point,
you're
gonna
run
into
differences
of
opinion,
confusion
about
what
should
be
done
and
the
storming
phase
describes
that
phase
where,
for
the
first
time,
interpersonal
conflict
sort
of
enters
the
arena,
and
this
can
be
kind
of
a
make
or
break
phase
for
any
group
and
an
open
source
community
is
no
exception.
A
B
So
I
think
this
goes
without
saying,
but
you
know
I
want
to
be
explicit.
Disputes
are
unavoidable.
You
know
you
want
to
set
the
right
expectations
for
you
and
your
team
by
acknowledging
that,
like
you,
will
very
well
have
disputes
at
some
point
and
they're
okay
to
have
the
worst
thing
you
can
do
is
ignore
them
and
be
caught
off
guard.
So
just
know
that
they're
gonna
happen
and
that's
fine.
The
next
is
the
code
of
conduct.
B
I
serve
on
a
code
of
conduct
committee
and
I
highly
recommend
that
you
have
one
for
your
project
again.
This
is
one
of
those
things
you
want
to
have
this
before
you
really
have
like
need
to
have
it
before
there
are
any
incidents,
and
this
not
only
protects
you,
it
protects
your
project
and
it
protects
your
community
and
I
know
for
some
people.
They
think
that
this
is.
You
know
that
there's
a
lot
of
work
that
goes
into
this
stuff,
but
you
don't
have
to
create
this
from
scratch.
B
There
are
lots
of
examples
out
there,
like
the
cncf
code
of
conduct,
that
you
can
adopt
for
your
projects
and
then
next
is
governance.
So
a
governance
stock
basically
provides
rules
of
engagement
around
things
like
decision
making
and
voting
for
a
project,
and
you
know
sometimes
users
will
decide
whether
or
not
they
want
to
participate
or
use
your
project
based
on
this,
especially
if
there's
things
around
like
if
it's
like
one
company
controlling
a
project
right
and
so
this
is
something
again
you
want
to
think
about
before.
B
A
Have
a
stake
in
it.
I
think
that
in
both
of
those
cases,
the
code
of
conduct
and
governance,
those
are
the
areas
where
some
really
big
issues
can
come
in
and
really
do
substantial
damage
to
a
project.
At
any
point,
and
that's
why
you
want
to
make
sure
to
have
those
too,
but
then,
then
again,
I
get
the
easy
one
right.
A
Coding
standards
are
another
way
to
kind
of
stop
like
the
mundane
issues
right
where
a
pr
opens,
and
you
feel
like
you're,
almost
like
bickering
about
where
the
parent
goes
or
how
you
do
semicolons
or
where
the
white
spaces
are,
and
you
as
a
as
a
core
maintainer
and
as
a
project
creator
can
very
simply
create
some
guides.
That
say,
hey
use
this
formatter
over
your
code,
hey,
we
tend
to
follow
these
particular
idioms.
It's
best,
even
if
you
can
point
to
an
established
set
like
the
go
programming.
A
If
you
can
just
remove
a
whole
layer
of
those
problems,
then
the
core
maintainers
are
really
focusing
more
on
the
substance
of
what's
being
asked
and
the
pull
request
and
and
conversely,
your
contributors
are
going
okay,
I
feel,
like
I
know,
coming
into
it.
What's
expected
of
me
yeah.
Maybe
I
would
have
put
my
friends
somewhere
else,
but
I
understand
that
that's
what
they
want
to
do
to
keep
their
code
clean
and
it
just
removes
that
whole
area.
So
I
think
that's
a
nice
easy
way
to
establish
something
that
can
solve
problems
now.
A
The
last
one
is
really
something
we
have
to
remind
ourselves
of,
sometimes,
especially
when
we
start
projects
that
there's
a
distinct
difference
between
a
contributor
and
an
employee
right,
and
sometimes
it
as
you
get.
You
know
in
that,
in
that
kind
of
heady,
early
days
of
a
project
you
get
really
excited
and
people
come
in
and
start
committing
and
and
start
changing
the
code
you
get,
and
then
you
start
thinking
of
those
people
as
employees
right
using
that
model
where
you're
like.
Oh,
I
need
you
to
do
this.
I
need
you
to.
A
Can
you
get
this
done
by
tuesday?
You
know,
and
it's
easy
to
get
a
little
heavy-handed
on
that
side
which
becomes
unfair
to
these
people,
and,
and
it
is
a
not
the
way
we
should
be
looking
at
them
right-
respecting
volunteers,
as
people
who
have
very
graciously
given
of
their
time
and
talent
is,
of
course,
what
we
all
aspire
to
be,
but
we
as
maintainers
often
have
to
take
a
look
at
ourselves
as
we
head
out
of
that
forming
and
into
the
storming
period
and
go
oh
okay.
A
So
now
we
move
on
into
the
into
the
third
phase,
so
it's
forming
storming
and
then
norming
and
in
the
norming
phase.
This
is
when
the
group
dynamic,
really
changes
more
to
say:
okay,
all
right
now,
we
know
how
to
work
together
or
now
we
know
how
to
solve
problems.
How
do
we
work
together
to
sort
of
head
toward
the
optimal
right?
A
How
do
we,
how
do
we
kind
of
codify
how
things
are
done
in
this
project,
with
the
purpose
of
making
it
easy
for
us
to
continue
on
one
thing
that
we
can
do
for
that
is
revisit
how
we
do
issue
management
right
in
that
first
time,
when
we're
talking
about
forming
we're
talking
about
trying
to
get
people
to
submit
issues
and
make
them
feel
comfortable.
Well,
you
know,
if
your
project's
doing
well,
all
of
a
sudden,
you
don't
you,
don't
necessarily
feel
the
need
to
get
people
to
start
filing
issues.
A
You
really
start
going.
This
is
a
lot
of
issues,
I'm
not
really
sure
how
I
can
keep
up
with
it.
So
at
this
point,
then,
you
start
figuring
out
strategies
for
triaging.
We
use
labels
a
lot
for
some
of
our
projects
and
and
try
and
categorize
things
early
triage
on
a
regular
cycle
and
prevent
things
from
building
up
and
again.
The
purpose
of
this
is
not
so
much
is
not
so
much
and
really
the
purpose
of
many
of
these
things
in
the
norming
phase.
Isn't
so
much
individualist
individualist?
It's
not
about
me.
A
It's
about
how
the
core
maintainers,
who
are
becoming
a
group,
can
start
to
sort
through
amount
of
big
amounts
of
information
very
efficiently
and
in
a
way
they
all
agree
upon.
So
labeling
issues
is
a
super
super
convenient
way
for
somebody
to
be
able
to
go
through
and
triage
things
really
quickly,
and
then,
when
somebody
else
has
time
they
can
come
back
through
and
say:
okay,
I'm
gonna,
look
for
a
bug!
A
Oh,
these
three
are
labeled
bug
that
one's
labeled,
small,
I'm
gonna,
grab
a
small
bug
and
work
on
that
today
and
that
helps
everybody
streamline
things
without
everybody
having
to
do
sort
of
the
redundant
work
of
reading
every
issue
in
the
queue
delegating
work.
Delegating
work
as
the
project
grows,
it's
going
to
become
increasingly
important
to
figure
out
how
you're
going
to
parcel
stuff
out
among
the
maintainers
of
the
project,
so
helm
is
a
good
example
of
that
and
adam's
sitting
in
the
front
row.
So
I
can
pick
on
him.
A
A
How
do
you
feel
about
becoming
a
core
maintainer
and
you
start
building
out
in
this
norming
phase,
a
process
by
which
you
can
identify
people
around
you
who
are
going
to
be
productive
for
the
project
healthy
for
the
community
and
and
then
you
know,
kind
of
delegate
out
that
that
work
to
them
and
then
make
it
clear
how
they
can
claim
work
and
make
it
clear
how
what
the
expectations
are
to
working
together?
And
that's
when
you
really
start
to
see
the
project
as
a
whole
strengthen
right.
A
C
B
So
you
also
want
to
standardize
communication
channels,
and
this
is,
for
everyone's
sake,
figure
out
what
needs
to
be
private,
with
maintainers
versus
transparent
with
the
community
again.
This
goes
back
to
building
trust
and
use
your
dedicated
communication
channels
as
intended,
and
this
is
for
consistency
and
trust,
and
if
and
when
you
outgrow
your
channels,
such
as
with
slack
consider
splitting
it
for
the
sake
of
organization
again
using
helm
as
an
example,
we
used
to
just
have
a
helm
channel,
but
then
you
know
it
got
a
bit
noisy.
B
We
started
having
developers
in
there
and
users,
and
so
we
ended
up
splitting
the
channel
into
a
helm,
dev
and
helm
users
channel
again
just
for
organization
and
clarity,
so
think
about
that
and
if
and
when
you
need
to
do
that,
do
it
as
soon
as
possible
and
then
also
just
for
you
know.
When
it
comes
to
communications,
you
want
to
document
for
the
future
right
like
you're,
not
always
going
to
have
the
exact
same
people
working
on
your
project.
B
A
So
we
start
with
forming,
then
we
go
on
and
we
deal
with
interpersonal
conflict
and
storming.
Then
we
get
to
this
place
where
we're
really
starting
to
solve
process
problems
and
that's
the
norming
phase
and
then
the
final
phase
that
tuckman
identified
was
called
performing,
and
the
idea
here
is
that
the
group
is
sort
of
settled
into
their
thing
right
and
we
understand
how
we
work
together.
We've
hit
stride
on
a
lot
of
things.
A
We
know
what
our
in,
in
the
case
of
an
open
source
project
like
this
right,
what
the
day-to-day
cadence
looks
like
for
things,
how
we
version?
How
we
do
this?
How
we
do
that?
The
last
phase,
the
performing
phase,
is
really
about
making
sure
that
we
can
perpetuate
everything,
we've
just
built
and
and
continue
it
on
and
keep
everything
kind
of
healthy
over
the
long
term.
A
A
We're
all
at
this
point,
I
think
painfully
aware
of
the
impact
of
burnout
and
one
of
the
things
about
maintaining
an
open
source
project
which
I'm
sure
will
come
as
no
surprise
to
any
of
you
is
that
it
can
be
really
stressful
to
manage
things
like
issue
cues
right.
Nobody
comes,
I
shouldn't
say
nobody
very
rarely.
A
This
was
my
free
time.
Why
am
I
spending
my
free
time
on
this?
I
could
spend
my
free
time
on
something
else,
so
it
became
a
very
important
thing
to
for
us
to
figure
out
ways
of
expressing
appreciation
to
core
maintainers
help
them
feel
appreciated
and
help
them
feel
valued,
and
karen
had
often
done
really
cool
things
like
create
some
sort
of
special
special
swag
to
give
specifically
to
core
maintainers.
You
know:
here's
a
t-shirt.
Here's
we
gave
out
we've
done
awards.
A
B
And
then
again,
just
kind
of
acknowledging
that,
like
people
will
eventually
move
on,
you
want
to
actively
always
be
thinking
about
the
future
right,
so
treat
your
current
maintainers
well,
because
that
will
encourage
new
people
to
stop
us
step
up
as
contributors
and
then
also
ideally
become
maintainers
down
the
line,
and
just
be
honest
with
yourself
about
this
yeah
just
always
be
thinking
about
how
you
can
bring
in
new
contributors
before
you
need
to.
I
guess
that's
kind
of
my
current
theme
right
now.
For
this
whole
talk.
B
Things
before
you
need
to
so
yeah
as
an
example,
we
did
our
helm
contributor
summit
earlier
this
year
and
with
that
we
did
workshops
for
people
who
are
new
to
the
project
to
get
them
caught
up
to
speed
on
how
to
contribute
to
the
project.
And
then
we
also
use
that
as
an
opportunity
to
identify
current
maintainers
that
we
felt
like
had
potential
to
become
maintainers
reached
out
to
them
and
then
we're
like
currently
working
with
them
and
mentoring
them
to
become
maintainers.
B
A
Yeah,
yeah
and
and
being
able
to
keep
that
momentum
once
you've
gone
through
all
these
other
phases
to
kind
of
build
it,
it
felt
much
easier
to
have
a
core
maintainer
summit
and
say
this
is
what
we've
already
discovered
about
it.
You
know
come
on,
join
us,
it's
going
to
be
fun,
but
sometimes
it
is
time
for
people
to
go
right
and
it's
not
always
because
of
burnout.
A
You
become
an
emeritus
professor,
and
this
is
a
title
of
respect,
a
kind
of
way
for
the
department
to
thank
you
for
your
contribution
over
the
years
to
your
particular
specialty
to
your
particular
field,
and
we
really
liked
that
idea
of
of
having
a
title.
That
was
a
title
of
respect
but
didn't
necessarily
carry
with
it
more
responsibilities
with
the
project,
and
so
we
introduced
a
helm,
emeritus
maintainer
status
that
when
somebody
said
you
know
it's
my
time,
job
change,
life
change,
tired.
A
You
know,
interest
change
whatever
I
I
kind
of
need
to
step
back,
then
we
would
give
them
this
title
emeritus
maintainer
and
they
would
go
in
the
code
owner's
file
in
the
emeritus
maintainer,
and
that
meant
that
from
then
on
out
they
knew
that
when
they
put
on
a
resume
yeah,
I
worked
on
helmery.
I
worked
on
brigade
or
something
like
that.
They
would
be
able
to
point
back
to
the
file
in
the
repo
and
say
see.
I'm
I'm
still
listed
here
right
and
other
people
would
be
able
to
go.
A
Oh
yeah,
I
know
that
person
they
I
didn't
know
they
worked
on
this
project
and
there's
this
like
sense
of
respect
and
and
honor,
in
being
able
to
recognize
the
work
that
people
did.
So
we
we
coined
that
title.
That's
something
that
I
really
hope
other
projects
do
as
as
well,
because
I
just
think
it's
a
really
cool.
B
All
right
so
now
we're
at
the
conclusion,
and
you
know
basically,
you
want
to
say
that
in
reality,
open
source
projects
aren't
static.
Right,
like
we
presented
this
model
to
you,
but
at
the
same
time
not
all
the
projects
that
you
work
with
will
go
through
these
phases
or
at
the
same
pace,
and
so
sometimes
we
move
back
and
forth
through
this
model,
and
all
of
that
is
okay.
A
A
You
know
forming
storming,
norming
and
conforming.
He
realized
that
he
might
have
missed
something
and
so
later
on,
he
came
back
and
offered
a
final
step,
a
fifth
step
that
he
called
adjourning,
and
this
is
a
step
that
we've
all
seen
happen
with
open
source
projects
as
maintainership
kind
of
quiets
down.
The
project
is
no
longer
quite
as
relevant
and
and
it's
time
to
just
say,
hey.
C
A
C
B
A
Even
to
get
to
the
the
community
part
so
with
a
lot
of
our
projects,
we'll
take
the
the
github
org
for
the
project,
so
slash,
helm
and
then
there's
slash
helm
is
the
code.
Repository
charts
is
the
other,
and
community
is
one
of
them
and
we
will
often
put
people
who
do
a
lot
of
design
work.
Karen,
who
does
a
lot
of
community
work
bridgette?
Who
does
a
lot
of
community
work
and
and
documentation
work?
People
people
like
that
will
go
in
their
docs
repositories,
will
often
separate
out
from
the
code
repositories.
A
We
used
to
keep
the
two
together
for
the
simple
reason
that
then
you
could
pull
request.
One
pull
request
with
a
feature
change
and
a
doc
change,
but
over
time
we
realized
that
there
were
a
lot
of
specialist
activities
that
you
could
do
in
a
doc's
repository,
and
so
we
started
breaking
those
out
and
then
we
started
assigning
maintainers,
who
were
dock
maintainers?
A
Who
could?
Who
would
really
focus
on
everything
from
and
correct
feel
free
to
jump
up
and
correct
me
if
I'm
wrong,
but
like
the
consistency
of
the
documentation
when
we
got
into
translation,
managing
translations,
making
sure
the
quick
start
guide
and
the
reference
material
is
all
up
to
date?
And
so
then
we
would
make
maintainers
of
a
community
repo
that
focused
on
some
of
that
maintainers
of
the
docs
repo
that
focused
on
that.
So
we
didn't
necessarily
give
them
titles
different
than
core
maintainer.
We
just
split
up
our
repos.
A
Now
I
imagine
you
could
definitely
just
say
we're
going
to
have
a
category
called
docs,
maintainer
or
docs,
and
code
code
maintainer
or
something
like
that,
but
that
wasn't
anything.
We've
tried
out
trio.
Oh
I
forgot
about
that.
Oh
yeah,
that's
really
good!
So
in
helm
we
introduced
sorry,
I
just
oh.
A
We
introduced
triage
maintainers
recently,
because
what
we
were
discovering
was
the
issue.
Queue
was
getting
out
of
control
and
we
were
getting
burned
out
just
triaging
the
issue
queue
and
a
lot
of
times.
Those
were
questions
where
somebody
could
answer
in
two
sentences
or
point
them
to
the
documentation.
So
we
introduced
a
new
category
of
maintainer
called
triage
maintainer
that
they
don't.
A
I
mean
they're,
certainly
welcome
to
open,
pr's
and
stuff,
but
they're
not
obligated
to
review
prs
and
things
like
that,
but
they're
empowered
to
be
able
to
go
through
and
label
issues
and
close
issues
and
stuff
like
that,
and
that
for
a
project
the
size
of
helm
has
been
a
tremendous
boon
to
us.
It's
been
very,
very
helpful.
B
E
Okay,
one
more
question:
you've
worked
the
two
of
you
who
have
worked
on
large
projects
that
are
graduated
cncf
projects
like
helm,
but
you've
recently
been
starting
some
small
new
projects.
Can
you
talk
a
little
bit
about
people
who
might
see
all
of
the
work
that
goes
into
a
giant
project
like
helm
and
say,
wait
what,
if
I'm
just
starting
you
give
a
few
tips
for
people
who
are
starting
a
project
like
say,
crosslink.
B
A
So
the
metaphor
we
like
to
use
is:
it
has
to
do
with
circles
all
right
in
the
very
first
days
of
a
project
before
we
get
into
the
the
topics
of
this
kind
of
thing.
You
imagine
you
got
your
close
circle
of
people
who
are
working
together
on
the
code
and
you're
all
kind
of
huddled
together,
looking
inward
and
saying
okay,
how
are
we
going
to
design
this?
A
How
are
we
going
to
code
that
then
you
get
to
kind
of
this
first
phase,
where
you're
ready
to
start
community
building-
and
the
metaphor
we
always
use
is
okay,
so
you
got
this
group
of
people
and
they
all
stand
up
and
they
all
kind
of
turn
away.
So
they're
facing
outward
and
the
metaphor
is
designed
to
say
you
know:
everybody's
got
each
other's
back,
because
that
first
phase
can
be
kind
of
rough
right,
you're
going
to
get
challenged
a
lot
on
your
assumptions.
A
Everybody's
got
each
other's
back,
but
at
the
same
time
you're
facing
outward
and
starting
to
bring
people
in,
and
so
you
have
to
make
some
very
intentional
moves
at
that
point
to
say
hey.
This
is
what
we're
doing
you
know.
Sometimes
we
might
be
a
little
overly
enthusiastic
on
twitter
about
what
we're
working
on
and
how
excited
we
are
about
it.
A
But
the
idea
is
to
start
bringing
people
in,
and
hopefully
some
percentage
of
those
people
will
like
the
project
and
want
to
stick
around
and
use
it
and
then
some
percentage
of
those
people
who
stick
around
and
use
it
will
want
to
start
working
with
you
on
it
and
so
a
lot
of
that
like
after
the
1.0
phase.
So
much
of
the
effort
is
really
that
outward
communication
thing,
but
the
goal
of
that
among
the
other
goals.
A
So
to
answer
bridget's
question
most
directly,
then
that
that
turn
out
that
initial
turn
outward
when
you
really
start
focusing
time
that
would
otherwise
be
engineering
time
on
making
people
feel
welcome
on.
You
know
thinking
hard
about
those
pr's
and
leaving
some
some
positive
comments,
as
well
as
negative
comments
on
thanking
people
for
filing
issues
when,
admittedly,
sometimes
you're
like
right.
But
it's
all
about
respecting
people
where
they're
at
and
trying
to
build
up
that
next
concentric
root.
D
B
B
A
Right
that
you
just
will
spare
yourself
a
lot
of
problems
with
that,
because
again,
your
goal
in
this
community
building
phase
is
to
make
the
right
space
for
the
discussion
to
be
about
what
you're
trying
to
build
and
how
you're
going
to
do
it
not
and
not.
Having
jerky
people
come
in
and
ruin
the
the
exact
thing
you're
trying
to
do
right.
A
Yeah-
and
I
really
feel
very
strongly
that
what
sets
open
source
software
apart
from
any
other
you
know
commercial
proprietary
doesn't
really
matter-
is
the
fact
that
when
you
start
to
build
these
communities,
we
build
much
better
things
when
we're
working
together.
Collectively,
we're
smarter
about
these
things
and
not
handling
code
of
conduct.
Issues
will
just
destroy
that
right
away.
A
F
It's
a
song,
okay.
I
I
hope
this
is
relevant,
I'm
wondering
if
you
could
speak
a
little
bit
about
how
to
make
your
community
inclusive.
Given
that
you
know
many
people
are
dedicating
their
free
time.
You
might
have
a
handful
of
people
who
are
paid
to
work
on
the
project.
How
do
you
make
sure
that
you're
giving
those
people
who
just
have
a
few
minutes
to
spare
all
the
opportunity
to
participate.
A
A
C
A
A
In
so
that
we
could
streamline
the
process
of
getting
them
in
because
otherwise,
what
we
noticed
happened
was
that
the
loudest
ones
were
the
ones
who
got
considered
for
something
right.
It
was
the
ones
who
were
there,
the
most
and
who
were
commenting
on
the
most
number
of
issues
which,
while
a
good
indicator
of
their
interest
and
expertise,
is
not
the
only
indicator
of
interest
and
expertise,
so
we're
getting
better,
I
don't
know.
Are
there
other
things?
We've
done
that
I.