►
From YouTube: Intro to Kubernetes Sig-Architecture Subprojects - Davanum Srinivas, VMware & Jordan Liggitt, Google
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
Intro to Kubernetes Sig-Architecture Subprojects - Davanum Srinivas, VMware & Jordan Liggitt, Google
SIG Architecture maintains and evolves the design principles of Kubernetes, and provides a consistent body of expertise necessary to ensure architectural consistency over time. The SIG takes care of evolution of Conformance definitions, API definitions/conventions, Deprecation Policy, Design principles, etc. To support these activities the SIG participants work on multiple subprojects. They are as follows: * Architecture and API governance - is largely oriented towards sub-project maintainers. * Code organization - is oriented towards maintainers and distributions. * Conformance - is oriented towards distributions and community/ISV ecosystems solutions. * Production readiness - is oriented towards distributions, support organizations, and users. In this talk, we will walk through what each of the subprojects does, how they work, how each of them benefit and influence work in the kubernetes community, and how you can get involved.
https://sched.co/UajO
A
B
A
So
did
all
the
bots
attack
you,
so
we
have
plenty
of
stuff
going
on
just
submitting.
A
PR
is
one
of
the
things
that
you
know
we
do,
and
but
there
is
a
lot
of
processes
behind
the
scenes,
so
we'll
go
through
some
of
the
things
that
we
do
as
a
project
so
to
introduce
ourselves
and
I
go
by
Tim's.
That's
my
nickname.
My
full
name
is
down
Sreenivas
and
I
work
for
VMware.
My
handle
on
github
and
Twitter
is
Adams.
Do.
B
A
So,
let's
before
we
start,
let's
go
over
some
of
the
community
values
that
kind
of
drivers.
So
we
like
to
distribute
the
work
we
don't
want.
You
know
people
to
get
overloaded
and
stuff
like
that
right
so
and
we
value
community
or
over
a
specific
product
or
a
company,
and
we
try
to
automate
everything
that
we
do.
A
So
that's
part
of
the
reason
why
you
have
so
many
BOTS
come
come
by
your
way
when
you,
when
you
try
to
interact
with
us
and
we
always
we
try
to
listen
to
all
the
things
that
you
are
saying.
Sometimes
it's
hard.
Sometimes
maybe
you
feel
that
you
know
they
are
not
listening
to
us,
but
we
do
try
to
you
know
whether
it
is
on
Twitter
or
slack
or
on
issues
and
PRS.
A
We
do
try
to
pay
attention
it's,
but
there's
things
that
we
can
do
it's
things
that
we
can't
do,
but
this
context
involved-
and
there
is
history
involved
and
things
like
that.
But
overall
we
do
try
to
tweak
things
that
we
do
and
we
try
to
evolve
and
not
let
things
be
the
same
way
over
time
so
just
to
for
all
the
people
who
haven't
dealt
with
the
hierarchy
and
structure
that
we
have
at
Cuba
notice.
A
So
we
have
the
CNC
F
on
top
and
then
we
have
Cuba
notice
is
a
project
under
CNC
F,
so
in
in
Cuba
notice,
the
main
you
know
overlap
between
C
and
C,
F
and
Cuban.
Artists
is
the
steering
committee
and
under
the
steering
committee
we
have
all
the
special
interest
groups.
Anybody
know
anybody
not
know
what
a
special
interest
group
is.
A
So
everybody
knows
I
guess
so.
We
have
special
interest
group
for
various
areas
like
storage
or
node,
and
things
like
that
architecture
and
things
like
that
and
we
have
work
groups
jump
in
anytime.
We
have
work
groups
and
we
have
user
groups
as
well.
So
this
is,
as
of
a
month
ago,
Ike
I,
think
I,
don't
think.
We've
added
anything
since
then.
A
Have
a
set
of
design
principles
and
we,
but
you
know
some
of
the
things
is
like
we
don't
have
the
same
set
of
people
working
on
the
code
or
a
period
of
time,
so
we
try
to
write
down
what
we
can.
So
we
have
some
people
who
come
later
can
rely
on
some
written
material
to
see
what
happened.
Why
was
a
decision
taken
and
things
like
that?
So
we
try
to
write
down
API
conventions.
We
try
to
write
down
conformance
test
information.
A
You
know
the
architecture,
design,
principles
and
the
deprecation
policy,
so
somebody
is
somebody
coming
in
and
say:
oh,
this
CLI
flag
is
no
longer
useful.
When
can
I
pick
a
tit,
so
we
don't
want
to
restart
a
whole
another
discussion
when
we
get
a
new
new
request
like
that
from
somebody
saying.
Ok,
this
is
not
useful
anymore,
let's
to
get
rid
of
it,
so
we
don't
want
to
say
so.
We
have
written
down.
You
know
if
it's
a
CLI
flag.
How
do
we
deal
with
that?
If
it's
a
API
change?
A
How
do
we
deal
with
it?
So
that's
basically
what
the
cigar
does
cigars
tries
to
do
stuff,
which
is
across
all
the
SIG's,
and
we
try
to
maintain
some
consistency
and
try
to
make
sure
that
people
can.
You
know,
go
look
for
information
and
they
can
help
themselves
instead
of
having
to
ask
someone
or
go
to
a
meeting,
and
we
all
end
up
talking
about
the
same
thing
all
over
again
and
again
and
with
different
answers
in
at
different
times.
C
Okay,
so
if
you
look
at
that
project
diagram,
there's
a
lot
of
work
going
on
in
lots
of
little
boxes
and
they
have
their
view
of
the
world
whether
they're
focused
on
you
know,
containers
or
the
node
or
scheduling
or
Windows
or
security
or
whatever
it
is,
and
the
goal
of
SiC
architecture
is
to
take
the
things
that
we
want
to
be
consistent
across
those
both
just
in
terms
of
best
practices
like
we've
realized
after
years
and
years.
This
works
best.
C
Let's
not
have
to
relearn
the
same
lesson
over
and
over
and
also
in
terms
of
consistency
for
users.
You
know
people
using
communities,
don't
really
care
which
little
box
a
particular
thing
came
out
of.
They
want
to
use
the
whole
project
as
a
coherent
thing,
and
so
these
are
the
main
cross-cutting
processes
where
sega
architecture
tries
to
document
and
provide
information
and
tooling
and
just
a
place
for
all
of
those
individual
areas
to
learn
and
follow
the
best
practices,
and
so
conformance
will
go
over
these
in
more
detail.
C
But
the
conformance
testing
ensures
a
consistent
surface
so
that,
if
you
are
running
on
kubernetes
in
one
cloud
or
another
cloud
or
on-premise
or
wherever
it
is,
there's
a
certain
set
of
things,
you
can
assume
exist
and
function
a
specific
way.
The
API
review
process
again
is
documenting
conventions
and
things
that
make
sure
the
API
surface
as
coherent
as
we
can
make
it
and
gives
a
document
for
people
writing
api's
and
designing
api's
so
that
they
don't
have
to
have
one-on-one
consultation
sessions.
C
They
can
start
with
sort
of
these
foundational
principles,
design
document
and
management,
there's
a
repository
full
of
design
documents
in
various
stages
and
so
sort
of
the
process
around
that.
The
the
questions
that
you
need
to
answer
in
a
design
document,
that's
overseen
by
secure
architecture
and
then
finally,
Devon's
talked
about
the
the
deprecation
policy
skew
policies.
This
is
again
to
help
the
people
building
communities
understand.
You
know
what
am
I
allowed
to
do.
C
How
long
do
I
have
to
keep
these
two
things
working
together
over
what
span
of
time
and
then
also
from
the
perspective
of
people
deploying
kubernetes
clusters?
You
know
how
do
I
go
about
upgrading?
What
order
do
I
have
to
do
things
in
what
does
the
project
test
and
guarantee
and
then,
finally,
from
a
user's
perspective,
documenting
that
making
sure
that
everybody
understands
that
is
on
the
same
page.
C
Will
we
will
try
to
leave
some
time
at
the
end,
but
yeah
but
yeah
for
sheree
to
jump
in?
That's
fine
as
well
other
things
that
come
up
in
cig
architecture
we
have
patterns.
Sometimes
they
apply
really
clearly
in
all
those
various
areas.
Sometimes
new
things
come
up
right,
we're
solving
a
lot
of
problems,
and
sometimes
there
are
problems
we
really
haven't
thought
through
before
and
so
sick
architecture
is
a
place
to
come
and
discuss
those.
There
are
a
lot
of
people
with
a
lot
of
experience.
C
C
It
doesn't
happen
a
lot,
but
sometimes
the
people
leading
different.
Some
projects
disagree
about
what
the
right
thing
is.
It's
not
a
question
of
what
should
we
do?
It's
like
I,
definitely
know
we
should
do
a
and
I
definitely
know
we
should
do
B
and
so
again
those
tend
to
kind
of
bubble
up
and
get
broader
perspectives
and
say
garbage,
and
so
the
the
normal
way
that
we
start.
Those
discussions
is
with
the
mailing
list.
We
try
to
work
a
synchronously
as
much
as
we
can.
C
So
you
can
follow
along
all
right,
so
we're
gonna
jump
through
these
sub
projects.
I
think
we
already
talked
to
this.
So
I'll
talk
through
the
first
one.
So
diving
down
into
the
API
review
process,
there's
a
short
link
there
you
can
read
through
it.
They're
kind
of
two
categories
of
API
is
ones
that
are
built
into
kubernetes
and
then
ones
that
are
built
on
top
of
kubernetes,
using
custom
resources
or
other
extension
mechanisms.
C
But
over
the
past
couple
of
leases
we've
been
working
to
distribute
expertise
in
this
area
so
that
all
of
those
individual
areas
have
people
identified
as
being
familiar
with
these,
who
can
do
first
passes
on
designs
and
reviews,
and
so
we're
we're
working
to
spend
up
capacity
in
that
area
if
you're
working
in
an
area
that
doesn't
have
API
reviewers,
and
you
would
like
to
get
familiar
with
these
and
sort
of
be
able
to
provide
that
to
that
area.
That
would
be
great.
Come
talk
to
me
afterwards
and
I'll
point
you
in
the
right
direction.
B
A
Discriminators
is
a
single
repository
which
has
a
lot
of
things,
so
we
have
a
sub
project
called
code
organization
where
we
look
at
what
are
the
things
that
we
render
as
in
pull
stuff,
that
we
use
from
like
dhaka,
docker
or
Microsoft
HCM
or
go
for
cloud
all
those
things
are
vendor
dependencies,
so
we
have
a
lot
of
them,
especially
because
we
have
cloud
providers.
So
when
we
add
a
new
cloud
provider,
we
end
up
pulling
a
whole
bunch
of
additional
dependencies.
A
So
we've
accumulated
this
over
time,
so
the
code
organization
project
is
about
how
do
we
make
things
simpler,
easier
both
for
the
building
as
well
as
their
release
and
trying
to?
We
don't
want
really
stale
dependencies.
So
if
there
is
external
repository
that
we
are
rendering
in
and
if
the
Seabee
gets
fixed
there,
we
won't
even
know
about
it,
because
you
know
half
the
time
we
are
using
sha
instead
of
a
release,
so
we've
gone
through
this
process
of
okay.
Let's
look
deeply
into
a
vendor
dependencies.
What
is
in
there?
A
Do
we
really
need
it
here?
Are
there
alternatives?
Can
we
switch
to
something
else?
Can
we
switch
to
something
better?
Can
we
switch
to
a
specific
version?
So
when
a
new
version
comes
in,
we
can
do
a
difficulty
in
the
old
and
the
new,
so
we
can
pull
in
the
new
version
and
sometimes
the
transitive
dependencies
cause
problems
like
I'll
tell
you
the
example
from
two
days
ago,
the
Azul
folks
wanted
to
update
something
and
what
ended
up
happening
was
the
continuity
version
that
they
were
pulling
in
through
their
dependency
was
not
matching.
A
The
container
the
dependency
that
was
pulling
in
through
see
advisor
so
see
advisor
needs
continuity
and
AHS.
Who
needs
continuity
and
those
were
not
matching.
So
then
we
have
to
jump
in
and
say:
okay,
this
is
what
you
got
to
do.
You
got
to
first
take
the
continuity,
which
is
the
newer
Shaw,
newer
version,
add
to
see
advisor
and
then
update
both
what
you
need
and
what
you
know
see
advisor
needs.
So
you
end
up
fixing
three
dependencies
instead
of
just
the
thing
that
the
assault
team
wanted.
A
So
that's
another
example
of
code
organization
stuff-
and
this
is
like
ongoing
basis
and
the
other
thing
we
do
is
like
we.
We
have
patterns
about
code
itself
right
in
terms
of
red,
so
how
to
put
this
so
we
need
to
get
rid
of
code
from
KK.
So
one
mechanism
that
we
use
is
called
the
staging
mechanism
where
we
move
some
of
the
code
into
a
saging
directory
and
that
staging
directory
gets
published
in
two
separate
repositories,
so
it
can
be
consumed
easily
by
anybody.
A
A
So
the
other
example
is
we
move
code
from
KK
into
an
external
repository,
for
one
example
would
be
Cuban
artists,
utils,
so
Cuban,
artists,
utils,
is
a
repository
where
we
have
some
utility
function,
but
we
think
that
those
utility
functions
are
usable
outside
of
the
Cuban
artists
ecosystem.
So
we
have
a
process
for
doing
so.
When
somebody
says
okay
I
need
to
extract
this
code,
then
we
go
through
this
mechanism
of
okay.
Should
it
go
under
staging?
Should
it
go
into
a
separate
repository,
you
know
what
do
we
do?
A
Do
we
just
put
it
in
another
repository
maintained
by
another
organization,
and
then
we
just
went
rent.
So
we
go
through
this
mechanism
of
okay.
What
is
the
best
way
to
do
this,
so
it
we
can
take
care
of
this
code
in
the
longer
term.
So
that's
basically
what
we
do
in
code
organization
and
there's
a
lot
more
people
here
in
this
room
who
know
more
about
conformance
testing
than
me.
John
is
here.
You
know.
Brad
has
been
involved
for
a
long
time
as
as
well.
So
the
effort
here
is
you
as
a
consumer.
A
You
go
to
one
of
the
cloud
providers
and
say:
I
want
to
use
you
the
kubernetes
that
you're
providing
so
and
then
you
go.
Take
your
AML's
and
you
run
the
stuff,
and
then
you
see
there
are
maybe
subtle
changes
here
and
there
and
like
we
want
to
reduce
that
kind
of
thing
where
you
struggle
moving
stuff
from
one
cloud
word:
another
cloud
Rider.
So
that's
where
the
conformance
stuff
comes
in.
We
try
to
make
sure
that
there
is.
There
is
guarantees
that
you
can
rely
on
when
you're
writing
your
applications.
A
So
you
don't
have
to
run
into
trouble.
You
know
getting
stuff
from
one
place
to
another
place,
so
that
would
be
one
of
the
main
things
about
the
conformance
project,
and
this
would
be
here.
We
have
a
collaboration
with
CN
CF,
because
the
the
way
this
works
is
first,
we
write
tests
and
then
we
evaluate
whether
the
tests
are.
You
know
valid
conformance
tests
and
we
have
a
set
of
criteria
for
something
to
be
a
conformance
test,
and
then
we
go
through
that
process
of
saying.
Yes,
this
is
a
good
conformance
test.
A
We
should
promote
it.
Then
we
add
a
tag
so
and
then
what
ends
up
happening
is
it
gets
run
as
part
of
our
CI
job
and
it
runs
against
multiple
cloud
providers
and
then
we
kind
of
like
okay,
this
this
seems
to
stick
so
we're
good
and
then
we
make
it
release
and
then
the
end-to-end
tests
end
up
going
to
tooth,
like
so
no
boy
and
then
gets
used
by
everybody
in
the
community,
so
that
if
you
run
solo
boy,
you
are
essentially
running
the
end-to-end
tests,
which
are
in
our
repository.
A
A
C
So
this
is
a
tool,
that's
designed
to
help
us
see
where
we
have
coverage
gaps.
So
it
takes
the
output
of
running
conformance
tests,
running
an
e
to
e
test
and
basically
identifies
all
the
endpoints.
We
have
all
the
operations
on
those
endpoints
and
then
tells
us
how
we're
doing
like
in
this
case,
this
particular
API
group
is
doing
really
well.
C
But
if
you
kind
of
look
at
the
faded
areas,
there
are
others
that
aren't
quite
so
covered,
and
so
this
is
what
we're
working
to
close
these
gaps
so
that
we
know
that
a
conformant
cluster
actually
supports
all
of
these
operations
and
those
do.
What
do
you
think
they're
supposed
to
do
and
the
changes
make
things
happen?
The
way
you
think
they
should.
So,
if
you're
interested
in
helping
there's
a
lot
of
work
to
do
here,
it's
pretty
straightforward
and
well-documented
like
what
should
be
done.
There's
just
a
lot
to
do
right.
The.
A
In
text
right
and
then
start
from
text
to
say,
somebody,
who's
knowledgeable
in
the
area
will
write
a
text
file
which
says
this
is
what
we
expect
from
the
text
from
the
test,
and
then
we
we
are
trying
to
see
if
we
can
have
some
code
generator,
which
was
turn
around
and
turn
that
into
an
actual
test.
This
is
extremely
preliminary
at
this
point,
but
the
the
thought
here
is,
we
would
ping
the
sig
leads
and
technical
leads
of
various
six
to
actually
contribute
to
this
description.
A
B
C
That
just
started
up
we're
calling
production
readiness,
this
kind
of
came
out
of
experience
or
feedback
from
cluster
operators
that
some
of
the
features
we
were
releasing
were
difficult
to
run
for
various
reasons.
Sometimes
it
was
a
documentation
issue.
Sometimes
it
was
the
inability
to
monitor
at
scale
via
metrics
and
sort
of
programmatic
observation.
C
But
the
goal
of
this
sub
project
is
really
to
answer
the
question:
how
will
people
run
this
in
production
and
start
to
make
that
part
of
the
design
process
so
that
the
people
writing
designs,
who
are
very
focused
and
know
their
area
really
well
understand
the
types
of
questions
that
the
people
who
are
gonna
be
using
their
features
are
asking
and
what
they
need
to
make
really
clear
and
make
sure
is
available.
Metrics
monitoring,
scale
testing,
so
testing
documentation,
like
all
of
these
aspects,
need
to
get
baked
into
our
design
process.
C
A
So
this
one
happens
during
the
kept
process
itself,
so
we
are
trying
to
front-load
it
rather
than
go
and
talk
to
people
after
they
have
written
the
code.
So
that's
you
know
that's
important
as
well,
because
some
when
people
are
writing
the
code,
the
dome,
sometimes
they
don't
know
how
the
end
users
are
going
to
be
using
it
as
well.
A
Okay.
So
there
are
three
other
things
that
we
are
trying
to
do.
This
is
absolutely
nascent
the
first
one
that
we
are
trying
to
do
is
core.
That
is
what
we
are
calling
technical
debt
and
what
happens
is
sometimes
we
take
shortcuts
and
people
have
taken
shortcuts
over
the
past
so
and
there
are
to
lose
and
fix.
Me
is
in
the
code.
There
are
issues
and
ers.
A
So
this
is
like
a
discovery
process
phase
right
now,
going
back
in
to
the
PRS
and
issues
and
caps
and
in
hand
enhancements
and
going
through
the
code
to
figure
out
what
is
it
that
we
have
missed
and
based
on
so
we
are
trying
trying
to
collect
the
data.
We
also
are
thinking
about
going
at
interviewing
the
people
that,
like
Joe
or
you
know,
other
people
who
have
been
in
the
project
Tim.
How
can
have
been
in
the
project
for
a
long
time
to
say?
A
Why
did
you
do
this?
How
can
we
fix
this?
What
do
we
have
to
do
so?
This
would
be
like
a
really
good
way
of
going
back
in
history
and
trying
to
figure
out
how
things
were
done.
Why
what
is
the?
Maybe
if
you
have
learnt
things
or
along
the
way,
where
you
know
the
older
decisions,
no
law
are
no
longer
valid.
So
maybe
it's
time
for
us
to
you
know,
move
on
and
do
something
else.
So
this
is
basically
the
technical
debt
team.
A
There's
three
four
of
us:
we
in
the
contribute
summit
yesterday
was
it
yesterday.
Yes,
yesterday
three
more
people
said
they
were
interested,
so
this
is
like
a
smaller
group
and
my
Onkyo
is
leading
the
group.
So
if
you
are
interested
in
this
kind
of
research
work
where
you
know
you
get
to
get
to
talk
to
a
lot
of
knowledgeable
people
and
try
to
understand
what
what
has
been
happening
in
the
project,
this
will
be
like
a
good
fit
for
you,
too,
come
in
and
help
us
out.
You'll.
A
You
know
why
do
we
use
conditions?
Do
we
should
we
use
conditions
like
you
know,
there's
so
much
that
you
can
learn
from
from
doing
this
research?
It's
it's
it's
an
amazing
opportunity
for
sure
so
and
Mike
is
doing
this,
so
the
other
one
we
are
doing
is
the
book
club.
We
are
starting
a
book
club
where
we
are
getting
people
to
read
the
caps
write.
A
What
has
been
happening
is
you
know,
people
who
are
interested
will
gather
on
a
cap
and
say
yeah
me
and
then
they
move
on,
but
then
what's
happening
is
you
know
they?
We
need
to
get
more
people
involved
in
the
care
process
so
that
we
are
doing
a
again.
It
goes
back
to
the
front-loading
issue,
where
we
make
sure
that
things
are
done
right.
The
first
time
around
so
tim
Hawken
is
running
this,
so
you
know
and
there's
few
other
people
who
DVD
Ed's
signed
up
for
it.
A
So
you
know,
if
you're
interested
in
understanding
what
we
are
doing
and
what
we
are
going
to
do
next
in
the
next
next
upcoming
releases.
This
is
the
best
way
to
get
involved.
This
gives
you
a
heads
up
on
the
features
that
are
going
to
come
in
gives
you
a
heads
up
on.
You
know
what
are
the
trade-offs
if
something
gets
deprecated
something
gets
changed.
You
will
get
a
really
early
view
on
this
and
we
would
love
to
especially
operators
to
get
involved
here.
Part.
C
Of
the
goal
of
that
is
to
make
sure
that
things
don't
slip
through
the
cracks.
So
these
the
the
people
who
are
working
on
reading
through
these
the
goal
is
for
them
to
read
it
discuss
it
think
about
it
and
then
kind
of
bring
back
a
summary
or
a
report
back
to
the
main
city
architecture
meeting.
So
if
you
are
going
to
those
or
listening
to
the
recordings
of
those,
you
will
get
sort
of
the
Distilled.
C
Here's
the
point
of
this
and
here's
the
good
things
and
the
bad
things
and
the
questions,
and
so
the
goal
is
to
fold
that
back
into
the
main
meeting
and
kind
of
make
good
use
of
that
time.
So
we're
not
all
reading
that
during
the
meeting
but
have
already
read
it,
bring
back
distill
that
right,
I,
typically.
A
C
A
We
always
could
use
help
with
issues
and
PR
triage,
and
this
is
extremely
low
volume.
It
takes
about
10-15
minutes
every
week.
This
is
a
good
way
to
figure
out
somebody
tagged
sick
architecture.
Why
did
they
pack
cigar
collection?
Does
it
really
need
to
be
tagged
with
sick
architecture?
Can
signal
and
sick?
So
rich
can
talk
between
the
two
of
them
and
do
we
really
missing
the
sick
architecture
so
and
then
you
push
things
around
to
the
correct
bucket
into
the
correct
sig.
That's
basically
what
we
do
here
in
the
issue:
PR
triage.
A
The
other
thing
that
happens
here
is
to
make
sure
that
if
there
are
really
burning
issues
then
we
add
it
to
the
meeting
agenda.
So
that's
the
additional
thing
that
we'll
end
up
doing
in
this.
Currently
we
don't
have
anybody
doing
this.
We
just
do
it
on
an
ad-hoc
basis,
but
I
would.
Rather,
if
you
know,
if
we
do
it
on
a
weekly
basis
or
every
other
week,
for
you
know
10
minutes.
So
it
doesn't
take
that
long.
A
C
The
first
response
to
request
to
add
things
to
the
project
is
going
to
be:
try
it
out
as
an
extension,
build
it
on
top,
prove
it
out
and
do
a
prototype
explore
the
solution
you're
looking
at
on
top,
rather
than
starting
everything,
sort
of
tree
and
pushing
it
out
to
everybody
consuming
kubernetes,
and
the
hope
is
that
that
will
sort
of
slim
down
the
velocity
and
rate
of
change
in
the
core
of
kubernetes.
And
let
us
work
on
paying
down
some
of
this
technical
debt.
Do
some
cleanup
work?
C
Do
some
stabilization
and
sort
of
enable
people
to
still
get
features
that
they
want
without
burdening
them
at
burdening
the
whole
community
on
sort
of
mesh
features
by
building
it
in
directly
into
kubernetes,
and
with
all
that,
extra
time
that
we
get?
We
are
working
on
building
out
conformance
stuff
working
on
the
reliability,
the
production,
readiness
reviews
making
our
designs
and
our
existing
features
higher
quality
all
right.
So
if
all
this
sounds
fascinating
to
you,
how
can
you
participate
the
link
there
lists
about
eight
different
ways
you
can
get
in
touch.
There's
slack!
C
There's
mailing
lists,
there's
meetings,
it
breaks
out
with
some
projects
that
we
talked
about
some
of
those
have
standing
meetings,
some
of
those
have
docs
or
github
project
boards
that
you
can
look
at
and
kind
of
see.
What's
going
on
and
find
individual
people
who
are
owning
things
to
reach
out
to
we're
very
friendly.
We
have
lots
of
work
to
do,
and
so,
if
you
have
questions
or
would
like
to
help,
we
are
happy
to
hear
from
you
yeah.
B
A
Don't
really
need
to
be
a
like
a
Big,
Shot
hotshot,
you
know
quarter
or
anything
like
that.
You
know
you
have
some
time
come
hang
out
with
us,
you
listen
to
what
we
are
talking.
You
get
some
kind
of
the
history
and
the
context
and
we'll
always
be
happy
to
talk
to
you
and
give
you.
You
know
additional
information
on
what
we
know
already
and
will
point
you
to
existing
issues,
existing
caps,
existing
PRS
and
give
we'll
give
you
the
history
in
the
context
of
why
things
were
done,
and
we
are.