►
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.
For more information: https://github.com/kubernetes/community/blob/master/mentoring/meet-our-contributors.md
A
Hi
everyone,
my
name,
is
Paris
I
work
at
Google,
welcome
to
December
5th
edition
of
meet
our
contributors.
Today
we
are
joined
by
two
awesome.
Current
contributors
also
Jeff
who's,
our
one
he's
our
on
our
ones
and
twos
live
streaming.
Youtube
for
us
well,
George
is
unfortunately
not
available
for
us.
Today,
however,
we
are
going
to
get
down
to
business
and
what
this
next
hour
is
going
to
provide.
Everyone
is
a
quick
answer
and
our
question
and
answer
session
for
these
current
contributors
on
all
things
upstream,
kubernetes.
A
First,
we'll
start
out
with
some
introductions,
but
first
things.
First,
everybody
should
be
aware
that
we
do
abide
by
the
cloud
native
compute
foundations
code
of
conduct,
and
that
means
please
for
please
be
respectful
to
each
other
on
all
of
our
communication
mediums
we're
going
to
be
answering
questions
today
on
slack,
so
that
would
include
there.
That's
the
meet
our
contributors
channel.
A
You
can
also
find
me
in
direct
message
on
slack
if
you
would
rather
remain
anonymous,
and
then
you
can
also
find
me
on
Twitter
and
feel
free
to
reach
out
to
me
on
any
medium
and
we're
gonna
go
right
into
introductions
so
Justin.
Why
don't
you
quickly
give
it
give
folks
an
introduction
on
yourself
how
you
got
into
kubernetes
what
you've
been
working
on?
Go
ahead.
Awesome.
B
C
Hi
I'm
Zach
core,
listen,
I
am
one
of
the
chairs
of
cig
Doc's.
How
did
they
come
to
kubernetes
about
a
year
and
a
half
ago
I
met
a
colleague
at
Google.
I
had
just
left
github
and
my
colleague
said:
hey
I've
got
this
cool
documentation
said
I
want
you
to
work
on.
We
could
do
that
and
they
said
that
sure.
What
is
it
and
they
sean
is
how
that
went.
C
Things
that
I
love
doing
in
kubernetes,
sig
Docs
new
contributors,
I
love
getting
new
contributors
in
the
door.
Sig
Docs
is
one
of
the
easier
paths
into
kubernetes
membership
and
there's
a
well-established,
well
defined
contribution
guide
for
how
anyone
anyone
anywhere
can
review
PRS,
contribute
to
kubernetes
documentation
and
become
a
member
of
the
kubernetes
or.
A
B
D
B
Real
difference
and
has
a
lot
of
people
actually
using
it
I
think
some
of
the
reasons
for
that
are
that
at
least
initially,
you
know
they
were.
The
sort
of
the
majority
of
the
contributors
were
from
Google
and
Red
Hat
and
I
feel
like
Google
brought
sort
of
like
a
long-term
roadmap
from
their
boring
experience
and
Red
Hat
brought
a
sort
of
hands-on
like
we
need
to
make
it
be
a
useful
pass.
B
In
terms
of
you
know,
how
do
we
grow
a
project
that
has
been
to
date
very
successful
and
has
far
more
people
in
it
that
can
think
and
like
meaningfully
work
in
a
single
get
everything,
and
so
we
have
the
technical
infrastructure
to
enable
things
like
CR
DS,
which
lets
you
know
you
collaborate
on
in
disparate
projects
and
we
have
the
sort
of
governance
infrastructure
to
let
a
lot
of
projects,
collaborate
without
all
clobbering
each
other.
But
there
are
a
lot
of
other
good
projects
which
are
also
worthy
of
your
time,
I'm
sure.
C
Well,
partially
I
stumbled
into
it.
I
had
never
fully
worked
on
an
open-source
project
before
I
had
contributed
sort
of,
incidentally,
to
like
Adam
at
github,
but
I
guess.
Kubernetes
was
intriguing
to
me
because
at
at
Rackspace
the
when
we
were
first
talking
about
docker
at
Rackspace
and
about
this
whole
idea
of
containerization
I
found
that
I
found
that
tremendously
interesting,
and
so
when
the
first
time
that
someone
described
kubernetes
to
me
as
container
orchestration
I
halfway
knew
what
they
were
talking
about.
C
I
knew
the
container
part,
but
not
the
orchestration,
so
it
was
intriguing
and
that
that
made
kind
of
a
natural
fit
I
should
point
out
right
now
that
I'm
working
at
the
Linux,
Foundation
and
so
I
am
working
in
open
source.
All
the
time
now
and
kubernetes
in
particular,
is
I,
think
I've
come
to
love
open
source
like
overall,
through
kubernetes
kubernetes
was
my
intro
to
open
source
as
an
area
of
contribution
and
I
love
it.
C
C
So
I
have
become
a
lot
less
shy
about
just
putting
questions
about
how
things
work
out
into
the
world,
because
I
am
constantly
and
routinely
surprised
by
who
knows
what
so
there
are
I
would
say
that
with
proprietary
projects,
there
is
the
appearance
of
information
silos
and
they're
there.
There
is
a
well-defined
pool
of
expertise
that
then
isn't
actually
the
total
pool
of
expertise
and
with
open
source.
The
pool
of
expertise
is
really
democratic.
C
B
I
think
the
big
difference
is
the
sort
of
number
of
people
involved.
I
think
you
know,
even
in
we've
done
a
lot
of
work
to
make
it
so
that
I
don't
know
how
many
contributors
communities
has
presumably
Paris.
You
can
tell
me
that
I
think
it's
at
least
thousands,
if
not,
that
might
be
or
off
by
worse
Matthew,
but
thousands,
let's
say
and
think
they
they're
not
all
like
working
on
the
same
file,
and
certainly
you
know-
that's
definitely
spread
across
directories
and
across
repos.
B
But
you
know
we
have
hundreds
of
contributors
on
pops
and
obviously
there
some
of
them
contribute
a
lot
more
than
others.
But
everyone
is
very
welcome
and
it's
great
to
see
any
contribution
and
it
makes
it
harder
to
get
that
when
you're
working
on
a
something
which
is
more
just
you
know,
in
a
commercial
organization,
you
might
own
a
particular
subsystem
entirely
and
you
have
to
make
it
work
for
you
and
they
it's
more
a
small,
a
smaller
group
and
you
know
open
source.
B
A
For
that's
a
perfect
segue
into
the
next
question,
actually,
which
is
from
a
current
reviewer,
and
they
are
looking
for
tips
on
how
to
deal
with
the
in
with
an
influx
of
type
OPRS
and
things
that
are,
you
know,
either
extra
small
or
not
necessarily
priority,
and
it's
taking
up
all
taking
up
time.
What
are
some
I
guess,
best
practices
or
tips
and
I
know
Zack
I
think
you
have
probably
has
some
best
practices
here
as
well,
but
what
are
some
best
practices?
Justin?
A
B
B
B
It
was
sad,
ipv6
support,
so
you
know
I'm
sure
we'll
have
collective
u6
support,
but
you
know
I
I
I
do
think
that
I
personally
think
that
Type
O
PRS
are
a
great
way
or
smaller.
Prs
are
a
great
way
into
the
project.
I
they
they.
They
don't
take
much
time
to
review
individually.
So
I
tend
to
motivate
myself
by
thinking.
Oh,
you
know
it's
another
point
on
def
stats
or
whatever
it
is
or
another
point
on
like
the
github
graph
right
now.
A
B
We
can't
necessarily
do
that
in
in
community
communities,
where
a
very
subtle
change
can
like
cause,
hundreds
of
thousands
of
people,
hours
and
hours
of
lost
times
with
like
double-checking
that
every
I
and
cross
every
T.
But
when
that's
not
the
case,
I
do
think
it's
good
too.
If
it's
not
going
to
really
break
things,
we
can
just
let
it
in
so
I'm
in
favor
of
rapid,
merging
and
I'm
in
favor
of.
If
you
want
to
do
a
type
of
PR.
B
That's
fine
by
me:
please
don't
send
me
a
million
like
it
over
the
next
hour,
but
you
know:
that's
it's
great
and
I.
Think
it's
great!
We
get
into
the
project.
I
do
think
we
don't
necessarily
have
to
have
them
I,
don't
think
you
should
do
titled
yards.
If
that's
your
only
intention
in
the
project,
it's
valuable
but
I
think
it's.
Oh,
it's
a
weigh-in
and
you
should
leave
that
weigh-in
for
others.
If
you're,
not
you
can't
to
get
into
the
project,
I.
C
So
we
do
get
a
lot
of
typos
PRS,
maybe
someone
obviously
so
for
us.
It
is
actually
kind
of
a
it's
great
to
see
the
work
in
the
contribution,
but
occasionally
we'll
get
a
really
enthusiastic
contributor
who
open
will
open
the
PR
for
like
a
one-character
change
and
in
those
cases
we
ask
folks,
hey
just
bat,
your
bat,
your
PRS,
like
gather.
C
The
way
that
we
review
PRS
in
sync
Docs
is
maybe
a
different
question,
but
we
have
a.
We
have
a
review
process
that
we
try
to
keep
the
number
of
PRS
open
in
NK
website
like
under
a
hundred
when
things
get
over
a
hundred,
that's
usually
a
sign
that
we're
not
keeping
a
head
of
the
work.
So
we
ask
folks
to
batch
batch.
Their
PRS
bundle
bundle
changes,
so
we
occasionally
get
like
someone
will
run
a
linter
on
on
blog
posts
and
things
like
that
and
that's
great.
C
A
litter
is
something
that's
it
so
the
phrase
linter
comes
from
like
a
lint
brush
where
you
brush
to
brush
the
lint
off
of
a
sweater
and
make
it
look
nice.
So
it's
something
that's
a
linter
is
a
piece
of
software
that
you
run
to
make
your
code
pretty
or
that
changes
the
format
to
look
nice
and
conformant.
C
It's
a
it's
a
way
of
quickly
catching
routine
typos
broken
links,
things
like
that.
So
it's
basically
it's
it's
the
equivalent
of
doing
the
sort
of
light,
light
housekeeping
on
documentation
and
it's
valuable,
but
we
usually
we
ask
for
especially
for
blog
posts
that
people
can
find
changes
to
blog
post
within
the
past
year,
because
older
than
that
we'll
let
it
ride.
A
B
A
What
about
you
like?
What
if
you
ever
been
a
time
where
your
you
know
your
owners
have
said
like
hey
I,
don't
know
what
to
do
with
this
with
this
contributor
because
they
are
just
keep
you
know
getting
into
the
extra
small,
slash
typo
fixes,
and
it
would
be
nice
if
we
can
kind
of
step
in
and
have
you
ever
done,
that
kind
of
a
mentoring
or
coaching
with
a
contributor
before.
C
C
A
new
contributor
will
come
in
and
just
be
very
enthusiastic
about
their
contributions,
but
usually
we'll
see
like
a
pattern
like
someone
will
open
like
five
to
ten
PRS
of
the
same
sort
in
a
row
and
our
reviewers
are
really
good
about
stepping
in
and
saying
hey,
please,
please
bundle
these
all
together
or
they
can
in
a
case
where
it
would
be
like
more
effort
to
actually
go
through
and
close
all
the
PRS
will
say
hey
next
time.
Please
do
this
please,
but
please
bundle
small
changes
together.
C
So
it's
I
mean
I,
don't
think
it's
a
case
of
gamification
so
much
as
it's
just
really
enthusiastic
contribution
and
it's
great
to
have
that
enthusiasm,
and
so
that
kind
of
that
kind
of
active
intervention.
We
always
want
to
be
really
gentle
with
with
people
who
are
coming
in
and
contributing
valuable
work,
but
yeah
we
do
step
in
and
and
ask
folks
to
I
guess
be
more
mindful
of
of
their
of
the
contribution
process
and
the
things
that
are
going
to
make
it
easier
for
their
work
to
get
reviewed
and
more
likely
to
get
merged.
A
Two
different
approaches,
which
is
good
I,
like
that
that
just
shows
contributors
that
they
again
should
be
mindful
of
where
they're
contributing
for
everybody
listening
each
repo
better,
have
a
contributing
MD
file,
I,
guess
that
was
a
subliminal
message
to
all
of
my
maintainer
Zout.
There
I
know
Justin's
like
to
my
yes
and
those
contributing
markdown
files,
typically
point
back
to
our
main
contributing
guide.
However,
plenty
of
other
special
interest
groups
and
maintain
errs-
and
things
like
that-
have
indeed
housed
their
own
contributing
markdown
file.
A
A
This
is
a
good,
a
good
test
for
everybody.
That's
listening,
like
do,
I
have
a
contributing,
markdown
file.
Let
me
check
on
that.
Yes,
that's
really
good
and
yeah
for
everybody
listening.
You
can
always
point
it
directly
to
the
mean
contributing
guide,
that's
in
the
community
folder
and
again,
if
you
have
some
kind
of
special
characteristic
about
your
special
interest
group
or
a
working
group,
or
what
what
have
you
included
in
your
contributing
markdown
file.
A
That
is
like,
if
you
think
that
contributors
out
there
are
doing
things
that
you
don't
necessarily
want
them
to
do
or
behaving
away
and
your
workflow
that
you
don't
necessarily
want
them
to
to
behave
or
you
want
to
welcome
certain
certain
positive
behavior
characteristics,
etc.
All
of
that
stuff
is
excellent
for
a
contributing
guide,
and
then
you
can
always
point
folks
to
that
contributing
guide.
As
you
are,
you
know
identifying
behavior
that
isn't
really.
A
You
know
good
for
you
like
again
in
a
case
where
someone's
submitting
you
know
tons
of
typos,
you
can
always
say:
hey
this.
You
know
read
this
contributing
guide.
This
has
some
step-by-step
guide
and
how
to
get
involved
in
a
more
valuable
way
and
things
along
those
lines.
So
that
was
just
my
my
little
tidbit
there
so
earlier
this
morning
we
actually
had
a
lot
of
questions
around
cube
con.
B
B
You
for
an
absolute
beginner,
you
can
do
like
your
first
PR
and
through
miss
I,
think
mostly
Google
folk,
but
some
people,
they're
helping
you
know,
show
how
to
do
a
PR
and
in
terms
of
the
mechanics
of
that
I
think
if
you're
I
think
in
general
I
would
think
about
what
your
interest
is.
I
think
it's
very
difficult
for
someone
that
just
wants
to
contribute
to
communities
to
sort
of
know
where
to
start
and
so
I
think
you
know
everyone
has
something
they're,
particularly
interested
in
and
passionate
about
or
more
so
than
others.
B
So,
like
you
might
like
networking
where
you
might
like
authentication
or
you
might
like,
whatever
it
is
a
the
u.s.
for
GCP,
and
there
are
six
that
are
oriented
around
most
of
the
broad
areas
of
turbidities
and
I.
Think
all
the
states
have
an
intro
session
or
almost
all
the
six
of
an
intercession
and
they
dive
one
or
more
deep
dive
sessions,
and
so
I
think
thinking
about
where
you,
where
your
interests
align
and
attending
sort
of
the
well,
if
you're,
totally
new
to
the
sigmund.
B
Definitely
well
it's
a
good
you're
saying
the
intercession
regardless
and
then
get
it
the
deep
dive
session
to
probably
a
great
way
where
actually
a
lot
of
a
lot
of
design
or
discussion
around
design
happens
and
you
can
sort
of
understand
how
the
sinks
operate.
In
my
experience,
my
mother's
actual
decisions
get
made
even
in
the
deep
dive
sessions,
but
it's
good
to
have
people
meet
face
to
face
and
a
lot
of
discussions
happen.
Those
discussions
continue
happening
in
zoom
meetings
and
then
on.
It's
happen,
issues
and
design
Docs.
So.
B
A
A
Actually,
two:
there
is
a
Monday,
that's
sold
out
with
a
hundred
and
ten
people,
and
then
there
is
Tuesday,
which
I
think
is
already
like:
weightless
stain
as
well
yeah
I
know
just
for
everybody
that
didn't
listen
to
the
morning
session.
We
are
onboarding
almost
300
contributors
next
week,
so
that
is
significant
and
get
those
Help
Wanted
and
good.
First
issue
labels
out
there
at
all
for
real
people
are
gonna,
be
poking
around
in
your
repos
speaking
of
typos
they're,
going
to
be
poking
around
in
your
repos.
A
So
it's
way
better
to
get
those
labels
out
and
done
I'm
actually
going
to
send
an
email
out
to
our
chairs
and
tech
leads
in
the
next
day
or
two
to
remind
them
of
that
as
well,
but
yeah.
That's
both
both
of
those
are
great
tips.
I.
Definitely
think
that
the
deep
dive
sessions
are
awesome,
myself
and
I.
Think
that's
worthwhile
people
always
say:
oh
I
want
to
meet,
maintain
errs.
You
know
how
do
I
do
it?
That's
how
you
do
it?
That's
really
the
the
best
way
to
do
it.
A
C
B
C
Would
say
if,
for
whatever
reason,
you're
not
able
to
make
it
to
that
process,
pay
a
mind,
especially
in
the
slack
afterwards,
because
we'll
be
publishing
and
talking
about
those
results
in
our
slack
Channel
after
that,
so
I
would
say
that
slack
is
probably
the
the
most
active
way
to
get
involved
and
follow
what's
happening
with
Sigma
X.
That's.
B
Yes,
although
we
don't
make
decisions
about
what
I
think
is
really
great
about
the
coupon
format.
Is
we
get
people
that
are
not
necessarily
the
fuel
that
show
up
every
week
and
have
variable
perspectives
that
are
not
sorry,
the
ones
we
get
every
week
and
they're
like?
Well,
that's
not
going
to
work
for
us
type
saying,
and
that's
really
wonderful
to
hear,
because
you
know
a
lot
of
the
times.
A
I
think
it's
cool
you'll
also
probably
see
people
who
are
running
it
in
production
as
well,
and
they
just
kind
of
want
to
keep
up
with
that.
One
thing
that
that
sig
is
working
on
so
that
they
can
make
sure
that
you
know
when
they're
building
out
their
things
that
they're
they're
covered
so
I
think
that's
a
great
way
to
to
get
feedback,
get
it
give
it
close
those
loops.
That's
what
happens
at
these
events.
I
also.
B
A
Yeah
and
guess
the
good
news
there
I
mean
it's
good,
it's
good
flash
bad,
but
the
good
slash
bad
news
is
that
it's
sold
out.
We
have
a
hundred
and
eighty
people
that
were
signed
up
that
wanted,
mentorship,
I,
know
Justin's
like
and
but
we
only
have
sixty
mentors.
So
if
you
are
out
there
and
want
to
mentor
and
Justin-
and
you
really
love
that
7:45
in
the
morning
local
time,
slot
Justin
I
think
it
should
be
very.
A
No-
and
that's
just
remember
that's
the
morning
that
the
night
before
is
cube.
Con
I
mean
it's
ice,
cube
con,
so
ice
cube,
but
Jeff's
awake
from
YouTube
streaming
right
now,
like
so
ice
cube,
is
playing
the
night
before
our
mentoring
slot,
so
I
think
our
7:45
a.m.
is
going
to
be
super
fresh
in
more
ways
than
one
but
yeah.
If
you
are
listening
out
there,
and
you
want
to
help
us
out
with
mentoring,
CNCs
sent
out
a
notice
I
think
it
was
the
last
week
for
mentor
and
mentee
sign
ups.
A
A
I
need
to
reiterate
that
to
everybody
I'm
going
to
reiterate
that
until
them
blue
in
the
face
until
everybody
understands
you
do
not
need
to
be
an
expert
ever
to
mentor
anything
your
experience
as
a
new
individual
in
this
community
as
equally
as
valuable
as
the
expert,
because,
again
it's
about
the
journey,
not
the
solution,
everybody's
learning
together
there
is
power
and
peer
mentoring.
That
is
my
that
was
my.
That
was
my
soapbox
there
for
a
second.
This
is
mentoring.
A
Y'all
right
here,
we're
answering
questions
that
people
would
typically
answer
or
typically
I,
ask
a
mentor.
So
mentoring
comes
in
many
varieties
and
I
think
everybody
should
just
be
open
to
it
and
say
why
not
so
if
both
of
you,
if
any,
if
you
could
send
it
out
to
your
member
your
membership
as
well,
to
ask
them
if
anybody
would
like
to
mentor,
we
would
love
to
have
them
right
now.
A
B
A
Yes,
yes,
I
know
there
was
there
was
a
little
snafu
there
in
the
beginning,
where
you
couldn't
specify
which
session,
but
now
we
have
that
covered.
So
definitely
definitely
do
that
all
right,
while
I
look
for
our
next
question
here,
do
either
of
you
have
questions
for
each
other.
Justin
is
there
anything
you've
ever
wanted
to
know
about
Docs
or
is
there
anything
you've
ever
wanted
to
know
about
cobs,
cluster
API
or
every
other
little
itty-bitty
thing
that
Justin
works
on
I?
A
C
So
Justin
with
clustered
DNS
inheritance,
there
was
an
issue
a
while
back
about
who
owns
featured
feature
documentation
for
how
cluster
inheritance
behaves.
The
issue
that
we
ran
into
was
that
with
cluster
DNS
inherited
specifically
at
the
node
level.
If
you
said
there
is
a
value
called
default,
the
default
is
not
the
default
behavior
so
who
owns
that
feature
documentation,
because
it's
describing
what
happens
for
dms
inheritance
at
the
node
level,
so
is
it
seeing?
Is
it
signaled
that
ODEs?
It
is
it's
in
cluster
lifecycle,
as
it's
in
cluster
ops
who
owns
this
or.
D
B
It
out
I
think
I
think
it's
fine
to
have
a
good
guess
what
personal
I
think
I
don't
know
if
there's
an
issue,
but
an
issue
would
be
a
good
one
and
I
putting
a
particular
sake
on
there
with
with
a
guess,
is
a
good
idea
and
then
the
cigs
will
likely
figure
out
who
really
owns
it.
I
guess
we're
talking
about
just
documenting
the
behavior,
so
honestly,
I
don't
know
who
owns
TNS,
it
might
even
be
acts.
A
A
Yeah
repeats,
no,
he
said
to
me,
say:
Paris,
throw
the
wrong
answer
out
there.
Someone
is
gonna,
correct
you
and
I'm
like
I.
Never
thought
about
that.
Like
wow,
that's
a
question
that
we
get
a
lot.
The
question
is:
how
do
I
know
what
sig
owns
what
and
that
was
a
perfect
example
of
a
you
know.
I
mean
Tina,
asking
another
maintainer
who
owns
what?
How
and
I
think
Justin's
kind
of
response
was
pick
something
and
somebody's
going
to
respond
to
you.
A
But
in
the
case
where
you
pick
something
and
they
don't
respond,
then
what
like
so
should
Zach
then
go
to
go
to
slack
and
say
everybody
in
this
signal
or
should
should
Zach
go
to
the
mailing
lists
like
what
do
you
think
well,
we'd
like
if
say,
if
you
know,
if
zach
pinged
on
this
issue,
like
some
some
folks
from
sig
node,
for
instance,
and
they
didn't
respond,
would
his
best
bet
then
would
be
to
go
to
their
mailing
lists.
I
thought.
B
A
B
So
owners
are
one
of
the
ways
you
know
we
talk
about
like
how
how
we've
split
it
up.
So
not
everyone
is
treading
on
each
other's
toes
all
the
time.
In
a
lot
in
most
directories
in
kubernetes,
you
will
see
a
file
whose
name
is
owners
and
old
cats,
and
the
intention
is
that
that
file
describes,
who
owns,
owns
an
ounce
of
a
nanosecond,
the
entire
subtree
underneath
that
file
and
so
and
they're.
B
Typically,
that
file
is
divided
into
approvers
and
reviewers,
and
so
reviewers
are
able
to
lgt
em
a
PR,
but
they
that
comes
in
underneath
that
directory,
but
it
touches
a
file
underneath
that
directory
and
approver
is
also
needed
to
of
/,
approve
that
a
PR
and
then
once
you
have
approval
and
OGT
em,
then
the
PR
should
merge.
We
keep
changing
the
rules
that
whether
approve
implies
LG
TM
and
all
these
sort
of
things,
but
broadly
that's
how
it
works.
B
So
the
intention
is
basically
to
say
who
is
responsible
or
who
is
knowledgeable
about
a
particular
subtree
of
the
code,
and
that
applies
to
have
the
entire
all
the
community
projects
I
believe
and
you'll
always
find
an
owner,
as
we
sure
that
we
find
an
owner's
file
in
the
top
level
of
every
repo.
Those
people
are
responsible
in
theory,
for
everything
in
that
repo.
B
So
you
shouldn't,
like
the
owners
file
in
kubernetes
communities,
are
some
of
the
like
maintainer
z'
of
the
whole
project,
and
it
would
probably
overkill
to
ping
them
on
a
tree
on
a
dock
on
a
typo
fix.
I.
Think
you
would.
That
was
not
a
great
idea
and
then,
but
if
you
drill
down
into
the
subdirectory,
is
responsible,
you
can
sort
of
see
who
owns
the
who's
responsible
for
the
code,
and
you
can
figure
out
people
in
there
that
do
that.
Personally.
B
I
would
look
at
also
look
at
the
github
history
on
that
file
like
who
is
contributing
and/or
actively
working
on
the
code.
If
you
want
to
know
why
something
changed
in
a
particular
way,
you
know
why,
if
something
is
a
particular
wave
and
like,
if
you
think,
there's
a
bug
in
as
you
can
look
at
the
history
on
that
on
that
file
or
even
on
those
lines,
that's.
A
Awesome
thank
you
for
that.
That
was
a
really
great
explanation
and
Zac
your
crews,
using
orders
files
these
days
too
right
except
your
process,
is
sort
of
a
like
a
secondary
review.
Do
you
want
to
just
kind
of
like
a
high-level
go
through
like
what
your?
What
your
process
looks
like
compared
to
say
someone
that's
doing
I,
don't
know
like
code
for
for
cluster
I
mean
I,
know
they're.
All
like
you
know
a
little
hairline
different,
but
I,
don't
think
cluster
necessarily
as
like
a
Docs
and
a
tech
review.
C
Absolutely
sig
Buxton
uses
owner's
files
as
well,
but
if
you
look
at
our
owner's
file
in
the
top
level
of
K
website
it's
well,
it's
really
apparent
that
we
use
another
file
as
well
called
owners
underscore
aliases
and
we
make
liberal
use
of
owners
underscore
aliases
with
sig
Docs.
It
may
be
a
little
daunting
if
you
look
at
those
at
that
owner
Sebelius's
file,
because
sig
Docs
uses
a
lot
of
different
aliases,
and
we
do
that
because
we
have
not
just
a
regular
list
of
approvers
and
reviewers.
C
We
have
broken
those
out
by
language,
because
kubernetes
Doc's
are
available
in
multiple
localizations
Chinese,
Korean
and
Japanese
as
well
as
English,
so
we
have
an
alias
for
approvers
and
alias
for
reviewers
in
every
language.
That's
currently
available
as
a
localization
of
kubernetes.
So
what
we
do,
though,
is
I,
don't
know
if
it
was
ever
a
formal
convention
or
just
a
convention
that
everyone
adopted,
but
there
is
an
alias
like
if
you
ever
want
to
get
on
github.
C
If
you
were
trying
to
signal
a
cig
for
PR
review,
there's
usually
like
a
sig,
a
cig,
no
PR
reviews
alias
and
cig
docks
has
one
as
well
and
that's
specifically,
for
people
who
can
chime
in
on
a
PR
and
anywhere
in
the
kubernetes
organization
anywhere
in
a
kubernetes
project.
So
if
you
go
for
cig,
docks,
PR
reviews,
if
that's
what
you
enter
that
and
we
use
that
same
convention
that
other
things
used
as
well.
A
That's
it
looks
like
you,
I
uses
owner
aliases
as
well.
I
do
know
that
some
other
groups
also
use
that
that's
awesome,
so
I
want
to
go.
I
want
to
go
back
to
something
really
quick
that
we
tabled
earlier,
which
was
Justin,
bringing
up
this
concept
of
like
go.
What
unit
go
with
what
you
know
and
kind
of
go
with
why
you're
interested
in
and
when
picking
sakes.
A
What
do
you
kind
of
counter
that
with
because
I
I
do
sometime
then
again,
I'll
tell
you
what
my
canned
responses
later,
but
a
part
of
that
canned
response
is
like
go
with
what
you
know
and
then
it's
well
I
know
a
lot
or
oh,
you
know,
I'll,
learn
anything,
and
you
know
it's
that.
It's
that
it's
kind
of
that,
like
you,
know,
job
interview
where
you're
like
I'll
do
whatever
you
want.
Oh
my
gosh
work
at
Google
like
I'll,
wipe
the
floors
like.
What
do
you
want
me
to
do?
A
B
So
if
you,
if
you
what
I
think
cluster
API
is
very
interesting
in
terms
of
I,
mean
I'll,
be
seven
sick,
toss
to
life
site
or
rainbow,
and
six
laps
of
life
cycle,
so
I
focus
on
I
have
a
narrow
view.
Point
of
the
imagine
list
people
do
but
like
cluster
API
is
still
relatively
greenfield.
Scd
ADM
is
one
that
we're
just
getting
started
right
now.
Berry
green
fields,
hopefully
we'll
have
some
stuff
on
a
Dom
management
which
will
be
fairly
Greenfield
as
well.
Any
of
those
things
right.
B
A
C
We
do
and
I
encourage
folks
to
come
to
Docs
as
a
like,
if
you,
if
you
don't
know
where
to
start
well.
First
Paris
I
want
to
echo
I
think
your
advice
is
really
good.
Do
what
you
know
and
I
would
say
that
stick
box
is
a
great
place
to
do
what
you
know,
because
every
area
of
kubernetes
is
ducks
touch
on
every
area,
even
kubernetes,
I
think
I
think
folks
sometimes
come
in
and
are
like
yes
I'm,
so
enthusiastic
about
ducks
I'm
totally
willing
to
do
this.
C
Tell
me
what
to
do
and
I
think
it's
a
very
it's
a
request
for
active
mentorship
and
sort
of
active
guidance,
and
unfortunately
we
don't
have
the
time
or
the
the
the
energy
just
the
availability
of
people
to
do
to
do
that
kind
of
active
mentor
like
one-on-one
mentorship
with
with
new
contributors.
So
what
we've.
C
C
Is
tried
to
make
sure
that
our
contributing
guide,
if
you
go
to
kubernetes,
io,
/
doc,
slash
contribute
there
is
a
well-established
kubernetes
contribution
guide
for
docs,
specifically,
and
that
goes
out.
There's
big
shout
out
to
misty
Linville,
who
did
a
lot
of
the
the
heavy
lifting
for
that
overhaul
yeah.
C
She
did
a
really
good
job
with
overhauling
the
contribution
guide,
but
there's
like
basic
contribution,
intermediate-advanced,
so
there's
a
very
sort
of
clear
calf
to
how
you
can
specifically
get
involved
and
Parris
I
would
take
your
advice
to
do
what
you
know
and
focus
that
to
Docs
to
only
fix.
What's
wrong,
you
don't
have
to
fix
the
entire
English
for
the
entire
article.
C
C
E
B
Think
that
that
actually
sort
of
speaks
to
why
I
don't
mind
small
PRS
and
it's
sort
of
my
rule
of
thumb
is
that
the
like
the
amount
of
time
it
takes
to
get
a
PR
done
is
searchable
the
square
of
the
number
of
lines
so
like.
If
you
change
four
things
in
one
PR,
three
of
them
might
be
great.
One
of
them
might
be:
oh
I'm,
not
so
sure.
So
if
we
have,
if
there
were
forty
yards,
I
can
do
this
code.
A
B
A
Feel
I've
a
feeling
it's
missed
director
anyway.
Alright,
on
the
same
note,
though,
on
this
and
on
the
same
kind
of
note,
what
is
your
tips
for
reviewers
and
approvers
and
owners
into
getting
them
to
use
more
good?
First
issue
labels,
Help
Wanted
issues,
the
thing
that
I
hear
a
lot
from
our
current
crew
of
folks
in
owners
files
is
hey.
They
just
don't
have
the
time
to
help
folks
through
B.
They
think
that
the
problem
is
too
complex,
see
they
think
that
it
would
be
a
lot
of
onboarding
B.
They
just
don't
do
it.
A
So
what
are
some
tips
that
you
that
help
you
kind
of
I
guess
tasks
out
both
new
and
casual
contributors,
because
I
think
we
have
17,000
plus
contributors
at
this
point.
All
of
them
are
mostly
casual
right
and
from
the
casual
contributors.
One
of
the
things
that
I
heard
from
the
feedback
for
the
the
upcoming
summit
is
that
folks
want
to
talk
about
how
to
engage
more
with
casual
contributors.
So
how?
A
C
C
I
will
say,
first
of
all
that
what
you
have
said
is
true:
we
we
struggle
with
time
and
availability
as
well.
This
is
where
I
don't
tow
the
party
line
and
where
I
admit
that
in
in
cig
docks,
we
honestly
don't
pay
a
lot
of
attention
to
issues,
because
we
have
the
choice
to
either
pay
attention
to
issues
and
tried
the
triage
issues
appropriately
or
focus
on
getting
PRS
through
the
review
process.
So
we
focus
a
lot
of
our
effort
on
to
PRS,
so
I
guess
I
would
say.
C
If
there
is
someone
who
wanted
to
dedicate
themselves
exclusively
to
triage,
you
would
be
feted
with
roses.
Parade
in
the
streets
in
in
in
cig,
docks,
I
would
say.
I
can
talk
a
little
bit
about,
like
my
wish
list.
I
wish.
That's
specifically
like
Help,
Wanted
or
good
first
issue
that
those
were
labels
that
anyone
could
apply
not
just
org
members,
but
that
anyone
could
apply
by
like
slash
command.
I
mean
the
it's.
C
It's
a
would
be
a
fairly
straightforward
piece
to
do:
I
mean
to
implement
those
labels
as
a
slash
command
in
like
tests
infra
tested
for
this.
The
sig
that
handles
prow
kubernetes
does
in
how
CI
CD
system
it
would
be
relatively
straightforward
to
make
those
slash
commands
but
handling
them
from
from
anyone,
whether
they
inside
the
order
out.
That
would
be
more
difficult,
I
suspect,
but
that
would
be
my
wish
list
is
for,
for
anyone
to
be
able
to
apply
those
labels
voluntarily
to
self
apply.
C
That
would
make
him
that
would
make
those
issues
or
PRS
filterable
through
the
the
PR
dashboard,
and
that
would
be
that
would
be
a
much
easier
way
for
for
the
reviewers
on
the
bandwidth
that
we
can
fight
folks
who
need
that
kind
of
helper
or
mentorship
on
PRS,
especially
so
as
an
actual
answer.
I,
don't
know
how
I
don't
know,
but
if
I
could,
if
I
could
build
my
own
path,
that's
what
that
might
look
like
that
is.
A
An
awesome
point
and
I
think
that's
something
that
the
Syrian
committees
in
favor
of
which
is
creating
roles.
It's
just
kind
of
like
a
business
where
you're
your
department
has
different
people
that
do
different
things.
So,
for
instance,
contributor
experience
we're
currently
looking
for
a
project
manager,
we're
probably
going
to
look
for
a
triage
person
that
you're
talking
about
so
like
cutting
out
and
chiseling
roles
for
people
that
are
currently
contributing
gives
them
value.
It
gives
your
it
gives
your
your
sig
value.
I.
A
Think
that's
a
excellent
point
and
that's
I,
think
my
tip
too,
to
maintain
errs
is
to
ask
people
what
they
want
to
do.
Ask
people
if
they
want
to
contribute
if
they
say
yes,
then
think
about
putting
them
on
as
like
a
like.
Maybe
a
casual
contributor
liaison
someone
that
can
go
in
and
look
at
your
issues
and
apply
labels
and
then
maybe
just
like
walk
people
through
it,
and
then
we
can
reward
and
recognize
them
in
ways
and
if
you're,
unsure
of
those
ping
me
Justin
what
about
you?
What
are
your?
A
E
B
Know
I
certainly
don't
do
a
good
job
on
any
other
repos
I'm
involved
in
with
the
Help
Wanted
labels.
They
tend
to
rot,
I
think.
In
other
words,
if
they
are
genuinely
good
first
issue
type
things
they
get
snapped
up
and
done,
and
then
we
have
the
Help
Wanted
actually
turned
out
to
be
really
difficult.
This
was
stuck
there
and
we
need
to
like
I
guess.
B
I,
don't
know
how
I
would
encourage
that,
but
I
can
I.
Might
try
and
we'll
see
what
happens.
I
do
very
much
like
the
idea
of
the
most
meta
health
wanted,
or
the
first
issue
that
back
raised,
which
is
the
good
first
issue,
is
a
good
first
issue
bot,
but
as
to
the
actual
question
at
hand,
I'm
not
trying
to
serve
do
a
great
job
with
myself
and
I.
Don't
think
it's
it
is
difficult.
I
think
is
the
answer.
A
Yeah
I
mean
think
I
think
it's
a
problem
that
we're
all
trying
to
solve,
which
is
both
good
and
maybe
we
can
collectively
do
it
together,
but
that
wraps
up
this
session.
So
thank
you
both
very
much
for
your
time.
Jeff.
Thank
you
so
much
for
the
YouTube
help
and
that
wraps
up
our
December
edition
of
meet
our
contributors.
I
can't
believe
we
did
a
whole
year
of
this.
We
have
12
of
these
solutions.
C
A
Have
over
a
thousand
unique
views,
one
of
the
someone
did
a
code
base,
a
quick
impromptu
code
based
tour
of
kubernetes
kubernetes
and
got
over
500
like
within
the
the
first
24
to
48
hours.
So
this
is
scalable
mentoring.
People
have
questions
all
the
time
and
we
are
here
to
answer
them
at
least
once
a
month.
So
that's
it
for
me.
I
hope
everybody
has
an
awesome,
cube
con
awesome
new
year
and
we
will
see
everybody
back
here,
January
2nd
mentors.
If
you
could
stay
on
the
line
as
we
cut
it,
that
would
be
awesome.