►
From YouTube: Kubernetes Contributors Workshop
Description
The workshop will give you an overview of the Kubernetes community and how folks interested to contribute can start their journey. The attendees will learn about the structure of the community, the communication guidelines and how they can get involved in their areas of interest.
A walkthrough of the Kubernetes codebase will provide attendees a bird’s eye view of how the code is organized. We will then introduce the automation and tooling which helps Kubernetes contributors throughout their journey.
We will complete the workshop with a hands-on session where attendees will themselves file changes to the code.
Content : https://github.com/kubernetes-sigs/contributor-playground/tree/master/india/kcd-blr-2021#resources
A
B
Sure
I
I'm
happy
to
start
sorry,
everyone
really
nice
to
see
so
many
people
joining
early
in
the
morning.
I
still
feed
that
name
for
a
separate
early
and
yeah
really
nice
to
see
all
here.
So
I'm
assuming
most
of
you
all
are
here,
because
you
want
to
get
started
with
contributing
to
kubernetes
and
a
little
bit
about
how
I
got
started.
So
I
came
across
this
project
called
kubernetes
because
I
was
learning
go
at
the
time
and
I
saw
that
kubernetes
was
the
biggest
project
and
it
was
a
student
there.
B
B
I
applied
got
selected
and
I
worked
on
kubernetes
for
around
four
to
five
months
and
it
was
a
really
wonderful
experience
if
you
use
crds
before
so,
like
the
validation
design
and
like
the
status
of
the
scale
sub
resources
designed
for
cra.
So
that
was
what
I'd
done
during
my
internship
program.
I
really
enjoyed
it
like
during
the
internship.
It
wasn't
just
like
this
project
that
I
was
working
on.
Kubernetes
has
different
groups
as
well
as
I
was
getting
involved
with
release
testing.
B
There
was
a
group
called
contributor
experience
that
deals
with
automation
for
the
communities
project
and
making
sure
like
when
people
contribute
like
you
all
here.
They
have
a
good
experience,
so
I
was
also
getting
involved
with
that
and
then
luckily,
like
just
consistently
contributing
got
selected
as
a
technical
lead
for
that
group
contributed
experience.
I've
been
mainly
like
working
on
the
policy
and
the
automation
they
could
have
automation
for
the
kubernetes
project
other
than
that,
like
being
involved
in
the
api
side
of
things.
B
Crd
is
released,
testing
a
bunch
of
other
places,
keep
cpl,
and
so
on
and
later
I
realized
like
hey.
I
really
love
this
community
and
I
want
to
do
more.
So
I
also
like
applied
for
the
steering
committee
didn't
get
selected.
The
first
time
I
got
to
active
the
next
year
so
be
in
involved
in
like
governance
aspects
of
the
project,
so
yeah
that's
kind
of
it
and
like
I'm,
really
hoping
to
see
more
contributors
from
india
after
the
session.
C
Yep
thanks
for
the
thank
you
for
the
awesome
introduction,
so
hi
everyone.
I
am
navarro
and
welcome
everyone
this
morning
to
this
kubernetes
contributor
workshop,
thanks
all
for
giving
giving
like
four
hours
of
your
time
to
this
workshop
in
order
to
learn
how
you
can
start
contributing
to
kubernetes.
C
As
for
me,
I
started
in
the
kubernetes
community
around
two
years
back,
I
started
with
tinkerine
around
the
kubernetes
python
client,
primarily
on
the
basis
that
I
had
been
using
it
as
part
of
one
of
our
internal
products
and
we're
building
kind
of
a
passion.
It
was
a
natural
flow
to
improve
the
client
and
to
get
started.
How
do
you,
how
does
the
client
ecosystem
work
then.
C
G
Me
and
mother
were
fairly
new.
I
am
currently
in
my
second
year
of
college
and
I
got
introduced
to
the
community
through
a
program
called
linux
foundation
mentorship.
It
is
just
like
gsoc,
which
nikita
mentioned
but
yeah.
That
was
like,
I
think,
four
or
five
months
ago,
and
so
my
I
found
working
on
just
like
I
found
working
on
my
project
very
interesting,
made
friends
here.
So
I've
been
sticking
around
since
then
it's
a
lot
of
fun
yeah!
So
motherf
do
you
want
to
go
next.
H
Sure
so
this
is
sort
of
full
circle
for
me
because
I
started
like
my
journey
in
kubernetes
began
with
this
workshop
in
jan,
so
this
workshop
happened
in
jan.
So
that's
how
I
got
started
and
I
remember
like
there
was
so
much
happening
and
I'm
like
okay.
This
seems
really
cool,
but
also
anything,
but
these
people
seem
really
nice.
So
I
don't
know
they
might
be
open
to
helping
me
out.
So
I
went
and
joined
the
slack
and
things
were
things
just
worked
out
after
that
and
yeah.
H
So
since
then,
I've
been
trying
to
help
out
in
various
different
places.
Wherever
I
can,
I
mainly
try
and
work
on
like
the
node
and
api
machinery
side
of
things
I
haven't
been
able
to
too
much,
but
hopefully
soon
enough,
but
yeah,
and
that's
pretty
much
that's
a
little
bit
about
me
and
yeah.
I'm
a
student
as
well
currently.
A
A
It's
true,
it's
just
really
fun
to
you
know,
be
a
part
of
something
that's
bigger
than
your
academic
or
your
professional
career.
So
without
further
ado,
let
me
just
go
ahead
and
introduce
myself,
because
I
could
go
on
about
how
fun
the
community
is
for
like
another
50
minutes,
so
I'm
viviana
and
I
am
fairly
new.
I
like
to
think
of
myself
as
fairly
new,
because
I
joined
the
community
last
year
just
before
the
pandemic
began
and
turns
out.
A
It
was
perfect
timing
because
I
really
got
to
explore
the
of
the
community
that
I
was
interested
in
at
that
point
of
time.
So
I
started
my
contribution
with
you
know:
documentation,
edits
and
website,
blogs
and
stuff
like
that,
because
I
mean
it
was
not
technically
what
you
would
call
fourth
contribution.
A
A
Apart
from
that,
I
have
been
dabbling
in
bits
and
pieces
and
stuff
that
interests
me
around
the
community.
So
I
have
had
no
specific
area
of
contribution
where
I
actually
found
my
true
passion
and
calling
or
something
like
that.
I,
like
understanding,
why
are
dabbling
and
experimenting?
So
that's
that's
how
I
have
gone
about
learning
more
and
more
about
kubernetes,
because
it's
something
that
I'm
required
to
know
as
part
of
my
day
job
as
well.
A
A
So
it's
it's
just
fair
enough
that
I
actually
speak
about
the
community
and
how,
within
the
project,
we
are
organized
since
it's
a
large
project-
and
we
probably
already
know
that,
given
that
you
know
we
have
a
lot
of
contributors
depending
in
and
out
and
a
lot
of
sustained
contributors
chipping
in
so
how
is
it
organized
and
the?
How
is
the
project
functioning
at
a
very
high
level?
Is
what
we're
going
to
look
at
in
this
section.
A
So
the
kth
community
in
general
is
organized
into
various
subjects
because,
like
I
said
before,
we
have
a
lot
of
contributors.
I
think
I
I
might.
I
might
not
be
too
off
the
mark
when
I
say
that
we
have
around
50
000,
plus
contributions
coming
in
every
year,
so
it
is
organized
into
subgroups,
as
you
know,
one
being
the
special
interest
groups
and
then
the
next
one
being
a
working
group,
the
third
one
being
a
user
group
and
the
fourth
one
being
committed.
A
Now,
even
within
the
special
interest
group,
we
have
a
further
subdivision
known
as
a
subproject
and
we
shall
look
at
what
each
of
these
subgroups
so
to
say
are
responsible
for
or
what
aspect
of
the
you
know
tool
they
deal
with
that
sort
of
thing.
Now.
This
is
a
very
old
picture
and
I'm
sure
you
know
when
martha
saw
this
in
january.
He
he
probably
recognizes
this
photo,
because
this
was
the
exact
same
photo
that
we
use.
A
We
haven't
updated
it
for
a
while,
because
it
constantly
keeps
on
changing,
and
one
of
our
initiatives
is
to
actually
sort
of
get
this
done.
Get
our
have
an
automatic
update
done
as
and
when
new
committees
and
groups
are
added,
but
this
is
an
overall
view
of
how
the
kubernetes
project
is
organized.
Some
user
groups
working
groups
might
be
missing
here
and
there,
but
there's
a
good
representation.
A
So,
as
you
can
see,
the
staff
at
the
top
mainly
are
committees
in
the
orange
color.
The
six
that
is
special
interest
groups
are
marked
in
blue.
You
have
various
things
which
we
shall
go
through
in
the
next
in
the
next
couple
of
slides
and
then
there
are
also
working
groups
and
user
groups
that
are
highlighted
in
green
now,
since
this
image
was
published,
there
have
been
few
additions
to
all
of
the
you
know
subgroups
here,
so
we
I
have
updated
the
slides
to
reflect
that.
So
don't
be
worried.
A
A
So
that
being
said,
what
is
a
sick
or
a
special
interest?
Now,
like
you
know,
we
have
a
lot
of
contributors
and
it's
not
possible
humanly
for
a
project
to
be
sustainable
enough
with
the
amount
of
contributions
coming
in
every
year
and
having
no
sort
of
organization
or
no
sort
of
hierarchical
structure.
A
So
what
was
decided
in
the
communities
community
was
to
sort
of
have
special
interest
groups
that
is
sort
of
like
a
small
project
within
the
communities
project
itself
and
what
it
would
focus
on.
It
depends
upon
the
various
categories
that
you
know
we
have
so
that
brings
us
to.
You
know
the
various
categories
of
sigs,
which
one
of
them
is
the
feature
area
which
specifically
focuses
on
features
for
the
kubernetes
tool,
plumbing
which
basically
deals
with
the
overall.
A
You
know
tooling,
of
the
project,
then
there's
meta,
which
basically
covers
the
span
of
the
community,
but
is
not
sort
of
you
know
specialized
in
any
type
of
you
know,
feature
or
any
type
of
you
know
a
specific
area
of
the
state.
So,
for
example,
one
of
the
meta
six
that
we
are
going
to
look
at
is
the
sig
release,
which
I
am
part
of
and
nabru
has
been
part
of.
A
A
Then
of
course
we
have
dogs,
because
no
good
community
can
be
there
without
no
good
community
or
open
source
project
can't
function
effectively
without
documentation
right.
So
we
have
dogs
and
even
within
docs.
We
have
a
lot
of
you
know
sub
six,
if
I
may
say
so,
and
then
we
have
the
cloud
provider
six,
because,
obviously
you
know
kubernetes
is
a
product
that
has
been
turned
into
a
managed
service
with
many
cloud
providers.
A
So
we
have
that
as
well.
Now
these
are
examples
of
feature
area
6..
As
you
can
see,
there
are
quite
a
few
of
them
and
each
of
them
deal
with
this
different
feature
aspects
of
the
kubernetes.
Technically,
if
you
look
at
it,
I
think
signal
is
something
mother.
Is
you
know
a
part
of
and
there's
this,
then
this
sick
network
that
deals
with
the
network
aspects?
A
There's
almost
all
of
these
are
like
self-explanatory,
so
I'm
not
going
to
go
and
tell
you
what
everything
is
responsible
for,
but
if
you,
if
for
a
broadcast
every
feature
area
is
responsible
for
features
within
the
cooperatives
now
numbing.
Six,
like
I
mentioned,
deals
with
you,
know
the
overarching,
tooling
and
everything
else,
so
she
will
be
cluster
life
cycle
instrumentation.
Another
plumbing
figure
meta.
Six,
like
I
mentioned,
are
you
know
spanning
the
breadth
of
the
project
it.
A
A
You
know
delegated
to
one
specific
area
of
the
project,
so
contributor
experience
deals
with
you
know,
contributors
across
the
you
know
project
and
it
it's
basically
a
thing
that
is
responsible
for
a
lot
of
things,
not
that
that
that
is
not
limited
to
you
know
your
new
contributor
workshops
like
we
have
here.
We
have
stuff
like
the
mentoring
sub
project.
A
Irrespective
of
whether
or
not
it's
a
feature
or
a
plumbing
or
whatever,
at
the
sake
that
is,
then,
you
have
documentation
and
website
which
basically
deals
with
documentation
website
because,
like
I
said
before,
kubernetes
is
a
huge
open
source
project
and
it's
it's
a
given
that
we
require
a
lot
of
documentation
and
a
lot
of
good
documentation
for
the
whiteboard
adoption
of
the
project.
So
sig
docs
is
one
of
the
main
documentation
things
within
the
project.
A
A
Then
we
have
a
sub
section
and
I,
I
would
say
subsection
some
group,
maybe
of
syntax,
which
basically
deals
with
the
security
aspect
of
the
sake,
security
aspect
of
the
kubernetes
project,
and
it
is
responsible
for
the
documentation
of
all
the
security
features
and
ensuring
that
they're
as
up-to-date
as
possible
security
docs
is
another
one.
It's
a
relatively
newer,
safe
as
compared
to
the
other
ones,
but
it's
it's
there
and
is.
A
I
think
it
has
a
bi-weekly
call
on
on
thursdays,
not
sure
of
the
time,
though,
because
I'm
bad
with
time
zones.
Unfortunately,
then
we
have
cloud
providers
wherein
you
know
different
cloud
providers
are
some
projects
of
this
six.
So
this
this
slide,
like
runs
into
two
other
slides
here,
and
you
have
the
various
cloud
providers,
almost
all
of
them,
that
you
can
think
about
your
kali
baba
aws.
A
Ibm
openstack
vsphere,
so
all
of
that
is
there,
but
now
we
also
spoke
about
working
groups
and
sub
projects
right
as
other
sections
within
the
community.
So
what
are
they
now
in
some
in
some
areas
there
are,
you
know
particular
features,
or
particular
things
that
require
intersect
effort,
so
working
groups
are
formed
towards
collapse
towards
facilitating
that
interstate
collaboration.
A
Now
you
might
ask,
how
is
it
different
from
you
know?
A
meta
say
now:
metastage
is
basically
spanning
the
entire
bridge
of
the
project.
It's
not
it's
not
towards
I
mean
it
does
promote
industry
collaboration.
Everything
is
basically
focused
on
collaboration
here,
but
in
case
of
working
groups,
it's
focused
on
more
collaboration
between
two
or
three
states,
not
like
an
entire
breadth
of
the
community.
A
Now,
in
that
case,
what
is
a
sub
project
now,
if
even
within
six,
we
have
specific
focus
areas
right
so
in
in
a
separa
in
the
release?
Sig,
for
you
know,
instance,
we
have
a
focus
on
or
develop
developing
better
tools
for
improving
our
release
processes
and,
having
you
know
these
branch
management
areas
that
we
can
improve
on.
A
So
we
have
a
release
management
as
a
specific
sub
project
under
the
release,
sig
release
and
there
are
other
sub
projects
as
well
so
for
tools
we
have,
like
example,
cube
ctl,
cube,
three,
etc.
We
have
a
specific
sub
projects.
We
even
have
different
sub
projects
that
achieve
certain
goals.
So,
for
example,
we
have
like
the
computer
site
that
is
a
sub
project
within
the
contributes.
A
We
have
certain
areas
that
we
probably
want
to
target
within
a
particular,
so
machine
learning
is
another
sub
project
which
is
there
now.
These
are
the
different
working
groups
that
are
there
within
our
community,
and
each
of
these,
like
I
mentioned
before,
focus
on
interesting
efforts
and
two
or
more
six
are
know.
A
Now,
when
we
talk
about
user
groups,
which
is
the
third
category,
we
have
all
these
working
groups
and
special
interest
groups,
and
even
the
sub
projects,
having
focused
ownership
of
their
own,
you
know,
tooling
or
whatever
it
is
that
they're
trying
to
put
them,
but
in
case
of
user
groups
we
do
not
have
food
based
ownership.
It
is
just.
A
A
So,
at
the
top
of
all
of
this,
we
require
folks
who
can
sort
of
guide
us
and
deal
with
all
the
governance
stuff
that
is
sort
of
you
know
a
requisite
when
you
have
such
a
large
open
source
community,
and
even
if
you
do
not
have
you
need
somebody
to
take
care
of
the
governance
right,
you
need
to
have
people
setting
the
rules
and
regulations
and
stuff
like
that.
So
these
committees
are
there
that's
steering
security
response
and
code
of
contact.
A
A
You
know
introduction
speech,
so
she
had
sort
of
you
know
put
in
her
name
in
the
banner
for
one
of
the
elections
for
the
steering
committee,
and
I
don't
I,
I
think,
the
first
time
she
didn't
get
in
on
the
second
time
she
bought.
It
was
what
she
said,
but
the
gist
of
this
is
that
these
are
for
contributors
who
have
been
there
for
long.
A
A
A
So
if
you
obviously
this
is
a
very
intimidating
task
and
you
might
not
get
it
right
at
the
first
goal,
which
is
why
you
know
we
have
the
contributor
experience
slack.
So
you
can
definitely
ask
on
this
participant
and
we're
always
ready
to
help
out.
So
if,
if
not
at
the
same
contraband,
we
even
have
an
indian
specific
in
dev,
one
which
I'll
be
posting
the
link
to
in
the
next
couple
of
slides.
So
you
can
ask
us
there
as
well
and
but
not
at
this
particular
conference.
A
Maybe,
but
there
are,
you
know
at
coupon
and
all
the
other
conferences
that
we
have
new
contributor
workshops.
We
have
six
specific
intros
introductory
sessions.
You
can
go
there
and
you
know
sort
of
get
to
know
who
you
who
will
be
working
with
and
what
are
the
you
know
targeted
areas
and
join
that
sig
or
sub
project
directly.
A
Now,
if
so,
if
you're
joining
a
working
group
or
a
sub
project
also
join
the
corresponding
sale,
because
if,
if
you
are,
you
know
the
sub
project
or
the
working
group
is
always
aligned
with
a
specific
six,
so
it
makes
sense
to
sort
of
join
this
sig
signal
spell
now.
How
do
I
join
us
say
because
I've
been
speaking
about
how
to
figure
out
where
you
fit
in,
but
actually
joining
a
sake
is
a
totally
different
ballgame.
A
So
how
do
I
join
us
now
join
this
specific
mailing
list.
Now,
that's
that's
a
no-brainer,
but
again,
where
do
you
find
it?
Because
that's
that's
something
that
you
should
know
right,
because
the
mailing
lists
are
not
exactly
something
you
will
find
on
typing
it
out
on
google,
so
you
actually
need
to
understand
where
you'll
find
the
mailing
list.
So
that
is
what
I'm
going
to
be
showing
right
now
so
bear
with
me
as
I
switch
screens
and
stop
the
sharing
for
a
minute.
A
A
Okay,
so
if
you
can
see
here,
you
can
see
the
kubernetes
community
page
right.
So
if
if
in
that
page
you
can
see,
there
are
a
list
of
the
various
things
that
are
there
within
the
project.
So
you
have
six
cli
cigar
scaling.
You
even
have
the
committees
which,
basically
you
cannot
join
without
an
invitation,
so
you
have
the
committees
as
well,
and
you
have
all
the
actual.
A
You
know
organizational
subgroups
within
this
page
and
each
of
these
organizational
subgroups
basically
has
their
own
chart
or
their
readmes
and
everything
where
you
can
find
the
respective
information
on
how
to
join
a
mailing
list.
So,
for
example,
I'm
just
going
to
go
to
signal
because
that's
something
I'm
not
part
of-
and
if
you
can
see
here
there's
this
is
relevant
to
the
node
special
interest
group.
You
have
the
regular
meeting
when
it
is
scheduled
and
you
have
the
meeting
notes
and
agenda
linking
floor.
A
A
That's
it
that's
as
simple
as
that.
You
just
have
to
join
the
group
and,
of
course,
if
you
actually
do
want
to,
you
know,
participate
in
conversations.
We
have
this
slack
channel
as
well.
Mailing
lists,
are,
you
know
for
discussions,
long-form
discussions,
but
if
you
want
to
have
you
know
using
conversations
over
a
particular
thing,
slack
is
your
best
bet.
A
A
A
So
before
that,
you
know
it's
absolutely
important,
that
you
know
that
everything
every
single
thing
that
we
speak
about,
whether
it's
on
the
mailing
list,
whether
it's
on
your
slack
or
whether
it's
even
on
the
meetings,
it's
governed
by
the
kubernetes
community
code
of
conduct,
which
basically
boils
down
to
be
nice
to
each
other.
I
mean
you
do
not
want
to
be
at
the
receiving
end
or
at
the
giving
end
of
abusive
behavior
or
harassing
language,
because
that's
that's
just
not
nice
right
as
humans.
A
We,
we
wouldn't
expect
that
to
be.
You
know
done
to
us,
so
why
would
you
do
it
to
anybody
else?
So
kubernetes
community
code
of
conduct
underlies
all
our
communications
and
you
basically
have
to
abide
by
it.
If
you
are,
you
know
a
part
of
any
of
the
meetings
or
conversations
within
the
avenues
that
I
spoke
of
before
so
given
the
number
of
people
and
given
the
number
of
time
zones
companies,
not
maybe
not
even
companies,
professional
levels
that
we
are
working
at,
we
have
a
lot
of
avenues
to
keep
in
touch.
A
So
how
do
we
do
it?
So
first,
of
course,
is
the
mailing
list,
which
I
just
showed
you
it's
it's
it's
a
good
form
of
you
know
discussions
and
you
know
to
basically
go
back
and
forth.
You
know
something
that
requires
consensus
for
more
immediate
forms.
We
have
slack
and
zoom
zoom
is
when
you
obviously
have
obviously
a
requirement
for
in-person
communication.
So
that's
that's
when
that
comes
into
place
and
slack
is
again
an
ascent
form
of
zoom
so
that
you
know
where
you
have
that
feeling
of
staying
connected.
A
A
We
haven't
reached
there,
yet
we
are
imperfect,
but
we
are
trying.
So
what
are
some
of
the
async
initiatives
within
the
community
have
been
highlighted
here
so
in
the
sick
quantum
x
like
we
try
to
alternate
between
slack
threads-
and
you
know,
fortnightly
zoom
meeting
so
that
everybody
has
the
chance
to
contribute
in
case
they
cannot
actually
attend
the
zoom
meeting
there
are
in
even
within
the
release
team.
A
When
we
have
meetings
we
have
apac
friendly
timings
separately,
scheduled
for
those
joining
in
from
the
other
side
of
the
globe.
So,
for
example,
for
this
cycle,
we
have
the
impact
friendly
or
release
team
meeting
today
evening
at
7
30
p.m.
Istion,
it's
it's
a
recurrent
one
across
the
particular
cycle.
A
So
it
helps,
but
obviously
sometimes
it
helps
to
also
have
that
in-person
interaction,
because
otherwise,
how
do
you
actually
know
and
put
a
face
to
the
name
that
you've
been?
You
know
emailing
and
stacking
with
for
so
much
so
sometimes
yes,
it's
good
to
have
meetings,
but
we
try
and
keep
most
of
our
conversations
just
like
that
now,
because
I've
said
all
of
this,
you
might
think
that
we
are
purely
a
boring
community
parent.
A
We
just
you
know,
talked
about
really
of
technical
stuff
and
we
know
it
out
over
code,
but
that's
not
really
the
case.
We
try
to
spice
up
our
meetings
a
little
bit
sometimes,
and
this
is
like
a
clear
picture
of
how
we
try
and
have
our
fun
even
when
doing
work.
So
this
is
the
this
is
like
one
of
the
meetings
that
happened
not
recently,
of
course,
because
it
was,
it
was
a
little
bit.
I
think
it
was
in
2019,
I'm
not
sure
but
yeah.
A
That
being
said,
that's
that's
a
you
know,
meeting
that
was
really
fun
and
when
we
talking
about
slack,
we
really
wouldn't
want
you
to
leave
your
emoji
game
behind
and
we
have
like
a
really
huge
huge
list
of
emojis
on
slack.
So
please,
please,
please
don't
talk.
You
know.
I
think
that,
because
we
are
all
you
know,
working
towards
or
delivering
a
software,
you
have
to
be
really
serious
and
cook
or
see
this
gaps
on
and
work.
A
You
do
have
to
do
that,
but
you
also
have
to
ensure
that
you
have
fun
and
you
bring
in
your
own
individual
piece
of
jazz
with
you,
so
we
have
a
lot
of
emojis
feel
free
to
use
them
and
for
all
those
who
joining
from
india,
I'm
I'm
sure
most
of
us
are
because
this
is
too
late
for
the
us
too
early
for
the
uk
and
india
is
like
the
only
timing
right
now.
That
is
perfect.
A
So
if,
for
indian
specific
folks,
you
I'd
request
you
to
join
the
slack
the
step,
that's
the
link
is
giving
you
step
one
to
find
the
in-depth
in
users
and
in
events
channels
on
slack,
say,
hi
and
introduce
yourself
and
use
normal
emojis,
and
we
promise.
We
won't
show
you
if
you
use
too
many
emojis
really
I
mean
we
expect
you
to
use
emojis,
and
this
is
basically,
I
guess,
mother's
first,
so
mother,
here's
your
claim
to
fame.
A
A
B
B
B
B
B
So
there
are
a
lot
of
repositories
of
google
at
the
inside
and
it
can
be
confusing
like
one
of
the
biggest
questions
that
people
always
ask
us
is
like
which
repository
do
I
contribute
to?
Is
it
like
the
main
kubernetes
repository?
It
has
two
thousand
open
pr's
and
two
thousand
open
issues
like
almost
hundreds
of
other
people,
so
which
one
do
we
work
on.
I
we
actually
have
a
ton
of
slides
about
this,
but
I
might
just
like
bust
through
them,
and
I'm
just
going
to
show
you
things
on
github.
B
So
there
are
a
few
project-based
repositories
so,
like
we've
talked
about
the
kubernetes
community
repository
a
lot.
So
if
you
want
to
find
out
which
six
there
are
in
the
project
or
what
are
the
mailing
lists,
what
are
the
slack
channels?
Here's
where
you
go
to
I'm
going
to
talk
about
the
enhancement
stream
bit.
B
We
have
one
main
repository,
so
that's
kubernetes,
so
one
more
thing
since
we
talked
about
kubernetes
most
of
the
time,
we
don't
want
to
keep
saying
kubernetes
every
single
time
when
we
refer
to
repository,
so
we
usually
just
shorten
escape.
So
when
we
say
k
website,
it
means
github.com
kubernetes
slash
website,
and
then
you
have
another
developer
tools
related
things
so,
like
you
have
if
you
worked
on
controllers,
so
you
know
that
there's
this
repository
called
sample
controller,
which
has
an
example
for
how
to
write
controllers
code
generators.
B
I
mean,
if
you've
written
clients
or
controllers
or
done
basically
anything
on
top
of
like
written
tools
on
top
of
the
kubernetes
api.
You've
probably
interacted
with
the
quality
score
generator.
So
there
is
one
project
about
that
as
well.
Staging
repositories
I'm
going
to
cover
it
a
little
bit
later,
but
just
keep
in
mind
that
there
is
something
called
station
repositories,
and
this
is
very,
very
important
to
the
kubernetes
project
and
we'll
see
why
and
what
that
means
later.
B
We
have
six
repositories.
I
will
not
cover
all
of
them,
but,
like
we
talked
about
six,
so
each
same
one
is
a
set
of
repositories
so
really
like
release
the
release.
One
federation
is
owned
by
sigma,
multi-cluster
and
so
on
cloud
provider.
Repository
is,
if
you
work
on,
you
have
experience
on
a
particular
cloud
provider
and
you
want
to
contribute
only
in
that
direction.
This
is
where
you
look
at
products
and
tools
like
we
talked
about
cube
cpl
in
the
chat
just
right.
Now
we
have
that
dashboard
mini
cubes.
B
B
In
the
kubernetes
github
oil
we
just
have
the
main
kubernetes
project
and
some
more
projects
surrounding
it.
So,
like
anything
that
encompasses
not
just
one
sick
but
multiple,
six
that
usually
goes
there.
So
if
you
want
to
contribute
to
the
main
kubernetes
project,
that's
where
you
look,
but
nowadays
most
of
the
development
that
we
do
happens
in
the
kubernetes
6
github
organization.
So
we
have
slightly
less
scoped
repositories
over
there.
B
So
if
you
want
to
contribute
like
a
cube
builder,
some
written
controllers,
you
know,
there's
this
project
called
what
kind
or
I'm
just
like,
lacking
all
the
names
right
now
but
they're
like
I
think,
100
or
900
repositories
over
there.
So
take
your
pick
go
see
which
things
you
like
want
to
contribute
to.
I
can
actually
show
you
how
you
can
look
through
that.
B
So
when
you
go
to
kubernetes,
you
have
130
repositories
over
here,
which
are
a
lot,
but
just
one
thing
I
want
to
call
out,
I
won't
go
over
every
one
of
them
is
that
each
repository
has
this
topic
labeled
over
here.
So
if
you
say
kate,
say
cluster
like
so,
if
you're
interested
in
only
the
repositories,
that's
a
cluster
lifecycle
loan.
So
you
click
on
this
cluster
lifecycle
and
it
will
show
you
all
the
kubernetes
repositories
that
cluster
lifecycle
has.
B
Similarly,
you
can
do
it
for
whatever,
if
you're
interested
in
cli
or
epm
machinery,
which
is
a
very
popular
thing,
you
can
look
into
that
storage
networking,
whatever
area
you're
interested
in
right.
So
look
through
those.
So,
for
example,
in
kubernetes
alone
we
have
130
of
them.
There
are
a
lot
of
members
too.
So,
like
there's
a
lot
of
activity
that
goes
on
in
the
kubernetes
project,
so
I'd
definitely
say
that
you
know
nowadays
a
lot
of
activity
happens
here.
B
B
If
you
want
to
start
small
kubernetes
depository
essay,
because
it
has
slightly
less
number
of
contributors
and
you
can
get
like
dedicated
mentorship,
I
mean
you
can
get
even
in
kubernetes
but
like
you
can
have
a
dedicated
communication
channels
with
small
set
of
contributors.
So
that's
pretty
much
all
I'd
say
about
the
tour
of
repositories.
I
want
to
keep
it
very
quick,
we'll
take
a
small
break
right
now:
go
have
your
coffee
or
breakfast
and
then
we'll
join
in.
I
guess
10
minutes
later.
B
B
A
A
D
B
B
F
All
right
looks
like
nobody's
going
so
I'll
go,
I'm
akash,
I'm
from
bangladesh.
I
have
met
navaron
over.
I
think
a
python
talk
someday
and
we
connected
on
linkedin.
So
that's
how
I
know
him-
and
I
saw
this
workshop
coming
up.
I
was
already
interested
in
kubernetes
but
didn't
know
where
to
start
off,
so
this
seemed
like
a
great
start.
So
I
just
signed
up-
and
you
said
you
said
what
am
I
looking
for-
I'm
actually
looking
for
a
billion
dollars,
but
I
doubt
I'll
find
it
here.
B
C
G
I
J
Hey
guys,
this
is
rebor
here,
I'm
based
out
of
pune
I've
been
I've.
I
really
wanted
to.
You
know:
do
some
sort
of
contribution
to
open
source
community,
because
all
my
experience
as
an
id
profession,
I've
been
pulling
information
from
them
using
stack
overflows
and
google's
and
everything
to
all
those
things.
So
it
is
just
a
token
of
appreciation.
J
As
soon
as
I
can,
and
I'm
really
looking
forward
for
the
client
stuff,
I
mean
the
very
specific
on
technical
aspect.
I'm
really
looking
forward
for
the
kubernetes
client,
with
various
languages
specific
to
python
and
javascript,
and
on
the
on
the
other
side.
I
really
find
very
intuitive
was
about
the
nodes
itself
and
the
kubernetes
node.
So,
looking
forward
on
those
aspects,
thank
you.
D
C
K
Hey
everyone.
I
am
rohan
before
I
say
anything,
just
a
big
shout
out
to
the
team
behind
the
kubernetes
docs,
so
to
get
a
proper
understanding
of
how
kubernetes
works.
So
I
sort
of
started
reading
the
whole
concepts.
You
know
that
particular
section
and
I
read
it
completely
and
I
I
can
say
that
you
know
it
is
so
very
well
written
and
organized
that
you
know
it.
It
became
a
good
starting
point
for
me
to
understand
kubernetes.
K
So
I
have
been
writing
minor
code
right
to
just
understand
how
the
control
controllers
work
and
pods
work.
You
know
I
saw
a
2018
kcd
mumbai.
You
know
youtube
video,
where
you
know
I
got
to
understand
like
how
you
can
call
the
api
and
everything,
but
you
know
right
now.
I
my
interest
lies
in
the
api
api.
Auto
scaling.
Sorry
right!
So
you
know
I
am
trying.
I
am
kind
of
stuck
in
the
like
yeah.
K
I
know
the
basics:
how
how
to
call
the
api,
but
I
want
to
venture
forward
so
for
a
beginner
like
me,
you
know
how
do
I
do
that
and
one
more
good
thing
that
I
found
the
cuban
it
is
community
repo.
Whenever
I
was,
you
know,
stuck
like
how
to
find
a
particular
answer
to
a
particular
question,
so
kubernetes
community
repo,
you,
you
know,
always
helped
me
and
I
signed
up
for
a
mentorship
program
as
well,
but
so
far
you
know.
B
K
So
I
I
have
I
so
I
just
joined
the
auto
scaling
sig,
okay,
because
I
that
is,
I
find
that
yeah.
That's
my
area
of
interest
right
and
I
started
you
know
compiling
the
binary.
You
know
cube
cuddle
and
try
I
so
what
what's
happening
is
yeah.
I
know
where
the
api
auto
scaling
api
code
results
right.
I
am
trying
to
find
my
way
to
debug
that
particular
code,
so
that
debugging
process
is
a
little
bit
difficult
for
me.
B
It
looked
pretty
good
like
even
for
the
actual
score
base.
So
that
could
be
one
thing
I
mean
if
you're
looking
specifically
for
deepaki,
but
if
you're
looking
for
like
diving
into
code
on
a
particular
thing
actually
just
say
the
feature
to
this,
because
lots
of
sims
also
do
like
code
based
walkthrough
kind
of
a
thing.
So
if
it's
called
base
understandable.
I
C
B
B
So
let's
actually
understand
how
features
get
added
with
these
projects
right,
like
that's
an
important
thing
features
we
all
care
about
that
most
folks
are
familiar
with
the
usual
workflow
for
open
source
projects.
So
if
you
want
to
add
a
feature,
the
common
steps
are
usually
to
get
her
issue
for
a
feature
request.
B
Another
implementation
in
a
full
request
right,
you
should
pull
requests,
but
one
key
thing
that
comes
before
all
of
this
is
the
design
of
the
feature,
along
with
thorough
considerations
of
the
implications
of
the
change
that
the
future
would
bring
in,
and
these
implications
become
really
important
for
a
big
project
like
kubernetes
and
this
design
phase.
That's
why
it's
a
very
big
thing
in
kubernetes
to
the
point
that
we
actually
have
a
new
name
for
it.
So
we
call
it
caps
or
kubernetes
enhancements
proposal
kep.
B
It
is
essentially
a
design
document
that
is
a
way
to
like,
propose
or
communicate
and
coordinate
efforts
with
different
people
on
new
efforts
in
the
kubernetes
project.
So
if
you
want
to
create
any
feature,
you
write
a
gap,
and
this
is
if
you've
like
been
if
you've
hung
out
in
the
kubernetes
project
or
the
upstream
community.
B
You
might
have
heard
this
name
a
lot,
and
this
is
a
very,
very
important
part,
so
it's
like
crucially
understand
what
caps
are
and
how
to
find
them
and
what
to
do
with
them
so
how
to
find
them.
So
you
can
find
all
of
these
proposals
in
a
repository
called
kubernetes
enhancements
and
if
you
frequently
hear
it
being
referred
to
as
the
enhancement
report,
so
people
will
be
like
have
you
looked
at
this
captain
enhancement,
people
things
like
that,
so
people
say
enhancement
repo.
B
B
B
If
you're
changing
like
small
test
fixes
code
refactoring
that
are
generally
not
surface
to
you,
the
users,
they
don't
have
to
go
through
the
cab
process.
There
are
exceptions,
of
course,
for
example,
if
you're
changing
the
github
automation
for
the
project
that
affects
contributors,
but
maybe
not
users,
it
still
needs
to
go
through
the
process,
but
since
this
means
that
we
have
like
a
very
detailed
document
for
most
big
features,
these
documents
also
end
up
being
very
useful
for
learning
about
the
internals
of
communities.
B
So
if
you
want
to
learn
more
about
kubernetes,
definitely
look
for
gaps,
kept
skip,
skip,
skip
skips,
I'm
going
to
keep
repeating
this
a
thousand
times
like
caps
are
very,
very
important
and
for
this
reason
exactly
martha
I
know
we
will
like
reflect
to
buy
them
a
lot,
but
he's
been
doing
really
amazing
work
across
the
project.
He
started.
A
new
initiative
called
a
kept
reading
club,
which
is
similar
to
like
a
book
reading
club
and
it's
a
great
way
to
get
more
context
and
background
and
why
a
feature
was
written.
B
The
way
it
was
most
of
us
know,
like
you,
can
figure
out
how
a
feature
works
by
looking
through
the
documentation.
You
can
even
figure
out
how
it
works
by
looking
through
the
code,
but
the
why,
behind
it,
not
the
how
and
the
what
the
why
behind
it?
Why
was
it
written?
The
way
it
was
is
usually
not
I
mean
it
should
be
written
in
like
code
comments
or
something,
but
sometimes
it
just
doesn't
get
surfaced
there.
B
So
this
is
all
present
in
a
cap
and
that's
why
I
would
clearly
suggest
you
all
to
look
through
caps
and
reach
out
to
motherhood.
If
you
are
interested
in
this,
this
is
also
an
actually
india
friendly
time.
So
I
think
it's
around
8
p.m.
On
mondays
is
that
is
that
right,
mother,
when
is
the
cap
reading
class.
B
Okay,
so,
like
now,
you'll
have
like
one
action
item
to
take
forward
like
if
you
want
to
know
why
a
feature
was
written.
The
way
it
was
find
the
gap
which
I'll
tell
you
like
in
a
minute
how
to
find
the
cap
just
take
the
link.
Let
martha
know
that
you're
interested
in
this
and
then
you'll
figure
out
the
rest,
and
you
can
just
join
the
meeting
and
participate
and
like
and
discuss
it's
more
like
a
reading
club
kind
of
thing.
So
you
just
discuss
it's
not
like
someone
presenting
it
to
you.
B
B
There
is
a
very
handy
kept
package
in
here,
capsule
actually
in
here,
and
gaps
are
also
organized
depending
on
sex.
So
finally
get
some
api
machinery
caps,
here's
where
you
go
and
sigma
d
cluster
you
have
there
you
go.
I
see
a
question
which
says
on
the
calendar
invites
for
this.
Yes,
if
you
join
the
stick
architecture
mailing
list,
you
should
get
a
calendar
and
fight
with
my
life,
probably
yeah
so
yeah
so
sick
directories.
I
am
going
to
very
selfishly.
B
D
B
Can
you
find
in
a
cap
there's
this
yaml
file
called
cap.yaml
for
each
cup?
We
use
yaml
everywhere
we're
going
to
use
some
yama
here
as
well.
There's
this
like
title
and
all
of
that
who's,
the
author
of
the
cap,
which
is
the
owning
sick.
Where
and
there's
a
status
which
says
whether
the
cap
is
implementable,
it's
already
been
implemented,
it's
still
in
discussion.
There
are
different
names
for
the
status,
which
I
don't
remember
exactly
what
they
are,
but
that's
like
status,
who
reviewed
the
cap
who
approved
the
cap.
B
I
actually
like
this
part
a
lot,
so
it
says
see
also
so
it's
just
references
to
links
that
are
they'll,
give
more
context
behind
the
discussions.
If
you
like
go
to
this
link,
you'll
find
a
mailing
list
said
about
why
this
feature
request
came
about,
and
this
is
also
pretty
important.
So
what
stage
is
it,
and
so
you
have
features
that
are
alpha
beta
and
ga
and
which
kubernetes
version
is
it
targeting
so
like
for
1.22?
This
is
going
to
be
an
alpha
phase,
so
it
says
alpha,
1
or
22..
B
If
there's
it's
like
a
beta
thing,
there'll
be
another
failure
which
will
say
beta1.23
or
something
so
the
kept.yaml
file
is
a
very
good
way
to
understand,
which
stage
is
the
captain
who
wrote
it
like
metadata
about
it?
Now,
let's
come
to
the
main
cap,
the
table
of
contents
usually
looks
similar
for
almost
each
of
the
cats.
So
you
have
summary:
what
is
it
about
motivation?
Why
are
we
doing
this
in
the
first
place?
B
This
is
I
actually
like
this
portion
a
lot
too,
because
it
tells
you
why
I
mean
we
know.
Okay,
fine
xyz
features
works
like
this.
Why
was
this
brought
about?
What
was
the
problem
behind
it?
Like
the
history
of
the
context,
is
pretty
useful
goals.
What
are
we
trying
to
do
non-goals?
What
are
we
not
trying
to
do
proposal
is
the
exact
thing
that
we
are
proposing,
and
you
also
have
to
include
like
test
plans,
some
constraints
and
caveats
that
you
have
another
very
important
thing
in
a
clip.
B
B
It's
a
questionnaire,
so
we
have
a
set
of
questions
around
just
making
sure
that
your
future
is
ready
for
production,
so
it
has
quite
like
if
most
of
these
questions
are
not
relevant
for
this
kept
but
like
how
can
this
feature
be
enabled
or
disabled
in
a
live
cluster?
How
can
you
do
a
rule
out
and
like
what,
if
you're
doing
an
upgrade,
how?
How
does
that
work
like?
How
do
you
roll
back?
What
was
the
upgrade
path
tested
monitoring
dependencies?
B
How
does
it
scale
things
like
that
and
implementation
history,
and
another
part
I
like
most
about
caps-
is
the
alternatives
because
see
over
here?
If
you
see
like
the
four
alternatives
to
turn
down,
so
we
went
through
multiple
proposals
and
then
we
discarded
some
of
them
and
just
said
okay.
This
is
not
going
to
work
because
of
whatever
is
it's
right
so,
like
you
can
figure
out
the
context
behind
a
bunch
of
them
in
so
gaps
are
very,
very
useful
documents,
and
that's
why
we
have
like
reading
club
surrounding
it.
B
I
mean
if
there's
one
thing
you
get
out
of
this:
go
to
the
studio
club
for
sure
so
yeah
like
it's
pretty
useful.
Definitely
look
through
caps
that
you're
interested
in.
If
you
choose,
whichever
stick
you
want
to
choose,
go
through
them
read
a
document.
If
there's
a
feature
you
like
reach
out
to
madhav
and
then
we
can,
we
can
also
invite
the
authors.
So
let
me
sometimes
do
that
or
invite
authors
or
reviewers
of
the
cap
to
talk
about
what
went
on
when
they
wrote
it
cool.
B
In
yeah
so
kubernetes
communities,
this
is
a
huge
repository,
so
most
people
get
super
intimidated
when
they
look
at
this
there's
so
many
packages.
There
are
so
many
directories.
I
don't
know
where
to
look
at
and
if
you
sometimes
look
at
it,
it
feels
the
code
is
duplicated
in
a
lot
of
places.
It
is
not.
B
We
will
look
into
why
that
feels
like
that
sometimes
and
yeah,
let's
just
typewriter,
so
I'm
going
to
cover
a
few
directories
in
this
session,
so
the
command
directory
cmd
docs,
is
pretty
self-explanatory,
hack,
we're
going
to
talk
about
package
and
staging
and
test
so
first,
let's
just
look
at
the
command
directory,
so
the
command
directory
contains
the
main
functions
of
various
binaries
that
we
have,
when
I
say
binaries
like
cube,
ctrl
cube
aps
our
controller
manager.
If
you
want
to
understand
the
entry
point
for
these
binaries,
it's
all
yours.
B
B
Next,
let's
look
at
the
hack
directory
so
hack.
There
is
a
lot
of
hacky
scripts,
so
it's
mostly
bash
and
python.
A
lot
of
bash
actually
and
unfortunately,
a
lot
of
cash,
so
you'll
notice,
like
if
I
just
keep
scrolling
down
you'll,
see
that
there
are
a
lot
of
scripts
which
have
the
update
prefix
right.
So
like
update
culture
and
update
performance
iron,
update
generated
a
ton
of
files,
verify
verify
all
verify.
Api
groups
verify
bazel
blah
blah
blah
blah
blah
blah
like
update
and
verify.
B
Why
do
we
have
these
prefixes?
So
kubernetes
has
a
lot
of
auto
generated
code,
so
we
write
code,
but
we
also
auto
generate
code
like
automatically,
so
these
scripts
are
basically
used
for
generating
quotes.
If
you
do
hack
update
good
gender
research,
it
does
some
amount
of
auto
generation
of
code.
Then
you
have
update
generated
docs
which
under
documentation
and
things
like
that,
if
you
do
update
all
it
will
run
all
of
the
update
script.
B
So
whenever
you
are
like
change
making
any
change
to
the
kubernetes
code
base,
you
will
need
to
update
some
code
or
the
authorization
some
of
these
update
scripts,
which
update
scripts
to
run
comes
with,
like
you
will
get
to
know
that
with
practice,
so
you
don't
need
to
know
like.
Oh,
the
script
is
for
this
reason,
nothing
like
that.
You
can
run
the
update
all
script,
but
it
takes
a
very
long
time.
So
I
usually
just
let
the
kubernetes
see
I
do
the
works
I'll
open.
B
If
I
don't
know
which
scripts
I
need
to
upgrade
I'll,
just
open
the
pull
request.
The
ci
will
fail,
like
it
will
say,
like
you
need
to
update
these
scripts.
You
can
just
do
that
with
practice,
though
you
will
come
to
know
that.
Okay,
fine,
if
I
change
some
part
of
the
code
that
requests
code
generation,
I
just
need
to
use
this.
One
verify
does
pretty
similar
thing
so
for
each
almost
for
each
update
script,
you
will
have
a
corresponding
verify
script.
B
So
if
you
do
upgrade
open
api,
spec
there'll
be
a
verify
open,
ap
aspect,
so
just
to
verify
whatever
you've
updated,
is
correct
or
not.
Don't
need
to
worry
too
much
about
these,
but
just
have
an
idea
that
there's
something
called
as
an
update
and
a
verify
script.
There
are
also
pretty
other
handy
scripts
and
I'll
just
call
out
two
of
them,
which
are
pretty
useful.
B
So
if
you
want
to
install
fcd
on
your
system
at
the
correct
version
that
kubernetes
master
branch
or
whichever
branch
you're
working
on
requires,
you
can
use
the
installation
script,
it
will
just
automatically
install
lcd
the
correct
version
for
you.
This
is
like
the
most
important
scripter
file,
local
app
cluster.
So
if
you
are
making
any
changes
to
the
kubernetes
code
base
and
if
you
want
to
create
a
cluster
with
those
changes,
you
can
use
the
script,
so
it
will
create
a
single
node
cluster
for
you
and
you
can
play
around
and
test.
B
However,
you
like
so
the
hack
directory
lots
of
bash
lots
of
ci
scripts
involved
and
helper
scripts
to
help
you
create
a
cluster.
Now,
let's
go
on
to
the
package
directory
package.
Historically,
almost
all
of
kubernetes
code
was
in
the
package
directory
later.
We
realized
that's
a
lot
of
code
in
a
single
directory.
It's
becoming
too
huge
of
a
monolith,
let's
break
it
down,
so
we
moved
some
of
this
code
into
other
repositories
or
other
directories,
but
a
significant
chunk
of
it
still
remains
in
package.
B
B
So
if
you
want
to
know
about
deployment
controller,
the
new
space
controller,
the
garbage
collector
garbage
collection
controller,
how
does
that
work?
All
of
it
is
here.
This
is
pretty
useful
if
you
want
to
understand
the
business
logic
behind
how
these
controllers
work
business
logic
behind
how
a
deployment
works.
So
all
of
all
of
this
goes
in
the
controller
directory
really
really
useful
to
understand.
B
So
if
you're,
just
like
looking
to
even
understand
kubernetes
I'd,
say,
take
a
look
at
this
directory
for
sure
we're
gonna
come
for
to
package
aps
and
updates.
So
just
keep
this
open.
We're
gonna
look
at
staging
next,
so
staging
is
a
pretty
funny
interesting
directory.
So
you
have
this
thing:
called
soul
structure
start
io,
and
you
have
a
lot
of
detectors
here.
These
are
actually
this.
Okay.
The
code
over
here
is
copied
to
some
other
place.
Why
do
we
do
this?
B
If
you've
written
code
on
top
of
kubernetes
you've
probably
used
the
kubernetes
client?
So
you
use
kubernetes
client
code,
so
you
see
code
over
here
and
you
think,
okay,
so
we
add
code
directly
in
this
repository,
but
that's
not
the
case.
We
add
code
in
the
staging
directory
and
abort
copies
code
from
the
staging
directory
to
this
kubernetes
client
board.
B
You
likely
won't
need
to
care
about
the
copying
of
it
or
like
the
mechanics
behind
it,
but
it
is
pretty
important
to
understand
because
staging
there's
a
lot
of
code
in
staging
and
understanding
how
staging
works.
Why
do
we
have
a
stage?
Room
directory
is
pretty
crucial.
It's
a
very,
very
important
part
of
how
the
code
is
organized
in
communities,
so
you
have
station
directories.
So
one
of
the
question
that
comes
up
is
like:
why
are
we
doing
this
whole
added
effort
of
copying
code
from
staging
to
another
repository?
B
The
main
reason
is
because,
if
you
want
to
import
client,
if
you
are
a
third
party
consumer,
if
you
want
to
import
client
code,
will
you
if
you,
if
you're
using
the
staging
directory
you'll,
have
to
import
the
whole
kubernetes
repository
and
that's
a
lot
of
code?
You
don't
want
that
much
code,
you
just
want
client
go
portion
of
it,
so
we
copy
code
into
another
repository,
so
you
can
just
import
the
smaller
one.
B
So
it's
just
to
break
down
and
make
sure
like
people
who
are
consuming
kubernetes
are
not
importing
a
huge
chunk
of
code,
so
you'll
find
pretty
much
all
that's
like
cube.
Cpl
main
code
is
here:
we've
talked
about
that
in
the
chat
for
a
bit,
so
the
cube
cpl
is
over
here
code
generator.
Is
your
client
voice,
your
api
server
apm
machinery?
So
that's
the
main
glue
code
that
holds
the
api
together
and
the
api.
So
let's
go
to
that.
So
this
is
direct
call
api
you'll
find
all
the
api
groups
here.
B
Now,
if
you
go
to
package,
apis
you'll
find
a
lot
of
these
directories
here
and
if
you
start
looking
at
like
what
what
is
in
here
right
like
I
won't
go
into
detail,
but
just
something
that
confuses
a
lot
of
people
apps,
you
go
type
start
profile,
okay,
right
and
then
you
see
a
stateful
set
struck
here.
Okay,
I'm
gonna
do
the
same
thing:
apps
in
the
station
directory
apps,
v1
types,
dot,
co,
a
stateful
site,
struct
here
as
well
other
two
stateful
substrates
and
two
different
packages.
B
If
you
actually
notice
that,
like
more
of
these,
what
is
happening
here?
Why
is
this
like
two
like
by
the
two
or
more
files
for
the
same
piece
of
code?
So
kubernetes
has
this
concept
of
internal
and
external
types.
Since
you
have,
you
can
have
different
versions
of
the
same
pieces.
You
can
have
stateful
set
v,
one
v,
one
beta
one
v,
one
beta
two.
B
We
will
also
need
to
convert
between
versions,
differential,
backward
and
forward
compatibility.
So
there's
a
lot
of
conversioning
that
happens
between
v
one
to
v,
one
beta
one,
and
we
will
beta
two
here-
p:
two.
We
won't
be
v
one,
so
some
of
them
so
to
and
this
conversion
can
conversion
systems
can
grow
a
lot.
When
you
have
a
lot
of
versions
to
make
it
easier,
we
have
a
hub
version
called
the
internal
version,
so
the
internal
version
lives
in
package
directory.
B
So
if
you
go
to
package
apis
app
types,
it's
internal
version
and
for
each
external
version
it
will
be
in
the
stage
introductory
so
apps
v,
one
v,
one
beta
two
v,
one
beta
v,
one
beta
one-
and
we
would
do
so.
You'll
have
external
versions
here,
so
these
are
copied
out
to
another
repository
that
you
can
import.
So
you
can
always
import
external
versions.
You
can
never
import
the
internal
version.
You
should
never
care
about
the
internal
versions,
internal
right.
So
that's
in
the
package
directory.
B
If
you
didn't
follow
any
of
this,
that's
okay,
I
think,
like
codebase
walkthroughs
work
best
as
a
recording,
so
I
hope
it
could
be
useful
like
when
you
refer
the
stack
again,
but
this
is
also
like
very
important
to
understand
because
it
gets
very
confusing
when
you're
working
through
currency,
the
same
code
like
infusing,
is
duplicated
in
a
lot
of
places,
but
it
actually
is
not
anyway.
So
let's
go
on
to
the
final
directory
test,
so
we
always
have
to
test
a
code.
B
We
have
three
types
of
tests:
unit
tests
in
with
other
types
of
code,
also
like
unit
tests,
integration
tests
and
e3
tests
unit
tests
are
in
the
packages
themselves,
so
whatever
code
you're
writing
in
whichever
directory
you
write
an
underscore
test.profile
me
in
that
same
directory
itself.
So
that's
why
the
unit
tests
go.
Then
we
have
integration
tests
that
are
in
integration
directory
and
then
you
have
e2e
tests
and
then
e2
directory.
B
So
if
you
want,
if
you're
adding
a
new
feature,
you
should
always
write
at
least
integration
tests
differently
to
you
once,
depending
on
the
future,
integrate
what
are
the
difference
between
integration
and
eta,
so
integration
tests
are
not
run
against
a
full-blown
cluster,
so
it's
run
against
just
the
aps.
Servers
there's
they're,
not
really
pods
or
containers
in
here.
So
just
talking
to
the
api
server
directly
for
e2
tests,
they
are
run
against
a
real
cluster.
So
you
there
is
a
concept
of
like
containers
and
faults
that
come
in
here.
B
So
one
other
thing
just
to
keep
in
mind
around
what
ets
are
what
integration
tests
are,
how
to
use
them.
There's
also
like
a
framework
for
it.
So,
let's
start
with
qmark,
for
instance,
if
you're
writing
scalability
tests,
so
we
have
a
framework
which
allows
you
to
create
fake
nodes,
sort
of
called
hollow
notes.
So
I
won't
go
too
much
into
that,
but,
like
there's
a
ton
of
framework
for
mocking
different
kinds
of
tests,
so
just
to
do
a
very,
very
quick
recap.
So
command
directory
contains
the
main
functions.
B
The
entry
point
of
everything
hack
is
just
a
lot
of
hacky
bash
bash
scripts.
Pretty
much
the
package
has
a
lot
of
business
logic,
including
the
controllers.
So,
if
you
wanna
know
about
controllers,
here's
where
you
go
package
also
contains
the
internal
versions
of
oil
resources.
Staging
contains
repositories
that
are
copied
out
with
directories
that
are
copied
out
to
its
own
repositories.
B
So
that's
why
you
look
for
station
like
client
go
external
versions
of
eps,
and
things
like
that
test
is
for
integration
and
eq
tests
hope
this
was
somewhat
useful
and
like
kind
of
breaks
down
the
big
kubernetes
monolith
and
yeah,
that's
pretty
much
it
for
the
code-based
walkthrough
quickly.
Gonna
cover
how
you
can
find
your
first
issue,
because
this
is
the
main
question
that
people
have
after,
like
like
pretty
much.
B
Everyone
asks
right
like
how
to
find
your
first
task
to
work
on
so
most
open
source
projects,
surface
a
list
of
issues
are
tasks
for
beginners
and
kubernetes.
Does
this
too
using
a
github
label
called
good
first
issue?
So
if
you're,
just
starting
out
in
the
project,
you
can
go
to
the
link
below
good
first
issue
and
the
good
thing
about
these
is
like
they
have
no
barrier
to
entries.
As
a
new
contributor,
you
should
be
able
to
tackle
these
without
advanced
setup
or
domain
knowledge.
B
So
even
if
you're
new
to
kubernetes,
that's
perfectly
fine,
you
can
learn
things
on
the
fly,
so
you
don't
really
need
prerequisites,
even
if
you
need
any
prerequisites
like.
If
you
need
to
know
networking,
it
will
be
called
out
in
the
issue
itself.
So
the
pretty
detail
talking
about
details.
It
also
includes
the
solution,
background
knowledge
context,
even
links
to
relevant
code,
that
you
need
to
change.
Everything
is
explained
in
the
issue
itself
and
the
best
part
about
these
issues
is
that
you
get
a
dedicated
mentor.
B
B
So
when
you
have
solved
a
good
first
issue,
you
can
take
it
another
set
of
issues
with
the
label
health
wanted.
So
these
issues
also
have
a
low
barrier
to
entry
and
kind
of
have
like
a
goldilocks
party,
so
like
not
too
high
that
a
whole
contributor
would
do
it,
but
not
too
low
that
it
wasn't
useful
for
a
cold
contributor
to
spend
time
to
review
it
answer
questions
and
help
it
get
into
a
release.
B
So
these
are
also
really
really
good
places
to
jump
in
one
I
think
I
do
see
people
complaining
about
is
that,
since
these
are
such
good
issues
to
start
with,
they
go
away
in
like
seconds
so
minutes
or
hours
or
whatever.
Like
you
create
the
issue,
I
I
guarantee
you
like,
I
would
say
at
least
give
it
three
or
four
hours,
some
one
or
the
other
will
pick
it
up,
so
it's
pretty
hard
to
find
them,
which
is
okay.
B
If
we
like,
we
talked
about
the
in-depth
channel
on
kubernetes,
so
a
bunch
of
us
contributors
keep
posting
good
first
issues
there
so
keep
an
eye
out
on
the
channel,
because
that's
like
a
very
good
place
to
find
these
issues
on
time,
other
slightly
ad
hoc,
but
actually
much
more
useful
ways
to
jump
in,
would
be
to
refactor
and
document
code,
write
tests
and
help
fix
test
failures.
I
want
to
call
this
out
explicitly
because
sometimes
folks
think
that
writing
tests
or
fixing
them
is
not
really
a
fancy
or
you
know
shiny
contribution.
B
However,
communities
is
in
the
face
where
we
want
to
make
it
more
stable.
We
don't
really
want
to
add
more
features.
So,
honestly,
the
project
would
love
and
absolutely
love
your
contribution
if
you
wrote
tests
or
fix
them,
but
the
other
question
that
obviously
comes
up
is
like
I
don't
know
which
tests
to
fix
or
which
code
to
refactor
ask
us
like.
These
are
slightly
more
ad-hoc
ways.
B
There
are,
I
mean
there
can
be
github
issues
too
so
like
go
look
at
them,
but
if
you
don't
know,
if
you're
still
confused,
why
do
something
ask
us,
and
then
we
can
tell
you
like
something
like
I'm
working
on
this
feature,
and
I've
noticed
this
is
not
right,
but
I
don't
have
the
time
to
refactor
it
myself.
I
let
you
know
and
then
we'll
let
you
know
now
like
the
revenue.
Not
all
contributions
have
to
be
about
good.
B
In
fact,
I
would
actually
go
on
to
say
that
to
keep
a
project
like
kubernetes
sustainable,
you
need
a
large
amount
of
contributions
that
have
absolutely
nothing
to
do
with
code
at
all,
so
some
examples
of
that,
including
triaging
issues,
helping
improve
documentations
and
writing
blog
posts
if
you've
used,
google
ids
and
you'd
like
somebody
calls
kubernetes
issues,
you
might
have
noticed
that
there
are
several
github
issues
that
are
auto
closed
by
a
bot
and
that
can
be
annoying
as
a
user.
I
do
understand
that,
but
we,
why
do
we
do
that?
B
Because
we
don't
really
have
people
who
can
help
triage
issues?
We
just
don't
have
people
that
we
cannot
care
about
all
of
the
issues
that
come
in
because
we
just
don't
have
the
time
and
department
to
do
it.
So
we
really
need
people
to
help
triage
issues.
Even
if
you
don't
know
the
answer,
that's
totally.
Okay,
just
surface
it
to
the
sake
make
sure
it
doesn't
get
lost
talk
about
it
in
meetings.
It's
okay
like
if
you
don't
know
how
how
an
issue
is
works.
You
can
just
say
like
here.
B
There
have
been
several
folks
who've,
been
doing
this
consistently
to
issue
triage
and
have
been
promoted
to
lead
positions
in
the
community
so
like
because
of
good
leadership,
you
need
to
care
about
broader
aspects
of
the
project
right.
So
just
writing
code
is
not
enough
and
these
type
of
contributions
are
actually
a
gateway
to
more
bigger
rules.
Oops,
two
more
bigger
roles
in
the
community
what's
happening.
B
So,
let's
look
at
one
action
item
that
you
can
take
here
so
sig
node
that
works
on
cubelet
and
node
is
having
a
bug
scrub
session.
Today.
I
believe
it's
already
started
so
they're
doing
a
six
hour
time
period
where
they're
like
working
or
synchronously.
I
think
in
a
it's,
a
channel
called
signal
bug
scrub.
So
one
of
the
indian
contributors,
aditi
sharma.
She
is
leading
that
session.
B
So
this
like
it
caters
to
all
times
once
so
check
this
out.
If
you
don't
like
know
where
to
find
this
box
obsession
or
ask
them
chatter
and
the
in-depth
channel
and
we'll
point
you
to
it
now,
once
you
get
started
with
contributing,
you
want
to
move
up
the
ladder
you
want
to
feel
like
you're
progressing
right,
it's
like
contributing
it's
not
enough!
So
how
does
that
progress?
Look
like
how
does
that
ladder?
B
Look
like
so
first,
you
become
a
member
of
the
kubernetes
organization
and,
to
be
very
honest
like
this
bar
is
not
that
high.
Even
if
you
summit
like
five
or
six
pull
requests,
you
can
become
a
member
of
the
kumari's
github
organization.
We
have
a
lot
of
members,
so
this
is
not
a
high
bar,
so
I
really
really
suggest
everyone
here
to
try
to
at
least
achieve
this.
One
start
contributing
with
stick
around
for
a
month
or
two,
and
this
is
very
much
possible.
B
Now
then
you'd
become
a
reviewer
when
you
start
reviewing
code
and
an
approver
when
you
can
sign
off
on
ps,
so
you
start
living
a
little
bit.
You
get
promoted
to
a
reviewer
and
then,
when
you
consistently
review
when
people
feel
like
they
trust
you
to
actually
sign
off
on
the
board,
are
they
promoted
to
the
approval
status
and
eventually
there's
this
thing
called
an
owner?
Who
sets
the
priorities
and
provides
leadership
for
subproject?
B
So
we're
talking
about
this
in
the
chat
so
qfctl,
for
example,
is
a
sub
project
of
six
cli
and
the
people
listed
as
owners
for
keep
ctl.
They
set
priorities
and
provide
leadership
for
a
cpl
features
or
whatever
everything
that
goes
around
cube.
Cpm
and
contributors
also
get
the
sweet,
kubernetes
patch.
B
I
I
started
as
a
google
summer
of
current
on,
so
I
can
tell
you
like
this
works,
or
there
are
several
other
contributors
who
started
out
like
that
as
well.
So
this
has
worked
pretty
good
for
us.
It's
also
outreachy
and
linux
foundation,
lfx
mentorship
program
and
most
people
think
that
these
are
usually
for
students.
Only.
That's
not
the
case.
The
lfx
program
is
not
just
limited
to
students,
so
anyone
can
apply
so
take
a
look
at
it.
B
I
think
it's
done
a
few
times
a
year,
so
keep
an
eye
out
on
this,
and
I
want
to
call
out
one
of
the
decent
elephants.
I've
gone
to
kubernetes
ash
who's.
Also,
in
this
workshop
and
he's
talked
about
his
journey,
his
work
over
the
internship
program
has
been
immensely
impactful
for
the
project.
So
kubernetes
is
a
very
big
project,
which
means
it
also
has
a
lot
of
dependencies
and
analyzing.
B
These
dependencies
were
turning
out
to
be
quite
a
struggle
for
us,
so
he
single-handedly
who
worked
on
a
project
called
depth
stat,
so
it
was
his
own
github
repository
and
then
we
thought
like
oh
wow.
This
project
is
really
useful
and
we
later
brought
it
into
the
kubernetes
project
and
we
are
also
using
it
for
the
main
kubernetes
depot,
and
I
also
like
really
like
this
tweet
from
dan,
which
points
out
how
this
tool
is
helping
highlight
like
remove
the
people
of
16
dependencies
like
this.
B
Pretty
much
never
happens,
and
we
could
never
really
understand
how
many
dependencies
are
being
removed
before
that
added
before
so.
This
tool
has
been
really
really
helpful,
so
I
just
really
want
to
call
this
out
so
like
these
internship
projects
can
be
very
impactful
so
reach
out
to
us.
If
you
want
to
know
what,
and
also
not
only
this
he's
been
working
on
a
lot
of
other
aspects
to
even
after
the
internship,
so
one
about
more
about
the
internship
program,
how
to
get
involved.
B
C
B
D
C
C
They
are
responsible
for
day-to-day
work
required
to
successfully
release
kubernetes,
while
the
sick
at
large
is
focused
on
improving
this
process
itself,
so
there
are
like
several
verticals
or
focus
areas
in
the
release
team.
So,
as
you
can
see
in
the
tutorial,
there
are
enhancements
ca
signal.
Backtriage,
docs
release,
notes,
communication
stream.
So
all
of
these
are
each
of
these
teams
handle
a
specific
area
of
the
release
cycle.
C
C
There
is
also
an
emeritus
advisor
who
is
one
of
the
previous
release
leads
they
come
in
to
advise
the
release,
lead
in
critical
teamwork
terms
or
any
workflow
improvements
that
they
want
to
have.
Even
the
emirates
advisor
handles
having
headless
the
shadow
program,
so
emulators
advisor
helps
in
all
of
those
day-to-day
activities
now
onto.
L
C
So,
as
you
can
see,
along
with
each
roll
lead,
we
have
shadows.
So
all
of
these
roles
have
a
set
of
like
four
to
five
shadows
and
the
goal
is
to
mentor
them
in
order
to
lead
in
a
future
release
that
specific
role
or
the
overall
release.
So
you
start
becoming
a
role
shadow.
Then
you
become
your
own
lead,
then
you
then
you
become.
Then
you
volunteer
for
the
release,
lead
shadow
position
and
then
eventually
can
become
the
radius.
C
C
Goes
although
like,
if
you
start
with
one
team,
there
is
no,
there
is
no
foundation
that
you
can't
hop
on
to
another
team.
You
can
do
it
in
a
future
cycle
if
you
like
to
explore
more
so
coming
to
the
main
topic.
What
is
the
shadow
program
so
think
of
the
shadow
program
as
an
apprenticeship
program
where
you
kind
of
intern
in
the
release
team
and
try
to
learn
by
doing
things
you
you
basically
tag
along
the
lead
and
help
the
lead
in
the
day-to-day
activities
of
the
team
of
that
role.
M
C
Be
shadow
in
the
last
week
of
the
any
any
of
the
release
cycles,
the
emeritus
advisor
and
the
release
team
lead
post
the
sign
up
form
on
the
mailing
lists,
so
it
is
really
important
to
join
the
kubernetes
dev
mailing
list
where
all
of
the
announcements
going.
So
that
is
the
time
you
should
start
looking
at
the
process
and
like
if
you
are
interested,
go
look
at
the
docs
read
through
them
and
cover
the
process
once
more.
C
C
C
Just
fill
up
the
form
now,
a
quick
tip
there
is
provide
crisp
answers
to
the
questions
in
the
form
so
that
when,
when
the
leads
are
wetting
your
application,
they
know
why
exactly
you
are
trying
to
be
a
shadow
in
the
release
team
and
also
what
are
the
previous
experiences
that
drove
you
to
that
decision
and
after
you
fill
the
form,
just
wait
for
the
selections
to
be
announced.
So
in
the
past
year
the
shadow
program
has
turned
out
to
be
very
competitive.
C
We
in
the
in
the
previous
release.
In
the
near
past
release
cycles.
We
have
seen
hundred
plus
applications
for
just
the
teach
shadow
positions.
So
please
don't
be
disheartened.
If
you
don't
get
selected,
you
can
apply
in
the
future
cycles
or
help
out
in
other
tasks
of
sig
release
as
an
open
source
project.
We
always
need
contributors,
so
the
releasing
shadow
program
is
a
very
important
program,
insecure
release,
but
it
does
not
mean
that
there
are
no
other
opportunities
in
securities
to
get
started,
as
we
understood
in
the
earlier
sections
of
this
workshop.
D
C
G
C
C
C
C
So
that's
all
before
the
second
break,
so
you
can
go
ahead
and
have
your
morning
beverage
of
choice,
coffee
whatever,
so
that's
all
for
the
second
part
of
the
workshop,
let's
hop
back
in
at
12,
where
we
will
learn
more
about
the
automation
that
drives
the
kubernetes
community
and
get
onto
the
demo
in
handsome
cool.
Let
me
just
stop
cheering.
D
C
Yeah,
I
can
do
that
so
leading
a
release
has
been
a
fun
experience,
primarily
because
this
is
the
first
time
someone
is
someone
was
leading
the
release
from,
I
think,
outside
the
north
american
subcontinent.
I
don't
remember
anyone.
I
may
be
wrong
in
that.
If,
but
certainly
it
was
the
first
for
a
person
from
the
asia
pacific
region
to
lead
a
release.
So
there.
C
Challenges
to
actually
get
the
team
rolling
and
one
interesting
problem
that
we're
trying
to
solve
in
the
community
is
the
synchronous
nature
of
our
communication,
so
as
they
mentioned
that
we
are
doing
asia-pacific
friendly
listing
meetings,
so
handling
those
and
then
like
trying
to
so
so.
The
release
lead
role
is
more
of
like
a
managerial.
You
need
to
manage
like
39
or
40
people
in
in
the
release
team.
You
have
to
ensure
that
everything
all
of
the
things
get
done
on
time.
C
You
have
to
ensure
that
everyone
is
okay
with
the
release.
Everyone
is
having
fun,
they
are
not
stressed
out.
So
this
is
an
important
part
of
the
important
part
of
the
roles.
Mr
responsibilities,
we
stored
up
on
the
lead
so
yeah
it
was
a
fun
and
adventurous
proposition.
Also,
there
are
some
cool
things.
C
N
C
N
C
There
are
no
prerequisites
as
like:
there
are
hard
bound
prerequisites
as
such
it's
just
time,
so
it
becomes
kind
of
a
day
job
for
you.
So
you
need
to
invest
like
25
to
30
hours
a
week
into
the
release
in
initial
parts.
You
can
do
by
15
hours
a
week,
but
at
the
end
of
the
release
it
becomes
a
full-time
job
for
you,
so
support
from
from
your
employer
is
really
important.
C
The
other
thing
is
the
whole
journey
through
the
shadow
program.
Prepares
you
for
taking
up
that
position,
so
there
is
nothing
that
you
would
need
other
than
this
time
requirement
when
you
sign
up
for
this
role,
because
you
will
be
through
the
program
you'll
be
through
the
ladder
and
already
gain
context
on
what
each
role
in
the
release
does.
C
So
you
would
also
need
a
lot
of
like
management
skills,
as
in
you
need
to
keep
everyone
happy
with
everything
that
you
take
at
the
end
of
the
day,
you
have
the
release.
Team
serves
the
community,
it
is
there
to
serve
the
kubernetes
community
and
it
is
there
to
like
make
processes
simpler
for
all
other
six
who
want
to
publish
features
as
part
of
any
release.
C
B
C
O
I
O
O
Actually
so
I
did
not
start
contributing
to
kubernetes,
but
I
had
started
with
like
some
other
open
source
project.
Actually
I
think
last
year
it
was
like
litmus
devo
or
something
they
had
started,
but
due
to
time
constraint
and
company
like
like,
I
was
changing
and
all
those
things
I
was
not
able
to
continue
this
so
so
I
like,
I
had
a
thought
like
daily.
I
have
to
at
least
contribute
one.
F
O
This
one
of
the
open
source
like
development
or
anything
activity
or
anything,
but
I
was
also
like
having
some
some
other
thoughts
like
I'm,
not
good
at
this
concept
or
not
or
so,
those
kind
of
thoughts
also
came,
and
I
like
I
did
not
continue
actually
so
so
that
kind
of
situation
I
had
faced
so
just
like.
I
want
to
again
come
back
to
this.
That's
why,
like
I.
D
C
A
B
B
B
K
K
I'm
ganesh
I'm
audible
yeah,
so
I
I
would
like
to
ask
a
query
or
what
would
you
recommend
for
working
professionals
and
have
a
very
less
hands-on
coding
experience,
but
you
would
really
like
to
contribute
to
the
open
source
projects
like
kubernetes.
Another
open,
stack
and
all
those
because
I
had
really
tried
to
you
know,
get
into
the
contribution.
K
Teams
that
work
across
the
globe-
and
then
time
zone
was
one
of
the
major
issue
for
me
as
a
beginner,
but
then
later
on,
I
really
got
sent
into
the
other
tasks
at
my
office,
but
then
now
I
am
trying
to
learn
kubernetes,
because
we
are
also
growing
as
a
team,
and
maybe
we
will
be
getting
more.
You
know
support
related
queries
from
for
openshift
as
well.
So
as
a
beginner,
I
would
like
to
start
with
kubernetes
upstream
first
and
then
we'll
be
moving
to
red
hat.
A
So
can
I
take
this
question
yeah,
so
hi
ganesh
and
I
basically
identify
with
what
you
just
said,
because
I
am
not
from
a
coding
background.
I
come
from
a
primarily
infrastructure
background
and
I
did
not
know
kubernetes
when
I
started
off,
because
we
as
an
organization
just
started
adopting
kubernetes
as
a
product
into
you,
know
our
infrastructure.
A
So
I
did
not
have
any
knowledge
about
kubernetes
or
coding.
The
basic
knowledge
that
I
did
have
was
that
of
html,
css
and
javascript,
and
that
also
it
was
rusty
at
best
because
I
basically
completed
graduation
eight
years
ago,
so
that
was
when
I
actually
remembered
having
done
anything
related
to
you
know,
coding
really
remotely
related
to
coding.
A
That's
the
very
first
thing
that
I
would
recommend,
and
it
comes
from
personal
experience,
because
I
did
not
have
any
idea
and
it
will
not
make
sense
for
a
person
to
sort
of
just
directly
get
into
contribution
without
understanding
or
how
it
works
locally.
Even
if
it's
just
a
simple
you
know
set
up
on
your
local
machine
first,
try
doing
that.
Second
thing
is:
if
you're
looking
to
get
started
with
upstream
contributions,
I
guess
nikita
went
through
those
good
first
issues
and
help
ported
links
and
we've
pasted
them
on
chat.
A
Those
are
good
avenues
to
sort
of
check
out
for
a
good
first
issues,
and
you
know
issues
that
you
can
contribute
to.
Second.
The
second
thing
that
I
would
say
is
do
not
limit
yourself
to
open
open
streams
upstream
contributions.
It's
it's!
It's
not
that
you
know
only
court
contributions
are
valuable.
A
You
know
scale
up
on
the
contributor
ladder
so
stay
tuned
to
that
as
well,
but
the
basic
first
step
would
be
to
understand
the
product
at
a
very
basic
level,
because
even
if
you're
trying
to
get
involved
really
you
need
to
know
right
or
what
is
the?
What
is
it
that
you're
contributing
to
you?
Just
you
just
can't
wait.
You
just
can't
really
contribute
without
knowing
the
product,
so
I
would
recommend
that
for
your,
you
know,
startup
start
a
thing.
B
But
I
think
that
sounds
well.
I'd
also
add
that,
like
to
answer
this
question
and
the
similar
sentiment
that
was
brought
up
a
minute
ago
about
like,
if
you
have
a
deja,
that,
like
obviously
you're
not
getting
paid
to
work
on
open
source,
how
do
you
find
time
to
work
on
it
and
how
do
you
find
time
to
learn
the
code
and
contribute,
and
sometimes
you
feel
you're,
not
good
enough?
B
No
one
is
good
enough
to
be
honest,
like
I
don't
know
anything
about
everything
about
the
kubernetes
convex,
like
the
creator
of
kubernetes,
doesn't
know
it
like
at
this
point.
It's
too
huge,
so
not
knowing
is
a
pretty
common
sentiment
across
the
project.
So
don't
worry
about
it.
It
definitely
takes
time
to
learn.
B
If
you
already
have
a
deja,
I
think
navalny
can
answer
this
much
better
because
he
at
us
previously
he
did
manage
both
deja
vu
and
open
source.
But
one
thing
I
do
tell
people
is
that
you
don't
really
need
to
put
one
hour
every
day
or
like
to
show
up
every
single
day.
Even
if
you
show
up
maybe
once
or
twice
a
week,
just
showing
up
is
the
most
important
thing
for
sure
I
would
say
on
slack:
that's
also
enough,
you
don't
need
to
attend
meetings.
B
I
don't
attend
too
many
meetings
because,
like
I'm
after
wearing
meetings
on
my
calendar
already,
but
just
showing
up
on
slack,
it
works
out
well
too,
so
show
up
on
stack.
You
don't
have
to
show
up
every
single
day.
Twice
a
week
is
okay
but
show
up
consistently.
Consistency
is
the
one
thing
that
we
need.
We
get
lots
of
drive-by
contributors.
We
don't
really
get
consistent
contributors
and
sometimes
to
be
very
honest
like
if
I'm
putting
an
investment.
B
If
I'm
investing
in
mentoring
a
contributor,
I
would
also
expect
them
to
stick
around
like
I
want
to
see
that
sort
of
return
of
investment
on
of
my
time.
So
consistent
contributions
doesn't
have
to
be
one
hour
every
day.
One
hour
once
every
two
days,
good
enough
for
learning,
like
vivia
said
we
do
like
we,
I
mean
there
are
a
bunch
of
newbies
in
the
community
and
in
the
in-depth
channel
or
like
various
other
channels.
We
do
do
like
code
based
exploration
sessions
together.
B
We
did
recently
a
few
weeks
ago,
so
you
can
learn
together
with
the
rest
of
the
people,
because
everyone's
in
the
same
world
right
so
we
could
learn
together.
So
I'd,
say
time
wise,
take
it
slow
but
show
up
consistently
and
learn
with
everyone
else.
You
don't
have
to
do
this
all
by
yourself
because
it
get
it.
C
C
That
I
did
in
the
kubernetes
community,
it
was
all
as
part
of
my
hobby
and
I
used
to
do
it
on
my
free
time.
So
it
does
get
a
bit
hectic
if
you
take
up
roles
in
the
community,
so
I
really
suggest
people
like,
as
nikita
and
divya
have
mentioned,
be
consistent,
even
if
you
put
in
like
one
or
two
hours
a
week.
That's
completely
fine,
so
we
in
the
community
really
value
like
consistent
contributions,
rather
than
like
getting
people
getting
like
burned
out
by
open
source.
C
We
really
don't
want
people
to
suffer
through
that,
and
but
burning
out
in
open
source
is
a
real
problem,
so
give
give
one
or
two
hours
of
your
time
devote
just
a
little
bit
in
understanding
towards
your
goal.
So
that's
what
like
one
thing,
is
like
finding
the
reason
that
you're
contributing
to
open
source
for
me.
Initially,
it
was
just
to
learn
just
to
learn
about
something:
a
really
cool.
C
C
Okay,
can
I
just
get
a
quick
okay
awesome,
so
we
did
talk
about
a
lot
of
things
like
how
the
community
is
organized,
how
our
code
is
organized,
but
now,
when
you
start
contributing
to
over
ideas,
the
project
is
really
big
and
there
are
like
100
more
than
100k
issues,
slash
prs.
We
recently
raised
that
milestone.
C
It's
really
important
to
have
automation
which
handles
data
for
you,
because
github
as
an
ui
needs
to
be
managed.
Somehow
now
you
either
have
people
or
you
either
have
auto
machines.
So
in
order
to
relieve
our
contributors
from
doing
all
of
that,
we
have
a
great
deal
of
automation
which
goes
into
properties.
C
So
the
first
thing
which
comes
up
is
labels,
so
there
are
a
lot
of
issue
or
vr
labels,
for
example.
Here,
if
you
don't
sign
the
cla,
you
will
see
a
cncfcln
no
label.
Now
no
contributor
manually
puts
that
there
is
a
port
which
checks
your
cla
signing
status
based
on
your
committed
email
and
your
github
account
and
then
appropriately
puts
that
label.
C
Also.
Do
note
that,
unlike
the
basic
github
experience
in
the
kubernetes
organization,
you
cannot
manually
unbelievable
request
or
issue.
Some
people
can,
but
they
do
have
like
maintenance
privileges,
but
we
even
the
maintainers,
don't
manually
put
in
labels
unless
something
is
on
fire
or
they
really
need
to
do
so.
C
All
of
the
labels
in
the
kubernetes
community
are
added
by
talking
to
what
now
this
is
done
so
that
we
can
add
lots
of
granularity
to
who
can
access
what.
So,
for
example,
if
you
are
not
a
narc
member,
your
code
is
by
default,
not
tested,
as
you
can
see
here,
the
last
line,
kt
robot
added
the
needs,
okay
to
test
label,
so
any
contributor
who
is
not.
C
C
Now
I
we
understand
that
labels
can
be
overwhelming,
because
there
are
so
many
of
them
even
like
I
don't
know
all
of
the
labels.
However,
they
are
what
makes
much
of
that
test
and
the
community
infrastructure
of
this
project
work.
We
use
a
tool
called
which
looks
for
this
labels
and
acts
accordingly.
Now
labels
are
also
used
for,
like
multiple
purposes,
say:
triage
planning,
work,
permissions,
court
reviews
updates
to
prs
status.
C
Here
is
an
example
of
labels
that
are
used
on
kubernetes
coverages
repository
shows
here
after
I
referred
to
skk
just
because
they
gave
me
amazing.
You
can
hover,
on
top
of
each
of
this
label
description
on
on
each
of
these
labels
to
know
a
brief
description
about
what
this
does.
Not
all
of
the
labels
have
them,
but
some
of
them
do
and
you
can
get
a
great
deal
of
information
from
that.
C
You
should
ideally
ask
on
the
kubernetes
contributors
channel
or
whoever
you
are
talking
to
when
filing
the
issue
or
in
contributor
experience,
or
you
just
guess,
which
sig
that
you
feel
that
is
most
close
to
your
issue.
Then,
when
the
sikh
does
it
triage
of
their
issues,
they
can
come
and
judge
whether
this
indeed
belongs
to
them,
or
it
is
for
some
other
thing.
C
As
I
said
it's
better
to
label
your
pr
with
the
same
than
not
because
then
it
gets
the
right
attention
now
the
current
label
defines
what
type
of
an
issue
it
is.
It
is
really
helpful
in
triaging
those
issues.
So
your
the
issue
that
you
file
or
the
pr
can
be
a
park
or
a
bug
fix.
It
can
be
a
feature
issue
usually
feature
issues
are
not
filed
in
kubernetes
kubernetes,
because
we
follow
that
process
of
enhancements
of
caps
by
which
all
features
need
to
go
in
and
get
it
before.
C
Even
they
are
considered,
there
are
labels
called
kind
documentation
which
specifies
any
documentation
needs.
There
is
a
design
label.
There
is
a
failing
test
label,
for
example,
if
any
test
is
failing
and
it
has
not
been
brought
to
the
notice
of
the
owner
of
that
test,
you
can
file
an
issue
and
attack
the
appropriate
safe
so
that
they
can
look
at
it.
Sometimes
the
tests
don't
consistently
fail,
but
they
keep
on
flicking
between
failures
and
successes.
I
C
Up
millions
of
lines
of
code
there
in
the
kubernetes
repository,
sometimes
we
do
clean
up.
There
are
prs
open
which
clean
up
20k
30
case
lines.
Sometimes
so
you
can
put
kind
clean
up
on
those
issues
onto
the
priority
one,
so
the
priority
level
defines
the
critical
criticality
of
the
issue
or
the
pr.
C
This
is
used
heavily
in
project
planning
in
the
kubernetes
project
and
you
will
almost
never
add
this
label
without
closely
working
with
yourself.
So,
as
I
said,
this
is
very
important
to
be
vetted
by
someone
who
knows
about
the
issue
that
we
are
sometimes
when
the
sig
does
triage.
If
there
is
any
pending
question
left
to
be
answered
by
whoever
is
filing
the
issue,
they
can
also
put
an
evading
evidence
on
triage
label
now,
specifically
for
pull
requests.
There
are
some.
There
are
four.
These
are
four
very
important
labels.
C
The
release.
Note
label
determines
the
status
of
the
release.
Note,
so
does
your
change
require?
It
really
is
not
when
releasing
kubernetes,
you
can
also
put
release
dot,
none
which
basically
puts
a
label
which,
when
the
release
notes,
are
being
generated,
it
signals
that
no
specific
change.
You
need
to
put
in
the
lock
improved
and
lgtm
go
through
our
improved
ngtm
labels
are
used
in
reviewing
our
pr's.
So
when
you
file
a
pull
request,
when
you
file
a
change,
some
a
reviewer
will
come
in
ngtm
njtm
your
peer.
C
If
they
feel
like
you
have
complete,
the
change
looks
same
and
after
you
get
an
ngtm,
an
approver
will
come
and
improve
your
pr
I'll.
Come
to
that
later
on.
When
I
explain
like
what
is
the
flow
of
when
you
want
to
get
attention
to
your
change,
when
I
explain
the
pr
workflow
so
then
it
will
become
more
clear.
C
The
cherry
pick
approved
label
is
only
used
for
patches
or
changes
which
are
back
quoted
to
previous
releases,
and
it
is
used
only
during
certain
stages
of
the
release
cycle.
So
every
month
there
is
a
team
called
patch
release
demon
securities
who
go
through
all
these
cherry
pick,
approved,
pull
requests,
merge
them
to
those
specific
branches
and
then
cut
the
batteries.
C
C
C
C
D
C
C
You
can
also
put
a
slash
retest
command
in
in
your
pr
comment,
which
will
run
all
of
the
test
sort
configured
in
that
repository
for
the
changes
that
you
are
making
slash,
close
slashes,
sorry,
slash
close
closes
the
pr
slash,
cc,
tag,
someone
or
subscribe
someone
to
the
issue
so
that
they
can
have
a
look
at
it.
It's
something
like
a
friendly
thing.
C
Now,
a
lot
of
you
have
asked
questions
onto
the
dev
setup
or
how
should
you?
What
is
the
flow
that
you
should
follow
in
contributing
to
kubernetes?
So
we
follow
the
feature
branch
ideology.
So
the
recommendation
is
so
you
have
the
upstream
kubernetes
kubernetes
repository.
You
should
forward
the
repository
to
your
uw
user
and
then
clone
the
repository,
broken
clone
the
fork
locally
and
then
add
the
upstream
as
if
you
want
you
should
keep
on
like
fetching
from
upstream,
so
that
you
get
like
latest
changes,
sometimes
on
a
pr.
C
You
may
need
to
rebase
your
changes
on
top
of
the
masters,
the
master
branch,
if
there
are
any
conflicting
changes.
So
we
follow
this
ideology
of
like
checking
out
feature
branches.
Whenever
you
need
to
propose
any
change,
and
then
you
push
the
feature
branch
to
your
fork
and
then
file
a
pull
request
to
the
main
deposit
against
those
changes.
C
C
C
If
you
have
not
specified
the
kind,
it
will
come
and
label
it
to
be
its
kind
same
for
if
you,
if
you
don't
specify
a
scene,
you
can
add
more
labels
and
resolve
those
review
comments,
and
this
becomes
like
a
cycle
so
everywhere
will
come
in.
Then
they
will
see
the
changes.
If
they
feel
like
there
can
be
improvements,
they
will
ask
you
to
do
it.
C
The
bot
will
keep
on
telling
you
what
criteria
are
missing
so
that
you
know
what
you
need
to
iterate
on
again,
the
same
thing.
Okay,
so
one
thing
to
note
here
is:
you
might
see
that
we
have
a
slash,
close
command
now.
A
lot
of
the
common
github
features
are
disabled,
like
closing
a
pull
request
in
favor
of
this
key
level,
bot
command
so
that
we
can
have
like
granular
control
of
over
who
executes
what
in
the
community.
C
So,
as
mentioned
the,
what
helps
you
in
finding
reviewers,
so
there
are
owner's
files
files
scattered
out
throughout
the
kubernetes
code
base,
and
they
have
hints
as
to
who
can
review
this
code.
So
the
bot
just
looks
in
those
files,
and
this
gives
you
suggestions
that
who
can
you
assign
in
order
to
get
a
degree?
For
example,
a
rosty
is
being
suggested
to
review
this
code.
K
C
The
sick
meetings,
although
of
the
appropriate
safe,
then
you
can
use
that
to
get
some
attention
to
the
pr
or
since
the
meetings
are
a
bit
uncomfortable
times
for
us,
you
can
ask
us,
someone
will
come
in
at
their
own
preferred
time
and
give
you
suggestions
or
one
more
way
of
asynchronous
communication.
Is
you
can
send
an
email
to
the
mailing
list
of
that?
C
This
is
these.
Are
these
are
some
of
the
ways?
The
final
way
is
read
the
owner's
file
on
your
own.
If
the
body
is
not
giving
you
meaningful
suggestions
and
determine
whom
you
should
tag,
however,
do
keep
in
mind
that
all
of
these
project
reviewers,
are
usually
are
very
busy
and
have
their
own
days
of
requirements,
maybe
in
a
different
time
zone
than
so.
Please
be
patient
and,
like
don't
spam,
lists
and
channels
with
repeated
requests,
although
usually
like
you
would
never
need
to
come
to
this
step.
C
If
you
want
to
test
in
specific
ci
job,
you
can
say
slash
test
and
the
name
of
the
ci
job
see
here.
The
bot
makes
it
really
easy
for
you
to
find
out
the
command
that
you
need
to
run
so
some
quick
tips
answer
any
questions
that
are
put
up
put
up
by
the
reviewers
look
for
messages
from
boards
resolve
them
seek
out
any
additional
owners
that
need
to
approve
the
vr.
C
C
So
after
you
give
the
demo.
So
what
we
want
you
to
do
is
follow
the
same
steps
and
create
a
pull
request
on
your
own
and
go
through
the
flow.
As
we
have
been
mentioning,
there
are
swags
for
people,
so
the
first
30
most
pr's.
We
will
get
something
special,
so
we
will
be
seeing
the
status
of
this
pr
merged
prs
and
send
you
communication
on.
What's
next,
so,
let's
get
our
hands
dirty.
C
C
C
C
Slash
something
like
that,
just
any
name
would
do
which
makes
sense.
So
the
task
here
is
what
you
will
need
to
do
is
go
to
the
india,
slash,
kcdblr2021,
slash,
work,
dire
directory
and
create
a
markdown
file
like
this,
with
your
github
user
name
and
put
any
content
inside
it.
I
just
put
kubernetes
school
earlier.
What
I'm
going
to
do
now
is
make
a
change
here.
I
C
C
C
C
Although
there
are
a
lot
of
ways
to
create
pull
requests,
I
usually
go
through
the
github
cli
to
make
my
life
easier,
I'm
just
showing
here
just
for
the
sake
of
simplicity,
so
that
you
all
understand
like
what
goes
on
in
the
ui,
so
see,
github
check
the
pull,
request,
template
and
pre-filled
some
information
for
you
now.
I
know
what
this
info,
what
this
instructions
contain,
but
I
highly
request
you
all
to
go
through
the
steps
and
understand
what
do
you
require
in
order
to
file
this
vr?
C
Let
me
just
remove
this,
since
there
are
anyways
comments
now.
What
type
of
pr
is
this?
As
I
mentioned,
the
time
table
is
really
necessary,
so
here
I
am
doing
a
documentation,
so
I'm
just
documenting
that
when
it's
cool
kubernetes
is
cool
and
amazing,
so
it
will
label
a
kind
documentation
which
we
will
see
what
this
pr
does.
C
That's
all
you
can
put
in
anything.
I
am
just
putting
something
in
actually,
I
have
to
specify
like
which
issue
this
br
fixes.
So
github
automation
just
closes
the
issue
whenever
this
pull
request
is
merged.
Since
here
I
am
not
fixing
any
specific
issue,
I
can
say
none
do.
I
have
any
special
notes
for
my
reviewer.
C
C
Does
this
pr
introduce
a
user
facing
change?
It
is
not
so
I'll.
Just
put
none
in
the
release,
not
block,
but
if
it
is,
if
it
involves
a
user
facing
change,
if
it
involves
a
feature,
it
is
almost
always
necessary
to
put
this
release.
Note
label,
because
if
you
make,
if
the
community
makes
any
changes
to
feature
sets
in
kubernetes,
they
need
to
be
propagated
in
the
change
log.
C
M
C
D
C
Kicking
in
action
see
so
the
part
tells
that
the
pr
has
already
been
improved.
There
is
a
reason
to
this.
Not
everyone
of
you
will
see
this.
This
is
because
I
am
in
the
owner's
file
for
this
directory,
so
it
has
automatically
put
in
an
approved
label
and
it
also
puts
in
the
size
of
this
pull
request.
There
are
some
simple,
logical
rules
which
determines
like
what
size
appears.
C
C
C
C
So,
as
you
see,
the
kubernetes
robot
has
already
automatically
merged
this
comment,
so
I
didn't
even
need
to
do
anything.
So
that's
how
the
automation
helps.
You
helps
you
out
in
your
journey
with
that.
I
will
like
to
keep
this
session
open
for
any
questions.
While
you
go
through
the
workflow
and
placeable
request.
C
So
that's
the
task
for
this
workshop
in
the
meanwhile
feel
free
to
ask
any
questions
related
to
the
task
to
the
workshop
or
anything,
it's
kind
of
an
open
house
right
now,
so
one
thing
to
emphasize
again:
you're
not
raising
the
pull
request
just
for
swags,
so
just
some
side
effects
of
raising
this
pull
request.
What
we
really
want
you
to
do
is
like
learn
the
workflow
of
a
pull
request
in
the
communities
community.
B
B
C
C
C
C
B
This
is
pretty
silent.
What
I
guess
my
next
question
would
be
like.
Would
what
else?
What
kind
of
feedback
do
you
all
have
for
the
session?
What
else
would
you
all
like
to
see
in
a
contributor
workshop?
I
know
this
didn't
cover
everything
and
that
was
sort
of
intentional
as
well,
because
it's
a
lot
of
information
and
it's
not
in
person,
and
we
usually,
we
used
to
do
this
in
person
at
cubecons,
which
used
to
have
it
used
to
be
way
more
fun
and
more
interactive.
K
B
I
B
So
did
you
have
do
you
have
the
link
for
the
cla,
like
the
one
that
we
posted
in
shatter
there?
If
not,
I
can
drop
it
again,
so
you
will
get
two
options:
you'll
get
an
option
to
sign
the
individual
clm,
the
corporate
sealer.
Usually,
if
you're
not
getting
paid
to
do
this
or
if
you're
not
doing
this,
if
you're
not
going
to
be
contributing
to
kubernetes
during
your
workouts,
then
you
can
use
the
individual
sale,
but
you
will
need
to
sign
it
if
you
are
having
trouble
signing
it.
I
C
Okay,
so
one
of
the
common
one
of
the
common
things
that
I
notice
when
creating
a
comment
using
the
github
ui,
is
that
it
does
not
attribute
the
correct
email
id,
because
when
you,
when
you
have
your
email
masking
on
so
github,
has
this
thing
called.
It
does
not
diverse
your
email
id,
so
it
will
put
in
the
commenter
email,
users.no
reply,
dot,
gw,
github.com
email
id.
So
that
may
be
one
of
the
reasons,
because
I
see
some
of
the
comments.
B
P
P
B
B
J
Hey
guys,
quick
question,
I'm
not
sure
if
I'm
doing
it
right,
so
I
did
a
good
clone
of
the
main
master
branch.
I
created
a
git
checkout
using
hyphen
b
so
that
I
can
create
my
own
branch
on
that.
I
made
it
file
in
work
directory
and
when
I'm
pushing
it,
I'm
using
that
command,
which
I
placed
like
get
push
hyphen
f1
setup,
setup
upstream
origin,
my
own
open
account.
J
C
J
C
C
B
C
Q
B
B
So
all
the
github
automation
that
we
just
saw
is
over
there,
including
how
the
tests
are
done,
which
tests
should
we
run
when
like
how
the
bot
should
automatically
merge
when
it
has
a
particular
set
of
labels,
the
component
that
actually
merges
automatically
it's
called
tide.
So
it's
like
a
it's
a
very
weird
analogy,
like
a
wave
of
tide
coming
and
like
merging
your
pr's
away
or
something
so
you
can
take
a
look
at
that
directory
in
the
desktop
and
I've
also
like
worked
on
travel
bunch
of
us
here.
C
So
some
fun
facts
about
tight.
So
during
the
time
when
we
merge
most
of
the
code
in
the
release
cycle,
we
see
something
called
a
real
wave
when
tide
is
basically
going
over
all
of
the
peers
and
it's
it's
kind
of
in
a
loop
where
you
can't
match
anything.
So
you
need
to
like
curate
those
pr's
all
the
way
through
just
a
fun
fact.
The
caveats
that
you
will
see.
B
I
think
one
thing
that
I'm
seeing
pretty
often
is
people
aren't
really
creating
folks
of
the
repositories
they're
trying
to
push
to
the
kubernetes
playground
repository
directly,
so
you
will
not
have
access
to
it,
so
you
will
not
be
able
to
push
to
the
repository
directly.
You
have
to
create
a
fork.
So
if
you
on
the
right
hand
side,
I
think
yeah
so
the
right
hand
side
when
you
like
go
to
the
github
page
you'll
see
a
fork
button.
B
B
C
Q
C
Do
check
in
github
once
if
there
are
beginner
issues,
also
one
of
the
best
one
of
the
other
ways
to
get
to
know
what
is
going
on
and
what
needs
help
is
to
just
show
up
in
those
slab
channels,
say
hi.
Why
are
you
here
and
that
you
want
to
work
on
something
new?
So
most
of
the
things
have
things
that
are
in
flux.
They
would
really
want
some
new
eyes
on
and
they
will
help
you
from
there.
B
Also,
like
aditi,
has
posted
a
message
on
the
in-depth
slap
channel
that
we
were
talking
about
for
the
sigmoid
bucks
graph,
so
they
are
triaging
signaled
issues
right
now
and
they
will
also
be
posting
it
on
slack,
like
whatever
issues
they're
doing
it.
So
she's
posted
the
zoom
link.
I
know
it's
been
a
lot
of
like
zoom
calls
since
morning,
but
if
you're
interested
it's
happening
today,
you
can
learn
at
least
about
like
how
it's
done.
B
C
B
J
On
the
very
start,
the
keynote
going
with
the
not
really
into
the
deep
side
of
kubernetes
so
getting
familiar
of
how
we
can
do
that
in
that
101
session
as
well,
and
then
I'm
really
looking
forward
for
this
session
is
basically,
I
think
it's
on
the
track
three
year
end
of
the
day,
which
is,
which
is
how
do
we
debug
nodes
and
without
docker,
so
because
I
know
that
kubernetes
is
getting
away
from
docker,
not
exactly
the
way
it
means.
But
yes,
there
are
a
few
interesting
things
going
around
with
it.
G
B
B
One
of
the
contributors
from
india
who
works
on
signor
she's,
pretty
active
there.
So
actually,
if,
like
that's,
actually
very
interesting
to
you,
you
should
like
probably
attend
this
ignored
session
that
I
was
talking
about,
because
there
is
a
very
active
effort
going
on
in
removing
docker
shrimp
from
kubernetes.
So
like.
B
C
So
a
lot
of
other
people
have
also
been
facing
this
issue,
and
pawan
has
put
in
the
instructions
on
how
you
should
how
you
can
resolve
this
issue.
So
what
is
happening?
Is
you
have
committed
with
any
user
like
committed
with
an
email
that
is
not
associated
with
any
github
user?
So
github
is
not
able
to
determine
who.
F
C
D
C
So
how
did
you
all
like
this
workshop?
Do
you
have
any
feedback
changes
that
you
want
to
see
or
any
additional
content
that
you
want
to
see
in
the
future,
because
this
workshop
will
be
done
like
periodically
throughout
time?
It
may
be
us,
maybe
some
other
set
of
people,
but
we
are
like
collecting
feedback
about
the
content
and
incorporating
them
back
into
the
program.
I
C
Iteration
of
this
workshop,
what
we
did
was
we
took
a
live
issue
and
we
solved
it
in
the
in
this
workshop
itself.
Now
the
problem
with
that
is
usually
in
google.
In
the
kubernetes
project,
you
might
have
seen
that
either
issues
are
complex
or
the
simple
issues
are
taken
up
really
friendly,
so
we
really
want
to
do
that
going
through
the
whole
flow
of
finding
something
really
like
in
depth
into
the
product
and
like
in-depth
into
the
project
and
then
like
fix
that
issue.
D
C
C
So
I'm
not
sure
how
do
you
resolve
it
because
I
have
not
tried
it,
but
usually
when
you
create
it
through
your
github
user,
you
have
to
ensure
that
the
computer
email
is
the
same
that
you
have
signed
the
cla
with
so,
as
I
mentioned
like.
Sometimes,
if
you
have
enabled
the
github's
privacy
feature
of
masking
your
email,
it
will
show
up
as
a
different
username.
I
B
Yeah,
I
was
gonna
talk
about
solid
topic,
so
like
also
the
way
the
whole
automatic
margin
works.
Is
that
there's
a
merge
pool.
So
if
there
are
a
bunch
of
pr's
which
have
lgtm
approve
and
all
the
right
labels
they
get
into
a
pool
and
they
are
tested
all
over
again.
So
I
don't
think
this
repository
has
tested,
so
it
will
be
quick,
but
they're
tested
all
over
again.
B
So
since
there
are
lots
of
people
creating
pull
requests
now
there
are
a
bunch
of
pr's
in
the
porsche,
it's
called
a
merge
pool
so
like
tide
and
a
pool,
it's
already
water,
see
analogy
so
it
will
get
merged
once
like,
like
all
those
pr's
in
the
watchpool,
will
get
merged
at
once.
It
takes
a
bit
of
time.
So
if
there
are
more
number
of
pr's
per
get
much,
so
don't
worry.
If,
if
your
pr
has
been
lgtm
and
approved
it
will
get
merged
automatically.
C
Yeah,
I
just
dropped
a
link
to
the
merge
pool.
So
if
you
want
to
see
it
in
action,
you
can
yeah
keep
on
checking
the
status
there
so
usually
like
the
much
pool
is
per
repository
and
the
delay
between
or
the
reconciliation
loop
at
which
it
merges
pr
is
also
configured
for
repository
that
all
goes
into
the
automation.
I
think
we
get
a
link
to
the
test
repository
earlier.
B
J
J
M
B
C
B
M
M
F
C
B
So
yeah,
and
also
one
more
thing
is
so.
This
is
slightly
an
official
workshop
and
I
mean
whatever
we
do
is
like
official
from
the
poverty
side
of
things.
We
have
to
host
it
on
platforms
that
where
we
can
cover
in
the
kubernetes
code
of
conduct,
because
it's
very
important,
so
we
usually
just
stick
to
the
zoom
slack
and
those
systems.
E
L
D
C
C
I
K
B
So
client
and
server
there
is
a
rule
that
I
mean
for
backwards
and
forward
compatibility.
You
can
have
two
n
minus
two
versions,
like
the
difference
between
them
can
be
n
minus
two.
So
if
it's
more
than
that,
you
we
can't
guarantee,
like
things,
might
work
separately
so,
but
it's
better
to
always
have
them
in
the
same
version
for
sure.
B
B
C
G
C
K
B
C
C
B
B
D
C
C
B
B
So
what
settings
here
on
this
error
right,
I'm
getting
yeah
so
missing,
github
user
means
that
the
email
that
you're
using
to
sign
your
comment
is
not
matching
the
email,
that's
in
your
github
profile.
So
it
says
that
it
cannot
map
the
comment
email
to
any
github
username.
So
you
need
to
make
sure
that
whatever
comment
you're
using,
you
may
commit
email
you're
using
it's
in
your
github
profile
or.
B
C
C
So
the
new
contributor
workshops
have
traditionally
happened
in
the
contributor
summit
and
the
kubernetes
contributor
summit
used
to
happen
in
each
cubecard,
the
europe
and
us1
during
the
pandemic.
We
have
been
thinking
thinking
through
the
medium
of
this
workshop
and
right
now,
since
almost
everything
is
online.
The
contributor
experience
special
interest
group.
There
is
a
team
inside
that
which
is
this,
is
the
mentoring,
sub
project
they're
actually
trying
to
make
all
of
the
content
into
self-paced
videos
which
contribute
new
contributors
can
look
at
at
their
own
wish
in
india.
C
We,
this
is
the
second
time
we
are
doing
it
last
time.
We
did
it
in,
I
think,
as
part
of
the
kubernetes
triangular,
so
we
really
don't
have
any
fixed
cadence.
I
I
don't
know
if
there
would
be
one
more
in
indian
time
zone
in
this
year,
but
let's
also
end
if
any
one
of
you
wants
to
get
involved
in
conducting
this
workshop
feel
free
to
ping
us
on
in-depth.
We
would
be
like
really
happy
to
help
you
through
it.