►
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
Deep Dive: Kubernetes (PM) SIG - Ihor Dvoretskyi, CNCF & Stephen Augustus, VMware
Kubernetes is one of the most high-velocity open source projects in the world, and one of the most unique features of this community project - that it has its own PM team and PM process. SIG-PM, originally established as a Product Management Group, today covers multiple aspects of Product, Program and Project Management of Kubernetes. In this session, the SIG-PM co-chairs will run a deep dive session on the SIG-PM community-wide responsibilities, day-to-day responsibilities, together with working on the real-world cases.
https://sched.co/MPjc
A
A
A
little
bit
more
about
us
who
decided
to
put
up
pretty
pictures,
oh
wait
for
it,
so
to
go
a
little
deeper,
I'm,
a
senior
cloud
native
architect
at
VMware.
So
that
means
I
do
pre
and
post-sales
delivery
for
customers
as
well,
as
do
a
lot
of
community
focused
work.
So,
in
addition
to
that
I'm,
the
sig
chair
for
sig
p.m.
for
sake,
release
and
sig
Asher
I'm,
also
on
the
cube
Con,
Program,
Committee
and.
B
I'm
a
program
manager
Microsoft
on
upstream
projects,
so
helping
with
upstream
endeavors
like
kubernetes,
is
one
of
the
things
that
I
do
and
I
represent
in
kubernetes
singing
sig
p.m.
and
I'm
also
a
release
team
shadow
for
1:15.
So
if
you're
interested
in
what's
coming
in
1:15,
feel
free
to
ask
me
afterwards,
I'm
also
a
CNC
F
ambassador.
So
you
might
see
me
around
the
place.
Doing
Ambassador
e
things.
A
So
this
is
gonna,
be
like
there's
some
rehash
of
what
we
talked
about
yesterday
and
then
we
wanted
to
expand
on
one
of
the
sub
projects
in
particular.
So
to
start
like
what
is
sig
PM,
who
is,
we
are
Signum,
so
lucky
is
pretty
intently
focused
on
sig
p.m.
but
the
the
top-level
chairs
for
sink
cam
are
Kayla
miles,
who's
that
pivotal
you've
heard
of
ur
s
key
who's
at
the
CN
CF
as
a
developer,
ambassador,
Jay,
singer
Dumars,
who
is
a
program
manager
at
Google
and
myself?
You
already
know
me
now
right.
B
I
think
you
know,
I've
been
in
the
kubernetes
community
for
a
while,
and
one
of
the
things
that
doesn't
transcend
so
well
into
open
source
is
kind
of
the
product
project
the
p-star.
So
this
is
endeavour
under
kubernetes
to
try
and
bring
all
the
work
that
we
typically
do
inside
corporate
entities
out
into
open
source
so
that
we
can
have
great
experiences
around
building
products
and
projects
and
growing
the
community
around
that.
So
that's
why
I'm
really
excited
to
come.
B
A
You
know
I
think
it's
really
curious
because,
like
this
is
something
that
you
know,
I,
don't
I,
don't
think
you
know
looking
at
a
few
open
source
projects,
I,
don't
think
this
exists
right
so
trying
to
bring
I
think
we're
trying
to-
and
you
know
we're
not
reinventing
a
wheel
that
exists
in
commercial,
but
we're
trying
to
invent
a
wheel
period
and
hopefully
create
a.
You
know,
create
a
set
of
process
and
procedure
that
can
be
used
for
for
hopefully
different
open-source
projects
as
well
and.
B
B
A
So
yesterday
we
talked
about
the
the
different
sub
projects
that
we're
spinning
up
in
cig
p.m.
so
we're
just
going
to
quickly
go
over
that
stuff
again.
I'm,
not
gonna
dive
into
any
of
the
projects
in
specific
outside
of
caps.
I
think
caps
are
are
like,
like
I
mentioned,
caps
are
in
the
critical
path
for
everything
that's
being
introduced
into
kubernetes,
so
I
think
it's
really
important
that
everyone
have
an
understanding
of
what
caps
do
day
to
day.
A
B
Has
anybody
ever
raised
two
kept
in
this
room
heard
of
a
camp
okay?
What's
it
kept
it's
like
a
pet,
but
for
kubernetes
pretty
pretty
pretty
accurate
right.
So,
if
you're
trying
to
get
an
enhancement,
some
may
call
it
a
feature
into
kubernetes.
This
is
the
process
that
we
ask
the
community
to
go
through
and
it
serves
many
different
arms
yeah.
A
Yeah,
so
you
know
the
cap
is
meant
for
multiple
personas,
the
end
users
and
developers
the
whole
idea
with
kept.
You
know,
they're,
you
know
they're
inspired
by
peps
they're
inspired
by
rust,
RFC's.
What
I
would
really
like
out
of
the
process
is
that
anyone
who
reads
a
cap
can
at
a
glance
understand
what
an
enhancement
is
right,
and
you
know
so
for
the
from
the
perspective
of
the
media
of
developers.
Who
may
not
be?
Can
you
know
familiar
with
that
particular
piece
of
code?
A
This
is
supposed
to
give
them
an
opportunity
to
just
kind
of
have
a
one-sheet
understanding
of
what
that
that
code
is
going
to
be
introducing
or
that
new
process
is
going
to
be
introducing
to
the
project.
So
you
know,
hopefully
we
can
use
this
to
eventually
elicit
product
themes
right,
so
you
know
we
have.
We
essentially
have
a
set
of
different
product
teams
across
across
kubernetes,
and
we
happen
to
call
them
SIG's,
but
you
know
they're,
you
know
if
we
want
to.
A
If
we
want
to
draw
those
parallels
between
enterprise
and
will
not
enterprise
but
commercial
entities
and
and
and
open-source
you
know
the
way
we
organize,
we
have
the
we
have
a
set
of
committees
and
committees.
Are
you
know
our
top
level
committee?
Is
this
enduring
steering
committee
the
steering
committee
delegates
authority
from
the
committee
itself
to
things
which
are
special
interest
groups
right?
There
are
also
working
groups
and
sub
projects.
Sub
projects
live
inside
of
they
live
inside
of
SIG's
sub
projects
are
the
the
means
of
organization
that
actually
owns
code
right.
A
So
any
piece
of
code
that
you've
touched
in
kubernetes
or
you've
seen
in
kubernetes,
probably
belongs
to
some
sub
project
within
these
31:32
SIG's
that
exist
right
now,
right
and
then
finally,
there
are
working
groups
and
working
groups
are
cross-cutting
efforts
that
are
basically
multiples.
Big
efforts
right
and
you
know
the
whole
idea
there
is
that
there's
supposed
to
be
a
finite
amount
of
time
that
those
working
groups
exist
for
right
define
what
the
purpose
of
it
is
right.
So,
like
the
the
working
group,
the
Kate's
in
for
a
team
right
now
right.
A
The
whole
idea
behind
the
Kate's
in
for
Team
is
that
we
want
to
spin
up
a
set
of
Engineers
and
develop
a
set
of
processes
that
we
can
essentially
migrate.
The
migrate,
the
kubernetes
build
infrastructure
that
lives
in
Google
right
now
over
to
CN
CF
based
infrastructure.
So
there
are
a
bunch
of
different
ways
that
we
organize
the
primary
one.
That
we
focus
on
day
to
day
is
zigs
and
zigs
are
saying,
feel
like
product
teams
to
me
right.
B
A
Real
quick,
the
way
a
kept
is
designed
we,
you
know,
we
talked
about
caps
yesterday
and
I
wanted
to
do
a
more
of
a
deeper
dive
into
what
a
cap
is.
You
know
how
to
spot
a
cap
how
to
spot
a
good
cap.
How
does
one
bad
cap
you
know
so
primarily
what
we
wanted
to
do
is
create
a
document
that
would
be
able
that
would
lend
itself
to
automation
right.
A
So
the
first
thing
that
we
need
to
do
there
is
is
create
some
sort
of
machine,
readable
piece
of
that
document
right,
so
that's
the
metadata
section,
and
then
you
know
going
into
going
a
little
deeper
into
the
cap.
We've
got
the
motivation
summary
and
these
artifacts
that
are
produced
or
whether
they're
their
pictures
or
diagrams
or
something
that
are
attached
to
the
cap.
It's
kind
of
you
know
the
artifacts
that
you
would
need
to
tie
this
story
together.
Alright,
so
the
motivation
and
summary
kind
of
you
know
kind
of
obvious
it's.
A
B
B
So
when
we
think
about
personas
one
of
the
teams
is
the
release
team
who
are
trying
to
understand
and
say
what
is
in
release
1.15
and
their
social
record
is
actually
all
the
caps
we're
going
to
go
through
the
process
in
the
scope
of
the
release
team
they're.
Looking
at
all
the
titles
they're
looking
for
summaries
they're
looking
at.
B
That
when
they
cut
a
release
in
kubernetes,
they
can
actually
say
this
is
what
was
delivered
because
the
person
who
is
writing
the
feature
is
not
the
person
typically
who's,
part
of
the
release
team.
So
it's
it's
supposed
to
be
that
human
readable
that
effect
as
to
what
and
why,
but
not
the
code
itself.
So.
A
Occasionally,
you
will
see
code
in
caps,
but
Lucky's
right
that
it
is
meant
to
be
as
human
readable
as
possible,
so
the
the
mock
for
a
feature
you
might
see
right.
The
I
would
like
to
do.
Foo
and
food
will
speak
to
bar,
and
you
know,
and
and
then
Bart
eventually
speaks
the
Bad's
like
just
getting
the
general
idea
of
what
the
code
flow
looks
like
you
may
see
that,
but
but
often
it
will
be
strictly
the
human
readable
aspects
of
it.
Yeah.
B
A
C
A
A
C
A
Right
hold
on
so
this
is
the
first
part
of
a
this
is
a
metadata
field
that
we
were
talking
about,
and
this
is
the
first
part
of
the
cab.
It's
kind
of
laying
out
what
the
title
of
the
cab
is.
The
authors
of
the
cap,
the
owning
SIG's
who's
participating
in
that
the
reviewers
approvers
when
it
was
created
when
it
was
last
updated,
so
on
and
so
forth
right.
So
this
you
can
a
machine
can
read
this.
A
So
we
mentioned
the
the
status
here
and
and
I
like
to
I
like
to
hammer
in
the
the
note
that
these
statuses
are
important,
because
these
statuses
give
us
a
signal
behind
which
we
understand
the
level
of
work
that
needs
to
be
done
on
that
cap,
for
it
to
be
accepted
right.
So
a
provisional
cap
is
hey.
I
have
a
really
great
idea.
Well,
I
think
it's
a
great
idea.
A
Can
I
write
a
little
bit
about
this
and
have
the
cig
review
it,
and
maybe,
if
that
makes
sense,
I
can
do
a
prototype
on
this
idea
and
move
it
forward
right,
and
at
that
point
the
cig
is
supposed
to
say:
hey,
we've,
okay,
this
motivation
looks
good.
Some
of
these
goals
look
good.
We
should
make
some
of
these
non
goals.
The
implementations
may
be
a
little
off
or
maybe
haven't
written
the
implementation
or
don't
have
a
test.
Planner,
that's
okay,
right
as
it
moves
into
the
implementable
state.
A
The
bar
for
this
gets
a
lot
higher
right.
The
the
implementable
state
is
kind
of
the
bar
at
which
the
release
team
says
it's
either
going
in
the
release
or
it's
not
right.
If
it's
going
in
the
release
and
needs
to
have
some
some
sense
of
implementation
like
how
we're
actually
going
to
do
the
implementation,
what
the
non
goals
of
that
feature
are
what
the
test
plan
is
there
and
we've
actually
like
updated.
The
cap
template
recently
to
include
a
release
team
checklist
right.
B
A
B
I
think
the
good
thing
is
in
a
title
without
even
a
summary
or
abstract.
You
can
actually
say
that
what
this
thing
is
going
to
do
so,
that's
incredibly
clear
for
somebody
like
me
or
somebody
on
the
release
team
and
come
and
say:
okay,
that's
a
feature
that
was
shipping.
That
can
be
a
top-level
item
that
ends
up
in
the
blog.
We
were
not
a
a
nice
blog
about
it,
and
then
you
know
the
community
can
use
it.
So
not
having
this
process
in
place
means
we
don't
have
any
way
to
track.
B
A
So
moving
moving
forward,
we,
you
know
the
way
that
we
try
to
tie
caps
together
is
including
a
an
enhancement
issue
right,
so
we're
kind
of
in
this
split
state
where
we
are
using
enhancement,
issues
and
I'm.
Sorry,
if
the
font
is
a
little
small,
but
these
are
kind
of
just
like
snapshots
from
the
repo.
So
this
is
when
you
open
an
enhancement
issue
you're,
given
an
issue
template
and
the
issue
template
it's
like
hey
describe
your
cap.
Tell
me
a
little
discretion.
Hance
minh
tell
me
a
little
bit
about
how
it
works.
A
You'll
see
a
link
to
that
proposal
as
well
as
like
who
I
need
to
contact
right
so
because
this
is
the
so
we
have
a
directory
of
caps
right
and
we
have
multiple
sub
directories
per
cig
of
caps.
So
this
is
an
easier
ingress
point
for
the
release
team.
To
just
add
a
glance
see
what's
going
on
who
I
need
to
contact
for
more
details,
and
if
you
were
to,
if
you
were
to
look
through
one
of
these
issues,
you
just
see
multiple
pings
from
the
release
team.
Like
hey,
are
your
Doc's
ready,
hey
this?
A
It's
code
freeze
in
a
week
please
make
sure
that
blah
blah
blah
is
done,
so
this
is
kind
of
like
our.
This
has
been
our
steel
thread
behind
how
the
enhancements
built-
and
we
want
to
shift
away
from
that.
This
is
this-
is
one
of
my
annoying
pings
that
I
think
I
think
this
is
the
release.
I
figured
out
how
to
automate
that
so
so
this
is
like
the
previous
template
I'm
just
giving
you
a
rundown
yeah.
This
is
112.
Giving
you
a
rundown
like
hey,
do
be
expect
anything
to
happen
with
this.
A
This
feature
this
time
around
and
if
so,
these
are
all
the
things
that
I
need.
As
you
can
see
that
there
there
is
a
set
of
labels
attached
to
these
right.
The
kind
feature,
sig
storage
stage
beta
and
tracked
yes
right,
so
the
release
team
uses
that
tracked.
Yes
as
an
indicator
that
this
is
something
that's
going
into.
The
release
and
the
rest
of
them
are
common
indicators
that
you'll
see
across
kubernetes
repos.
A
B
Can
also
see
on
the
right-hand
side
in
the
milestone,
because
it
is
tracked
right
here
you
can
actually
see
this
is
judo
land
and
115,
and
if
you
can
see
this
over
here,
they
also
have
identified
that
the
beta
released
target
is
115.
So
if
you
were
to
go
into
the
enhancement,
issues,
repo
and
click
on
the
115
milestone
today,
you
would
see
all
the
release
of
the
enhancements
that
are
proposed
for
the
115
release.
So.
A
Alright,
so,
first,
to
give
you
an
example
of
what
the
not
an
example
but
the
canonical
template
for
caps
right-
and
you
know
this
template
is
kind
of
a
cross
between
a
template
and
instructions
right.
We
figured
it's
easier
to
have
the
documentation
in
one
place
instead
of
jumping
between
two
markdown
files,
because
everyone
loves
reading
markdown.
A
A
You
have
some
sort
of
reference
point
of
who
is
supposed
to
actually
own
this
right
and
I
think
that
this
part
is
really
important,
because,
especially
for
newer
contributors
right
starting
to
work
on
enhancements
without
a
plan
is
exactly
and
without
clearer
sig
ownership
is
exactly
how
they
get
hung
up
right
so
being
able
to
understand
who
owns
it
or
who
should
own
it
or
being
able
to
ask
the
right
questions
to
figure.
That
out
is
is
one
of
the
most
important
first
steps.
Yeah.
B
Especially
because
people
come
and
go
in
the
community,
but
the
the
seek
is
the
entity
that
should
remain,
and
obviously
as
features
come
in
that
seek
maintenance
responsibility
over
the
lifetime
of
that
feature,
as
it
goes
into
alpha,
beta,
stable
or
even
if
it's
blocked
out.
If
it
only
goes
into
alpha,
they
get
to
make
the
decision
to
pull
it
back
out.
If
it's
not
getting
any
momentum
as
well.
A
Yet
there
are
several
open
PRS
for
caps
that
have
been
open
since
January
December
November
for
provisional
caps
that
are
not
merged
yet
because
there's
a
there's
kind
of
like
a
bite
shedding
process
or
like
a
well.
If
you
could
do
this
or
well,
if
this
API
did
blah
it's
like
hold
on,
is
it
a
good
idea
or
not
right?
A
Let's
get
that
merged
in
and
then
let's
talk
about
it,
I
think
you
know
it's
easier
to
have
that
discussion
once
the
idea
is
bought
forth
in
a
sig
meeting
or
in
a
design
document
and
then
bring
that
into
the
cap
right,
so
so
for
everyone,
who's,
gonna,
listen
to
this
recording
later
merge
early
iterate.
Often,
please
please,
so
they
so
the
cap
has
a
pretty
table
of
contents
as
you
do
this
release,
sign-off
checklist.
That
I
was
talking
about
right.
So
do
I
have
an
enhancement
in
the
release.
A
Milestone
have
I,
create
an
enhancement
issue
right,
have
kept
approvers
set
the
status
to
implementable
right.
So
this
is
like
okay,
the
bar
is
higher.
Have
we
have
we
iterated
over
the
design
details?
Have
we
done
a
test
plan?
Do
we
understand
what
the
graduation
criteria
for
this
enhancement
is?
Have
we
made
sure
that
we've
committed
to
history
what
the
implementation
steps
have
been
right?
Do
we
have
user-facing
documentation
right,
because
this
isn't
useful
unless
users
can
actually
use
it
right?
A
So
as
an
example,
we
can,
we
can
click
through
the
repo
hoping
Wi-Fi,
it's
all
happy,
so
you
can
see,
there's
two
files,
the
owners
and
the
owners
alias
file
all
right.
So
this
repo
in
particular,
because
it's
under
cig
p.m.
you'll,
see
approvers,
are
set
as
pm
maintained,
Urza
p.m.
leads,
and
then
the
reviewers
are
like
feature
maintained
errs.
A
There
are
a
bunch
of
different
historical
reasons
why
there
are
so
many
aliases,
but
the
process
owners,
the
process,
approvers
and
sig
release
leads,
are
allowed
to
look
at
this
stuff,
and
then
these
labels
here
mean
that
anything,
that's
labeled
as
anything
that
comes
into
this
repo
as
a
code
change
will
get
automatically
labeled
as
sig
p.m.
which
means
now
it's
searchable
across
the
kubernetes
repos
right
and
then
you
know
within
the
owners
aliases,
because
owners
by
itself
is
not
super
useful,
but
the
owners
aliases
will
give
you
a
rundown
of
these.
A
Are
the
API
machinery
leads?
These
are
the
API,
the
the
sake
app
leads
so
on
and
so
forth.
These
people
are
the
people
who
are
ultimately
going
to
approve
things
that
are
landing
in
the
in
this
repo
right
and
then
you
know
we
have
custom
content
down
here,
which
defines
the
p.m.
maintained,
errs
and
so
on
and
so
forth,
and
you
know
you
can
see
that,
let
you
know
I
are
on
this
list
and
it's
essentially
SiC
p.m.
plus
sig
release.
Looking
at
this
list
and
sig
architecture
forget
about
them,.
A
But
going
back
to
you
going
back
to
the
template,
so
some
of
these
sections
that
we
talked
about
right
and
and
really
it
is
it
is
incredibly
human,
readable
and
I.
Think
it's
I
think
you
know
writing
a
cap
should
be
easy.
It
should
be
painless.
You
know
there
has
been
some
friction
before,
especially
in
the
you
know,
the
114
release
cycle.
We
introduced
caps
as
a
requirement
for
the
release
cycle,
so
we
said
okay,
well,
you
know
things
are
just
kind
of
flying
in.
We
need
to
make
sure
that
there's
some
gate
right.
A
B
Absolutely
girls
and
non
goals
I
feel,
like
you
know,
we
get
in
the
summary
in
the
motivation.
That's
the
first
hurdle
and
you
will
hashing
out
the
goals
and
non
goals
them,
and
that's
really
just
being
crystal
clear
on
what
the
purpose
of
this
is
and
what
the
purpose
of
it
isn't
is
not
so,
but
you
know,
we
also
call
that
things
that
are
optional,
I,
think
from
here
on
down
there
optional
for
as
marked
by
but.
A
You
can
see
you
know,
we
start
to
ask
some
harder
questions
right,
something.
What
are
the
constraints
behind
you
know
doing
certain
implementations
right
is
it?
Is
it
a
human
bandwidth
constraint
and
going
back
to
the
the
owners
files
right?
The
top-level
approvers
who
are
commonly
sink
chairs,
sink
chairs
and
sink
technical
leads
everything
flows
through
their
their
queue
unless
they
have
help
right.
So
it's
very
important
to
understand.
Like
yes,
we
have
human
constraints,
we
may
have
infrastructure
constraints
right.
A
We
may
not
be
able
to
build
certain
things
like
recreating
the
release
process,
because
we
don't
have
revenue
for
it
right
or
you
know,
or
it
could
be.
We
can't
implement
this
API,
because
this
is
you
know
like
this
contradicts
this
other
API
that
you
never
knew
about,
but
we
can't
deprecated
yet
because
we
need
our
deprecation
cycles
at
least
two
cycles
right,
yeah.
C
A
They're,
a
bunch
of
you
know,
they're
a
bunch
of
like
idiosyncrasies
to
the
process
that
you
have
to
be
aware
of,
but
starting
to
list
this
stuff
for
a
reviewer
gives
them
the
context
to
start
doing
the
research
for
you
right
and
then
you
know.
Finally,
the
test
plan
graduation
criteria
and
upgrade
downgrade
strategy
version,
skew
strategy
and,
and
finally
like
listing
these.
These
are
some
of
the
the
optional
some
of
the
optional
fields
that
Lackey
had
mentioned.
A
So
we
said
we
were
gonna
stay
in
the
repo
and
we
are
gonna
stay
in
the
repo
for
a
little
bit
just
to
look
at.
So
this
is
the
so
this
is
the
CSI
volume
resizing
kept
our
tracking
issue
that
we
had
shown
in
the
slides-
and
you
know
just
running
through
really
quickly.
You
can
see
like
it
doesn't
take
a
lot
to
get
this
done.
Right
are
as
I
scroll
to
infinity.
A
But
you
see,
the
summary
is
short.
The
motivations
are,
you
know
pretty
brief
and
the
the
the
the
goals
and
non
goals
like
this
is.
It
doesn't
take
a
lot
to
like
understand
the
baseline
of
what
the
the
motivation
of
an
enhancement
is.
So
like
I,
don't
think
it's
a
high
bar
to
ask
people
for,
but
going
into
this
proposal,
wacka-wacka
right,
it
defines
all
of
the
api's
that
it
would
be
hitting
considerations
around.
B
And
from
there
we
get
into
the
test
plan
now
this
becomes
more
critical
as
you
kind
of
crystallize
what
you're
gonna
do
on
the
cap
and
this
outlines
when
we're
doing
the
release.
What
we
need
to
look
at
to
make
this.
This
enhancement
is
in
the
right
process
and
graduation
criteria.
Sorry
I
losing
my
voice.
B
What
is
the
milestones
you
want
to
hit
for
alpha,
beta
and
GA
and
how
to
get
through
them?
So
you
this
is
a
great
example
of
a
rider
cap.
So,
if
you're
looking
at
a
cap-
or
you
want
to
write
your
own
or
review
somebody
else's,
this
is
a
great
one
to
look
at
to
see
the
fields
that
you
need
to
think
about
and
you'll
see
up
the
top.
B
A
Now
I
want
to
talk
a
little
bit
about
I
think
we
have
not
too
many
minutes
left,
but
I'm
gonna
speed
through
this,
so
this
is
kind
of
like
the
future
state
like
it's
like
in
a
world
where
caps
evolve.
So
we
want
to
move
to
the
point
where
you
know.
We
have
already
started
to
tie
caps
to
the
release
process
and
we
want
to
move
that
forward
even
further
right.
So
in
the
sync
release
repo
we
organized
by
releases
right,
so
the
release
release,
/
115
subdirectory
will
describe
the
release
team.
A
The
dates,
the
important
dates
for
that
release,
the
exceptions
that
are
attached
to
that
release.
So
exceptions
are
when
something
doesn't
get
in
time.
It
doesn't
have
all
the
things
that
it
needed
in
time
and
really
K.
You
got
to
file
a
thing
for
us
and
we
have
to
approve
it
so
that
we
can
make
sure
this
is
safe
to
introduce
the
kubernetes
at
this
later
stage
right.
A
So
we
want
to
try
to
move
to
a
point
where
we
can
do
the
same
on
the
within
the
enhancements,
repo
and
then
and
then
kind
of
like
cover
this
and
layer
it
in
automation
right.
So
the
idea
is
that
we
would
we
would
go
into
these
enhancement
States
and
essentially
create
a
receipt
right,
and
that
receipt
is
very
similar
to
that.
That
enhancement
issue
that
you
saw
before
right.
But
the
big
difference
here
is
that
the
receipt
becomes
a
PR
right.
So
now
we're
committing
this
to
the
history
of
kubernetes
right.
A
So
it's
not
like.
Yes,
it's
it's!
It's
fairly
easy
to.
You
know
it's
fairly
easy
to
look
up
an
enhancement
issue,
and
yes,
it's
entirely
possible
that
we
will.
It
doesn't
matter,
because
we
will
continue
to
use
github
forever,
but
it's
possible
that
we'll
switch
off
and
get
have
to
rate
and
and
having
something
that
is.
Is
version
controlled,
super
important
right
having
that
receipt
in
the
in
the
repo
means
that
we
can
take
the
release
team
and
have
them
as
approvers
for
these
things
that
are
coming
into
the
release
right?
A
They
approve
it
once
they
approve
it.
A
bot
comes
along
and
and
transfers
all
of
the
information
from
proposed
for
like
proposed
caps
or
proposed
enhancements
over
to
accepted
right
and
then
from
there.
We
can
move
it
through
States
and
what
what
changes
there
is
the
the
human
nagging
of
like
hey
it's
five
days
until
this
thing
is
that,
like?
Can
you
please,
like
fill
these
things
out?
Becomes
our
bot
runs
at
this
day,
6
p.m.
Pacific
time
right?
If
your
thing
is
not
in
by,
then
it
doesn't
get
in
right.
It's
automatically.
B
B
B
A
So
this
is
the
Kerber
Nettie's,
115
enhancement,
tracking,
spreadsheet,
right
and
I
will
tell
you
as
someone
who
has
previously
done
this
role
and
I
think
lucky.
You've
also
shadowed
this
role.
This
is
a
manual
process,
there's
a
team
of
people
who
have
put
this
into
a
spreadsheet
and
they
do
so
every
release
cycle
right.
This
is
not
something
that's
sustainable,
I,
don't
think
it's
something
that
sustainable
or
can
be
ensured
to
be
accurate,
all
the
time
right.
So
you
can
see
we
keep
the
features
list
here.
A
A
Well,
these
are
the
kind
of
Alpha
features
are
in,
so
you
can
kind
of
get
a
get
an
idea
of
like
if
this
is
going
to
be
a
release
that
is
heavily
weighted
on
new
features
altogether,
if
it's
gonna
be
something
that
is
kind
of
like
a
stability
release
so
like
this
is
this
is
kind
of
the
reason
that
we
put
these
together.
But
again,
this
is
not
sustainable.
If
it's
done
by
just
people,
I
gets
prone
to
error
right
and
it's
I
had
I
had
to
click
way
too
many
buttons
to
get
to
that.
A
A
So
so
I
think
the
biggest
one
is
is
the
fact
that,
as
Lackey
was
mentioning,
there
has
been
a
lack
of
process
or
a
lack
of
consistent
process
across
the
community,
and
this
is
I
mean
because
this
is
in
the
critical
path
for
people
on
the
release
team
for
people
consuming
the
project.
Overall,
it
has
been
like
'whoa
process.
We
haven't
seen
real
process
like
this
before
so
I.
Think
it's
lightweight,
but
it
we're
still
trying
to
work
out.
C
I
really
got
alarmed
when
I
saw
all
the
manual
job
that
you
had
to
do
on
the
excel
sheet,
and
my
question
is:
if
you
are
a
very
well-known
open
source
project,
haven't
you
got
at
least
some
free
license
from
JIRA
to
to
help
you
track
features
because
Gina
out
of
the
box?
Does
all
these
things
you
show
on
the
spreadsheet?
C
A
That's
fair,
and
so
what
we
try
to
do
is
is
use
the
tools
that
we
know
everyone
can
get
at
right.
Regardless
of
whether
or
not
you
have
a
free
license
of
JIRA.
There
is
an
understanding,
and
there
is
also
a
maintenance
overhead
for
I
know.
I
know
every
company
that
I've
been
at
where
they've
spun
up
JIRA
they've
gone
like
hey.
Can
you
help
out
with
building
out
that
JIRA
workflows
and
the
boards
and
help
us
burn
down
this
thing
and,
like
hey,
I'm,
an
SRE?
A
This
is
not
my
job
right,
so
it's
you
know
dedicating
ourselves
to
picking
up.
Jira
means
that
we
have
to
create
a
support
team
for
that
right
and
and
overall,
our
community
is
not
in
the
we're
I
think
we're
all
here
to
support
each
other,
but
you
know
we're
not
in
the
business
of
building
support
teams
for
for
free
software
right.