►
From YouTube: 20201208 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
december
8th
that
this
is
a
enhancement,
subproject
meeting
of
sig
architecture.
This
is
a
meeting
that
is
recorded
and
available
on
the
internet
will
be
available
on
the
internet
later
for
viewing.
So
please
be
mindful
of
what
you
say
and
do
please
be
sure
to
adhere
to
the
kubernetes
code
of
conduct
and
in
general,
just
be
awesome
people.
So
we've
got
a
few
things
on
the
agenda,
but
I
also
see
a
potentially
new
face.
Do
you
want
to
say
hi.
B
Yes,
my
name
is
jacob.
I
work
on
I
work
at
aws
and
I
don't
have
a
big
agenda
or
anything
have
somebody's.
Looking
at
my
video,
I
just
was
hoping
to
check
out
what's
going
on
sort
of
lurk,
expose.
A
Lurking
all
right,
so
jeremy,
you
want
to
kick
it
off.
Jeremy
and
navaroon.
Kick
it
off
with
a
receipts
update.
C
Yeah
sure
number
do
you
want
to
talk
about
your
cap
work
so
far.
D
Yep,
so
I
raised
the
kepia
like
two
weeks
back
evading
reviews
on
things:
the
implementation
history,
so
the
details
part
is
still
a
bit
wonky
like
I
was
going
over
the
notes
in
the
roadmap
documentation
and
trying
to
do
a
mind
map
of
like
how
that
thing
will
exactly
fit
into
the
cap.
D
I
was
a
bit
confused
and
I
wanted
some
reviews
on
that
part.
So
one
question
was
like:
are
we
going
to
do
the
tooling
for
1.1?
I
think
jeremy
dropped
the
question
as
well
in
today's
meeting
notes.
Based
on
that,
I
think
I
I
feel
like
we
should
decide
on
whether
to
put
all
those
implementation
stuff
in
the
cap
at
the
current
state
or
not.
So
that's
what
like.
D
I
was
bike
sharing
with
my
own
mind
that
whether
we
should
do
it
or
not-
and
I
went
through
all
the
reviews
that
were
already
put
by
kirsten
laurie,
and
I
think
someone
also
put
more
comments.
Sorry
for.
D
Yeah,
so
I
was
going
through
the
comments
and
resolved
most
of
them,
which
I
thought
like
we're
saying
just
to
have
more
reviews
on
it.
Yeah,
that's
all
on
my
part,
right
now,
jeremy,
you
want
to
add
more
yeah.
C
I'm
gonna
I'm
reviewing
what's
there
right
now,
since
I
have
a
little
bit
of
free
time.
I
think
the
major
question
is:
I'm
gonna.
Ask
your
question
now
kirsten
see
you
oh.
C
Okay,
cool
yeah,
so
the
chair
recognizes
kirsten
after
I'm
done
talking.
I
think
that
we
should
get
the
kept
nail
down
and
figure
out
what
pieces
of
it
we
want
to
automate.
We
wouldn't
provide
tooling
for
like,
because
you
could
step
back
and
think,
like
the
whole
thing
could
be
done
manually
for
121
it'd,
be
extra
work
and
it
would
probably
be
less
ideal,
but
I
think
we
can
identify
the
minimal
set
of
things
like
people
can
create
the
kep
receipt
themselves
like
it's
a
small
piece
of
yaml.
C
That
should
be
something
that
people
can
do
by
hand.
I
think
we
can
build
validation
to
make
sure
that
it
has
the
things
that
are
necessary
and
we
can
build
like
a
summarization
function
to
like
to
build
the
manifest
or
the
top
level
of
the
receipt,
and
I
think
those
are
like
the
to
me
would
be
the
minimum
things
we
would
want
for
121..
We
can
go
past
that
too,
but
I
think
those
would
be
the
two
that
I
would
want
to
see
in
terms
of
tooling
that
we
would
need
in
place.
C
I
think
the
rest
of
it
is
all
nice
to
have
like
making
it
easier
for
people
to
reference
a
cap
and
have
it
generate
the
the
metadata
for
them.
I
think
is
all
nice
gravy
stuff
afterwards,
but
I
think
for
one
like
nailing
down
the
cap
and
getting
getting
all
the
reviews
in.
It
probably
needs
to
happen
soon.
If
we're
going
to
do
this
for
121,
because
we're
getting
towards
the
end
of
the
year
and
then
121
is
going
to
start.
C
So
I
think
we
should
set
ourselves
a
deadline
of
having
reviews
done
this
week
and
try
to
incorporate
the
feedback
this
week.
Just
so
we
can
have
that
done
and
start
communicating
it,
because
I
think
that's
going
to
be
the
hardest
part
is
communicating
to
people
so
that
they
know
that
hey.
This
change
is
coming
you're
going
to
need
to
do
these
things
differently
for
121.,
like.
B
C
Obviously
communicate
that
stuff
1121
starts
up,
but
that's
going
to
be
at
the
beginning
of
the
year
and
then
there's
not
a
whole
lot
of
runway
after
we
start
communicating
that
at
the
beginning
of
the
year
before
people
have
to
start
doing
those
things
during
the
enhancements
collection
process.
So
I
think
that's
the
biggest
decision
point
right
now.
Are
we
sure
we
can
do
this
for
121?
Can
we
get
it
reviewed
and.
E
I
actually
have
a
question
about
this
because,
like
I
was
thinking
about
this
yesterday
and
now
like
it's
like
kind
of
bothering
me
that
we're
using
a
cap
to
change
the
enhancement
process,
but
then
we're
not
following
the
enhancement
process
like
it
feels,
especially
because
it's
like
a
real
change
to
the
process
like
it
reminds
me
of
the
discussion
that
we
were
having
about
deprecations.
Just
last.
B
E
C
E
Without
very
much
warning,
and
without
necessarily
like
a
lot
of
testing
and
instruction
about
how
to
really
go
about
doing
this
in
a
way
that
doesn't
just
throw
everything
into
disarray,
and
so
what
I'm
wondering
is
like
one,
it
kind
of
sets
like
a
bad
example,
but
then
two
I
almost
feel
like
and
somebody's
gonna
yell
at
you,
but
that's
fine.
I
always
feel
like
the
cap
itself.
It's
not
done
right.
The
cap
is
not
done
and
it
wasn't
done
in
120..
I
feel
like
maybe
a
goal
for
this
is
finish.
E
E
Like
I
could
open
a
cap,
I
could
use
the
neutral
or
the
new
process
and
tell
you
how
it
goes
and
so
could
other
people,
maybe
a
sig
chair,
maybe
just
someone
who
just
wants
to
volunteer
like
there's,
there's
a
couple
of
authors
that
I
think
would
probably
do
it
and
get
that
feedback
along
with
and
and
the
great
part
of
doing
it.
E
Okay,
like
it's
more
fully
rolled
out
after
we
have
it
for
x
cycles,
because
I
I
just
envision
like
the
more
I
think
about
it.
The
more
I
think
that
it's
gonna
really
cause
a
lot
of
like
drama,
especially
since
it's
the
first
half
of
the
year
after
vacation,
especially
since
the
cap
itself
isn't
finished,
and
there
hasn't
been
like
this
idea
of
it
circulated
that,
like
maybe
just
leveraging
the
process
a
little
bit
better
and
having
people
test
it
out.
E
Right,
like
could
just
be
like
the
the
easier
roll
out,
because
I
would
hate.
B
E
Roll
it
out
and
it
just
causes
so
much
disarray,
people
hate
it
and
then
you're,
just
like
fighting
with
people
constantly,
because
they're
not
aware
of
it.
You
know
like
it
was
a
real
challenge
to
get
like
there's
a
lot
of
authors
and
sigs
that
we're
just
bringing
into
the
fold
of
the
enhancement
process
and
really
trying
to
get
them
to
participate,
and
now
we're
basically
telling
them.
Okay,
like
you,
have
to
do
it
completely
differently.
E
Now
with
no
warning,
and
I
I
just
think
that
that's
going
to
cause
like
a
lot
of
of
issues
when
we
could
potentially
leverage
the
enhancement
process,
which
and
and
this
is
a
cat-
I
mean
that's.
The
other
problem
is
like
this
was
rolled
out
as
a
cat,
but
I
just
think
leveraging
that
process
to
make
sure
that
we
get
it
right
might
make
121
easier.
A
So
I
think
that
we,
I
think
that
we
are
leveraging
the
process
by
writing
a
cap
about
a
kepp.
It's
essentially
it's
essentially
one
of
the
the
few
medic
that
we
have.
I
don't
disagree
with
some
of
your
points,
but
I
do
think
that
the
way
we
have
gotten
things
done
in
the
past
is
by
enforcement,
as
opposed
to
like
kept
people
started
doing
caps
when
kept
became
a
requirement
for
the
release
process.
A
There
was
a
lot
less
buy-in
before
that
when
we
decided
between
architecture
and
and
release
that
it
was
going
to
be
a
requirement
for
the
release
process,
that's
when
it
actually
started
happening
right.
So
so
I
think
that
we
do
need
the
requirement
and
I
think
that
it
can't
be
a
a.
Maybe
you
can.
Maybe
you
can't
right,
because
that's
no.
E
A
Sorry
yeah,
so
so
I
think
that
that's
gonna
that
allows
people
the
wiggle
room
that
we
don't
want.
I
will
agree
with
the
point
that
maybe
it's
too
soon,
maybe
it's
too
soon,
and
maybe
we
are
not
as
baked
as
we
want
to
be.
Maybe
we
say
that,
like
you
said,
maybe
we
say
that
121.
A
This
is
a
thing
that
we
are
going
to
be
turning
on
for
122.,
you
need
to
be
prepared
for
it.
Here's
how
you
do
the
thingy
right
and
and
make
sure
that
the
cap
is
complete.
I
think
that
what
is
there
is
really
great
right
now.
I
think
going
back
to
your
point,
jeremy,
the
the
goal
for
this
was
always
the
first
iteration
of
this
was
going
to
be
a
manual
manual
and
and
and
that's
kind
of
it
manual,
and
then
we
would
do
the
generation
and
then
everything
else
would
come
afterwards.
A
So
I
think
you
know
what
comes
out
of
that.
Is
that,
let's
make
sure
that
what's
written
down
right
now
is
d
scoped,
to
to
note
that
to
note
that
the
first
phase
of
this
will
be,
you
have
to
submit
one
of
these
tiny
receipts
yourself
and
we
will
generate
the.
We
will
generate
the
the
larger
manifest
and
then
moving
forward
as
we
as
we
you
know,
put
together
feedback
and
and
build
that
into
the
tool.
A
The
tool
will
get
better
and
better,
but
you
need
to
give
us
feedback
so
that
we
can
make
it
better.
So,
overall,
I
I
agree.
I
will
note
that
this
is
a
cap
that
is
out
of
tree,
so
it
has
different
rules
and
it
is
also
process
cap.
So
it
has
different
rules
than
one
for
something
that
is
landing
within
kubernetes
kubernetes.
C
Yeah,
I
I
definitely
the
reason
I
added
the
like
the
question:
can
we
get
this
for
121
is
because
I
have
a
concern
that
we're
going
to
run
into
just
calendar
and
it'll
be
unpleasant
for
people,
and
I
I
definitely
don't
want
to
make
people
unhappy
during
the
early
part
of
the
release.
I
think
it's
all
already
can
be
stressful
enough,
like
trying
to
get
those
things
like
their
cups
themselves
merged
and
having
them.
C
Adapt
to
this
new
thing
will
probably
be
a
little
challenging,
and
that's
I
mean
I
think,
that's
what's
been
on
my
mind
for
the
last
couple
of
days
like
for
the
same
reasons
like
we
didn't,
communicate
the
doctorship
thing
very
well
and
people,
I
mean
it's
not
the
same
thing,
but
you
know
it's
still
communications
and
I
think
people
were
kind
of
upset
and.
C
Thing
for,
like
the
exec
probe
thing,
it's
coming,
it's
not
a
big
change,
but
it
didn't
get
communicated
to
people
and
there
was
some
feelings
that
were
not
great
feelings.
So
I
don't
want
to
end
up
with
not
great
feelings
towards
this
process
by
yeah
sticking
it
in
like
at
the
end
of
the
year
and
saying
hey
january.
4Th
is
here
start
doing
this
thing.
A
E
You
know
in
122,
there's
going
to
be
a
different
process
and
just
like
build
that
like
bake
in
that
awareness
because
sometimes
like,
if
you
have
to
blast
everybody,
it's
a
lot
harder,
but
you
can
build
that
sort
of
like
okay,
things
are
going
to
change
kind
of
idea
into
the
121
process.
So
by
the
time
you
know
the
announcement
comes
and
the
new
rules
are
in
place
for
122.
E
There's
been
this
like
awareness
of
it.
So
it
also
means
that
people
can't
argue
as
much
there's
going
to
be
a
little
bit
less
pressure,
because
I'm
more
concerned
about
the
release
team
and
the
pushback
that
all
the
shadows
and
all
the
individuals
you
might
get,
and
I
think
that
just
like
giving
that
extra
notification
cycle.
So
that's
like
look.
This
is
the
rule.
Now
this
is
what
you
have
to
do.
We've,
let
you
know
for
one
release.
We
told
you
what
it
was
going
to
be.
A
A
So,
if
we,
if
we
take
121
as
a
development
cycle
and
a
kind
of
pre-notice
cycle,
I
think
it
also
gives
us
an
opportunity
to
set
the
good
example
of
of
saying
like
this
is
how
we
should
communicate
things
in
the
community
and
and
additionally,
it
gives
the
the
release
team,
the
incoming
release
team,
an
opportunity
to
focus
on
tightening
how
we
do
communications
overall
right
and
use
that
as
a
focus
for
121,
as
opposed
to
trying
to
drive
receipts.
E
I
think
that
we
will
be
able
to
also
coordinate
whoa.
Is
that
my
mind
what's
wrong
with
my
mic?
I
think
that
we'll
also
be
able
to
like
coordinate
with
you
know
like
comms
or
whoever
else
we
need
to
communicate
with,
like
maybe
josh
burkus,
maybe
like
just
get
the
build
a
little
bit
more
awareness
of
what's
going
on.
I
think
that,
like
we
would
really
have
that
opportunity
in
that
121
cycle
yeah.
I
I
I
was
just
thinking
about
it
the
other
day,
and
I
thought
I
would
just
bring
it
up.
A
No
thank
you
for
raising
it.
I
think
it's
smart,
it's
smart,
because
I
think
that
we
constantly
deal
with
perception
and
kind
of
like
the
the
mps
score
of
the
community.
So
that's
yeah.
So
that's
a
good
point.
I
think
we're
all
in
agreement.
So,
let's
let's
table
it
until,
let's
still
get
it,
let's
see
if
we
can
push
what
we've
got
over
the
finish
line,
at
least
to
get
the
docs
down.
A
Have
it
reviewed
as
a
team
and
ship
that
to
the
wider
community
for
their
review
and
from
there
I
think
we
focus
on
using
121
as
a
development
cycle
instead
right
cool.
Any
questions
comments,
concerns
about
this.
D
I
have
one
question
so
in
the
next
release
cycle,
will
we
be
working
on
validations
as
well
to
be
shipped
for
1.22,
but
like
validating
the
manually
generated
receipts.
C
C
Okay,
so
I
recorded
two
things
as
decisions:
we're
going
to
target
122
as
the
the
launch
of
this
121
will
be
a
development
cycle
and
then
we're
going
to
start
with
a
phased
approach
in
the
cap.
Implementation
about
manual
at
first
graduating
up
to
more
tooling,
as
we
have
bandwidth
and
feedback.
E
Oh
no,
I
just
I
just
know
that,
like
the
last
release
actually
went
pretty
well
except
for
some
outliers,
and
I
think
it
would
be
great
if
you
know
like
we
just
build
on
that,
like
we're,
getting
more
people
to
buy
in
we're
getting
sticks
to
buy
in
and
if
we
can
kind
of
just
have
the
tool.
As
an
extension
of
that,
I
think
it's
going
to
be
really
good.
A
A
So
we
will
save
that
note
for
later
future
topics.
Let's
get
that
into
future.
A
A
Also,
I
should
mention
or
throw
it
out
to
the
group.
I
would
like
to
make
this
meeting
shorter
moving
forward.
I
think
there
was
a
soft
mandate
a
while
back
to
do
25
or
50
minute
meetings.
I
think
everyone
there's
there's
a
lot
of
overlap
between
people
who
are
here
and
people
who
are
on
the
sig
release
or
release
engineering
calls
immediately
beforehand.
So
that
is
like
back-to-back
meetings.
Let's
give,
let's
give
each
other
a
break,
I
think
so.
A
For
the
new
year,
we're
gonna
shift
these
two
to
50
minutes
and
get
a
password
and
like
also
decide
like,
is
this
meeting
time
working
for
everyone?
If
it's
not,
we
can
assess
that.
I
think
we
we,
you
know
often
have
people
who
need
to
drop
from
this
time.
E
D
E
I
I
would
I
mean
for
me,
tuesday,
tuesdays
tend
to
be
very
busy
this
meeting,
so
the
time
isn't
like
super
great
for
me,
so
I'm
definitely
willing
to
have
a
time
change.
A
A
Now
I
don't
have
a
great
understanding
of
the
entire
scope
of
like
the
conformance
tests
and
how
and
when
they're
done
and
what
needs
to
happen,
but
we
were
chatting
at
the
we
were
chatting
at
the
sig
architecture
meeting
last
week
and
one
of
the
things
that
hippie
raised
was.
A
It
would
be
great
to
have
kind
of
an
idea
like
if
you
look
through
some
of
what's
written
here,
it'd
be
great
to
have
an
idea
of
when
an
api
is
exposed
and
the
kind
of
operations
and
what's
yeah,
essentially
what
operations
we're
looking
for
when
that
api
is
doing
things
right.
Having
this
as
an
additional
piece
of
metadata
would
give
us
the
ability
to
start
to
track
the
way,
an
api
changes
over
time
and
kind
of
how
how
it's
changing
between
different
milestones.
A
I
would
argue
that
maybe
this
is
information
that
could
be
stuck
in
the
milestone
struct,
but
standalone
is
fine
too.
I'm
curious
to
hear
your
thoughts
on
what
you
all
think.
E
G
Okay,
well,
I
think
that
I
turned
off
my
headphones
because
it's
making
me
crazy,
like
this,
actually
came
from
like
a
kept
exception,
just
as
background
kept
exception
that
we
had
that
after
it
was
merged,
it
was.
E
By
chance
that
he
happened
to
be
looking
and
noticed
that
there
was
a
conformity
he
did
so,
I
think,
like
just
part
of
the
motivation
of
this,
is
like
we
can't
rely
on
chance
of
the
right
person
looking
at
the
pr
or
at
the
cat
and
then
knowing
enough
to
ask
whether
this
needs
a
conformance
test
so
like
he
was
able
to
catch
it.
I
think.
G
I
want
to
say
it
was
sergey's
enhancement.
I
don't
really
remember
dance.
So
from
that
perspective,.
E
A
Yeah,
my
first,
I
think
my
first
stare
at
this
is
because
I
don't
work
on
api
changes
in
general.
My
first
question
here
is:
it
sounds
like
it's.
It's
definitely
starting
to
sound
like
we
have
different
classes
of
caps
right.
We
have
some
that
are
focused
on
process
delivery
right.
The
triage
kept
the
receipts
thing
that's
coming
in
the
you
know
the
enhanced
the
kept
617
one
where
they're
strictly
focused
on
process
they
may
be
out
of
tree.
A
They
may
affect
something
that
is
in
tree,
but
it's,
but
the
code
is
not
directly
entry
right.
Then
we've
got
we've
got
enhancements.
That
may
be
intrigued,
but
may
not
directly
affect
an
api
right
and
like
what
do
we
call
those
and
then
you've
got
the
you
know
kept
like
that's
like
this
idea,
which
would
be
an
api
change
right.
A
So
maybe
it's
worthwhile
to
keep
the
api
specific
information
outside
of
any
struct
that
we
would
use
for
for
other
cap
types
and
then
maybe
it's
also
worthwhile
taking
a
crack
at
defining
different,
kept
types,
because
I
think
there
is
an
open
issue,
there's
an
open
issue
for
do.
We
use
caps
for
policy
changes.
I
think
was
something
that
was
opened
by
aaron
aaron.
I
think
a
while
back,
and
the
answer
is:
maybe
it
really?
A
I
think
it
depends
on
the
sig,
how
close
it's
you
know
how
close
it
is
to
touching
kubernetes
kubernetes
like
there
are
lots
of,
I
think,
a
lot
lots
of
workflow
things.
You
know
a
decision
tree
to
kind
of
step
through
right.
If
you
look
at
it
from
kind
of
a
cluster
lifecycle
perspective
right,
they
have
their
own
kep
process
right
where
changes
to
cluster
api,
don't
even
land
in
enhancements
right.
A
So
that's
an
entirely
different
world
and
and
again
that's
something
that's
out
of
tree,
so
we
don't
necessarily
care
for
it
to
conform
right,
although
it
does
it's
kind
of
a
one-to-one
mapping
between
the
between
their
cat
caps,
ca
ep
their
cluster
api
enhancement
proposals
and
the
caps
themselves
right.
So
I
think
I
think
like
when
one
when
is
an
enhancement
in
enhancement,
we
have
some
of
this
documentation
already.
What
are
the
diff
different
types
of
enhancement?
A
Proposals
that
we
might
see
could
be
an
interesting
question
to
tackle
in
the
future,
and
if
we
want
to
do
something
api
related
right,
how
do
we
provide
historical
information
about
it
right
this?
This?
The
set
of
fields
is
a
good
example
of
how
to
do
that,
but
I
think
that
it
also
dovetails
into
a
conversation
about
about
communication
right
about
communication,
about
standing
up
receipts
right
because
it
all
goes
back
to
like
how
early
can
you.
A
E
Yeah
I
just
typed
in
the
chat
I
was
like
well,
you
know,
like
we
have
kkpr
say
like
api
review
required
or
they're
tagged,
but
we
really
need
to
capture
that
with
a
little
bit
more
information
in
the
cast,
because
the
thing
is.
Is
that,
like
not
everybody's?
Looking
at.
D
E
A
Yeah-
and
I
think
I
think
that
it-
you
know
it
kind
of
correlates
to
the-
if
you
think
about
like
the
the
prod
readiness
review
stuff
too,
being
able
to
flag
that
something
needs.
Some
sort
of
review
is
pretty
important
and
I'm
not
sure
that
we
have
a
good
mechanism
for
doing
that
right
now.
A
Further
being
able
to,
I
think
a
harder
question
is:
how
do
we
tie
something?
That's
in
flight
to
a
cap?
There's
there's
no
way
to
do
that.
Right
now,
outside
of
a
guarantee,
are
a
hope
from
the
author
of
the
prs
that
they
will
either
link
link
the
kep
in
some
way
or
come
back
and
update
the
implementation,
history
and
there's
no
way
to
essentially
extract
information
from
the
implementation
history,
assuming
it's
up
to
date
to
kind
of
gain.
A
A
B
A
Yeah,
I
think
I
think,
what's
worthwhile,
I
don't
know
how,
when
who
should
be
responsible
for
doing
this,
but
like
there,
there
is
likely-
or
there
is
definitely
a
backlog
of
caps
that
are
under
loved
and
that
don't
meet
certain
criteria.
Right
is
there
something
that
we
can
or
should
be
doing
on
our
side,
to
make
that
more
visible
to
people.
B
A
To
depending
on
how
you
set
up
the
you
know,
set
of
assemblings
and
yada
yada,
so
I
think
it's
you
know
it's
it's
worthwhile
to
maybe
look
into,
although
I
won't
call
it
like
one
of
our
top
line
objectives
right.
E
Well,
conversions
usually
do
require
content
changes,
because
the
new
template
requires
more
information
than
the
old
template
like
so
I
I
would
just
by
default,
say
that
any
upgrade
is
going
to
have
a
content.
Change
upgrade
like
change
of
template
is
going
to
have
a
content
change,
because
otherwise
the
text
is
going
to
be
incomplete.
A
So
I
I
say
that
to
say
that
I
converted
all
the
sig
release
caps
into
the
new
into
the
new
format
without
content
changes,
so
they
are
out
of
date.
A
A
Yeah,
I
think
I
think
we
need
an
indicator
that
is
not
just
the
the
last
updated
date
for,
and
I
think
we've
also
proven
that
the
last
updated
date
are.
The
field
specifically
was
not
useful
because
we
removed
it
right.
We
we
decided
to
depend
on
the
github
updates.
Instead,
so
yeah
work
to
be
done
there.
I
won't
say
it's
the
most
important
work
I
think
convincing
sigs
that
it
is
information
they
should
provide,
is
maybe
more
important
than
trying
to
do
it
ourselves.
F
Sorry,
did
you
ask
for
me
because
I
are.
A
So
tldr
on
receipts,
we
are
going
to
continue
forward
with
refining
the
cap.
What
we
are
going
to
do
is
hold
off
on
trying
to
deliver
it
for
121.
use,
121
as
a
development
cycle
and
an
opportunity
to
kind
of
pre-announce
it
to
the
community
and
then
and
then
go
full
force
for
122.
F
A
C
I
think
the
api
snoop
stuff
they're
doing
is
giving
them
a
pretty
good
idea
of
what
hasn't
been
updated.
It
doesn't
have
those
things
to
find
and
I
don't
think,
there's
anything
that
kept
that
defines
that,
but
I
think
it
gives
a
good
picture
of
things
that
would
need
to
be
updated.
If
we're
going
to
add
this
as
required
stuff,
let's
probably
go
hand
in
hand,
we
can.
B
C
Out,
what's
what's
the
minimum
thing
we
want
to
add,
I
think
it
is
worth
tracking
and
adding
just
so
people
don't
forget,
I
think,
looking
at
the
when
when
hippie
was
showing
the
the
dashboard,
they
had
there's
a
lot
of
stuff.
That
has
a
lot
of
it's.
B
A
But
it's
like
it's
very
it
is.
It
is
nebulous
to
be
honest
when
you
start
looking
at,
especially
if
you
you
come
from
the
perspective
where
you
don't
understand
it,
and
then
you
have
to
understand
that
like
where
there
is
and
isn't,
coverage
and
kind
of
like
where
there
isn't
coverage
is
scary.
A
To
be
honest,
so
I
think
yeah
getting
a
better
understanding
of
the
tool.
I
would
say
that
another
kind
of
axis
of
this
is
we
are
adding.
I
think
that
it
is.
A
I
think
that
we
need
to
assess
what
we
are
and
aren't
adding
to
the
metadata,
and
there
should
perhaps
be
a
process
around
when
we
do
and
don't
add
things
to
the
metadata,
because
when
we
do,
we
essentially
say
okay,
you
have
to
go.
Do
this
now
right,
like
the
metadata,
is
our
api?
Essentially
right?
So
when
we
add
things
we
we
basically
say
like
you
got
to
go.
Do
this
now
and
like
any
any
addition
or
any
proposal
to
add
something,
it
should
be
considered
an
api
change
review
type
situation.
A
I
think
that
we
have
some
flexibility
now
that
it
is
a
little
bit
more
loosely
defined,
but
I
think
that
we're
quickly
moving
into
an
area
where
multiple
streams
will
depend
on
this
being
valid
and
not
shifting
frequently
so
as
we
do
that,
especially
as
the
receipts
process
comes
into
play
and
you're,
and
we're
doing
metadata
validation
that
we
need
to
make
sure
that
it's
not
moving
around
one
of
the
one,
maybe
a
good
example
of
the
of
a
change
that
is
required.
A
I
think
from
from
my
perspective
and
but
how?
How
do
we?
We?
How
do
we
do
it
effectively
right?
So,
if
you
look
at,
let's
go
to
the
board.
A
So
if
you
look
at
what's
in
progress
and
boom
right,
so
if
you
look
at
this
pr
from
from
jeremy
jeremy
morris,
we'll
see
that
a
few
things
happened
right
added
an
open
sections
thing
to
the
kept
template
and
open
question
section.
I
think
that
this
is
actually
something
that
we
want
people
to
answer
within
the
cap
and
not
within
the
metadata
right
yeah.
That
was
kind
of
my
read
on
it.
A
I
do
kind
of
there's
something
I
like
about
the
unresolved
bit
because,
like
we
can
key
off
of
that,
but
I
think
for
now
it
probably
makes
sense
for
it
to
just
be
in
human
as
opposed
to
in
the
yaml,
but
the
so
so.
Thoughts
on
that
first
part.
A
And
I
think
it
it's
also
like
context-less
right,
the
second,
you
move
it
over
into
the
ammo.
It's
like!
Well,
it's
an
open
question
about
what
it's
a
thing
in
the
cap
and
then
you
go
to
the
cap
and
you're
like
well.
It
probably
should
have
been
in
the
cap
already
right,
like
just
give
me
one
place,
so
that
will
be
one
piece.
A
I
think
the
the
second
interesting
part
about
this
pr
is
checking
out
checking
out
the
what
what
happened
around
the
groups
right
so
there's
a
request
and
essentially
like
what
what
I
was
mentioning
was
that
for
a
cap
that
has
participating
groups,
not
all
of
those
groups
are
necessarily
sigs
right.
So
I
think
it's
more
accurate
to
call
it
participating
groups
as
opposed
to
participating
right.
So
this
is
something
that
was
up
on
a
board,
and
this
became
a
search
and
replace
right.
A
So
you
can
see
that
across
you
know
all
the
caps
and
an
update
to
the
tests
and
a
you
know
update
to
the
the
ammo
validation
bits
and
proposal.
Structs
right
discord
go
away
so.
E
A
I
no
I
I
think
we
should
do
it.
I
think
if
we
are
going
to
say
that
we're
making
a
change
one
if
we
are
making
a
change
that
is
minimal,
I
think
it's
absolutely
fine
like
this
is.
This
is
a
pretty
small
change.
It's
just
a
very
small
change
times.
All
of
the
caps
right.
I
think,
if
we're
going
to
make
a
tiny
change
like
that,
then
we
should
not.
This
is
kind
of
like
to
the
user.
Satisfaction
point
where
we
shouldn't
be
like
hey.
A
You
got
this
like
we
changed
this
one
little
field,
and
now
you
have
to
go
update
all
your
caps.
Well,.
E
A
Yeah,
that's
fine,
I
think
you
know
if
the
field
was
wildly
different,
I
would
have
different
opinions
on
it,
but
this
is
pretty
small
in
the
grand
scheme.
I
think
we
still
need
to
go
through
the
the
exercise
of
deciding
who
updates
these
things
to
new
formats.
Like
really,
I
think
this
is
sig
responsibility,
so
kind
of
poking
them
to
do
that
moving
into
121.
A
If
I'm
changing
a
field
from
one
field
to
the
other,
it
shouldn't
have
to
be
a
search
and
replace
right.
I
should
be
able
to
run
a
generator
based
on
our
tooling
to
say,
like
old
field,
to
newfield
spit
me
out,
what's
supposed
to
happen
as
a
result,
right
and
and
then
that
becomes
a
generated
commit
by
itself
right.
A
So
that's
one,
I
think.
Like
that's
one
idea
I
had
as
looking
as
I
was
looking
through
this
cap.
I
think
it's
this
pr.
I
think
it's
fine
to
merge
outside
of
fixing
this
open
questions
thing,
but
I
would
say,
take
a
look
at
this
one
yeah.
A
A
So
so
drop
drop,
a
review
on
that
yeah
yeah,
and
I
I
think
you
know
outside
of
that.
We
should
have
the
conversation
about
like
converting
fields
right
and
how
often
we're
like.
Are
we
willing
to
do
it?
How
often
will
we
won't
we?
What
is
the
process
for
doing
so
right?
Because,
right
now
it
does
seem
like
a
few
people
come
by
and
they're
like
hey.
We
want
to
add
this
thing
and
really
cool
whatever
like
there.
You
go
that
eventually
it's
going
to
come
to
a
point
where
we're
like.
B
E
Changes
the
problem
is,
is
that
it's
really
hard
to
tell
what
version
someone
like
like
there's
a
the
big
major
version
changes
right,
where
it's
like
you're,
going
from
the
one
file
to
two
files
like
I
can
eyeball
that
change
like
pretty
easily,
but
the
odds
that
we're
gonna
change
from
two
files
to
like
three
files
or
the
one
file
again
are
low.
So
going
forward.
E
It's
going
to
be
really
hard
to
like
at
a
glance
tell
what
version
of
a
cap
anybody's
on
without
having
to
like
either
create
a
tool
to
like
scan
all
of
the
ammo
fields
or
eyeball
it
or
something.
So
it
might
just
be
worth
having
like
a
version
field
and
then
collecting
a
bunch
of
kept
changes
and
aggregating
them
together
and
then
putting
them.
E
That's
what
a
version
is
and
then
putting
the
wallet
into
a
version
that
starts
on
x
release
because
they
kind
of
trickle
in
which
is
confusing
too,
like
even
to
the
release
team.
I
think
it
can
be
confusing
or
enhancements
kept
config
I
just
created
yeah,
but
even
to
the
shadows
and
stuff,
it's
harder
for
them
to
know.
What
to
look
for
if
the
template
is
changing
all
the
time
too,
so
it's
nice
to
have
it
like
say
this
is
actually
the
template
for
the
work
that
we're
measuring
against
for
this
cycle.
A
A
This
is
what
we're
kind
of
leading
to
right
a
versioning
system
for
caps
and
if
you
notice,
if
you
notice
everything
that
lands
in
the
enhancements
prop
sub
project
project,
some
of
the
things
that
some
of
the
things
that
are
milestone,
maybe
milestone
as
caps
beta
or
keps,
ga
right
so
like
that
is
to
hint
at
the
fact
that
we're
not
quite
done
with
process.
Yet
right.
I
would
say
that
we're
in
a
beta-ish
phase,
and
maybe
it's
time
to
the
same
way.
A
We
would
expect
of
someone
else
when
submitting
a
cap
to
define
what
their
alpha
beta
and
ga
stages
mean.
Maybe
it's
time
for
us
to
do
that
as
well.
E
E
G
A
And
make
the
appropriate
conversion
right
so
the
same
thing
that
jeremy
did
here,
but
as
a
generated
commit
right.
So
we
are
over
time,
but
I
think
we
had
a
really
really
dope
conversation
about
lots
of
new
things.
So,
let's
keep
it
going.
Let's
make
sure
that
we
get
the
let's
make
sure
that
we
get
the
receipts
kept
reviewed.
A
I
think
we
have
a
little
bit
more
time
now,
given
that
we
know
that
we're
we're
not
doing
this
until
122,
but
nonetheless
we
have
some
momentum
in
discussing
it.
So,
let's
make
sure
we
don't
lose
that
cool
all
right.
Everyone
catch
you
later.