►
From YouTube: 20201013 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
13th.
This
is
a
meeting
of
the
enhancement
sub
project
for
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
now
before
we
get
started.
I
see
that
we
have
some
new
faces
here.
So
if
you
are
interested
in
saying
a
few
words
about
why
you're
here
general
intro
that'd
be
great.
A
D
C
F
F
Let's
party
I'll
just
run
through
the
items
here
so
that
we
reckon
with
all
of
them
so
review
receipts
process
roadmap.
We
have
a
receipt
process
roadmap
and
we
should
look
at
it
because
this
seems
to
resolve
a
lot
of
the
issues
that
have
been
floating
around
for
quite
some
time
that
many
people
have
expressed
like.
Why
can
we
fix
this
thing?
Receipts
aims
to
fix
those
things
making
kept
transparent.
F
So
I
don't
want
to
say
too
much
about
this
if
anything
at
all,
because
we
oh
actually
there's
a
github
issue
for
this
now,
but
basically
we
have
the
plan
to
make
a
caps
website
and
the
github
issue
will
give
you
some
details
about
that.
But
basically
it's
not
going
to
be
extremely
complicated,
all
the
bells
and
whistles,
but
it's
to
give
us
a
start
in,
can
we
query
caps
and
they're
owning
sig
and
then
go
from
there
with
status,
etc.
F
The
next
item
is
update,
features
enhancements,
repo
documentation,
just
wondering,
if
there's
anything
left
to
do
on
that
item.
We've
asked
that
a
couple
of
times
but
haven't
come
up
with
a
concrete,
yes
or
no.
So
if
we
can
walk
out
of
here
with
that,
that
would
be
a
big
win
and
then
last
time
we
were
looking
at
the
kept
template
based
on
previously
offered
feedback
from
various
sig
leads
and
chairs,
and
others
interested,
and
these
are
the
action
items
that
came
from
that
review
effort
all
in
one
condensed
place.
F
So
I'm
not
sure
if
there's
anything
more,
we
actually
have
to
do.
There's
also
these
two
items
from
jeremy
that
are
related.
He
claimed
those
those
are
also
related
to
the
cups,
template
and
they're.
Quite
self-explanatory
and
clear
and
small.
F
Converting
cups
from
flat
files
to
a
directory
structure
that
issue
is
actually
being
handled
by
the
enhancements
team.
This
cycle,
so
I
don't
think
there's
anything
more
to
oh,
no,
it
sounded
like
christian
might
have
popped
in.
I
don't
think,
there's
anything
more
to
say
there
until
chris
kristen
comes
back
with
to
us
and
then.
G
She
gave
a
quick
update
on
that
yesterday
and
said
that
they're
gonna
they
haven't
started
that
yet
because
of
the
enhancement
trees
and
now
that
they're
freed
up
a
little
bit,
they're
gonna
start
working
on
that.
F
Right
yeah,
so
that
works.
Thank
you
and
then
there
was
this
tracking
enhancement
slip
issue
from
I
think
two
meetings
ago,
because
we
didn't
get
to
it
last
time.
H
Well
so
last
week
in
the
production
writing
sub
project,
so
we
talked
about
some
tooling
options
that
we'd
like
we
have
some
issues
around,
how
we
do
the
production,
readiness
reviews
and
do
our
approvals
right
now,
and
so
this
might
fit
in
with
the
ticketing
system,
like
I
wanted
to
discuss
here,
if
possible.
H
What
people
think
the
right
tooling
is
so
I'd
like
to
bring
that
up.
It
might
make
sense
to
bring
it
up
in
the
context
of
the
receipts
business,
because
that
might
be
one
that
might
be
one
implementation.
F
Yeah-
let's
put
it
yeah-
let's
put
it
here
like
as
the
next
item,
so
that
we
try
to
get
to
it
because
all
the
other
ones
are
fairly
like
dealt
with
except
tracking.
F
F
Jeremy,
I'm
going
to
share
the
screen
so
that
we
can
look
at
the
documents.
F
So
maybe
I'll
just
go
over
it
real,
like
the
headers,
so
that
we
just
know
what
content
is
here.
So
basically,
we've
been
talking
about
this
receipts
process
to
divest
the
release
team
from
a
lot
of
the
cat
hurting
they
do
in
any
given
release
cycle,
and
if
we
have
to
tldr
what
receipts
means.
F
It's
an
opt-in
promise
or
soft
commitment
from
a
sig
about
the
caps
that
they're
submitting
to
a
specific
release,
and
it's
aimed
at
tracking
all
actions
and
get
so
no
more
mixing
of
comments
on
the
issue
and
in
the
cup
itself
for
our
mvp
delivery
goal
for
120.
You
know
we're
not
going
to
fix
all
of
the
problems
right
away,
but
we
want
to
have
a
start
where
we
have
collections
of
mini,
manifests
based
on
tracking
three
stages
or
statuses
of
caps,
which
are
proposed,
accepted
and
exceptions.
F
What
this
effort
solves
is
the
cat
hurting
issue.
We've
mentioned
also
just
alleviating
a
lot
of
the
uncertainty
about
who
can
speak
for
a
cup
a
lot
of
the
back
and
forth,
and
then
this
is
kind
of
where
we
want
to
probably
spend
our
most
time
is
how
this
process
will
work
and
then
the
implementation
steps,
because
that's
kind
of
where
we
this
is
the
bulk
of
like
this-
is
the
work
itself.
F
So
when
stephen-
and
I
talked
about
this
on
friday,
his
idea
is
what
it
is
that
the
sig
submits
a
pr
sharing
its
receipt
is
a
yaml
file
of
relevant,
kept
metadata
to
the
proposed
bucket
or
folder
for
a
given
release.
F
H
So
can
I
ask
a
question
the
so
the
sig
submits
apr,
so
so
we're
saying
one
yaml
file
per
seg
per
release,
listing
all
of
the
proposed
enhancements
and
exceptions,
or
is
this
a
file
per
feature?
First
per
cap.
A
So
this
is
a
file
per
cap
right,
so
the
what
we're
trying
to
get
out
of
the
business
of
is
essentially
trying
to
figure
out
all
of
the
things
that
a
sig
is
doing
with
multiple
stakeholders.
At
the
same
time,
the
aggregate
of
the
aggregate
of
each
of
these
receipts
would
become
a
manifest
right,
which
is
okay
right,
so
that
becomes
so
think
and
you'll
see
a
little
lower
in
the
dock.
A
Basically
tree
structure,
all
of
these
buckets
we
can
kind
of
play
with
what
the
names
are,
what
we
decide
to
do
with
them-
maybe
maybe
exceptions
is
actually
at
risk
and
we
can
move
things
back
and
forth
through
that
bucket.
But
the
idea
is
that
you
would
be
able
to
run
some
tool,
and
you
know
I
was
talking
to
lauren.
I
was
like.
Maybe
this
is
kept
ctl.
Maybe
this
is
one
of
the
the
functionalities
of
cap
ctl.
A
So
you
know
the
first
step
is
that
someone
right
enhancements,
lead
enhancement,
shadow
or
something
can
run
this
tool
to
generate
the
appropriate
directory
structure
for
the
receipts
right.
So
the
same
way
we
have
sig
release
releases,
slash,
release.
120.
Would
be
the
same
within
the
enhancements
for
rebo
or
it
could
be
in
the
sig
release
repo
like,
however,
we
want
to
play
it
right
from
there.
A
It's
releases
the
name
of
the
release,
the
set
of
buckets
accepted
proposed,
maybe
at
risk
or
exceptions
right
and
once
that
directory
structure
is
set
in
place.
We
also
add
an
owner's
file
so
that
the
enhancements
leads
for
that
team
can
can
own
that,
for
that
release
can
own
that
and
the
so
there
will
be
one
a
generation
of
the
structure
and
then
two
a,
I
guess,
the
think
make
generate
kind
of
workflow
or
output
from
from
ka
community
right.
A
You
can
run
make
generate
it
loads.
It
looks
at
segamals
and
spits
out
something
right.
This
something
would
be
a
manifest.yaml
whatever.
We
want
to
call
it
within
the
root
of
the
of
the
release
directory
right,
and
that
is
going
to
list
everything
that
is
grouped
by
things
that
we've
accepted
things
that
have
been
proposed
and
things
that
are
potentially
at
risk
right.
So
so
at
that
point
you
kind
of
have
two
separate
mechanisms.
A
Potentially,
if
we
look
at
a
website
right
eventually
like
if
we
have
clean
metadata
on
a
website,
someone
can
slice
and
dice
and
figure
out,
what's
happening
per
release
right.
They
can
easily.
They
can
just
as
easily
use
this
manifest.yaml
per
release
to
see
what's
happening
within
the
release
and
what
the
statuses
are
for
that
right
right.
So
this
becomes.
This
becomes
the
enhancements
tracking
sheet
going
away.
H
Right,
yeah
yeah,
which
would
be
awesome
and-
and
I'm
just
thinking
about
this
is
this-
is
cool
because,
like
like
one
of
the
things
we
do,
every
every
release
like
with
gk
here
is:
we
have
to
go
through
and
figure
out
go
through
the
release,
notes,
figure
out
what
features
and
what
new
feature
flags
there
are
what
we
might
need
to
enable
or
disable
you
know,
and
this
would
help
automate
some
of
that
like
so
I
I'm
just
sort
of
thinking
through
that.
You
know
that
would
be
really
cool.
F
If,
if
you
want
me
to
go
through
this
stock
with
you
in
detail
like,
I
can
do
that
we'll
get
through
it
all,
but
just
to
bring
you
up
to
speed
on
all
the
things
yeah.
A
A
F
But
maybe
we
can
just
go
through
the
remainder
steps
yeah.
So
basically,
just
I
think
you
covered
essentially
the
the
basic
steps
here.
You
have
your.
F
Yeah
we
got
your
release
team
looking
in
that
bucket,
then,
when
the
enhancement
freeze
hits
they
create
the
accepted
bucket
folder
push
that
stuff
into
the
accepted
folder
and
then
can
generate
a
report.
They
can
ship
out
to
the
community,
highlighting
like
what's
missing
in
a
cup
and
what
kept
past
and
are
accepted
and
then.
A
Yeah,
so
one
of
the
interesting
things
about
this
step
is
that
it
allows
us
to,
depending
on
how
we
play
it,
allows
us
to
kind
of
ratchet
up
the
expectations
of
validation
between
those
two
buckets
right
so
like
in
a
proposed
bucket.
Maybe
we're
only
looking
for
fubar
and
baz
right
and
then
for
it
to
become
accepted
the
it
becomes
less
about
the
the
release
team
kind
of
going
through
and
reading
through
all
the
issues
and
seeing
if
that's
okay,
okay,
cool,
add
it
to
the
checklist,
it
becomes
a
lift
and
shift.
A
Basically,
you
know
a
get
move
from
the
proposed
bucket
into
the
accepted
bucket
right.
When
that
pr
is
issued,
there'll
be
a
pre-submit
and
if
the
pre-submit
doesn't
pass,
it
means
you're
missing
information
right.
So
you
basically
block
the
release
until
the
information
is
provided.
H
So
so,
this
is
exactly
why
I
thought
this
this
is.
This
is
really
cool
so
with
the
the
prr
is
one
case
in
point
here,
so
what
we
were
looking
for
for
tooling,
that's
why
I
thought
might
fit
in
this
discussion
is
what
we
really
want
is
when
you
target
a
given
feature
given
cap
at
a
particular
milestone.
H
We
want
to
validate
end
stage.
We
want
to
validate
that
the
prr
has
been
approved
by
a
pr
approver
and
for
that
stage,
and
so
we
have
some
of
that
like
that-
that
gate
then
is
not
on
any
individual
code.
Pr,
it's
not
even
necessarily
like.
If
you
wrote
your
cup
and
you
said
I'm
going
to
advance
in
the
to
this
stage
in
these
releases,
and
you
had
a
plan
and
you're
executing
against
your
plans
successfully.
H
You
may
not
touch
your
cup
again,
so
we
won't
even
necessarily
get
I
mean
you
should,
because
you
should
touch
it
to
update
the
prr,
but
like
we're
not
going
to
necessarily
get
a
pr,
you
know
if
somebody
doesn't
realize
that
or
whatever
right
we're
not
going
to
get
an
opportunity
necessarily
to
approve
a
pr.
Unless
they,
I
guess,
a
human
catches,
it
and
the
enhancement
student
says:
oh,
they
didn't
finish
these
beta
level.
Pr
questions
right,
there's
just
a
lot
of
gaps
or
possibility
for
things
slipping
through
the
cracks.
H
So
what
we
were
thinking
is:
is
there
some
kind
of
validation
we
can
do
on
the
maybe
on
the
milestone
assignment
or
something
you
know,
but
I
don't
think
we
do
that
anywhere
right
now.
So
this
is
really
would
be
that
pr
and
those
validations
you're
talking
about
would
be.
I
think,
the
right
place
to
do
that
to
say
hey
in
order
to
be
in
the
in
the
we
have
a
list
in
the
template.
In
order
to
be
in
the
release,
you
have
to
have
your
graduation
criteria.
H
You
have
to
have
a
test
plan
and
one
of
those
things
is,
you
have
to
have
the
appropriate
pr
questions
answered,
and
so
the
piece
missing
here
is
how
we
is
that
must
be
approved
by
a
pr
approver.
So
if
we're
going
to
have
multiple
criteria
going
into
the
decision
of
when
something
can
go
into
the
release,
how
do
we
trigger
reviews
by
those
sub
teams?
So
if
the
prr
team
has
to
review
the
prr
and
approve
it
right
now,
what
happens?
Is
they
put
it
in
the
kept
template?
H
A
Yeah,
I
did
that
one
too
yeah,
so
I
have
multiple
ideas,
but
it's
probably
longer
than
bob's.
H
Okay,
we
did,
I
did
write
down
some
ideas,
but
I
really
wanted
to
bring
it
to
this
group
and
and
anyway,
so
I
don't
want
to
like
hijack
things
here.
I
don't
know
you
just
wanted
to
bring
it
everybody's
attention.
F
F
H
Yeah
and
linked
the
doc
in
the
in
the
agenda
that
describes
the
most
important
part
of
that
is
our
tooling
options.
The
most
important
part
is
the
goals
which
are
the
others
are
just
like.
Almost
notes,
you'll
see
scratch
down,
but
the
the
goals
are
what
I
what
I
just
described.
I
hope.
C
I
H
A
H
H
I
I
thought
only
worked
for
applying
labels,
not
for
actually
getting
you
know,
selecting
the
right,
reviewers
or.
I
Out
I
I
will,
I
will
say,
though,
at
least
when
it
comes
to
adding
like
a
label
and
making
it
like
blocking
it's
not
that
difficult.
It's
you
know
soon.
You
started
off
with
the
whole
needs
triage
one
and
then
nikita
finished
it
off
and
it
wasn't
wasn't
a
huge
huge
change.
A
H
A
So
I
think
we
have
a
good
melange
of
the
people
that
we
need
to
discuss
it
in
general.
Across
you
know,
it's
kind
of
we've
got
people
across
release
and
architecture
and
contributor
experience.
I
think
in
terms
of
ideation
like
it
happens
across
here
and
the
prr
meetings
and
then
in
terms
of
like
well.
How
would
we
actually
implement
this?
It's
it's
contributor
experience,
okay,
cool.
B
A
Happen
right
where
this
this
again
folds
back
into
like
kept
metadata,
is
it
clean
right
being
able
to
answer
that.
H
Question
and
we're
trying
to
put
in
the
in
the
pr
in
the
cap
yaml
we
trying
we
tried
to
put
as
much
as
we
can
so
that
we
could
answer
these
questions
with
tooling,
rather
than
a
human.
H
Having
to
say,
did
they
answer
these
alpha
questions
like
some
of
them,
like
you
know
what
what's
the
future
flag,
we
make
them
put
that
in
the
what
components
does
it
have
to
go
with,
which
also
ties
back
in
like
then
you
can
this
manifesto
with
this
tool
that
reads
the
manifest
here's
the
features
you
can
say.
Oh
here
are
the
new
feature
flags,
here's
what
the
components
that
need
them.
It
can
be
really
nice
rich
amount
of
data
that
we
can.
A
Then
it
gives
us
an
opportunity
to
again
with
this
magical
cap,
ctl
new
functionality,
thing
being
able
to
say
something
like
kept
ctl
propose,
you
know,
propose
kept
number
stage,
blah
blah
blah
blah
right
and
instead
of
having
to
hand
cobble
this
receipt,
you
can
just
it'll
automatically
pull
the
it'll
pull
the
metadata
from
the
cap
right
and
just
strip
out
only
the
pieces
that
it
needs
right
and
then
that
becomes
kind
of
like
a
much
cleaner
workflow.
A
If
the
you
know,
if
the
sig's
saying
like
I
know
which
caps
I'm
gonna
do,
I
can
write
a
script
around
kept
ctl.
If
I
wanted
to
to
do
the
proposal
right
and
then
issue
the
pr
so
and
that
that
that
comes
back
to
like
is
the
metadata
clean
right
so
like
making
sure
that
we
do
that
that
clean
up
and
and
stricter
and
stricter
validation,
as
we
get
better
at
as
everyone
gets
better
at
making
sure
that
the
caps
are
up
to
date,.
F
So
like
with
the
initial
mvp
we
do
like,
I
said
we
don't
want
to
do
everything
all
at
once,
but
some
of
the
steps
that
stephen
had
in
mind
were
like
the
validation
showing
us.
The
results
manifests
are
correct,
then,
as
we
go
deeper
into
that
carving
it
up.
F
A
Yeah,
so
for
developments
up
kind
of
two
and
three
right,
it
becomes
the
you
have
a
stronger
hope
of
the
well.
You
have
a
stronger
hope
of
the
there
being
minimal
differences
between
what
you've
put
in
the
receipt
versus.
What's
in
the
cap
metadata,
if
you're
pulling
it
directly
from
the
kept
metadata
right,
then
you
kind
of
know
that
they're
in
sync,
so
ideally
whatever
tool
that
we
create
is
is
you
know,
is
pulling
data
from
the
caps
as
opposed
to
being
hand-cobbled
right
right.
B
A
I
think
the
first
iteration
of
this
is
going
to
be
for,
for
121
is
going
to
be
the
hand-cobbled
bits
right
and
we'll
we'll
lean
on
we'll
lean
on
pre-submit
validations
right
to
make
sure
that
those
are
clean.
H
Yeah,
if
they
were
on
the
tool,
they
use
a
tool,
we
can
actually
it's
the
same.
At
least
today,
it's
the
same
libraries,
you
could
actually
run
the
validations
without
them
even
having
to
push
the
pr
and
just
say,
hey
no
way.
This
is
going
to
get
approved
unless
you
fill
out
this
this
this
and
this.
A
Yeah,
but
we
we
do
want
to
make
it
easy
for
for
someone
to
propose
something
right
and
it
like
a
lot
more
lightweight
than
saying
like
going
through
a
thread
of
200
comments
and
trying
to
figure
out
where
an
enhancement
issue
is
at
right,
yeah,
so
like
this
is
this
is
again
supposed
to
drive
down
the
traffic
on
enhancement
issues
and
push
people
more
into
to
making
sure
that
the
caps
are
up
to
date
right
the
I.
I
A
Yeah,
so
this
is
and
the
what
ends
up
happening
is
it
kind
of
like
moves,
some
of
that
that
responsibility
from
the
the
authors
into
the
enhancements
team's
side
as
they
as
they
flip
something
from
proposed
accepted
right
so
like
that
becomes
a
massive
pr
with
the
entire
manifest
and
all
the
sets
of
receipts.
And
at
that
point
we'll
start
we'll
start
hitting
the
red
flag
right,
yeah.
A
J
H
A
We
could
eventually
move
there,
but
it
it's.
It
presupposes
that,
like
we've
got,
we've
got
the
tooling
down
all
right.
B
A
That
they're
gonna
they're
gonna
be
some
tweaks,
so
I'm
thinking
with
the
exceptions,
one
that
that's
probably
going
to
be
at
risk
right
instead
right
that
folder
it
becomes
at
risk
and
if
a
release,
team,
member
enhancement,
sub
team
member
proposes
this
pr
and
they
start
to
hit
validation
errors
right.
What
immediately
happens
is
they
take
whatever
you
had
and
they
put
it
in
at
risk
right
and
and
instead
of
having
to
do
the
back
and
forth
on
the
issues.
A
We
can
just
go
okay.
Well,
these
were
accepted
because
they
passed
validation.
These
are
at
risk
because
of
these
reasons,
right
generate
a
report
based
on
the
at-risk
prs,
send
it
out
to
the
community
right,
your
pr,
your
your
kep,
your
enhancement
remains
at
risk
until
you
do
these
things
and
go
read
the
report
so
so.
H
So
then
enhancements
team,
what
they're
gonna
do
is
people
are
gonna,
who's
gonna
have
owners
on
the
proposed
and
then
the
enhancements
team
is
going
to
go
through
everything
you
proposed
or
potentially
run
a
tool
on
it
that
gives
them
at
least
you
know
these
paths
and
then
they
may
be
doing
second
level
of
verification
and
then
they're
going
to
do
another
pr
to
move
them
into
accepted,
and
is
it
just
the
enhancements
team?
At
that
point
also,
who
has
the
owner's
permissions
on
that.
A
Only
the
enhancements
team
will
have
well
the
enhancements
team
and
and
the
sub
project
owners
will
have
ownership
over
the
release.
Directories
and
the
enhancements
team
will
be
only
delegated
the
release
directory
for
their
release.
H
Yesterday
was
great
but
yeah,
so
so
again
we
create
the
spreadsheet
based
on
the
issues.
Then
we
have
to
go
through
and
decide
and
ask
people.
Are
you
going
to
include
this?
So
what
what
we're
saying
now
is,
instead
of
so
now
you're
saying
you
run
a
tool
and
does
that
tool?
H
I
know
you
said
it
creates
the
directory
structure.
Does
it
create
proposed
yamls
for
every
issue
or
it
just
okay,
and
then
we
send
out
an
email
to
dev
and
every
other
mailing
list?
Another
son
saying
I'm
sorry,
I'm
just
I
haven't
read
the
document,
but
we
sent
out
an
email
saying:
okay,
hey
everybody!
A
So
I
mean
initially
initially
we
say
here
is
the
yaml
structure
that
we
accept
that
we
expect
right
create
a
receipt
that
has
that
is
the
the
basically
the
number
of
your
cap.yaml
right
and
and
this
structure
right.
I
think,
I
think,
probably
for
the
first
step.
It's
going
to
be
manual.
I
G
Yesterday
and
like
we,
both,
I
think,
feel
having
done
enhancements
and
I
won't
speak
for
bob
or
nabaroon,
but
there's
a
lot
of
impetus,
put
on
to
individual
authors
right
now
to
get
through
this
process
and
not
on
the
sigs,
and
we
like
chris
kirsten,
and
I
both
think
that,
like
there
should
be
more
on
the
sigs-
and
I
think
this
puts
the
the
ball
in
their
court
to
make
sure
that
things
happen
like
we
just
approved
an
exception
requests
yesterday
for
something
that
you
know
was
going
on
like
there
were
a
bunch
of
changes
happening
to
the
cap,
it
didn't
get
updated
correctly
like
it
didn't.
G
Have
the
prr
didn't
have
the
things
that
were
necessary
because
somebody
picked
it
up
because
somebody
else
was
out
and
like
all
that
stuff
was
happening,
but,
like
jordan,
didn't
say,
hey
you
should
update
these
things.
There
wasn't
any
review
of
the
of
the
kept
at
that
point.
It
was
just
the
technical
pieces
in
it.
There
was
no
like
hit
knock
from,
like
I
said,
oh
saying,
hey,
please!
This
is
going
to
come
in.
We
just
got
the
exception
request
after
not
having
any
response
at
all
for
the
whole
four
weeks
of
enhancement,.
F
H
So
we
might
need
to
provide
more
more
like,
like
I
know,
laurie.
I
know
folks
have
been
like
helping
the
slaves
with
triage
and
things
like
that.
You
may
want
to
define
or
or
propose
another
sort
of
process
for
them
of
release
planning,
because
I'm
not
sure
all
the
sticks.
Do
it
and
well
here's
my
picture
and
tell
you
they
don't.
F
H
Exactly
because
what,
in
my
experience
being
on
the
enhancement
team,
a
couple
of
times
as
a
shadow
nonetheless
doing
the
pinging
is
that
more
than
one
occasion,
I
think
somebody
they're
like
oh
darn,
I
forgot
about
this
right.
I
better
do
that
and
if
we're
just
like
sending
an
email,
saying,
put
your
stuff
in
yeah,
they're,
gonna,
miss
and
so,
and
there
are
things
that
some
of
them
are.
H
You
know
I
guess
what
I'm
trying
to
say
is:
if
we're
gonna
step
back
and
not
be
pushing
people,
then
there
needs
to
be
something
else,
pushing
them.
So
so
we
have,
for
example,
now
a
policy
and
in
fact
it's
not
only
just
a
policy,
it's
enforced
in
code,
or
it
will
be
soon.
This
121,
I
think
we're
working
on
the
code
for
121.
H
H
If
there's
no
human
involved
or
there's
no
tooling
involved,
that's
nagging
people
or
raising
issues
that
things
are
gonna
go
away
and
maybe
it'll
just
happen
once
and
the
cigs
will
be
like.
Oh
my
god,
we
can't
let
this
happen
again,
but
we,
I
don't
know
it's
just
a
thought.
We
have
to
sort
of
plan
for
it.
F
I'd
be
happy
to
talk
to
you
about
that,
because
I've
been
doing
a
lot
of
this
outreach
to
sigs
about
their
process,
and
I
get
all
kinds
of
responses-
and
I
know
you're
doing
I
know
you're
doing
stuff
on
this
as
well
in
your
own
way,
there's
a
there's,
still
a
resistance
from
some
groups,
just
any
sort
of
process
and
responding,
and
so
that's
going
to
create
issues
for
them
right
now.
It's
kind
of
like.
F
To
them,
then,
then
they
they
have
to
own
it
and
to
your
point
about
providing
a
human
yeah
for
sure
like
because
we
don't
want
to
just
be
cruel,
we
don't
want
to
be
like
cutting
people
off
from
their
own
code
and
their
work,
but
all
the
same,
there's
a
certain
point
where
it's
like
all
right.
Now
you
own
this.
Now
you
have
to
kind
of
collaborate.
Collaborate,
you
know
meet
us
halfway
and
I
I'd
love
to
brainstorm
with
you
like
how
that
could
look
based
on
the
data
that
I've
been.
F
H
A
I
No,
so
some
of
the
like
the
marketing
teams
were
working
on
basically
ways
of
broadcasting
messaging
to,
like
you
know,
every
slack
channel
every
mailing
list
and
a
lot
to
try
and
get
stuff
out
the
one
problem
we've
talked
about
too,
with
some
of
these
things,
especially
like
once,
you
start
broadcasting
everyone,
it's
easier
for
people
to
tune
out,
it's
it's.
C
G
B
G
F
And
honestly,
like
I
always
ask
people
like,
do
you
really
want
to
be
nagged?
You
know
like
when
I'm
doing
this
with
teams,
I
work
with
it's
like.
Do
you
want
me
to
nag
you,
because
that's
not
fun.
For
me,
it's
probably
not
fun,
for
you
either
like
what
if
we
were
having
a
completely
different
discussion
right
now
about
how
to
like
plan
what
you
would
like
to
do,
instead
of
do
you
have
it
do
you
have
it
like
come
on.
A
So,
let's,
let's
I
think
we,
I
think
we
all
have
an
idea
of
what
we
want
with
this
and
we're
kind
of
happy
where
this
is
going.
Maybe
we
kind
of
birds
eye
it
and
go
back
to
the
agenda
and
make
sure
we
hit
the
other
topics.
Sure.
F
D
So
I
wanted
to
ask
one
question
here
so
near
the
code
free,
so
all
up
like
the
process
until
after
the
announcements
freeze
is
pretty
clear
here:
the
workflow
with
the
whole
receipts
thing.
So
what
happens
when
an
announcement
which
has
been
approved
into
the
release
or
accepted
into
the
release
they
drop
off
due
to
not
being
able
to
fulfill
their
code
requirements?
D
A
So
a
lot
of
the
the
kind
of
brain
mappy
stuff
I
was
doing
was
kind
of
focused
on
eliminating
the
toil
during
because
like
since
we,
since
it's
such
a
huge
part
of
the
cycle,
to
have
this
in
place
and
do
it
quickly
at
the
beginning.
I
was
kind
of
focusing
my
efforts
there,
but
I
I
do
agree
that
yeah
having
a
slip
because
we
want
to
like
I
worry
about
having
a
slipped
bucket
because
we
want
to.
Although
we
eventually
want
to
probably
aggregate
all
the
slips
somewhere
right.
A
Maybe
this
is
the
way
to
do
it
right,
comb,
the
directory
structures,
pull
everything
from
slipped
and
then,
and
then
say
like
this.
Is
you
know
this?
This
popped
this
many
times
this
pop
that
many
times
right
and
then
have
kind
of
a
rough
heuristic
on
on
what
what's
slipping
across
release
cycles?
Maybe
that's
the
way
to
solve
it
right,
and
I
know.
B
A
F
So,
just
to
follow
up
a
couple
questions,
there's
a
few
technical
implementation
questions,
they're
highlighted
in
yellow
and
then
there's
a
few
questions
related
to
process.
For
example.
F
H
I
think
that
it
does
help
pr,
but
I
think
stephen's
comment
earlier
was
right
that
that's
that's
like
a
let's
get
the
basic
thing
flowing
and
we
can
that's
something
we
layer
in
on
top
later,
but
I
just
want
to
make
sure
that
whatever
we
do
for
the
tooling
for
prr,
doesn't
you
know
isn't
just
like
completely
in
conflict
with
this
or
you
know,
I
want
to
make
sure
that
they
they
go
hand
in
hand.
F
Yeah,
so
so
I
mean
a
number
of
things
here
so
like
I
want
to
just
know
quickly.
I
don't
want
to
know
like
the
answers
to
questions
but
like
how
do
we?
How
would
we
like
to
work
on
these
questions
in
yellow,
like
in
the
slack
channel?
How
can
we?
How
can
we
work
on
this?
So,
the
next
time
when
we
meet,
we
have
answers,
maybe
even
get
answers
before
then
we'd
like
to
ask
and
as
threads
in
the
slack
channel,
would
that
be
a
sustainable
way
to
move
forward
on
those
questions.
H
Or
writing
up
the
design
as
a
as
a
cat
or,
however,
we're
gonna
do
it
can
make
those
decisions
and
that
if
people
don't
like
them,
they
can
comment
now,
and
you
know.
A
Think
we
solved
some
of
them
already
yeah.
So
if
we
feel
like
this
becomes
again,
this
becomes
the
update
to
617
right
closing.
B
A
F
A
I
would
say
the
next
step
is
that,
like
now
that
it's
all
pretty,
I
lift
and
shift
it
into
617..
Okay,
we
identify
some
people
who
are
interested
in
working
on
the
thing.
Jeremy
just
threw
his
hand
up
so.
C
A
All
right
all
right,
we
got
hackers,
you
know
we
have
much
of
the
library
that
we
need
already
and
kept
val.
F
A
You
know,
I
think
it's
I
think
it's
making
sure
that
we
like
having
the
documentation
making
sure
that
we
pump
it
before
121
and
and
getting
cracking.
I
think
you
know
the
the
bare
bones.
First
phase
is
manual
everything
just
understanding
the
structure
that
we
want,
making
sure
that
the
you
know
making
sure
that
the
the
content
in
the
receipts
matches
the
things
that
are
going
to
be
in
the
metadata
right
and
from
there
we
start
layering
improvements
on
it
right
write
a
tool
for
it.
A
You
know,
make
the
tool
you
know,
make
the
tool
read
in
the
kep
metadata,
yada,
yada
yada
right,
so
so
super
super
bare
bones
hack
it
out
for
121
to
land
for
121.
If
we
get
further
in
terms
of
improvements,
then
that's
great.
A
I
think
mvp
landing
to
to
you
know
give
the
release
team
some
some.
Some
much
needed
relief
will
be.
F
F
F
F
F
G
I
think
so.
Okay,
I
think
that
we,
there
are
a
couple
things
we
should
decide
like.
Where
will
this
live,
sig
release
or
enhancements.
A
B
G
Think
the
rest
of
the
stuff
that
we
discussed
was
addressed
as
we
were
talking
and
everything
else.
I
think
we'll
just
as
we
come
across
things
we'll
make
educated
guesses
and
circle
back.
Okay,.
D
Just
one
there
sorry,
so
I
think
the
comment
that
you
made
right
on
the
comment
that
you
wrote
capps
website.
I
think
it's
not
the
kept
website
the
release
website.
I
think
we're
targeting
both
as
like
different
entities
right,
so
we
have
the
caps.
F
J
So
sorry
keep
going
keep
going.
D
B
D
I
just
wanted
to
clarify
if
it's
like,
because
of
the
release
website
right
now,.
A
A
For
for
the
current
release
right,
so
what
I
was
what
I
was
kind
of
implying
there
is
that
if
the
metadata
is
in
the
same
is
in
the
same
place
as
what
we're
shipping
to
that
site,
then
it
becomes
a
really
easy
view
for,
what's
what's
in
the
release,
what's
at
risk,
yada
yada
right
on
the
flip
side,
having
the
enhancements
website
like
we
can
also
generate
this
data
in
on
the
enhancements
website
or
because
it's
coming
from
the
same
metadata
right.
A
The
the
tricky
part
right
is
that
if
we
want
to
create
a
tool
that
is
eventually
going
to
generate
these
receipts
based
on,
what's
already
in
the
repo,
then
now
we're
dealing
with
two
repos
right.
So
it
gets
harder
right.
So
it's
easiest.
If
everything
is
in
k
enhancements
and
if
we
want
to
do
later
designs,
we
have
different
machinations.
Later
we
can
do
that
right,
but
having
everything
in
one
place
is
the
easiest
thing
to
do
for
now,.
I
Okay,
and
as
far
as
the
contributors
I
can
just
in
ingest
stuff
from
wherever
it
doesn't
matter
too
much.
I
The
other
thing
is
like:
if
we're
producing
an
artifact
or
something
like
that
it,
it
might
not
necessarily
have
to
be
stored
in,
like
you
know
that
at
least
is
all
the
aggregate
metadata
or
something
like
it
doesn't
necessarily
have
to
be
stored
in
key
enhancements
as
a
like
an
actual
item
in
there,
it
could
be
dumped
to
like
a
gcs
bucket
or
something
like
that,
and
it
can
pull
it
from
there
or
you
know,
have
it
be
in
in
both
places.
It
doesn't
matter
too
much.
A
I
A
So
just
lori
just
note
that
it's
not
pre-submit
it's
either
periodic
or
post
cement.
C
A
Yeah
so.
D
A
Can
we
can
do
it
on
merges
or
we
can
do
it
on
on
a
schedule
right?
So
if
we
had,
you
know
for
enhancements
at
least
people,
I
imagine
people
are
going
to
be
a
little
neurotic
about
that
and
want
to
be
like
is
it
in?
Is
it
in?
You
know.
A
But
but
yeah
again
it's
it's
it's
one
of
the
many
factors
that
we
can
we
can
play
around
with
and
we
don't
need
to
to
set
just
yet.
F
F
F
A
So
we
need
the
so
I
noticed
that
we
do
not
have
the
pr
templates
the
pr
templates
could
use
updates.
I
think
there
is
an
update
in
flight
from
anna
about
the
docs
within
the
pr.
B
A
Also
need
a
general
template
for
when
you're
requesting,
when
you're
requesting
enhancements
to
the
enhancements
process
right
so
features
for
enhancements
that
are
not
enhancement,
issues.
A
F
A
Switch
back
to
the
issue
real
quick
sure
this
is,
this
is
again
kind
of
brain
dumped
from
what
was
in
617
originally.
So
we
somewhat
have
a
glossary
of
terms.
We
do
not
have
as
many
issue
templates
as
we
could.
Oh
pr
templates
do
we
have
pr
templates,
I
think
we've
something
to
check
as
well.
So
if
someone
wants
to
check
on
the
issues
and
pr
templates
go
for
it,.
H
A
Exception
process
update,
I
think,
we've
we
shipped
the
exceptions
process
stuff
over
to
k,
release
right,
it's
exceptions.md
or
something
or
I'm
wrong.
I
don't
know
where
it
lives
right
now.
It's
probably
nk
release
alongside
the
release
team
documentation,
so
so
outside
of
that,
I
think
really
handling
the
templates
and
click
that
issue
one
more
time.
Yeah
handling
the
templates
and
making
sure
that
we
feel
cool
with
the
glossary
would
be
the
remaining
pieces
to
close
this
out.
A
Yeah
I
yeah,
I
don't
know
offhand,
I
would
say
it
looks
like
arno
and
myself
are
assigned
to
that
right
now.
If
someone
we
can
check
in
with
arno,
but
from
last
meeting
he's
got
a
bunch
of
stuff
he's
cranking
on.
So
if
someone
is
interested
in
picking
that
up,
because
I
am
definitely
not
working
on
it
right
now,.
F
All
right
so
we'll
un-assign,
you,
maybe
maybe
my
former
colleague,
can
take
a
look
at
this
I'll.
Ask
him
cool
okay,
then
I
think
maybe
the
issue
here
about
enhancement,
slip.
F
F
I
put
a
little
comment
for
you
and
then
the
two
items
from
jeremy
they're
related,
but
he
he
claimed
those.
G
I
have
a
pr
that
I
think
is
done
for
that
didn't
get
a
chance
to
open
it.
Yet,
okay,
that's
my
plan.
G
G
Yep,
so
this
one
is
super
manual
right
now,
because
you
have
to
go
look
at
all
of
the
spreadsheets
and
kind
of
rely
on
people
moving
them
to
the
right.
I
mean
this.
The
stretching
mostly
automates
the
changes
and
status
and
stuff,
but
that
really
only
goes
back
to
like
117,
so
carrying
historical
stuff
over
from
previous
releases
is
harder
because
there
wasn't
as
much
automation.
G
Things
were
removed
or
dropped
in
some
of
the
older
spreadsheets
for
different
reasons
like
if
they
just
didn't
act,
it
was
in
and
then
it
was
dropped
versus
they
just
never
got
trapped
and
then
it
was
dropped.
I
think
that
there's
not
much.
We
should
do
here
until
we
get
to
the
receipts
process
and
we
have
more
trackable
data.
I
mean
I
think
we
can.
G
We
can
kind
of
continue
this
and
just
look
say
sense,
117
and
keep
a
running
metric
or
running
a
report
somewhere,
but
I
think
that
the
what
we're
going
to
do
with
like
removed
from
the
the
remove
bucket,
I
think,
will.
G
A
Yeah,
no,
I
I
agree
that
I
don't
want
anyone
doing
this
manually
honestly,
like
yeah,
so
let's
hold,
let's
hold
until
receipts
land.
G
Yeah,
so
this
one-
I
don't,
I
don't
know
if
we
can
enforce
things
slipping
like
that.
I
think
that
I
mean.
Maybe
we
can
come
in
and
be
more
more
strict
about
those
things,
but
I
think
that
what
we
should
do
here
is
it's
less
on
us
at
this
point
like
to
to
really
ping,
and
my
worry
with
the
slipping
things
is
from
the
releasing
perspective,
at
least.
Is
that
it's
hard,
it's
actual
toil,
and
we,
if
these
things
slip
all
the
time?
G
It's
just
we
know
these
things
are
probably
going
to
slip
for
some
reason
or
another.
I
I
I
don't
know
if
there's
a
lot
of
benefit
that
comes
from
like
trying
to
stick,
this
kind
of
perma-beta
thing
in
because
it
it'll
be
it'll,
become
it'll,
become
the
problem
of
the
sigs
at
that
point,
yeah
for
the
most
part.
A
Tracking
this
right
now
provides
us
with
more
work,
and
I
think
I
think
that
the
the
effort
is
better
suited
in
kind
of
improving
the
tools
that
we
have
right
now.
Honestly,
this
is
work.
This
is
work,
that
is,
we
are
responsible
for
shepherding
this
process
right.
A
The
sigs
are
responsible
for
landing
their
enhancements
right,
so
we
need
to
provide
them
an
effective
playground
to
work
in
yeah
and
they
have
to
do
the
things
that
are
required
right
so
like
this,
I
don't
I'm
not
sure
what
benefit
tracking
provides
for
us.
I
think
it's
more
of
a
benefit
for
cigs
overall
yeah,
you
know,
let's,
let's
make
it
easier
for
them
to,
let's
make
it
easier
for
them
to
commit
or
not
commit
to
something
first
right
and
then
from
there
we
have
a
better
idea
of
like
well.
A
G
E
Sorry,
it's
sort
of
out
of
context.
Now
we
were
talking
about
things
in
in
the
capital
template,
but
I
I
know
I
have
been
as
we
get
more
and
more
caps,
I'm
seeing
more
and
more
caps
that
are
dealing
with
the
same
feature
and
not
always
from
the
same
seg
and
as
such,
it
seems
like
we're.
We
need
to
start
tracking,
which
enhancement
requests
actually
relate
to
which
other
enhancement
requests
you're.
Looking
so.