►
From YouTube: 20201124 SIG Arch Enhancements
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Hello,
hello.
Everyone
today
is
november
24th.
This
is
a
bi-weekly
meeting
of
the
enhancement
sub-project
meeting
of
the
enhancement
sub-project
of
sig
architecture.
This
is
a
meeting
that
is
recorded
and
will
be
available
on
the
internet.
So
please
be
mindful
of
what
you
say
and
do
please
be
sure
to
adhere
to
the
kubernetes
code
of
conduct
and
in
general,
just
be
awesome
people
so
laura.
You
want
to
take
it
away
with
the
agenda.
B
C
Ahead,
oh,
we
can't
hear
you.
C
E
D
G
I
I'm
stepping
in
because
we
part
of
the
conformance
sub
project,
another
sub
project
of
architecture,
and
we
had
a
really
fun
release
for
120,
leading
up
to
some
ga
promotions
for
some
new
features,
and
it
was.
It
was
toward
the
end
of
the
release
cycle.
G
So
it
was
a
bit
a
bit
touch
and
go,
and
so
I
wanted
to
make
sure
that
we
that
I
learned
enough
about
where
all
of
the
caps
are
and
how
to
engage
in
that
process
for
the
ones
that
are
currently
inflow,
so
that
there's
plenty
of
lead
time
for
the
people
that
want
to
do
a
release
of
their
feature
within
a
release
cycle
so
that
it's
not
done
at
the
end
during
our
test
race
because
we
have
it
anyway.
Sorry,
I'm
digging
into
agenda
stuff.
But
I
am
that's
why
I'm
here.
E
B
G
I
am
still
here.
Okay,
I
assume
I
know
I
can't
zoom
in.
I
think
it's
probably
needs
this.
Pr
probably
needs
a
bit
more.
We
can
merge
and
iterate,
but
even
if
we
make
a
change
here,
it's
gonna
be
years
before
a
cat
that
goes
through
this
process
is
going
to
have
my
small
change.
G
The
current
cap
that
merged
ga
for
this
release
was
started
in
2016.
right,
so
this
well
well,
this
is
lovely.
I
think
if
we
look
at
the
changes,
some
things
that
are
probably
missing
is
time
frames,
because
we
should
encourage
them
to
have
all
of
their
tests,
written
probably
from
the
when
they're
in
beta,
so
that
the
promotion
pr
can
occur
with
those
tests
in
place.
G
I
think
we've
only
had
one
promotion
where
all
of
that
occurred
at
once,
and
it
was
like
orchestrated
by
liga
and
the
end
result
was
us
realizing
it's
probably
too
difficult
to
try
to
have
a
process
in
place
for
the
test
to
be
stoking
as
beta
tests
and
didn't
have.
The
promotion
include
updating
the
test
and
updating
the
endpoints
all
inside
a
single
ppr.
G
G
I
believe,
if
not,
we,
I
definitely
need
to
update
it
to
include
it,
the
idea
being
that
the
sig
release
the
release
team
would
get
informed
that
a
new
promotion
occurred
and
blocked
the
release
until
that
is
promoted
with
all
the
that
all
the
tests
are
included
as
well.
G
What
happened
in
this
last
release
was
that
promotion
occurred
with
less
than
two
weeks
to
go
in
the
release
and
we
made
an
exception
from
the
conformance
side,
and
I
think
there
was
also
an
exception
made
from
the
sig
release
side.
G
But
now
that
it's
merged
we're
having
people
on
the
conformance,
the
architecture
side
saying
that
the
tests
aren't
well
written
and
so.
G
This
really
will
deal
with
with
this
part
of
trying
to
make
those
tests
better,
but
in
the
future
we
would
love
to
have
more
of
the
timing
laid
out
for
those
people
wanting
to
go
through,
like
like
inside
of
the
caps
and
you're
gonna
need
to
plan
for
this.
I
I
I
totally
agree
with
you
and
I'm
the
one
that
granted
the
release
exception
for
those
things
to
get
added.
I
think
that
took
a
look
at
your
pr
and
I
definitely
think
we
can
add
more
to
it.
We
can
use
this
as
a
starting
point,
but
I
think
it
would
be
really
good
to
add
a
section.
Maybe
that
makes
it
really
explicit
something
maybe
for
the
table
lists
out
the
end
tests
that
are
going
to
be
added
as
part
of
the
test
plan
and
then.
I
That
will
be
promoted
to
conformance
that
way.
We
have
that
extra
documentation
there
and
it'll
be
easier
for
the
the
release
team
to
go
through
and
verify
that
those
are
in
place
before
we
accept
it
into
the
release
and
as
to
like
adding
things
back,
we
we
actually
got
pretty
good
adherence
to
updating
caps.
I
This
time
kirsten
was
the
enhancements
lead
for
120,
and
she
worked
with
a
lot
of
authors
to
get
them
to
update
to
the
new
format,
because
there
were
a
lot
of
things
like
that
back
in,
like
you
know,
from
116,
or
way
before
116,
that
hadn't
updated
their
cups
beforehand.
So
as
part
of
the
enhancements
collection
process
this
time
around,
they
did
a
pretty
good
scan
of
the
things
that
had
opted
into
the
release
and
got
them
to
update
the
format
correctly.
I
So
I
think,
if
we
add
this
to
the
ammo
and
to
the
readme,
like
maybe
a
section
wherever
it's
going
to
land,
but
we
we
add
in
those
sections,
I
think
we'll
get
pretty
good
adherence
from
people
marking
these
things
down
and
filling
the
sections
out
and
definitely
like
during
the
121
time
frame.
We
can
have
the
release
team
work
with
you
too.
G
Well,
that
would
be
lovely
in
this
we're
talking
about
adding
a
section
for
the
ede
test.
I
think
even
more
explicitly
would
be
each
of
the
operations
yeah,
because.
D
G
Can
have
an
api
snoop
link
that
has
the
exact
operation
and
it
will
have
a
a
setting
to
say
what
either
what
the
tests
hitting
it
are
or
if
there
is
a
test
in
place.
So
we
know
which
one
to
promote
so
that
the
we're
well
prepared
to
to
know
exactly.
What's
going
to
happen
when,
when
we
submit
that
promotion
request
for
those
edu
tests,.
A
Yeah,
so
one
thing
I
would
say
is
that,
because
we're
adding
a
new
requirement
to
the
cap,
just
in
general,
I
think
end-to-end
tests
are
mysterious
for
people.
If
we're
going
to
add
this
as
a
requirement
to
keps,
it
needs
to
be
incredibly
thorough
before
saying
that
it's
a
requirement
for
everyone.
A
I
cause
like
I
with
those
with
with
that
pr.
I
I
reviewed
the
pr
just
now,
but
that
pr
like
I
would
need
a
lot
more
detail
to
get
where
I'm
going
and
be
successful,
submitting
a
cap.
A
So
just
just
a
note
that
this
is
maybe
new
territory
for
a
lot
of
people,
especially
people
who
are
going
to
be
reviewing
the
keps
from
the
release
team
side
needing
to
have
the
appropriate
context
to
to
know
if
something
looks
off
right,
as
well
as
how
we
start
to
work,
those,
maybe
those
promotion
tests
into
master
and
forming
right
to
so
that
the
release
team
has
visibility
on
that
too.
A
G
Before
I
think
it's
getting
examples,
because
normally
we
link
into
api
snoop
for
a
specific
release,
so
we
can
see
new
promotions
or
any
new
ga
apis
that
don't
have
tests,
because
that's
the
primary
use
cases
for
it.
G
And
I
don't
know
that
something
exists
currently
for
those
links.
The
primary
binary
indicator
is
the
there's
the
job
and
I
think
that's
that's
fairly.
A
A
Yeah,
I
would,
I
would
say,
even
just
to
start,
if
it's
a
link
in
that
in
that
document
to
api
snoop,
I
think
for
a
lot
of
people
who
are
not
close
to
like
I
have
like.
I
have
some
co-workers
that
are
starting
to
poke
around
the
conformance
stuff,
like
I
think,
for
a
lot
of
people
who
are
not
familiar
with
with
that
kind
of
subproject
and
like
being
able
to
point
them
to
api
snoop
and
show
them
the
functionality
and
like
show
them
how
they
might
become
conformant.
A
If
they
start
to
look
at
these
things
would
be
useful,
especially
if
you
know
as
you're.
If
you're
say
you
were
kept,
who
has
been
open
since
you
know
2016,
or
something
like
that
right
and
you're,
coming
back
to
the
kind
of
backfill,
a
bunch
of
information,
giving
them
something
like
api
stamp
to
kind
of
like
poke
at
and
go
oh
well,
I
can
see
exactly
which
points
are
you're.
You
know
not
on
the
board
would
be
super
useful.
G
We've
found
the
most
the
common
use
is
within
the
cap
to
point
to
the
entire
area.
I
think
it's
the
api
group
that
is
getting
promoted,
so
they
can
see
the
existing
endpoints,
which
ones
are
tested
and
which
ones
are
conformance
tested.
G
The
other
tooling
that
we've
not
seen
a
lot
of
linking
to,
but
the
our
team
will
use,
will
be
to
actually
bring
up
the
snoop
db
within
a
cluster
that
has
audit
locking
turned
on
so
that
we
can
verify
which
endpoints
are
getting
hit.
G
We
we
verify
that
by
bringing
in
existing
e
to
e
jobs,
we're
with
the
tester
run
and
downloading
their
audit
logs
and
injecting
over
the
db.
F
Jeremy,
would
this
be
like
a
longer
term
feature
for
the
receipts
receipts
kind
of
boss?
Would
that
be
something
that
they'd
have
to
have
conformance
tests
in
place
and
on
passing?
They
would
be.
You
know,
included.
I
These
things
in
first
and
figure
out
what
it
looks
like
to
document
these
things
before
we
think
about
adding
any
validation
for
it.
I
mean,
I
think,
we're
still
going
to
end
up
with
a
lot
of
manual
review
of
these
things,
as
we
go
forward
with
the
receipts
process
for
for
a
while,
and
I
think
just
having
the
understanding
of
what
these
look
like.
What
what
satisfies
the
conformance
need
from
the
conformance
working
working
group
like
what
what
in
the
cap
will
satisfy
that
help
with
the
review
process.
G
I
We
don't
really
keep
a
a
catalog
like
that.
I
think
the
best
thing
to
do
would
be
to
look
at
the
ones
that
are
promoting
to
beta
this
time
around
yeah,
okay
as
a
first
pass
and
then,
as
we
start
to
close
the
you
know,
putting
sig
release
hat
on
and
release
lead
dot.
As
we
start,
the
enhancements
collection
for
121
that'll
identify
the
things
that
are
going
to
promote
to
ga
yeah
and.
G
I
Be
able
to
early
on
help
identify
which
ones
are
are
lacking
in
that
sense,
and
definitely
like
it's
slightly
out
of
the
scope
of
enhancements.
That's
a
thing,
it's
more
like
an
extra
release
thing,
but
you
also
have
like
several
people
from
sig
release
here,
so
we
can
help
coordinate
that
for
121.,
but
definitely
the
things
that
are
promoting
the
beta
and
120,
I
think,
would
be
the
a
good
set.
You
know
like
to
start
working
on
to
make
sure
that
going
forward.
G
As
a
quick
demonstration
of
that,
if
anybody,
if
the
screen
sharing
person
would
like
to
go
to
api
snip,
we
actually
have
a
list
of
apis
that
have
gone
through
that
transition
per
release.
G
If
you
scroll
down
past
the
graph
there's
a
list
and
that
list
is
the
new
things
and
when
we
see
levels
stable,
we
that's
where
we
kind
of
an
indicator,
but
past
stable
will
be
the
beta
and
other
things.
So
if
for
what
I
hear,
I
should
look
at
the
apis
down
there
in
the
beta.
G
And
then,
if
we
had,
if
you
click
on
my
safe
flow
control,
api
server
in
the
category
area,
that
would
give
us
a
zoomed
in
area
for
just
flow
api
control
to
say
that
they
have
21
endpoints
and
one
only
one
conformance.
So
this
would
be
a
great
link
for
their.
G
A
So,
just
as
a
just
kind
of
as
an
indicator
like
what
is
bad
like
is
this
bad.
G
No
they're,
it's
just
it's
not
bad
in
that
we
don't
have
requirements
for
alpha
or
beta
to
have
tests,
but
for
them
to
promote
the
ga.
They
should
have
not
only
your
tests
written
but
ensure
that
they
meet
the
definition
of
conformance.
So
we
have
the
conformance
guidelines
that
say
what's
required
that
way
when
they
promote
once
it's
stable,
they
can
go
ahead
and
wait
two
weeks
because
we'll
have
to
look
at
the
test
grid
for
those
tests
and
ensure
that
they're
non-flaky,
so
there's
two
big
things.
G
A
Yeah-
and
that's
I
mean
that's-
I'm
gonna
air
quote
that's
easy
to
do
when
you're.
I
think
I
think,
when
people
are
buying
into
the
release
cycle,
it's
like
two
weeks
is
is
a
big
chunk
of
time
right
like
or
rather
it's
just
it's
just
it's
a
small
sliver
of
the
entire
release
cycle.
So
I
think
it's
entirely.
A
To
make
that
happen
it
just
it's:
just
people
have
to
be
aware
of
the
enhancements
collection
periods
and
and
when
development
should
be
going
on
for
the
release.
So
I
don't
think
I
don't
think
that
part
will
be
hard.
I
think
it'll
be
making
sure
it
happens
in
caps
too.
G
One
other
quick
length
that
might
be
useful
specifically
for
sig
release
and
for
the
the
cap
is
the
release
itself.
So,
if
you
go,
I
can't
quite
see
the
full
screen
on
my
phone,
but
if
you
go
up
to
the
top
of
the
page,
there'll
be
a
link
to
conformance
something:
that's
rotate.
My
progress,
yeah
click
on
the
progress
yeah
and
then
there's
two
things:
there's
a
list
of
ineligible
endpoints.
G
But
if
you
look
at
the
time
of
the
release
for
this
release
here,
we've
avoided
any
new
endpoints
without
test
the
orange
that
we
don't
want
rotate
the
phone
again.
I
can't
quite
see
with
the.
If
you
click
on
the
the
I
guess.
It's
turquoise
the
turquoise
area
are
the
successful
promotions,
which
is
primarily
what
we're
focused
on
here.
So
we
could
link
to
this
to
see.
This
is
the
untested.
G
G
That's
the
top
color
under
type.
G
This
is
where
we
want
to
keep
our.
This
is
where
we
would
like
it
to
be,
and
what
happens
when
we
don't
have
test
is
under
promoted
without
test.
So
if
you
click
on
promoted
without
test
it'll
add
add
that
to
the
filter,
there's
none
in
this
release
yet
because
we
that's
part
of
the
release
cycle.
If
we
want
to
see
what's
the
indicator,
that's
really
easy
to
link
to.
G
If
you
uncheck
promote
with
test
this
link,
if
we
go
to
the
url
or
we
go
back,
we
can
change
the
release
and
we
can
probably
just
go
back.
G
Yeah
and
then
just
choose
one
of
the
orange
areas.
Oh
right,
any
of
those
orange
areas
are
the
release
where
we
had
promotions,
but
it
was
promoted
in
that
release,
but
it
wasn't
tested
so
much
later.
These
are
the
ones
we're
trying
to
avoid
and
make
sure
that
the
promotion
release
is
the
tested
release,
and
we
can
see
that
this
particular
piece
of
debt
introduced
in
114
was
finally
cleared
in
this
last
in
the
120.
G
Some
of
them
are
probably
more
useful
for
the
release
team
and
some
of
them
are
more
useful
for
the
particular
api.
That's
trying
to
promote,
but
there'll
be
an
overlap
of
those.
G
B
Up
have
action
item
to
for
hippie
hacker
to
keep
working
on
the
existing
pr
to
make
it
clearer
for
folks
who
are
not
familiar
with
conformance
tests.
What
exactly
they're
looking
at
and
then
add
the
link
to
this
api
snoop
as
a
way
to
get
some
metrics
here
and
details
about
what's
been
tested
or
not,
and
then
what
about
this?
Looking
at
the
caps
promoting
to
beta
and
120
are
we?
The
idea
is
to
also
work
with
some
of
those
to
identify,
what's
lacking
in
the
testing
sense
and
then
make
them
ready
for
121.
A
Sure
hang
on:
do
we
want
to
hit
sushmita's
check-in
first
yeah.
D
Oh
okay,
yeah,
so
basically
aiden
and
I
we
worked
on
the
buff
template
and
we
wanted
to
look
into
the
glossary
part
of
it,
but
we
had
some
questions
regarding
the
answering,
so
I
wanted
to
understand:
what
exactly
are
we
like?
What
is
the
glossary
for
or
like
yeah?
I
just
want
to
understand
like
where
do
we
have
to?
Why
do
we
need
it
and
like?
Where
do
we
create
it?
If
you
could
give
me
like
a
background
for
that,
I
probably
can
be
able
to
understand
that
better.
A
So
I
think
you
know
part
of
it
is
like
maybe
do
we
need?
It
is
a
good
question
to
ask
great
the
the
idea
is
that
if
there
are
a
set
of
you
know,
words
that
you
don't
understand,
for
you
know
for
kind
of
engaging
with
this
process.
A
Where
do
you
go
to
get
them
right
so
like
either?
Our
documentation
is
incredibly
explicit
about
laying
out
everything
that
is
in
the
process
or
you
know
are.
In
addition,
you
know
we
also
have
a
set
of
you
know,
quick
terms
to
look
up
to
help
people
kind
of
on
board.
So
that's
what
the
glossary
would
be
for.
D
So
will
this
be
a
part
of
the
kept
template
or.
A
It
should
be
outside
of
the
template
really
right.
It
should
be
kind
of
like
close
to
where
you're
entering
our
domain
right.
So
maybe
on
the
read
me
maybe
close
by
to
the
readme.
Maybe
it's
a
glossary.
Md,
that's
in
the
root.
D
B
D
So
that
was
about
it
and
we
worked
on
the
buck
template
as
well.
Oh,
do
you
want
to
bring
that
up?
Yeah
I'll,
stop.
K
E
E
D
Okay,
so
I
had
a
look
at
like
some
of
the
other
six
that
have
that
have
templates,
and
I
had
a
look
at
some
of
the
open
and
closed
bugs
that
were
reported,
like
pull
requests
that
had
these
information
and
I
kind
of
brought
together-
and
I
observed
that
there
is
nowhere
that,
like
most
some
of
the
some
some
of
the
bugs
have
like
some
of
the
fields
missing.
D
So
I
thought
if
we
can
like
make
that
a
mandatory
field
or
an
optional
field,
it
could
be
better,
and
this
is
the
this-
is
something
that
I
aiden
and
I
we
came
up
with
so
oh,
is
there
any
feedback.
A
Yeah,
so
so
I
would
say
that
we
primarily
don't
have
bugs.
I
think
that
will
crop
up
more
as
we
have
as
we
build
more
more
and
more
tooling,
so
I
would
probably
drop
the
environment
section.
I
think
a
bug
I
think
a
bug
for
us
right
now.
Maybe
it's
someone
that's
using
the
tooling,
but
more
likely
it
is
a
it's
a
piece
of
feedback
for
the
process.
A
More
so
so,
like
our
bug
is
more,
I
guess
meta,
and
so
it's
yeah
it's
either
gonna
be
kind
of
like
a
feature
request
or
a
feature
request
specifically
for
some
piece
of
tooling
or
for
the
kept
template
or
what
might
be
considered
to
be
a
bug
for
one
of
those
one
of
those
pieces
within
our
our
area.
B
A
So
I
do
like,
maybe
so
I
think
you
know
probably
dropping
environment
and
steps
to
reproduce.
I
like
most
of
the
rest
of
it.
D
And
now
that
you
told
me
that
this
is
mostly
like
you
know,
how
do
we
improve
the
cap
template
or
like
feature
enhancement?
So
do
we
need
the
priority
and
severity
would
be
my
question.
A
So
yeah,
so
one
of
our
we're
just
having
this
conversation
in
another
meeting,
one
of
the
problems
that
we
have
with
because
I
was
like,
oh
we
could
kind
of-
we
could
just
use
the
labels
for
these
we
kind
of
can't.
So
we
have.
We
have
labels
that
indicate
priority
right,
but
the
labels
are
also
kind
of
like
spliced
in
with
severity
right
so
they're,
like
their
labels
like
priority
critical
urgent
right
are
important,
soon
or
important
long
term
right.
A
So
it
gives
you
kind
of
like
a
some
angle
of
priority
and
also
urgency,
but
they're
conflated,
so
I
think
explicitly
listing
out
something
that
we
consider
to
be
potentially
blocking
for
the
process
right.
If
we
have
something
that
like
doesn't
work
right
it
just
it's
something
that
we
rolled
out
and
it's
straight
up
doesn't
work
and
people
are
pissed
off
right.
They
should
be
able
to.
They
should
be
able
to
provide
that
feedback
on.
You
know
on
this.
This
bug
template
right,
I'm
kind
of
like
process.
B
I
can't
move
forward
because
I
don't
know
what
to
do
and
where
to
find
instructions,
and
that
would
be
like
urgent,
because
maybe
other
people
would
be
in
the
same
position
like
they
just
it's
like.
That's
me.
That's
me
too
yeah
you
do
exactly
and
then
something
that
would
be
long-term
might
be
just
the
basics
are
there,
but
we
know
that
it
could
be
better
in
some
way.
You
know.
A
You
know
it
takes
a
few
cycles
to
clean
up
or
something
right.
You
know
something
like
the
recedes
process.
Right
is
a
is
going
to
be
a
multi-cycle,
lift
sort
of
right.
So
seeing
you
know
seeing
someone
file,
maybe
if
someone
was
to
file
something
on
receipts
right
now
right,
I
would
love
a
way
to
be
able
to
say
what
I'm
going
to
deliver
for
the
release
cycle,
and
I
don't
have
a
way
to
do
that
right
now,
without
writing
a
full
scale,
cap
right
and
then
that's
something
that
I'm
like.
A
Oh,
this
is
actual
feedback.
This
is
actionable.
Feedback
like
this
is
something
we
can
roll
into
our
process,
so
I
think
yeah
having
a
template,
for
you,
know,
process,
improvement
or
what
people
might
perceive
to
be
bugs.
Maybe
the
bug
is
something
that
is
like
poorly
explained
or
it's
a
term
that
they
don't
understand.
That
needs
to
be
part
of
the
glossary
right.
B
So
here's
a
question:
there
are
already
some
of
these
types
of
issues
that
have
been
filed
that
we
haven't
acted
on,
one
example
might
be:
can
I
file
a
policy
change
as
an
enhancement,
so
you
know
that
might
stop
somebody
because
they'd
they
would
be
like.
I
don't
know
what
to
do.
I
have
a
policy
improvement.
B
A
B
For
example,
maybe
for
that
question
it
comes
from
one
person
right.
Somebody
will
file
an
issue
like
I
don't
know
what
to
do.
I
have
a
can
I
file
a
policy
kept
then
what
you
could
do
is
take
that
issue
use
this
bug,
template
and
try
to
get
more
feedback
on
it,
for
example,
in
chairs
and
leads,
or
in
whatever
sig
might
have
originated
the
issue
just
to
get
more
input.
B
You
know
just
like
any
product
manager
would
getting
user
feedback
on
the
process
itself
and
there
you
then
have.
Maybe
I
don't
know-
maybe
maybe
so
maybe
you
would
have
less
discussion
on
issues
which
can
take
a
long
time
to
kind
of
like
you
know.
People
might
leave
issue
comments,
but
then
nothing
really
happens
on
those
for
significant
amounts
of
time.
Maybe
through
this
kind
of
more
face-to-face,
proactive
input
gathering,
you
can
reach
decisions
a
lot
faster
around
this
process
and
then
have
clearer
clearer
to
do's
from
that
feedback.
A
So
so
I
think
that
something
that
has
that
that
is
actually
a
great
that's
a
great
issue
to
bring
up
should
keps
the
the
one
about
should
keps
be
used
for
policy
changes.
I
think
the
answer
has
been.
Maybe
it
depends
yeah
exactly
the
the
triage
cap
is
a
great
example
right
where
so
one
we
don't
want
to
create
more
friction
than
we
need
to
for
a
sig
to
deliver
some
unit
of
work.
A
If
it
is
not
in
if
it
is
not
directly
in
the
release
cycle,
then
there
is
definitely
a
an
opportunity
to
say
that
maybe
this
thing
doesn't
need
to
be
a
cap
right,
but
at
the
same
time,
if
it
touches
a
lot
of
people-
and
it's
not
well
formed-
maybe
there's
an
opportunity
for
it
to
be
a
cap
right.
I
think
I
think
the
triage
capital
is
a
great
example
of
of
that,
where
it's
like
a
process,
we're
about
to
drop
it
on
the
entire
community.
A
Does
it
work
like
we
need
to
flesh
it
out
and
and
having
that
thoughtful
conversation
around
creating
something
that
can
work
for
multiple
people,
but
we
do
need
to
be
able
to
say
that
like
explicitly
say
that
that
it
should
be
done
and
are
we
at
the
point
where
we
can
say
that,
do
we
think
it's
been
sufficiently
useful
to
to
try
to
enforce
I,
and
I
don't
think
it
has,
but.
B
No,
I
mean
I
think
these.
This
is
just
like
when
you're
we're
talking
about
these
big
policy
changes
like
take,
for
example,
your
effort
to
see
what
people
would
like
in
terms
of
release
cadence
three
or
four
per
year.
You
did
a
ton
of
outreach
on
that
question.
So
then
your
data
is
pretty
pretty
diverse
and
also
you
have
this
huge
swath
of
perspectives
on
that
question.
B
With
these
kinds
of
policy
questions
or
not,
we
hear
from
some
people
who
are
heavily
invested
in
the
process
already.
They
leave
github
issue
comments
and
then
it
kind
of
just
stalls
out,
because
there's
obvious
knowledge
that
you
know
the
comments
of
five
or
ten
people
weren't,
probably
enough
to
act
on
so
then
nothing
really
happens,
and
so
what
I
could
see
this
doing
is
the
bug.
Template
could
be
a
way
to
activate
user
feedback
around
those
policy
questions
to
make
them
a
lot
crisper
and
actionable.
B
I
guess
it
would
be
the
more
proactive
we're
going
to
actually
go
out
and
seek
your
feedback
instead
of
just
wait
passively
for
people
to
find
the
issue
comment
on
it,
and
then
it
sort
of
becomes
the
tragedy
of
the
commons
who
who
actually
picks
up
that
issue
and
makes
something
happen.
A
A
Yeah
because,
like
that,
the
only
thing
I
don't
want
is
for
it
to
create
where
we
either
become
a
gating
function
for
people
to
deliver
process
change
or
we
become
responsible
for
gathering
the
feedback
required
for
some
process
change.
I
don't
be
responsible
for
that.
So.
B
B
Let
us
know,
and
then
maybe
we
invite
people
to
come
here
but
like
they
leave
owning
the
question
and
we're
just
like
providing
space
for
that
check-in
and
clarity.
You
know
I'm
going
to
own
this
github
issue
about
policy
and
I
want
to
come
to
the
enhancement
sub-project
meeting
to
just
kick
around
a
few
ideas,
get
some
context
in
perspective
and
then
go
off
and
solve
the
problem.
A
A
True
true,
I
think
that
you
know,
I
think
part
of
what
we
could
do
is
consider
a
this
is
I
think
this
is
when
we
have
more
consistent
attendance
outside
of
kind
of
like
the
lead
framework
and
and
the
people
who
have
been
in
and
around
the
release
team
is,
is
maybe
consider
what
does
this
look
like
to
be?
What
would
this
look
like
as
in
office
hours,
right,
yeah
this?
A
This
has
come
up
before,
but
again
like
in
the
sig
pm
before
times
when
there
weren't
a
lot
of
people
showing
up
to
these
meetings.
I
was
just
kind
of
like
yapping
at
a
camera
for
an
hour,
the
yeah.
The
idea
is
essentially
like
you
have
a
cap.
You
want
to
do
stuff
with
your
cap.
You
don't
know
how
how
to
do
that.
Come
bring
your
cap.
We
will
help
you
cap.
B
A
Yeah
and
then
it
becomes,
you
know
it
becomes
a
you
know,
infectious,
almost
right,
you,
you
know,
you
teach
one,
you
know,
or
you
teach
a
few
people
how
to
do
that
they
go.
You
know
they
go.
Do
it
and
sorry
to
bring
up
infection,
but
it's
okay.
A
On
did
you
catch
the
caps,
like
you
know,
like
teaching
someone
how
to
to
kind
of
structure
the
spot
properly
yeah.
It
becomes
less
of
a
requirement
for
the
release
team
to
understand
how
to
deliver
these
in
the
front
half
of
the
cycle
or
to
chase
people
in
the
front
half
of
the
cycle,
and
more
so
a
you
know.
Maybe
it's
a
I
don't
know
like
you
know.
A
Maybe
it
starts
off
as
a
like
kept
training
session
or
something
with
with
sig
chairs
and
leads
right
and
then
it
kind
of
grows
into
you
know
everyone's
got
their
own
kind
of
understanding
of
how
to
deliver
it
within
their
sig.
I
would
love
to
see
you
know.
I
would
love
to
see
the
the
idea
of
the
sig
pxm
rise.
Yeah
like
exactly
you
know,
you
have
been.
You
have
been
incredible
to
to
have.
A
You
know
leading
program
management
efforts
on
the
release
side,
and
I
think
that,
like
that,
just
that
model
is
useful
to
people
right,
and
I
think
you
know
if
I
think
what
ends
up
happening
is
like
the
most
organized
engineer,
ends
up
being
the
product
manager
right
for
for
the
cycle
right,
which
means
they're,
they're
handling
the
caps
they're,
doing
reviews
they're
doing
approvals
they're,
you
know
they're,
organizing
the
bits,
they're
working,
the
board
they're,
you
know
they're
communicating
out
and
that's
a
lot
of
that's
a
lot
of
juggling
right.
There's.
A
And
it
can
maybe
be
in
a
bunch
of
of
hands
right.
This
is
an
opportunity
for
contribution
on
kind
of
the
pxm
side
right
where
classically
there
wasn't
any
right.
H
A
B
B
Different,
but
we
have
talked
all
along
about
trying
to
get
pxm's,
embedded
and
sigs,
and
to
do
that,
you
know,
would
be
partly
trying
to
make
yourself
obsolete
as
quickly
as
possible.
So
this
is
essentially
like
training.
The
chairs
and
tech
leads
to
do
cap
development
and
prioritization
and
breakdown
work.
B
If
they
don't
have
that
knowledge
already
and
then
either
you
form
a
relationship
with
that
sig
and
you
stick
around
and
work
as
an
embedded
member
of
the
team
kind
of
like
what
sig
release
has
had
happened
with
me,
or
they
go
and
find
someone
else
in
the
sig
who
wants
to
do
that.
Work,
who's,
an
engineer
as
well,
but
just
has
more
of
an
interest
in
product
management,
and
then
they
go
and
do
it.
You
know
because
I
think
some
based
on
my
conversations
with
sigs.
B
Some
folks
are
not
that
enthusiastic
at
this
point,
or
at
this
moment
and
having
someone
with
a
product
management
background,
come
in
and
actually
do
product
management
work.
I
don't
agree
with
that.
I
think
that
it's
incredibly
useful
and
in
fact
quite
needed,
but
there
are
some
just
concerns
that
I
think
people
have
developed
over
time.
That
would
have
to
be
chipped
away
at
so
it
would
be
a
trust,
building,
effort
to
show
up
and
start
working
with
them
and
have
them
realize.
B
A
Yeah,
that's,
but
you
know
also
like
making
you
know
some
people
do
this
because,
like
it's
fun
right,
I'm
having
fun
doing
this
right
and
it
and
it
can
maybe
make
open
source,
feel
more
like
work
and
and
not
as
exciting.
For
that
reason,
I
don't
buy
it.
I
don't.
A
So
if
we,
you
know,
if
it's
something
that
we
want
to
do,
we
should
get
a
better
understanding
of
like
what
our
metrics
for
success
are
and
who
our
potential
champions
are
in
various
cigs
right
like
who
might
be
even
be
interested
in
this
right
and
and
how
do
we
show
that
it
works
eventually
and
if
we
can
do
that,
and
we
have,
I
think
we
already
have
you
know
a
list
of
of
potential
volunteers
for
some
of
this
right
and
you
know
so.
A
A
So
like
providing
a
framework
for
success
for
this
as
well
like
here,
are
the
things
that
you
want
to
try
to
drag
out
of
the
sig
or
want
to
improve
or
like
hear
like
when
you
have
this
conversation,
you
know
that
you're
you're
moving
to
this
level,
yada
yada
like
providing
a
framework
for
success,
especially
for
new
contributors.
Stepping
into
this
because,
like
pxm
stuff,
has
not
been
successful
in
the
community
and-
and
I
would
hate
to
like,
send
a
new
contributor
off
to
go.
A
Do
something,
and
just
like
not
have
a
good
time.
So
we
need
to
make
sure
we
make
that
a
positive
experience
for
everyone.
Yeah.
B
So
we
have
a
bit
of
a
model.
It's
just
been
a
matter
of
timing
with
kubecon
and
people
being
on
vacations,
but
we
have
a
pm
who's
been
interested
in
helping
a
sig
cloud
provider
to
to
serve
this
function.
And
basically
you
know:
what
can
she
do
from
a
product
manager
perspective
to
help
them
self-organize
so
that
the
two
chairs
don't
have
to
do
all
of
the
heavy
lifting?
So
I
think
actually
the
meeting.
B
Well,
I
think
tomorrow
is
the
meeting
and
we're
gonna
have
everybody
on
vacation,
so
it
might
be
postponed
again,
but
at
some
point
there
will
be
a
meeting
and
we
will
go
and
we
will
sort
this
out,
but
I
imagine
that
there's
probably
other
cigs
that
would
be
welcoming
to
this
kind
of
help.
So
that's
actually
nikita
s
she's
in
the
enhancements
channel,
so
sushmita.
B
You
know
where
each
person
who's
a
product
manager
has
a
specific
sig.
They
work
with
or
like
a
specific
task,
so
say,
for
example,
you
would
like
to
just
host
the
office
hours
or
be
one
of
the
hosts
of
that,
and
you
would
sign
up
for
that
and
then
people
would
come
bring
their
cups
and
you
would
help
them
make
their
cups
better.
We
would
have
to
communicate
the
messaging,
so
we
would
want
folks
to
be
aware
that
we
would
be
doing
these
new
activities
in
121
so
that
they
actually
show
up.
J
B
Yeah,
like
clearly,
you
know,
there's
something
that
they're
not
getting,
whether
it's
time,
whether
it's
they
missed
a
step,
so
that
could
actually
be
a
great
starting
point
for
getting
feedback.
A
Yeah,
so
I
would
say
like
selfishly,
this
is
the
kind
of
feedback
that
I
want,
as
we
start
to
make
considerations
around
changing
the
release.
Cadence.
One
of
the
questions
that
we've
been
asked
is
like.
Well
what
slips
like
what
lands
like?
How
do
we
know
like
how?
How
do
we
know
that,
like
a
change
in
the
process
can-
or
you
know,
change
in
the
cadence
may
or
may
not
affect
delivery?
A
I
think
that
I
think
that,
surprisingly,
we
had
a
lot
more
enhancements
land
in
this
release
than
I
like.
This
is
probably
one
of
the
heaviest
end-of-year
releases.
I've
ever
seen
it's
it's.
G
A
In
quite
a
while,
you
know,
and
and
it's
like
at
this
point-
I've
done
a
few
of
them
so
so
like
this
is
yeah.
This
is
we
usually
like
we'll
land.
You
know
somewhere
in
the
30
well
like
somewhere
in
the
30
to
40
range
will
be
proposed
and
maybe
30
of
that
will
drop
by
the
end
of
the
release
right.
So
that's
that
you
know.
A
That's
that
you
know
we
had
a
you
know
we
had
a
commit
level
and
then
we
had
a
delivery
level
of
like
you
know,
60
something
percent
right,
so
I
think
it'd
be
interesting
to
poke
around
kind
of
like
the
the
in
between
bits
where,
like
things
were
proposed
and
where
they
didn't
so
checking
out
that
deferred
stuff.
I
yeah,
I
think,
that's
a
that's
a
great
idea.
I
know
josh
burkus
has
a
an
intern
that
a
data
in
turn
that
they
were
looking
to
collect
information
around
this.
A
A
Quantify
or
again
straight
yep,
so
that's
that's
a
good
angle
to
play.
J
B
I
A
I
One
minute
now
and
I
are
pairing
on
a
hack,
md
document-
it'll,
be
our
you
know
like
just
our
drop
in
for
the
the
pr.
I
think
at
this
point,
it's
better
to
focus
on
getting
that
nail
down,
and
then
we
can
work
on
manually
executing
that
stuff
during
121
and
then
work
on
any
supporting
tooling.
We
need
to
do
during
121
and,
like
maybe
identify
any
areas.
The
process
sucks
that
we
need
to
change
before
we
codify
anything
with
some
tooling
do
have
a
branch
open.
I
The
work
in
progress
stuff,
so
we're
flushing
out
the
user
stories
we
want
to
make
like
the
the
the
cap
have
like
pretty
verbose
user
stories.
Just
so
it's
really
clear
to
people
like
what
the
workflow
is
going
to
look
like
and
that
kind
of
turns
into
documentation
like
as
a
kep
author,
I'm
gonna
do
these
five
things
or
these
four
things
and
how
the
process
will
fit
into
that.
So
we
haven't
had
a
lot
of
time
last
week
or
the
week
before,
just
given
like
release
cadence
stuff
and
kubecon
and
other
stuff.
I
But
my
week
is
pretty
free
this
week,
so
yeah.
I
Yeah,
it's
pretty
dope,
so
we're
flushing
those
things
out
and
then
just
kind
of
the
surrounding
text.
We've
cleaned
up
the
we've
removed
some
things
from
the
template
that
don't
make
sense
kind
of
going
back
to
like
policy
changes.
This
is
largely
a
policy
change
that
will
have
some
tooling
to
support
it,
but
like
does
it
make
sense
to
have
a
pr
review?
Probably
not
because
it's
not
really
a
thing.
I
That's
going
to
graduate
like
that,
so
we
we're
hopefully
going
to
have
that
stuff
wrapped
up
this
week
or
a
large
chunk
of
it
wrapped
up
this
week
and
we'll
drop
it
into
the
enhancements
channel
for
a
review
unless
you
have
any
other
thoughts
on
that
navaroon
nope
thanks
same
thoughts
on
this.
A
I
would
I
would
say
that,
as
we're
entering
the
holiday
yeah,
the
I
would,
I
would
put
it
up
sooner
rather
than
later.
A
Because,
like
I
am
very
likely
to
stare
at
things
during
thanksgiving
and
even
if
it's
even
if
it's
like,
even
if
you
feel
it's
not
meaty
or
it's
not
like
cooked
enough
like
I
would
just
toss
it
up
and
get
you
know
if
people
want
to
stare
at
it,
give
them
an
opportunity
to.