►
From YouTube: 20201027 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
october
27th.
This
is
the
bi-weekly
meeting
of
the
sig
architecture,
enhancement
sub
project.
This
is
a
meeting
that
will
be
recorded
and
available
later
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.
A
So
we've
got
a
few
things
on
the
agenda
and
I
see
that
lori
you
put
the
first
one
on.
B
I
think
I
put
them
all
on.
I
was
just
putting
a
lot
of
items,
so
what
I'm
doing
is
I'm
carrying
over
things
that
aren't
done
from
past
meetings
to
the
current
meeting
just
track
things.
We've
talked
about
things
we
said
we
would
do
so,
there's
part
of
that,
and
then
there's
also
just
wrapping
up
some
of
the
questions
that
we
put
in
slack
and
then
don't
get
to
because
everybody's
super
busy.
B
We
had
these
questions
from
last
time.
There
wasn't
any
note
that
we
resolved
them,
so
I've
brought
them
over
to
today.
There's
also
this
action
item
just
putting
it
here
too.
It
also
need
template
for
when
you're
requesting
enhancements
to
enhancements
process.
B
I
think
that
is
actually
part
of
this
item
above
right,
because
we're
talking
about
templates,
then
capturing
and
iterating
on
kepp's
template
feedback.
I
don't
think
we
have
any
discussion
here.
This
is
mainly
to
do
for
you,
stephen.
A
B
And
then
these
are
two
to
do's
for
jeremy
they're,
quite
small,
I'm
wondering
if
the
time
would
be
better
served
since
jeremy
is
doing
other
things.
If
somebody
else
could
take
them
over
they're,
just
really
small
type
of
fixes.
B
B
Oh,
thank
you
so
much
so
I
can
assign
it
to
you
or
you
can
assign
yourself
or
pull
jeremy
off
of
it.
A
B
A
B
Yeah
but
it's
the
other
issue
is
also
linked
to
there
and
you
can
take
a
look
and
decide.
E
B
And
yeah,
so
looking
at
the
second.
A
I
guess
I
can
do
some
investigation
yeah,
so
the
answer
is.
A
Yeah,
the
answer
is
the
first
step
that
you
should
be
doing
is
creating
an
enhancement
tracking
issue
right.
The
number
of
the
enhancement
tracking
issue
is
going
to
tell
you
what
that
four
ends
is
right
for
the
cap,
so
that
is
to
say
that
the
second
set
of
directions
is
correct.
A
A
A
Well,
kept
template
was
created
separately
from
the
kep0001,
so
basically
going
back
to
going
back
to
the
original
cap
and
saying
do
we
want
to
update
this
or
do
we
want
to?
I
think
what
we
initially
decided
to
do
is
just
call
it
implemented
and
move
on.
B
B
A
So
so
for
this
for
this
issue,
it's
it's
a
small
baby,
one
which
is
which
is
totally
fine
to
grab.
I
would
say
that
one
of
the
sub
project
owners
should
work
on
updating
the
cap.
B
A
The
big
yeah
and
after
this
issue
gets
resolved.
B
It's
okay,
it's!
Okay,
updating
the
template.
D
B
D
A
D
A
B
A
B
It's
cool
all
right,
but
that's
not
a
prerequisite
for
craig
to
do
the.
B
Then
then
I
was
going
to
move
to
this
item
to
spend
time
on
receipts,
maybe
last
just
updating
the
features
and
enhancements
repo
documentation.
So.
A
Yeah
this
was
this
was
the
work
that
we
had
decided
would
be
good
to
shard
to
interested
txms.
B
He
did
yeah,
so
I
will
just
ping
them
both
again
cool
and
I
think
we're
done
with
that
for
now.
Although
wait
one
question
the
glossary,
will
they?
They
won't
know
where
it
is
who
might
know
where
it
is.
A
Yeah
and
I
was
laughing
at
craig
craig
note-taking
and
he
was
like
actually
low-rate.
B
All
right,
so
I
guess
that's
resolved
then
so
then
it
just
leaves
receipts
process
check-in.
A
Yay,
oh
no,
so.
B
B
D
D
A
A
A
Is
a
release
directory
already
the
releases
directory
and
then
each
release
has
a
scoped
owner's
file
which
includes
enhancements,
lead
right.
E
A
B
E
D
A
E
A
Yeah
so
I
was
like
this
is
a
this:
is
an
information
architecture
exercise
really
because,
like
so
many
of
these
things
are
sig
release
related
like
when
you're
talking
about
release,
notes
and
the
enhancements
and
and
a
few
other
things
they
should
really
all
be
on
one
website
and
right
now,
people
are
essentially
building
websites
in
different
places
that
are
not
the
one
true
website
so
having
them.
If
we
said
that
that
release
website
was
supposed
to
be
the
just
the
sig
release
repo,
then
it
becomes
really
easy
to
just
have
them.
A
Have
the
receipts
also
in
the
sig
release,
rebound
right
the?
If
there's
going
to
be
an
enhancement,
swap,
I
think
it's
like
who
gets
the
website
for
who
does
the
website
first
right
because,
like
we,
we
want
to
do
an
enhancement
right.
We
could
say
we
could
have
two
websites
right
like
if
the
enhancements
one
is
aggregating,
everything
that
is
kept
metadata,
then
that's
one
website
right
and,
however,
you
want
to
slice
and
dice
that
metadata
can
give
you
what's
happening
for
the
current
release
right
and
the
release
website
could
potentially
contain.
A
So
the
plus
one
for
keeping
it
in
enhancements
is
also
that,
if
eventually
we
want
the
the
receipt
to
just
be
a
snippet
of
the
kept
metadata,
then
it's
a
lot
easier
to
do
whatever
information
munching,
whatever
this
kept
ctl
tool,
maybe
eventually
does
within
one
repo
right,
instead
of
checking
out
to
assuming
that
both
are
up
to
date
on
your
local
and
yada
yada
yada
right
so.
A
D
D
It's
what
we're
looking
at
okay.
So
so,
if
the
process
is
as
a
a
cap
as
a
sig,
I
go
and
update
the
metadata.
With
my
proposed
release
schedule
I
have
complete
authority
to
to
merge
that,
and
I
should
I
mean
there
needs
to
be
yeah,
because
it's
it's
I
mean
you
should
with.
A
A
Idea
so
there
are,
I
guess
there
are
a
few
ways
that
you
can
carve
it
up
like.
The
initial
idea
was
that
you
provide
this
hand
coupled
stub
right
that
goes
into
a
proposed
folder
right
eventually,
eventually,
we
run
some
tool
to
essentially
aggregate
all
those
stubs
put
it
into
metadata.yaml
within
the
top
level
of
that
release
right
so
that
that
is
one
flow.
The
what
you
suggested
is
could
eventually
be
possible,
but
we
may
not
want
to
go
down
that
route
because
it
puts
it
on
the
release
team
to
do
that.
A
D
Right
so
I'm
thinking
about
like
well,
that's
right,
hopefully
automated
right.
So
somebody
it's
it's
about
permissions
on
the
on
the
directories
and
like
I
guess
you
would,
I
guess,
or
it's
about
how
much
work
a
cap
author
has
to
do.
Does
a
cap
author
have
to
do
a
pr
in
enhancements
and
then
a
pr
in
release,
sig
release,
you
know
in
this
process.
They
would
do
they
would
do
their
enhancements,
they
would
merge
it.
D
A
Right
right,
so
so
the
the
reason
for
the
separate
folders
is
basically
a
allowing
us
to
put
different
pre-submit
checks
on
on
those
folders
right,
so
like
the
submitting
into
proposed
would
have
weaker
validation
than
something
that
loans
and
accepted
right,
so
the
so
and
right.
So
we
kind
of
talked
about
like
a
proposed
accepted
and
then
something
like
an
at
risk.
Exception,
z,
folder
right.
A
So
if
if
we
determine
that
your
receipt
is,
does
not
have
all
the
things
it
needs
to
to
have
to
actually
go
into
a
release,
then
it
gets
moved
to
at
risk
instead
of
accepted
right.
D
Right
and
the
the
thing
that
would
be
interesting
is
right.
Now,
that's
done
through
like
changing
a
value
on
a
spreadsheet,
and
can
we
automate
that
toil
away
and
then
having
them
in
a
proposed
folder?
Okay,
you
can
have
a
pre-submit
check
that
says
you
know
you
have
to
meet
these
criteria
and
then
you
can
propose
it
and
then,
in
order
to
get
actually
targeted
to
the
release
in
an
accepted
state,
you
have
a
separate
set
of
pre-submits
that
are
going
to
check
like
is
it
implementable
status?
Is
it
this?
A
And
and
yeah
and
and
the
idea
there
would
be-
the
propose
is
kind
of
like
lucy
goosey.
You
know
you're
going
to
do
this
for
the
release
for
sure.
Maybe
you
haven't
updated
the
cap,
yet
I
don't
know
right.
Maybe
the
cap
update
is
in
flight
right
and-
and
maybe
the
the
accepted
part
is
that
I'm
going
to
do
a
comparison
of
like
this
cap.
So
maybe
you
propose.
The
cap
that
is
in
you
know
is,
is
in
an
early
phase
right
and
it's
not
implementable.
A
Yet
right,
maybe
one
of
the
checks
that
moving
to
accepted
would
do
is,
is
look
at
the
cap.
Metadata
and
say:
is
the
status,
implementable
right
and
then
and
then
flag
it
right.
Your
your
cap
isn't
implementable
right.
So
that's
usually
a
discussion
that
an
enhancement
sub
team
member
has
with
a
you
know
with
with
a
sig,
and
you
know
that
and
instead
maybe
becomes
a
report
right.
The
following
things.
A
The
following
things
were:
were
you
know
our
plan
for
the
release
but
are
currently
at
risk,
for
you
know,
click
in
and
see
more
details
right.
So
that's
that's
a
potential
route.
I
think
I
think
it
makes
sense,
for
I
think
it
makes
sense
for
the
stuff
that
goes
into
accepted,
to
be
validated
against
the
actual
kept
metadata.
As.
A
What's
in
the
receipt
right
yeah,
so
so
craig
just
to
catch
you
up,
because
I
know
it's
been
a
while
since
you've
touched
specifically-
and
this
is
what
you're
hearing
is
wildly
different
from
what
we
were
doing
when
sig
pm
was
live,
so
the
receipts
process
is
basically,
I
think
we
had.
We
had
talked
about
some
of
this,
but
not
the
actual
implementation.
Details
is
a
process
by
which
we
would
essentially
you
know.
First
goal
is
to
eliminate
the
enhancements
tracking
spreadsheet
right.
A
So
so,
essentially,
the
receipt
is
a
commit
to
the
work
that
you're
going
to
do
for
the
release
right,
as
opposed
to
the
enhancement
sub
team
going
through
all
of
the
open
enhancements,
pinging
people,
one
by
one.
You
know
slowly
like
pulling
teeth
and
getting
the
data
out
of
them
and
then
updating
the
tracking
spreadsheet
and
doing
that
back
and
forth
throughout
the
release.
A
Right,
basically,
you
submit
a
receipt,
and
if
your
your
proposed
receipt
is
in
on
time,
then
it
is
moved
to
maybe
the
accepted
bucket
right,
assuming
it
has
all
the
correct
stuff,
the
validation
that
we're
talking
about
right
now,
if
it
doesn't
it's
in
an
at-risk
bucket,
and
it
gives
you
an
opportunity
to
figure
out
what's
at
risk,
why
is
that
risk
and
how
to
bring
it
back
into
accepted
that
you
know
eventually,
maybe
becomes
a
report
instead
of
a
sheet
right,
weekly
report
or
something
that
goes
out
and
says
like
hey
these
are
these
are
the
ones
that
are
in
the
release
right.
A
So,
instead
of
having
you
know,
anyone
from
the
enhancement
sub
team
have
to
do
this
work
right.
We
start
to
put
kind
of
automated
levers
around
it,
so
we're
just
kind
of
talking
through
what
those
need
to
look
like
what
the
first
steps
are.
D
So
I
would,
I
would
still
want
to
understand
better
what
those
pre-submits
look
like
with
respect
to
the
different
folders,
because
if
we
can
have
fewer
folders,
I
think
it's
simpler,
like
you
could
proposed,
could
just
come
out
of
peptide
yaml
and
then
what
you
know
if
it's
in
the
kept.yaml.
D
But
if
we
see
a
real
need,
I'm
just
I'm
not
sure
what
that
need
is.
As
far
as
I
see,
pre-submits
were
accepted,
are
there
pre-submits
for
proposed
and
and
what?
What
would
they
be
such
that
we
couldn't
do
it
off
of
just
the
kept.yaml?
Changing
the
targeted
release
for
a
stage.
A
D
A
D
D
B
So
here
sorry,
this
is
my
suggestion
is
that
I
don't
think
we're
going
to
build
the
perfect
system.
I
guess
if
we
have
too
many
steps
right
off
the
bat
that
can
turn
people
off
right
away
from
it,
but
that
said,
we
still
aren't
going
to
build
the
perfect
mvp
or
you
know
the
first
program.
A
A
About
is
so.
What
I
worry
about
is
adding
the
tool.
What
this
would
be
like
is
is
having
kept
ctl,
be
able
to
do
this
right.
What
I
worry
about
is
having
a
pre-submit
against
a
tool
that
is
not
complete
and
questioning,
because
I
would
question
like
if
I'm
working
on
something,
that's
not
related.
It's
enhancements
and
I've
wired
it
into
a
pre-submit
like
my
first
question
is
like
is
my
tool
broken
right
versus
the
question
for
them
should
be?
Did
I
submit
the
correct
information
right?
A
Not
whether
or
not
they
shouldn't
have
to
care
about
the
tool?
That's
that's
doing
the
pre-submit
right.
So
so
that's
one
of
my
worries
that
we
we
produce
an
ineffectual
tool
and
turn
on
pre-submits
for
this
accepted
bucket
right,
the,
but
I
get
what
you're
saying
I
totally
get.
What
you're
saying.
Ideally
it
is.
It
is
two
buckets
right:
it's
essentially
like
at
risk
and
and
accepted
right,
and
you
know
and
your
proposal
your
proposal
is
your
pr
you're.
A
Absolutely
right
right
right,
you
you,
don't
you
don't
get
to
merge
until
you
know
until
that
happens,
and
then
you
know
the
question
becomes.
Is
there
a
reason
for
an
at-risk
bucket.
A
You
know,
maybe
there
doesn't
need
to
be
a
set
of
buckets
at
all
right.
Maybe
it's
just
the
the
the
120
right
you're
in
or
out
or
or
it
can
be
like
you
know,
receipts
are
releases,
slash,
120,
slash,
receipts
right
and,
and
you
drop
everything
into
that
bucket
and
if
it
you
know,
if
it
merges
to
the
bucket,
then
it
emerges,
then
it
would
have
enough
data
and.
D
That's
that's
accepted,
so
one
other
question,
then,
is
one
of
the
things
the
release
team,
the
other
three
enhancement
team
does
is,
is
is
there's
one
is.
This
is
all
what
we're
talking
about
is
sort
of
before
enhancements,
freeze
or
just
after
with
exceptions,
then
there's
the
actual
throughout
the
rest
of
the
release.
There's
like
hey
what
prs
are
associated
with
this?
D
I
guess
that's
still
for
now
manual
is
that
is
that
how
does
that
fit
into
this
tooling?
Updated
process.
A
Yeah,
so
that
was
kind
of
one
of
the
ideas
around
around
having
the
accepted
bucket
right,
where
maybe
one
of
the
validations
is
whether
or
not
you
have
a
docs
pr
attached
to
your
to
your
cap
for
that
milestone,
but
figuring
out
how
we.
A
Metadata
because,
like
this
is
all
stuff
that
should
really
be
in
the
implementation
history
of
the
cap-
and
I
you
know
if
you've
you've
read
multiple
caps
at
this
point,
and
you
know
that
you
know
implementation.
History
is
never
like
really
well
structured
right.
E
D
Like
like,
there's
docs
kept,
they
usually
usually
like
they'll,
be
later
in
the
cycle
like
after
a
lot
of
development's
done,
there's
like
we
needed
the
docs
placeholder
pr,
but
that
that's
different
than
accepted
early
accepted
to
be
worked
on
at
enhancements.
Freeze
time
that
comes
much
later
and
also,
of
course,
writing.
The
actual
code
comes
later
than
enhancements.
Freeze
and
the
enhancements
team
currently
tracks.
All
of
that
stuff
too,
and
so.
A
They
track
the
ish
right,
so
you
know
that's
for
the
for
the
code,
part,
it's
kind
of
split
between
you
know,
enhancements
and
kind
of
bug,
triage
bug,
triage
is
less
bug
triage
and
more.
You
know
issue
triage
issue,
pr
triage
right
for
anything,
that's
targeted
for
the
release
right
and
then
from
the
docs
perspective.
That's
the
docs
team.
The
docs
team
is
usually
the
one
doing
the
tracking.
A
A
D
A
I
think
I
think
our
first
goal
is
to
decrease
the
amount
of
time
that
it
takes
for
time
and
toil
that
it
takes
for
people
to
get
things
done
right
at
the
beginning
of
the
cycle
right
if
you
can
like,
if
we
can,
if
we
can
minimize
the
toil
like
between
the
beginning
of
the
cycle
and
enhancements
freeze,
then
we've
done
a
lot
of
work
there,
yeah
and
and
and
if
we're
saying
that
the
rest
of
the
cycle
is
manual,
interaction
with
people,
I
think
that's
probably
fine.
For
now.
D
Do
we
in
our
pr
template?
I
don't
think
we
do.
We
ask
right
now
what
feature
issue
the
pr
is
for
I
mean
I
know
years
ago
before
I
was
even
involved.
There
was
like,
if
you're
going,
to
submit
a
pr,
you
need
an
issue
associated
with
it,
and
people
just
created
issues
and
then
pardon
my
language
and
then
you
know
like
to
just
like
cover
their
butts,
so
I
don't
want
to
necessarily
push
people
towards
that.
D
A
So
what
we
so
what
we
did
as
of
a
few
days
ago,
maybe
yesterday
I
merged
it
or
something
there
were
some
updates
to
the
so
that,
like
what
you're
describing
is
what
the
enhancement
issue
is
supposed
to
be
right.
Before
anything
happens,
you
create
the
enhancement
issue
and
the
enhancement.
E
A
Gives
you
the
number
that
you
use
for
the
cap
right
the
so
what
we
added
to
the
template
was
basically
the
each
of
the
each
of
the
phases
or
stages
are
now
basically
sub
sub
bullets.
Right,
one
is
looking
for
your.
You
know
your
kkpr,
the
you
know.
Next
is
looking
for
your
your
docs
pr
and
then
and
then
making
sure
that
you
have
an
enhancements.
D
Should
I
be
putting
in
my
description,
a
link
back
to
that
feature
issue,
and
if
we
did
that,
then
I
could
have
a
tool
that
can
say.
Oh
this
feature
needs
these
pr's
to
merge
in
order
to
be
part
of
this
release,.
A
A
What
we
could
eventually
do
is
if
those
sections
are
being
filled
out
to
scrape
that
and
try
to
like
map
do
some
some
mapping
there,
but
that
is,
I
think,
orders
of
magnitude
harder
than
what
we're
trying
to
do
right
now,
yeah
and-
and
it's
also
going
to
come
down
to
like
if
you
are
working
on
some
subsection
of
an
enhancement
and
you're
not
really
connected
to
the
sig
and
you're
just
churning
out
code,
then
you
don't
know
to
do
this
thing
right.
A
Yeah
so
like,
I
don't
think
that
we
can
solve
for
that
without
creating
some
additional
friction
and
merging
in
kkk.
D
A
As
as
an
enhanced,
you
know
as
an
enhancement
as
an
enhancement
owner
right,
you
were
essentially
the
you're
supposed
to
be
the
the
project
manager
percent
for
that
enhancement
right,
so
you
should
be
taking.
You
should
be
making
it
easy
for
everyone
who
is
looking
at
that
thing
and
taking
the
prs
that
get
merged
and
putting
them
in
the
implementation.
History
like
that
was
literally
the
point
of
that
section.
A
B
F
A
To
do
if
something
it
if
something
in
the
workflow,
like
I
you
know
perfect,
is
the
enemy
of
good
yada
yada
right
like
if
something
in
the
workflow
proves
to
us
that
this
should
be
elsewhere,
then
we'll
consider
it
at
that
point,
but
I
think
right.
B
B
Okay
and
then
this
is
the
reason
why
and
then
so
confirmed
this
repo,
so
that
question
is
resolved
and
then
there
was
the
question
of
the
folder
structure.
B
A
So
so
I
feel
that
we
yeah,
so
we
we
talked
about
this
a
little
bit.
The
the
pr
was
another
piece
of
this
right.
B
A
Exactly
the
prs.
A
Right,
so
we
don't
necessarily
we
want
people
to
like.
I.
I
do
want
to
make
it
easy
for
people
to
commit
to
to
say
you
know
to
doing
something
right.
If
the
stage
is
off
right
like
bringing
something
into
accepted,
would
basically
like
if
the
stage
is
off
or
they're
they're
it's
being
promoted,
then
it
might
require,
or
probably
will
require
a
pr
review
right.
Is
that
metadata
filled
out
right?
That's
the
kind
of
thing
that
the
additional
validation
would
do
going
into
that
accepted
bucket.
So
so
what
I?
A
B
Why
don't
what
about
the
two
buckets?
Because
there
was
the
at
risk
and
accepted.
C
D
A
D
Right
right
and
then,
but
if
you
just
want
to
you,
just
want
to
signal
this
is
what
we're
planning
and
you're
still
working
on
pieces
of
it.
Put
it
in
proposed
right.
A
D
Exactly
and
they
they
don't
give
it
any
attention
until
then
and
so
like
if
they
have
an
extra
snap.
It's
kind
of
weird,
so
not
that
I
want
to
increase
that,
but
I
just
realistically
don't
think
we're
going
to
get
a
lot
of
people
who
are
like
you
know
way
ahead
of
time,
proposing
things
what
we'll
find
out.
A
It's
mostly
sorry,
sorry,
it's
it's
mostly
like
to
there
isn't
an
amount
of
work
to
be
done
right
when
you
like
to
be
done
done
right
to
have
officially
proposed
your
thing.
You
have
your
cap
updated.
You
have
you've
done
a
prr,
all
that
good
stuff
yeah,
and
that
is
harder
to
do
than
just
saying.
I'm
going
to
commit
to
this
thing.
I.
E
A
Commit
to
this
thing
right,
so
we
do
want
to
give
people
that
that
route
to
be
able
to
soft
commit
to
something-
and
you
know
ahead-
of
providing
the
rest
of
the
work
right,
because
if,
if
we
can
get
people
to
say
like
if
I,
if
I'm
able
to
say
at
the
beginning
of
a
cycle
that
they're
going
to
be
54
enhancements,
54
planned
enhancements
like
just
by
way
of
the
receipts,
that's
a
win
to
us
right.
We
know
it's
going
to
drop
later
in
the
cycle
right.
A
We
know
it's
going
to
drop
by
at
least
a
third
later
in
the
cycle
right,
so
yeah,
just
lowering
that
barrier
to
entry
for
people
is
important
to
me.
I
can.
A
Either
way,
but
I
I
like
that
yeah,
I
like
that
too,
to
choose
your
choose:
your
choose
your
own
adventure
kind
of
yeah,
okay,.
A
B
B
Yeah,
so
that's
good,
then
you
address
your
preferences
and
this
is
like
an
acceptance
criteria
to
have
a
fairly
reliable
estimate
of
a
number
of
keps
at
the
beginning
of
the
cycle.
Knowing
there
will
be
drop-off
okay,
so
then
I
think
this
just
triggers
the
question
about
the
name
of
these
buckets
one
more
time
we
actually
had
four.
I
guess
we
had
a
remove
bucket,
which
was
added
last
meeting.
I
think
kind
of
quietly.
A
Okay,
so.
B
A
B
D
D
Something
get
moved
at
risk,
so
the
that's
the
enhancements
team
going
through
and
saying
this
one
assuming,
presumably
it
only
can
move
from
accepted
to
at-risk,
not
from
proposed
at-risk.
If
we
hit
freeze
and
you're
still
in
proposed,
then
you're
done
unless
you
get
an
exception.
So
let's.
C
D
A
Yeah,
so
the
idea
is
that,
ultimately,
the
enhancements
team
is
going
to
handle
running
whatever
tool
to
generate
the
full,
manifest
of
all
the
receipts
that
are
in
the
release.
Right
and
those
are
going
to
be
based
on
they'll
they'll,
be
grouped
by
you
know.
What's
what's
accepted,
what's
at
risk,
what
you
know,
what
have
you
the?
A
The
idea
is
that
the
original
idea
was
that
only
the
enhancements
team
is
writing
to
the
accepted
bucket
right
when
they
submit
that
pr,
that's
essentially
the
correlation
of
all
the
receipts.
If
any
receipt
fails
a
check
right,
then
you
plop
it
out
and
move
it
to
to
at
risk
right.
So
it's
so
it's.
So
it's
supposed
to
be
happening
like
it's
supposed
to
be
happening
as
the
as
the
enhancement
sub
team
is
sweeping
everything
from
proposed
and
moving
it
into
accepted
right.
F
I
have
one
question
there:
does
it
happen?
Does
this
like
exercise
happen
on
a
like
periodic
basis?
Let's
say
a
week
or.
A
We
would
figure
out
whatever
time
between
the
start
of
the
cycle,
our
pre-start
of
the
cycle,
to
enhancements,
freeze,
right
and
and
structure
that
as
like,
okay,
well,
we're
gonna
do
one
sweep
a
week
or
we're
gonna
do
two
sweeps
a
week
right.
If
you
miss
the
boat
you
get
moved
into,
but
I
would
say
that
the
I
would
say
that
we
don't
do
the.
Maybe
we
don't
do
the
final
bit
until
one
until
code
freeze
hits
right,
yeah,
we'll
figure
it
out.
A
F
So
we
will
do
it
once
right,
after
the
enhancement,
freeze,
plus
the
delta
of
the
exceptions
window
right,
basically
move
everything
which
either
did
not
file
an
exception
or
just
fell
off
the
radar
to
removed
right.
So.
A
We
probably
like
we
probably
want
to
do
something
soon-ish
like
if
we
get,
if
say
we
get
10
receipts
submitted
or
something
right
to
start.
We
probably
want
to
try
to
sweep
those
and
as
soon
as
we
can,
or
essentially
as
as
these
things
are
coming
in
right,
we're
we're
signing
we're
assigning
the
enhancements,
we're
giving
the
enhancement,
subteam
ownership
powers
over
this
release,
directory
right
and
from
there,
because,
because
what
you
want
again
we're
trying
to
to
to
drive
down
the
toil
here
and
and
for
me
it
would
be.
A
You
know
for
me,
as
some
enhancement
owner
it's
going
to
be
useful,
to
hear
that
my
enhancement
is
at
risk
for
these
reasons
earlier,
rather
than
later
right.
I
don't
want
to
hear
that
at
enhancements,
freeze
that
I
have
to
go
back
and
fix
something
that
I
thought
was
was
all
set,
because
I
did
the
thing
that
you
told
me
to
do
right
so
like
as
soon
as
I
can
hear
about
it's
at
risk.
A
For
these
reasons,
then
I'm
I'm
in
a
better
state
right
and
then
it's
less
chasing
for
the
team
after
enhancements
phrase
to
decide
what
what
belongs
where
so.
F
So
I
was
like
talking
more
on
the
like
accepted
or
at
risk
to
removed
bucket
migration.
So
how
does
the
state
transfer
look
like
for
those
receipts?
So
we
will
probably
do
it
like
two
times
a
cycle
right.
Ideally.
A
Or
pragmatically
it
depends.
I
forgot
that
this
removed
bucket
was
going
to
exist
at
all.
I
think
I
think,
if
you're,
if
I
think,
if
you
remain
at
risk
past,
a
certain
point
you've
been
removed.
D
That
makes
me
wonder
what
I
said
previously
and
let
me
agree
to,
but
maybe
with
a
bad
idea
is
going
straight
to
accept.
It
doesn't
necessarily
make
sense
in
that
context
like
proposed,
it
sounds
like
if
you
go
into
proposed
and
you
run
this
tool-
you
process
that
whole
cue
and
things
either
get
filed
and
accepted
or
at
risk
that
risk
means
they're.
D
They
not
meet
the
criteria
accepted
needs.
They
meet
the
criteria
for
the
current
point
of
the
release,
the
current
stage
of
the
release
so
as
enhancements
freeze,
that's
a
certain
set
of
criteria
at
you
know,
code,
freeze
or
whatever,
or
maybe
a
week
prior
to
code
phrase
or
two
weeks
prior
to
freeze,
that's
a
different
set
of
criteria.
A
Say
because
that
involves
kind
of
building
sub
commands
into
whatever
this
tool
is
right
or
you
know,
maybe
it's
saying
you
know,
sweep
sweep
and
code
free
sweep,
sweep
enhancements,
freeze
kind
of
situation.
I
would
like
to
be
able
to
get
the
same
output
from
the
tool
whenever
I
run
it
so
yeah.
I
don't.
I
don't
know
the.
A
A
A
It
was
a
proud
job
right
and
then
it's
then
it
then
it
becomes
really
hands
off
right
if
it
is,
if
we
decide
to
wire
this
up
in
a
way
where
a
bot
has
a
token
to
just
write
to
the
repo
and
call
it
a
day
like
that,
you
know,
that's
pretty
sweet.
D
Yeah
we
and
we
would
have
to
see
like
like,
like
imagine,
you
drop
it
in
proposed
and
then
the
runs
and
if
it
meets
all
of
the
criteria
it
gets
moved
to
accepted.
But
with
that-
and
we
can
talk
about
it.
So
let's
decide
now
like
a
pr.
That's
on
the
release
team
says:
yes,
I
accept
it
or
is
it
purely
automatic?
I
guess
we'd
learn
over
time.
A
Oh,
we
talked
about
this.
We
totally
talked
about
this
because
we
were
writing
tools,
for
we
were
writing
tools
to
submit
prs
automatically
for
for
other
areas
like
the
release,
notes
right
and
then
so
the
idea
would
maybe
be
to
do
it
the
same
way
test
infra.
A
Does
it
right
or
you
submit
a
pr
and
basically
test
in
for
on-call,
has
to
come
in
and
say
yes
to
that,
pr
that
updates
all
the
images
and
stuff
right
so
like
that's
the
way
to
do
it
where,
instead
of
like
you
know,
immediately
writing
to
the
repo
it
stages,
a
pr
right
and
that
pr
continues
to
get
updated
until
someone
from
the
enhancements
team
hits
it
and
goes
like
yeah.
That
looks
sane
and
it
passes
all
the
checks
so
right,
okay,.
B
So
and
proposed,
you
would
run
a
tool
eventually
that
would
do
this
so
yeah
I
just
want
to
make
okay
eventually
run
a
tool
with
the
bottom
token
that
it
would
be
ready
to
go
to
accept
it.
A
A
B
Okay,
we
still
have
some
major
questions
here.
We
have
just
two
minutes
left.
One
of
the
major
questions
that
I
pulled
out
in
the
notes
is
that
I'll
just
put
it
here,
because
it's
closer
having
one
big
receipt
poses
potential
for
conflict
when
multiple
editors
are
working
simultaneously
could
be.
A
Only
one
person
should
be
working
on
this
at
a
time
and
the
bot
solves
a
lot
of
the
the
bot
is
not
handling
not
necessarily
handling
the
it
can
handle
that
manifest
generation,
because
ultimately,
every
time
it
runs
again
it
will
you
know
things
will
be
in
the
right
places,
so
this
can
eventually
shift
into
just
an
approval
process,
as
opposed
to
manually
running
the
tool
and
getting
the
large
receipt.
B
B
B
Could
be
like
a
wrangler
one
person
is
doing
it
at
a
week,
person
of
the
week
in
charge,
so
there
you
go
and
then
you
had.
The
bot
can
eventually
handle
the
manifest
generation,
and
then
I
think
you
said
one
other
thing:
I'm
gonna
put
this
over
here
conflict.
A
B
Yeah
move
this
up.
It
might
just
be
something
we
would
emphasize
more
on
the
enhancements
team
if
it's
not
already.
B
Yeah,
okay,
so
that's
the
major
question,
the
other
thing
yeah,
the
only
other
thing
that's
outstanding.
It's
just
real
flashy
quickie-
is
that
this
document
has
been
hanging
around
since
june.
It
is
kep
cuddle
cap
ctrl,
whatever
information,
but
we
have
continued
to
slide
a
little
bit
into
the
receipts
could
also
be
kept
cuddle
or
maybe
not
maybe
that
tool
could
do
some
of
this.
The
boundary
still
is
like
a
little
ambiguous
and
this
document.
A
Yeah,
so
what
we
talked
about
with
this
tool
and
the
this
it's
been
it's,
I
guess
it's
been
hanging,
purposely
ish,
because
you
know
essentially
what
we
said
about
this
tool
is
like
we,
we
want
the
process
like
it's
people,
process
tools
right.
We
want
the
processes
that
we
develop
to
govern
what
needs
to
go
into
this
tool
and.
A
Still
kind
of
like
formulating
this
process,
I
think
it's
fine
that
this
document
may
be
getting
a
little
stale.
The
moving
forward
on
receipts
would
force
us
to
maybe
write
more
validation
in
the
in
the
kepval
library,
as
required
to
to
work
for
the
receives
process,
and
if
that
becomes
the
ultimate
structure
for
the
first
iteration
of
kept
ctl,
then
that's
fine.
B
B
D
B
B
Yeah
it's
in
the
agenda.
I
also
slacked
on
about
it
two
weeks
ago.
So
it's
it's
here.
What,
if
from
this
here
I'll
just
put
the
title
cap
kept
notes,
but
it's
here
and
then
yeah.
A
E
B
All
right,
thank
you.
Okay,
thanks
all
right.