►
From YouTube: 20200707 SIG Arch Enhancements
Description
GMT20200707 153445 SIG Arch E 2048x1152
A
Hello,
hello,
everyone
today
is
July
7th.
This
is
the
first
official
meeting
of
the
enhancements
sub
project
for
sig
architecture
rarara.
This
is
a
meaning
that
is
recorded
and
available
on
the
internet.
So
it
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
we've
got
a
few
items
on
the
agenda,
but
we
have
only
a
few
people
here,
so
I
think
I
think
what
would
be
worthwhile
is.
A
B
Sure
John
Balam,
Eric
I
am
one
of
the
chairs
in
architecture
and
have
been
also
Enhancement,
shadow
for
118,
119
and
so
I'm
really
interested
in
making
the
process
smoother
for
how
we
handle
camps
just
improving
improving
the
discoverability
of
caps.
One
of
the
things
that,
in
second
architecture
we
tried
to
do
a
while
back,
was
start
to
review
some
of
the
cap
to
try
and
find
ones
that
were
like
either
good
ideas
that
were
lost,
because
maybe
the
person
pushing
it
forward,
one
well-known
in
the
community.
B
Sometimes
that
means
people
don't
spend
as
much
time
on
something
or
things
that
maybe
we
mean
we're
concerned,
might
be
an
idea
that
that
sounds
good
on
the
surface,
but
might
cause
problems
that
we
want
to
sort
of
course
correct
early
and
we
in
a
really
entertain
finding
good
caps
in
flight
and
understanding
what
stage
they
were
in
through
the
process,
and
so
that
kind
of
instigated
a
desire
to
to
work
on
improving
the
discoverability
and
the
management
of
caps.
And
there
was
a
lot
of
work
already
done
previously
or
a
planning
work
done.
D
Inc
I
am
one
of
the
chairs
of
SiC
contributor
experience.
A
current
release
lead
shadow
for
our
enhancements,
lead
and
I
sort
of
have
been
iteratively
working
on
improving
enhancements
on
mostly
the
tracking
machines
from
the
other
stuff
for
a
bit
now,
and
this
all
sort
of
just
seems
the
lots
of
inclusion
of
a
lot
of
those.
Those
efforts.
E
Jeremy
record
I
am
also
currently
release
lead
shadow
and
previously
led
the
enhancements
sub
team
for
the
release.
Team
I
feel,
like
I,
think
my
experience
has
made
me
really
interested
in
making
the
cat
process
a
little
bit
better
and
a
little
bit
more
discoverable,
like
John
mentioned,
having
gone
through
a
couple
of
cycles.
Doing
like
enhancements
tracking
for
the
releases
I
definitely
feel
like
there's
a
areas
where
we
can
make
things
better,
make
it
easier
for
people
to
find
things,
have
a
better
understanding
of.
E
What's
gonna
be
in
the
release,
it's
not
going
to
be
in
the
release
and
just
have
a
little
bit
more
automation
and
like
official
buy-in
around
things
rather
than
shreya
Jean
through
github
comments
on
issues,
so
I'm
pretty
excited
to
see
what
we
can
do
inside
of
the
project,
particularly
interested
in
seeing
what
kind
of
tooling
we
can
build.
I
like
to
build
to
lane
to
make
experience
better
for
people.
C
Hi
everyone
so
I'm,
currently
leading
the
enhancements
team
of
the
1.19
release
cycle,
have
been
shadow
for
the
previous
two
release
cycles,
hundred
one
seven
and
1.18.
Apart
from
that,
I
helped
in
maintaining
the
kubernetes
Python
client
yeah,
so
here
to
help
out
with
any
enhancements
related
to
link
change
process.
Since
there
are
a
lot
of
ways,
we
can
improve
things,
making
it
a
better
experience
for
the
tape
authors,
people
who
have
to
manage
the
tips
and
so
on.
Yeah
yeah
thanks
everyone
for
initiating
this
sub
project.
A
C
A
Never
and
so
I
I
guess
I'll
go
last.
My
name
is
Steven.
Augustus
I
am
I
get
around
the
community.
I
am
a
former
features
lead
before
we
started,
calling
these
things
enhancements
for
the
previous
release
team,
one
of
the
emeritus
sig
p.m.
chairs,
as
well
as
one
of
the
sig
release
chairs.
So
my
focus
for
quite
a
while
has
been
in
and
around
caps
I
think
that
the
way
that
keps
dovetail
with
the
other
way
that
enhancements
dovetail
with
the
release
process
with
cig
architecture.
A
The
overall
state
of
the
world
for
the
project
is
extremely
important,
because
this
is
kind
of
the
ingress
point
to
the
release
cycle.
I
think
that
it's
important
that
we
get
this
right,
we've
had
you
know,
as
Bob
mentioned,
we've
had
difficulties
with
the
the
tracking
spreadsheets
in
the
past.
This
is
one
of
the
first
things
that
I
remember
talking
with
Igor
about
when
I
was
shadowing
and
saying
we
need
to
burn
the
sheet
to
the
ground
like
seriously
like
this
needs
to
not
exist.
A
We
need
to
to
service
service
portions
of
the
release
process
with
automation,
defining
getting
the
right
people
in
place.
Defining
the
right
process
for
doing
these
things
and
then
building
tooling
around
that
and
and
ultimately
that
is
not-
that
is
not
a
spreadsheet,
so
I'm
excited
to
see
the
the
journey
that
were
on
right
now,
for
those
that
are
familiar
been
championing
the
the
kept
process
for
for
quite
some
time
in
insig
p.m.
we,
we
initially
spun
features
and
and
what
they
were
called
features
at
the
time.
A
The
repo
out
from
sega
architecture
over
to
cig
PM
carried
it
in
cig
p.m.
for
a
while
retired
sig
PM
more
recently
transferred
that
sub
project,
now
known
as
enhancements
back
to
sig
architecture,
put
together
a
bunch
of
really
awesome
people
in
the
same
room.
So
as
sub
project
owners,
it's
myself,
Bob,
Jeremy
and
John.
So
I
think
we
have
a
wealth
of
knowledge
across
multiple
release
cycles.
A
Some
some
a
lot
of
lessons
about
what
not
to
do
when,
when
learning
how
to
build,
maintain
review,
approve,
keps
I
think
that
overall,
that's
going
to
lead
to
some
some
nice
net
improvements
as
we
move
through
the
sub-project.
So
this
is
I
think
you
know
I.
Think
we've
got
a
group
with
us
on
the
on
the
call
today
that
is
kind
of
the
I
guess.
This
is
the
core
group.
The
core
group
of
previous
enhancements
leads
as
well
as
sub
project
owners
and
and
the
current
enhancements
lead.
So
you
know
moving
moving
forward.
A
A
The
the
answer
is
that
there
is
no
answer
the
we
have
never
been
able
to
a
list
elicit
a
concrete
kubernetes
roadmap
across
release
cycles,
and
it's
something
that
sort
of
manifests
itself
as
the
cycle.
As
the
cycle
happens
right,
you
know.
So,
as
we
do
enhancement
collection,
we
get
an
idea,
so
enhancement
collection
is
one
of
the
first
parts
of
the
release
cycle.
It's
essentially
and
just
providing
some
context
for
people
who
are
not
familiar
with
the
release.
Team
are
some
of
the
process.
A
We
establish
a
release
team
on
the
cig
release
side.
The
release
team
is
composed
of
a
bunch
of
different
roles.
One
of
the
roles
is
the
enhancement
sub
team
and
the
enhancement
sub
team
is
responsible
for
collating
the
enhancements,
as
well
as
kind
of
essentially
cat
herding,
the
enhancement
owners
for
for
the
cycle,
making
sure
that
those
enhancements
stay
up
to
date.
A
Instead
of
features,
features
are
and
I
think
it
think
this
distinction
that
we
made
a
while
back
now
was
important,
so
features
are
units
of
work
that
can
be
executed
within
the
scope
of
one
release
cycle
right.
So
just
that's.
That's
the
definition
right
features,
units
of
work
that
can
be
executed
within
one
ready
cycle
enhancements,
are
essentially
proposals.
Larger
changes
to
the
overall
they
can
be
processed
changes.
They
can
also
be
code.
Changes
right,
so
enhancements
are
larger
efforts
of
work.
They
may
be
composed
composed
of
multiple
features.
A
So
the
primary
way
that
we
we
do,
some
of
this
tracking
is,
is
through
a
through
a
document
called
a
cap
right.
A
cap
is
kubernetes
enhancement.
Proposal
caps
are
inspired.
You
know
from
a
variety
of
places,
design
proposals
overall,
if
you've
seen
the
previous
design
proposals
that
we
we
had
in
the
kubernetes
community
repo,
it's
partially
inspired
from
that
it's
partially
inspired
from
the
rust
RFC's,
partially
inspired
by
the
pipe
python
peps.
A
So
this
is
kind
of
like
a
accumulation
of
knowledge
acquired
from
multiple
places
and
I
think
that
we've
we've
somewhat
made
the
process
our
own.
It's
been
very
interesting
to
see,
see
the
adoption
across
multiple
places.
You
know
we
have
we
kind
of
have
the
some
sub
projects
that
have
adopted
this.
So
if
you
look
at
the
the
caps
KitKat
cap,
yeah
CAE
pees
right,
those
are
the
cluster
enhancement
proposals
right,
so
they
they
use
a
lighter
weight
version
of
the
cups
to
track
some
of
their
features.
We
have
internally.
A
So
caps
are
Kudo,
Kudo,
builder
enhancement,
proposals
for
their
projects
and
and
Bob
is
saying
that
Red
Hat
also
uses
this
to
some
some
extent,
so
I
think
that
it's
I
think
that
it's
it's
a
process
that
has
had
a
lot
of
influence
and
in
the
community
across
the
last
few
years.
It's
something
that
we're
consistently
getting
better
at.
There
are
always
opportunities
for
improvement,
but
I
think
that
definitely
in
the
recent
days
we've
we've
laid
the
groundwork
for
some
really
cool
things.
A
Moving
forward,
we've
started
to
bring
in
so
to
chuck
worked
on
a
validation
tool.
He
worked
on
a
a
command-line
tool
to
search
caps,
which
became
part
of
that
became
the
library
that
we
use
now
for
validation
within
the
K
enhancements
repo
and
we're
also
building
tooling
around
that
to
do
validation
of
the
metadata
templates
that
have
for
keps
and
that
will
eventually
evolve
into
doing
validation
for
the
website
that
we
produce
or
the
various
reports
that
we
generate.
A
A
The
interesting
interesting
points
about
the
process,
like
the
production,
readiness
reviews,
that's
the
hope,
with
the
production
readiness
reviews
is
that
we
become
more
confident
in
the
in
the
enhancements
that
we're
producing
across
release
cycles
and
how
they
may
be
leveraged
in
production
environments
right
so
bringing
bringing
the
knowledge
base
of
the
various
operators
and
maintained
errs
in
the
community
to
essentially
vet.
These
enhancements
saying
you
know
our-
is
this
something
that
can
be
well
observed
right.
What
are
the
failure
states
for
for
this
type
of
enhancement?
A
B
A
It's
very
interesting
to
see
how
a
enhancement
behavior
behaves
over
a
few
node
cluster
versus
a
five
5,000
node
cluster,
and
you
know
the
the
scalability
stuff
gets
interesting
too,
because
there
is,
there
is
a
need
for
us,
as
community
members,
to
be
able
to
provide,
in
some
ways
the
the
infrastructure
to
be
able
to
make
sure
that
we
can
test
against
these
enhancements.
So
it's
it's
not
easy
for
anyone
to
just
spin
up
a
5,000
10,000
node
cluster.
So,
if
we're
going
to
so,
if
we
review
things
for
scalability,
we
also
have
to.
A
We
also
have
to
have
the
means
to
to
allow
people
to
test
against
those
assumptions.
Are
so
a
lot
going
on?
I
think
that's!
That
was
some
of
the
background.
There
is
way
more
that
I
could
honestly
talk
hours
so
that
I
won't
do,
but
I
want
to
draw
some
of
the
division
overall,
and
this
is
vision
that
I've
had
from
from
sig
p.m.
days
earlier
in
cig
release
days.
I
want
us
to
get
to
the
point
where
we
can
elicit
a
project
roadmap
right,
and
this
only
comes
from
you
know.
A
This
is,
this
is
not
an
enhancements
problem.
This
is
not
a
release
team
problem.
This
is
not
a
architecture
problem.
This
is
a
community-wide
problem
that
our
reviewers
and
approvers
are
overburdened.
They
are
they're
involved
in
a
variety
of
different
places
and
they're,
often
one
of
a
few
people
that
can
do
the
thing
that
they
do
and
approve
the
thing
that
they
can
improve.
So
we
need
to
find
ways-
and
this
is
not
just
within
this
sub
project.
This
is
all
across
the
community.
A
We
need
to
find
ways
to
defray
the
burden
from
reviewers
and
approvers
right
so
that
they
can
focus
so
we
can
have
more
contributors
focusing
on
tactical
and
we
can
have
more
reviewers
and
approvers.
Focusing
on
strategic
goals
for
the
community,
and
part
of
that
is,
is
listing
the
project
roadmap
right
this.
A
The
reason
I
mention
reason
I
mentioned
oversubscription
is,
if
you
have
more
time
to
focus
on
strategy,
you
have
more
time
to
think
about
what
your
sig
wants
to
do
over
the
next
few
cycles,
which
means
you
have
more
time
to
report
out
what
your
sig
wants
to
do
over
multiple
cycles,
which
means
people
like
enhancements
and
the
release,
release
team
and
sig
release
and
sake.
Architecture
have
more
time
to
aggregate
what
your
sig,
what
you're
saying
and
what
multiple
SIG's
might
be
doing
over
multiple
cycles.
A
We
also
want
to
put
it
together
in
a
way
that
is,
that
is
not
prone
to
human
error
right,
so
so
deriving
deriving
this
information
from
automation,
right
and
and
part
of
the
way
that
we're
planning
on
doing
that
is
is
using
the
metadata
within
caps
to
get
that
done
right.
So
there
is
a
field:
are
there
a
few
fields
that
we
recently
added
to
caps?
A
So,
with
this
data
we
can
even
even
if
it's
not
perfect,
it's
more
than
we
would
have
had
before,
and
that's
the
kind
of
data
that
we
can
start
to
aggregate
into
well
here.
Here's
everything
that's
planned
for
alpha
during
this
time
frame.
Here's
everything
that's
planned
for
beta,
so
on
and
so
forth,
and
this
is
essentially
the
work
that
the
the
enhancements
sub
team
of
the
release
team
does
rate,
but
they
do
it
manually.
So
we
want
to
move
away
from
that
that
manual
phase
and
move
into
something.
A
That's
more
automated,
multiple
panes
of
glass
there
will
be
I
know
we
like
to
say
single
pane
of
glass,
but
there'd
be
most
multiple
viewing
points
for
keps,
whether
you
want
to
analyze
them
from
the
command
line,
whether
you
want
to
analyze
them
just
by
sorting
through
the
repo,
whether
you
want
to
view
them
on
a
website
that
will
be
eventually
possible
as
well
so
and
and
all
of
that
stuff
is,
is
rooted
in
in
in
the
the
metadata
and
and
validation
of
the
metadata.
That
is
within
the
the
que
enhancements
Revo.
F
A
A
A
A
For
our
the
various
enhancements
and
then
also
field
to
provide
an
opportunity
to
you
talk
about
user
experiences.
So
if
you've
seen
like
again
going
back
to
the
the
Python
peps,
the
the
rust
rfcs
as
well
as
the
go
experience
reports,
those
will
give
you
some
nice
ideas
about
how
how
we
report
back
the
information
that
users
are
gaining
from
our
experiences
with
those
enhancements.
A
I
think
it's
important
to
deliver
a
stronger
feedback
loop
between
the
users
who
who
are
utilizing
the
enhancements,
as
well
as
the
people
who
are
building
them
so
that
we
can.
We
can
ensure
that
over
over
multiple
phases,
we
can.
We
have
a
better
idea
of
how
we
should
be
building
for
our
consumers
right.
So
I
definitely
think
that
that
is
a
part
that
we're
not
focusing
on
as
much
as
I
would
like
to
okay
all
right,
but
that
is
I.
Think
I.
Think
I've
talked
out
vision
for
a
little
bit.
C
A
Next
up
on
the
agenda,
we
have,
we
have
some
work
done
by
various
PM's
that
are
newer
to
the
project.
What
we
wanted
to
do
was
kind
of
get
an
opportunity
to
take
the
to
have
some
beginner
eyes
on
the
process
and
Laurie
Apple,
who
is
a
program
manager
for
cig
release,
has
has
kind
of
corralled
a
bunch
of
product
and
program
managers
to
take
a
look
at
the
the
kept
process
and
there's
a
there's,
a
doc
linked.
A
A
Okay
right
so
I
was
referring
to
yes,
this
kept
process
review,
so
they
met
earlier
in
June
and
I
think
they
might
have
had
I
believe
they
might
have
had
one
or
two
meetings.
But
user
stories
John
to
your
point,
was
one
of
the
things
that
they
talked
about
finding
out.
What's
value
we're
adding
to
the
cat
process,
some
of
the
chatter
about
the
caps
needs
to
be,
maybe
they
need
to
be
smaller,
easier
to
consume.
A
The
I
think
that
one
of
the
goals
for
this
sub
project
in
general
is
as
well
as
to
accelerate
merge
velocity
for
keps
I.
Don't
think
that
we
should
be
responsible
for
the
content,
the
technical
content,
specifically
of
of
an
enhancement
but
I
do
believe
that
we
should
find
ways
to
make
sure
that
we're
essentially
greasing
greasing
the
wheels
and
making
sure
it's
possible
to
merge
these
things
when
they're
ready
to
get
merged.
So
there
are
at
any
one
point.
You
know
there.
A
Right
now
we
have
207
open
issues,
so
these
are
actively
tracts,
they
may
be
enhancement
related
issues
or
they
may
be
kept
smo
STUV.
These
are
kept
enhancement
tracking
issues
and
then
we
have
127
open,
pull
requests
right,
so
some
of
these
are
specifically
related
to
the
enhancement,
sub
project
and-
and
some
of
them
are
specifically
enhancements-
are
specifically
enhancements
right,
so
caps
and
you
can
see
if
we
were
to,
let's
sort
by
oldest
right,
we've
got
stuff,
that's
been
open
since
December,
2018,
right
and
I'm.
A
You
know
this
is
this
goes
back
to
the
point
of
this.
Is
we
need
to
make
it
easier
for
reviewers
and
approvers
to
do
their
thing?
This
is
not
just
again.
This
is
not
just
an
enhancement.
Sub-Project
thing.
This
is
a
community-wide
problem
of
reviewers
and
approvers
being
oversubscribed
in
multiple
areas.
A
A
Automation
can
help
with
that
better
process
can
help
with
that.
The
right
people
in
the
right
places
can
help
with
that
the
sig
sig
reliefs
were
kind
of
testing
something
out
right
now,
so
we're
I
think
we're
the
first
sig
within
the
community
to
establish
a
program
manager
role.
The
idea
behind
that
will
Lori
Apple
she's
doing
a
great
job
right
now
of
kind
of
analyzing.
A
What
sig
release
does
day
to
day
she
started
within
the
release
team,
since
that's
kind
of
like
the
ingress
point
for
a
lot
of
people's
interactions
with
sig
release
across
bug,
triage
CI
signal,
the
enhancement
sub-project
so
on
and
so
forth,
and
trying
to
analyze
ways
to
make
us
better
right.
I
felt
that
if
some
work
was
started
there,
it
would
kind
of
reverberate
throughout
multiple
areas.
Since
we
touch
multiple
areas
in
the
community,
and
that
was
the
the
production
of
the
stock
was
was
part
of
that.
A
So
Lori
got
together
with
a
few
pxm
folks
and
and
started
looking
at
the
enhancements
rivo
and
just
tearing
it
apart
honestly
suggesting
some
improvements
for
us
to
make.
You
know
definitely
the
user
stories
I
think.
That's
a
big
piece
that
John
had
mentioned
earlier,
talking
about
best
practices
and
improving
the
user
experience
overall
for
for
keps,
and
then
we
can
see
that
there
are
a
lot
of
open
questions
around
the
process,
so
sub-project
owners
I
would
like
you
to
take
some
time
to
comment
up
the
stock.
So
we
can.
A
E
Team
just
ask
questions
and
gathered
feedback,
so
inside
of
that
document
it
lays
out
a
couple
of
high-level
user
stories,
so
things
around
like
I'm
a
kept
author
I
want
to
create
a
new
camp.
How
can
tooling
help
me
do
that
same
thing
around
validation
and
then
some
some
thinking
around
what
a
promotion
process
might
look
like.
E
So,
instead
of
the
current
strategy,
where
we
go
into
the
issues-
and
we
comment
and
say
like
this-
is
going
to
be
in
the
1i
t,
no,
this
is
not
going
to
be
in
119
moving
to
a
more
formal
kind
of
ticketing
process
and
that's
laid
out
a
little
bit
inside
of
there.
So
caps
TTL
was
an
attempt
at
just
kind
of
pulling
on
the
threat
of
one
of
those
things
just
kind
of
automating
the
process
of
starting
okay.
So
we
have
the
kept
metadata
template
and
the
readme
template.
E
How
can
we
take
those
things
and
turn
some
little
automation
into
that?
How
can
we,
you
know,
create
this?
The
scaffolding
for
somebody
just
start
working
on
one
of
those
things,
and
then
how
can
we
also
you
know
validate
the
pieces?
Are
there
before
somebody
submits
in
them
are
kind
of
building
on
the
cap.
The
cap
Val
tool.
E
That's
there,
so
it's
written
in
Cobra
or
it's
in
go
using
Cobra
the
CLI
framework
and
I
think
we're
at
the
point
now
where
we've
got
like
that
basic
functionality
and
I
think
it
would
be
good
to
for
everybody
to
review
this
document
that
Lauri's
put
together
and
comment
on
it.
If
you
haven't
already
I,
think
I
saw
some
comments
from
Bob
in
there
and
then
I
think
it
would
be
good
for
us
to
build
the
work
like
a
road
map
out
just
to
think
about
what
process
changes.
E
Do
we
need
to
put
in
place
and
then
what
tooling
the
things
we
add
to
that
tool
to
in
for
to
help
those
those
process
changes
along
I
think
we.
We
have
a
fairly
good
idea
about
like
what
the
process
looks
like
for
creating
a
kept,
validate
and
kept,
but
I
think
we
should
spend
some
time
kind
of
fleshing
out
what
the
ticketing
system
looks
like.
What
does
it
look
like
when
we
want
to
specifically
promote
something
from
like
alpha
to
beta
in
certain
release?
E
D
A
I'll
layer,
some
some
history
on
this,
so
I
think
it's
important
to
note
that
we
had
this
Jeremy
and
and
Bob
came
to
me
with
this
idea
of
kept
CTL
and
and
I
said.
This
is
something
I
presented
in
cube
con
like
to
cube
cons
ago
like
like
so
the
idea
for
four
kept
CTL
was
initially
Calif
miles
is
and
as
well
as
the
idea
for
the
ticketing
system.
So
I
had
spoken
to
Laurie
about
this.
A
Essentially
what
this
ticketing
system
would
look
like,
we
were
on
a
sig
Friday
on
official
unofficial,
cube
friends,
hang
call
and
started
chatting
with
Laurie,
as
well
as
Paris
about
about
kept
tooling
overall
and
and
in
the
ticketing
system.
The
idea
for
the
the
ticketing
system
is
essentially
to
remove
the
need
for
enhancement
issues
for
the
back
and
forth,
the
back
and
forth
interaction
between
the
release,
release
teams,
enhancement,
sub
team
and
enhancement
owners
overall.
So
talking
so,
you
can
skip
the
doc.
A
If
you
want
to
talking
a
little
bit
about
how
the
the
receipts
the
system
would
work.
Essentially,
we
have
buckets
very
similar
to
the
way
that
we
handle
the
releases
within
the
cave.
Cig,
release
repo
right
now.
Essentially,
when
we
have
a
new
release,
we
create
a
new
bucket
for
that
release.
So
119
is
the
current
one
and
within
within
that
subdirectory
contains
a
listing
of
the
of
the
milestones
for
that
release,
the
exceptions
that
might
be
contained
within
that
release
the
the
release
team
assigned
for
that
release
and
so
on.
A
There
would
be
releases
119,
120,
what-have-you
and
within
each
of
those
sub
directories
would
be
accepted
proposed
and
maybe
one
other
one
other
folder-
that
I
haven't
thought
of
yet,
but
the
proposed
when,
as
an
enhancements
owner
when
you
are
interested
in
proposing
an
enhancement
to
the
release
cycle,
you
would
submit
a
ticket
write,
a
PR
in
the
form
of
a
ticket
which
it
would
be
a
small
piece
of
yam.
Oh,
that
would
be
hey.
This
is
this:
is
the
enhancement
we're
talking
about?
A
A
Those
those
enhancements
would
live
in
that
proposed
PR
for
a
little
bit
at
which
point
closer
to
the
enhancements.
Freeze,
those
PRS
would
get
merged
right.
Those
piers
would
get
merged
as
proposed
and
once
enhancements
freeze
hits.
Some
piece
of
automation
would
come
over
and
move
move
things
from
the
proposed
bucket
into
the
accepted
bucket
right.
So
now
we
have
an
accepted
list
of
all
of
the
enhancements
that
we
intend
to
commit
to
for
the
cycle
right.
A
That's
something
again,
that's
something
that
we
can
start
building
roadmap
of
off
of
right,
this
sort
of
obviates
the
entire
need
for
the
release
sheet,
the
the
enhancements
tracking
sheet
at
the
beginning
of
the
cycle,
because
it
becomes
PRS.
There
is
no
chatter
back
and
forth
between
sub-team
and
the
enhancements
owners.
It's
just.
We
want
to
commit
someone
from
the
the
enhancement.
Sub
team
approves
the
pr
it
goes
in.
We
call
it
a
day.
Automation
moves
from
proposed
to
accepted
anything
passed
the
enhancements
freeze,
it's
no
longer
a
question.
A
If
it
should
be
proposed
for
exception,
we
know
that,
because
it's
not
it's
not
in
the
accepted
bucket,
that
it
is
an
exception
right,
and
that
makes
it
easier
to
think
about
exceptions
and
think
about
exception
approval.
If
it's,
if
it's
something
that
needs
to
be
approved
as
an
exception,
that
becomes
a
PR
right.
That
becomes
a
discussion
on
a
PR
and
emerge
from
a
release.
Team
lead,
sub
team
enhancements,
sub
team
member.
A
What
have
you-
and
that
makes
it
a
little
easier
to
track,
there's
no
longer
a
matter
of
tracking
exceptions
in
a
separate
place,
not
utilizing
that
yeah
mole
file
that
we
track
exceptions
in
and
having,
and
and
maybe
not
losing.
The
discussion
about
an
exception
within
mailing
list
thread
right
as
a
PR.
It's
very
clear
about
what
the
intent
is
right
and
whether
or
not
it
gets
accepted
is
whether
or
not
the
PR
merges
where.
B
Even
as
part
of
this
process,
one
thing
I
think
that
would
be
helpful.
What
are
the
other
things?
The
enhancement
team
does
rate?
Is
it's?
It's
pinging
all
of
the
the
people
to
say
hey
validating,
say,
they've
done
the
test.
Klan
they've
done
the
of
the
PR
questions
like.
If
we
can
validate
any
of
this
automatically.
You
know
again
trying
to
reduce
soil
for
the
that
team,
and
then
you
could
have
a
you
know.
Your
your
CI
can
say
this
is
ready
to
promote
or
not
into
the
accepted
rocket.
B
D
A
A
Mark
and
I
think
that
you
know
with
the
test
plan
it's
important
to
like.
We
have
fuzzy
borders
around
some
of
these
things
that
we
request,
so
you
know
making
it
making
it
yeah
Mille,
making
it
like
yet
another
llamo
file,
but
making
it
yeah
while
making
it
something
that
we
can
validate,
makes
it
very
concrete
to
someone
using
updating
a
cap
right.
A
If
your
PR
gets
blocked
on
a
pre
submit,
there
will
be
reasons
why
it
gets
blocked
on
the
pre
submit
and
it'll
usually
be
related
to
something
being
off
with
the
cap
metadata
right.
So
we're
we've
been
adding
more
and
more
of
those
validations
across
the
last
cycle
and
change
and
I
think
that
we're
I
think
we're
at
a
baseline
point
right
now.
It
has
a
few
expectations
of
you
that
the
cap
is
named.
It's
numbered
it's!
You
know
it
has
a
working
link
to
an
enhancement
tracking
issue
that
it
has
a
latest
milestone.
A
So
we
want
to
essentially
make
it
impossible
for
people
to
to
file
bad
caps
or
at
least
file
bad
metadata
for
caps,
so
so
little
by
little
we're
getting
through
an
improvement
of
the
of
the
the
cap
metadata
and
the
the
reason
that
we
we
put
so
much
focus
on
on
on
fixing
the
metadata
is
again.
We
want
to
make
it
one.
We
want
to
make
it
hard
for
people
to
use
incorrectly,
but
we
also
are
going
to
use
the
metadata
to
inform
the
other
ways
that
we
interact
with
caps
right.
A
So
if
you
take
caps
ETL
as
an
example
right,
we
want
to
make
sure
that
kept
CTL
does
the
thing
it's
supposed
to
do.
If
it's
create
a
cap,
if
it's
promote
a
cap,
it
needs
to
those
fields
need
to
be
correct
for
it
to
be
able
to
do
its
job,
and
the
second
part
of
that
is
the
website
right.
So
when
there
is
a
cap
website
which
we
should
move
on
soon,
the
kept
website
will
be
reading
everything
from
kept
metadata
right.
A
So
it's
important
that
again,
that's
that
stuff
is
correct
and
and
having
these
multiple
panes
of
glass
to
view
kept
s'en
will
one
be
easy
for
people
who
who
like
different
presentation,
mechanisms
for
processing
data
and
two?
It
will
allow
more
people
to
see
the
work
that
we're
doing
and
and
suggest
improvements.
So
I
think
we've
got
a
ton
of
information
here
about
how
we
can
improve
I.
E
So,
along
those
lines
and
tooling
wise
Laurie
said
that
she
had
a
few
people
reach
out
to
her
interested
in
contributing
to
some
of
that.
I
think
that
I
think
she
was
slightly
concerned
that
people
would
need
to
have
more
intimate
knowledge
of
the
enhancements
process,
but
I
think
we
can
probably
come
up
with
some
issues
and
prioritize
them
like
treat
it
like
a
real
project
and
have
enough
context
in
there
that
we
can
entice
some
new
contributors
to
come
and
work
on
some
of
that
stuff.
E
A
I
would
say,
as
a
first
step,
I
would
like
us
to
make
sure
that
we've
all
gone
through
these
notes,
as
well
as
the
process
review,
because
I
think
that
conversation
that
you
had
with
Laurie
came
from
a
conversation
that
I
had
with
Laurie,
which
was
essentially
I.
Don't
think
we
all
have
the
same
vision
about
what
the
kept
CTL
tool
needs
to
be
yet
so
I
think
we
should.
We
should
baseline
on
what
we
want
this
tool
to
be
because
it
doesn't
need
to
be
everything
and,
and
maybe
on
some
levels.
A
It
doesn't
need
to
exist
right.
The
initial
idea
for
the
tool
was
that
it
would
be
the
single
command-line
interface
that
you
could
use
to
create,
promote
process
caps,
right,
I,
think
from
the
promotion
standpoint.
Maybe
that's
not
as
valuable
for
the
tool
was
supposed
to
also
allow
you
to
be
able
to
review
caps.
So
as
a
reviewer
you
could
you
could
hit
kept
CTL
review
or
something
like
that,
and
it
would
add
your
it
would
add
your
name
as
a
slot
and
the
metadata.
A
That
said,
you
were
reviewing
and
process
your
changes
and
I'm,
not
sure
that
that
fits
nicely
into
a
github
workflow
that
it's
maybe
even
a
thing
that
we
would
want
to
build.
So
we
need
to
figure
out
what
we
do
and
don't
want
the
tool
to
do.
First
and
and
I
I
was
yeah.
I
was
telling
Laurie
that
I'm
afraid
of
bringing
people
in
to
work
on.
Just
like
hey,
go
work
on
this
feature
and
we're
like
we
don't
actually
need
the
feature.
A
F
F
There
is
one
point
of
view
that
says
the
fact
that
people
create
enhancements
and
go
through
that
process
means
there's
a
need
for
a
feature.
There's
another
point
of
view.
That
says:
maybe
the
fact
that
we
aren't
merging
that
many
of
these
indicates
that
the
SIG's
aren't
in
agreement
that
it's
a
feature
that
we
need,
and
it
is
socially
awkward
to
close
someone's
cap,
I
and
I.
Don't
I,
don't
think
I'm
the
only
one
that
feels
that
way.
F
A
lot
of
emotion
invested
by
the
cap
authors
because
it
does
take
them
fair
amount
of
time.
It
is
something
they
obviously
thought
was
important
and
a
reaction
of
yeah
we're
we're
not
gonna
get
to
this,
and
we
aren't
going
to
devote
our
review
time
to
merging
it
can
sometimes
be
hard
to
hear.
Is
there?
A
I
I
love
this
I
love
this,
because
I
think
that,
from
the
perspective
of
a
submitter
of
a
cap
right,
you've
also
got
you've
got
multiple
perspectives
in
like
assessing
a
cap
rate,
and,
and
one
of
them
is
maybe
we
don't
need
it,
because
something
like
it
already
exists
great
and
maybe
the
the
person
who's
writing.
The
cap
doesn't
have
the
context
to
know
that
that
thing
exists
already,
but
the
first
part
of
the
process
is
supposed
to
be
socialized.
A
This
idea,
with
a
sig
rate,
you're
supposed
to
get
a
pulse
on
whether
or
not
you're
kept,
is
a
good
idea
before
you
write
it.
So
so
I
would
advise
SIG's,
first
and
foremost
to
make
sure
that
one
their
contributors
know
that
they
can
do
that,
and
and
two
that
you
know
we
might
not
necessarily
be
reviewing
content
that
wasn't
pre-approved
in
in
you
know,
in
some
sort
of
discussion.
A
I
think
that
the
the
way
that
I
really
like
the
way
that
I'm
a
little
bit
more
loosey-goosey
with
my
meetings
but
I
like
the
way
that
architecture
handles
architecture
handles
their
meetings.
It's
it's
something.
The
topic
is
proposed
on
the
mailing
list-
great
and
it's
kind
of
like
okay,
let's
keep
discussing
this
before
it
ends
up
as
an
agenda
item
and
and
the
idea
is
kind
of
similar
with
the
cups
yeah.
B
If
you
have
I
could
say,
I
think
that
that
the
way
you
just
sensed
even
that
that
that
the
process
should
be
socialized,
firstly,
I
think
we
can
build
that
into
a
process
better
right,
so
that,
like
one
thing,
we
talked
about
I,
don't
know
a
while
back
on
some
PR
comment,
issue
I
think
David
put
the
issue
comment
in
it
was
like.
Maybe
we
need
to
assign
like
a
shepherd
to
any
given
cap
from
the
sink.
B
It's
one
of
the
sig
leads
or
tech
tech,
either
tech
we
emerge
in
some
Sun
bar
I,
don't
know
what
the
bar
is
with
like
we
can.
If
a
cap
comes
from
a
new
contributor
or
somebody
who
has
not
been
contributing
a
lot
like
it
like
I
said
earlier,
might
not
get
the
scrutiny
that
it
needs
early
enough
and
then
they
end
up
investing
a
lot
of
time.
So
if,
if
the
process
like
we
have
this
process,
github
doesn't
next
consider
that
itself
well.
B
If
we
can
build
the
tooling
or
even
the
documentation
of
the
process
of
first
just
send
this
out,
maybe
on
a
mailing
list
or
maybe
in
a
PR,
and
then
you
know
you,
you
have
to
use
that
to
get
somebody
on
in
the
cig.
Who
can
commit
the
resources
behind
to
the
review
and
approval
resources
to
it
to
you
know,
to
give
it
a
thumbs-up
before
you
get
to
the
next
stage.
That
could
avoid
a
lot
of
having
to
say
no
after
somebody's
invested
a
lot
of
time
in
a
so.
D
F
B
A
There
is
there's
kind
of
a
mechanism
that
we
have
for
this
already,
that
I
don't
see
a
lot
of
people
using,
and
that
goes.
That's
the
the
kept
statuses
right
you
can
merge
it
kept
without
approving
it
right
there.
So
there's
a
proposed
status.
There
also
deferred
statuses,
as
well
as
rejected
statuses,
right
I
have
I'm,
not
sure
I've
ever
seen.
A
rejected
kept
so
like
a
rejected
cap
should
be
still
committed
to
history.
I,
don't.
B
A
A
It's
okay,
to
merge
something
and
say
we're
not
going
to
do
this
right
and
flip
the
status
to
reject
did
write
for
the
sake
of
having
that
in
the
project
history
because
you
know
invariably,
a
year
later,
two
years
later,
maybe
just
a
cycle
later,
someone's
gonna
say:
hey
I
had
this
really
great
idea,
great
and
and
you'll
be
able
to
say
well,
we've
discussed
that
in
PR
yada
yada
yada
it's
in
this
cap.
They
are
some
of
the
drawbacks
that
we
we've
logged.
A
Because
of
that,
and
that's
the
reason
that
we
decided
not
to
go
in
that
direction
and
or
maybe
it's
something
that
provides
provides
context
for
a
future
discussion
about
how
to
build
that
enhancement
better,
but
without
it
merged
it
with
it
as
an
abandoned
PR.
We
don't
get
the
opportunity
to
do
that
right.
So
we
have
to,
we
do
have
to
get
people
more
okay
with
saying
no
I,
think
I,
think
saying
no
and
and
merging
something
as
rejected.