►
Description
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.
In this session members of the Kubernetes Steering Committee answer questions from the audience
See https://contributor.kubernetes.io/mentoring/meet-our-contributors/ for more information
A
Hi
everyone
and
welcome
to
the
second
session
today
of
our
monthly
mentors
on
demand
series
called
meet
our
contributors.
This
is
the
steering
committee
Edition.
Everyone
that
is
on
right
now
is
a
part
of
our
first
official
kubernetes
steering
committee.
We
also
have
some
founders
and
and
folks
that
have
been
with
the
project
forever.
So
this
is
a
good
way
to
get
any
governance.
Questions
related
governance,
questions
out,
history,
questions
anything
about
these
contributors
that
you'd
like
to
know,
etc.
A
All
questions
are
fair
game,
being
anything
technical
that
you
have
as
well,
so
grab
bag
and
also
ps4
listeners
I've
heard
that
we
have
an
election
coming
up,
and
some
of
these
folks
are
rerunning
based
on
their
term
limits
and
we'll
we'll
talk
about
that
in
a
second
when
we
get
into
an
election
question,
but
first
things:
first,
we
do
have
a
code
of
conduct,
so
those
of
you
that
are
participating
with
us
in
the
meet
our
contributor
slack
channel,
as
well
as
on
Twitter
and
anywhere
else.
Please
be
excellent
to
each
other.
Also
panelists.
A
B
Hey
I'm
Michelle
neroli
I'm,
a
developer
I
work
at
Microsoft
also
on
the
steering
committee
like
Harris
mentioned.
I
have
been
working
on
a
few
different
projects,
but
I've
always
been
really
passionate
about
different
ideas.
For
last
few
years,
I
co-founded
sig
apps
and
worked
a
lot
around
how
application
our
apps
and
workloads
features
integrate
with
with
higher-level
Tony
I
work
on
home.
We're
now
a
top-level
estancia
project
I
mean
if
I
sufficient
in
Jerusalem
pass
it
off
to
Aaron.
C
Cool
hi
everybody,
I'm
Erin,
Kraken
burger,
also
known
as
Aaron
of
cig
beard
cuz
when
I
started
at
Google
two
months
ago.
That's
the
name
that
just
popped
up
on
my
cubicle,
so
I
have
adopted
it.
As
my
own
I
started,
the
co-founded,
the
cig
testing.
It
was
the
second
stage
ever
to
be
founded
for
the
project.
I
helped
create
the
community
repo
I've
been
involved
in
every
Cooper
Nettie's
release
since
v13
in
formal
or
informal
roles
and
I
also
participate
pretty
actively
in
sakes
that
are
like
horizontal
to
the
project.
C
D
D
D
D
Currently
the
sig
architecture
co-chair
looking
at
ways
we
can
improve
reliability
of
the
system.
In
general,
it's
been
a
while,
since
I
sent
out
sort
of
an
annual
summary
or
a
plea
for
help,
but
I
historically
had
periodically
done
that
to
highlight
areas
of
the
project
that
need
more
focus
and
reliability
will
probably
be.
My
upcoming
suggested
focus.
E
Hello,
everybody
I'm
Joe
Beda,
one
of
the
cofounders
of
kubernetes
back
when
I
was
at
Google,
along
with
Brian
and
Craig,
obviously
building
on
one
of
the
ideas
and
works
from
from
a
lot
of
other
folks.
It's
like
Google
and
out
currently
I'm
the
CTO
of
hefty,
oh
and
we're
working
to
make
kubernetes
and
cloud
native
in
general,
more
accessible
to
prices
in
general.
It's
a
very
generic
way
of
talking
about
what
we're
doing
in
terms
of
involvement
lately
in
the
project.
I
think
I've
been
spending
a
lot
of
time
and
across
across
hefty.
E
Oh
we've
been
spending
a
lot
of
time
with
seed
cluster
lifecycle
working
to
make
kubernetes
in
general,
more
operable
both
in
terms
of
bringing
a
cluster
up,
but
then
with
newer
efforts
like
cluster
API
and
stuff
historically
was
involved
early
on
with
with
cig
scale,
which
was
our
first
cig,
which
came
out
of
a
community
meeting
where
I'm
like.
Why?
F
F
F
F
Today,
I
currently
co-chair
signaled,
with
John
from
Google
and
as
I've
laid
I've,
been
trying
to
make
sure
that
all
the
engineering
resources
that
Red
Hat
brings
to
bear
to
the
project
works
effectively
and
works
well
with
the
upstream
and
so
as
well
as
just
trying
to
keep
up
with
everything
that's
happening
in
kubernetes.
So,
like
others
on
on
the
call
here,
a
particular
concern
about
how
we
grow
the
number
of
contributors.
G
That's
me
Quinton,
who
I
currently
work
for
huawei
as
a
technical
vice-president
on
the
cloud
computing
out
of
the
business
I
previously
was
Google
for
five
years,
both
as
an
SRE,
so
a
heavy
user
org,
as
well
as
very
early
kubernetes
team.
We
run
about
same
time
that
Derek
joined
I,
think
2014,
ish
I,
remember
meeting
you
for
the
first
time
at
our
inaugural
kubernetes,
whatever
that
was
called
at
the
time
get-together
in
San
Francisco.
There
were
probably
20
of
us
and
I
think
these
days,
they're,
like
10,000
of
us.
G
It's
it's
been
quite
phenomenal
to
watch
it
grow
prior
to
Google,
I
had
a
few
other
startups,
as
well
as
founding
the
ec2
project
at
Amazon.
So
I
guess
I
have
a
fair
amount
of
experience
with
both
big
companies
and
small
companies
and
I
like
to
try
and
help
the
cookies
community
in
general
sort
of
be
able
to
balance
the
needs
of
both
big
and
small
companies.
I've
previously
been
involved
in
many
SIG's
I
think
I
was
also
in
the
early
days
of
cig
scale
and
I.
G
Think
I
read
their
chart
there
at
some
point
in
the
early
days.
I
was
also
responsible
for
the
testing
side
of
Google
before
Eric
later
and
his
merry
band
got
involved
and
co-chair
for
cig
multi
cluster
at
the
moment,
and
some
of
you
may
have
come
across
me
through
Federation
and
such
things
and
I'm
also
involved
in
the
CN
CF
on
the
TRC
technical
oversight
committee
with
Brian
and
I.
Guess.
That's
me,
I'm
an
engineer
by
background.
A
software
developer
primary.
A
Awesome
so
a
wonderful
crew
with
us
today
and
I
already
have
seven
questions
that
are
queued
up
mostly
from
my
Dean's,
but
there
are
a
few
in
the
slack
channel.
So
let's
start
first
things.
First
I
got
a
couple
questions
around
this
same
kind
of
topic,
so
I'm
going
to
combine
them.
What
keeps
you
up
at
night?
C
Was
that
too
much
of
an
eye
roll
there
like
I'm
having
a
difficult
time
narrowing
the
list
down?
I?
Think
if
I
were
to
it's
close
to
Brian's
word
of
reliability,
I
would
almost
say
sustainability,
I
think
so
the
particular
facet
of
that
that
I'm
interested
in
right
now
is
I
think
that
the
release
process
has
grown
as
a
wonderful
place
for
new
people
to
get
involved,
but
I
think
that
it
still
requires
a
lot
of
heroics
each
and
every
time.
I
also
think
the
idea
of
the
release
team.
C
You
know
a
group
of
like
up
to
double-digit
people
completely
dissolving
once
the
first
cut
of
a
release
has
gone
out.
The
door,
leaving
a
single
individual
responsible
for
managing
all
patches
thereafter
is
not
fair
to
that
individual
and
could
potentially
lead
to
breaking
changes.
Getting
introduced
as
seemingly
innocuous
patched
versions
go
out
the
door
more
than
that
I
am
concerned
about
or
in
addition
to
that,
I
think
I'm
concerned
about
our
funnel
or
latter
of
people
who
can
act
as
approvers
within
the
project.
C
So
an
example
of
that,
but
I'm
dealing
with
today
is
I'm,
trying
to
add
more
conformance
tests
to
the
project
and
at
the
moment
there
are
only
two
people
who
are
at
the
like
very
end
of
that
process,
who
can
say
yay
or
nay,
and
so
we've
discussed
this
in
save
architecture
and
we've
also
discussed
it
and
a
CNC
F
conformance
working
group
of
how
we're
going
to
grow
that
particular
pool.
So
that's
great.
That's
one
critical
instance
of
the
problem
for
me,
but
I
feel
like
this.
C
Classic
problem
exists
pretty
much
everywhere
within
the
project
and
I'd
like
to
find
ways
for
us
to
improve
automation
around
that.
Then.
Finally,
I
think
that
the
signal-to-noise
ratio
in
general
of
the
project
is
still
not
necessarily
where
it
needs
to
be
I
think
this
shows
up
in
issue
management
and
PR.
Triage
and
I
also
think
this
shows
up
in
test
results
and
test
flakiness
in
general.
I
see
Brian
has
his
hand
up
I'll
punt
to
him.
D
D
Yeah
I
shared
a
lot
of
Aaron's
same
concerns.
I
particularly
mentioned,
and
remind
people
that
get
up.
Notifications
are
basically
totally
useless
for
me
or
completely
random,
so
people
poke
me
by
other
means
and
then
I
can
go
search
for
stuff
and
sometimes
find
it,
but
the
volume
is
just
really
too
high.
According
to
dev
stats,
I've
got
about
1
million
notifications
on
the
project
and
I'm
pretty
sure
at
least
a
fifth
of
those
or
a
quarter.
Let
me
hit
my
inbox
in
the
first
two
years,
so
the
volume
is
just
incredible.
D
I
think
partitioning
the
project
into
smaller
pieces
is
really
the
best
thing
we
can
do
about
that
and
that's
similar
to
one
of
the
release.
Issues
and
one
of
my
longer-term
objectives
is
to
have
developments
not
immediately
hit
kubernetes
kubernetes
master,
either
by
moving
things
to
other
repos
or
other
branches,
so
that
we
have
some
means
of
an
additional
gate
before
a
need
feature
or
development
hits
a
release.
So
the
kid
weakens
properly
assess
his
quality
back
pre
100.
D
So
yeah
and
I
agree
about
the
automation
and
documentation
for
bootstrapping
new
people.
We
really
have
a
huge
knowledge
transfer
issue,
which
is
why
we
require
so
many
reviews
and
such
and
why
the
pools
are
still
so
small.
We
created
the
distinction
between
reviewers
and
approvers,
with
the
hopes
of
being
able
to
get
more
people
involved
in
the
review
process
and
have
them
learn
by
doing
and
then
eventually
promote
them
to
approvers,
but
the
lack
of
a
process
and
the
continuous
overload
on
approvers
as
someone
prevented
that
from
happening.
E
I
mean
so
Maya
died,
two
things
on
the
list
and
the
first
one
is
restating
a
lot
of
the
stuff
that
I
think
Aaron
and
Brian
talked
about
about
creating
such
a
sustainable
way
to
get
new
contributors
on
board
and
making
them
successful,
setting
expectations
and
processes
so
that
they
actually
don't
get
blindsided
by
a
lot
of
this
sort
of
sort
of
learning
by
osmosis.
That
happens
right.
The
other
thing
is,
is
you
know
from
from
a
project
point
of
view?
E
We
have
to
decide
where
does
kubernetes
end
and
where,
though,
does
the
rest
of
the
ecosystem
pick
up?
What
belongs
part
of
kubernetes?
What
does,
and
you
know-
and
some
of
this
is
like
what
is
this-
what
is
a
sub
project?
What
is
appropriate
for
being
part
of
it?
I
think
you
know
my
I'm
a
middle
it
minimalist
when
it
comes
to
this
stuff.
I
want
kubernetes
to
be
a
kernel.
I
think
it
makes
sense
to
have
a
thriving
ecosystem
of
stuff
building
on
top
of
kubernetes.
E
A
The
blue
Yeti
is
button
is
weird
anyway.
Thank
you.
So
the
next
question
is
from
Jonas
and
I
meet
our
contributors.
Slack
channel
Jonas
has
seen
a
lot
of
mentions
of
different
parts
of
kubernetes
project
that
has
interesting
names
such
as
prow,
tide,
velodrome
and
so
on.
Where
do
these
names
come
from
and
what
do
these
parts
do?
I.
C
Will
happily
take
this
one,
since
at
least
those
parts
specifically
are
all
under
the
purview
of
cig
testing?
I
didn't
necessarily
help
write
these,
but
I
was
around
when
they
came
into
being
so
felid
room,
I
can't
necessarily
speak
too
proud
and
tie-dye
can
but
like
we
don't
necessarily
have
a
hard
and
fast
rule
within,
say
testing
about
how
we
name
our
projects.
C
So
we
have
a
wide
variety
of
project
names
in
there
from
phosphorus,
which
I
think
is
like
Greek
for
Shepherd
and
that's
the
project,
that's
responsible
for
shepherding
resources
in
and
out
of
tools
and
cleaning
them
up.
We
use
that
for
TCP
projects
and
we
don't
have
to
bind
a
single
set
of
CI
jobs
to
a
single
GCP
project,
but
I
think
certainly
around
prowl.
That's
probably
the
place
where
we
try
to
be
cutest
so,
but
I
was
essentially
our
CI
system.
C
That's
like
if
this,
then
that
for
github
I,
recently
posted
a
blog
post
about
this
and
the
sundry
pieces
of
automation
that
we
developed
to
help
run.
This
project
proud
technically
means
like
the
front
of
the
boat,
and
so
the
idea
is
Prowse.
The
thing
that
is
driving
the
project
forward,
if
we're
all
writing
on
the
good
ship,
kubernetes
or
something
and
then
like
every
proud,
was
basically
like
a
set
of
different
micro
services,
and
every
individual
component
of
prow
has
some
kind
of
nautical
name
to
it.
Where
possible.
C
So
I
think
like
splice
is
the
thing:
that's
responsible
for
batching
up,
pull,
requests
and
testing
them
all
at
once,
so
that
we
can
improve
our
merge
velocity
or
at
one
point
in
time
like
taht
was
the
thing
that
was
responsible
for
generating
new,
build
IDs
and
thoughts.
Like
you
give
everybody
a
little
tot
to
function.
We
have
sinker,
which
is
the
thing
that
actually
kills
off
old
jobs
or
old
DRD
resources
we
have
plank,
which
is
the
thing
that
makes
jobs,
walk
the
plank
and
go
off
into
actual
execution,
all
sorts
of
fun.
C
Little
things
like
that
tied
specifically
I
kind
of
like
the
analogy
there.
It
doesn't
really
have
anything
to
do
with
the
boat,
but
the
idea
is,
you
know
right
now:
kubernetes
kubernetes
is
the
only
repository
remaining
within
the
entire
kubernetes
project
that
has
submit
cube
where
PRS
go
into
a
queue
and
are
ordered
by
priority
or
whether
or
not
they
have
a
milestone,
and
we
found
that
that
serialized
merge
queue
really
hampers
our
velocity.
C
So
the
idea
here
is
this:
allows
us
to
not
just
have
a
single
queue
for
a
single
repo
for
a
single
branch,
but
instead
have
one
project
that
sort
of
sweeps
around
and
picks
up
all
the
different
pools
across
all
the
different
repos
and
branches
that
meet
whatever
criteria
is
configured
for
them.
This
has
really
fundamentally
improved
our
operational
load
like
it's
way
way
easier
for
us
to
add
any
repos
to
this
and
I
think
it's
it's.
C
What
is
directly
contributed
to
the
fact
that,
like
two
months
ago,
we
had
about
30
repos
using
the
same
set
of
automation
and
whatnot,
and
today
we're
up
to
about
95
repos
out
of
the
hundred
and
twenty
something
that
make
up
the
whole
project.
So
that's
at
least
those
specific
things.
I
don't
know
about
velodrome,
but
you
know
we
like
to
keep
it
cute
and
I'm
done
and.
A
E
E
World
where
you
can
find
out,
you
know
this
information
is
all
in
markdown
file,
spread
throughout
like
a
gazillion,
different,
repos
I.
We
need
to
do
a
better
job
as
a
community
in
terms
of
making
it
easy
to
find
that
stuff
to
consume
it
to
get
that
decoder
ring.
So
you
can
figure
out
what
all
these
systems
are,
what
they
do,
and
maybe
the
fun
trivia
for
how
they're
named
it's
still
things
like
this,
though,.
B
But
also
I
think
the
sig
charter
is
coming
together
is
really
great
we're.
Finally,
in
a
documenting
the
lay
of
the
land,
what
SIG's
are
doing,
there
is
just
so
much
that
they
chairs
were
leads,
oh
and
being
able
to
kind
of
document
their
experience
and
how
they
work
and
function
as
a
sig
will
allow
us
to
also
figure
out.
You
know
where
the
gaps
are
and
where
we
can
help
SIG's
function
for
the
long-term
health
aliy.
D
Right,
Brian,
yeah
and
we're
also
chipping
away
some
smaller
governance
issues.
I
believe
we
got
the
working
group
formation
procedure
written
up
and
checked
in
and
Aaron
implemented
sub
projects,
which
is
helping
to
close
the
gap
between
people
organization,
which
was
in
SIG's
working
groups
and
or
at
least
SIG's
and
code
organization,
which
was
controlled
by
owners
files
there's
still
more
to
to
implement
there
so
completely
push
that
through.
But
at
least
now
we
have
a
conceptual
framework
for
how
that
works
and
all
the
SIG's
are
enumerated
their
sub
projects
in
60ml.
E
I'm
gonna
be
a
little
controversial,
I
think
the
key.
The
key
thing
that
the
steering
committee
has
done
is
that
the
steering
committee
has
tried
not
to
do
a
lot.
I.
Think
one
of
the
things
that
we
work
to
do
is
to
you
know.
Technically
the
steering
committee,
according
to
the
Charter,
you
know,
has
some
pretty
arbitrary
power
with
respect
to
doing
stuff
with
the
project.
But
it's
also
a
goal
of
the
steering
committee
and
I.
E
Think
we've
done
a
good
job
of
delegating
that
to
different
groups
and
really
creating
a
wider
base
of
people
making
decisions
within
the
project,
and
so
we've
put
at
least
we've
tried
to,
especially
with
the
charters
to
put
more
meat
behind
the
SIG's
being
able
to
make
decisions.
You
know
with
things
like
like
sub
projects,
more
structure
so
that
people
know
where
to
go
and
even
within
a
sig
to
actually
have
distributed
power,
so
I
think
I
think
not
doing
stuff
is
our
is
our
main
accomplishment.
F
Carry
on
Derek,
you
know
I,
guess
I,
depending
on
how
long
you've
been
working
in
the
project
it.
The
entire
project
just
starts
to
feel
like
a
blur
and
kind
of
to
Joe's.
Point
like
to
me.
I
think
the
most
important
thing
that
the
inaugural
group
of
steering
committee
members
as
well
extending
back
to
the
bootstrap
community
is
to
not
rock
the
boat
too
much
I
mean
commodities
is
pretty
successful.
Has
a
large
contributor
pool
and
people
have
been
working
well
together
and
I?
F
Think
it's
at
Joe's
point,
there's
some
wisdom
and
not
trying
to
do
too
much
too
quickly
and
trying
to
see
what
impact
small
changes
might
have
generally
like
I.
Think
broad
communication
across
the
entire
project
is
a
difficult
thing,
so,
even
where
you
would
want
to
make
changes,
it's
oftentimes
difficult
to
get
those
changes,
realized
or
or
messaged
out
to
the
entire
set
of
volunteers.
We
have
working
towards
communities
here,
so
I
kind
of
agree
with
Joe's
sentiment
and
I.
G
As
has
been
pointed
out,
we,
you
know
we're
a
very
large
project
now
growing
very
fast,
and
we
haven't
really
had
an
e
in
a
major
catastrophes
which
is
which
is
pretty
impressive,
actually
and
and
without
the
steering
committee
having
to
be
very
heavy-handed
at
all
about
anything.
So
hopefully
that
means
we're
doing
things
roughly
right.
A
C
I
was
gonna
agree
with
Joe's
point,
I
think
that
the
best
areas
where
we've
had
the
most
success
or
where
we
did
nothing
we
just
delegated
to
somebody
else,
I-
think
the
code
of
conduct
committee
was
a
great
example,
I
think
the
github
management
stuff
project.
So
we
all
used
to
have
owner
privileges
to
every
github
repo.
We
don't
anymore.
We
can
set
that
off
to
a
sub-project
understate,
contributor
experience
and
I
just
think.
C
In
general,
we've
been
pretty
aggressive
about
trying
to
find
who's
empowered
to
make
the
decision
rather
than
making
the
decision
ourselves,
and
the
last
thing
is
if
nothing
else,
I
think
pushing
kubernetes
forward
to
be
the
first
graduated
project
of
the
CNC.
F
was
a
good.
You
know
crossing
the
t's
dotting
the
ice
thing.
That's
it
for
me.
Awesome.
B
Just
I
think
I
glossed
over.
Why
I'm
so
excited
about
the
code
of
conduct
committee
and
I,
just
like
want
to
go
back
to
that
like
this
committee
is
so
qualified,
like
every
single
person
has
prior
experience
and
I.
Don't
so
like
it's
so
great
that
people
who
are
not
only
experience
but
also
passionate
about
the
subject
are
on
the
committee.
I
think
we
have
fantastic
set
of
people
and
they're
also
leveraging
learnings
from
other
communities
like
Mozilla,
like
Paris,
has
done
so
much.
B
Research
jason
has
worked
with
those
people
as
well
like
they're,
going
out
into
different
communities
and
figuring
out
how
other
open-source
communities
do
code
of
conduct
and
decision
making
and
management,
and
all
that
and
I
just
I'm
so
excited
to
have
such
a
brilliant
group
of
people
together.
Working
on
that
working
on
that
sense
that
we
have
this,
this
awesome
community
that
has
been
really
inclusive
and
angle,
hopefully
sustainably
grow.
A
H
Apologies
for
being
late,
all
of
this
I
am
Sarah.
Novotny
and
I
have
been
working
on
kubernetes
in
varying
forms,
since
2015
and
I
sit
on
the
steering
committee.
I
also
am
one
of
the
board.
Representatives
of
the
cloud
native
computing,
Foundation
and
I
sit
on
the
board
of
the
Linux
Foundation
as
well.
C
I'll
jinx
us
real,
quick,
so
I
actually
called
a
50-50
shot
of
whether
or
not
we
were
going
to
have
all
six
be
able
to
enumerate
what
it
is
they're
in
charge
in
before
our
next
election
I,
don't
think
we're
going
to
get
it
done.
We
currently
have
seven
charters
merged
last
I
looked
out
of
the
like
30
ish,
different
SIG's
that
we
have
that's
totally
on
us.
I,
remember
actually
sitting
down
specifically
with
most
of
the
members
of
the
steering
committee
in
person
at
koukin
in
Boston
and
saying
everybody
like
what
do
we?
C
What
are
we
doing
like
I'm,
really
disappointed
in
us,
and
it's
taken
me
a
while
to
get
acknowledged
that
it's
as
Joe
alluded
to
like
there
is
a
different
kind
of
progress
to
be
made
here.
It
certainly
seems
to
many
people
who
have
submitted
their
charters
that
there's
a
whole
lot
of
nothing
yep
that
gets
done
to
us
and
I.
Think
part
of
that
is
that
we're
incredibly
over
committed
on
a
variety
of
efforts
throughout
the
project
which
again
just
brings
me
back
to
I.
C
Don't
know
if
we
made
it
clear
enough
from
the
beginning
and
how
often
I
can
say
that
you
more
fully
appreciate
like
fully
formed
proposals
that
come
to
us
being
able
to
more
or
less
than
something
that
looks
good
is
great,
because
I
think
if
we
are
left
to
our
own
devices,
we
bike
shed
way
too
much.
For
me.
F
A
A
E
I
mean
280,
characters
is
difficult,
I
mean
I'm
all
about
the
Twitter,
but
this
one's
hard
I
think
the
history
of
the
project
is
that
you
know
a
lot
of
experience
at
Google
and
beyond
around
how
to
run
API
driven
automatic
scalable
systems.
That's
you
know,
containers
are
a
part
of
it,
but
it's
not
the
defining
part
of
the
system.
The
history
of
the
project
is
that
knowledge
existed
inside
of
Google
and
we
focused
on
how
do
we
make
it
available
more
widely,
along
the
way,
open-source
being
one
of
the
techniques?
E
The
initial
goal
out
of
that
project
was
to
provide
a
better
way
of
deploying
and
using
software,
so
that
you
know
from
from
the
Google's
point
of
view,
the
motivation
for
Google
was
that
it
actually
essentially
ends
up
resetting
some
of
the
expectations
when
it
comes
to
the
cloud
platform.
You
know
you
say
it's
like
shake
the
snow
globe
right,
it's
like
it
essentially,
if
we
can
find
a
better
way
to
do
stuff
than
it
actually
puts
all
the
cloud
providers
and
other
folks
on
it
uneven
footing
to
be
able
to
compete
on
this
stuff.
E
A
F
I,
don't
like
singling
out
any
single
contributor,
because
I
honestly
think
anyone
that
helps
is
amazing
right
like
and
then
anyone
who
helps
review
or
comment
or
make
something
you've
worked
on.
Better
is
like
super
amazing,
so
I'm
hard
pressed
to
to
name
any
individual
per
se,
but
I
just
I.
Think
no
contribution
is
too
small
and
I.
F
D
Docs
wasn't
mentioned,
but
I'll
mention
Docs,
because
I
put
a
lot
of
effort
into
that
at
some
point,
like
all
those
things
are
super
hard
to
get
people
to
do,
but
they're
immensely
critical
to
keeping
the
project
moving
along
and
making
it
successful,
especially
when
people
step
up
and
it's
not
their
full-time
job
like
I'll
call
out
Christoph
again
for
that
just
helping
to
to
paying
everybody
and
move
things
forward.
Dimms
is
also
good
at
that,
although
I
think
it
is
his
job,
somebody
or
another,
but
I.
C
Strongly
applaud.
You
are
like
a
really
friendly
lot
around
here,
even
if
it
sometimes
doesn't
look
like
it.
Even
if
sometimes
things
go
quiet
and
it
can
be
difficult
to
reach
the
right
people
or
find
the
right
signal.
We
know
we
hear
you.
We
agree
with
you
as
long
as
we
remember
that
they're
like
humans
on
each
side
of
the
screen,
I
think
that's
super
helpful,
and
so
those
who've
made
the
journey
like
I
can't.
Thank
you
enough.
G
The
other
observation
is
that
effort
does
not
equal
value
in
all
cases,
and
there
are
some
people
who
make
enormous
contributions
in
terms
of
value
which
are
not
necessarily
reflected
in
you
know:
vast
amounts
of
actual
hours
or
yeah
those
kinds
of
things.
So
so
I
would
say
you
know
if
you
want
to
know
how
to
best
contribute
to
the
project.
G
Don't
look
only
at
large
amounts
of
you
know,
commenting
on
PRS
and
shepherding
things
around,
but
but
look
at
the
highest
value
thing
that
you
can
do
with
the
least
amount
of
effort,
and
especially
if
they
things
that
other
people
can't
necessarily
do
because
they
don't
have
the
skills
or
the
experience.
Or
perhaps
the
resources
available
and
focus
your
attention
on
those.
A
All
right,
thanks
for
that,
and
then
the
next
question,
so
we
have
a
few
questions
like
this.
A
few
folks
have
pinged
and
said
that
they
are
contributing
to
the
project
right
now,
as
current
contributors,
however,
doesn't
sound
like
any
of
them
are
with
cloud
providers
and
they
feel
like
they're
having
a
hard
time
finding
their
voice
or
just
really
getting
that
credit.
E
F
F
Yesterday
we
were
actually
discussing
this
exact
topic
because
oftentimes
people
who
want
to
contribute
or
may
be
more
quiet
or
passive
on
a
state
call
or
don't
know
who
to
reach
out
and
on
the
mentorship
side
everyone's
often
wants
to
help
the
broadest
set
of
people
we
can.
But
then
you
want
to
be
able
to
focus
where
you
can
mentor
effectively
in
the
time
that
everyone
has
that
scarce.
F
So
I
would
say
that
for
folks
who
do
want
to
help
attend
a
cig
meeting
and
just
speak
up
that
you'd
like
to
help
and
try
not
to
scope
your
participation,
at
least
depending
on
the
state
you're
looking
to
do
your
work
in
around
just
meeting
your
own
particular
pet
use
case.
But
making
your
use
case
broadly
important
to
the
rest
of
the
group
is
probably
the
biggest
thing.
A
D
A
E
I'm
just
go,
you
know,
start
small
start
within
a
cig,
build
up
some
relationships
there
and
you
know
I
think
what
we're
trying
to
do,
or
at
least
what
I'm
trying
to
do
with
with
the
SIG's
is
create
a
smaller
group
of
folks
so
that
it
becomes
a
person,
a
person
thing
versus,
or
this
large
sea
of
people,
and
so
I
think
you
know
fine
to
find
your
find
a
sort
of
a
smaller
group
that
you
can
start
integrating
with
and
working
with
and
and
then
grow.
Your
participation
from
there.
I
I
It's
like
a
little
sticky
note,
basically
on
a
contributor
role,
board,
SIG's
looking
for
help
people
looking
to
help
looking
for
SIG's
and
then
we're
gonna
try
to
match
them
up
together
there
so
that
we
can
find
put
people
in
the
right
spot
with
the
right
skills
that
they
have
and
then
for
SIG's
to
be
able
to
kind
of
delineate
and
list
things
that
they're
looking
for
help
with
some
requirements
and
things
that
are
expected
so
that,
like
you,
know
we're
set
contributors
for
success
as
opposed
to
you.
You
know:
hey
I'm
new
here.
I
D
Looking
for
and
if
you
look
at
the
stats
contributor
turnover
is
massive
on
the
project
like
90,
something
percent
of
contributors
only
contribute
one
or
a
few
PRS,
so
that
is
extremely
taxing
to
to
reviewers
and
approvers
and
mentors
and
other
people
who
are
trying
to
onboard
contributors,
especially
helping
people
through
a
complex
feature.
So
you
know
signing
up
for
some
commitment.
The
project
is
also
much
more
likely
to
get
senior
people
on
the
project
just
to
spend
a
lot
more
time
with
you
just
from
a
practical
perspective.
D
F
I
think
maybe
maybe
this
is
a
blog
series
we
could
do
but
I
think
to
Brian's
point
on
impedance
mismatch.
I
mean
I've.
I've
worked
on
the
project
now
for
four
or
five
years,
I
forget
how
long
when
I
work
saying
but
explaining
how
existing
or
established
contributors
also
struggle
to
get
what
they
want
to
have
done
done
is
often
a
good
anecdote
to
share
so
just
to
know
that
new
contributors
experience
here
are
people
who
are
getting
involved.
It's
not
just
them
who
had
it.
F
It's
also
everyone
else,
who's
in
the
project,
so
I
think
all
of
us
who've
worked
on
the
project
long
enough.
That
realized
that
the
journey
is
consensus-building
more
than
the
code
committing
a
lot
of
times,
and
so
some
of
the
issues
that
people
look
to
tack
are
lit
literally
like
the
most
extreme
bounds
of
computing,
and
so
the
knowledge
that
everyone
else
has
to
go
and
go
on
that
journey
with
you
needs
to
accumulate
is
significant
and
I.
F
Think,
in
some
cases,
just
sharing
like
individual
contributors,
like
I,
tried
to
do
this
for
the
last
18
months,
and
this
is
the
journey
I
had
and
why
we,
where
we
are
and
I
still
didn't
get
this
one
that
feature
done,
might
often
help
make
the
impedance
mismatch
more
relatable,
as
we
also
match
that
with
along
the
way
I
got
these
other
things
done
and
learn
list.
We
have
the
project
better
as
a
consequence.
F
F
D
E
I
think
there
is
this
problem
where
there
are
times
when
folks
will
write
a
lot
of
code,
submit
a
PR
and
then
and
then
be
told
oh
you're,
doing
everything
wrong,
and
then
they
rewrite
it
three
times
and
then
at
the
last
minute
somebody
swoops
in
and
says.
Well
what
about
this
other
thing
and
that
can
be
an
incredibly
frustrating
demotivating
experience.
E
I
always
hate
to
see
that
happen,
and
so
some
of
the
work
that
we're
putting
in
in
terms
of
trying
to
get
some
of
the
right
processes
in
and
trying
to
create
line
to
site
within
SIG's
is
to
reduce
the
amount
of
frustration
for
folks
doing
a
ton
of
work
before
they.
They
know
that
it's
going
to
fly
so.
H
E
Think
you
know
the
other
piece
of
advice
there.
It's
like
use
things
like
the
kept
process.
It's
not
a
hundred
percent.
Yet
like
there's
a
hefty
owe
employee.
We
were
trying
to
get
something
in
and
it's
like
and
we
hit
a
wall
because
it's
not
totally
all
done
yet
for
this
release,
but
you
know
pre-flight.
Some
stuff
talked
to
folks.
You
know
build
up
some
of
that
and
you
know
it
takes
time
to
build
those
relationships
because
it
is
a
relationship
based
thing,
but
but
we're
trying
to
improve
that
situation.
A
D
Yeah,
so
that
comes
from
a
combination
of
constraints
about
supported
versions,
q
in
the
system
and
how
we
expect
the
components
to
be
upgraded
so
originally.
Originally,
we
did
not
officially
support
upgrades
of
kubernetes
at
all
pre
1.0,
and
then
we
were
trying
to
figure
out
what
kind
of
upgrade
process
we
should
support.
D
This
is
in
the
original
Cuba
bootstrapping
scripts
in
the
cluster
directory,
which
very
well
yeah,
and
so
we
came
to
the
conclusion
based
on
you
know,
periods
how
people
would
want
to
test
these
things
and
upgrade
and
downgrade
and
the
pace
of
upgrades,
and
so
on
that
we
needed
support
to
releases
a
version
skew
between
the
cubelets
and
the
control
plane
and
practically
speaking,
only
one
release
of
version
skew
between
cube
control
and
the
control
plane.
But
cubelet.
We
expect
it
to
be.
We
expected
to
upgrade
the
control
plane
first
and
cubelet
after
so.
D
Cubelet
was
strictly
behind,
whereas
keep
control
needed
to
be
able
to
be
used
against
multiple
clusters,
including
those
have
been
upgraded,
so
you
needed
to
have
forward
compatibility
in
order
to
operate
against
multiple
clusters
that
were
being
upgraded.
So
the
combination
of
those
requirements
ended
up
being
that
we
meet
at
least
needed
3.
So
we
decided
that
we
would
support
3
in
patch
3
and
we
were
able
to
sustain
that
and
that
effectively
became
the
de
facto
standard
and
as
we
formalized
the
release
processes,
we
wrote
that
down.
D
We
did
once
patch
1
older
version
with
some
security
patches.
That
was
super
painful
because
we
were
no
longer
running
continuous
testing
on
that
release
version.
So
I,
don't
think
we'll
continue
to
do
that.
It's
it's
hard
to
sustain
and
it's
super
expensive.
If
you
saw
the
recent
grant
announcement,
but
that's
where
it
comes
from.
It's
just
that
combination
of
version,
skew
constraints.
A
Awesome
and
then
the
last
one
is
mostly
open-ended.
What's
one
thing
that
you
wish
all
contributors
were
on
the
same
page
about
whether
it's
a
tip
or
whether
you
feel
like
there's
a
trend
happening,
maybe
with
reviews
you
can
get
as
technical
as
you'd
like
or
high-level
as
you'd
like
Joe.
Your
first
I
would.
E
Say
that
it
it
takes
all
sorts
of
contributors
to
really
make
communities
work
as
a
project.
It's
not
just
about
the
code
there's
so
many
other
things
that
go
into
making
the
project
work,
and
so
I
want
everybody
to
to
really
recognize
the
sort
of
the
breadth
of
you
know:
passion,
experience
and
types
of
people
and
what
they're
all
bringing
to
the
party.
So
that's,
that's
the
one
thing
I
want
everybody
be
aware.
A
H
Want
everyone
to
remember
anytime,
you're,
responding
to
something
that
there
is
another
person
who
is
put
effort
in
perspective
and
thought
into
this.
Most
of
our
contributors
do
spend
a
lot
of
time
working
on
this
project
and
especially
those
who
might
not
and
might
not
have
all
of
the
history
of
what's
gone
on.
They
still
have
not
spent
some
time
thinking
about
a
response
and
thinking
about
an
issue
that
they've
submitted,
etc.
H
So
as
long
as
we
all
remember,
there's
another
person
who
has
made
an
effort
to
share
something
behind
every
pull
request
behind
every
issue
we
made
every
whatever
interaction
there
are.
We
have
such
better
experiences
for
new
contributors,
existing
current
contributors,
people
that
are
moderating
the
different
slack
channels,
the
different
email,
aliases
and
groups,
etc.
It's
just
so
much
better.
If
you
take
just
that
five
seconds
to
go,
you
know
what
there's
another
human
who
has
actually
spent
some
time.
G
Very
briefly,
you
know
that
this
whole
project
is
driven
by
people's
passion,
to
do
things
and
if
you
kill
that
passion
the
entire
project
dies.
And,
conversely,
if
you
keep
everyone
excited
about
loving,
you
know
logging
on
every
morning
and
seeing
what
feedback
they
got
on
their
PR
or
which
PRS
they
get
to
review
today
or
whatever
that
that
work
flow
looks
like
that's
how
you
sustain
the
project.
You
know
a
lot
of
the
other
stuff
is
details
and
people
enjoy
working
on
this
thing.
G
D
Please
remember
that
it's
nothing
personal,
just
there's
a
huge
amount
of
a
huge
volume
of
things
going
on
in
the
project
and
many
of
the
pull
requests
and
issues
don't
have
the
right.
People
subscribed
and
the
teams
don't
have
the
right
people
on
them
and
things
like
that.
So,
if
you
don't
get
a
response,
please
try
one
of
the
other
channels.
Try
slack
try
email
show
up
at
a
cig
meeting,
it's
nothing
personal.
We
want
to
do
better,
just
that
we
have
not
been
able
to
make
the
mechanisms
work
adequately.
F
Just
a
hundred
percent
would
agree
with
what
Ryan
said.
I
mean
I
github
mentions
is
an
impossible
thing
to
track,
and
while
we
have
tools
to
try
to
help
steer
people's
attention,
I
always
actually
appreciate
when
someone
reaches
out
on
slack
or
it
comes
to
this
big
meeting
and
says:
hey,
can
someone
look
at
this
again,
just
as
a
way
of
closing
that
human
loop
we're
reading?
F
All
of
your
email
is
really
difficult,
so
I
agree
with
Brian,
as
that's
like
a
key
contributor
tip,
is
don't
give
up
if
your
issue
didn't
get
a
response
reach
out
to
someone
and
everyone,
as
Sarah
said,
is
typically
very
friendly
and
wants
to
help
out
it's
just.
They
might
have
lost
your
your
issue
or
common
in
the
noise.
C
So
I
agree
with
everything
everybody
said
and
since
you
all
were
so
nice,
let
me
let
me
do
something
a
little
different
and
that
is
to
say
that
I
believe
very
strongly
that
flaky
or
failing
tests
that
continue
to
be
flaky
or
failing
or
worse
than
no
tests
at
all,
and
if
you
are
responsible
or
own,
some
of
these
tests,
I
am
coming
for
you
and
I
will
take
those
tests
away.
That
is
all.
A
Alright,
well
that
wraps
up
today's
steering
commitee
edition
of
meet
our
contributors.
This
was
fun,
expect
this
monthly.
Actually,
they
will
join
us
at
either
the
2:30
at
p.m.
UTC
or
8
p.m.
UTC,
depending
on
when
their
steering
committee
is
a
steering
committee
meeting
is
that
day,
but
we
will
continue
to
cycle
through
steering
committee
members
for
an
AMA
and
that's
it
for
me
panelists
if
you
can
stay
on
stay
on
after
we
cut
the
stream
and
if
not
thanks
so
much
for
participating
today,
all
right
we're
out
of
here.