►
From YouTube: Intro: Contributor Experience SIG - Jorge Castro, VMware & Bob Killen, University of Michigan
Description
Don’t miss out! Join us at our upcoming events: EnvoyCon Virtual on October 15 and KubeCon + CloudNativeCon North America 2020 Virtual from November 17-20. Learn more at https://kubecon.io. The conferences feature presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Intro: Contributor Experience SIG - Jorge Castro, VMware & Bob Killen, University of Michigan
In this 30 minute session, we will explore the projects we have been working on with Contributor Experience and the future work we have on deck. We will provide an update to the following projects and have information on how to get involved.
https://sched.co/c9yh
A
A
We
get
started.
The
kubernetes
community
is
massive.
We
have
over
48
000
drive-by
contributors,
that's
how
we
classify
people
who
have
submitted
issues
or
prs
or
fixes
to
kubernetes
and
out
of
those
we
have
about
almost
1200
org
members,
which
we
consider
to
be
for
developers
who
are
larger
contributors
to
the
project.
We
manage
about
209
repositories
in
github
and
have
processed
almost
167
000
pull
requests
and
have
a
healthy
community
of
100
000
users
in
our
slack.
That
should
give
you
an
understanding
of
who
we
are.
A
Kubernetes
is
divided
into
23
cigs,
11
working
groups,
3
committees
and
2
user
groups.
We're
diverse
sig
with
a
lot
of
different
people
with
different
backgrounds,
work
at
different
companies
and
different
interests.
We
tend
to
be
the
meta
sig
for
the
project.
If
you
consider
kubernetes
as
a
large
network
of
interconnected
groups,
we
tend
to
be
the
grand
central
station,
where
cigs
can
collaborate
around
making
things
better
for
themselves
and
for
new
contributors.
If
you
have
no
idea
where
to
contribute,
then
we'd
be
honored
to
be
your
first
sig.
A
It's
not
uncommon
for
people
to
hang
out
with
us,
while
they
understand
and
figure
out
how
the
project
works
and
then
move
on
to
whatever
specialized
sig
interests
them.
More
remember.
Kubernetes
is
an
operating
system.
People
love
to
play
with
networking
for
a
while.
They
want
to
learn
how
storage
works
and
they
maybe
dip
their
toes
in
the
apis.
There's
no
wrong
way
to
do
it
and
there's
never
a
shortage
of
work
in
any
area
of
kubernetes.
A
So
for
us
finding
a
place
for
you
makes
us
happy
so
you've
met
myself
and
bob
sigs
have
co-chairs
and
tech
leads
who
are
facilitators
of
the
sig.
Our
job
is
to
keep
the
ball
rolling
and
ensuring
people
are
empowered
to
fulfill
to
do
the
things
that
they
want
to
do.
It's
also
a
ton
of
fun
bob-
and
I
are
your
co-chairs
and
nikita
raganath
and
christoph
blecker-
are
our
technical
leads.
We've
been
selected
to
represent
the
sig
as
your
chairs
and
tech
leads.
A
Let's
talk
about
teams,
kubernetes
is
huge.
Dividing
and
conquering
is
really
the
only
reasonable
way
to
accomplish
a
large
amount
of
work.
At
the
same
time,
so
we
tend
to
be
divided
into
teams
and
sub
projects
which
we'll
get
to
in
a
little
bit.
Our
teams
are.
We
have
an
events
team.
We
have
a
marketing
team,
we
have
a
github
administration
team.
We
have
a
stream
team
which
handles
our
youtube
work.
We
have
a
team
of
moderators,
an
entire
team
of
people
who
handle
the
asia
pacific
time
zone
and
community
managers,
which
is
our
team.
A
So
what
do
we
do?
You
might
have
seen
our
work.
Doing
your
first
pull
request
to
kubernetes
any
given
time
we
have
a
thousand
or
so
open
pull
requests.
So
we
depend
on
automation
to
help
put
those
pr's
in
front
of
the
right
eyeballs
doing
that
requires
assembling
processes
for
us
to
follow
on
how
to
do
exactly
that.
That's
just
one
example
of
a
process
that
we
work
on.
We
usually
have
one
of
these
processes
for
every
part
of
the
contribution
process.
A
Things
like
when
should
we
expire,
abandoned
github
issues
to
what's
the
best
way
to
onboard
a
new
person
to
what
kind
of
label
should
the
project
use?
We
do
this
for
consistency,
reasons
so
contributing
to
sig.
Networking
should
feel
familiar
to
you
if
you've
contributed
to
storage,
for
example.
So
we
strive
to
get
contributors
consistent
experience
across
the
project
while
at
the
same
time
providing
services
to
these
other
cigs
to
make
their
lives
easier.
A
So
first
things.
First,
we
have
a
nice
large
list
for
you
of
every
sig
here
at
this
link.
This
lists
the
sig,
the
co-chair,
their
slack
channel,
their
mailing
list
and,
more
importantly,
their
meetings
and
their
meeting
notes.
All
sig
meetings
are
public
and
have
a
public
notes
document.
This
is
a
great
way
to
browse
on
what
you
want
to
do.
So,
if
you
start
at
this
page
click
around
see
what
interests
you
and
then
you
can
dig
a
little
bit
deeper
into
each
one
of
these
sigs.
A
We
also
publish
a
community
calendar
which
has
all
of
those
seg
meetings
and
other
project
meetings
in
one
place
we
recommend
subscribing
to
the
calendar
so
that
you
can
see
what's
going
on
in
the
community.
Also,
if
you
subscribe
to
that
sig's
mailing
list,
you
will
automatically
get
a
meeting
invite
to
that
sig's
public
meeting.
A
So
what
we
do
is
we
take
everything
that
the
sig
owns
and
then
we
divide
it
into
conquerable
areas
that
we
apply
a
team
to
a
sub
project,
we're
going
to
talk
about
the
community
sub
project,
which
kind
of
owns
and
manages
the
overall
community
repo.
We
will
talk
about
the
community
management
subproject,
which
manages
the
operations
and
policy
for
a
lot
of
the
things
that
we
do
here.
Contributor
documentation
is
the
home
for
things
our
contributor
and
developer
guides
and
our
contributor
website
we
will
be
covering
devstats,
which
is
our
set
of
grafana
dashboards.
A
That
tries
to
gather
all
the
metrics
around
contributions,
so
we
can
figure
out
things
like
pr.
Velocity
average
mean
time
between
a
pr
and
merge
and
we
can
figure
out
who's
contributing
where,
and
that
gives
us
the
data
and
information
that
we
need
to
make
better
policy
decisions
and
to
figure
out
where
we
can
improve
as
a
project.
A
Events,
so
these
mostly
are
physical
events.
Some
of
you
might
have
attended
a
contributor
summit.
We
will
be
talking
about
events
and
their
effects
going
forward,
especially
in
this
calendar
year.
We
have
an
entire
sub-project
dedicated
to
github
management,
so
the
kubernetes
code
base
does
all
live
on
github
and
there's
an
entire
subproject
who
manages
that
and
bob
will
be
getting
into
those
details:
kate's
dot
io
is
our
home
page
and
it's
the
home
of
the
kubernetes
infrastructure
working
group
in
this
video
playlist.
A
There
should
be
a
status,
and
we
will
briefly
talk
about
some
of
the
things
that
we
do.
There,
mentoring,
of
course,
as
a
huge
project.
The
best
way
to
get
things
done
is
through
mentorship,
either
group
mentorship
or
one-to-one
mentorship,
there's
no
guide
or
anything
that
we
can
write,
that's
better
than
people
helping
themselves
out
to
understand
and
figure
out
how
things
work.
So
we
have
an
entire
sub-project
to
that.
A
We
will
be
dedicating
some
time
to
tell
you
how
that
works,
and
then,
lastly,
keeping
a
slack
infrastructure
healthy
is
difficult,
especially
with
such
a
large
group,
so
we're
going
to
cover
some
of
the
tools
and
policies
that
we've
put
in
place
to
make
that
fun.
A
So,
first,
community
management,
mailing
lists
and
calendars
fall
under
this.
All
of
our
mailing
lists
are
hosted
on
google
groups
and,
as
I've
been
mentioning
all
these
six
have
a
public
mailing
list
and
meetings.
It's
not
uncommon
for
sigs
to
publish
their
meeting
notes
regularly
on
their
mailing
list.
It's
usually
the
first
place
where
you
want
to
ask
a
question
or
interact
with
members
of
the
community,
so
we
host
these
as
a
project
in
one
place
for
us
a
sick,
contributor
experience.
We
do
maintain
these
and
kind
of
do
the
infrastructure
plumbing
background.
A
So
hopefully,
your
interaction
with
mailing
list
is
just
as
a
user,
and
we've
currently
made
some
progress
in
these
areas
to
make
this
less
painful
and
easier
to
manage.
For
those
of
you
that
are
using
and
multiple
mailing
lists,
all
you
really
need
to
do
is
join
the
mailing
lists
and
figure
out
how
to
organize
the
mail
in
whatever
email
service
you
use
youtube.
Youtube.Com
kubernetes
community
is
the
home
to
all
of
our
youtube
videos.
A
Not
only
will
you
find
all
the
sig
meeting
zoom
recordings
in
there,
but
you
will
also
find
some
top
level
meetings
that
we
do
host
in
there.
So,
for
example,
we
have
a
monthly
community
meeting
that
covers
all
aspects
of
the
project.
We
have
instructional
videos.
We
have
code
walkthroughs
of
certain
areas
of
the
code
base.
The
release
team
after
every
release
does
an
entire
postmortem
of
the
release
process
that
gets
recorded
and
put
in
there.
A
So
if
you
subscribe
to
this,
you
will
be
getting
weekly
updates
of
things
that
are
happening
all
over
the
kubernetes
community
and
it's
an
excellent
resource.
If
you
want
to
catch
up
on
the
long
tail
of
things
like
that,
this
sub
project
is
managed
by
the
stream
team
and
we're
always
looking
for
more
members.
We
do
have
these
meetings
and
sometimes
we
have
special
events
and
things
like
that
and
those
are
recorded
and
put
on
youtube
and
that's
done
by
a
set
of
volunteers.
A
So
we
try
to
as
a
global
project
to
cover
all
sorts
of
time
zones.
So
when
we
do
have
live
streaming,
events
that
cover,
for
example,
europe
and
the
east
coast
of
the
us
we'd
love
to
bring
that
kind
of
content
also
to
people
who
live
in
the
west
coast
or
asia
pacific.
So
in
order
to
do
that,
if
you've
got
obs
skills
or
you
know
how
to
manage
youtube
channels
for
your
video
editor,
perhaps
or
you
know
how
to
make
pretty
looking
slide
intros
for
people's
videos,
we
could
always
use
skills
like
that.
A
So
please,
let
us
know
if
you're
interested
in
something
like
that,
the
community
management
subproject
one
of
its
main
tasks-
is
owning
stuff,
github.com,
kubernetes
kubernetes
is
where
kubernetes
the
software
itself
lives.
Github.Com
kubernetes
community
is
the
community
repo.
Here
you
will
find
things
like
our
governance,
documentation,
election
procedures,
our
values,
our
code
of
conduct
and
any
kind
of
the
projects
that
are
happening
around
the
project
tend
to
live
in
the
community
repo
and
that
is
owned
by
this
sub
project.
A
Zoom,
there's
a
lot
of
things
that
this
sig
does
for
zoom
as
far
as
managing
the
licenses
that
we
need,
so
that
sig
chairs
can
run
their
meetings
and
record
them
and
all
sorts
of
stuff
as
an
end
user
contributor.
You
generally
don't
need
to
deal
with
any
of
this,
but
if
you
do
know
how
to
administer
these
tools,
like
I
said
we
always
could
use
some
help.
However,
you
can
help
us
out
by
ensuring
that
the
zoom
client
on
your
computer
is
up
to
date.
A
A
Discuss.Kubernetes.Io
is
our
discourse-powered
community
forums.
It's
a
more
user-web-friendly
way
to
have
discussions
if
you're
not
interested
in
developer
mailing
list,
so
we
kind
of
run
this.
For
our
end
users,
you
will
find
developers
there.
You
will
find
people
who
might
have
the
same
interest,
the
same
questions
and
it's
just
a
nice
long,
huge
forum,
full
of
information,
everything
from
cube,
cuddle
tips
and
tricks
to
hey
everybody
check
out
this
cool
post
that
I
saw
about
kubernetes.
A
So
it's
a
great
way
to
spin
up
on
kubernetes
information
moderators
each
of
these
tools
and
properties
that
we
use,
whether
that's
zoom
youtube,
slack
discourse
all
need
moderators.
We
do
have
a
code
of
conduct
that
needs
to
be
enforced.
We
do
expect
when
someone
comes
to
one
of
our
properties,
that
they
will
have
a
wonderful
friendly
user
experience,
and
for
that
we
depend
on
a
large
group
of
moderators
across
almost
every
time
zone
in
the
world
to
make
sure
that
we're
just
keeping
things
nice
and
clean.
A
A
This
project
was
initially
started
by
paris
pittman,
and
this
is
is
an
example
on
how
we
hand
projects
off
to
people
as
they
onboard
into
kubernetes,
and
tell
us
what
they're
interested
in
and
then
just
find
something
that
they're
passionate
about
and
then
just
take
it
over.
So
this
team
was
established
last
year,
they've
set
up
an
entire
communication
framework.
We've
got
a
new
twitter
account
that
will
just
have
information
and
use
specifically
for
contributors
to
allow
us
to
give
users
more
information
in
a
place.
A
That's
consistent,
so
they
can
find
out
what's
going
on
and
not
depend
on
slides
like
this
all
the
time
to
figure
out
what's
going
on
in
the
project,
there's
plenty
of
things
to
do
here
in
this
team
and
before
I
hand
it
off
to
bob
just
a
reminder,
a
lot
of
these
teams
that
you
see
the
people
that
are
volunteering
and
working
here.
You
do
not
need
to
be
a
developer
or
a
programmer.
B
Well,
it's
my
turn
to
take
over,
so
I
want
to
dive
right
into
our
documentation.
It
is
sort
of
a
living
set
of
documents
and
with
that,
it's
sort
of
like
is
broken
down
into
two
broad
areas.
The
contributor
guide.
This
is
something
everyone
should
be
familiar
with,
whether
you
are
helping
write,
documentation,
running
issue,
triage
sessions
or
more,
it's
sort
of
the
base
level
of
knowledge
to
be
effective
in
our
community.
B
Next
is
the
developer
guide.
This
focuses
more
specifically
on
developing
kubernetes
things
like
going
best
practices
how
to
write
tests,
api
best
practices
and
much
more.
This
is
currently
also
going
undergoing
a
significant
rework
with
the
help
of
joel
barker
and
eric
aronson,
two
tech
writers
that
are
helping
us
sort
of
with
our
information
architecture
and
sort
of
restructuring
documentation
to
be
much
more
helpful.
B
Sorry
on
both
of
these
things,
we're
always
also
looking
for
more
help
with
revising
them,
especially
new
contributors
who
can
approach
them
with
sort
of
the
beginner's
mind.
There's
always
details
that
we
as
more
experienced
computers
overlook,
and
these
little
things
will
help
many
others
going
forward.
Lastly,
we
have
our
contributor
site.
B
This
we
really
want
to
publish
soon,
hopefully,
by
the
time
this
is
actually
live,
the
site
will
be
live,
but
the
the
sort
of
the
idea
behind
it
is
that
the
our
documentation
in
github
is
not
very
discoverable
and
having
a
single
website.
You
could
go
to
for
things
like
the
contributor
guy,
the
developer
guide
or
calendar,
and
some
other
resources
would
be
extremely
valuable
and,
as
well
as
helping
with
our
general
information,
discoverability
problems.
B
The
next
project
or
sub
project
is
dev
stats.
As
george
mentioned
earlier,
this
is
sort
of
a
tool
to
help
visualize
our
github
activity.
B
So,
like
the
number
of
contributors
now
historically,
it
has
been
actually
super
useful
for
our
community
groups
like
our
sigs
and
working
groups,
but
one
of
our
contributors,
lori
apple,
has
been
spearheading
an
effort
to
build
some
better
dashboards
that
we
can
use,
especially
when
it
comes
to
trying
to
find
some
like
good
community
health
metrics,
and
if
sifting
through
data
is
your
thing,
this
might
be.
This
might
be
of
interest
and,
if
you're
interested,
please
feel
free
to
reach
out
in
slack.
B
Next
is
events.
Now
events
have
been
hit
hard.
This
year
we
regularly
host
three
contributors
contributor
summits
a
year
alongside
kubecon,
and
each
one
has
its
own
event:
team
sort
of
modeled
off
our
release
team.
With
their
shadow
program.
It's
been
one
of
our
more
success.
Successful
means
we've
had
for
onboarding
new
contributors.
B
B
We
might
wind
up
doing
a
virtual
event
for
kubecon
north
america
later
this
year,
but
it's
still
sort
of
to
be
determined
if
you
are
interested
in
that
sort
of
thing,
please
subscribe
to
the
kubernetes,
dev
mailing
list
and
all
communications
regarding
that
will
be
sent
to
that.
B
The
other
big
thing
that
our
events
team
handles
is
the
elections
for
our
steering
committee.
So
our
steering
committee
elections
happen
once
a
year
and
members
that
are
appointed
to
the
steering
committee
are
elected
for
a
two-year
term
and
these
sort
of
sort
of
set
the
policy
for
some
of
their
project
and
and
I'll
join,
steer
it.
And
then
we
as
contributor
experience,
are
sort
of
the
executors
of
the
of
the
policy.
B
The
next
project
is
sort
of
near
and
dear
to
my
heart,
and
that
is
github
management.
This
sub
project,
along
with
the
github
admin
team,
manage
how
contributors
interact
with
github,
along
with,
like
you
know,
becoming
an
org
member
as
well
as
like
creating
and
managing
repos,
and
some
of
the
more
recent
stuff
we've
been
working
on
has
been
sort
of
designing,
defining
the
the
member
life
cycle
policy.
B
So
the
project
is
now
six
years
old
and
people
are
not
expected
to
be
contributing
to
it
forever,
but
with
org
membership
becomes
an
elevated
set
of
permissions
and
being
able
to
use
our
ci
without
checks,
as
well
as
like,
potentially
sign
off
on
code.
So
we
need
to
think
about
like
off-boarding
as
well.
B
B
We
have
209
repos
and
with
this
project
being
you
know,
six
years
old,
there
are
some
that
were
like
sort
of
experiments
and
other
ideas
that
aren't
really
actively
being
maintained
on
anymore.
It
just
makes
sense
for
them
to
be
archived
and-
and
this
is
sort
of
like
it
seems
like
a
lot
of
janitorial
work,
but
it's
essential
to
the
project.
Nonetheless,
now
before
I
jump
right
into
our
next
sub
project
mentoring,
there
is
a
little
bit
of
a
prerequisite.
B
B
This
means
that
you'll
be
sort
of
the
first
line
of
defense
when
it
comes
to
reviewing
pr's
as
they're
coming
in
now
after
spending
some
time
as
a
reviewer,
you
become
a
bit
more
of
a
subject
matter
expert.
In
that
area
of
the
code
base,
you
reviewed
a
bunch
of
prs
and
you'll
get
promoted
to
an
approver,
which
means
you
can
actually
sign
off
and
allow
that
code
to
be
merged,
and
you
know,
let's
say
you
start
to
learn
more
about
other
areas
and
other
areas.
B
Under
the
sig,
you
may
become
a
higher
level
approver
for
like
an
entire
subproject,
so
you
might
graduate
then
to
like
sort
of
helping
set
goals
and
outline
the
milestones
for
the
entire
subproject
itself
and
potentially
eventually
become
a
sickly,
and
this
in
itself
is
is
this
whole
thing
is
referred
to
as
the
ladder
and
now
for
many,
the
first
big
hurdle
is
making
the
jump
from
a
non-member
to
member,
but
our
mentoring
initiatives
are
here
to
help
people
climb
the
ladder
itself
and
mentoring.
Mentorship
is
just
essential
to
overall
project
health.
B
I
was
just
talking
about
contributing
life
cycle
and
off-boarding,
but
mentoring
is
how
we
bring
on
new
contributors
and
help
our
current
contributors
grow
into
the
roles
and
become
sub-project
owners
in
future.
Sig
leads,
and
with
that
we
have
a
couple
different
programs.
The
first
is
meet
our
contributors.
It
is
a
one-hour
sort
of
ask
me
anything
with
a
panel
of
current
contributors.
The
audience
for
this
is
tends
to
be
like
50
50
split
between
both
new
and
current
contributors,
and
some
of
our
more
common
questions
include
like
how
do
I
get
started?
B
B
B
B
We
also
have
two
major
internship
programs
working
with
google
for
the
google
summer
of
code
and
the
outreachy
internship
program.
I
believe
both
are
done
for
the
remainder
of
the
year,
but
look
like
subscribe
to
the
curious
dev
mailing
list,
if
you're
interested
in
this
sort
of
thing
in
the
future.
B
Next
we
have
our
new
contributor
workshop.
This
has
its
own
slide
itself.
It
happens
to
be
one
of
our
largest
mentoring
programs
and
we
tend
we've.
We've
previously
held
it
alongside
contributor
summits,
and
it
actually
used
to
be
under
the
events
sub-project,
but
it
has
since
moved
out
and
moved
under
mentoring.
B
Earlier
this
year-
and
this
is
because
hosting
in
person
had
a
lot
of
difficulties,
there
are
a
lot
of
issues
with
hotel,
wi-fi
networking,
corporate
laptops
being
locked
down,
and
it
just
led
to
a
degraded
experience
and
so
moving
it
to
an
online
only
event
where
you
can
sort
of
make
your
own
curriculum
and
it's
sort
of
like
the
content
itself
sort
of
mirrors.
Our
contributor
guide,
while
diving,
deeper
into
areas
like
areas
like
local,
build
and
testing.
B
This
piecemeal
approach
means
that
if
you
like,
you've
already
got
go
in
your
go
environment
set
up,
you
can
skip
to
the
sections
that
are
more
relevant
to
you,
such
as
the
the
like
repo
tour
and,
if
you're
an
experienced
contributor,
preferably
with
good
or
a
good
recording
setup.
We'd
love
your
help,
tackling
some
of
these
sections
of
recording
a
a
a
good
presentation
for
it,
and
with
that
that
takes
us
to
slack
and
from
slack
infra.
You
know.
B
As
we
said,
we
have
a
slack
workspace
with
over
a
hundred
thousand
users,
and
maintaining
a
safe
space
for
them
can
can
pose
quite
a
challenge
and
we've
sort
of
had
to
build
our
own
tooling
to
help
manage
it
all.
Now,
slack
itself
is
not
really
designed
for
open
communities
and
it
sort
of
expects
you
to
be
able
to
go
to
your
hr
person.
B
If
you
have
an
issue
with
someone
that
doesn't
really
work
so
well
in
an
open
group
and
one
of
our
contributors,
catherine
berry
built
a
tooling
that
lets
us
manage
slack
through
git,
as
well
as
edits,
a
like
plugin.
So
we
now
have
a
the
function
to
be
like
report
messages,
and
these
things
will
sort
of
bubble
up
to
our
sac
admin
team
for
review.
B
We
also
have
some
upcoming
things
that
we
intend
to
work
on,
such
as
automating
postings
to
analysis
for
things
like
security
announcements,
as
well
as
being
able
to
delegate
moderation
capabilities
to
channel
owners.
This
is
because
there
are
a
lot
of
projects
that
are
hosted
within
the
kubernetes
slack
and
for
some
we'd
like
to
be
able
to
or
they'd
like
to
be
able
to
manage
their
own
community
before
potentially
asked
to
like
bubble
up
or
escalate
to
up
to
us
as
full
slack
admins.
B
Lastly,
this
is
not
a
sub
project,
but
something
that
is
very
important
to
us,
and
that
is
the
naming
working
group.
Sig
controbex
is
one
of
the
sponsors
for
this
new
working
group
and
sort
of
the
idea
behind
it
is
to
help
establish
a
set
of
inclusive
language
and
suggestions
on
how
we
can
up
update
different
parts
of
the
project.
B
When
this
is
scheduled
to
occur,
you
can
expect
quite
a
bit
of
like
comms,
going
out
to
the
kubernetes
mailing
list,
as
well
as
on
the
twitter
and
elsewhere.
A
So
how
can
you
contribute?
You've
heard
us
talk
about
how
people
are
onboarding
themselves
on
the
contributor
ladder
and
things
like
that.
So
no
matter
what
people
are
the
center
of
kubernetes
yeah.
We
do
make
some
software
that
people
love
and
love
to
use,
but
for
us
the
contributor
experience
is
really
what
we're
all
about.
So
for
us,
it's
about
our
mission
to
make
contributing
contributing
to
kubernetes
easier
and
ensure
that
we
have
a
diverse,
sustainable
contributor
base
that
will
keep
driving
the
project
forward
for
years
to
come.
A
A
So
in
the
beginning,
when
I
showed
you
that
list
of
sigs
it
feel
free
to
just
kind
of
browse
around,
we
have
links
to
all
of
their
archives
and
then
see
what
interests
you
most
cigs
have
reserved
time
for
new
people
to
introduce
themselves
during
the
meeting
and
co-chairs
and
experienced
members
of
the
kubernetes
community
are
almost
always
out
on
the
lookout
for
new
people
to
make
them
feel.
Welcome,
so
feel
free
to
join
a
meeting.
A
The
first
is
always
find
a
buddy
there's
a
saying
that
says
if
you
want
to
go
fast,
go
by
yourself
if
you
want
to
go
far,
go
as
a
group,
so
for
me
initially,
when
I
was
getting
started
in
the
community,
I
found
a
buddy
who
was
able
to
help
me
someone
that
was
at
my
same
level
and
we
kind
of
bounced
ideas
off
of
each
other
or
if
we
got
stuck
with
something
we
helped
each
other
out,
and
I
also
regularly
sought
out
someone
who
was
more
experienced.
Who
could
help
me
out?
A
As
I
was
learning,
you
can
either
find
this
among
co-workers
if
you
have
co-workers
that
have
worked
in
kubernetes
before
or
you
could
just
find
one
in
a
sig
meeting,
for
example,
volunteering
to
take
notes
is
a
very
good
way
to
learn.
What's
going
on
in
kubernetes
very
quickly,
usually
the
co-chairs
and
tech
leads
are
running.
A
So
because
taking
notes
forces
you
to
pay
attention,
you
can
attend
the
meeting
without
being
tempted
to
open
a
new
tab
and
go
do
something
else,
and
I
found
it
a
really
great
way
to
kind
of
get
yourself
up
to
speed
on
who's
who,
what
they're
working
on
and
what
what's
important
to
people
as
as
they
as
you
attend.
The
meeting
attending
regularly
is
also
pretty
important,
kubernetes
releases
four
times
a
year,
usually
so
attending
regularly.
A
If
you
miss
a
month's
worth
of
meanings
and
it's
a
weekly
meeting,
you
know
that
is
a
lot
of
velocity
that
you've
missed
out
on.
So
usually
I
try
to
attend
regularly,
especially
if
it's
something
that
you're
really
interested
in.
If
there
are
other
parts
of
the
project,
we're
only
you're
only
mildly
interested
in
you
could
just
attend
meetings
on
a
less
regular
basis
and
always
remember
that
small,
dependable
contributions
is
always
better
than
volunteering
for
the
world
and
not
being
able
to
accomplish
anything.
We've
all
been
there.
A
You've
you've
found
this
great
project
that
really
you're
into
you're,
starting
to
really
like
the
people.
You
you
see,
people
that
you
admire
doing
so
many
great
things
and
then
you're
going
to
want
to
go
to
every
sig
and
volunteer
for
everything
and
then
you're
going
to
find
yourself
in
a
ball
like
an
in
the
ball
of
anxiety,
wondering
why
you
volunteered
for
all
these
things
and
you
just
started,
and
now
you
have
no
idea
where
to
get
started,
so
you
can
start
contributing.
A
We
have
people
who
contribute
one
hour
a
month
and
have
done
so
consistently
for
years,
and
that
is
a
thing
that
you
can
always
kind
of
depend
on,
so
do
not
bite
off
more
than
you
can
chew.
No
one's
going
to
yell
at
you
for
not
volunteering
enough
you're,
the
one
doing
us
the
favor
so
do
find
something
that
is
easy
for
you.
A
While
you
figure
out
what
to
do
and
as
you
get
gain
experience
and
figure
out
and
start
to
meet
other
people
and
start
to
figure
out
where
you're
exactly
going
to
fit
in
the
machine,
then
at
that
point
you
can
decide
to
chew
on
some
stuff,
sig
should
have
a
list
of
good
first
issues.
This
is
a
github
label.
We
also
use
a
help
wanted
label.
So
you
cigs
have
hey.
Welcome
here's.
You
know.
Here's
a
list
of
good.
A
First
issues
feel
free
to
dive
in,
since
everyone
is
busy
all
the
time
and
the
project
is
so
busy.
Some
sigs
maintain
these
lists
better
than
others.
If
you
go
to
a
sig
and
they
don't
have
these
or
they
only
have
a
few
things.
That
is
also
a
great
place,
because
you
can
use
your
beginner's
mind
as
a
new
person
to
kind
of
help
us
figure
out
what
things
are
appropriate
for
new
people
and
what
things
aren't.
A
We
have
plenty
of
non-code
role,
opportunities
like
the
stream
team,
slack
administration,
but
there
are
many
many
things
in
contributor
experience
that
don't
require
elevated
permissions,
where
we
could
always
use
your
help.
So
please
don't
feel
that
you
need
to
know,
go
or
python
or
be
a
programmer
at
all.
We
have
a
large
group
of
people
who
come
from
program
management
backgrounds
and
myself,
who
are
not
an
engineer.
I
come
from
a
system
administrator
background,
so
together
with
all
of
these
skills
that
we
have,
that
is
how
the
sig
gets
things
done.
A
We
do
it
together,
as
opposed
to
trying
to
expect
everyone
to
learn
things
that
they're
not
proficient
in
and
with
that.
You
can
always
find
us
on
slump
with
these
handles,
and
these
are
also
github
handles
the
home
page
readme.
There
will
take
you
to
a
summary
that
has
the
links
of
just
about
everything.
I've
talked
about
here
links
to
our
sub
projects,
sub-projects
things
of
that
nature
and
then,
of
course,
our
trebek's
mailing
list,
which
has
the
asynchronous
forms
of
communication,
and
with
that,
thank
you
for
joining
us
bob.