►
From YouTube: Kubernetes Meet Our Contributors 20190605
Description
When Slack seems like it’s going too fast, and you just need a quick answer from a human...
Meet Our Contributors gives you a monthly one-hour opportunity to ask questions about our upstream community, watch interviews with our contributors, and participate in peer code reviews.
See https://github.com/kubernetes/community/blob/master/mentoring/meet-our-contributors.md for more information
A
Okay
right,
everyone,
hello,
welcome
to
June's
edition
of
meet
our
contributors.
We
have
awesome
contributors
on
the
line
today
to
help
you
out
with
all
of
your
upstream
mentoring
needs.
Why
mentoring,
mentoring
at
scale
is
hard,
and
these
folks
are
here
today
to
give
you
an
hour
of
their
life
so
that
you
can
get
either
unjammed
unblocked,
more
educated,
more
curious
on
upstream
kubernetes
development,
so
first
things:
first,
we
usually
do
around
BIOS
intros
and
then
we
go
right
into
the
show
with
some
house
rules
and
some
questions.
A
So,
if
you're
out
there
listening
right
now
on
YouTube
and
you
want
to
participate,
ask
a
question:
asked
Valerie,
David,
Josh,
George
or
myself.
A
question
do
so
in
the
meet
our
contributors
slack
channel.
If
you
don't
have
a
bite
on
the
kubernetes
instance,
slack
Cates,
k8s
I/o,
you
can
meet
us
there
and
meet
our
contributors.
You
can
also
tweet
me
or
send
me
a
DM
on
the
kubernetes
slack
channel.
If
you
would
rather
a
anonymous
conversation,
that's
totally
fine.
Some
people
say
hey.
A
What's
a
cig
and
I'm
really
embarrassed
to
even
ask
that
and
that's
totally
okay
here,
that's
what
this
whole
hour
is
for.
It's
your
hour,
your
questions.
So
let's
get
right
into
house
rules
really
quick
before
we
do
BIOS
house
rules
make
sure
that
you
are
kind
to
each
other.
We
do
abide
by
the
CNCs
code
of
conduct.
We
also
have
a
code
of
conduct
community
here
at
kubernetes
and
just
please
be
excellent
to
each
other.
This
includes
the
panelists
because
you
are
allowed
to
ask
each
other
questions.
A
Please
you
don't
know
each
other
so
feel
free
to
ask
each
other
questions,
and
that
also
goes
for
people
asking
questions
and
participating
in
our
in
our
chat
in
our
various
resources.
So
that's
the
first
major
house
rule
and
let's
go
ahead
to
BIOS
so
Valerie.
Why
don't
you
go
first,
tell
us
a
little
bit
about
yourself.
A
C
This
is
my
first
time
on
the
show
I
work
at
Google
and
I've,
been
here
for
two
and
a
half
years.
I
came
fresh
out
of
college
from
MIT
and
the
reason
why
I
got
into
kubernetes
is
because,
while
I
was
at
MIT,
I
took
a
distributed
systems
class
and
ended
up
implementing
raft
as
part
of
the
class
so
which
is
the
algorithm
that
backs
at
CD,
and
so
when
I
was
interviewing
for
spots
at
Google.
C
That
came
up
and
ended
up
being
one
of
the
reasons
why
I
decided
I
wanted
to
try
my
hand
at
this
kubernetes
thing,
and
so
when
I
joined
I
joined
dawn
and
yuju
&
Lantau
and
on
the
gke
node
team.
And
since
then,
I've
worked
on
a
lot
of
monitoring
stuff
I've
taken
up
ownership
of
C
advisor.
So
if
you
open,
PR,
czar
issues
there
you'll
most
likely
see
me
and
I've
also
done
a
lot
of
work
for
resource
management
in
signal.
So
my
starter
project
when
I
joined
was
I
implemented.
C
A
D
Hey
there
I'm
Josh
burkas
I
work
for
Red,
Hat
and
I
spend
a
lot
of
time
in
said
release,
particularly
on
the
release
team
I've
been
in
the
release
team
for
I,
don't
know
four
different
kubernetes
releases,
something
like
that,
which
is
something
that
people
who
are
listening
to.
This
call
can
do
because
every
release
we
recruit
new
shadows
to
learn
the
various
roles
on
the
release
team.
D
D
That's
me
and
Noah
Kantrowitz,
which
is,
and
it's
just
a
roundup
of
all
of
the
what
we
regard
as
the
interesting
merges
into
core
kubernetes
for
the
last
week
and
developer
news
and
other
sort
of
related
stuff.
I
started
it
as
an
internal
newsletter
at
Red
Hat
to
help
our
developers
keep
track
of
what
was
going
on
in
kubernetes
and
once
it
got
sufficiently
long,
I
was
like
I
should
really
publish
this
and
so
I
did
and
then
Noah
joined
to
help
add
more
stuff
to
it.
Awesome.
A
A
Yeah
we're
in
this
please
use
Josh
purchases
and
was
handy
field
guide
for
upstream
development
on
last
week
in
kubernetes
development.
It
is
a
great
resource
if
you're
looking
for
something
to
skim,
and
that
brings
us
to
the
end
of
our
panelist
BIOS
again,
my
name
is
Terrence,
so
working
Google
I
do
upstream
kubernetes.
Community
support
George
is
also
on
the
line,
doing
our
and
choose
YouTube
stuff
to
make
sure
that
you
can
hear
my
loud
annoying
voice,
clearly
at
7:30
in
the
morning,
Pacific
time
anyway.
Alright,
that
brings
us
to
our
announcements.
A
Announcements
first
announcement
is,
this
show
is
doing
awesome,
we're
receiving
thousands
of
viewers
totally
for
our
for
our
episodes.
We're
looking
for
more
upstream
remedies
developers
to
help
us
come
on
the
show
you
don't
have
to
necessarily
develop
if
you
will
docks,
Raiders
are
included
in
their
community
managers
and-
and
the
like.
Please
join
us-
also
announcements
if
you're
new
to
the
kubernetes
community
and
you're
just
joining
us
today.
We
have
this
lovely
thing
on
Thursday
is
every
Thursday,
except
for
major
holidays
and
cube
cons
at
10:00
a.m.
called
the
kubernetes
community
meeting.
A
Why
is
this
important?
This
is
important
because,
like
Josh's
last
weekend,
kubernetes
development,
it's
super
hard
to
keep
up
with
things,
so
we
try
to
have
a
condensed
contributor
circus
at
10
a.m.
every
week.
This
will
give
you
say,
updates
demos,
for
what's
the
latest
in
the
community
release
updates,
which
are
super
critical,
like
wins
code
freeze,
that's
super
important
and
also
announcements
and
shout
outs
to
awesome.
People
in
the
community
should
totally
join
us
again
happens
every
Thursday
at
10
a.m.
all
right
on
to
the
good
stuff.
So,
typically,
we
take
questions
random
willy-nilly.
A
Whatever
comes
in
this
time,
I
actually
curated
them
a
little
bit
so
I'm
gonna
do
some
of
the
new
contributor
questions
first
and
then
try
to
move
on
to
the
current
contributors,
but
depending
on
the
flow
of
questions,
and
things
like
that,
we
might
jump
around.
But
we're
gonna
try
this
to
see.
If
this
makes
a
little
bit
more
sense
from
a
flow
perspective.
A
B
For
me
personally,
I
got
very
interested
in
distributed
systems
when
I
was
in
university.
I
had
a
graph
theory
professor,
who
proposed
a
couple
of
open
problems
to
the
class
and
I
started,
trying
to
brute
force
them
and
I
very
quickly,
found
that
I
needed
to
split
the
problem
up
between
computers
to
even
have
a
hope
at
that,
and
this
being
like
2013-2014,
a
lot
of
distributed
systems
attack
like
spark
and
so
on,
was
still
very
immature,
so
I
started
trying
to
build
my
own
system.
A
D
Thing
is:
I
was
a
PostgreSQL.
The
database
developer
for
many
years
and
I
started
working
on
how
to
automate
high
availability
for
post
was
because
I
was
consultant
doing
that.
A
lot
of
that
for
clients
and
I
actually
worked
on
two
different,
automated
high
availability
systems
that
we
developed
over
the
years
from
scratch
code.
Both
of
them
had
a
lot
of
issues
when
I
started.
A
So
lots
of
distributed
systems,
lots
of
high
availability
systems,
which
is
odd,
I,
mean
I,
know
it's
not
odd.
It
makes
sense,
but
for
to
have
all
of
you
on
the
on
the
call.
Usually
we
have
plenty
of
other
folks.
They
came
in
through
other
weird
ways
and
things
like
that's
really
cool.
So
we
always
get
the
infamous
question
of
saying:
do
I
join
where
do
I
start?
What's
a
cig
questions
or
how
you
would
respond
to
that
I
mean
it's
I'm
sure
all
of
you
on
the
phone
have
a
call
rather
apologize.
A
B
So
kubernetes
development
is
a
very,
very
huge
responsibility,
so
we
have
everything:
broken
up
into
groups
called
SIG's
for
a
special
interest
group,
the
SIG's
specifically
own.
They
have
a
specific
mission
statement
of
what
they're
supposed
to
do.
It
typically
translationally
owning
an
abstract
area
and
owning
specific
components
in
the
codebase,
for
example,
in
cig
network
who
are
responsible
for
like
the
network
connectivity
in
the
stack,
and
that
means
we
own
things
like
the
ingress
controller,
the
service
controller
Kubb
proxy
see
an
icepack
if
you're
looking
to
choose
a
cig.
B
First
thing
to
look
at
is
just
like
what
interests
you,
for
example,
like?
Are
you
interested
in
like
user
experience
of
workloads?
Perhaps
the
gaps
which
defines
things
like
deployments
and
staple
sets
would
be
a
good
fit.
Perhaps
you're
really
passionate
about
like
operations
and
usability,
then
maybe
like
sig
node,
which
manages
the
internals
of
a
worker
or
sorry
I'm,
blanking
coaster
lifecycle,
which
manages
like
the
upgrade
deprecation
management
cycle,
would
be
a
good
fit.
B
Also,
it's
fairly
easy
to
just
like
hop
in
hop
in
a
stock
channel,
look
up
people's
YouTube
recordings.
If
you
aren't
really
sure
about.
What's
going
on
and
want
to
kind
of
poke
your
head
in
multiple
things,
though
I
get
involved
in
too
many
things
and
I
would
caveat
that
definitely
like
one
one.
Sig
is
a
pretty
good
workload.
B
A
D
The
only
one
I'll
say
is,
in
addition
to
all
of
those
areas
which
are
going
to
depend
sometimes
in
what
you're
already
working
on
there's
also
a
lot
that
goes
into
running.
All
the
things
for
the
project,
and
often
the
SIG's
that
are
responsible
for
the
project
have.
D
If
you
are
QA
q
e,
automated
testing,
geek
DevOps
geek,
do
look
at
participating
in
test
infrastructure,
because
they've
got
a
to-do
list
a
mile
long
in
terms
of
doing
automated
testing
and
automation
of
kubernetes,
and
it's
also
really
interesting,
because
we've
done
a
lot
of
things
to
automate
kubernetes
project
around
github.
That
with
just
knew
that
that
goes
beyond
what
other
projects
have
done.
And
so,
if
you
really
are
interested
in
that,
not
only
do
we
need
your
help,
but
it's
an
opportunity
to
basically
do
new
stuff.
C
Sure,
I
would
say
a
one
possible
place
to
start
would
be
to
look
at
the
caps
that
are
open.
A
cap
is
a
kubernetes
enhancement
proposal
and
I
think
that
can
be
a
more
concrete
waves
of
looking
at.
Oh,
this
is
what's
being
done,
and
these
are
the
cigs
that
are
involved
and
often
times
that
maybe
can
be
a
little
bit
easier
to
figure
out.
Oh
am
I
interested
in
this?
Am
I
not
you
know.
Do
I
want
to
go.
C
A
Thanks
George,
yeah
and
David.
Thank
you
so
much
for
spelling
alpha
jargon.
We
have
a
lot
of
it
and
we
have
a
lot
of
lingos
and
you
know
yeah
yeah
I,
don't
need
to
tell
you
you're
like
we
do.
We
do
yeah,
providing
only
providing
context
is
one
of
the
things
current
current
kubernetes
contributors
can
help
out
with
the
most
as
it
relates
to
new
contributors.
Probably
I
know
22
months
ago,
I
was
one
as
well,
and
the
lingo
that
was
flying
around
was
definitely
like
wow.
A
A
They
feel
just
they're
overwhelmed
stepping
into
the
community
joining
the
slack
channels,
plus
a
lots
going
on
any
advice
for
people
who
are
a
feeling
overwhelmed
and
then
be
any
either
communication
platforms
or
anything
that
you
think
that
they
should
target.
That
would
be
more
wise
for
further
development
efforts.
C
I
can
speak
to
this
one
a
little
bit
every
once
in
a
while
I'll
walk
past
Tim,
Hawkins
desk
and
he'll
say
something
to
me
to
the
effect
of
I
I
can't
keep
up
with
this
anymore.
I
can't
see
everything
that's
going
on
at
once,
even
though
I
try,
and
so,
if
you
feel
like
that,
know
that
even
the
people
who
know
the
most
so
to
speak
in
the
project
can't
keep
up
with
it.
So
my
recommendation
is
generally
to
try
and
pick
a
reasonable
scope
that
you
can
get
the
depth
that
you
want.
C
So
for
me,
what
that
means
is
that
I
pay
attention
to
the
cubelet
and
it's
api's
for
monitoring
and
resource
management
and
I
only
pay
attention
to
certain
areas.
So
I
I
stay
up-to-date
in
a
specific
number
of
things
that
I
think
I
can
pay
attention
to
and
because
my
scope
is
pretty
small,
I
tend
to
know
exactly
what's
going
on
in
a
bunch
of
different
areas
and
I'm
very
up-to-date
in
those.
But
if
you're
someone
who,
for
example,
wants
to
know
what's
going
on
in
the
broader
kubernetes
community,
then
interacting
with
sig
p.m.
C
or
a
sig
release
and
looking
at
the
stuff
that
comes
out
of
those
channels,
I
think,
is
a
usually
a
broader
way
to
to
get
information
about
kubernetes
generally
in
all
the
things
that
are
are
happening
there.
Oh.
D
D
We
as
in
sig,
contribute
experience,
runs
a
new
contributor
workshop
at
each
coop
con
on
the
contributor
summit,
which
would
be
the
day
before
the
main
coop
con
or
two
days
before
the
main
coop
Gunn.
And
so,
if
you're,
actually
in
a
position
to
go
to
one
of
those
conferences,
you
can
do
that
as
a
crash
course
in
the
community
and
how
to
submit
changes
and
do
PRS
and
all
of
the
other
sort
of
basics
that
you
need
to
know
to
contribute.
A
B
B
That's
a
pretty
good
way
to
see
like
what
is
user
facing
that's
happening
or
like
requires
a
lot
of
coordination.
Siga
architecture
sometimes
is
a
good
overview
of
the
project
and
beyond
that,
when
I
don't
have
time
to
like
do
too
many
things,
at
least
to
look
at
people's
meeting
agendas
and
quickly
scrub
through
their
meeting
recordings.
So
I
can
maybe
spend
five
ten
minutes
instead
of
a
full
hour-long
meeting
to
figure
out.
A
Yes,
time
is
of
the
essence,
and
especially
in
kubernetes,
so
we
heard
from
we
heard
release
we
heard
news
contributor
workshop.
We
heard
a
lot
of
different
onboarding
avenues.
If
you
will,
what
are
some
avenues
that
you
see,
people
trying
that
you
don't
necessarily
think
is
the
most
successful
approach.
C
I
mean
I
would
say
the
classic
example
of
an
unsuccessful
approach.
Is
someone
who
comes
in
and
immediately
wants
to
make
a
large
change
to
kubernetes.
So
someone
who
comes
in
says
I
think
kubernetes
needs
this
and
we're
going
to
do
it.
I
think
it
can
be
hard,
especially
to
navigate
the
enhancement
process
and
to
navigate
the
SIG's
and
to
know
exactly
how
to
reach
out
to
them
and
how
to
effectively
advocate
for
the
change
that
you're
you're
trying
to
make
and
the
other
thing
is
that
often
times
you
know
I.
C
Okay,
that's
step
three
in
a
you
know,
one
two
three
step
process
so
oftentimes,
for
example,
in
sig
note
two
years
ago
we
set
out-
and
we
said
we
want
to
tackle
GPUs
and
other
devices,
and
we
want
to
make
topology
work
because
making
sure
CPUs
and
GPUs
are
matched
up
on
the
same
in
the
same
relative
place
on
your
on.
Your
board
is
important,
and
so,
but
we
ended
up
having
to
take
a
step
back
and
say:
okay,
we
have
to
leave
topology
for
later,
because
we
need
to
get
basic
device.
C
A
B
I
would
definitely
+1
that
I
might
also
add
that
this
experience
will
really
vary
depending
on
like
when
you
get
involved
with
the
project
and
what
you're
trying
to
work
on.
But
the
project
has
a
lot
of
volunteers
and
people
who
are
stretched
too
thin
and
just
like
our
size
and
structure,
means
that
it
can
be
hard
to
mentor
new
people
and
teach
to
people
about
the
project.
B
Like
there's
lots
of
resources
like
this,
like
some,
if
you,
if
you
kind
of
walk
into
the
project
and
say
like
I,
want
to
be
I,
want
to
be
taught,
I
want
to
be
like
guided
through
everything.
People
may
not
have
the
time
and
ability
to
do
that,
so
you
will
have
to
do
a
certain
amount
of
like
digging
for
work
and
going
to
the
code
and
teaching
yourself.
We
can
provide
the
resources
to
make
that
feasible,
but
we
can't
effectively
like
give
everyone
a
dedicated
teacher.
Yes,.
A
I
completely
agree:
that's
why
I
think
that
our
best
opportunities
for
people
who
really
want
mentoring
and
really
want
that
experience
is
through,
like
the
release
team
and
like
where
there's
already
teams
set
up
in
SIG's,
meaning,
like
teens,
might
like
that
you
might
have
triage
team
stuff
like
that.
Where
there's
already
like
a
shadow
role
and
that's
already
been
built
in
and
that's
a
great
mentoring,
deal
I'm
sure
Josh
shouldn't
talk
about
that
too.
A
But
if
that's
something
that
you're
looking
for
you
say,
hey
I
need
a
mentor,
go
to
a
saying:
ask
them
if
they
have
any
teams
that
you
can
join
teams
being
like
what
with
shadow
rolls.
That
is
the
like
one
of
the
best
pieces
of
advice
that
I
think
we
can
give
you
because,
like
David
alluded
to
it's
super
hard
to
get
a
feature
through.
When
no
one
knows
you
so:
okay,
especially
when
a
31,000
contributors
touch
our
repos
in
some
way,
I
call
it
some
event.
A
A
Cool,
thank
you
alright
and
then
so
next
question
I
think
it
was
a
network
one
if
I
recall
correctly
yeah.
Yes,
what
forsake
Network
any
starting
point
for
getting
into
validation
or
performance
testing
for
kubernetes
networking.
Would
it
be
useful
for
community
if
all
test
test
cases
already
done
and
dusted.
B
Suspect
that
I
mean
I'm
kind
of
passing
the
buck
with
this,
but
I
think
that's
a
cast
thing
would
be
a
good
place
to
talk
to.
As
far
as
like
some
of
the
frameworks
involved
in
that
like
we,
we
know
the
mechanics,
but
the
sig
doesn't
Signet
working
doesn't
deal
as
much
with
like
how
communities
test
infraworks
yeah.
A
D
D
The
and
I'm
not
I,
think
it's
too
complicated
to
be
suitable
for
automated
test
framework.
So
if
you're
a
network
performance
geek,
please
jump
on
that,
because
particularly
somebody
who
could
not
only
look
at
performance
for
that.
But
then
maybe
actually
look
at
some
of
the
causes
of
lack
of
performance.
If
that's,
what
you
find
would
be
awesome.
A
Yes,
I'd
also
think
I,
don't
know
if
I'm
gonna
work
those
correctly
but
we're
just
gonna.
Try
it
anyway,
but
I.
Think
scalability
is
one
of
those
special
interest
groups
where
it's
super
hard
to
break
through
or
break
in,
because
it
is
complex.
They
do
look
after
the
entire
system,
so
I
guess
my
TLDR
theirs,
don't
necessarily
get
discouraged.
If
you
are
one
of
those
self-identified
performance,
geeks
Josh
is
speaking
about
it's
something
that
is
complex
and
will
take
a
little
bit
of
a
ramp.
A
A
So
people
want
to
meet
you
apparently
I've
gotten
a
couple
dm's
and
then
there's
one
in
the
chat
about
someone
asking
if
you're
going
to
home
summit
when's
the
next
conference
that
folks
can
meet
you
face
to
face
or
what
are
some
of
the
conference's
that
you
have
on
your
agendas
for
the
next.
You
know
until
the
end
of
the
year
cube
con
San
Diego.
Anyone.
A
A
D
A
It's
pretty,
it
looks
pretty
yeah
I
can't
believe
that
it's
already
here,
hello,
Chang,
hi
yeah.
So
if
anybody
is
going
to
cube
con
Shanghai,
that's
a
good
announcement
and
plug
is
yes.
There
will
be
a
new
contributor
workshop
there,
but
if
you're
also
a
current
contributor
they're
hanging
out
and
having
some
fun
and
doing
some
networking
there
too
so
go
and
meet
some
folks
if
you're
in
Shanghai.
A
A
No
on
the
recording,
we're
gonna
have
to
snip
out
David's
face
right
there.
That
was
hilarious.
He
was
really
scared
for
a
second
okay
like
I'm,
not
rhyming,
anything
someone's,
no
other
contributor
workshops
prior
to
the
summits
recorded.
Yes,
they
are
indeed
you
can
look
those
up.
There
is
a
link
actually
that
Castro
Joe
put
in
there
right
above
feel
free
to
click
that
link.
We
have
I
think
two
or
three
sets
of
new
contributor
workshops
report
it
now.
A
We
should
probably
take
like
the
first
one
down
just
out
of
stale
information,
but
always
check
out
the
last.
That
would
be
in
Cuba
on
Barcelona
and
then
all
right,
I
have
a
couple
of
current
contributor
questions
in
my
DMS
right
now,
but
I'm
looking
in
the
chat
to
make
sure
we're
covered,
looks
like
we're
good
for
chat
questions
all
right.
First,
current
contributor,
we,
which
is
a
popular
question
as
of
late,
which
is
tell
me
how
you
give
yourself
or
provide
yourself
self-care.
How
do
you
avoid
burnout?
A
No
comment:
aka
Valerie
is
currently
not
saying
right
now,
no
just
kidding
yeah
I'm
trying
to
shed
load
and
optimize
what
I'm
working
on
right
now
and
that's
important
to
know
and
to
recognize
a
saying:
no
is
fine,
and
so
is
saying:
hey
I,
just
don't
have
the
time
to
work
on
this,
so
it's
totally
respectable.
Take
care
of
yourself
David.
What
about
you,
yeah.
C
C
It
might
still
be
open
actually
but
worked
and
made
some
progress
and
solve
some
problems
that
we
hadn't
been
able
to
solve
before
and
it
still
didn't
quite
meet
the
bar
and
so
I've
had
to
just
set
it
aside
and
work
on
other
things.
Just
because
it's
okay
not
to
succeed
at
getting
a
feature
in,
or
sometimes
it's
just
not
the
right
time
in
the
community.
So
working
on
just
a
couple
things
at
once
and
making
sure
that
you're
able
to
focus
on
it
is
is
really
important.
A
A
D
D
D
You
know
I
go
to
conferences
as
part
of
my
job
running
redhead
boots
at
conferences,
running
contributor
summits
and
which
of
other
things,
and
so
this
year,
a
bunch
of
stuff
just
stacked
up
right
next
to
each
other.
So
Seattle
DevOps
days
da
Kirk
on
Red
Hat
summit,
koukin
Barcelona
percona
live
another
smaller
event
in
the
middle
somewhere,
the
which
is
just
a
really
bad
idea,
because
if
nothing
else,
the
constantly
shifting
time
zones
really
gets
deal.
A
Yes,
that
is
definitely
self-care
as
well.
Time
in
between
events
is
wonderful,
all
right.
Thank
you
all,
and
then
there
was
also
if
you're
listening.
There
was
a
bernal
panel
that
was
recorded.
I
think
I
have
not
seen
the
recording,
but
there
was
a
recent
burnout
panel
at
cucumber
salona.
If
you
want
to
search
for
that
on
YouTube,
that
was
very,
very
good.
I
know
tons
of
people
who
went
and
some
of
the
panelists
who
had
a
good
time
doing
it.
So
you
should
definitely
check
that
out
as
well.
B
I
think,
in
my
experience,
one
of
the
biggest
things
is
to
be
very
clear
about
the
scope
and
intended
changes
which
includes
like
strong
communication
skills
as
to
what
you're
proposing,
as
well
as
being
very
judicious
about
what
you
put
in
the
non
goals
section.
So
when
we
write
a
cap,
we
have
a
so
excited
goals,
for
we
also
list
a
section
called
non
goals,
which
is
basically
meant
to
be
anything
that
is
potentially
like
a
logical
conclusion
or
related
that
we
don't
want
to
touch.
B
So
that's
a
good
way
to
get
people
to
focus
on
exactly
what
you
proposed
versus
have
like
a
gigantic
bite,
shedding
argument,
as
well
as
focusing
on
like
each
specific
kept
phase.
So,
for
example,
provisional
is
just
meant
to
be.
We
agree
that
we
would
like
to
do
this.
We
think
the
like
thing
that's
outlined
is
not
unreasonable.
So
let's
push
it
further
versus
having
like
a
production-ready
plan
at
that
phase.
A
The
way
I
just
had
another
question,
that's
sort
of
similar,
so
in
the
same
breath,
let's
talk
about
somebody
wants
to
know
how
you
get
it
in
front
of
the
right
people.
So
how
do
we
with
tips
on
getting
it
through
like
a
consensus
period
and
then
tips
on
getting
it
in
front
of
the
right
people?
B
B
C
Was
gonna
say
going
and
thinking
about
it
in
a
couple?
Different
phases
can
be
useful,
so
at
first
you're
really
trying
to
spread
the
word
about
the
need,
and
so
you'll
go
to
SIG's
and
you'll.
Say:
hey
like
this
is
a
problem.
I
really
think
we
should
solve,
and
I
really
think
it
should
be
on
your
roadmap
for
117
right
and
before
you
necessarily
step
in
with.
Oh
here's,
my
you
know
prescribed
solution,
and
this
is
what
I
want
to
do
so
coming
forward
with
the
problem.
C
First
doing
your
homework
and
coming
in
with
exact
like
production,
examples
are
really
powerful,
I
think
in
cigs,
because
contributors
don't
necessarily
always
have
a
production,
kubernetes
cluster
up
and
running
that
they
can.
You
know
when
you
come
to
them
with
a
problem
they
can
go.
Oh
yeah
I
hit
that
all
the
time
right,
because
we
don't
always
run
a
lot
of
kubernetes.
We
just
work
on
it
so
coming
in
doing
your
homework
and
and
having
all
the
evidence
that
this
is
a
big
problem
area
and
that
the
SIG's
should
address
it.
A
D
B
A
All
right
and
then
David
I
actually
dropped
a
question
for
you
in
Zune
chat
that
might
need
some
homework
for
you
to
answer
beforehand
so
check
that
out
and
then
we'll
go
into
the
next
question.
Next
question
for
current
confront
current
contributor.
It's
talking
about
building
trust
they're,
saying
that
they
are
doing
a
lot
of
smaller
tasks.
Smaller
PRS
cleanup
work
things
along
those
lines
like
at
what
point
in
time.
Do
they
have
the
conversation
or
does
somebody
else
have
the
conversation
as
to
like
how
they
get
into
an
owner's
file
like?
A
C
It's
like
sure
it
gives
you
the
ability
to
merge
stuff
when
I
added
myself.
It
was
mostly
because
I
felt
that
one,
the
current
approvers
and
the
directories
that
I
had
would
look
to
me
anyways
to
approve
the
change
and
to
that
I
think
the
objective
is
more
around
reducing
the
burden
for
higher-level
approvers,
then,
for
you
know
giving
anyone
in
particular
any
extra
privileges.
D
If
you
just
feel
like
you,
don't
get
enough
email
from
github
right,
I
all
be
inside
yourself
to
notice
files
guarantee
that
your
mailbox
will
never
be
empty.
I
will
also
say
that
owners
files
are
not
necessarily
even
limited
to
code
most
of
the
the
owner
files
that
I'm
in
are
for
things
like
a
new
contributor
workshop,
etc.
D
A
It
sounds
like
you
know,
TLDR
for
experience.
There
is,
if
you're
writing
the
code,
if
you
know
a
lot
of
the
code
or
Doc's
or
community
management,
anything
that's
in
anything,
that's
in
our
repos.
If
you
think
you
know
this
solidly
and
people
come
to
you
for
advice
on
it.
You,
when
I
PR
yourself
into
the
owners
file
and
have
that
conversation
with
the
rest
of
the
rest
of
the
owners,
files,
folks,
so
yeah.
You
know
they
are
all
right.
Valerie.
E
A
Valerie,
do
you
have
a
different
take
or
an
additional
take,
or
anything
like
that,
not
really
I'm,
not
in
yet
by
the
way,
yet,
anyway,
David
did
you
get
a
chance
to
check
out
that
question
about
the
image
GC
and
where
it's
doing
it's
checking's
yeah.
C
A
C
Can
explain
garbage
collection
a
little
bit
so
the
code
that
does
garbage
collection
is
in
the
image
GC
manager,
which
is
package,
cubed
images,
image,
GC
manager
and
the
way
that
it's
currently
structured
is.
It
has
two
functions
that
tend
to
get
called
frequently.
One
is
garbage
collect
and
one
is
delete.
Unused
images.
C
Garbage
collect
is
based
on
the
image
GC
policy
that
you
specify
with
cubelet
flags.
So
you
said
what
you
think
the
high
percentage
should
be
and
then,
when
it
hits
the
high
percentage,
what
the
low
percentage
it
should
garbage
collect
down
to
is,
and
then
how
long?
Oh,
that's
that's
new
I
haven't
seen
that
before,
but
it
looks
like
there's
also
how
long
an
image
can
has
to
exist
before
it
can
be
removed
and
the
image
garbage
collector
interfaces
with
the
stats
collection
system.
C
C
Interestingly,
this
code
path
is
triggered
by
two
different
mechanisms.
One
is
the
one
I
just
talked
about,
which
is
if
I
can
find
at
the
end.
I
can
go.
There
is
which
is
setting
the
high
and
low
thresholds
for
image.
Garbage
collection
and
the
other
path
is
actually
addiction.
So
if
you
run
your
node
out
of
disk
say
because
of
POD
created
an
empty
derp
and
used
it
all,
then
before
it
goes
into
bits
here,
your
workload
it'll
actually
go
and
try
and
reclaim
images
that
aren't
being
used.
C
A
Sorry
that
might
get
trimmed
out
for
the
youtubers
who
want
to
know
about
garbage
collection
Hey.
Thank
you
so
much
that
was
awesome.
That's
sort
of
a
good
segue
into
the
next
question
which
this
current
contributor
wants
to
know.
Are
there
any
areas
of
the
project
that
you
work
on,
that
you
see
contributors
making
either
the
same
mistake
or
like
you
wish.
You
could
tell
contributors
and
mass
this
one
thing
like.
What's
up
one
thing
and
why.
A
D
Don't
know
it's
it's
specific
to
different
groups.
I
mean,
like
one
sort
of
you,
know,
ongoing
problem
that
we
see
with
people
who
are
contributing
as
part
of
a
corporate
team
is
that
they
will
all
of
a
sudden
show
up
with
a
big
chunk
of
code
and
say,
hey
here's.
This
thing
that
we
would
like
to
have
in
kubernetes
with
no
sort
of
preface
to
it,
and
that
code
is
almost
never
acceptable
under
those
circumstances,
because
it'll
turn
out
to
clash
with
other
things,
we'll
have
the
wrong
style
would
be
in
the
wrong
place.
D
If
you
were
team,
where
you
work,
wants
to
contribute
something
to
kubernetes
or
whatever
get
involved
with
the
appropriate
sink
or
SIG's
early
talk
about
what
you're
doing
and
why
you're
doing
it
and
people
will
give
you
tips
in
how
to
properly
connect
that
into
kubernetes
rather
than
trying
to
just
do
a
code
dump,
which
I
mean
it's
not
just
kubernetes
I've
worked
on
other
open-source
projects
in
and
large
code
dumps,
pretty
much
always
end
up
being
a
lot
more
work
than
if
you
started
working
with
the
existing
project
contributors
to
begin
with.
B
Maybe
I'll
just
rehash
a
point
that
I
kind
of
alluded
to
earlier,
which
is
that
I
was
like
a
volunteer
contributor.
I
get
a
lot
of
perspectives.
People
who,
like
are
going
to
also
volunteer
their
time
reaching
out
to
me
and
I
think,
like
the
biggest
factor
of
success,
I
see
us
how
much
legwork
people
are
willing
to
do
like
some
people
are
just
jumping
in
on
issues
and
asking
questions,
and
other
people
like
really
want
to
be
want
to
be
guided.
They
haven't
read
the
developer
guide,
they
aren't
gonna.
Look
at
the
code.
B
They
just
want
to
be,
like
pointed
and
kind
of
like
have
their
hand,
guided
and
I.
Don't
think
that
for
a
lot
of
SIG's,
that's
something
that's
going
to
be
successful,
I,
think
kind
of
going
out
there
and
participating
and
finding
work
and
making
sure
that
you
are
up
to
date
is
gonna,
be
the
best
way.
So
that
can
mean
like
looking
at
the
codebase
relevant
things
like
contributor
guides,
going
to
meetings.
C
Or
working
on
issues
that
may
eventually
like,
if
you're
you
open
an
issue,
maybe
someone
else
can
resolve
it
before
before
it
needs
to
involve,
like
the
lead
of
a
cig,
for
example,
yeah
guys
I
would
think
I
think
that's
the
biggest
surprise
people
have
is,
even
though
it's
an
open
community.
The
people
who
have
a
lot
of
responsibility
tend
to
be
way.
Overloaded.
Yes,.
A
And
such
as
open
source
last
question,
do
any
questions
for
each
other.
Now
that
you've
been
doing
this
thing
for
an
hour,
I
don't
know
if
you
knew
if
you
knew
each
other
beforehand
any
questions,
because
this
is
a
lot.
This
is
the
last
question,
the
meta
one,
all
right
that
wraps
our
show
for
June.
A
If
anybody
that's
watching
would
like
to
reach
out
to
any
of
us,
we
are
on
slack
as
David
mentioned.
I
think
you
can
I'm
sure
you
can
find
us
from
our
handles
that
we
have
here
on
Zoom
I'm
Paris.
There
is
two
Pierce's
actually
now
in
the
kubernetes
slack
instance,
pretty
crazy,
66,000
people,
you
would
I,
guess
there's
going
to
be
to
Paris's,
so
yeah
find
us
meet
our
contributors
slack
Channel
next
month,
we'll
be
here
same
time
same
place.
Thank
you.
So
much
panelists
you've
helped.