►
Description
Presented by Stefen Fejes, UI Engineer at 30 Seconds
Wonder what's it's like to grow one of the fastest growing open source projects before graduating from high school? Since it's release, 30secondsofcode.org was nominated as the 6th fastest growing open source project by GitHub in 2018, gathered over 45,000 stars, made it to Hacktoberfest trending lists, and started series of education projects used by thousands of developers daily. Growing an organization of this size isn't easy, especially when a newbie is running it. Stefan will share some of his most inspiring and challenging moments of running the organization—and share tips for maintainers and teams starting their own open source projects.
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
Thank
you
so
much
for
joining
in
I
really
appreciate
it.
It
feels
so
awesome
to
be
here
after
more
than
30
hours
spent
in
the
air
and
flying
from
Serbia
to
San
Francisco.
My
name
is
Stefan
and,
as
few
organizers
of
this
conference
already
told
me,
I'm
actually
the
youngest
speaker
at
this
year's
good
have
universe
conference.
So
that's
kind
of
unique
I
know.
Thank
you.
I
know
the
bio
says
I'm
19
years
old,
but,
as
you
all
know,
time
flies
so
I
had
to
turn
20
years
old
at
some
point.
A
As
a
front-end
engineer,
I
mostly
worked
with
JavaScript
and
I,
usually
joked
that
I
have
a
black
belt
in
JavaScript.
So
there's
a
reason
why,
this
year,
this
Karate
emoji
and
the
reason
why
I'm
here
today
is
actually
to
talk
about
open
source
and
I'll,
be
talking
about
building
an
open
source
community
from
the
ground
up.
So
here
are
some
projects
that
have
done
in
the
previous
two
years
season
started
by
coding
journey.
The
last
one
is
this
called
accessibility
guide?
A
It's
just
a
guide
to
help
you
make
accessible
websites
and
all
this
one
most
popular
one.
Is
this
called
one
called
30
seconds
of
code,
so
today
we
are
going
to
learn
from
our
mistakes
and
you're,
going
to
hear
some
tips
and
tricks
on
how
we
managed
to
grow
one
project
from
zero
to
more
than
50
1000
github
stars.
A
So
when
people
in
conferences
or
meetups,
ask
me
Stefan
what
is
30
seconds
of
code
about
and
I
usually
tell
them
it's
a
curated
collection
of
useful
JavaScript
snippets
that
you
can
understand
in
30
seconds
or
less,
and
you
know
it's
enough
for
somebody,
but
for
more
people
it
needs
a
bit
more
description.
So
the
way
we
saw
there
is
one
problem
in
our
community
is
that
when
people
who
are
starting
to
code,
they
usually
solve
the
problems
in
a
similar
way.
They
found
a
problem.
They
just
Google
the
error
message
or
Google.
A
The
problem
and
the
first
thing
that
pops
up
is
actually
the
stack
overflow
link
or
some
third
party
blog
post.
So
they
just
copy
and
paste
that
code
into
their
own
editor
and
hope
is
going
to
work
out,
but
unfortunately
it
doesn't
usually
work.
So
they
go
back
and
copy
it
once
again,
and
you
know
once
they're
finished,
they
think
they've
done
a
great
job,
but
in
reality
they
didn't
the
problem
from
copying.
Somebody
else's
code
is
obviously
code,
consistency
and
optimized
solutions
and,
most
importantly,
the
lack
of
documentation.
A
So
when
beginners
copy
somebody
else's
code,
it
might
work,
but
they
have
no
idea
how
it
works
and
overall
we
think
it
is
a
bad
onboarding
experience
for
a
lot
of
people,
including
the
ones
who
are
jumping
to
JavaScript.
So
we
created
this
little
resources
called
30
seconds
of
code.
It's
just
a
collection
of
small
cards
where
each
card
represents
one
utility
function.
A
So
if
each
car
has
a
name,
a
description
of
what
a
function
does
and
a
bit
more
longer
description
on
how
it
works,
and
there
is
a
code
and
on
the
right
hand,
side,
you
can
see
a
copy
to
clipboard
button,
so
you
can
actually
copy
the
snippets
into
your
code
editor
and
use
them
across
your
projects,
and
we
even
went
a
step
further
and
added
examples.
So
people
can
actually
see
given
an
input.
What
is
going
to
be
the
output
of
the
function
and
how
it
actually
works?
A
So
when
I
say
we'
I
actually
mean
the
community.
This
is
not
a
project
that
I
have
started
originally,
so
in
numbers
there
are
more
than
380
snippets
made
by
nearly
200
contributors.
Now
and
together.
Those
contributors
made
over
5,000
commits
merged
more
than
800
pull
requests
and
opened
and
successfully
sold
nearly
the
200
issues.
So
this
number
might
be.
You
know
big
for
me,
small
for
you,
but
for
github
it
was
pretty
big.
A
We
managed
to
be
the
sixth
fastest
growing,
open
source
repository
of
2018
and,
most
importantly,
for
us,
this
is
an
idea
that
started
serious
of
our
education
projects.
Then
gonna
talk
in
a
second,
so
the
question
after
this
introduction,
I
get
usually
is
how
it
all
started.
You
know
a
lot
of
people
assume
that
I
started
coding
when
I
was
5
years
old
or
that
my
parents
are
from
engineering
backgrounds,
so
I
kind
of
had
some
boost
in
the
early
career,
but
the
truth
is
done.
A
So
let
me
ask
you
like
what
was
your
dream
job
and
you're
a
child?
A
lot
of
my
friends:
they
wanted
to
be
like
policeman's,
doctors,
surgeons
actors,
my
sister
nowadays,
she
wants
to
be
a
youtuber,
and
a
lot
of
my
friends
back
then
wanted
to
be
astronauts
and
to
drive
that
those
fancy
spaceships
and
my
spaceship
was
this
one.
So
I
just
wanted
to
be
a
garbageman.
I
still
have
no
idea.
A
A
So
this
is
what
fulfills
me,
but
even
then,
like
my
first
day
in
tech,
were
not
that
great,
so
originally
I
had
to
pick
a
high
school
to
go
to
and
for
a
long
time,
I
wanted
to
be
a
Lego,
brick
designer,
but
my
parents
didn't
know
like
which
school
I
should
go
to
in
order
to
become
one
and
back
in
Serbia.
That
school
didn't
even
exist,
so
it
wasn't
worth
it
so
I
had
to.
Like
pick
high
school
on
my
own
and
luckily
there
was
a
computer
science
experimental
class
in
my
school.
A
It
was
just
20
of
us
and
it
wasn't
great
either
so
I
started
and
I
had
to
cheat
in
high
school
because
I
wasn't
doing
so
well,
so
the
thing
was,
we
were
doing.
C-Sharp
and
I
was
sitting
in
the
first
row
of
the
classroom,
because
I
couldn't
see
sharp
right,
I,
wear
glasses
and
back
then
I
didn't
work
glasses
so
that
that
was
the.
A
A
I
would
copy
it
erase
all
the
variables
and
exchange
it
with
my
own
set
of
variable
names,
and
you
know
it
worked
for
two
or
three
months
until
we
were
given
exercise
to
to
actually
do
some
array
manipulation,
so
it
was
I
think
sorting
exercise.
Any
word
like
swept
to
elements
we
needed
to
introduce
a
third
variable
called
temporary.
That
is
going
to
hold
the
value
of
the
first
one
and
the
way
we
do
it
is
we
usually
introduce
the
third
variable
called
temporary
in
English.
A
We
short
heading
short-handed
to
the
TMP,
but
my
friend
was
not
good
at
English,
so
he
just
used
the
variable
name:
TRT
and
I
copy
the
same
code
exchange
all
the
variable
names,
but
forgot
to
change
the
trt
variable,
and
that
was
the
test
where
I
got
caught.
So
at
that
point,
I
realized,
you
know,
I
should
get
better
at
coding,
start
learning
on
my
own,
and
that
was
the
day.
A
I
got
into
web
development
and
I
did
my
first
two
internships
and
it
was
time
for
the
third
one
and
everybody's,
like
you
need
this
tool
called
have
on
your
resume
sounds
like
okay,
let's
start
and
I
was
browsing
to
read
it
and
found
this
awesome
project
called
30
seconds
of
code.
It
got
it
just
got
released
on
that
day
and
I
was
like
I
want
to
contribute.
So
I
made
my
first
full
request
and
thanks
to
it,
I
felt
like
so
awesome
once
I
done
so
it
was.
A
It
was
awesome
feeling,
so
it
was
just
because
of
this
guy
and
his
fast
and
responsive,
fast
and
supportive
response,
and
that
was
the
day.
I
said
you
know:
I
want
to
contribute
to
open
source
and
I
want
to
maintain
this
project
called
30
seconds
of
code
and
back
then
you
know
we
didn't
even
have
a
website.
A
So,
instead
of
copying
them
from
other
resources
like
Stack
Overflow,
he
wrote
them
himself
and
after
some
time
he
started
collecting
them.
So
once
he
got
to
20
snippets
few
lies:
why
not
just
share
it
and
see
how
it
works
out?
He
honestly
thought
it
was
like
a
very
stupid
idea,
but
it
turned
out
to
be
great,
so
the
takeaway
I
want
to
to
make
from
here
is
to
actually
let
every
idea,
no
matter
how
crazy
show
its
true
potential
a
lot
of
fast.
When
we
think
about
ideas,
we
think
that
our
they
are.
A
Our
ideas
are
like
very
good
in
the
first
few
minutes,
but
then,
after
that,
we
think,
like
it's
stupid
and
nobody's
going
to
like
them,
so
some
tips
for
finding
an
idea.
You
can,
for
example,
open
source
some
of
your
existing
projects,
and
there
is
probably
something
that
you
have
worked
on
for
the
last
two
years.
Also,
you
can
open
source
part
of
your
working
project.
A
So,
for
example,
if
you
open
source
wanting
in
the
social
community
you're
going
to
be
perceived
as
a
good
company,
and
also
your
hiring
process
is
going
to
be
much
much
more
easy
because
you
can
just
hire
people
who
contribute
to
your
project
and,
like
it
already
and
last
but
not
least,
you
can
start
something
new
and
today
we're
actually
going
to
talk
about
all
these
three
topics
and
all
the
tips
that
you
are
going
to
hear
are
applicable
to
any
of
your
projects.
So,
as
I
mentioned,
I
made
my
first
commit.
A
It
was
the
first
day
that
that
project
got
released
and
the
next
few
weeks
were
total
chaos,
so
that
reddit
post
went
from
zero
to
two
thousand
kill
half
stars
and
it
fan
it
felt
like
a
disaster.
There
were
hundreds
of
full
requests
to
review
and
tons
of
open
issues.
There
was
no
continuous
integration
and
there
was
like
a
lot
of
duplicate
code
and
without
any
contribution
guidelines
to
guide
future
contributors
on
how
they
can
help
the
project.
A
So
at
that
point,
Angelus
was
like
it's
not
doable
for
one
person
and
he
had
to
form
a
team.
So
the
team
was
formed
in
in
almost
no
time
we
just
picked
the
people
who
are
most
engaged
in
the
early
days
and
I
mean
obviously
you
you
it's
okay
to
start
alone
and
general
started
alone
and
I
joined
him
later
on.
So
it's
probably
the
most
frequent
way
to
start
an
open-source
project.
A
If
you
do
not
want
to
go
along
talk
to
people
from
the
community
or
your
colleagues
and
friends
and
convince
them,
your
idea
is
worth
making,
and
the
best
thing
for
me
is
that
if
you
like
somebody
else,
this
idea
just
don't
join
them.
So
there
are
probably
a
lot
of
projects
that
you're
using
that
are
open
source
and
it
would
be
so
cool
if
you
actually
work
on
something
that
you're
using
every
day
and
the
maintainer
subject.
Project
are
going
to
appreciate
it.
A
A
lot
so
I
didn't
want
this
talk
to
be
just
about
me.
So
I
created
this
repository,
called
killer
universe,
talk
and
invited
all
of
my
friends
who
joined
the
organization
early
on
to
hear
their
opinions
on
it.
So
next
slides
up
till
the
end
are
just
opinions
of
all
of
us.
So
if
you
do
not
like
the
presentation,
just
feel
free
to
open
the
full
requester
issue
and
yeah,
so
we
realized
that
having
a
great
people
around,
you
is
essential.
A
You
know
through
open
source,
we
develop
a
lot
of
friendships
and
once
we
reach
like
50,000
stars,
I
told
myself,
I
would
get
the
airplane
ticket
and
meet
all
the
contributors
who
were
active
in
the
early
days.
So
there
isn't
luckily
that
many
of
them-
and
there
was
one
quote
from
one
team
member-
his
name-
was
Atomics.
A
He
said
the
team
was
very
helpful
in
encouraging
which
made
the
atmosphere
to
repository
very
welcoming
and
I
felt
great
to
be
part
of
it,
and
there
specifically
this
part
that
I
really
liked,
and
for
me
this
is
what
open
source
should
be
like,
and
it's
not
really
a
secret
and
how
we
can
get
there.
So
the
way
we
get
there
is
actually
building
an
amazing
developer
experience
around
the
project
and
today,
I'm
actually
going
to
share
with
you
some
tips
and
tricks
that
I
found
really
useful.
A
So
this
is
my
little
checklist
we're
going
to
cover
all
of
these
things
and
starting
with
code
quality.
So
the
reason
why
a
lot
of
people
join
open-source
is
actually
to
to
learn
best
practices,
learn
on
your
language
and
they
want
to
actually
see
the
good
examples
of
code,
and
if
our
repository
is
not
well
structured,
it's
you
know
it's
not
going
to
be
worked
for
them,
so
they're
just
going
to
skip
it
and
you're
going
to
miss
your
users
and
the
future
contributors.
A
So
a
few
of
the
tips
I
give
is
to
actually
stick
to
a
coding
style
guide
and
be
consistent,
so
remove
every
clutter
that
you
do
not
find
useful.
I
bet
there
a
lot
of
like
and
use
variable
senior
project
or
unnecessary
files
that
are
just
making
it
hard
for
everybody
that
is
coming
to
the
project,
to
understand
what
is
happening
and,
for
example,
to
achieve
all
of
this.
Maybe
you
can
use
something
like
code
linters
and
for
matters
on
good
hooks.
A
So
for
those
of
you
who
do
not
but
not
know,
the
git
hooks
are
like
triggers
for
scripts
that
are
going
to
be
run
before
or
after
certain
get
actions.
So,
for
example,
we
added
a
linter
on
pre-commit
hook,
so
a
linter
is
going
to
listen
for
all
the
unused
variables
or
bad
coding
practices
before
somebody
commits
code
so
later
on,
you
won't
have
a
problem
in
reviewing
somebody
else's
code
because
it's
going
to
be
as
good
as
possible
and
we
also
run
for
matters
on
hooks
that
are
happening
after
the
commit
was
made.
A
So
we
actually
don't
require
people
to
use
like
spaces
or
tabs.
We
just
like
do
it
ourselves.
We
have
for
matters
automatically
and
I'm,
not
an
expert
on
code
quality,
so
that
would
be
it,
and
the
next
advice
that
I'm
going
to
give
is
about
documenting
your
code.
It's
like
probably
the
most
boring
thing
that
you
you're
thinking
right
now,
but
I'm
actually
not
going
to
talk
about
traditional
stuff
I'm
going
to
talk
about
writing
good,
commit
messages.
So
the
way
we
write
usually
code
is
this.
A
We
just
want
to
release
the
feature
as
fast
as
possible,
and
we
usually
end
up
with
commit
messages
that
look
like
this
or
maybe
not
exactly
like
this,
but
they're,
usually
like
one-liners
that
include
up
to
like
20
or
30
changed
files
and
for
the
next
person
who
comes
to
our
code
base.
They
mean
totally
nothing.
It's
just
a
way
for
us
to
push
the
code,
and
the
idea
I
had
is
that
we
should
actually
tell
stories
throughout
our
commits.
A
So
there
is
specific
structure
that
I
found
out
that
works
great
for
us
and
for
all
the
people
who
are
contributing
to
organization,
and
this
is
actually
it.
So
you
start
by
having
a
short
one-line
title
of
your
commit,
which
is
actually
going
to
be
up
to
like
I,
think
50
characters,
because
it's
going
to
be,
like
short,
understandable
and
actually
the
github
UI
shows
up
to
50
characters
on
each
commit
message.
After
that,
you
want
to
provide
a
longer
description
of
what
a
change
is
doing.
A
You
know
if
the
title
is
not
enough,
if
you're
using
a
bit
more
files
in
there.
So
you
should
definitely
like
include
description
of
it.
You
should
also
add
an
explanation
of
why
the
change
is
being
made
a
lot
of
us
doing
open
source.
Don't
do
it
full-time.
So
when
we
contribute
to
a
project
maybe
for
a
week,
then
we
make
a
longer
pass
and
then
come
back
to
it.
A
So,
for
example,
for
power
users,
you
can
just
search
the
whole
code
base
and
for
average
user
and
beginner
like
me,
you
can
install
extensions
like
guidelines
which
are
going
to
high.
So
when
you
highlight
each
line
of
code
they're
going
to
display
the
commit
message
next
to
it,
and
this
way
I
think
you
have
like
every
single
line
documented,
which
is
exactly
what
you
want
in
in
your
project,
and
this
is
not
something
that
I
came
up
with,
so
this
blog
post
up
here
is
actually
a
very
cool
one.
A
It
includes
like
a
longer
story
of
what
I
told
today
and
link
down.
There
is
actually
a
link
to
repository
called
get
flight
rules.
It's
a
repository
that
stores,
like
all
the
tips
and
tricks
on
how
it
needs
self-command
github,
gets
problems
on
our
projects.
So
next
in
our
list,
our
simplification
of
onboarding
experience.
So
in
order
to
like
attract
contributors,
you
kind
of
need
to
to
do
it
in
some
way
and
the
first
thing
that
they
see
when
they
enter
your
project
is
actually
your
readme
file.
A
So
the
idea
here
is
to
make
the
readme
file
as
appealing
as
possible,
and
you
know
this
is
our
really
file.
It's
not
perfect,
but
some
things
that
you
should
take
care
of
is
definitely
like
having
a
name
and
a
catchy
description.
Catchy
description
is
the
thing
that
people
are
going
to
read
it
first
and
if
it's
not
good
enough,
some
of
them
might
just
not
continue
reading
what
the
project
is
about.
A
You
also
want
to
include
some
kind
of
fancy,
graphics
and
those
trust
badges
over
there,
and
you
do
not
have
to
be
a
designer
for
that.
You
can
just
download
some
free
icons,
change
the
color
of
them,
add
text
and
create
the
original
order.
This
is
what
we
did
and
it
turned
out
to
be
pretty
good,
and
once
you
include
that
you
want
to
include
a
QuickStart
guide.
A
So
don't
just
link
to
Doc's
include
a
Quick
Start
Guide
telling
the
your
users:
how
can
they
benefit
from
your
project
and
what
they
can
do
and
if
they
get
interested
by
the
QuickStart
guide,
then
you
should
link
like
to
the
documentation.
So
the
documentation
should
not
take
place
in
the
individual
file.
It
should
be
either
like
in
the
github
wiki
page
or
some
third-party
resource,
and
so
now
they
are
using
your
project.
They
figure
out
how
to
do
so
and
they
might
be
interested
in
contributing.
A
So
you
definitely
want
to
have
a
contribution
guidelines
and
it's
a
file
that
I'm
going
to
talk
about
next
and
also
you
should
have
a
code
of
conduct
and
license.
I
know
a
lot
of
people
forget
about
is,
but
those
two
are
really
important.
So
if
people
are
like
violating
the
code
of
conduct
feel
free
to
just
kick
them
out
of
organization
and
also
take
care
about
the
license
on
the
first
day,
because
if
you
don't,
people
can
actually
for
the
whole
repository
and
you
know,
make
profit
out
of
it.
A
A
So,
if
I'm
the
country,
if
I'm
the
person
who
wants
to
contribute
to
your
project,
like
what
can
I
do
in
order
to
help
you
so,
for
example,
open
up,
will
request
which
snippets
for
the
JavaScript,
open
issues,
fix,
typos,
add
tests
and
a
bunch
of
other
stuff,
and
now
that
you
told
the
user
how
to
do
what
to
do?
You
need
to
actually
help
them
on
to
achieve
that.
A
So,
for
example,
a
lot
of
users
are
like
actually
the
first
time
contributors,
so
you
kind
of
want
to
add
links
to
the
starting
guide
and
github,
and
actually
github
has
a
lot
of
like
blog
posts
that
are
helping
first-timers
contribute
to
open
source.
So
you
should
just
link
to
them
and
forget
about
writing
those
on
your
own
and
last
but
not
least,
you
should
include
who
to
ask
for
help.
A
So
a
lot
of
people
put
a
lot
of
effort
into
composing
pull
requests
and
they
might
get
stuck
at
like
95%,
and
you
know
it's
going
to
make
them
feel
sad.
So
you
should
just
include
some
resources
and
like
who
should
I
ask
for
help.
Maybe
include
your
email
or,
if
you're
not
too
busy
like
I,
am
offer
one-to-one
a
mentorship
classes
and
it
would
work
out
definitely
so
when
you
have
the
contributing
MD
file,
it's
automatically
going
to
be
displayed
in
the
indigent
hub
UI.
A
So
when
somebody
is
trying
to
open
an
issue
or
start
on
your
pull
request,
it's
going
to
be
up
there
and
the
idea
behind
contributing
MD
file
is
that
you
should
explain
everything
like
on
five,
so
you're,
probably
familiar
with
that
subreddit
li5.
It's
basically
the
idea
of
explaining
everything
to
a
five-year-old
and
the
way
I
solve.
This
is
I'm
a
little
diagram
showing
like
what
is
the
contribution
process
for
30
seconds
of
code
like
so.
What
can
people
do
as
a
first
step?
I
can
do
as
a
second
step.
A
A
I
know
it
maybe
sounds
obvious,
but
a
lot
of
people
don't
do
this,
and
because
of
that,
their
onboarding
experience
is
not
even
that
good,
and
now
you
kind
of
want
to
to
welcome
the
first
time
contributors
in
some
way
and
for
me,
like
the
github,
is
perfect
place
to
do
this,
because
you
have
everything
set
up
in
one
place
so
with
over
forty
million
users.
I
just
think
that
github
is
writing.
A
I
mean
they're,
doing
like
all
the
marketing
in
the
social
community
and
people
just
seem
to
to
know
about
it,
and
some
events
like
Oktoberfest
are
a
great
place
to
attract
the
first-timers
and
I
know
a
lot
of
people
that
come
to
Oktoberfest
because
of
the
free
shirt.
But
you
you,
as
a
maintainer,
should
make
this
experience
more
than
just
a
free
shirt.
You
should
actually
show
them
what
is
open-source
about
and
after
that
they
want
to
ask
this
like
stupid
question.
If
I
make
it
pull,
requests,
do
I,
get
two
free,
shirts
and
yeah.
A
So
after
that,
you
you
want
to
know
that
contributing
to
open
source
for
the
first
time
can
be
very
daunting.
It's
so
hard
to
like
figure
out
and
how
to
to
do
so.
First
of
all,
people
need
to
find
a
motivation
and
motivating
somebody
to
do
something
for
free
and
spend
their
time,
like
their
most
valuable
asset
is
on
its
own,
very
hard
thing
to
do
so
once
they
find
a
motivation
like
I
did
for
the
job
interview
and
having
the
github
I
need
to
figure
out
a
way
on
how
to
contribute.
A
So
a
good
tip
is
to
actually
add
those
good
first
issue,
labels
to
your
issues,
so
that
people
who
are
new
to
the
industry.
They
can
actually
look
up
those
and
try
to
sell
some
easier
problems
at
first.
So
after
that,
you
know
they
figure
out
the
ways
in
which
they
contribute.
They
need
to
make
this
little
next
step,
which
is
like
forking,
the
repository
and
for
a
lot
of
people.
A
It's
like
very,
very
strange
thing
to
do
so
without
some
proper
guidelines
and
introduction
to
the
github,
it's
very
very
hard
for
them
to
even
come
to
this
church
step
and
after
that,
you
need,
they
need
to
make
changes
and
without
good
documentation
and
good
contributing
Docs.
It's
so
hard
to
do
so,
and
finally,
they
open
the
pull
request.
A
You
know
it
might
be
a
good
one
if
they
done
all
the
steps
correctly,
but
the
chances
are
low
because
their
first
time
contributing
to
open
source
and
they
probably
missed
a
bunch
of
stuff
in
the
mean
time
and
we
as
the
maintainer
are
responsible
to
keep
them,
because
it
just
takes
a
bit
of
negativity
to
remove
the
motivation
we
had
in
the
first
place.
So
this
place
over
here
is
the
area
where
you
should
shine.
A
You
know
when
somebody
opens
up
or
requests,
don't
just
blame
their
here
if
they
made
a
mistake,
point
it
out,
but
also
point
out
on
the
good
stuff
they
made
offer
help
if
you
think
they
need
it
or
perhaps
if
they
open
up
or
request,
but
never
came
back
to
it
after
your
review.
Do
a
follow
up
tag
them
and
see
if
you
can
make
it
through
to
the
final
steps
and
the
idea
behind
this
box
is
to
be
nice
to
everybody.
A
So,
for
example,
this
this
autumn,
this
October
there
was
a
Hector
burr
Fest
and
there
was
one
project
called
30
seconds
of
interviews
that
I
developed,
and
we
kind
of
the
idea
behind
a
project
is
to
provide
questions
and
detailed
answers
for
people
who
are
preparing
for
their
web
development
interview,
and
we
didn't
have
questions
on
accessibility.
So
I
kinda
marked
that
as
a
good
first
issue
for
somebody
and
one
girl
from
India,
she
was
like
she
wants
to
contribute,
so
she
made
her
first
full
request.
A
It
was
like
really
really
good,
and
you
know
this
was
my
response
to
her,
and
you
know
after
a
few
days
she
responded
with
this
and
in
the
next
few
weeks
we
had
a
full
accessibility
category
on
our
website
that
she
developed
on
her
own,
which
is
I,
think
fantastic.
So
also
when
communicating
on
a
project
you
should
use
like
the
simpler
language.
You
know
from
the
github
stats
of
this
year,
I
think
more
than
like
80%
of
the
people
are
coming
from
the
outside
of
us
and
it's
really
really
hard
to
communicate.
A
Well,
especially
on
our
project,
my
team
was
very
diverse.
We
were
coming
from
all
over
the
world.
English
was
not
our
first
language,
so
we
kind
of
needed
to
figure
out
a
way.
So
the
best
thing
to
do
is
actually
know
as
simple
English
as
possible,
without
keeping
everything
too
much
complicated
and
also
like
format
text
nicely,
so
people
can
actually
navigate
more
easily
around
and
the
takeaway
from
here
is
to
actually
tread
treat
contributors
like
your
guests.
A
So
the
idea
is
to
make
them
feel
like
they're
at
home,
and
you
know,
if
you
do
so,
I
think
you're
going
to
cover
all
these
steps,
and
we
did
so.
It
worked
pretty
great
for
us.
We
managed
to
be
the
first
learn
to
code
repository
that
is
recommended
by
github
when
you're
starting
to
learn
code,
and
we
actually
managed
to
announce
a
lot
more
educational
projects
such
as
this
one
called
30
seconds
of
CSS.
A
It's
like
a
collection
of
a
bunch
of
CSS
examples
on
how
you
make
like
fancy,
spinners
or
animations
or
gradients
or
bunch
of
other
stuff
for
about
developers.
I
also
launched
the
one
called
30
seconds
of
interviews
so
because
I
was
preparing
for
a
lot
of
job
interviews.
Back
then
I
collected
around
200
interview,
questions
and
carefully
written
the
answers
for
all
of
them.
A
So
a
lot
of
people
actually
got
a
job
from
this
website
and
it
feels
so
good
when
they
message
me
and
say
like
this,
helped
us
a
lot
and
they're
also
a
project
for
community
like
this
one
called
three
seconds
of
knowledge.
So
one
day
I
was
browsing.
The
product
hunt
and
the
first
training
project
of
the
day
was
30
seconds
of
knowledge.
A
It
was
a
Chrome
extension
that
took
all
our
learning
resources
and
put
them
in
like
a
new
tab
space
and
we're
so
like
upset
on
that
day,
because
somebody
just
took
all
of
our
ideas
and
made
our
Chrome
extension
out
of
it.
But
soon
I
realized
that
the
guy
who
made
it
lives
like
50
kilometers
away
from
me,
which
is
like
a
half
an
hour
drive.
So
it
was
okay
and
he
moved
the
whole
project
to
his
to
our
organization
and
he's
right
now
contributing
to
it
as
well,
which
is
awesome.
A
The
extension
also
exists
for
Firefox.
If
you
want
to
check
it
out,
it's
a
cool
learning
resource.
It's
like,
for
example,
every
time
you
open
a
new
tab,
you're
going
to
see
something
new
from
our
organization
and
the
idea
here
you
see
all
of
those
successful
projects
as
organization
we
made
I,
don't
know
over
like
80,000
github
stars
or
something
and
the
takeaway
is
not
to
be
anxious
about
numbers.
I
mean
numbers
of
commits
stars
traffic,
Falls
issues,
you
know,
PR
is
going
old.
A
It
just
doesn't
matter
like
you're
here
in
the
open
source
to
enjoy
your
time
and
there's
always
going
to
be
like
one
subway
station.
That
is
a
better
programmer
than
you
are
so
then
there's
like
kind
of
no
point
in
competing
with
that
and
I
was
because
I
was
searching
for
a
job.
You
know
I
was
doing
github
non-stop,
so
for
every
Christmas,
like
your
graph,
looks
something
like
this
mine
was
getting
greener
and
greener
and
greener
and
greener.
A
So
I
made
a
tree
commits
for
a
Drupal
age,
83
commits
for
83
unit
tests
and
it
was
like
nonsense
so
and
you
can
even
like
fake
the
whole
github
history
graph.
Is
that
your
thing
they're,
like
a
bunch
of
websites
that
you
can
draw
your
own
thing
and
just
import
that
to
github
directly?
So
there
is
no
way
in
competing
with
that,
and
there
is
one
little
tweet
from
Jason.
I
will
look
up
to
him.
A
He
said
the
periodic
reminder
open-source
maintainer
czar
doing
their
best
to
keep
up
with
a
firehose
of
questions,
bug
bugs
imperfect,
Docs
and
so
many
other
tasks
that
is
easy
to
take
for
granted.
Please
thank
them
and
be
kind
to
open-source
maintainer.
Usually
they
hear
only
the
bad
feedback,
and
this
is
very
true.
So
if
you
want
to
complain
to
something,
just
don't
do
it,
I
mean
haters
are
always
going
to
be
louder
and
their
approach
and
open
source
is
something
like
this.
A
A
To
close
this
talk,
I
mean
there
is
obvious,
like
this
quote,
from
atomic
from
the
early
on
that
open
source,
open
source
should
be
this,
so
we
all
want
to
be.
We
all
want
to
feel
great
to
be
part
of
it
and
I
found
one
gift.
That
explains
what
we
should
not
be
doing
so,
for
example,
this
is
your
future
contributor.