►
Description
Presented by:
Lauri Apple
Producer/Agile Project Manager, Zalando
What you share on GitHub tells a story about you, your development practices, and your openness to others in the open source community. If you're motivated to gain users, contributors, and positive feedback about your projects, then building a compelling, coherent narrative is essential.
In this talk, Lauri Apple will share insights gained from "editing" Zalando's GitHub repository so they can tell a better story. From 400+ projects of widely differing quality, reliability and maintenance levels, they've winnowed their offerings to make their highest-quality work more discoverable. She'll share how they used GitHub and other tools to create guidelines, categories, and processes that bring sanity to our storytelling.
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.
A
Hi
I'm
Laurie
Apple
I'm
from
Zalando
in
Berlin,
were
based
in
Berlin
and
I'm
here
to
tell
you
about
how
you
can
avoid
creating
a
github
junkyard.
So
it's
on
a
menu.
We'll
just
do
a
few
about
about
me
about
you.
It
will
go
through
a
section
about
asking
why
and
why
it's
important
to
ask
why
and
we'll
have
a
bonus,
hamster
picture
to
add
cuteness,
then
we'll
talk
about
building
junkyards
and
I'll.
A
Who
here
manages
the
github
organization
for
your
company,
all
right,
who
has
a
know,
github
manager
at
your
company
yeah,
who
does
open
source
because
it's
really
fun
yeah
and
who
likes
to
talk
about
how
their
workaholic
and
is
really
proud
of
it
and
being
busy
all
the
time.
I
should
have
raised
my
hand
for
the
third
question:
two
bits
fun
so
about
me.
I'm
a
little
bit
of
a
workaholic
I
have
blinking
I'd
have
two
jobs
at
solando.
A
We're
back:
okay,
thanks,
I'm,
also
one
of
the
open
organization
ambassadors.
The
redhead
has
a
program
to
promote
open
organizations,
collaboration
transparency,
so
I
write
blog
posts
for
them
and
help
build
our
maturity
model
for
open
organizations
with
a
bunch
of
others
around
the
world
and
I
have
my
own
little
project.
Feed
me
read,
means
which
will
give
you
read
me
editing
and
project
analysis
for
free.
A
So
that's
alright.
As
long
as
you
don't
mind,
I
don't
mind
so
about
solando.
Here's
a
lot
of
facts.
It's
a
really
big
company,
like
I,
said
we're
based
in
Berlin,
but
we
do
business
all
across
Europe
and
15
European
countries
and
our
tech
team
is
about
sixteen
or
seventeen
hundred
when
it
comes
to
open
source.
We
have
quite
a
lot
of
it.
This
is
the
front
page
of
the
dashboard
we
created
ourselves.
A
It's
like
our
storefront,
where
you'd
find
everything
at
our
main
github
repository,
which
is
backflash
solando,
and
you
can
find
that
dashboard
at
this
URL.
Some
quick
things
about
our
open-source
culture
is
that
we
are
polyglot.
So
we
have
a
search
engine
on
our
dashboard.
So
you
can
find
the
different
projects
for
making
different
languages.
We
actually
have
several
github
organizations
and
I'll
get
to
the
reasons.
Why
is
that?
A
Go
through
my
talk,
a
lot
of
the
tools
if
you
are
to
generalize
our
infrastructure
related
or
we
have
a
lot
of
stuff
for
working
with
api's,
because
we
have
a
micro
services,
architecture
and
I
found
this
to
be
necessary
and
the
TLC,
our
tagline,
of
where
we
are
as
a
culture,
is
we're
maturing.
So
we're
focusing
more
on
quality
and
less
on
quantity
as
we
go.
A
Why
do
we
open
source
all
the
usual
reasons?
The
are
typical
of
big
organizations,
development
of
our
people,
giving
back
to
the
community
improving
the
quality.
We
see
that
developing
in
the
open
improves
our
security
or
code
or
coverage
to
test
things
like
this.
Also
for
a
reputation
we
want
to
or
a
big
company.
We
want
to
be
out
there
in
the
open
source
world
as
a
presence,
and
it
does
help
with
recruitment.
A
What
do
I
bring
to
all
of
this?
So
those
questions
are
rather
generic.
What
I
like
to
do
is
ask
wise,
you
know,
dig
deeper.
Why
are
we
doing
things
like
this?
What
are
our
motivations
for,
participating
in
open
source
beyond
those
general
reasons?
Why
why
do
we
put
things
on
the
Internet?
Is
it
to
solve
a
problem
like
we
didn't
find
anything
that
solves
our
problem
ourselves,
so
we
went
built
it
and
now
we're
sharing
it
with
others?
Is
it
to
start
a
dialogue
with
community?
Is
it
for
our
egos?
A
A
We
build
a
lot
of
stuff
ourselves,
so
I
ask
this
question
a
lot.
Why
are
we
building
this
ourselves?
Is
there
something
else
out
there
that
could
do
the
job
that
we
could
contribute
to
and
are
our
building
methods
sustainable?
If
we're
building
a
lot
of
stuff,
you
know,
is
it
kind?
Are
we
being
kind
to
ourselves
by
creating
all
of
this
work
in
this
code,
or
are
we
building
a
big
burden
for
ourselves
that
we
have
to
maintain?
A
A
So
behind
me
are
some
of
the
logos
for
the
companies
that
I
work
for,
but
on
the
this
side
or
the
prints
and
the
other
side
is
the
biggest
online
website.
I
worked
with
Gawker,
which
was
taken
down
by
Hulk
Hogan.
So
here's
how
we
have
two
professional
wrestlers
that'll
come
up
in
this
presentation
and
Hulk
is
one
of
them.
He
basically
sued
Gawker
out
of
existence
last
year,
but
before
when
it
was
running,
Gawker
was
a
huge
website.
A
Conglomerate
of
companies
and
my
experience,
working
for
them
was
quite
different
from
when
I
was
a
prints
journalist
in
print
journalism.
You
call
people
on
the
phone,
you
talk
to
them.
You
build
relationships,
it's
actually
the
standard
practice.
You
also
have
limited
space
through
which
you
would
publish
your
work,
because
you
have
like
a
weekly
edition
or
daily
edition,
so
to
make
sure
that
you
actually
can
economize
on
what
you
put
out
there
in
the
world.
You
have
an
editor
and,
in
my
experience,
the
best
editors
or
the
hardest.
A
That
made
me
really
answer,
be
precise,
answer
questions
with
the
detail
and
you
know
drove
me
to
do
my
best
work
and
the
online
scene.
You
can
have
all
of
these
things.
There
are
great
investigations
that
are
run
on
websites
today,
but
what
I
was
doing
was
mostly
for
speed
and
generating
traffic.
I
was
often
working
at
night,
so
my
editor
was
in
bed
and
I
had
to
just
kind
of
put
stuff
on
the
internet
kind
of
solo
and
I.
Don't
when
I
look
back
at
these
two
different
experiences?
A
A
So
I
saw
a
lot
of
times
when
I
was
working
like
a
hamster,
like
I
was
just
putting
six
to
eight
posts
per
day
on
the
Internet.
You
couldn't
do
that
with
investigations.
You
know
if
you're
doing
a
really
researched
article
you
just
wouldn't
be
able
to
sustain
that
kind
of
workflow.
It
would
be
impossible
and
an
online
print
an
online
blogging.
You
can
so.
This
emphasis
on
speed
can
really
start
taking
a
tool
and
I
see
this
happening
in
software
development.
We
have
time
pressures,
delivery,
pressures,
personal
pressures.
A
We
want
to
put
out
a
lot
of
work,
a
lot
of
us
ourselves
and
it's
kind
of
become
a
status
symbol
to
be
busy.
So
there
are
some
reasons
for
why
we
do
this
to
ourselves.
It
can
be
fun.
We
also
can
save
the
day.
You
know
we're
building
stuff
and
making
things
run,
and
it's
there's
adrenaline
rush
and
we're
getting
it
out
there.
A
A
A
Okay,
because
we
have,
we
have
CEOs
that
brag
about
sleeping
in
the
office
and
working
all
the
time,
and
you
know
what
is
the
cost
of
that.
Is
that
really
how
we
want
to
live?
And
there
seems
to
be
a
growing
awareness
in
the
industry
of
questioning?
You
know
what
are
we
doing?
Jeff
got
health
who's,
one
of
my
favorite
thinkers.
He
just
wrote
the
book
sense
and
respond
who's,
written
other
books
and
it's
a
lean
UX
advocate.
A
You
know
he
recently
tweeted
this
we're
so
busy
that
we
don't
actually
have
a
strategy
that
can't
be
the
strategy
on
its
own
to
be
busy.
Our
prioritization
suffers,
and
we
say
yes
to
a
lot
of
things
that
we
might
not
be
able
to
do
or
want
to
do,
and
one
of
the
ways
that
we
can
continue
to
establish
a
boundaries
by
saying
no
hitting
that
pause
button
and
giving
ourselves
a
chance
to
think
are
we
actually
being
productive?
I
see
this
happening
in
our
organization
as
we
open
source.
A
So
one
of
my
colleagues
who
is
put
out
a
lot
of
work
on
github
who
is
responsible
for
a
lot
of
systems
running.
He
knows
a
lot
of
stuff.
I
asked
him
in
preparation
for
this
talk.
You
actually
enjoy
maintaining
all
the
stuff
that
you're
putting
on
github.
You
enjoy
this
role
of
knowing
all
these
things
and
being
responsible
for
them,
and
he
sent
me
back.
The
future
on
the
guy
is
like
that's
a
really
hard
question.
Let's
talk
about
that
in
person
over
you
know,
coffee
later
and
I
thought
to
myself.
A
Should
this
question
be
that
hard
like
what
if
the
answer
was
simply
yes,
I
enjoy
what
I'm
doing,
because
it's
sustainable
like?
Has?
He
even
had
chance
a
chance
to
think
a
few
thundering
himself
or
is
the
pressure
to
release
and
make
so
severe
for
him
that
he
doesn't
have
that
chance
to
stop
I
asked
another
colleague.
A
What
would
we
do?
If
would
we
be
able
to
maybe
have
more
time
to
think
if
we,
if
we
were
given
like
a
boundary
requirement,
my
suggestion
was:
let's
get
hub
charged
us
for
repo?
What
would
we
do?
Would
we
put
out
the
amount
of
work
and
his
response
was
this?
You
know
we
would
change
a
lot
of
things,
so
you
know
why
aren't
we
doing
that
now
is
my
question:
why
aren't
we
voluntarily
saying
wait
a
minute?
A
Now
the
clickers
discussion
to
the
question
about
whether
github
is
actually
free,
which
is
a
conversation
I
had
with
Kelsey
Heights
our
last
week
we
were
talking
about
this
concept
of
free
and
open-source
I
reached
out
to
him
because
he's
talked
about
minimalism
and
how
he
reduces
the
amount
of
work,
the
amount
of
stuff
that
he
has
so
he's
got
an
attitude
where
you
know
less
is
more.
That
he's
talked
about
and
has
allowed
to
influence
his
work,
and
we
talked
about
this
idea
of
free
and
what
happens?
A
Is
it's
really
not
that
free
to
release
this
work?
There
are
a
lot
of
costs
from
maintenance
to
Goodwill,
if
you're
too
busy
to
respond
to
people
with
pull
requests,
for
example,
because
you're
managing
50
things
you're,
costing
yourself
goodwill
with
those
people
that
want
to
help.
You
also
perspective
it's
time
to
ask
ourselves
why
craftsmanship
Shepard
suffers,
because
we
can't
reasonably
take
care
of
all
of
these
things
at
the
same
level
that
we
might
as
the
same
standards.
A
There's
a
throwaway
aspect
that
comes
out
of
all
of
this,
and
if
nobody
is
editing
and
pruning
the
work
and
asking
questions-
and
you
want
what
happens?
Is
you
end
up
with
a
github
junkyard,
so
I
really
like
this
tweet
from
Andrea
Goulet
who's
from
core
zebras
he's
like
I
wish
you'd
stop
making
so
much
thing
to
like
actually
fix
the
things
that
we
have
already
when
we
have
less
stuff
to
do.
A
We
made
a
little
bit
of
open-source
work,
but
not
much.
Our
teams
were
not
really
encouraged
to
do
it.
Some
teams
were
rather
secretive,
in
fact
about
releasing
information
to
the
public.
This
did
change.
It
was
like
I
saw
over
a
period
of
years,
and
so
teams
started
to
make
some
open-source
work,
mostly
in
Postgres
and
Python,
in
fruit,
infer
tools
made
with
Python,
but
it
was
extremely
limited,
and
so
the
octocat
was
quite
hungry
as
a
result,
at
least
we
weren't
feeding
it
very
much
in
2015
we
did
a
pivot.
A
In
our
tech
management
strategy.
We
took
on
the
principles,
talked
about
in
Daniel
Pink's
Drive,
to
bring
about
autonomous
teams
that
were
driven
by
mastery
of
skills,
knowledge
experiences
and
worked
with
a
greater
purpose.
You
know
they
were.
We
tried
to
facilitate
more
connection
to
the
products
we
were
building
as
part
of
this
open
source
became
way
more
encouraged
and
possible.
We
actually
said
about
a
set
of
principles,
open
source
principles
that
encourage
people
to
share
their
code
online.
A
It
also
had
a
lot
of
other
requirements
that
we
had
suggested
for
taking
into
consideration
aspects
of
quality
documentation,
licensing
before
sharing
the
code,
but
people
really
hung
on
to
share
your
code
part
and
share
that
they
did.
Our
github,
recycle
up
process
became
somewhat
like
the
Lucille
Ball
Show,
where
the
candy
is
coming
out,
and
it's
coming
out
so
fast
that
Lucille
Ball
and
her
colleague
end
up
having
to
eat
it
because
it's
impossible
to
keep
up
with
the
pay.
A
This
happened
for
us
on
github,
so
when
I
in
January
2016,
when
I
started
evangelizing,
officially
we
had
about
400
repositories
on
github.
We
were
open
sourcing,
all
the
things
and
we
didn't
even
know
it
was
there
because
there
was
just
so
much
of
it.
How
could
you
find
anything?
How
could
you
get
any
sort
of
narrative
or
common
sense
of
what
our
purpose
was
based
on?
What
we
had
in
our
organization
as
a
whole?
A
It
felt
like
it
was
a
compulsive
releasing
of
work
just
getting
it
out
there
on
the
internet
and
then
what
ever
happened
to
it?
Well,
we'll
see
but
like
there
was
really
not
like
that
long-term
vision
for
what
we
actually
wanted
to
achieve
with
all
of
this
work
and
the
work
piles
were
building
and
the
junk
yard
was
growing.
We
weren't
asking
why
we
were
doing
this
to
ourselves
and
what
value
to
the
customers,
which
would
be
potential
users
contributors
adopters.
We
what
we
were
offering.
A
We
had
lots
of
wild
dogs
running
through
our
github
organizations.
I
mean
it
was
not
a
friendly
place
to
go
to
our
repository
and
try
to
find
things.
The
quality
of
the
work
was
really
varied
from
really
good
code.
You
know
code
covers
100
percent
type
of
projects
to
like
no
documentation
at
all
and
a
couple
lines
of
code.
You're
like
what
is
this
so
for
a
user
to
stumble
upon
this,
and
you
know
if
we
were
try
to
use
something
of
ours
they
might
if
it
was
something
that
didn't
have
like
a
file.
A
You
know
central
files,
they
would
be
maybe
putting
themselves
at
risk.
They
wouldn't
know
that
they
could
use
what
we
were
offering
in
a
stable
way
when
what
was
on
top
of
this
is
that
we
weren't
responding
to
people
like
people
were
trying
to
commit
code
to
us
and
we
were
like
blowing
them
off,
which
was
like
really
nasty.
A
This
is
an
example
of
one
of
the
things
that
we
actually
put
on
the
Internet.
This
is
a
whole
wrapper
around
AWS,
it's
built,
so
it's
of
AWS
for
working
with
autonomous
teams
and
there's
a
compliance
part
built
into
this
because
of
our
requirements
is
a
publicly
traded
company
using
and
you
know,
processing
lots
of
customer
data.
So
this
is
what
we
built
all
of
the
orange
things
were
components
and
tools
that
you
would
have
to
install
before.
A
You
would
be
able
to
use
the
whole
thing
for
a
company
that
didn't
really
have
a
big
reputation
if
at
all,
in
open
source.
Asking
people
to
download
and
install
all
of
this
stuff
is
a
huge
ask.
Talk
about
friction,
so
high
friction
was
kind
of
our
aesthetic
at
the
time.
All
of
that
stuff
that
you
saw
this
still
works
and
we
still
use
it,
but
it's
an
open-source
project.
A
You
know
how
could
we
ask
somebody
to
like
run
all
of
this
stuff
and
if
the
documentation
somehow
doesn't
get
updated,
then
their
chances
of
being
able
to
be
successful,
even
diminish
great,
even
more,
there's
lots
of
value
in
what
we
have.
Sorry,
there's
lots
of
value
in
all
of
this,
but
it's
hidden.
You
would
have
to
like
sort
through
to
find
what
you
would
be,
what
you
would
need.
Luckily,
however,
the
team
that
created
this
realized-
hey,
maybe
we
shouldn't
build
stuff
like
this
anymore.
A
Maybe
we
need
to
actually
offer
you
know
greater
value
to
other
companies,
because
you
know
there
is
value
in
this
work,
but
we're
not
making
it
so
obvious.
As
a
result,
people
are
not
contributing
to
the
work
they're
not
at
using
it
and
with
time
it
we
become.
It
starts
to
decay,
and
then
you
get
junkyard
prime,
so
we're
actually
deprecating
a
lot
of
that
stack
now
because
we're
shifting
to
Gooper
Nettie's,
but
you
know
it's
still
being
used,
but
not
not
by
anybody
else.
A
This
brings
up
a
lot
of
questions
like
would.
We
have
built
this
big
sprawling
platform
if
github
had
charge
for
repo-
maybe
maybe
not,
but
we
took
advantage
of
the
free
Ness
of
github
and
created
this
thing.
What
if
we
had
asked
community
like?
What
would
you
do
like
build
us
build
this
with
us
together?
It
might
look
a
lot
different.
A
What
if
our
team
had
actually
had
more
time
to
explore
these
kinds
of
questions
they
weren't
under
that
pressure
to
get
something
out
that
would
be
sustainable
for
autonomous
teams?
What
if
they
had
been
able
to
play
around
a
bit
more
and
in
so
doing
think
about
the
costs
of
maintenance
and
opportunity?
A
We
don't
plan
these
kinds
of
situations.
We
don't
plan
our
junkyards,
but
they
kind
of
you
know
we
want
to
have
our
Corvette
right,
we
buy
a
Corvette
and
we
think
it'll
be
shiny
and
beautiful
forever,
and
that's
our
hope.
It's
it's
a
great.
You
know
aspiration,
but
this
often
doesn't
turn
out
that
way,
because
there's
new
things
turn
old
and
they
turn
old
for
the
reasons
mentioned
of
pressure
or
no
time
to
maintain
the
those
things.
A
This
perception
that
we
must
continue
to
be
busy
and
also
all
the
reality
at
times
of
not
being
able
to
ask
ourselves
like.
Can
we
build
some
hygiene
and
to
managing
our
technical
debt?
There's
also
this
belief
that
whatever
we
put
out
there
could
be
useful
someday,
even
if
you
can't
find
it,
it
could
be
useful
as
long
as
somebody
knows
where
it
is,
including
yourself.
You
know
ourselves,
there's
even
nostalgia
that
is
attached
to
some
of
the
work
that
we
put
out
there.
A
You
know
this
thing
was
important
three
years
ago
and
it
got
us
to
hires
and
we
went
and
gave
talks
about
it
but
like
that
was
three
years
ago,
but
we
know
we
hold
on
to
it
with
those
memories
tied
into
it.
Even
if
we
don't
take
care
of
the
work
anymore
and
also
this
idea
that
sharing
everything
you
know
bringing
back
to
what
our
team
interpreted,
sharing
all
the
things
means
through
open
source.
A
So
no
knowing
what
we
had
and
kind
of
having
all
these
things
in
mind
about
like
trying
to
make
our
github
a
friendly
ecosystem
where
we
could
enjoy
ourselves
and
others
could
help
us
I
said
about
on
doing
like
a
Big
Dig
and
to
do
this.
I
picked
a
couple
of
places
to
start
a
couple
themes,
one
being
to
supplying
the
basic
storytelling
and
my
experiences
as
a
writer
to
get
our
narrative
to
be
kind
of
sensible
for
for
users
or
doctors
coming
to
visit
us
and
github.
A
You
know,
would
we
make
sense,
also
focusing
on
craftsmanship.
So
as
a
person
who
believes
in
agile
values,
you
know
that
the
tools
are
great,
but
it's
really
the
values
of
working
software
collaboration,
openness,
those
are
the
things
that
really
make
it
exciting.
So
I
wanted
to
bring
those
into
the
open
source
context
and
then
also
get
a
handle
around
sustainability,
and
it
is
a
really
cool
rare
chance
to
develop
a
culture
of
open
source
at
mega
scale.
A
I
had
a
lot
of
help
along
the
way
to
go
on
such
an
expedition
takes
time,
for
us
is
such
a
big
organization.
It
requires
a
lot
of
steps
and
these
steps
are
still
ongoing.
There
are
some
things
that
were
pretty
easy
to
do,
and
a
lot
of
some
things
that
are
way
harder.
The
easy
stuff
is
setting
up
your
framework,
your
templates
or
guidelines,
new
orgs.
A
If
you
have
to
what
slow
and
takes
more
time
and
changing
the
minds
of
people
to
develop
software
differently
and
to
do
open
source
with
that
idea
of
costs
and
future
costs
in
mind,
I'll
run
through
these
pretty
fast,
because
I
think
I'm
little
mindful
of
time.
But
if
you
go
to
our
github
organization,
you
can
find
our
guidelines
here.
These
were
crowd-sourced
by
our
developers,
who
are
part
of
our
open-source
guild,
which
is
our
informal
gathering
place
to
talk
about
open
source
policies
and
projects
and
things.
A
So
this
is
all
a
combined
effort
and
has
evolved
over
time
as
new
needs
right
arise.
We
just
add
the
new
copy
onto
our
github
repository
and
it's
nice
and
organic.
This
way,
we
also
added
some
supporting
resources
to
put
some
context
around
the
guidelines
and
also
to
help
drive
the
ideas
of
craftsmanship
and
sustainability.
So
one
template
that
we've
created
is
a
readme
template,
because
you
can
do
so
much
with
the
readme.
A
It's
a
great
way
to
tell
your
story,
set
expectations
for
potential
users
and
contributors
like
yes,
I
will
merge
or
pull
requests
in
two
days.
No
I
will
not
like
don't
expect
an
answer.
For
me,
it's
such
a
great
place
to
be
able
to
encapsulate
what
your
story
is
for
that
particular
project
in
a
way
that
others
can
understand
it.
We
also
created
a
product
template
to
get
folks
to
ask
why.
Why
are
you
building
this?
What
are
you
building?
What
do
you
hope
for
this?
A
Do
you
have
a
maintenance
plan
to
maintain
this
over
time?
All
of
this
stuff
is
recycle.
There's
so
much
great
information
on
the
internet.
There's
really
not
that
much
original
to
what
what
we
were
doing
here.
We
just
tweaked
it
for
our
own
unique
circumstances,
as
you
might
for
your
organization.
If
you
go
about
setting
out
a
set
of
guidelines
as
well
organ
organ
eyes
repositories,
so
we
created
an
incubator
that
was
kind
of
a
place
where
we
could
shift
a
lot
of
the
stuff.
A
A
We
have
a
lot
less
work
on
our
main
organization
and
we
did.
It
was
like
330
plus
projects
now
we're
down
to
about
72
and
we
can
get
rid
of
more
more
questions
are
being
asked.
We're
collaborating
more
with
different
companies
and
individuals
who
can
actually
were
inviting
them
to
build
things
with
us.
A
You
know
much
more
proactive
way
than
before
in
a
much
friendlier
way,
we're
archiving
things
and
we're
also
influencing
other
companies
with
our
guidelines
primarily
to
develop
differently,
and
we
we
also
are
bringing
more
craftsmanship
into
each
repo
by
putting
all
the
essential
ingredients
like
docks
and
essential
files
in
there.
But
we
still
have
challenges
mostly
because,
when
you're
trying
to
change
a
culture,
it
doesn't
happen
overnight.
A
These
kinds
of
habits
of
craftsmanship
take
time,
there's
still
a
belief
that
when
you
put
it
on
github,
it's
done
yay.
It's
done.
We
still
put
out
way
too
much
stuff.
So
we
can
manage.
There's
this
fear
of
missing
out.
If
we
don't
rush
to
publish,
then
somebody
else
will
put
out
the
idea
and
we
will
have
our
opportunity
snatched
away
kind
of
this
belief
that
having
what
we
expect,
which
is
a
Minimum
Viable
Product,
you
know
something
that
somebody
could
contribute
to
use.
A
Understand
that
that's
not
the
that's,
there's
a
bit
of
a
struggle
with
what
that
means,
and
people
will
here
know
you
know,
don't
publish
at
all.
It
has
to
be
perfect
and
that's
never
what
it's
been
about.
It's
about
having
something,
that's
basic
and
ready
that
somebody
can
actually
like
connect
with
and
understand
like
what
is.
They
can
see,
what's
happening
in
this
repository
and
contribute
or
use
it
contribute
to
or
use
it,
and
an
incubator
has
become
our
junkyard
in
places
the
main
solando
organization
we're
still
not
as
friendly
as
we
could
be.
A
We
could
increase
the
transparency
by
managing
expectations
through
our
read
means
better.
You
know
where
we're
not
we're,
still
not
responding
to
people
in
a
timely
way
who
are
trying
to
contribute
to
us,
and
we
could
be
better
it
that
telling
folks
you
know
we
might
take
a
while
or
we
might
not
get
back
to
you
at
all.
A
You
know
go
go
for
us
and
fork
and
do
what
you
like,
but
we
you
know
we're
busy
we're
not
taking
care
of
this
project
anymore.
We're
not
really
being
this
strong
about
that
and,
as
a
result,
you
know
we
still
have
that
risk
of
people
coming
trying
to
work
on
our
stuff
or
use
it
and
not
having
a
stable
project
to
turn
to
getting
leads
and
heads
to
buy
into.
This
is
also
a
ongoing
task,
with
delivery
pressures
of
being
what
they
are
putting
out
new
features.
Putting
out
new
products.
A
A
We're
building
more
of
a
maturity
model
mindset
as
we
go,
because
we
see
that
we
have
a
need.
It
has
to
actually
come
from
the
organization,
not
just
one
person
who
happens
to
be
me
at
the
moment.
So
what
we're
actually
doing
to
address
this
is
having
a
official
strategy
which
we're
rolling
out
this
week
that
addresses
the
need
for
craftsmanship
and
encourages
it.
We're
setting
up
a
peer
review
group.
A
Blindly,
we're
making
interaction
with
the
community
naaaa
Osia
be
like
you
need
to
think
about
your
potential
users
and
contributors
or
your
communities
of
practice,
and
we're
also
going
to
be
doing
a
lot
of
training
and
coaching
folks
to
really
get
everybody
to
see
like
this,
isn't
just
a
set
of
rules
and
values.
We're
not
trying
to
like
make
life
arduous
and
terrible
for
you.
We
want
you
to
succeed,
and
here
are
some
simple
things
that
you
can
do
so
that
your
project
develops
and
blossoms.
A
Instead
of
becomes
like
a
old
junky
car,
so
I'm
closing
out
with
a
couple
of
tips,
learnings
and
some
asks.
So
please
like
if
you
haven't
cleaned
up
your
github
org
start
now,
because
the
longer
you
wait,
the
bigger
your
junkyard
will
grow.
You'll
be
a
lot
happier
if
you
tackle
it
now
and
establish
some
maintenance
into
your
processes.
A
If
you're
a
new
company
start
with
this
mindset
from
the
beginning,
because
you
will
also
be
very
happy
that
you
did
years
from
now
when
people
are
doing
this
maintenance
out
of
habit
and
it's
an
expectation
instead
of
like
something
that
you
have
to
introduce.
Ask
why
always
ask
why?
Why
are
we
publishing
this?
Why
do
we
care
about
this?
Why
don't
we
care
about
this?
Why
are
we
building
something
new
instead
of
contribute
to
this
big
vast
infrastructure?
A
That
needs
a
lot
of
help
to
keep
running
on
github
and
don't
make
cleanup
your
burden
so
don't
become
obsessive
about
it
and
so
that
it's
like
not
fun,
because
it
can
easily
not
become
not
fun
like
when
our
mom's
asked
and
dad's
asked
us
to
clean
our
rooms.
Up
like
that,
wasn't
fun
right.
We
often
rebelled.
I
did
and
had
lots
of
stuff
on
the
floor.
Your
developers
might
do
that
too,
and
you
might
want
to
do
it
like.
Why
are
we
doing
this
to
ourselves?
A
This
wasn't
supposed
to
be
like
this,
so
cut
some
slack.
This
is
hard
work
and
it's
not
going
to
happen
like
magic.
You
know
it's
an
evolutionary
process.
Keep
it
simple
as
well.
Don't
make
so
many
guidelines
that
people
hate
them
and
my
last
ask
is
please
respond
to
people
like
this
is
like
my
the
biggest
thing
like
it's
so
unfriendly,
not
to
respond
to
people
who
are
trying
to
ask
you
about
your
projects
or
contribute
to
it.
A
Just
please
do
it
and
I've
put
this
quote
from
Josh
burkas,
who
is
helping
us
develop
one
of
our
projects
Patroni
this
a
Postgres
high
availability
template
like
he
recently
wrote
a
blog
post
where
he
talks
about
like
why
it?
What
happens
when
you
don't
respond
to
people?
They
just
have
no
incentive
to
ever
help
you
again,
and
so
the
golden
rule
is
really
applicable
to
open
source.
Think
about
it,
or
else
you
might
have
a
junkyard
that
you
could
have
avoided
just
by
communicating
to
the
world
and
helping
them
help
you
so
I'm
done.