►
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)
Scaling Non-Traditional Contributor Mentoring Initiatives - Paris Pittman, Google (Any Skill Level)
Contributor growth is vital to the health of any open source project. So how do you do it? The common practice of 1:1 mentoring doesn't scale - takes up a considerable number of resources and forced relationships can be toxic. However, help in finding a mentor continues to be one of the most frequent requests by new contributors. What do you do when you have major skill gaps or need contributors of certain roles in large numbers? This talk will discuss modern, non-traditional approaches that can be applied to Kubernetes. We will cover the current strategies of the project, provide an update, and showcase how you can get involved.
About Paris
Paris is a Developer Relations Program Manager on the Google Cloud Open Source Strategy team focusing on Kubernetes Community. She has 13 years of professional experience in attracting and retaining engineering talent for organizations and open source projects. She has also been organizing communities in one form or another for over 20 years, and at one point ran enough meetups to subsist solely on the free pizza leftovers.
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
Oh
I,
like
the
way
you
set
that
that's
new,
actually
that's
very
new
hi.
Everyone
welcome
to
my
session
today.
I
am
going
to
be
talking
about
scaling,
non-traditional
contributor
mentoring
initiatives
for
kubernetes
I
have
been
working
on
this
for
roughly
five
months.
This
is
a
sub
project
of
the
contributor
experienced
special
interest
group.
These
initiatives
are
targeted
towards
both
new
and
current
contributors.
A
And
now
it
does
all
right
so
first
things,
first,
the
the
part
that
I
always
have
to
do
that
I
detest
the
most,
which
is
the
about
me,
slide
I
again
in
Paris
Pittman
I
work
at
Google
I've
been
with
kubernetes
as
well
as
Google
for
roughly
eight
months.
At
this
point
it
feels
like
three
days
sometimes.
A
Sometimes
it
also
feels
like
30
years.
So
today,
it's
roughly
three
days,
I
have
been
working
with
technical
communities
for
quite
some
time,
I
lived
in
Baltimore.
Most
of
my
life
I
recently
moved
to
San
Francisco
at
one
point
in
Baltimore,
I
had
roughly
ten
meetups
that
I
organized
and
I
thought
I
lived
off
of
pizza
for
a
good
portion
of
my
life
and
I
right
now.
At
this
point,
I'm
only
run.
One
meetup,
however,
is
the
largest
kubernetes
meetup
in
the
world.
A
We
have
roughly
I,
think
four
thousand
members
at
this
point
and
see
at
least
a
hundred
and
twenty
people
a
month.
So
it's
definitely
a
big
big
audience.
Also.
My
contact
information
will
be
on
at
the
last
slide.
So
don't
feel
the
need
to
write
that
down
right
now.
So
today
we're
going
to
talk
about
quite
a
few
things.
I
could
probably
talk
about
mentoring
for
eight
hours.
A
This
was
reduced
to
30
minutes,
however,
so
there
are
large
chunks
of
the
organization
and
the
planning
process
that
unfortunately
I'm
not
going
to
be
able
to
get
to
today
and
I'm
gonna
kind
of
speed
through
some
of
it.
So
after
the
talk,
please
feel
free
to
meet
me
out
in
the
hallway
and
ask
me
more
in-depth
questions
about
the
wise
and
the
house
of
what
I'm
working
on,
but
the
first
thing
that
we're
gonna
go
through
is
the
actual.
A
Why
and
then
we'll
continue
on
so
when
I
was
first
hired
with
Google
under
Sara
Novotny?
Who
built
this
awesome
community
of
folks,
she
told
me
that
we
really
need
mentoring
when
exactly
that
meant
was
up
to
me
to
decide
and
also
to
do
discovery
with
so
I
used.
Several
different
discovery
methods
and
I've
really
been
tackling
this
as
an
engineering
problem
and
not
a
people.
Problem
I
feel
like
a
lot
of
other
open-source
projects,
as
well
as
organizations
and
incorporations
treat
mentoring
as
a
people.
A
This
is
not
an
issue
necessarily
now
meaning
owners
files
growths
and
for
for
folks
who
don't
know
what
owners
files
are.
That's
really
how
we,
how
we
as
a
project,
claim
ownership
of
certain
things
and
certain
individuals
like
approvers
and
reviewers,
get
into
those
other
files
so
that
they
can
review
and
PRS
and
work
within
the
github
organization.
A
And
so
not
only
did
we
do
a
lot
of
dev
stats,
which
we
just
saw
earlier
in
the
session
earlier.
But
we
did
other
data
sources,
we
did
surveying
I
did
interviewing,
and
these
are
the
kind
of
the
data
points
that
we
we
came
across
with
one
of
the
surveys
that
I
actually
collected.
It
was
a
hundred
and
twenty
contributors
of
multiple
organizations
and
backgrounds.
A
Sixty
percent
of
those
individuals
said
that
they
could
benefit
from
a
mentor
I
thought
that
was
very
significant
and
really
after
talking
with
I,
think
it
was
like
75
one-on-one
interviews
that
I
had
and
several
different
focus
groups.
I
realized
that
most
of
the
issues
that
folks
were
having
were
broken
down
into
a
couple
different
categories
and
those
categories
were
things
like
they
genuinely
wanted
a
mentor
fine,
but
then
also,
as
I,
asked
them
questions
about
like
Oh.
A
What
would
you
ask
a
mentor
and
tell
me
why
you
think
you
need
a
mentor
and
things
like
that?
I
actually
got
down
to
the
fact
that
we
just
need
better
contributor
documentation
and
that's
an
undergoing
project.
It's
actually
ongoing,
probably
forever
with
the
life
of
the
project,
because
documentation
will
continue
forever.
A
But
this
is
a
problem
that
I
think
mentoring
should
technically
solve,
because
if
we
have
better
tech
documentation,
then
possibly
these
numbers
of
sixty
percent
would
be
reduced
because
people
were
thinking
that
they
need
mentoring,
because
just
because
it
was
you
know,
they
couldn't
necessarily
find
what
they
needed
to
be.
A
valuable
contributor
and
I
actually
heard
that
valuable
contributor
quite
a
lot,
and
so
I
really
got
down
and
see
like
what
it
meant
to
be
a
valuable
contributor
and
then
the
owner's
files
piece
which
I
just
touched
on
a
little
bit.
A
So
we
need
more
structure
around
moving
around
right.
Now
we
have
a
community
membership
markdown
file
in
the
in
the
community
repo
and
is
a
guide
for
us
on
how
people
get
into
owner's
files
and
become
members
of
the
organization
and
that
kind
of
provides
a
guideline
to
to
how
folks
kind
of
move
around
within
the
organization.
So
those
were
kind
of
the
problems
that
I
thought
we
needed
to
solve
and
tackle.
So
when
I
approached
mentoring,
I
was
really
thinking
about
these
things
in
mind.
A
A
That
would
take
someone
under
their
wing
there's
some
kind
of
goal-setting
involved,
and
you
know
when
we
look
at
that
kind
of
a
situation.
We
really
realized
that
there's
a
huge
time
burden
in
there
and
that
either
the
mentee
or
the
mentor
usually
has
some
kind
of
burden,
that's
heavier
than
the
other
in
that
relationship,
and
that
kind
of
sounds
good,
though
right
sure
it
does,
of
course,
but
there's
way
more
avenues
to
take
than
just
traditional
mentoring
and
I'm
actually
gonna
go
through.
Why
not?
This
and
one
main
reason
why
not?
A
This
is
because
maintain
errs,
aren't
necessarily
the
only
mentors
and
your
peers
are
people
that
are
reviewing
are
other
people
in
a
project
can
be
there's
always
a
new
way
of
solving
this
problem,
but
a
lot
of
organizations
and
open-source
projects
go
towards
traditional
mentoring,
because
it's
the
easiest
to
set
up,
and
you
don't
necessarily
have
to
think
about
other
ways
of
solving
this
problem.
But
again
that's
what
I
have
been
trying
to
get
away
from,
because
I
think
there
are
other
ways
to
solve
this
problem.
A
A
A
Also
in
these
relationships,
where
we're
forcing
people
to
get
into
them,
that
could
create
toxicity.
I
know
when
I
practice
this
with
some
coworkers
it
kind
of
when
toxicity,
mentoring,
and
if
you,
google,
just
mentoring
and
toxicity
you'll,
see
so
many
so
many
even
just
research
documentation
about
how
these
forced
relationships
or
even
not
forced
relationships,
but
these
mentoring
relationships
become
can
become
toxic
for
a
number
of
reasons.
A
For
instance,
one
that
you
hear
a
lot
is
that
the
mentor
no
longer
has
time
for
the
mentee,
and
this
can
be
kind
of
upsetting
to
a
mentee
depending
on
what
their
situation
is,
because
they
could
be
relying
on
this
person
for
information
or
relying
on
this
person
to
push
through.
So
they
could
think
that
something's
wrong
with
them.
Also,
there's
harassment
there's
no
way
for
other
people
to
kind
of
monitor.
A
What's
going
on
in
the
relationship,
you
never
know
what
kind
of
information
they're
getting
or
giving
so
there's
a
number
of
different
things
that
could
really
create
toxic
relationships
here.
So
this
is
something
that
we
also
kept
in
mind
as
we
build
gold
settings
hard.
It's
another
reason
why
we
chose
not
to
necessarily
go
the
traditional
route.
This
is
sort
of
a
hot,
take
too
so,
hopefully,
you're
not
live
tweeting.
A
You're,
say:
you're
a
mentee
you're
going
into
this
new
relationship
with
someone
or
this
new
project,
for
instance,
let's
take
kubernetes,
you
want
to
be
a
new
contributor
and
and
you're
it's
just
kind
of
daunting,
like
the
project
is
so
large.
It's
daunting,
you
don't
know
what
a
cig
is.
You
have
no
idea
and
then
a
mentor
comes
to
you
and
this
kind
of
matching
relationship
and
says:
oh
hey,
what
are
your
goals?
You
have
no
idea
what
your
goals
are.
A
Your
goals
are
I
want
to
make
a
PR
and
then
usually
they're
like
oh
well.
What
do
you
want
to
do
in
five
years?
Like
you
know,
it's
kind
of
like
a
job
interview
like
you're
I
have
no
idea
what
I
want
to
do.
I
just
want
some
information.
I
want
someone
to
talk.
To
me,
I
mean
the
typical
there's,
a
like
a
typical
goal-setting
process
and,
frankly,
we
as
humans
kind
of
aren't
great
at
goals,
so
definitely
took
that
in
mind
as
we
were
building
and
then
so.
Why
else
time
I
mentioned
this
previously?
A
This
seems
to
be
the
number
one
reason
as
to
why
people
don't
automatically
sign
up
to
mentor
and
it's
the
number
one
reason
why
we
don't
have
a
line
out
the
door
right
now.
It's
because
we
do
have
other
time
commitments
in
our
life.
An
open
source
for
the
most
part
is
voluntary,
even
if
you
are
working
on
the
project
full-time
with
a
corporation.
A
How
do
I
find
a
cig
and
I'm
sure
people
come
to
you
all
of
the
time.
Ask
you
those
questions
and
then
I'm
sure
you
answered
them
and
then
maybe
they
ask
you
another
one
and
then
all
of
a
sudden,
you're,
naturally
just
building
this
trust
up
with
this
individual
in
this
relationship,
so
I
think
we
really
need
to
unpack
the
term
mentor
and
really
educate
folks
on
what
the
term
mentoring
means,
especially
for
kubernetes.
A
Oh
excuse
me
and
those
terms
me,
though
term
mentor
means
a
much
different
thing
to
us
here,
so
it
really
means
sponsor.
What's
a
sponsor,
that's
somebody
with
social
clout.
In
order
to
gain
membership
into
the
kubernetes
organization
on
github,
you
actually
have
to
have
two
sponsors.
These
are
people
that
have
either
may
be
approved,
past
PRS,
for
you,
people
in
your
special
interest,
group,
etc,
but
they're,
just
people
that
are
giving
you
this
gateway
of
trust
within
the
organization.
A
There's
also
connectors
coaches
guides
you'll
note
that
I
have
not
used
necessarily
the
words
teacher,
because
again
teacher
also
implies
that
you're
providing
a
lot
of
your
time
and
a
lot
of
these
activities
that
you'll
see
don't
necessarily
need
a
lot
of
time
and
you'll
see
by
the
use
cases
that
the
time
is
not
necessarily
needed
either.
So
this
discovery
period
and
acting
like
an
engineering
problem,
I
put
together
a
couple
of
use
cases
again.
I
interviewed
about
75
folks
did
a
couple
focus
groups
surveyed
over
120
people.
A
That's
just
not
necessarily
happy
not
happening
naturally,
and
they
just
need
some
help
and
some
guidance
there
and
then,
of
course,
I.
Would
I
just
want
a
one-on-one
session
with
someone?
Yes,
I
just
want
to
talk
to
someone
really
quick,
whether
that's
for
an
extended
period
of
time
or
whether
that's
you
know
just
a
just
a
really
quick
one
on
one
session
like
a
pair
of
programming.
A
Actually
a
pair
of
programming,
a
code
based
or
I
hear
that
a
lot
of
here,
I
just
need
a
code
base
or
or
I
just
need
better
documentation
on
the
on
the
code
base
and
how
I
would
like
what
the
tree
looks
like,
etc
and
then
I'm
a
sig
or
I
mean
a
sig,
I'm,
gonna,
say
lead,
etc
and
I
need
a
certain
kind
of
contributor.
So,
for
instance,
in
the
last
dev
stat
session
we
saw
some
things
about
approvers
and
how
certain
SIG's
were
gaining
with
issues
and
PRS.
A
Yet
their
approvers
were
either
staying
the
same
or
even
decreasing
in
some
cases.
In
that
case,
then,
how
are
we
attacking
the
issue
of
not
having
a
certain
kind
of
contributor
and
how
can
we
rely
on
mentoring
to
help
out
with
that?
And
the
last
is
I've
heard
from
a
lot
of
members
of
the
community,
especially
veterans
that
we
don't
have
enough
students
and
of
course
we
don't
have
enough
underrepresented
folks
in
TAC
and,
frankly,
any
mentoring
program
that
you
set
up.
A
A
A
This
is
a
mantra
that
I've
lived
by.
Actually,
when
I
saw
this
I
was
like
oh
wow,
cupcakes
atm.
Yes,
humans,
don't
sale
systems
do
so
I
really
approach
and
again
I'm
purchased
a
problem
as
sort
of
an
engineering
issue
and
trying
to
think
of
ways
that
we
could
turn
mentoring
into
systems
and
you'll
actually
see
that
a
lot
of
folks
have
created
even
on
github
mentoring
systems,
where
people
do
like
one
on
one
matching
with
automation
and
algorithms,
and
things
like
that.
A
So
there's
ways
to
beat
this
meaning
beat
this
problem
and
I
guess
if
you
are
building
a
mentoring
program
for
something
that's
not
kubernetes
and
you're
in
the
audience,
I
think
I
would
definitely
approach
it
as
what
systems
can
I
use
to
benefit
this?
What
how
can
I
take
humans
out
of
this
equation?
I
mean,
obviously
you
have
the
human
mentor
and
you
that
you,
the
human
mentee.
A
But
how
can
you
scale
this
in
a
way
because
a
lot
of
mentoring
programs
that
I've
seen
fail
because
there's
too
many
humans
in
the
process
and
there's
too
many
moving
parts?
And
frankly,
as
you
know,
just
scheduling
calendar
invites
between
multiple
parties
is
very
difficult,
we're
all
very
busy
folks
so
like.
How
do
we
take
ourselves
out
of
this
equation
and
we're
gonna?
Do
it
by
the
following
ways?
So,
first
things
first
self
service:
how
can
a
sig
spin
up
a
program
for
mentoring
to
address
their
current
need
for
contributors
Automation?
A
This
alleviates
that
initial
need
for
people
just
to
go.
Oh
I
need
a
mentor
and
I
hear
this
a
lot,
especially
from
new
contributors
where
they
just
come
on
again.
They
just
come
on
to
the
project
and
they
immediately
say:
oh
I
need
a
mentor
and
I
can't
find
the
documentation
that
I
need
so
better
documentation
is
something
that
we
are
actually
using
to
scale
predefined
goals.
A
What
I
mean
by
this
is
we're
all
humans
and
ultimately
again
have
busy
schedules
and
therefore,
in
these
volunteering
assignments,
especially
mentoring,
people
tend
to
either
give
up
easy
because
there's
no
accountability
or
they
get
busy.
What
have
you?
How
can
we
structure
this
in
a
way
where
we
provide
them
with
some
accountability?
A
I
know
when
she's
in
the
audience
right
now,
she's,
actually
a
great
mentor.
She
just
joined
the
project
recently
and
by
sharing
her
immediate
experiences
with
other
people
that
helps
thirst
and
I
recently
saw
this
tweet.
This
is
by
Jonah
bacon,
who
is
one
of
my
favorites
in
the
in
the
open
source
community
he'd
built
the
up
onto
community
and
Jorge
Castro's
in
the
audience
too,
who
used
to
work
with
Jono
and
I,
really
felt
like
this
tweet
created
validation
for
for
some
of
the
stuff.
A
That
I
was
doing
especially
the
pure
components,
and
it
reads
the
trick
to
making
communities
scale
is
member
to
member
mentoring,
categories
members
and
groups
since
up
clear
mentoring
links
have
clear
criteria
for
what
mentoring
completion
looks
like
and
of
all
the
support
provide
mentors.
You
provide
mentors
based
on
mentee
feedback
and
that's
exactly
what
we're
doing
so.
These
are
the
seven
programs.
Can
anybody
guess
what
else
is
a
seven
about
kubernetes
the
logo
so
anyway,
I
just
figured
that
out.
A
Actually
why
creating
this
deck,
so
group
mentoring,
I'm
gonna,
go
through
in
a
second
the
one-on-one,
our
meet
our
contributors,
outreach
team,
google,
Summer
of
Code,
mentoring,
events
and
release
team.
That's
a
lot,
but
it
addresses
all
of
those
use
cases.
So,
what's
group
mentor,
group
mentoring
is
actually
I
call
it
my
baby,
because
it's
an
idea.
That
is
not
widely
used
and
open
source
whatsoever
Lee's
in
the
audience,
and
he
just
went
through
our
test
which
I'll
get
into
in
a
second.
A
But
this
is
creating
sort
of
a
safe
environment.
If
you
will
to
ask
dumb
questions
and
I,
say
dumb
and
in
quotes,
because
I
hear
that
a
lot
there's
no
such
thing
as
a
dumb
question,
but
this
is
a
peer
level
regime,
peer
mentoring
in
a
semi,
structured,
self-paced,
learning
environment.
So
a
sig
will
come
to
me
and
say:
hey
I
need
a
certain
type
of
I
need
a
certain
type
of
contributor.
In
this
case
and
the
case
for
lis
and
the
test
that
we
ran
QB
diem
said
hey.
A
We
need
more
reviewers,
meaning
people
who
are
currently
and
they
would
like
to
get
into
a
reviewer
file
to
review
PRS
and,
according
to
the
community
membership
guide
that
takes
roughly
at
two
to
three
months
to
get
to
membership
status.
So
we
created
a
two
to
three
month
program
where
we
taught
them
different
skills
needed
so,
for
instance,
testing
infra
as
it
relates
to
reviewers
Tim
Hawken
did
a
live
like
how
to
do
a
code
review
and
what
he
looks
for
and
then
we
had
also
many
different
other
kinds
of
resources
available.
A
Everybody
gets
together
in
a
slack
channel.
The
slack
channel
is
private
again
because
we're
trying
to
create
a
safe
environment
and
then
each
one
of
the
the
peers
would
ultimately
talk
to
each
other
and
like
throw
out
questions
and
they
help
each
other
and
there's
a
relationship
of
four
to
one
and
four
to
one
meaning
for
mentees
to
one
mentor
and
the
goal
is
predetermined.
The
goal
is
get
to
the
next
level
and
the
goal
is
already.
Those
requirements
are
already
drawn
out
in
the
community
membership
guide.
A
So
if
it
says
like
you,
have
to
have
20
PRS
on
your
belt
or
something
along
those
lines,
then
that's
what
you're
going
to
be
doing
through
the
program
and
we
have
these
by
weekly
check-ins
and
that's
holding
you
accountable
and
again.
Therefore,
it's
four
to
one
so
this
individual.
It's
almost
like
a
mini
team.
If
you
will
in
the
individual
mentor
with
my
help
and
with
you
know,
other
coordinators
helps
would
would
do
these
bi-weekly
stand-ups
and
ask
hey.
A
How
are
you
doing
and
some
of
them
are
even
on
slacks,
so
sometimes
you
don't
even
need
to
jump
on
a
call.
You
jump
on
slack,
you
predetermine
a
time.
You
say:
everybody's
gonna
get
on
slack
between
this
four
hour
window
and
hey.
What's
going
on
with
everybody,
and
then
people
post
their
issues
in
the
chat
and
say
hey
I'm
having
an
issue
here.
A
I
really
drew
this
from
Mozilla
leadership
and
ADA
Academy.
They
have
cohorts
of
similar
nature,
but
not
necessarily
quite
this.
So
what
do
we
learn
from
this
from
the
test?
Anyway,
we
learned
that
it
works.
It
works
because
we
graduated
three
well
actually
it'll
be
five
here
shortly:
Li's
graduating
hopefully
next
week,
but
we
graduated
almost
half
of
the
people
that
we
went
in
with
and
then
the
other
half
of
course
again
had
human
responses
of
got
busy
had
other
things
come
up.
A
We
actually
had
eight
time
zones
represented
and
it
ended
up
being
only
a
very
small
population
of
those
peers
that
were
in,
like
the
same,
like
similar
time
zones
where
talk
to
each
other
and
ideally,
what
we
want
everyone
in
their
cohort
to
talk
to
each
other,
not
necessarily
not
necessarily
just
the
people
within
that
time
zone
and
again
we
learned
that
people
have
lives
and
things
come
up.
This
is
natural
natural
part
of
mentoring,
the
one-on-one
hour.
A
This
addresses
I
want
to
talk
to
somebody
for
like
a
one-on-one
session,
so
we
are
pre
determining
the
activity
in
the
wall.
We're
saying
tell
us
what
you
want.
So
a
code
review
how
to
pair
programming
and
ask
me
anything
session,
a
code
based
or
you
get
one
shot
one
hour,
one
mentee
one
mentor
one
time
and
it
could
be
with
someone:
that's
either
a
peer.
That's
been
on
the
project
longer
or
even
a
maintainer.
If
so,
they
sign
up
to
be
a
mentor.
A
This
was
actually
inspired
by
the
Gopher
con
buddy
program
and
that
is
sort
of
kind
of
like
the
the
newcomers
lounge
that
coupon
rolled
out
this
year,
where
you
just
get
paired
up
with
someone
that
is
a
little
bit
more
experienced
with
you
for
a
short
time
period
meet
our
contributors.
This
is
a
an
answer
to
I,
have
some
quick
questions
and
I'm,
not
finding
it
in
documentation
or
I
need
something
clarified
or
I
have
a
one-off
question,
and
maybe
somebody
can
help
me.
A
A
What's
your
favorite
color
Y
opensource
y
kubernetes?
It
was
it's
really
spans
the
gamut,
but
it's
been
really
fun
and
cool.
We've
had
over
I
think
200
views
on
one
video,
and
that
means
to
me
that
we've
helped
at
least
200,
potentially
200
people
and
that's
scalable
and
that's
kind
of
what
we're
going
for
here.
A
Outreach
in
google
Summer
of
Code
outreach
E
is
a
program
where
they
pay
underrepresented,
folks
in
tech
to
work
an
open-source.
It's
a
known
issue
that
mostly
white
males
work
on
open
source
because
they
can
afford
to
so
outreach.
He
is
a
very
cool
program
that
is
a
third
party
that
helps
us
with
that
and
CN
CF
and
Google
paid
for
to
outreach.
He
interns
for
us
to
run
a
test
to
see
what
this
would
be
like
for
us.
A
So
this
is
at
least
getting
our
PR
out
as
well
that
we're
a
project
that
looks
for
new
contributors,
especially
students.
Now
both
of
these,
though,
aren't
necessarily
going
to
answer
scale.
So
that's
why
they're
in
addition
and
we're
not
necessarily
going
forward
with
them
as
the
only
solution,
I
actually
see
a
lot
of
open
source
projects
that
say:
oh,
we
have
mentoring,
and
then
you
find
out
that
it's
just
google
Summer
of
Code
and
you're
like
well,
how
many
interns
are
you
really
taking
on?
A
A
Last
but
not
least,
as
a
release
team,
this
was
something
that
I
definitely
can't
take
credit
for.
Several
members
have
helped
out
with
this,
including
Jay
singer
to
Mars
and
other
release,
leads
and
release
team
members
and
some
of
our
veterans.
This
is
a
really
cool
way
to
look
at
succession
planning
and
what
they
do
is
they
have
the
team,
and
then
the
team
has
different
shadow
roles
so,
for
instance,
the
release
the
release
team
lead.
A
Excuse
me
it
has
a
shadow
and
then,
ultimately,
that
is
just
creating
a
natural
mentoring
environment
where
the
shadow
has
to
come
on
to
the
calls.
And
then
there
are
maybe
even
responsible
for
a
few
different
small
minor
tasks,
but
they're
really
getting
a
lay
of
the
land
of
how
the
release
team
works.
We
actually
have
people,
especially
new
contributors,
float
through
the
release
team
and
one
of
our
new
contributors.
A
I
put
this
in
here,
because
this
is
my
flow
chart
is
huge
and
the
this
I
really
wanted
to
put
this
in
here
and
not
exclude
it,
because
I'm
really
working
off
of
one
single
source
of
truth
here,
and
this
is
where
the
automation
comes
in,
because
we're
essentially
creating
database
that
will
create
alert
systems
and
calendar
systems
and
all
different,
really
kinds
of
cool
ways
of
scaling.
This,
and
this,
like
I,
said
this
is
just
a
snip.
A
How
can
you
get
involved
all
again?
All
of
all
these
slides
will
be
uploaded,
but
we
have.
We
have
some
documentation
now
under
the
community
repo
in
the
mentorian
folder,
we
have
mentoring,
guidelines,
mentee
guidelines,
etc,
if
you're
a
sig
and
you
need
other
contributors
of
any
variety.
Please
reach
out
to
me
and
if
you'd
love
to
help
me
build
this
stuff,
like
I
said
some
of
the
stuff
is
still
in
a
state
that
is
not
implementable.
Yet,
please
reach
out
to
me.
You
can
touch
me
in
any
of
the
Conspirator.