►
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.
See https://contributor.kubernetes.io/mentoring/meet-our-contributors/ for more information
A
Hi
everyone,
my
name,
is
Paris.
Welcome
to
the
second
episode
of
October's
edition
of
meet
our
contributors
today
is
our
special
episode
of
the
steering
committee.
Ask
us
anything.
We
have
some
awesome
panelists
here
today
to
answer
any
questions
that
you
might
have
related
to
governance,
steering
committee,
stuff
projects,
project
related
business,
I'm,
sure,
Aaron
will
even
ask
or
answer
TestFlight
questions
feel
free
to
address
us
with
anything
and
we'll
try
to
take
it.
A
First
off
we
do
have
a
code
of
conduct
that
does
apply
to
all
of
our
communication
platforms
and
since
we
are
interfacing
with
Xoom
youtube,
slack
and
twitter
today,
that's
a
lot
of
them,
so
please
be
excellent
to
each
other
and
then
panelists,
don't
forget!
You
are
allowed
to
ask
each
other
questions
so
feel
free
to
jump
in
at
any
point
as
well
and
then
that's
it.
So
we'll
move
on
to
intros
first
person
that
I
see
in
my
screen
right
now
is
Aaron
of
cig
beard.
B
I'm
Aaron
of
cig
beard,
also
known
as
Aaron
Cruden
burger.
You
may
have
heard
of
me
through
co-founding
sig
testing
on
the
project.
You
may
have
seen
me
talk
about
graphs
of
the
week
or
various
automation.
Things
during
the
community
meeting
I've
been
involved
in
the
kubernetes
release
process
since
1/4
and
most
recently
I
am
the
release
lead
shadow
for
113
I,
currently
work
for
Google
on
the
engineering,
productivity
team
or
gke
Brendan.
How
about
you
next.
C
Okay,
hi
I'm
Brenda
burns
I
have
been
on
the
project
since
the
beginning.
I
am
currently
well
I
guess
on
the
project
I
work.
In
addition,
the
steering
committee
I
lately
have
been
working
on
client
libraries.
So
if
you
use
an
on
go
client
library
except
Python,
it's
something
that
I've
worked
on,
not
that
I
don't
like
Python,
but
just
that
someone
else
had
already
picked
it
up
and
I
work
for
Microsoft
Azure
and
coordinate
a
number
of
teams
there,
including
the
kubernetes
service
in
our
upstream
work
as
well.
D
D
I've
been
involved
in
number
of
SIG's
over
time
depending
upon
the
stage
and
growth
of
the
the
organization
and
the
project
in
the
beginning,
as
I
was
sick,
lead
or
Coast
League
lead
for
SIG's
scalability,
as
well
as
scheduling
and
in
recent
times,
I've
worked
on
some
projects
for
suggesting
and
I'm
leading
up
efforts
around
sequester
lifecycle,
which
is
basically
trying
to
unite
the
clans
around
Kubb
ADM,
ich
type
things.
There
are
many
ongoing
efforts
in
sequester
lifecycle.
A
Awesome,
thank
you
to
all
of
you
for
joining
today.
I
know
you
all
have
very
busy
schedules,
so
we
will
get
on
with
it
first
things.
First,
today
is
the
last
day
for
the
election.
This
is
the
second
election
for
communities
for
steering
committee.
So
what
are
your
thoughts
on
the
overall
processes
time
and
how
did
you
make
a
choice
to
use
dev
stats
and
and
the
50
threshold
I.
D
D
There
are
people
who
do
lots
of
other
work,
that's
not
directly
related,
but
it
is
very
beneficial
to
the
community.
So
we
still
have
the
exemption
process,
and
that
was
a
holdover.
From
last
time,
we
used
the
same
procedure
as
we
did
from
the
previous
election,
so
our
plan
there
was
that
we
wanted
to
make
sure
that
it
was
fair
and
it
was
very
clear
what
the
threshold
was
and
and
that
we
always
provide
an
opportunity
for
other
people
to
join.
D
But
we
also
wanted
to
make
sure
that
with
each
iteration
we
don't
want
to
have
this
sort
of
grandfathered
cycle
for
every
single
iteration.
We
wanted
to
make
sure
that
people
who
are
actively
contributed
to
have
a
voice
and
say
in
the
community-
and
you
know,
people
change
jobs-
they
go
here
and
there
and
that
doesn't
make
a
lot
of
sense,
for
you
know,
I'm
still,
a
PMC
member
on
the
batching
base,
notice,
I,
probably
shouldn't
be
right
because
I
haven't
conceded
and
that
would
sub-code
and
forever.
B
Think
there
was
a
fair
amount
of
debate
as
well
over
whether
or
not
we
were
going
to
be
able
to
accurately
measure
the
value
of
different
people's
contributions
and
whether
we
should
wait
accordingly.
So
I
think
the
certainly
ultimately
came
to
is
that
more
is
better,
that
there
may
potentially
be
some
bad
actors
or
some
people
who
are
gaming.
B
Now,
ultimately
like
that's,
it's
fine,
whatever
a
typo
fix
is
honestly
a
really
great
way
for
a
first-time
contributor.
Take
like
go
through
the
code
review
process
and
see
what
that's
like.
So
it's
not
like.
We
want
to
actively
discourage
that,
and
so
we
ultimately
came
to
the
decision
that,
like
one
vote,
should
be
equal.
So
the
one
thing
that
we
steering
committee
members
were
allowed
to
do
was
vote,
but
we
won't
vote
with
the
same.
You
know
strength
importance.
C
Guess
the
only
other
thing
that
I
think
it's
important
to
add,
and
we
talked
a
lot
about
last
time.
That's
congest
we're
highlighting
again
is
that
there's
always
been
an
exception
process
that
we
never
felt
like.
We
would
ever
be
able
to
get
it
right
fully
right
and
so
I
don't
think
we
want
to
be
in
a
situation
where
you
know
we
have
we're
standing
up
and
saying
this
is
the
perfect
way
to
do
things.
C
B
That's
that's
important
to
note
also
to
two
other
things.
I
just
wanted
to
point
out.
One
I
found
it
very
personally
I
found
it
really
helpful
that
you
had
the
Paris
you
as
an
election
officer,
opted
to
go
with
the
process
of
checking
in
the
list
of
voters
into
github.
It
was
a
really
one-stop-shop
answer
for
me
too,
for
people
who
are
like
wait.
D
Another
just
side
topic
for
those
who
are
interested
or
think
that
you
know
there
was
a
lot
of
thought
involved
or
the
I've
heard
analogous
things
in
the
community
where
some
people
have
mentioned
that
it
feels
open,
stachy
or
some
returning
down
and
interesting
OpenStack
path.
But
one
thing
I
want
to
stress
too,
is
that
this
is
actually
a
document
that
you
can
PR
against
in
the
queue
in
the
steering
repo.
D
So
if
you
have
suggestions
comments
or
how
to
improve
the
process,
you
know
absolutely
feel
free
to
submit
a
PR
and
the
steering
committee
will
then
reevaluate
if
that
makes
sense
for
the
next
election
cycle.
So
as
Brandon
mentioned
I,
don't
know
if
we're
ever
going
to
get
it
right,
but
that
doesn't
mean
we
can't
refine
and
get
it
better
every
single
time.
So
if
you
have
questions
comments,
complaints
concerns
the
the
best
way
to
do
that
is
submit
a
PR
with
your
suggestion
on
how
to
make
it
better.
A
Yes
and
for
those
listening-
and
you
are
eligible
to
vote,
you
still
have
a
few
hours
left,
I
feel
like
I'm,
just
like
beating
I'm
beating
the
drum
at
this
point.
But
yes,
you
still
have
a
few
hours
left.
If
you,
for
whatever
reason
realize
you
don't
all
of
them,
do
not
have
a
ballot,
we're
still
here
as
well
community
a
kubernetes
that
I
Oh
awesome.
So
let's
close
the
book
on
that
the
only
election
question
that
I
had
all
right.
A
The
next
came
in
and
folks
want
to
know
anything
new
that
happened
since
the
last
time
you
were
on
meet
our
contributors,
which
is
about
four
to
five
weeks
ago,
I've
seen
a
lot
of
discussion
about
working
groups,
anything
anything
get
finalized
or
merged.
In
the
last
four
to
five
weeks,
steering
related.
B
So
I
know
we
are
basically
I
think
at
the
second
wave
of
state
charters,
I
believe
most
of
the
outstanding
state
charters
have
more
or
less
been
reviewed.
I
know:
I
got
pings
personally
by
somebody
for
sig
multi
cluster
and
I
saw
notification
that
sig
AWS,
as
charter
is
out
there
and
I
saw
a
friendly
poke
from
Quentin
cool
on
sig
testings
mailing
list
about
us
not
having
a
charter
there.
So
I
think
I
don't
have
hard
numbers
in
front
of
me,
but
we're
we're
very
close
to
the
50
percent
mark.
If
not
further.
B
There
I
think
it
was
really
helpful
to
just
boil
it
down
to
we're
not
trying
to
solve
all
the
world's
problems.
Just
reference
this
this
document,
that
kind
of
has
the
standard
set
of
boilerplate
for
governance
stuff
and
then
let's
try
and
focus
specifically
on
code
and
binaries
and
processes,
both
in
scope
and
out
of
scope.
I
think
that's
been
super
helpful.
There
was
a
lot
of
discussion
around
working
groups,
I
think
I'm,
probably
going
to
let
Brendon
and
him
talk
more
in
detail
there,
but
I
did
made
it.
B
We
did
manage
to
at
least
decide
that
the
ongoing
effort
to
move
all
of
the
kubernetes
project
infrastructure
out
of
Google's
hands
and
into
the
sea
and
CF
s--
hands
is
going
to
be
done
as
a
working
group,
since
it
seems
like
it's
something
that
encompasses
work
owned
by
multiple
say,
such
as
release
and
testing
and
architecture
and
contributor
experience,
so
I
will
be
drafting
up
a
charter
for
that
and
I
believe.
That's
all
I
have
to
say
for
now
Brendon
you
look
like
you
were
gonna
go
next.
C
D
A
B
Other
thing
I'll
highlight
is
the
this
is
not
something
we
necessarily
were
directly
involved
in,
but
I
think
it's
a
great
example
of
how
to
work
with
the
steering
committee.
The
product
security
team
wanted
to
put
together
a
document
that
describes
sort
of
their
governance
policies
because
they've
been
operating
under
kind
of
a
cloak-and-dagger,
shadowy
level
of
trust,
and
they
want
to
formalize
that
to
be
able
to
rotate
people
in
and
out,
and
they
had
the
steering
committee
take
a
look
at
that.
B
So
it
was
a
great
example
of
bringing
kind
of
like
a
fully-formed
idea
for
an
up/down
boat
from
the
steering
committee,
and
that
was
a
great
example
of
progress.
Also
don't
have
hard
numbers
to
point
to,
but
I
think
that
a
large
number
I
think
the
github
management
sub
project
has
really
taken
the
load
off
of
the
steering
committee.
B
When
it
comes
to
approving
new
repos
for
different
sub
projects,
we
have
been
servicing
a
large
number
of
those
requests
and
I
haven't
heard
any
complaints
over
lag
time
or
complications
in
the
process
or
lack
of
clarity
or
anything.
So
if
anybody's
disagrees
with
that,
I
would
greatly
love
to
hear
from
you.
B
B
A
C
C
That's
definitely
something
I
mean
like
it's.
It's
a
remarkable
that
there's
that
number
of
people
who
are
interested
in
talking,
that's
a
real
testament
to
the
community.
I
think
also
one
thing
that's
underappreciated
perhaps
is
that
like,
while
we
see
each
other
on
pixelated
screens
a
lot,
we
don't
actually
see
each
other
in
person
on
that,
often
even
within
the
same
companies
we
are
often
very
geographically
distributed,
and
so
it's
nice
to
have
a
central
place
to
come
together
and
then
also
I
love,
meeting
people
who
are
using
the
product
and
hearing.
C
Things
they're
struggling
with
or
find
hard
I
think
you
know
it's
hugely
valuable
to
get
a
sort
of
a
reality
check.
There's
someone
who
really
has
no
vested
interest
like
I
sort
of
invested
interest
in
people
like
in
communities
that
a
user
has
very
little
nested
interest
in
being
anything
but
honest,
and
that
perspective
is
always.
D
D
Maybe
they
might
work
for
a
company
that
doesn't
allow
them
to
do
those
things
right,
I,
work
for
a
private
entity
and
then
I
have
its.
You
know
problems
that
are
there
or
you
know
they
think
X
could
work
better
and
I
think
as
open-source
developers
in
contributors,
and
you
know
steering
committee
members,
we
kind
of
thrive
on
feedback
right,
so
that
feedback
is,
is
super
essential
to
the
you
know,
the
long-term
sustainability
of
the
project
and
for
me,
I
think,
that's
that's
what
I
get
most
out
of
it.
It's
just
talking
with
individual
contributors.
B
So
I
strongly
echo
Brendan
and
Tim's
point
I
was
going
to
say
that,
like
first
off
I
consider
myself
a
massive
massive
introvert
when
I
took
the
myers-briggs
the
person
giving
me
the
results
said
like
you,
you
know
you
could
actually
be
a
monk
you'd
be
fine
on
a
monastery
with
zero
human
interaction
and
I've,
never
really
enjoyed
conferences
until
I
went
to
coop
con.
And
it's
it's
unclear
to
me
what
it
is
about.
Coop
con,
but
every
time
I
go.
B
B
B
Gotta
stay
on
brand,
the
I
think
a
point
Brendan
and
Tim
both
raised
is
very
important.
Is
the
the
forum
of
feedback
from
real
world
users
I?
Think
the
humanity
and
empathy
can
sometimes
be
lost
when
it
comes
to
interacting
with
a
faceless
project,
the
github
issues
that
seem
to
be
ignored
or
mailing
lists
that
seem
to
just
not
respond
in
any
way
shape
or
form.
B
It's
a
lot
harder
to
do
that
in
person
and,
generally
speaking,
the
reason
there's
not
that
much
of
response
on
our
end
is
because
we're
fantastically
busy
with
a
lot
of
stuff.
It's
not
because
we
don't
want
to
listen
and
I
do
think
it
speaks
to
a
need
going
forward
to
figure
out
the
best
forum
and
the
best
way
to
appropriately
capture
user
feedback
and
find
a
way
to
turn
that
into
actionable
stuff.
B
I
often
think
that
this
is
a
very
rich
community
when
it
comes
to
its
contributors,
but
it
perhaps
can
feel
very
insular
to
people
who
are
actually
using
kubernetes
as
a
product
and
I
really
want
to
find
ways
to
escape
the
echo
chamber.
So
you
know
you.
Face-To-Face
interactions
are
definitely
one
great
way
of
doing
that
and
then
to
circle
back
on
the
question
like
from
my
level
speaking
as
a
current
steering
committee
member,
at
least
as
of
today,
like
I,
really
enjoyed
all
of
the
steering
committee
members
getting
together
physically
in
the
same
room.
B
It's
just
some
of
the
things
that
we
have
to
work
through,
can't
really
be
effectively
dealt
with
for
an
hour
every
two
weeks.
They
do
require
some
focused,
concentrated
effort
and
as
fun
is.
It
can
be
to
hash
things
out
for
four
hours
at
in
a
row
in
a
room
over
some
document
or
something
like
it's
important
and
necessary
and
and
I
do
think
that
that
will
give
us
an
opportunity
to
really
unblock
a
couple.
Sticky
questions.
Don't
ask
me
for
examples
right
now.
Please,
yes,.
A
And
if
you
are
a
contributor,
this
is
your
plug
for
the
contributor
summit,
which
is
happening.
December,
9th
and
10th
pre
cube
con.
There's
a
lot
of
hallway
track
like
discussion.
That
happens,
especially
on
December
9th.
That
is
pretty
much
a
gigantic
hallway
track
for
four
hours
so
plenty
of
time
to
meet
fellow
contributors.
Right
now
we
already
have
220
people
signed
up,
that's
massive
Copenhagen.
We
had
120
excuse
me
190,
so
we
have
already
surpassed
that
we
are
quickly
on
our
way
to
sell
out,
so
that
is
in
a
Google
Form.
A
If
you
subscribe
to
kubernetes
devs
mailing
list,
you'll
be
able
to
find
it
there.
It's
also
in
many
many
other
corners
of
the
Internet
as
well,
but
that's
a
quick
stop
for
you.
You
alright,
so
I
have
two
questions.
That's
sort
of
relate
to
the
path
of
a
individual
who
wants
to
be
a
steering
committee.
Member,
so
I
got
pinged
on
DM.
They
said
I'm
your
average
code
contributor,
at
least
right
now,
but
they
are
very
interested
in
the
work
that
you've
been
doing
the
governance,
project
direction
and
things
along
those
lines.
A
C
I,
don't
know
I,
think
everybody's,
just
sort
of
a
code
contributor
at
some
level,
and
then
you
find
the
next
thing
to
volunteer
for
be
it
shadowing
on
a
release
or
taking
on
a
project
that
someone
mentions
in
a
sig
call
or
I
mean
I,
think
probably
I
guess
attending
a
sig
is
probably
the
next
best
thing:
fine
to
the
sig.
That's
interesting
to
you
and
attend
the
see.
I
mean
because
then
you'll
see
I
mean
I,
don't
know,
I
think
there's
definitely
always
requests
for
help
on
things.
C
Some
SIG's
probably
are
have
more
requests
for
help,
but
so,
like
I,
think
contributor.
Experience,
for
example,
is
one
that
is
sort
of
perennial
e
out
there.
Looking
for
people
who
are
willing
to
take
on
engineering
tests,
it
might
not
be
I.
Think
it's
interesting
to
you.
So
you
have
to
find
the
balance
between
personal
interest
and
availability
of
tasks
and
some
things
like
you
know,
sig
note
it's
going
to
be
way
harder
to
break
into
that.
C
Just
because
it's
a
very
complicated
piece
of
important,
complicated
piece
of
code
right
API
machinery
can
be
extremely
abstract
and
and
whatnot.
So,
like
I
think
you
have
to
have
expectations
about
where
you
want
to
go,
and
you
know
the
path
that
you're
gonna
take.
But
but
it's
pretty
straightforward,
I
guess
it's
not
like
it's
not
like.
There's
a
secret
knock
or
something
I
think
sometimes
people
think
there's
a
secret
knock
I.
Think
it's
just
sort
of
show
up
and
they'll.
B
Yeah
I
I,
don't
know
I,
don't
feel
like
I
have
a
fountain
of
wisdom
to
his
house
here,
but
I
feel
like
commit
to
things
and
get
things
done
is
just
one
piece
of
feedback
like
say:
you're,
gonna
do
a
thing
and
then
actually
do
the
thing,
because
they're
constantly
SIG's
asking
for
help
on
this
or
that
some
of
its
low
frame
hanging
fruit,
some
of
its
larger
I,
also
like
one
of
they
clear
that
it
is
extremely
possible
to
get
things
done
in
this
project.
Without
being
a
steering
committee
member.
B
We
we
actively
want
and
encouraged
the
style
of
governance
that
allows
people
and
mostly
get
things
done
without
requiring
this.
So
if
you
want
to
stay
a
purely
technical
contributor
go
for
it,
but
I
feel
like
the
skills.
You'll
need
to
be
an
effective
steering
committee.
Member
move
beyond
just
exerting
sheer
force
of
will
through
a
keyboard,
to
get
things
done
and
require
talking
things
out
with
other
people,
so
understanding
when
the
tasks
crossed
certain
boundaries.
B
D
Governance
is
like
learning
how
to
arbitrate
and
find
the
happy
path
forwards,
because,
ultimately,
it's
about
setting
the
ground
rules
for
how
we
operate
as
an
organization
and
how
we
sort
of
structure
ourselves
and
govern
ourselves
right
because
in
reality,
like
I,
think
a
lot
of
people.
Think
of
steering
as
like
we're
governing,
but
in
reality
we're
divesting
and
giving.
You
know
giving
responsibilities
to
different
parts
of
the
organization.
We
don't
really
try
to
lead
from
on
high.
We
try
to
solicit
opinions
and
ideas
and
try
to
push
that
responsibility
on
to
the
appropriate
parties.
C
You
know
I
think
that's
been
mentioned
earlier.
We
tend
to
be
really
really
busy
and,
and
so
that
means
we
win
some
cases.
We
move
very
slowly
and
I
think
we
worry
and
we
try
very
hard
to
sort
of
get
out
of
people's
way.
But
I
worry
sometimes
that
we
people
are
waiting
on
us
and
we're
not
we
don't.
We
don't
execute
with
a
cadence
that
helps
project
I.
Do
think
that
what
Jen
said
about
the
like,
you
know
thinking
about
all
the
possible
consequences.
B
I
try
to
like
ask
for
yes/no
decisions
as
much
as
I
can,
rather
than
try
and
hash
things
out
on
an
email
thread,
and
then
part
of
that's
just
because,
like
I'm,
not
a
great
writer,
so
it
takes
me
forever
to
write
that
stuff
anyway,
but
I
also
really
value
everybody's
time,
and
so
I
want
to
make
the
most
use
of
our
time
by
trying
to
ensure
that
we're
saying
yes
or
no
to
actionable
decisions.
I'd
often
find
whenever
somebody
like,
once
the
steering
committee,
to
figure
something
down
figure,
something
out
or
hash
something
out.
B
That
is
almost
always
a
recipe
for
death,
because
we
just
spend
so
much
time
trying
to
articulate
all
the
details
and
play
all
the
devil's
advocates.
It's
so
much
easier
if
fully-formed
work
comes
at
us.
That
is
mostly
correct,
that
we
can
say
yes
or
no
to
so
yeah
Tim
I'm,
so
curious,
like
you
were,
you
were
gleefully
smiling.
D
There
too,
it's
pretty
much
exactly
the
same
as
yours,
like
I,
think
as
I've
been
in
this
project
now
for
14
years.
You
get
to
the
point
where,
like
time,
never
have
enough
time
right
and
time
is
our
most
precious
commodity,
and
sometimes
the
bike
shedding
can
can
be
believers
it's
necessary
at
some
times.
D
But
sometimes
do
you
think
it's
it's
too
much
and
knowing
when
you
should
do
it
and
when
you
shouldn't
right,
it
becomes
difficult
and
whenever
you
get
a
group
of
like
it's
over
seven,
seven
or
more
you're
gonna
get
some
bike
inside
of
there.
So
I
think
I
just
want
to
echo
here
in
statement
and
that
the
steering
committee
is
meant
to
serve
and
empower.
E
C
I
think
I
think
the
basic
argument
cut
area.
The
basic
definition
comes
from
arguing
about
the
color
of
the
bike
shed
before
you've
built
the
shed
itself
right.
It's
it's.
It's
arguing
about
something
that
is
irrelevant,
given
the
current
state
of
affairs
and
having
that
argument
actively
prevent
you,
it's
sort
of
a
paradoxical
loop
where
the
argument
is
actually
preventing
you
from
making
the
progress
necessary
to
get
to
the
place
where
you
should
have
the
argument
right.
B
It's
not
that
far
off
from
the
technical
yak
shaving,
where,
in
order
to
fix
this
bug
over
here,
you
have
to
go
fix
this
bug
in
that
library,
which
means
you
have
to
refactor
this
entire
thing
over
here,
which
means
you're
working
on
this
project.
Here,
just
to
get
one
simple
fix
in
over
here
and
before
you
know
it
you're
shaving
a
yak
to
do
a
favor
for
a
guy
whose
library,
a
meat-eating
so
actually
I,
think.
C
You
actually
I,
don't
think
you
actually
was
totally.
That
is
the
definite
view
actually
I'm
gonna
feel
like
it's
totally
offended
bike
shedding
bike.
Shipping
is
like
proactively
worrying
about
the
problem
like
that
there
might
be
a
yak
somewhere
in
there
somewhere
before
you
even
start
on
the
journey.
Yes,.
C
D
A
plus-one
what's
galang
actually
has
generics
and
going
to
you
I,
think
I.
Think
a
massive
Redux
of
API
machinery
is
in
order
the
that,
if
I
ever
have
a
second,
if
you
actually
look
at
the
internals
of
the
couplet
and
actually
understand
how
it
does
its
mojo,
it's
pretty
it's
pretty
intense
over
mojo
de.
So
the
it's
it's
interesting,
oh
yeah,.
C
D
B
Aaron
so
I'm
not
like
I,
haven't
actually
ever
looked
at
API
machinery
code,
but
I
think
I
agree
with
the
both
of
them.
It's
more
like
I
want
to
have
empathy
because
I'm
sure
there
are
challenges
that
are
being
solved
and
worked
around
there
like
the
lack
of
generics
in
golang.
But
it
does
seem
like
it's.
A
very
opaque
area
for
newcomers
to
contribute
to
like
I,
can
never
throw
somebody
new
and
API
machinery
which
oh
and
the
Builder
logic,
the
Builder
logic
and.
B
B
The
tests,
the
same
business
logic
without
having
all
the
fun
flakiness
of
environmental
dependencies
and
clouds
being
cloudy
and
networks
having
you
know
their
usual
level
of
reliability,
but
the
the
code
itself
is
really
really
horribly,
tangled,
there's
a
bash
script
that
calls
ginkgo
that
call
well
I!
Guess
if
you
really
roll
it
back
to
like
cube
test
our
binary,
we
have
cube
test
which
calls
the
shell
script,
which
calls
another
shell
script,
which
calls
ginkgo
with
a
bunch
of
flags
which
I
think
then
also
can
read
in
a
config
file.
B
C
A
D
On
inside
so
we've
been
spending
a
ton
of
time
on
making
it
easy
for
any
newcomer.
Instead,
cluster
lifecycle
to
just
engage
and
I
think
we've
been
really
productive
and
getting
people
promoted
right.
So
in
the
beginning
it
was
kind
of
it
was
one
of
the
many
things
and
communities
that
grew
organically
and
it
grew
really
fast
and
we
came
very
popular
but
then,
since
since
I
started
working
on
it,
my
primary
objective
has
been
to
like.
We
don't
want
to
have
a
couple
of
strong
people
being
the
core
contributors
all
the
time.
D
We
want
to
be
able
to
federate
this
out
so
that
way
newcomers
can
come
in
and
just
instantly
crawl
up
the
ladder
and
just
you
know,
be
active
and
contribute
and
I
think
it's
a
testament
to
like
a
lot
of
the
new
VMware
folks,
we've
I've,
just
like
jumped
on
in
the
last
couple
of
months,
who
are
just
really
productive.
We
have
a
bunch
of
other
folks
coming
in
from
every
single
provider
on
the
planet,
working
on
different
cluster
API
stuff.
D
It's
it's
been
kind
of
crazy
to
see
it
grow,
so
I
think
I'm,
happy
I'm.
A
little
self-promotion
up
because
I'm
helped
manage
that
sig,
but
we've
we've
done
a
lot
of
work
to
try
and
make
it
better
over
time
and
other
SIG's
I
worked
on
the
past.
It
was
not
that
way.
I
think
I
kind
of
learned
from
my
mistakes
over
time
and
tried
to
try
to
harness
all
that
history
and
experience
to
try
and
push
this
forwards.
Make
it
a
little
bit
better
I.
A
Alright,
one
of
the
popular
questions
for
the
last
steering
committee
was
what's
one
thing
that
keeps
you
up
at
night
about
her
Nettie's.
So
this
question
is
the
positive
end
to
that.
What
is
one
thing
that
keep
that
makes
you
wake
up
every
day
and
work
on
kubernetes
like
what's
one
thing
that
makes
you
feel
super
positive
about
it
and
you
are
full
steam
ahead.
The.
A
C
I
think
just
the
same
and
just
the
opportunity
to
help
people
do
a
better
job
with
their
I
mean
I
get
off
on
the
user's
as
well.
Right
like
the
community
is
fantastic
and
the
users
are
part
of
the
community,
but
like
I,
don't
I'm
excited
to
help
people
solve
their
problems
with
the
software
that
we're
building,
even
if
they
never
contribute
back.
That's
really
exciting.
A
There
is
another
question
in
the
chat:
Aaron
don't
know
if
you
might
actually
know
this
one.
When
you
start
a
new
project
that
say
uses
kubernetes,
api,
kubernetes,
api
machinery
or
kubernetes
client
go.
How
do
you
prepare
the
package
or
equivalent
for
what
you
use
for
been
during
odep
I?
Unfortunately,.
D
I've
done
a
number
of
projects,
I
almost
always
use
them
nowadays,
until
until
the
magic
modules
upstream
or
whatever
the
new
mechanism
that
go
actually
decides,
we
typically
use
depth
on
our
MTO
projects
and
we
always
update
to
the
latest
version
of
client
go
for
everything
and,
as
a
result,
you
will
drag
in
the
transitive
dependencies
you
need
and
the
depth
graph
is
finite.
So
don't
try
to
depend
on
anything
outside
a
client.
Go.
That's
probably
like
my
one.
Don't
do
not
go
here.
D
C
C
A
B
C
D
So
I
think
the
right
way
to
approach
it.
It's
not
perfect,
I'll
give
it
that,
but
there's
a
lot
of
you
do
get
a
lot
of
benefit.
If
you
do
use
it,
there's
a
lot
of
details
that
are
handled
for
you.
You
know
there
is
a
cost
associated
with
it.
It's
not.
You
know.
If
you're
someone
who
likes
to
control
the
intricacies
of
what
you're
developing
client
go
is
probably
not
the
way
to
go
all
right.
D
Some
people
will
just
you
know,
do
exactly
what
Brendan
had
mentioned
if
you're
someone
who
wants
to
rely
on
something,
that's
been
vetted
and
has
regular
vetting
intervals
and
has
a
well-defined
release
process
then
and
you're
using
it
in
a
well-defined
structured
way
and
Clank
Oh
will
probably
serve
its
purpose
for
you,
I've
used
it.
We've
used
it
at
FTO,
consistent
across
all
our
projects
and
it's
it
works
all.
A
C
A
Thanks
to
Jeff
he's
the
unknown
avatar,
that's
sitting
on
the
bottom
of
our
screen
right
now
he
is
live-streaming
while
George
does
other
things
today,
but
that's
it.
Thank
you.
So
much
panelists
we'll
see
you
next
month,
I
think
at
the
7:30
a.m.
Pacific
time,
not
necessarily
Yuba
peers.
Like
all
right.
Thank
you.
Everybody
see
you
soon.
Thanks.