►
From YouTube: The Release Team Shadow Program - Mentoring For the Future - Guinevere Saenger & Lachlan Evenson
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
The Release Team Shadow Program - Mentoring For the Future - Guinevere Saenger, GitHub & Lachlan Evenson, Microsoft
Each Kubernetes release is guided by a team of specialist community members to shepherd the process and to culminate in a new release of the world’s most popular container orchestration tool. After Release Day, the team members update some docs, and then disband to re-focus their efforts elsewhere in the project, giving room to others to fill their former roles. But have you ever wondered how the Kubernetes Release Team gets formed in the first place? Come to this talk to find out how YOU could be part of a future Kubernetes Release Team! This talk will discuss the purpose and implementation of the Kubernetes Release Team Shadow Program, give examples of success and areas of growth, and may help you decide if this is an area where you would like to start your journey as a Kubernetes contributor.
https://sched.co/Uahk
A
Yeah,
so
we're
just
going
to
share
a
little
bit
about
our
experience,
leading
and
running
and
being
involved
in
the
release
team
shadow
program,
we're
going
to
talk
about
what
it
is,
how
it
works
and
why
we
do
it
first
off
who
we
are.
My
name
is
Guinevere
Sanger
I'm,
a
software
engineer
at
github.
I
became
involved
with
a
communities
project
about
two
years
ago
and
I
like
being
silly
at
work
on
the
internet
and
on
stage
and.
B
My
name
is
Lachlan
Evensen
I'm
going
to
be
trying
to
live,
draw
things
so
honk,
pre-prepared
honk
for
those
who
you
don't
know,
go
to
honk
what
is
it
honk,
zi
hog,
dot,
CI
and
check
it
out
for
yourself
my
name
is
Lachlan
Evensen
I
work
at
Microsoft
Azure
and
during
my
time
in
the
kubernetes
community,
I've
served
as
the
1/16
release
lead.
So
you
can
either
thank
me
or
give
me
some
nice
feedback
afterwards
for
that
a
CNC
F
ambassador
and
I'm.
C
B
But
there's
not
13
stripes,
so
you
know,
don't
don't
look
too
close.
I
could
have
it
revoked
but
yeah,
so
we're
both
been
in
the
release,
lead
position.
So
we're
sharing
our
experience
and
we're
very
excited
to
see
how
we
can
make
mentoring
programs
attractable
to
the
wider
audience
too.
So
we're
going
to
share
our
successes
in
that
and
what's
been
good
and
what's
been
bad
and
how
you
can
help.
A
Hi
everyone
I
am
the
kubernetes
release
team
lead
I
have
so
much
work
to
do
my
weekends
are
being
eaten.
My
boss
is
mad
at
me
because
I'm
falling
behind
at
work,
there
is
so
much
to
do
and
I
don't
even
know
what
I'm
gonna
do.
Next
it
turns
out
being
in
charge
of
a
kubernetes
release.
Is
a
lot
of
work
you
have
to
you
know
you
have
to
manage
all
the
features.
I
have
to
make
sure
that
all
the
bugs
get
found
and
fixed
before
the
date
I
have
to
manage.
A
The
community
I
have
to
talk
to
all
the
community
groups.
Hey
which
changes.
Do
you
want
to
put
into
your
release?
Please
keep
us
updated
and
please
keep
us
posted.
There
is
a
schedule.
I
have
to
schedule.
Meetings
using
scheduling.
Software
is
actually
really
hard.
I
didn't
know
that
I
need
to
make
sure
everything
has
a
priority.
I
need
to
make
sure
everything
is
somehow
juggled
people
make
the
meetings,
people,
don't
you
know,
people
don't
lose
track
and
we
don't
break
security
and
it's
it's
I.
B
So
it
turns
out,
you
have
a
lot
to
do.
I
think
I
might
be
able
to
help
you
with
that
I'm
new
here.
My
name
is
lucky:
I
have
a
lot
of
time
and
a
lot
of
energy.
Is
there
anything
any
way
that
you
can
help
me
contribute
to
kubernetes,
because
it's
a
big
project,
it's
super
hard
to
get
into
and
I
do
not
want
to
be
turned
away,
because
I
want
to
use
all
my
free
weekends
to
help.
A
B
B
A
A
B
B
A
C
A
A
One
of
the
roles
is
in
charge
of
kubernetes
enhancements.
That
is
the
person
that
Shepherds
all
the
new
features
and
all
the
cleanup
issues
and
all
the
all
the
new
changes
that
go
into
the
release,
but
we
also
need
to
have
people
that
make
sure
that
our
tests
pass.
So
that's
what
CI
signal
dies,
bug
triage
makes
sure
that
we
don't
accidentally
introduce
any
horrible
things
that
break
everyone's
stuff.
We
need
docs
for
all
this.
A
We
need
to
let
people
know
what
changed
from
release
to
release
and
we
also
like
to
need
to
let
people
know
that
hey
there's
a
new
kubernetes
release
out
there.
So
all
these
roles
have
slightly
different
things
to
do
and
depending
on
who,
you
are
what
you
know
and
what
you
want
to
learn.
You
might
be
interested
in
one
or
the
other.
We
don't
ask
that
you
know
everything
for
that
role,
but
you
must
be
interested
in
it.
So.
B
B
A
B
A
A
So
glad
you
asked,
we
have
an
application
form.
It
usually
goes
up
in
the
first
few
weeks
of
the
release
and
you're
going
to
fill
out
a
Google
Form
and
a
couple
things
we
want
to
know
about
you,
for
example,
you
know:
what's
your
experience
level,
what
are
you
interested
in
learning?
Are
you
a
kubernetes
Org
members?
Are
you
involved
in
a
kubernetes
sig?
Where
do
you
live?
Why.
A
Not
a
joke.
Actually,
it
turns
out
that
if
we
have
representation
on
the
release
team
across
multiple
time
zones
in
the
world,
that
that
is
a
really
really
good
thing,
kubernetes
is
a
huge
project.
We
have
maintain
errs
everywhere.
It's
it
turns
out.
It's
really
useful
to
have
people
that
are
awake
when
you
are
asleep.
Ok,.
B
A
A
A
A
A
A
So
this
process
is
actually
working
really
really
well.
I
think
there's
a
few
key
things
that
make
it
work
that
make
it
work
for
us
so
number
one.
We
have
a
really
low
barrier
to
entry.
If
you
become
a
shadow
on
the
release
team,
you
almost
immediately
become
a
kubernetes
org
member.
We
can't
have
you
not
be
a
member
and
running
around
organizing
enhancements
and
bugs.
We
also
have
a
handbook
when
you
are
on
the
release
team.
As
a
shadow,
your
lead
will
be
your
mentor
for
three
months.
You
will
have
a
mentor.
A
A
A
A
B
A
A
A
A
Not
all
having
the
shadow
program
obviously
allows
us
to
grow
a
community.
We
can
continuously
pass
along
the
torch
and
the
responsibilities
and
improve
upon
our
processes.
Every
shadow
has
new
questions
and
says,
but
the
handbook
doesn't
say
that
and
because
we're
an
open
source,
what
do
we
tell
the
shadows?
Go.
B
B
Absolutely
I
really
appreciate
the
fact
that
I
can
contribute
as
a
shadow
and
help
take
some
time
and
pressure
and
that's
really
meaningful
in
the
community
to
folks,
like
yourself
or
under
immense
pressure,
and
we
want
to
make
sure
that
we
preserve.
You
know
you
and
the
community
not
burn
you
out.
Yeah.
A
B
A
So
this
program
has
been
so
successful
that
the
numbers
speak
for
themselves.
For
the
current
release
that
I'm
leading
117
we
have.
We
had
76
applicants
to
be
a
shadow
on
the
release
team.
We
could
only.
We
can
only
fill
18
to
24
shadow
spots,
so
it's
been
a
huge
success.
People
are
asking
to
be
on
the
team
and
there
is
many
more
people
that
asked
to
be
on
it
then
can
have
and
it
didn't
used
to
be
that
way
a
year
or
so
ago.
A
B
A
A
B
B
Totally
so
we
need
you
to
apply,
we
need
this
process,
we
need
people
to
show
up
and
actually
help
the
shadow
applicants
go
up
to
cig
release
for
the
first
week
or
so
in
the
beginning.
So
the
next
release
starts
around
January
and
we
need
folks
to
come
in
and
help
participate,
so
keep
an
eye
out
for
those
application
processes
so
that
you
can
state
your
interest
and
be
part
of
the
selection
process.
B
So
we
really
want
to
have
this
process
not
even
only
adopted
in
the
release
team
itself
as
part
of
the
three-month
cycle,
but
we
think
that
there's
something
fundamentally
different
about
the
way
that
we're
mentoring
in
the
release
team
right
now
that
the
whole
community
could
stand
to
benefit
from,
and
this
speaks
to
just
nascent.
How
do
we
go
to
SIG's,
where
we
have
a
small
number
of
chairs
and
a
large
amount
of
responsibility?
B
Know
I
think
there
are
other
roles
that
weren't
even
there
and
you
don't
have
to
have
a
stated
role
to
contribute
to
the
release
team
as
well.
There
are
there's
a
wealth
of
information
and
process
that
we
all
need
to
partake
in
to
make
sure
that
a
release
goes
out
if
you've
never
part
taken
in
this.
It's
a
really
good
opportunity
to
see
the
soup-to-nuts.
How
we
put
together
a
kubernetes
release
in
a
very
short
span
of
time
meet
a
lot
of
people
from
the
community
because
you're
also
communicating
with
them.
B
A
And
Zig
release
is
not
the
only
sig
with
onboarding
programs
like
this
I
hear
sig
Docs
has
a
very
nice
onboarding
tract
as
well.
If
you
are
not
on
the
release
team,
there
is
release
engineering
that
also
mentors
and
on
boards,
people
just
like
this.
So
we
encourage
you
to
look
for
those
get
involved
and
become
members
of
the
community.
B
D
C
D
B
So
there's
a
lot
of
just
gathering
in
the
early
stages
is
what
are
the
seeks
working
on
and
in
the
later
stages,
is
making
sure
that
the
blog
show
up
and
that
we
do
a
blog
timeline.
So
that's
specifically
the
comms
role,
and
if
you
have
any
experience
of
that,
even
if
you
don't
we'd
invite
you
to
the
comms
role,
is
usually
fairly
understaffed
or
has
a
low
level
of
applicants,
because
people
think
that
they
not
qualified
to
do
the
comms,
but
really
a
lot
of
its
around
hey.
What
are
you
working
on?
B
A
Up
we
do
four
releases
a
year.
That
means
it's
a
roughly
three
month
time
commitment.
There
is
there's
the
warm-up
phase
and
the
there
is
also
a
retrospective.
If
you
are,
if
you've
shadowed
a
role
for
three
months
and
you're
interested
in
serving
as
lead
for
the
next
release,
then
it's
an
additional
three
months
of
commitment.
Oh
I,
see
I,
see
I,
see
you're
asking
per
week,
yeah
yeah.
Absolutely
they
said.
The
question
is
how
much
time
per
week
it
depends
on
the
role
if
you're
leading
the
releases
overall
lead.
A
It
tends
to
be
on
the
scale
of
you
four
hours
a
week
in
the
beginning
and
it
gradually
ramps
up
for
to
about
six
to
ten.
At
the
end,
sometimes
more
as
a
shadow,
it
depends
you
can
ask.
Hey
I
would
like
to
shadow
what
I
just
started
a
new
job,
so
maybe
I
can't
I
can't
be
available
at
all
the
time.
So
that's
something
for
you
to
discuss
with
your
lead
generally
you'd
expect
to
take
the
partial
amount
of
time
yeah.
B
I
served
as
enhancement
shadow
in
the
early
days
and
I
would
say
it
depends.
Some.
Some
roles
are
really
heavy
at
the
start
of
the
release
in
time.
Commitment
and
others
are
later
in
the
release
and
time
commitment
enhancements,
you're
pretty
busy
early
in
the
release,
trying
to
gather
people
to
have
all
their
caps
in
the
right
state
who
are
responsible,
and
then
you
have
a
Bob's
here,
Bob's
the
enhancement
late
for
1.17.
B
So
so
you
know
it
would
crack
me
if
I'm
wrong,
Bob,
then
there'll
be
enhancements,
freeze
and
then
code
freeze,
and
it's
really
making
sure
that
everybody
who
said
they
were
going
to
deliver
an
enhancement
to
kubernetes,
shows
up
with
the
code
in
the
right
state
and
with
the
docs
in
the
right
state.
So
enhancements
owns
tracking
the
cap,
making
sure
the
docs
show
up
and
making
sure
the
prpr
show
up
in
the
right
order.
B
So
I
think
that's
about
it,
so
they
get
keep
any
PR
after
after
enhancements
freeze
going
into
master
and
until
the
end
of
that
release.
So
also
they
determine
what
things
are
in
you
know.
Is
this
a
bug
or
is
it
a
new
enhancement?
Kick
it
out
so
I
would
say
roughly
in
the
early
stages,
maybe
two
to
four
hours,
maybe
a
little
less
and
then
around
enhancements
freeze.
B
You
might
be
spending
eight
hours
eight
to
ten
hours
a
week,
but
if
you
have
the
more
shadows,
you
have
the
more
you
can
delegate
and
I've
seen
releases
with
80
caps
and
I've
seen
releases
with
20
or
30.
So
it
really
is
a
factor
of
how
many
people
are
trying
to
change
things
and
so
yeah,
but
I
would
say
that
the
bottom
line
is
here.
Is
you
need
to
ask
that
your
boss
is
ok
with
you
with
this
time?
B
C
E
Hello,
my
name
is
Christopher
I
work
for
pivotal
on
the
paths,
pivotal
application,
service
release,
engineering
team
and
my
question
is
regarding
like
the
handbooks
and
what's
the
culture
around
them,
so
a
pivotal
like
we
take
these
handbooks
as
automation,
level.
Zero.
Do
we
have?
Is
there
like
roles
for
people,
automating
tasks
within
the
handbooks,
or
is
that
like
something
that
it's
even
done?
And
then
the
other
question
is
when
and
are
there
any
rules
around
making
changes
to
the
handbooks?
And
how
does
like
that
release
like
that
affect
the
cadence
of
the
releases?
That's.
A
A
really
really
excellent
question
and
the
top
level
answer
I
would
give
you
is.
Ideally
we
would
not
have
a
release
team.
Ideally,
this
entire
process
would
be
automated.
That
is
not
what
we
are
right
now
so
each
release.
We
attempt
to
automate
away
one
or
more
of
the
tasks,
for
example,
tracking
project
board
management.
Things
like
that
a
lot
of
times
can
be
automated.
A
Then
we
also
this
year
throughout
the
cycles,
automated
away
a
role,
an
entire
role
in
the
release
team.
There
used
to
be
a
test
in
for
a
role
on
the
release
team
and
the
person.
The
last
person
who
was
in
charge
really
really
really
hated
meetings,
so
she
just
developed
a
process,
an
on
call
process
and
a
lot
of
automation
to
make
sure
that
role
would
go
away
and
she
would
never
have
to
do
it
again.
That's.
A
And
that
is
encouraged.
We
talked
about
it
in
our
retros.
We
try
to
incorporate
that
as
part
of
the
process.
If
you're
a
shadow,
you
can
actually,
because
you
have
a
little
bit
more
freedom,
you're,
not
entirely
responsible
for
the
role
itself.
You
can
make
that
part
of
your
work,
saying
I,
see
what's
happening
here.
I
want
to
automate
it
away.
As
to
your
question
about
the
handbooks,
those
are
ever-evolving.
A
If
you
are
on
that
team,
go
change
the
handbook,
you
just
PR
a
change
in
it's
a
github,
it's
a
github
markdown
document
and
when
you
see
something
wrong
or
you
need
to
correct
something,
you
just
opened
a
pull
request.
You
get
the
team
and
the
cig
to
comment
on
it
and
that's
how
we
update
changes.
Cool
thank.
B
But
I
think
we
want
to
get
towards
that
state
where
we
automate
a
much
as
the
of
the
human
toil
away
and
a
lot
of
the
things
that
have
been
automated,
hang
up
processes
from
Google
having
having
most
of
the
kubernetes
test
infrastructure.
So
slowly
we've
been
opening
that
up
and
running
that
in
CNC
F.
B
So
that's
allowed
other
teams
to
step
in
from
other
companies
and
own
it,
for
example,
that
testing
for
role
was
a
Google,
a
role
and
a
Googler
came
in
and
automated,
so
that
Google
is
no
longer
needed
to
do
that
role
and
it
was
transparent
to
the
rest
of
the
community.
So
it's
great
to
see
you
know,
Google
are
helping.
You
know
even
free
themselves
from
a
lot
of
the
burden
and
toil
from
all
the
releases.
C
B
So
you
have
to
reapply
and
as
Winn
mentioned,
it's
pretty
pretty
tough,
but
we
look
for
many
different
factors,
so
you
know
apply
and
a
lot
of
people
actually
go
and
do
other
things
like
unnamed
people
in
the
release
team
I've
seen
people
come
along
and
say
I
really
don't
like
the
way
that
bug
triage
is
done.
This
is
an
example,
and
somebody
came
in
and
a
new
labeling
scheme.
So
but
yes,
you
have
to
reapply
for
each
one.
B
We
want
to
make
sure
that
you're
still
interested,
but
typically,
if
you
get
in
for
a
shadow,
you
usually
want
to
go
through
and
see.
The
rolls
through
I
served
on
three
release
teams.
Eye
shadow
lead
lead,
so
you
can
you
can
commit
to
that
so
once
you're
in
typically,
you
would
want
to
see
through
at
least
serving
as
Ally,
because
you've
already
gone
through
all
the
effort
to
learn
the
role.
Is
there
anything
else?
I
missed
yeah.
A
So
a
couple
things
we
do
look
for
different
for
lots
of
different
represents.
We
want
to
have
different
many
different
companies
represented
on
the
release
team,
yes,
which
kind
of
basically
means
that
if
you're,
if
you
work
at
Google,
it's
less
likely
for
you
to
be
on
the
release
team.
But
that's
not
that's
just
an
outcome.
That's
not!
Obviously
why
we
choose.
A
The
other
thing
is
this:
is
this
kind
of
ties
into
why
we
want
to
encourage
community
leaders
in
the
communities
community
to
have
their
own
onboarding
processes
so
that,
if
you
don't
make
it
under
the
release
team,
maybe
you're
more
interested
in
release
engineering
or
you
can
go
talk
to
sick
dogs
and
say
hey?
How
do
I
get
started
with
Docs
or
it's
it's
just.
It's
just
unfortunate
that
this
is
one
of
the
very
most
clearest
processes
to
communicate
to
becoming
a
community
member
right
now,
but
we
encourage
you
to
apply
again.
A
You
can
up
your
chances
by
being
involved
in
the
community
if
we
know
who
you
are,
if
we've
seen
your
handle,
if
you've
seen
you
open
issues,
if
we've
seen
you
show
up
at
meetings,
not
just
release
team
meetings
but
cig
meetings,
then
we're
like,
oh
okay,
so
we
know
this
person,
they
have
done
this.
They
have
made
these
comments,
we
know
them
and
we
think
they
would
be
a
great
addition
to
the
team
so
definitely
build
some
build
some
community
connections
that
will
definitely
help
you.
We.