►
Description
Want to view more sessions and keep the conversations going? Join us for KubeCon + CloudNativeCon North America in Seattle, December 11 - 13, 2018 (http://bit.ly/KCCNCNA18) or in Shanghai, November 14-15 (http://bit.ly/kccncchina18)
Growing in Your Contributor Role – Insights From a k8s Newcomer Working Within the Release Process - Tim Pepper, VMware (Beginner Skill Level)
New open source contributors often struggle to orient to a project’s processes and cadence, and kubernetes is no different in this regard. Approaching such a large and dynamic project can be daunting. While a relative newcomer to the kubernetes project, the speaker has twenty plus years of open source developer experience from which to draw on within the 1.10 release team as bug triage shadow and for 1.11 as the bug triage lead. Embedded service to the community within the release team, especially in a cross-SIG bug-focused role, provides a unique opportunity for contributor insights. This is not a 1.10 release retrospective (see pres. by Jaice Singer DuMars & Ihor Dvoretskyi), but the talk will walk through the release process, its phases, how the process is evolving through time and will use 1.10 specific examples to highlight areas ripe for new contributors to engage and grow.
About Tim
Tim is a software engineer with over 20 years open source development experience. He is currently a member of VMware's Open Source Technology Center acting as an open source developer advocate and contributing to upstream projects such as kubernetes. In his past he's worked on the linux kernel, device drivers, distributions, software update, Android, OpenStack, and an open source golang based orchestrator for multi-tenant containers and VMs that wasn't kubernetes.
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 21! 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.
A
If
this
is
the
talk
you're
expecting,
you
are
in
the
right
place,
growing
you're,
contributing
role
in
kubernetes
and
particularly
from
the
perspective
of
a
release
team
member
and
not
just
release
team
member
but
sort
of
a
newbie
release.
Team
member,
so
I'm,
a
kubernetes
newbie
I
only
really
got
involved
in
kubernetes
in
2017
I've
only
been
an
org
member
since
2018,
but
in
2018
I
joined
the
110
release
team
as
an
issue,
triage
shadow
and
then
for
the
current
release.
A
111
I'd
become
the
issue
triage
lead,
so,
while
I'm
a
newbie
on
kubernetes
I
am
also
an
experienced
software
engineer.
I've
been
doing
open
source
for
about
20
years.
I've
kind
of
made
my
career
in
it,
so
I
worked
in
I.
Currently,
work
in
VMware
is
open
source
program
office,
but
I
also
did
open
source
Linux
work.
A
So
people
say
I,
never
do
a
poll
in
a
presentation
but
I
move
out
here
where
I
can
actually
see
you
so
who's
new
to
kubernetes.
Here,
good
glad,
you
showed
up
welcome
whoo,
which
of
you
and
you
can
raise
your
own
multiple
times,
who's
looking
to
grow
and
your
your
contributor
role
in
kubernetes
nice
and
don't
touch
that
who's
new
to
software
development,
I
figured
so
yeah.
A
A
All
right
so
I
recently
became
an
org
member,
and
this
is
like
a
frequently
asked
question
in
the
community.
What
what
is
an
organ
umber?
What
does
it
mean?
And
it's
really
your
first
step
up
from
being
a
casual
or
new
contributor
and
technically
it
means
you're,
a
member
of
the
org
on
github
for
kubernetes,
and
with
this
comes
from
some
basic
abilities,
you
can
add
certain
labels.
A
Your
PRS
are
automatically
going
to
go
through
continuous
integration
testing,
but
with
it
also
comes
from
responsibilities
like
it
says
up
there
that
you
are
an
active
contributor
in
the
community.
That
said,
the
bar
for
membership
is
relatively
low.
Air
in
here
likes
to
say,
like
you,
just
need
to
be
showing
sustained
presence
and
activity.
So
it's
relatively
abstract.
It's
not
that
hard
to
do
you
shouldn't
be
too
hung
up
with
it.
A
If
you're
getting
involved
in
doing
stuff,
you're
probably
passed
the
bar
now,
the
the
other
three
levels
there
and
I
probably
should
have
inverted
this.
We
talked
about
this
being
the
contributor
ladder
and,
as
you
work
your
way
up
the
ladder
it's
down
in
the
graph,
but
beyond
being
a
member,
the
other
three
levels
really
start
to
come
into
ownership
and
you're
taking
ownership
over
areas
of
code.
A
What
we
really
want
an
open
source
is
to
avoid
the
tragedy
of
the
Commons,
the
idea
that
we
have
something
shared
code
or
aspects
of
the
project
that
nobody
owns
nobody's
responsible
for
and
that
they
sort
of
die
off
over
time.
So
the
the
ladder
is
kind
of
about
helping
to
ensure
that
we
we
have
clear
ownership
on
things
for
those
reasons,
so
new
contributors,
new
developers,
obviously
think
about
becoming
members,
is
you're
trying
to
advance
through
your
your
membership
and
kubernetes.
A
A
This
is
kind
of
normal,
agile
software
development,
open
source
stuffs,
moving
pretty
fast
a
three
month
cycle.
Maybe
some
things
are
a
little
slower.
Other
things
are
faster,
but
that's
kind
of
the
cycle.
You've
got
some
feature.
Definition
that
happens,
feature
work,
bug
fixing
and
the
release,
but
the
reality
is
that,
like
feature,
work
is
actually
happening.
All
the
time
bug
work
is
happening
all
the
time,
so
these
things
become
a
little
more
fuzzy.
Now
multiple
talks
today
and
also
yesterday
at
the
contributors
submit
if
you're
there
mention
the
release
team
as
an
entry
path.
A
A
So
this
presents
an
opportunity,
if
you're
a
newcomer,
looking
to
advance
to
maybe
step
into
some
of
those
areas,
and
there
are
a
few
here
that
I've
kind
of
highlighted
as
what
areas
that
I
think
of
ones
is
maybe
a
little
easier
than
others
to
get
a
net
gauge,
depending
on
your
experience
level
and
then,
especially
if
you're,
just
a
new
developer
testing
is
a
way.
I
feel
I
find
useful
to
approach
code.
If
I
see
a
test,
that's
failing
well,
I
can
go
read
the
test
case.
A
I
can
go,
read
the
code
associated
to
it
and
it
sort
of
becomes
an
entry
path
to
you.
Understanding
now,
I
may
not
be
the
person
who
ultimately
understands
and
fixes
the
bug,
but
it's
an
entry
path
for
me
now
great
if
I
actually
find
and
solve
it
cool,
but
it's
something
that
you
can
use
as
an
entry
way.
But
I
also
think
about
this
as
sort
of
it's
not
just
a
release
process,
but
it's
a
volunteer
process.
A
Any
of
you
could
get
involved
and
use
it
as
a
way
to
take
a
next
step,
and
that's
because
it's
happening
all
the
time.
This
isn't
just
a
static
thing
that
happens
during
three
months.
It's
happening
four
times
a
year
and
then
beyond
that
also
we
have
stable
patch
releases
four
prior
releases
and
those
prior
releases
get
support
for
a
number
of
subsequent
releases,
so
each
one
of
these
might
actually
be
a
12
month
continuum
and
for
the
folks
who
are
looking
to
advance
in
particular,
who
already
have
some
level
of
experience.
A
A
Can
we
decouple
there
and
if
that's
the
case
and
you're
thinking
well,
I
could
never
do
that
because
I'm
not
a
Google
employee,
maybe
if
you've
kind
of
grown
in
the
community
over
the
next
year.
By
that
point,
this
might
be
decoupled
and
it
could
be
your
place
to
engage
for
your
next
leveling
up
so
issue.
Triage
er
I
mentioned
that
that
was
the
role
that
I
have
and
every
presentation
needs
kittens.
So
here
my
kittens
and
bonus
points,
particularly
if
you
look
at
the
cats,
some
of
them
are
kind
of
grumpy.
A
Some
of
them
are
groggy.
Some
are
a
little
more
active.
Some
maybe
seem
happy
like
software
engineers.
That's
us
on
any
given
day
and
is
issued
triage
er,
you
sort
of
become
a
cat
herder.
You
have
to
understand
what
all
these
developers
are
going
through
and
doing
and
and
figure
out
how
to
get
resolution
on
something.
So
the
inner
treasure
is
mostly
pulling
bugs
and
checking
status
on
development
activities.
To
do
that.
A
We're
interacting
with
other
contributors,
especially
with
cig,
leads
we're
sending
them
reminders
on
things
that
are
going
on
or
having
to
reach
out
and
ask
questions
and
then
publishing
summary
reports
on
that
stuff,
if
you're
a
particularly
experienced
developer
or
something
that
you
might
bring
to
a
role
like
this
is
just
the
gut
level
intuition,
like
you,
see
something,
that's
a
problem
and
Jase
who
is
sitting
down
here.
The
the
lead
of
the
last
release.
A
I
think
he
did
a
good
job
of
kind
of
reaching
out
and
leveraging
the
whole
team
to
say
like
okay,
are
we
worried
about
this
and
if
you
bring
a
certain
level
of
engineering
experience
already,
that's
something
that
you
could
especially
add
to
the
conversation.
I
think
not
that
you
couldn't
also
be
a
completely
new
contributor
in
some
of
these
roles,
so
the
issue
treasurer
does
not
do
the
actual
work
like
we're
kind
of
the
the
cat.
Herder,
the
cats
or
the
cats
are
doing
their
things.
A
So
what
this
means
is
we're
doing
a
lot
of
reading
of
issues
in
github
of
email
discussions,
slack
conversations
things
like
that,
but
we're
not
actually
typically
looking
at
code
very
much
so
then.
What
are
we
looking
at
those
things
that
I
just
Misha
mentioned
for
the
most
part
slack
Google
Groups,
but
also
within
that
we
might
have
to
be
looking
at
test
results
and
attending
SiC
meetings.
A
So,
having
talked
about
issue
triage,
it's
important
to
think
about.
Well,
what
is
an
issue,
so
an
issue
is
obviously
a
github
thing,
but
it's
really
just
a
bucket
any
source
code
management
system
or
project
management
system
has
some
bucket
like
this
and
it
gets
its
meaning
through
the
way
the
project
uses
it.
So
on
github
you,
you
see
this
thing.
This
is
2,000
issues
or
5,000
issues
for
for
kubernetes,
but
there's
kind
of
a
first
pass.
A
Splitting
you've
got
things
that
have
a
label
that
indicate
they're
a
bug
or
a
feature,
and
as
the
issue
treasurer,
this
would
make
life
really
easy.
If
that's
what
it
was
because
there's
somebody
whose
job
is
focused
on
features
issue
triage
time
focus
on
bugs
the
reality
is
that
we
have
a
whole
bunch
of
kinds
of
issues
and
it's
really
kind
of
then
a
label
soup.
A
Earlier
today,
Aaron
mentioned
that
after
some
cleaning
and
consolidating
we're
down
to
something
like
a
hundred
and
seventy
labels
and
down
from
like
two
hundred
and
twenty,
so
this
becomes
very
complicated
to
track
and
understand.
But
within
that
again
is
some
opportunity.
We're
we're
having
discussions
I'm,
also
active
in
the
contributor
experience
sig
we're
having
discussions
around.
How
do
we?
How
do
we
make
it
more?
A
Inviting
for
all
of
you
who
are
new
and
part
of
that
is
the
principle
of
least
surprise
if
things
are
surprising
and
confusing,
that's
bad
for
the
contributor
experience,
but
some
of
us
who've
been
around
even
myself
even
just
a
year
or
so
having
gotten
used
to
these
things.
We
take
them
for
granted.
So
as
newcomers
raise
your
hand
and
speak
up
and
say
like
this
is
confusing
and
your
opinion
is
valuable
and
we
would
value
it
and
would
love
to
hear
your
perspective
on
these
and
not
just
on
labels.
A
A
So
if
you
are
a
member
like
if
you've,
if
you're
completely
new
and
you've
worked
your
way
up
to
membership,
there's
a
couple
of
actions
that
you
can
do
just
around
checking:
label
status
on
new
issues,
that's
a
very
valuable
type
of
chopping,
wood
and
carrying
water
that
we
we
look
for
people
to
do
so.
You
might
say
an
issue
that
clearly
has
wrong
labels,
fixable
or,
if
you're,
not
sure,
reach
out
to
the
cig.
That
seems
appropriate
for
it
and
say:
hey.
A
Is
this
right
or
if
there's
already
an
owner
on
the
issue
say:
hey
are
these
these
labels
right?
Could
they
could
have
good
things
be
more
clear
and
then
the
needs
okay
to
test
label
is
something
that's
always
useful
for
people
to
add.
If
it's
a
support,
question
helping
people
find
the
right
support
path
by
labeling
at
a
support
ticket
or
quite
commonly
things.
Don't
yet
have
a
cig,
we're
getting
automation,
that's
helping
with
that
I
think
in
the
future.
But
in
the
meantime,
helping
point
things
to
the
right.
A
Places
means
that
humans
start
seeing
them
sooner,
and
these
are
all
valuable
in
relatively
simple,
simple
tasks
that
you
can
perform
so
I'm
starting
to
get
old.
You
might
not
be
able
to
see
my
gray
hair
up
here.
I've
got
kids
in
college
now,
and
sometimes
you
have
to
have
the
talk
weird
where
do
is
come
from
and
we're
in
Copenhagen.
A
So
we
have
to
have
to
reference
Hans,
Christian,
Andersen
here
and
issues
mostly
come
from
humans,
believe
it
or
not
so
of
the
two
main
types
bugs
mostly
getting
filed
by
humans
at
the
basic
level,
and
these
can
be
people
inside
and
outside
of
kubernetes,
and
especially
if
they're
outside
of
kubernetes
they're
less
likely
to
send
the
labels.
So
it
becomes
an
opportunity
for
doing
issue,
triage
and
understanding
and
what's
going
on
and
getting
it
directed
to
the
right
place.
A
Features
may
be
a
little
less
so
because
they're
going
to
be
generated
mostly
by
humans
inside
the
project
and
SIG's,
but
sometimes
they
come
from
outside
as
well,
but
then
test
failures.
These
are
really
going
to
be
coming
as
a
result
of
test
automation
and
briefly
before
I.
Go
into
testing.
I
want
to
mention
that
a
lot
of
projects
in
open
source,
if
you
you've
seen
other
open
source
things,
you
might
have
a
requirement
to
do
a
pull
request
that
you
have
an
issue
first
and
that
the
the
pull
request
is
fixing
the
issue.
A
It
kind
of
makes
sense.
But
this
also
leads
to
a
sort
of
a
bureaucratic
overhead
and
a
lot
of
times.
Then
it
just
kind
of
gets
punted
away
and
in
kubernetes
we've
done
that
now
just
to
streamline
things,
but
is
it
issue
triage
er
I
have
to
figure
out
those
mappings
if
they
aren't
they're
explicitly
a
PR
may
not
be
connected
to
an
issue,
so
I'm
constantly
hunting
around
to
find
the
issues
that
are
associated
with
it.
So
on
testing
we
have
a
thing
called
test
grid
and
it's
this
big
matrix
on.
A
If
you
go
to
that
role,
you'll
see
it.
Each
of
these
is
a
little
tile
that
you
can
click
on
and
tracking.
What's
going
on
within
these,
when
you
click
on
it,
you
see
a
whole
bunch
of
test
results
and
failures
are
generally
highlighted.
That's
a
massive
job,
and,
thankfully
is
the
issue
treasurer.
It's
not
my
job.
A
There
is
on
the
release
team
somebody
who's
dedicated
to
understanding
the
signal
coming
out
of
the
continuous
integration,
but
it
also
still
becomes
sort
of
a
side
job
for
me,
because
I
do
need
to
have
some
breadth
of
understanding
there.
If,
if
I'm
needing
to
help
peeing
a
cig,
lead
or
figure
out
what
what
the
hang-up
is
on
some
particular
issue
or
we're
getting
down
to
crunch
time
and
everybody
on
the
release
team
is
watching
test
status.
Trying
to
understand.
A
Are
we
getting
better
and
I
mentioned
that,
because
I
think
that
that
is
something
that
newcomers
can
do
as
well
and
like
I
mentioned
earlier,
where
I
see
tests
and
test
cases
as
a
pathway
to
understanding
their
associated
functional
code
at
any
level
across
the
experience
spectrum,
that's
something
that
you
can
do.
There's
three
main
types
of
tests
and
kubernetes
unit
integration
and
end-to-end
in
that
order
they
get
more
complex
unit
tests
are
something
that
you
can
do
just
effectively
a
simple
go
test
and
it's
isolated.
The
code
is
right
there
in
a
particular
directory.
A
You
can
run
the
test
of
one
particular
piece
of
go
code
and-
and
you
can
play
around
and
understand,
what's
going
on,
you
could
break
the
test.
You
could
change
the
test.
Does
it
still
pass?
So
that's
a
good
I
find
way
to
get
into
something
new.
The
integration
tests
require
other
components.
You
can
still
run
them
locally
on
your
machine,
but
might
start
getting
a
little
more
complex
and
then
the
end
to
it.
Those
are
things
that
are
running
in
clusters,
so
they
start
becoming
more
complex.
A
We
actually
have
a
pretty
smoothly
running
pipeline
because
of
the
tricks,
but
what
this
means
is
that
maybe
there's
some
Crofton
test
cases,
maybe
there's
some
complex
test
cases,
cases
brittle
test
cases,
especially
the
skilled
engineer
in
the
room
who's
getting
involved
in
kubernetes.
This
is
a
great
place
that
you
might
be
able
to
engage
and
contribute
something
so
that
test
grid.
It
looks
a
lot
like
the
cig
list
grid
and
is
issued
triage
er
I
need
to
have
a
broad
overview
of
what
SIG's
are,
what
who's
doing.
What.
A
We
had
a
an
odd
scalability
performance
problem,
but
was
it
the
scaling
teams
problem,
a
problem
with
tests
or
the
infrastructure
that
ran
the
test,
hit
some
piece
of
code
merged
from
any
of
the
SIG's
that
broke
so
being
able
to
broadly
understand
who's
responsible
for
what
and
reach
out
and
and
query
them
on
things
is,
is
really
useful
in
the
release
team,
but
also
again
anywhere
in
the
spectrum
of
being
a
newcomer
to
weather
engineering
or
kubernetes.
This
could
be
an
entry
point
for
you.
A
If
you
don't
know
much
about
kubernetes
or
you've
only
started
dabbling
in
one
point
but
you're
wanting
to
spread
out.
If
you
attend
a
sig
release
meeting
series
for
a
while,
you
might
see
how
we
do
the
whittling
down
and
reach
out
and
understand
different
SIG's,
and
you
might
learn
more
about
SIG's
like
that.
So
how
do
you
learn
about
SIG's?
One
thing
that
I
would
suggest
for
newcomers
right
now,
especially
is
charter
documents.
A
Each
of
the
SIG's
right
now
is
working
on
a
charter
and
within
that
they're
defining
their
roles
and
responsibilities,
so
is
issue
triage
were
on
the
relief
team.
We
need
to
figure
out
like
who's
responsible
for
what
and
and
that's
why
I
have
an
interest
in
seeing
these
get
more
defined,
but
there's
a
newcomer
like
seeing
the
roles
and
responsibilities
documented.
It's
your
opportunity
to
say,
like
hey,
could
I
take
on
leading
that
role
or
could
I
shadow
that
role
now.
A
All
of
those
SIG's
can
mean
meetings,
meetings,
meetings
and
meetings
have
a
bad
rep.
This
slides
been
around
since
forever,
like
I,
think
I
first
thought
mini
a
graft
and
somebody's
cubicle
before
like
each
of
us
at
work
had
our
own
computer.
So
this
has
been
around
forever.
Like.
Are
you
lonely,
tired
of
working
on
your
own?
Do
you
hate
making
decisions
hold
a
meeting?
See
people
feel
important,
eat
doughnuts
all
on
company
time,
but
don't
hate
on
meetings.
A
Cuz,
like
meetings
is
how
kubernetes
is
made
and
yes,
the
the
volume
of
all
the
different
meetings.
It
can
be
daunting,
but
it's
approachable.
So
the
link
at
the
top
of
the
page
here
is
like
I
think
for
me
on
the
release
team,
but
also
just
sort
of
in
general
in
kubernetes.
If
there
is
one
link,
you
could
remember,
that's
the
one
is
a
jumping
point
to
information
on
kind
of
everything.
I
feel
like.
A
A
Now
that
community
meeting
is
kind
of
the
place
to
go
to
get
an
overall
orientation
to
things
that
are
happening
in
an
ongoing
basis,
but
if
you're
new,
it
could
be
your
initial
engagement
point
also
because
every
meeting
there
are
a
couple
of
SIG's
talking
about
what
they're
up
to
and
the
SIG's
then
cycle
through
every
quarter.
So
if
you
attend
this
meeting
on
an
ongoing
basis
across
the
year,
you're
really
going
to
start
to
get
an
organic
since
built
up
of
what
all
of
the
SIG's
are
doing.
What
they're
up
to
where
they're
going.
A
If
you
attend
the
release
meetings,
I
think
you
get
some
of
that
as
well,
and
would
love
for
people
to
participate
in
the
release
meetings.
The
steering
committee
records
their
meetings
and
publishes
them.
It
can
be
a
great
way
to
get
some
insight
into
the
thinking
of
some
of
these
senior
established
people
in
the
overall
project.
Thinking
similar
for
a
cig
architecture
and
then
obviously,
each
cig
and
work
group
has
its
own
meetings.
A
You
know,
as
a
newcomer,
so
I
mentioned,
that
the
the
community
meeting
has
that
agenda
they're
on
a
Google
Doc
most
of
the
SIG's
have
that
type
of
thing
and
there's
a
newcomer.
You
can
either
go
and
just
type
in
something
you'd
like
to
propose
for
the
agenda
or
put
the
Google
Doc
in
suggesting
mode
and
suggest
something
for
the
agenda.
I
really
encourage
you
to
do
that.
A
If
you
have
a
question,
ask
it
that
can
be
intimidating
to
find
your
voice
and
try
that,
but,
like
speaking
from
experience,
the
sig
release
team
or
the
release
team
being
involved
in
sig
release
made
me
go.
Do
that
and
it
was
intimidating
at
first
to
show
up
in
a
random
cig
and
put
something
on
the
agenda
and
be
saying:
hey.
You
guys
have
something
broken.
A
We
need
to
figure
out
what's
wrong
here,
like
it's,
not
just
showing
up
and
saying,
like
I,
have
a
question
I'd
like
contruct,
to
contribute
to
helping
you
guys
and
positive,
like
no
I'm
showing
up
potentially
the
the
bad
guy
even
but
every
cig
was
welcoming
and
inviting
and
I
really
encourage
you
to
use
sort
of
that
newbie
card
that
you
have
to
even
ask
questions.
Say:
hey
I'm,
curious
about
the
the
design
of
this
particular
component.
A
A
A
Kubernetes
started
with
just
a
couple
people
and
it
started
growing
beyond
that
and
got
bigger
and
bigger,
and
we
start
getting
more
and
more
newcomers
and
then
suddenly
like
this
is
the
set
of
people
who
said
they're
gonna
come
to
this
talk,
like
things
start
to
snowball,
and
this
is
awesome.
This
is
how
things
work
you
you
get
senior
members
mentoring
newcomers
because
they
realize
that
they
need
to
spread
their
load.
A
They
need
a
sustainable
community
and
a
need
to
avoid
burnout,
and
they
need
to
do
succession
planning
that
over
time,
maybe
they're
gonna
move
on
to
something
else.
They
need
to
have
you
all
built
up
and
ready
to
to
take
their
place
so
any
level
you
have
an
opportunity
to
grow
and
be
the
next
generation
of
people
on
this
project.
A
If
so,
I'm
guessing
some
of
you
might
have
been
here
in
the
last
presentation
that
was
done
by
Parris
Pittman,
but
if
not
check
it
out
when
the
videos
are
online,
she
goes
into
a
whole
lot
more
detail
on
these,
but
I'm.
Just
briefly
mentioning
the
the
formal
bits
of
mentoring
that
are
going
on
so
once
a
month,
there's
a
meet
our
contributors
where
you
can
post
messages
on
slack
and
Twitter
and
get
live
responses
via
zoom
from
people
who
are
fielding.
A
Those
questions
there
are
group
mentoring,
cohorts
that
are
aimed
at
say,
bringing
on
a
set
of
new
contributors
or
bringing
some
existing
contributors
up
to
membership
or
membership
up
to
reviewer
and
and
building
building
the
community.
In
that
regard,
the
one-on-one
hour
is
a
way
where
you
could
reach
out
and
get
somebody's
time
committed
for
an
hour
to
go
over
a
specific
thing
that
you're
curious
about
knowing
more
about
and
then
Google
Summer
of
Code
and
outreach
e.
A
Those
are
obviously
much
more
formal
programs,
but
if
they're
applicable
to
you
and
you're
interested
in
maybe
using
that
as
an
entry
point
by
all
means,
go
for
it.
So
with
that
I
hope
you
guys
kind
of
go
out
there
get
active,
get
doing
things,
try
to
grow
and
go
to
great
things
in
kubernetes
pick
some
SIG's
to
focus
on.
Maybe
maybe
a
couple
really
start
attending
their
meetings
following
what
they
do,
look
at
their
issues
and
pr's,
and
what
you
can
learn.
A
Look
at
the
types
of
code
reviews
that
people
do
on
those
and
and
and
learn
from
them
and
as
you
learn
the
code
and
test
cases,
you'll
start
to
understand
the
designs
and
weaknesses
you
can
start
to
contribute
to
the
issue:
backlog,
look
for
Help,
Wanted
or
good
first
issues
and
and
really
find
your
voice.
This
is
a
very
welcoming
community.
A
Ask
questions
write
down
the
answers
and
then
start
teaching
others,
because
there's
going
to
be
others
following
you
and
if
you're,
if
you're
in
a
cig,
meeting
or
other
places,
raise
your
hand
and
ask
for
mentoring.
If
it's
something
that's
just
beyond
your
ability
to
challenge
yourself,
stretch
yourself
and
then
take
that
and
and
try
to
lead
yourself
and
teach
others.
A
So
that
was
that
was
it
for
the
talk,
a
few
shout
outs
and
thank
you.
Some
people
who
have
contributed,
especially
the
contributor
experience
and
sig
release
team
and
then
a
number
of
individuals
there
and
Noah
Abrams
and
the
audience
here.
He
did
awesome
blog
post,
that's
linked
there
describing
his
journey
through
this,
as
well
as
a
total
newcomer
right.
So
the
slides
are
online.
If
you
want
to
reference
anything
I
know
I
kind
of
flew
through
them
fast,
there's
a
variety
of
links
and
things
there,
but
they're
already
online
and
ready
for
you.
A
Questions
so
release
team
starts
out
early
in
the
process
meeting
once
a
week,
so
you're,
if
you're
a
shadow
and
you're
just
learning
about
a
role.
You
might
literally
only
have
that
once
a
week
hour
and
then
later
in
the
cycle,
it
becomes
three
times
a
week
and
then
every
day,
Monday
through
Friday
right
at
the
end.
So
our
hour-long
meetings
and
then
early
on
the
meetings
are
often
shorter
than
that.
A
A
Spiff
XP
or
errand
quicken
burger.
He
will
sponsor
you
to
some
extent.
It's
gonna
depend
on
the
SIG's,
so
some
SIG's
leads
are
looking
for
more,
but
I.
Think
your
initial
question
yeah.
If
you're
just
going
for
membership,
looking
around
people
who've
been
involved
and
understand
your
work.
Those
are
the
people
who
understand
what
you
you
are
bringing
to
the
table
and
they're
the
ones
who
are
gonna
vouch
for
you
and
ideally
the
bars
is
relatively
low.
B
Just
want
to
tack
on
to
that
real
quick,
like
you
used
to
have
direct
you
used
to
need
direct
right
access
to
the
repo
in
order
to
do
anything
meaningful
and
we've
worked
really
hard
today,
so
that
you,
you
just
need
to
be
a
member.
That's
why
I'm
super
enthusiastic
to
like
vouch
for
anybody
who
wants
to
become
a
member
there
used
to
be
a
bar
of
like
you,
have
to
have
five
pr's,
and
somebody
has
to
the
vouch
for
it
and
stuff.
B
A
Would
also
add
one
other
aspect
on
say
you
reach
out
to
those
people,
and
this
is
this-
is
part
of
like
just
finding
your
voice,
it's
okay,
to
ask
the
worst
thing.
That's
gonna
happen
is
they're.
Gonna
say
you
know,
I
I'll,
sponsor
you
when
you've
done
X,
Y,
&
Z,
and
now
you
have
your
to-do
list
now.