►
From YouTube: Kubernetes Meet Our Contributors 20180711
Description
This is our monthly livestream where Kubernetes developers share information on how to contribute to the project. For more information check this page: https://git.k8s.iocommunity/mentoring/meet-our-contributors.md
A
Hi
everyone
and
welcome
to
July's
edition
of
meet
our
contributors.
This
is
about
kubernetes,
upstream
development
and
community.
This
is
our
mentors
on-demand
web
series.
When
you
are
in
need
of
a
mentor,
then
this
is
the
place
for
you
to
ask
questions
as
far
as
rules
and
things
are
concerned.
In
order
to
ask
questions,
please
try
the
meet
our
contributors
slack
channel,
that's
what
I
will
be
moderating
heavily,
but
if
slack
is
not
your
thing.
A
A
Also,
we
do
have
a
code
of
conduct
for
all
CN
CF,
related
communication
platforms.
That
includes
the
questions
that
you
are
asking
the
panelists,
as
well
as
the
panelists
themselves.
Please
be
kind
to
each
other.
Everyone
please
feel
free
to
be
chatty
in
the
in
the
slack
Channel
and
then
let's
go
into
intros.
My
name
is
Paris
I.
Do
community
engagement
for
Google,
specifically
on
the
kubernetes
project,
and
I
am
your
host
today?
So,
let's
start
with
Steve
Steve.
Do
you
want
to
give
a
quick
intro
about
yourself
sure.
C
C
Yeah
so
I'm
I'm
I
work
for
jetzt
at
uk-based
company,
I
yeah
I
work
on
cert
manager
and
a
number
of
other
ecosystem
projects.
I
help
try
and
help
out
instigate
the
iron
machinery
which
they
can
usually
on
slack
with
different
questions,
and
I
tend
to
be
the
one
bugging
Stephen
Coe
on
cig
testing
about
prowl
as
we
run
and
maintain
our
own
instance
of
pram
as
well.
A
F
A
You're
from
CN
CF
is
actually
going
to
join
us
as
well
and
I'd,
say
about
30
minutes
and
when
he
does
he'll
come
on
and
introduce
himself,
but
he
it
will
be
another
resource
for
everyone
all
right.
So
let's
get
right
into
it.
The
first
question
is
a
pretty
general
question
and
that's
how
to
get
into
open
source
and
feel
free
to
whoever
would
like
to
jump
in
jump
in
and
we'll
do
a
little
round-robin.
C
So
like
say,
ice,
probably
and
nearly
unrelated
to
keeping
up
teeth
the
way
to
Falken
running
able
to
escape
wearing
one
of
those
as
a
normal
ago
now,
but
and
kind
of
stumbled
upon
Kiba
Nettie's,
probably
about
two
and
a
half.
Three
years
ago,
I
got
very
lucky
finishing
joint
day
going
introduction
31.0,
which
was,
and
yet
it's
been
kind
of
quiet.
Since.
D
So
long
ago,
in
a
former
life,
I
used
Eclipse
a
lot
and
one
day
was
hitting
a
bug
where
it
was
crashing.
My
development,
environment
and
I
remember
the
moment
where
I
realized
that
I
could
actually
go
like
figure
out
where
the
bug
was
in
the
source
and
fix
it
and
fix
my
own
problem
and
make
life
better
for
other
people
and
and
get
my
name
and
the
contributor
released
notes
for
the
next
release,
and
at
that
point,
I
was
hooked.
D
A
F
A
That's
that's
a
great
lead-in
to
the
next
question.
Is
you
it
so
you
did
get
started
with
open
source
before
kubernetes,
with
the
exception
of
Steve,
did
you
have
to
learn
languages
in
order
to
feel
like
you
could
be
a
valuable
contributor?
And
what
did
you?
What
was
like
the
ramp
that
you
took
to
kind
of
be
a
valuable
contributor
for
those
open
source
projects.
C
We
had
space
I
kind
of
started
out.
That
was
the
very
first
thing,
I
ever
learned,
so
no
time
to
go
with
meeting
lots
of
Java
online
articles.
A
lot
of
it
me
was
looking
at
other
people's
work.
There
are
a
few
others
who
had
done
all
right,
I
must
admit,
I,
probably
spent
a
year
or
two,
not
in
the
understanding.
Most
things.
I
remember.
Inheritance
was
just
a
thing
that
I
have
to
deal
with,
but
I
didn't
really
understand
why?
D
Always
a
it's
always
a
balance,
some
sometimes
it
was
learning
a
new
language
of
kubernetes
that
was
the
first
to
go.
Development
I
had
done
and
you're
always
kind
of
balancing
what
is
normal
and
best
practices
for
a
language.
What
is
normal
and
best
practices
for
a
particular
project,
you're
on
and
then
what
are
things
that
you
have
learned
in
your
development
experience
coming
from
other
languages
or
other
projects
and
and
you're
always
trying
to
kind
of
merge
those
three
three
things
and
I
would
say
early
on.
D
You
want
to
kind
of
wait
heavily
the
best
practices
for
the
language
and
the
project
and
ask
a
lot
of
questions
just
as
you're
getting
familiar
with
how
how
the
project
functions
and
then,
as
you
kind
of
fully
understand
the
language
of
the
project,
then
you
can
kind
of
bring
in
your
experiences
and
say
well.
This
has
worked
well
for
me.
This
has
not
worked
well
and-
and
that's
really
how
you
can
start
to
contribute
to
to
a
project.
D
A
B
It
was
a
combination
of
being
as
lazy
as
I
could
be,
and
just
learning
the
only
the
thing
that
you
needed
at
the
time
so,
for
instance,
like
I,
think
channels
and
good
routines
can
go
I,
don't
think
I
even
bothered
to
learn
until
I
actually
had
a
need
for
them,
which
was
wait
after
I
started
at
the
project
and
just
learning
piecemeal.
A
couple
of
things
that
you
needed
to
do
for
that
specific
issue
or
about
the
humor
tracking
I.
B
B
A
D
I
would
just
say:
ask
questions
early,
it's
easy
to
kind
of
rattle
on
something
and
start
off
in
a
direction
that
might
not
be
quite
right
and
by
the
time
you've
invested
a
lot
of
energy
and
effort
in
a
particular
approach
it
can
be.
It
can
be
harder
to
kind
of
step
back
and
say:
oh
well,
maybe
maybe
this
other
approach
would
be
better.
So
finding
someone
and
a
slack
channel
or
tagging
someone
and
one
of
the
Sigma
ting
saying,
can
you
can
you
answer
some
questions
about
this?
D
C
Understanding
that
I
think
that's
a
really
good
resource
for
kind
of
just
in
full,
right,
well,
right
against
isil's,
I,
think
and
also
don't
get
discouraged
by
the
bots
and
things
like
that.
There's
a
lot
other
they
can
be
quite
noisy
and
they've
got
a
lot
to
say,
but
a
lot
of
the
time
you
know,
there's
people
behind
everything
and
I
think
it's
well
I!
Think,
anyway,
it's
a
really
welcoming
community,
there's,
always
someone
who
would
like
to
help.
A
All
right
well,
the
neck,
that's
another
good
lead-in
to
the
the
next
question,
specifically
for
Jordan
and
of
course
others
can
answer
to.
How
do
you
manage
your
time?
Jordan
is
one
of
our
top
contributors
and
he
is
a
issue.
Triage
powerhouse
I
think
so
folks
are
really
curious
as
to
how
you
do
it
tell
us.
G
D
Someone
mentions
a
topic
that
I'm
interested
in,
which
means
I
get
a
lot
of
pings,
but
it
also
means
that
when
there's
an
issue,
it'll
kind
of
show
up
on
my
radar,
because
five
or
six
or
seven
or
eight
people
will
be
mentioning
it
and
so
I
I
monitor
that
pretty
closely
I
will
open
up
incoming
port
requests
and
issues
kind
of
the
first
page
or
two
on
github,
probably
once
a
day.
Just
look
at
the
titles
and
jump
into
ones
that
look
relevant
yeah.
D
A
lot
of
kubernetes
is
so
interconnected
that
if
you
can
keep
up
with
what's
going
on
and
it's
really
hard,
you
will
actually
start
to
make
connections
across
issues
which
really
helps
a
lot
of
times.
You
know
someone
will
say
I'm,
seeing
a
flake
going
on
and
that'll
jog
something
in
my
memory
about
oh
well.
This
pull
over
here
went
in
a
couple
days
ago
and
that
might
be
related,
but
it's
not
easy.
I
will
I
will
say
for
the
for
flake,
specifically,
the
the
triage
board
is
is
really
fantastic.
D
We
can
probably
get
a
link
to
that,
but
there's
a
trails
board
that
scrapes
all
the
test
results
and
you
can
actually
see
for
a
particular
test
jobs
or
for
particular
tests
how
flaky
they've
been
and
where
they've
been
passing
and
failing,
and
so
sometimes
that'll
give
a
really
clear
signal
like
something
went
in
two
days
ago.
That,
like
that's,
that's
the
moment
where
things
went
sideways.
A
Awesome
and
I'm
gonna
share
that
screen
the
test
grid
and
in
one
second
here
while
I
do
that,
though,
James
same
question
for
you,
how
do
you
manage
pretty
much?
How
do
you
manage
your
time
between?
You
know
your
chest
commitments
and
your
upstream
commitments
and
your
hobbies
and
everything
else
that
goes
on
in
life,
I
think
James
might
be
frozen
and
Steve
same
question.
Really
quick
up,
nope
James
isn't
frozen
anymore.
A
A
Do
you
so
it
pretty
much
the
same
question
that
Jordan
had,
which
was
a
just
a
general?
How
do
you
manage
your
time?
You
know
folksy
Jordan,
do
a
ton
of
work
on
the
project,
I'm
so
curious
about
how
he
manages
this
time.
So
how
do
you
manage
yours,
especially
with
priorities
to
your
company
and
upstream
and
other
hobbies,
and
and
things
like
that,
yeah.
C
I
think
I
think
what
Jordan
said
it's
like
sleeps
over
eights
is
the
first
thing,
but
I
think
actually
it's
very
difficult
to
stick
to
that
so
kind
of
I'm,
trying
to
it's
a
tough
one,
I
think
and
it's
a
case
of
yeah,
triaging
and
I
think
letting
some
things
go
as
well.
C
A
A
B
Smaller
set
of
things
to
care
about,
like
that
always
helps,
you
know,
I
think
it's
obvious
when
Jordans
got
his
hands
all
over
the
entire
project,
that
you
know,
that's
a
huge
amount
of
commitment,
but
it's
a
lot
easier
if
you
have
a
smaller
amount
of
things
to
care
about
and
that
you
know
might
feel
like
a
little
bit
of
a
cop-out
or
something,
but
that's
totally
fine
right,
like
the
more
you
focus
on
a
small
area,
the
better
you
can
be
integrated
into
it
and
then
yeah,
just
I
think
James
said
is
well
like
not
being
okay
with
not
touching
stuff.
B
A
D
D
Then
sig
release
master
blocking.
That's
that's
a
pretty
good
one,
so
this
shows
a
bunch
of
test
jobs.
We've
got
a
summary
page
here
that
kind
of
gives
a
high-level
overview
for
each
job
of
whether
the
job
is
green
or
flaky
or
failing,
and
if
you
say
you're
on
the
summary
tab.
Now,
if
you
jump
into
one
of
the
tabs,
maybe
basal
test
or
misty
bezel
test.
A
D
Go
okay,
so
this
is
showing
the
results
of
the
nozzle
test.
Witches
are
like
our
unit
test
runs
and
you
can
see
the
jobs
go
from
left
to
right.
Most
recent
job
is
on
the
Left
lots
of
different
runtimes.
This
is
running
like
every
five
minutes,
something
like
that
and
then
vertically
you
have
all
of
the
different
individual
tests
packages
that
are
being
tested,
and
so
it's
a
long
list.
That's
why
it
took
so
long
to
load,
and
so
this
this
job
is
actually
one
required
to
be
green
for
stuff
to
merge
to
master.
D
So
it
stays
green,
mostly
basically,
all
the
time.
But
if
something
is
flaking
it
you'll
see.
Occasional
Reds
creep
in
a
particular
package
will
start
flaking,
and
so
the
way
this
works
is
it
sorts
those
to
the
top.
So
tests
that
are
flaky
will
show
up
those
red
blocks
in
this
list
and
if
you
change
the
size
to
super
compact.
D
B
B
D
A
G
A
B
I
think
one
of
the
things
that
it
is
fairly
new
still
and
sometimes
is
rough
edges
but
generally
is
super
useful
is
the
PR
dashboard
so
on
kubernetes
kubernetes,
the
large
repo
this
doesn't
apply.
But
if
you,
if
you're
a
contributor
to
like
any
of
the
sort
of
ancillary
repos,
that's
set
on
the
side
like
little
component,
repos
you're,
probably
using
a
program
called
tied
for
merging
and
I,
want
to
see
if
I
can
quickly
pull
up.
B
B
So
if-
and
this
is
on
an
entirely
different
repo
but
it'll
look
very
similar
if
you're
writing,
it
already
request
for
like
many
of
the
flow
requests
underneath
the
kubernetes
organization
that
are
not
in
the
kubernetes
repo,
specifically
so
down
at
the
bottom.
In
the
little
status
section,
there
will
be
a
little
status
from
a
program
called
tied
and
it'll.
Try
to
give
you
a
little
bit
of
an
overview
of
saying:
oh,
you
know
your
PR
right
now
we
can't
merge
it.
B
It
needs
a
couple
labels
and
if
you
click
the
details,
link
it'll
take
you
to
a
page
pull
request
status
and
what
this
is
hopefully
going
to
show
you
is,
you
know,
we've
got
your
requests,
what
jobs
have
run
on
it
and
maybe
a
couple
of
them
have
failed
and
then,
aside
from
that,
try
it
tries
to
digest
what's
the
current
state
or
PR,
and
what
do
you
need
to
do
to
make
it
merge?
And
so
here
you
notice
that
it
doesn't
meet
the
most
requirements.
B
It's
got
two
labels
that
are
required
and
missing,
and
there
ldcm
and
approved,
and
so
you
should
be
able
to
look
at
this
and
say:
okay
I
need
to
resolve
my
labels
for
this
PR
and
then
I
go
ahead
and
figure
out
for
each
PR.
What
is
trying
to
do-
and
the
interesting
thing
here
too,
is
like
that
little
link
at
the
bottom
of
your
PR
will
help
you
figure
that
out
for
a
specific
pool
request.
B
B
Sure
so
he's
actually
gotten
none
that
are
open,
good
job,
sure,
Oh,
No,
okay,
here
sorry
yeah,
so
this
one
he's
got
a
hold
on
there,
which
begins.
You
know,
he's
still
working
on
it
and
you
know
he
doesn't
want
it
to
immerse
coy
yet.
So
this
is
the
sort
of
page
that
will
be
linked
at
the
bottom
as
soon
as
the
tide
program
is
managing
the
merge
queue
for
your
repo,
and
so
that's
right
now
tied
is
managing
the
merge
queues
for
quite
a
lot
of
repos
and
the
kubernetes
organization.
Just
not
the.
D
B
C
That
I'll
quickly
share
my
screen,
one
that
it's
not
brand
new
or
anything
like
that.
I
do
find
really
useful
when
you've
got
I,
don't
if
you
can
see
there
yeah
well
than
that
I
find
really
useful
is
just
on
the
Governator.
This
cool.
This
is
the
tool
that
sucks
up
and
displays
all
of
the
lungs
from
test
runs.
There's
this
extra
PR
dashboard,
which
I
mean
I,
think
it's
yeah.
C
This
has
been
around
for
a
long
time
and
I'm,
not
sure
people
know
I,
think
it
might
even
be
being
placed
at
some
point,
but
it's
something
similar,
maybe
not,
but
this
just
kind
of
gives
you
an
overview
of
the
things
that
need
attention.
You
know
what
you've
got
to
look
at
and
what
you've
got
like
your
own
cool
requests
are
going
out.
It's
basic
mystics
to
tell
you
what
of
what
needs
to
happen.
C
Next
I
think
mine's,
pretty
small
in
some
I'm
sure,
but
this
can
be
really
useful
with
you,
especially
if
you
kind
of
leave
something
for
a
while
and
you
get
a
bit
of
a
backlog
or
you've
got
a
load
of
pull
requests.
You've
opened
up.
This
can
be
really
helpful,
just
to
get
an
overview
of
what
needs
to
be
looked
at
and
yeah.
It
just
points
you
in
the
right
direction.
A
A
C
C
Yeah
I
mean
I'd,
say
this:
a
large
pies
like
being
in
the
slack
channels
that
you're
interested
in
just
kind
of
in
the
morning,
I
tend
to
go
and
look
until
it
gets
back
to
you
know
yesterday
and
just
have
a
quick
read
through
I
guess.
You
know:
I've
got
the
bit
of
time
to
actually
do
that,
but
when
it
comes
to
actually
major
headline
really
I
mean
that
doesn't
kind
of
give
you
a
mess
overview.
Just
looking,
it's
back
major
headline
release.
Obviously
I
get
it.
C
D
Agree
with
the
release
notes
thing
even
for
point
releases,
so
seeing
what
went
in
the
emails
that
get
sent
out
usually
have
a
change
logger.
It's
interesting
and
I'll
usually
end
up
diving
into
a
few
of
those
and
taking
a
look,
I
use
issue
and
PR
queries
filtered
by
cig.
A
lot
like
I
said
a
leads
to
goth,
and
so
I'm
triaging
those
things
a
lot,
but
the
other
ones
that
I'm
interested
in
API
machinery.
D
Things
like
that
I
will
look
at
issues
filtered
to
a
cig,
so
we're
sick
off
I'll
throw
this
in
the
slack
channel.
That
looks
something
like
that
and
that
can
be
a
more
manageable
list
of
things
to
go
through
if
you're
I
mean,
if
you
pull
that
one
up,
you
know
the
first
page
has
things
going
back
a
few
weeks,
so
it's
it's
a
little
more
manageable
than
the
fire
hose.
That
is
all
issues
in
all
pprs.
So
if
you're
interested
in
a
particular
area,
don't
think
about,
my
label
works
pretty
well.
A
Even
our
project
governance
changes
rapidly.
How
do
you
keep
up
with
the
changes
to
not
just
code
but
community
and
how
we're
structured
and
I
mean
even
Steve
can
probably
talk
about
even
just
contributor
workflow,
because
we're
constantly
making
changes
for
the
better.
How
do
you
keep
up
with
those
things
that
aren't
necessarily
related
to
maybe
your
immediate
day-to-day,
but
yet
affected?
Nonetheless,
I
think.
B
Keeping
an
eye
on
the
like
the
communities,
dev
and
see,
contributor
and
experience
mailing
lists
is
huge
and
then
for
everything
that
is
like
not
machine
possible.
You
have
two
whole
I
personally
end
up
just
finding
people
that
I
trust
will
tell
me
the
important
things
which
I
know
that
approach
doesn't
really
scale
and
there's
a
lot
harder
when
you
don't
know
who
to
ask,
but
I
haven't
found
a
better
one.
A
D
For
some
of
the
lower
traffic
repos,
like
I,
actually
watch
the
community
repo,
so
in
github
you
can
say,
watch
and
you'll
get
actually
get
a
notification
for
every
issue
in
PR
that
gets
opened.
That
is
a
good
ping
to
kind
of
say,
hey
here's,
a
new
thing
that
is
going
on
and
usually
I
will
look
at
the
first
notification
for
a
particular
issue,
say:
ok,
I'm
glad
I
know
that's
going
on
and
then
I'll
mute
it.
So
the
bottom
of
the
email
there'll
be
a
link
to
mute
that
keeps
the
overall
traffic
manageable
I.
D
Don't
get
notifications
from
then
on
for
that
one,
but
it
pokes
me
whenever
something
new
gets
opened
up
and
then
I
can
stay
subscribed
to
the
things
that
I'm
interested
in
and
mute
the
ones
I'm.
Not
that
doesn't
work
for
kubernetes.
Don't
don't
watch
communities
because
you'll
exceed
your
male
quota
in
like
eight
seconds
but
for
lower
traffic
ones.
That
works
pretty
well.
C
They
just
wouldn't
want
to
deceive
anyone,
think
that
might
help
notification.
A
Now
the
next
question
comes
from
a
new
contributor
and
they
keep
hearing
that
testing
our
billing
tests,
fixing
tests
and
issue
triage
is
the
way
in.
However,
that
seems
ambiguous
to
them.
They
can't
necessarily
find
any
docs
that
would
allude
to
how
to
actually
enter
into
those
areas
and
with
issue
triage,
they
say
that
there
aren't
enough
Help,
Wanted
and
or
good
first
time,
issues
in
this
in
the
pot
or
the
stack.
Rather,
what
are
some
advice?
D
F
D
Could
be
a
good
place
to
add
a
unit
test?
So
if
you,
if
you
find
a
package
with
no
tests
and
kind
of
ask
around
in
the
/
channel
hey,
would
it
make
sense
to
test
this
function
of
that
function?
That
would
probably
be
a
pretty
straightforward
place
to
start,
especially
if
the
functions
you're
testing
are
small
for
the
help-wanted
thing.
I
know,
I,
think
Carolyn
in
in
slick
and
Nikita
in.
D
Put
together
a
pretty
great
guide
for
what
should
go
into
a
Help
Wanted
issue
that
was
kind
of
vague
and
ambiguous
before,
and
people
would
tag
tacky
issues
that
were
actually
very
complex
issues,
help
Wanda
just
because
hey
I'd
love
it
if
someone
would
help
with
and
it
wasn't
really
focused
towards
new
contributors.
So
there's
there's
a
good
guide
there
now
I
agree
that
there
aren't
enough
of
them,
but
that
might
be
a
symptom
of
the
issues
we
have
that
are
long-lived
not
being
straightforward
to
deal
with.
How.
G
D
A
lot
of
areas
and
when
you
have
the
same
person,
kind
of
responsible
for
running
process
and
being
tech
lead
for
an
area
and
doing
design
and
review
and
design
themselves.
People
get
squeezed
and
one
of
the
first
things
that
gets
squeezed
out
is
kind
of
that
grooming
delegation
work,
which
is
when
you
take
a
step
back
and
look
at
it,
doesn't
make
sense.
But
just
realistically
that's
that's
what
happens.
I
think
what
we're
trying
to
do
is
tease
apart
those
those
different
roles
and
try
to
spread
that
across
multiple
people.
D
So
a
lot
of
the
things
are
working
through
this
right
now,
taking
what
used
to
be
one
person
or
two
or
three
people
and
spreading
the
roles
across
multiple
people.
That's
been
progress
and
as
those
get
spread
across
people
will
have
more
time
to
go
and
do
this
kind
of
grooming,
triaged
summarization
identification
of
issues.
That
would
be
good
for
for
people
to
jump
in
on
fair.
A
And,
what's
just
just
in
case
someone
out,
there
does
not
know
as
they're
listening.
Can
you
define
what
a
sega's
sure.
D
So
Saiga
stands
for
special
interest
group.
It
kind
of
divided
the
project
up
into
I,
don't
know
how
to
characterize
it
areas
of
interest.
So
some
sometimes
these
are
functional
areas.
So
there's
sick,
node,
6cl
eyes
that
are
focused
around
like
the
cubelet
or
the
command
line.
Sometimes
these
are
cross-cutting
areas
like
sag,
off
or
sick
architecture,
and
people
who
have
interest
in
those
areas
can
join
the
city.
D
They
can
kind
of
follow
along
with
discussions
at
the
focal
point
for
discussions,
but
then
it's
also
a
way
to
model
ownership,
so
given
in
kubernetes
is
owned
by
one
or
more
SIG's
and
they
are
the
ones
responsible
for
fixing
tests
when
they
break
and
designing
and
implementing
and
moving
features
along,
and
so
that
that's
kind
of
how
both
the
project
runs,
how
its
organized.
So,
if
you're
interested
in
a
particular
area,
find
the
special
interest
groups
related
it
to
that
area
and
subscribe
to
their
mailing
lists
and
join
their
slack
channels
was.
A
B
I
think
one
sort
of
like
potential
thorn
with
some
of
the
issue
triage
the
closer
you
get
to
like
the
center
of
the
mail
storm.
Maybe
some
like
the
higher
stakes.
Some
of
the
issues
are
and
sometimes
like.
That's
not
where
you
want
to
start,
because
it's
a
little
bit
stressful,
there's
a
lot
of
people
looking
at
it.
A
lot
of
people
are
affected
by
it
so
and
I'll
switch
to
jacket.
B
You
know
a
document
that
Nikita
put
out
and
like
get
them
written
down,
but
until
then
just
reaching
on
so
I
could
be
okay,
I'd
like
to
do
something
we've
had.
You
know
like
pretty
good
success
with
people
just
coming
and
saying
that,
so
until
we
got
a
better
like
labeling
process
talking
to
people,
I
think
is
always
going
to
be
your
best
bet.
I'll.
D
C
D
C
One
third
that
I
suppose
I
think
looking
at
the
periphery
projects
is
probably
a
really
good
entry
point
into
all
of
it
because
they
tend
to
follow
a
similar
pattern
to
the
main
communities.
Repo,
but
I'm
constrained
by
you
know
such
a
strict
release
process
and
you
know
it's
not
such
a
huge
code
base
and
so
it's
easier
to
work
with
tests
and
get
up
and
running
and
I
think
the
issues
there
as
well
Mike
and
Steve's
they're,
not
necessarily
so
critical.
C
So
there's
not
such
a
pressure
on
you
to
actually
get
that
thing
out
through
the
door
in
know
with
all
these
set
like
quality
well,
I
mean.
Obviously
you
need
a
certain
level
of
quality
that
you
need
to
adhere
to.
But
you
know
it
is.
It
can
be
tough
in
the
main,
repo,
I
think
and
just
as
a
onboarding
experience,
I
think
there's
a
lot
of
work
to
be
done
in
the
outskirts.
You
know
ingress
controllers
and
so
on.
C
B
B
A
A
They
don't
necessarily
work
on
this
full-time,
but
they
do
put
a
lot
of
hours
into
it.
How
can
they
find
a
voice
within
the
project
because
they
feel
like
a
lot
of
the
design?
Decisions
are
held
with
some
of
the
top
companies,
but
they
have
a
lot
of
good
ideas.
So
how
can
they
really
find
their
voice
within
the
project
and
gain
credibility?
I.
B
Think
it's
important
if
it
may
just
be.
You
know
how
much
they're
trying
to
try
to
bite
off
like
again
as
another
shameless
plug
distich
testing.
You
know
if,
when
we
have
design
proposals
come
through,
like
no
matter
who
you
are
in
the
state,
you
always
post
your
design
proposal
on
to
the
mailing
list
and
everyone
you
know
talks
about
it
there.
You
know
once
no
I
will
do
a
cap,
but
it's
very
open
flat,
and
so
that
may
or
may
not
be
what
other
sticks
look
like.
B
You
know
we're
still
like
in
terms
of
the
number
of
people
working
on
site
testing.
That
may
not
be
the
same
as
other
states
as
well
and
so
I
think,
like
it's
kind
of
inevitable,
if
you
want
to
make
a
splash
in
a
bigger
pool,
you
have
to
have
to
put
in
a
little
bit
more
effort.
So
if
you
know,
if
you
have,
if
you
want
to
have
some
sort
of
like
pivotal
role,
maybe
try
finding
a
project
where
it's
just
going
to
be
more
manageable.
C
Yeah,
sorry,
joking
up
to
you
great
now,
just
gonna,
say
testing
for
I
think
is
a
good
example
of
that,
though
I
personally
found,
it
tends
to
be
the
things
you
work
on
can
be
more
self-contained.
It
can
be
kind
of
within
one
plugin
and
it's
not
rolling
out
to
thousands
of
users
on
loads
and
loads
of
clouds.
Necessarily
I
mean
it
is
rolling
out
to
thousands
of
users,
but
how
they
interact
with.
C
It
is
very,
very
different
and
I
find
I
personally
found
that
that
to
be
a
really
good
place
to
kind
of
get
involved
with
the
project,
I
wouldn't
say,
I
make
so
many
pull
requests
against
the
main
kubernetes
repo.
It
does
tend
to
be
these
sorts
of
testing
for
and
so
on.
There's
a
lot
of
cool
work
going
on
and
that
can
get
you
used
to
that
process.
D
D
I
Drive
this
if
I
was
setting
up
a
cluster
just
on
bare
metal
or
I've,
got
a
cloud
provider
that
isn't
represented
how
how
do
I
interact
with
this?
So,
if
you're
looking
for
a
way
that
doesn't
involve
lots
and
lots
of
time
input,
even
just
showing
up
and
reviewing
designs
and
asking
questions
that
kind
of
highlight
your
use,
cases
can
be
a
pretty
lightweight
way
to
get
involved
in
the
process.
D
A
A
So
I
think
that
folks,
that
aren't
necessarily
affiliated
with
a
major
organization
or
cloud
do
indeed
have
impact
with
the
project.
I
mean
I'm
thinking
of
Christoph
who
works
at
Disney
and
he
does
major
major
stuff
for
us
and
does
not
work
for
our
cloud.
So
I'm
sure
we
can
all
think
of
individuals
that
make
great
impact
for
the
project.
So,
if
you're
feeling
that
way,
please
see
us
especially
me
DM
me
on
slack.
A
We
do
not
want
that
that
perception
whatsoever
and
we
want
you
to
be
valuable
just
as
much
as
you
do,
so
we
actually
only
have
ten
minutes
left,
and
that
was
my
last
question.
Let
me
make
sure
I'm
gonna
check
all
the
channels
on
more
time
check
my
direct
messages
or
good
there,
and
then
let's
check
some
other
areas,
but
last
but
not
least
panelists
/
mentors
do
you
have
any
questions
for
each
other
Oh.
D
A
Right,
well,
that
is
going
to
end
this
session
today
for
those
watching.
We
do
actually
have
a
special
session
at
one
o'clock.
Watch:
Lee,
I'm.
Sorry,
one
o'clock
Pacific,
how
not
global
of
me!
That
would
be
a
p.m.
UTC
check
to
check
your
local
timezone
for
that.
But
we
are
doing
the
first
30
minutes
is
sort
of
a
steering
committee
asked
us
/,
Town
Hall,
so
of
your
project,
governance,
questions
like
what's
the
difference
between
a
sub
project
and
a
working
group?
Is
there
a
difference?
A
Thank
you
so
much
to
all
of
the
mentors
today,
it
makes
a
great
deal
to
the
community
that
you're
willing
to
sacrifice
your
time
to
answer
these
questions,
but
we
do
have
tons
of
new
and
currying
contributors
who
are
looking
for
mentor
like
question.
Slash
relationships,
slash
experiences,
so
this
is
one
of
those
and
we
will
see
everyone
either
on
the
next
session
or
next
month,
all
right.
Thank
you.
So
much
I
appreciate
everybody.
Adios.