►
From YouTube: Cloud Native Mentorship: Tips for Being a Great Mentor to CNCF Students - Lucas Servén Marín
Description
Don’t miss out! Join us at our upcoming hybrid event: KubeCon + CloudNativeCon North America 2022 from October 24-28 in Detroit (and online!). 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.
Cloud Native Mentorship: Tips for Being a Great Mentor to CNCF Students - Lucas Servén Marín, Private
The CNCF and broader Linux Foundation offer generous mentorship programs that connect students around the world with open source projects. The whole open source community can benefit from and grow thanks to these opportunities, however, many technically talented maintainers are not trained as teachers or equipped with the tools to lead student projects. So what can open source maintainers do to help ensure mentees are successful in their cloud native journeys? And more broadly, how can maintainers use these opportunities to build a long lasting and inclusive community? In this talk, Lucas discusses challenges, successes, and lucky breaks he experienced through two years of non-stop mentorship as a maintainer of Thanos. Based on these lessons, he provides concrete strategies and tips that Thanos mentors and mentees have leveraged to communicate effectively and empathically and to meet the community's goals, whatever they may be.
A
Yeah
thanks
everyone
for
coming
thanks
a
lot
for
coming
to
this
session.
I'm
happy
to
see
people
are
excited
to
talk
about
mentoring,
so
yeah.
The
whole
point
of
this
session
is
to
talk
a
little
bit
about
what
makes
a
mentorship
successful
and
I'm
going
to
give
you
some
tips
specific
to
the
cloud
native
world.
But
the
idea
is
that
some
of
the
things
we're
going
to
talk
about
are
kind
of
general
to
mentorship.
A
You
know
as
a
whole
and
also
maybe
even
helpful,
for
improving
communication
in
other
parts
of
in
other
parts
of
life
as
well,
so
we're
gonna
start
a
little
bit
more
existential,
maybe
than
we
would
like.
Maybe
we
would
like
to
with
these
two
questions.
So
what
is
a
good
mentor,
and
why
do
I
want
to
mentor?
A
A
So
without
further
ado,
my
name
is
lucas
herbert
marin
and
I'm
an
engineer
and
I'm
also
a
maintainer
of
one
of
the
cncf
projects
called
thanos,
and
I
didn't
study,
teaching
or
anything.
I
studied
engineering,
but
I
have
been
teaching
in
different,
like
kind
of
in
different
environments
for
the
last
12
years,
like
tutoring
and
mentoring,
and
everything
from
you
know
chemistry
to
guitar
to
grpc.
A
A
So,
like
one
of
the
things
that
we
care,
a
lot
about
in
thanos
is
about
learning
in
particular,
so
we're
always
trying
to
think
about
how
we
can
make
things
better
and
in
particular
how
we
can
make
the
mentorship
experience
better
for
our
students
the
next
time
around,
and
I
think
this
kind
of
raises
a
really
big
question,
which
is:
why
does
it
matter?
Why
should
we
invest
so
much
effort
in
making
a
mentorship
experience
better
for
students,
like
you
know,
we're
open
source
maintainers,
we're?
A
A
So
this
is
why
the
stakes
are
so
high
right
like
for
some
students,
a
mentorship
can
be
a
lifeline
and
for
other
students
it
can,
at
the
very
least
you
know,
be
their
first
experience
programming
in
a
formal
setting
or
their
first
experience
in
open
source
at
all.
So
if
a
program
a
mentorship
program
goes
poorly,
it
can
mean
that
this
student
will
never
participate
in
open
source
again,
so
the
stakes
are
definitely
really
high.
A
A
A
Am
I
doing
this
because
I
want
to
build
a
community,
or
am
I
doing
this
because
I
really
like
just
the
pleasure
of
teaching
other
people,
and
I
think
that
this
is
true
for
mentors,
but
it's
also
a
really
good
question
for
mentees
as
well
right
like
how
can
we
know?
How
can
we
be
a
good
mentor
if
we
don't
even
know
what
a
student
wants
to
learn
inside
of
the
thanos
project?
We
start
every
single
one
of
our
mentorships
asking
our
students
this
exact
question.
A
What
do
you
want
to
learn
because
maybe
they
want
to
learn
goaling
or
maybe
they
want
to
learn
about
open
source
software,
or
maybe
they
just
want
to
build
their
cv?
These
are
all
legitimate
reasons
to
do
a
mentorship
program
right,
but
if
we
don't
know,
then
we
can't
aim
in
the
right
direction
at
all
so
encourage
your
students
to
really
think
about
this
question
and
also
once
they've
thought
about
it,
encourage
them
to
actually
ask
for
what
they
want.
A
A
And
yeah,
and
the
last
thought
on
this
subject
is:
if
you
ask
for
what
you
want
as
a
mentee,
then
your
maintainers
are
going
to
be.
Your
mentors
are
going
to
be
able
to
actually
curate
the
goals
of
the
project
to
suit
your
learning
needs
and
on
the
other
side,
on
the
flip
side,
as
a
mentor
you'll
also
be
able
to,
you
know,
curate
the
tasks
of
a
project
to
suit
the
goals
of
the
pro
of
the
of
the
open
source
project
itself.
A
So
here's
an
example
from
the
thanos
world.
From
our
point
of
view,
you
know,
a
mentorship
program
is
not
really
supposed
to
be
a
school
project
at
all.
Our
mission
is
to
tell
people
to
teach
our
students
about
real-world
engineering
and
in
the
real
world.
There's
laws
of
unknowns.
In
fact,
sometimes
the
unknowns
are
so
great
that
you
won't
even
able
you
won't
even
be
able
to
finish
the
project
at
all
in
the
first
place.
So
the
goal
of
the
project
shouldn't
be
hey
finish
some
task.
A
Instead,
the
goals
that
we
have
for
our
mentorship
projects
are,
we
want
to
teach
people
about
contributing
to
open
source.
We
want
to
teach
people
to
learn
how
to
work
together
and
we
want
to
empower
the
next
generation
of
open
source
contributors,
and
one
thing
that
we
always
like
to
say
inside
of
the
thanos
team
is
that
art
or
like?
A
So,
like
I
mentioned,
the
real
world
and
engineering
is
full
of
unknowns,
and
sometimes
it's
going
to
be
full
of
really
unpredictable
things.
That's
going
to
break
everything
from
the
very
beginning,
so
the
unpredictable
is
going
to
happen
and
we
should
try
to
be
flexible
and
accommodate
this.
That
means
that
we
should
have
backup
plans.
A
For
example,
one
thing
that
happened
to
us
in
the
previous
previous
thanos
mentorship
session
is
that
in
the
very
first
week
of
a
program,
an
external,
an
external
community
member,
finished
the
entirety
of
a
student's
project
within
the
first
week,
and
that
meant
that
we
had
to
adapt
really
really
quickly
and
come
up
with
like
an
alternative
plan
and
on
the
flip
side.
Another
thing
that
happened
was
that
one
time
the
project
ended
up
being
so
challenging
that
there
was
no
way
we
were
gonna
finish
at
all.
A
We
like
super,
like
did
not
anticipate
how
challenging
it
was
gonna,
be,
and
in
this
case
we
had
to
push
the
goal
post
back.
So
in
both
situations
we
found
that
it
was
really
useful
to
get
together
think
about
the
goals.
Think
about
what
we're
trying
to
learn
and
come
up
with
a
new
project
and
again
the
point
of
the
program
for
us
is
not
to
do
a
single
project.
A
A
So
how
can
we
guarantee
that
we
actually
learn
from
our
mentorship
programs
like?
How
can
we
guarantee
that
we
get
valuable
feedback
from
every
mentorship
program?
How
can
we
make
sure
that
how
do
we
make
sure
that
our
mentorship
program
is
self-correcting?
How
can
we
make
sure
that
every
mentorship
is
better
than
the
one
before
and
in
other
words
like?
A
How
can
we
make
sure
that,
at
the
end
of
every
mentorship,
we
come
up
with
more
suggestions
like
the
ones
that
I'm
kind
of
gonna
be
presenting
today
and
the
way
that
we've
been
doing
this
inside
of
thanos?
Is
we
hold
retrospectives,
and
I
know
that
people
can
like
barely
contain
the
excitement
to
like
start
the
human
wave
right
now,
but
we
even
have
like
a
little
document
inside
of
thanos.
A
That
is
like
an
outline
describing
what
the
mentorship
process
or
sorry
the
retrospective
process
looks
like,
so
that
mentors
and
mentees
know
what
to
expect
and
for
us
holding
consistent
and
well-structured
retrospectives
is
a
really
helpful
way
to
get
high
quality
feedback
from
everybody
involved,
and
that
way
we
can
make
everything
better.
The
next
time
around
so
holding
retrospectives
is
really
cool,
but
people
here
are
probably
learning,
are
probably
really
interested
in
mentorship
and
interested
in
learning
and
interested
in
pushing
the
boundaries.
So
it's
natural
for
us
to
ask
ourselves.
A
How
can
we
learn
even
more
than
this
like
consider
the
following
problem
right?
If,
if
we
hold
a
retrospective
just
at
the
end
of
three
months,
then
it
I
have
to
wait
till
the
end
of
the
program
to
get
any
feedback
about.
If
I'm
doing
things
correctly
or
not,
and
on
top
of
that
you
know,
I
have
a
limited
bandwidth
as
a
maintainer.
So
if
I
can
only
mentor
two
students
every
year,
that
means
that
I
only
have
two
learning
opportunities
to
improve
things
in
an
entire
year
and
that's
not
very
much.
A
So
what
can
I
do
to
learn
more
so
that
I
can
improve
my
meeting
with
with
my
mentee,
which
may
be
tomorrow
and
one
strategy
that
we've
done
inside
of
thanos?
Is
that
we've
been
holding
retrospectives
among
all
of
the
mentors,
so
we
can
share
and
aggregate
feedback
from
every
single
retrospective
and
in
practice
this
is
a
really
cool
tool,
because
it
means
that
I
may
only
have
two
students
every
year,
but
there
may
be
a
bunch
of
other
maintainers
that
have
in
total
10
students.
A
A
But
actually
one
more
thought
on
this
is
that,
when
sharing
details
more
broadly
within
the
entire
maintainer
team,
it's
important
to
keep
in
mind
that
some
details,
shared
inside
a
retrospective,
are
going
to
be
shared
in
confidence
and
are
not
appropriate
to
share
more
broadly
so.
Keep
in
mind
that
we
should
only
share
things
that
are
appropriate
with
everyone
else.
So
you
can
keep
the
trust
of
the
whole
community
and
keep
people
safe,
but
yeah
getting
5x
the
time.
A
How
can
we
learn
even
more
than
we
have
been
doing
just
inside
of
one
open
source
community
and
one
approach
that
we've
come
up
with
inside
of
thanos
is
that
we
want
to
share
our
feedback
and
our
learnings
with
an
even
broader
community.
So
that
might
mean
all
of
thanos,
not
just
the
maintainers
but
the
entire
thanos
community
or
all
of
kubecon,
and
in
fact,
one
of
the
feedback
items
that
we
had
from
our
last
internal
thanos
meetup
was
hey.
A
So
there's
still
one
problem
here,
which
is:
we've
shared
feedback
with
the
whole
thanos
community
and
with
the
entire
kubernetes.
You
know
community
as
well,
so
we've
been
learning
a
lot
a
lot
more,
but
what
we've
really
done
is
just
increase
the
learning
bandwidth,
but
it
still
takes
me
months
to
learn
right.
We
have
this
problem,
which
is
that
we
still
have
a
really
long
or
slow
learning
latency.
A
So
this
is
a
really
big
question,
which
is:
how
can
we
learn
faster
and
one
approach
that
we've
been
doing
is
that
we
try
to
hold
many
check-ins
with
our
students
like
every
single
meeting.
That
means
that
if
we
have
a
weekly
meeting
with
a
student,
we'll
try
to
always
ask
a
question
like
hey:
how
are
things
going?
A
You
know?
How
are
you
feeling
is
there
anything
that
we
should
be
doing
differently?
Asking
any
variation
of
this
question?
It
may
sound
really
menial,
but
it's
like,
if
you're,
asking
really
empathetically
and
honestly
you're
trying
to
improve
the
process,
and
that's
really
key
for
us
to
get
more
feedback,
because
at
the
end
of
the
day,
if
you
only
hold
a
retrospective
after
the
entire
process
is
over
it's
too
late
to
fix
things
right
now.
A
You
know,
even
if
you
have
nothing
to
really
update
about
actually
scratch
that,
if
you
have
nothing
to
update,
then
you
should
especially
have
a
meeting
because
it
sounds
like
you
could
improve
the
process.
Even
if
your
only
update
is
hey.
I
wasn't
able
to
finish
my
work.
That's
totally
worth
communicating.
A
Maybe
you
can
use
this
hour
to
say,
hey,
you
know
what
we
should
have
unblocked
you
better
or
we
should
be
changing
the
way
that
we're
setting
our
weekly
goals
because
you
weren't
able
to
meet
it.
So,
no
matter
what
we
do
having
a
check-in
is
really
really
useful
and,
of
course,
the
goal
here
shouldn't
be
to
just
fill
an
hour
right
if
the
check-in
is
really
really
short.
That's
fine,
but
having
more
frequent
feedback
is
always
helpful.
A
A
That
means
that
it's
probably
not
the
most
efficient
use
of
time
to
do
work
that
you
could
otherwise
do
alone,
because
you're
going
to
end
up
just
doing
like
some
coding
work
alone,
that,
with
the
added
pressure
of
somebody
watching
you
the
whole
time
and
that's
fine.
If
your
goal
is
to
do
pair
programming,
then
for
sure
by
all
means
program
together
for
an
hour,
but
at
least
do
it
consciously.
A
Instead,
if
the
point
of
this
check-in
is
to
like
improve
the
process,
then
it's
probably
a
better
use
of
time
to
work
asynchronously,
because
you
know
when
you're
working
a
synchro,
asynchronously
you're,
going
to
naturally
run
into
problems,
you're
going
to
naturally
run
into
doubts
and
run
into
issues
and
a
weekly
check-in
is
the
perfect
environment
to
ask
and
answer
these
kinds
of
questions
we'll
skip
this
and
come
back.
We
have
time
so
yeah
speaking
about
issues.
A
A
You
know,
like
all
these
points,
you're
making
sound,
really
great,
but
I'm
really
busy
as
a
maintainer
and
I'm
worried
that
I
don't
have
enough
time
to
implement
these
things
and
instead
I
want
maybe
some
practical,
simpler
advice
that
you
could
give
me
and
I
think
that's
like
really
really
helpful
and
transparent
feedback,
but
saying
something
like
this
requires
a
lot
of
trust
and,
ironically,
building
trust.
A
bet.
One
of
the
best
ways
to
build
trust
is
also
to
communicate,
empathically
and
honestly
so
kind
of
works.
Both
ways
right.
A
We
need
trust
to
be
transparent,
but
we
also
need
transparency
to
build
trust.
So
I
mean
we
could
talk
about
just
this
subject
for
like
plenty
of
sessions
and
if
you
want
to
talk
more
about
this
kind
of
communication
stuff
like
let's
chat
afterwards,
but
it's
definitely
a
really
important
subject
so
yeah
once
we're
making
progress
on
a
project,
we
want
to
make
sure
that
we're
keeping
our
momentum
and
moving
towards
our
goals
and
one
of
my
goals
as
a
mentor,
is
to
help
students
meet
their
goals.
A
So
how
can
we
prevent
people
from
getting
stuck
and
one
of
the
most
useful
things
that
we
found?
Is
that
it's
really
valuable
to
time
box
your
explorations
and
your
troubleshooting,
and
and
really
hold
yourself
accountable
to
this
time
boxing.
So
one
thing
that
happened
to
us
in
the
thanos
world
was
that
we
got
super
in
the
weeds
trying
to
fix
some
protobuf
issue
with
a
student,
and
it
took
us
days
and
we're
being
honest,
it
actually
took
us
weeks
until
we
finally
realized
hey.
A
We
have
to
take
a
second
to
think
about
this
problem
from
another
angle
and
we
realized
that
we
should
have
been
attacking
it
from
the
top
down
from
the
api
level.
Instead
of
the
bottom
up,
but
we
would
have
never
thought
about
this
if
we
didn't
take
a
break
to
think
about
everything
from
another
way.
So
it's
extremely
it
can
be
extremely
useful
tool
to
time
box
and
set
limits
to
the
amount
of
time
that
you'll
invest
on
something
and
to
really
hold
yourself
accountable.
A
A
So
like
don't
let
this
block
you
and,
in
fact
like
make
sure
to
plan
other
work
so
that
the
feedback
waiting
for
the
feedback
doesn't
become
a
bottleneck
in
your
work
and
also
try
to
have
a
backup
plan,
because
it
may
be
totally
the
case
that
your
big
proposal
will
be
rejected
by
the
community
and
then
what
happens
so
yeah
make
sure
that
feedback
doesn't
become
a
bottleneck,
yeah.
And
then
this
one
is
maybe
a
little
bit
more
self-explanatory,
but
try
to
merge,
often
and
frequently,
every
time
that
we
make
a
pr.
A
Maybe
a
strategy
you
can
take
is
to
have
a
fork
of
your
project
and
you
can
merge
frequently
to
this
fork
and
then
you
can
actually
get
reviews
done
on.
You
know
all
these
pr's
on
another
fork,
and
then
you
can
merge
this
to
the
main
branch
or
anything
else,
but
try
to
think
outside
of
the
box
that
you
can
get
more
feedback
as
often
as
possible.
A
Yeah
so,
in
the
end,
make
sure
that
you
keep
the
collaboration
relationship
between
your
students
and
your
mentors
friendly
and
empathic,
and
caring
and
understanding
of
one
another,
because
mentoring
throughout
the
pandemic
has
been
a
huge
challenge
for
everybody.
Right
I
mean
we've.
Had
families
lose
lose
loss?
Oh
my
god.
We've
had
families
that
have
lost
loved
ones,
we've
had
people
who've,
gotten
sick,
we've
had
people
who've
had
to
change
jobs,
we've
had
people
who
have
had
to
change
priorities
or
have
just
changed
interest,
and
these
are
all
normal
things
that
happen
in
life.
A
These
are
all
really
normal
challenges
and
they're
not
going
to
go
anywhere
so
try
to
always
stay
understanding
of
one
another,
and
the
best
thing
that
we
can
do
as
mentors
is
to
always
support
for
and
care
for
one
another
and
to
really
be
there
so
yeah
I
mean
in
the
end
we
learn
every.
We
learn
a
lot
every
single
time
that
we
do
a
mentorship.
I
know
that
I
learn
a
really
a
lot
every
single
time.
I
know
that
yeah.
I
really
appreciate
the
whole
mentorship
experience.
A
A
C
A
A
So
we
definitely
try
to
structure
the
work
and
then
there's
also
maybe
more
pedagogical
part
which
is
like
we'll
try
to
you
know,
try
to
kind
of
impress
upon
them
the
importance
of
merging,
often
so
that
you
can
get
more
feedback.
But
the
other
strategy
is
just
to
like
give
these
kinds
of
tasks,
and
it
will
just
happen
kind
of
like
naturally,
it's
on
its
own,
so
that
definitely
works
as
well
and.
C
One
of
the
patterns
that
I
see
people
do
often
is
they
discover
as
they're
working
on
something
they
need
to
refactor
a
class
and
then
that
refactor
gets
pulled
in
to
add
a
feature
and
all
of
a
sudden
the
review
gets
more
than
twice
as
hard
in
comparison.
If
you
did
the
two
separately-
and
I
didn't
know
if
you
had
had
that
experience
as
well.
A
So
it
took
way
way
longer
to
review,
and
I
think
that
this,
maybe
you
know,
maybe
a
little
bit
signals
the
importance
of
having
mentors
as
much
as
possible
do
some
investigative
work
before
they're
assigning
their
tasks
to
different
students,
and
so
they
kind
of
have
a
rough
idea.
Obviously,
things
like
we
said
earlier:
there's
a
lot
of
unknowns
and
they're
going
to
go
awry
sometimes,
but
as
much
as
we
can.
If
we
can
plan
ahead,
that's
going
to
be
really
helpful.