►
From YouTube: SIG Architecture Office Hours 20180111
Description
http://bit.ly/sig-architecture
Chat transcript. Unfortunately times are wall clock time, not video time.
-----
08:34:34 From Cluster Ops : Is Joe chopping up for other folks?
08:35:44 From dims : https://github.com/kubernetes/community/issues/1407
08:36:53 From dims : “Document List of Organizations” ^^
08:37:21 From briangrant : https://github.com/kubernetes/community/pull/1569/files
08:39:30 From Joe Beda : There are 3 numbers in computers: 0, 1 and many. 8 ~= 30
08:44:37 From Joe Beda : Lots of things being discussed:
08:44:51 From Joe Beda : 1) How do we tool and enable associated projects
08:44:57 From Joe Beda : 2) What is the process for SIG sponsored projects
08:45:04 From Joe Beda : 3) Where do those live (from an org point of view)
08:45:16 From Joe Beda : 4) Do we really want to manage x0 orgs?
08:45:16 From SIG Testing : ~10 distinct sigs in incubator, ~20 distinct sigs overall
08:45:29 From Joe Beda : 5) Do we rush to this or do it on demand.
08:46:22 From dims : and labels!
08:46:26 From bburns : do it on demand
08:46:31 From Timothy St. Clair : I think this is wildly conflating ideas.
08:51:33 From Matt Farina : Something to think about… what’s required and what’s self-service. netflix is an example of talking about self-service where innovation happens when people break from that
08:52:00 From Matt Farina : CLA checking is required. is every repo using the same labels self-service or required and why?
08:52:14 From Timothy St. Clair : Intent is in the doc.
08:53:37 From Kubernetes Sig-Net : FYI: pulling all kubernetes orgs. `for i in `seq 1 15`; do echo $i > /dev/stderr; wget -qO- "https://api.github.com/search/users?q=kubernetes+type:org&page=$i"; done | tee orgs`
08:53:45 From Kubernetes Sig-Net : returns 150
08:55:05 From Matt Farina : does someone have the url to the doc? i’ve switched machines and lost the chat history and it’s not in the notes
08:56:36 From briangrant : https://docs.google.com/document/d/1yauW9zMtWgXN8xh4q6144B2xBTPuIOLGc0L6aQPMj1I/edit?ts=5a3c8c55#
08:57:28 From Matt Farina : Thanks Brian
08:57:45 From Kubernetes Sig-Net : Shoot, I have to go to a kid-school thing. Sorry to drop off,
08:58:37 From Timothy St. Clair : I have to drop as well, have a hard-stop.
08:59:34 From Forest Z : I think we shall have a self-serving on boarding portal for new contributors to onboard to K8s.
09:00:15 From bburns : yeah, I need to drop for stand-up...
09:00:20 From bburns : let me know if you need more frome
09:01:01 From Joe Beda : ps://github.com/kubernetes/community/pull/1584
09:01:38 From Forest Z : Sorry, need to drop early for scrum. Have a good one.
09:02:42 From Michelle Noorali : Have to drop to prep for my next meeting.
09:05:40 From Jaice Singer DuMars : +1 to what Caleb is saying
09:06:02 From Jaice Singer DuMars : Approval = acknowledgement & accepting it as a priority
09:08:10 From briangrant : I think we need to distinguish /approve from the Approved state
09:11:46 From briangrant : I think not having the state be explicit would make the state less obvious.
09:14:51 From briangrant : I like the idea of renaming Draft to Accepted
09:14:59 From Joe Beda : https://www.python.org/dev/peps/pep-0452/
09:16:27 From briangrant : https://github.com/rust-lang/rfcs#the-rfc-life-cycle
09:16:56 From briangrant : Modifications to "active" RFCs can be done in follow-up pull requests. We strive to write each RFC in a manner that it will reflect the final design of the feature; but the nature of the process means that we cannot expect every merged RFC to actually reflect what the end result will be at the time of the next major release.
09:26:34 From briangrant : Porting previous proposals to the KEP template can vet the template, but doesn’t vet the process at all
A
Doing
the
recording
and
doing
a
little
bit
of
leading
since
Jase
may
have
to
take
off
and
Brian's
been
on
vacation
and
he's
visibly
underwater
I
can
see
it
in
the
video
right
now
so
I
put
a
couple
of
things
on
the
agenda
that
I
know
have
cropped
up.
The
one
thing
is
that
you
know
Caleb
and
I
have
been
having
a
bunch
of
back-and-forth
around
the
cat
process.
I
think
it'd
be
great
to
have
an
ongoing
discussion.
A
There
Tim
sent
email
to
the
I,
don't
know
Kerber
entities
dev
talking
about
regular
meetings
around
API
review
question
of.
Do
we
want
to
do
this
in
this
meeting?
Do
we
want
to
actually
do
that
as
a
separate
meeting?
I
think
you
know,
Brian
said
that
hey
you
know
we
might
want
to
do
it
as
part
of
these
office
hours.
Are
there
other
agenda
items
that
folks
really
want
to
make
sure
that
we
get
to
during
this
hour.
C
That
org
structure
was
a
sorry,
my
I
still
need
to
log
out
and
log
back
in,
oh
hey,
Tim,
yeah
I
recorded
the
meeting
for
Robert
the
other
day.
The
the
org
structure
was
a
part
of
the
conversation
from
the
steering
committee
meeting
Anna
and
the
architecture
meeting
from
last
week,
and
there
was
a
action
item
to
just
create
the
initial
org
and
ask
for
forgiveness.
Later
we
had
enough
people
that
had
consensus
on
it
and
there
was
feedback
adherence
here
now
so
I
think
you
can
talk
about
it
more
yeah.
D
E
B
D
So,
instead,
if
I
have
a
repo
called
frameworks
hosted
at
an
organization
called
kubernetes
sake,
testing
I
would
love
for
the
package
hosted
there
to
be
testing
cockades
dot,
io,
/
frameworks
and
I
would
love
for
this
to
be
a
pattern
that
the
other
SIG's
can
follow
from
a
discoverability
perspective.
If
this
is
the
direction
we
want
to
proceed,
I
wasn't
sure
if
I
was
blocked
on
Tim's
PR,
to
make
this
a
little
more
regex
based
to
try
pushing
that
again.
D
This
seems
like
an
awful
lot
of
administrivia
and
overhead,
so
so,
where
I
landed
with
like
having
an
org,
/
sig
ever
all
is
like
I'd
love
to
have
some
idea
of
consistent
teams
and
labels
and
process
across
this
org
and
right
now
we
don't
do
that
for
the
like
8
orgs,
that
we
have
and
we're
just
sort
of
implying
that
this
this
is
going
to
have
to
be
solved
now
for
30-something,
orgs
I.
Don't
think.
C
Brendan's
dot
did
not
say,
create
the
org
/
see
if
you
only
said
if
they
have
artifacts
that
are
publishable
right,
the
it
didn't
explicitly
say,
create
the
organizational
structure.
Just
you
know,
ad
hoc
I
think
the
only
reason
we're
squatting
on
them
now,
but
it's
only
if
they,
if
the
sig
has
artifacts
that
they
want
to
hold
and
publish
within
that
SIG's
/
under
that
six
purview.
That
was
part
of
it,
but.
D
F
F
Because
the
trouble
is
that,
if
you
have
a
bunch
of
like,
if
you
have
a
contribute,
your
gonna
have
a
tragedy
in
the
comments
or
you're
gonna
have
a
bunch
of
people
giving
opinions
on
things
that
they
don't
have
purview
over
right
so
like.
If
you
have
one
giant,
org,
you're
you're,
either
gonna
have
an
organ
or
nobody
feels
ownership
and
it's
like,
oh
sure,
throw
something
in
there.
I,
don't
really
it's
not
ours
or
you're.
Gonna
have
like
you,
know,
people
from
all
over
the
place.
F
D
But
I
wasn't
proposing
that
Brendan.
What
I
was
talking
about
was
the
model
of
like
say:
kubernetes.
Incubator
is
owned
by
everybody
who's.
Currently,
a
member
of
the
kubernetes
sake
leads
mailing
list.
So
it's
substantively.
It's
still
like
everybody
who's.
A
lead
of
a
sync
can
have
decision-making
power
over
whether
they
want
to
make
a
repo
for
their
sake.
No.
A
But
Erin
I
think
one
of
the
things
is
that
for
the
Associated
projects
thing
in
Brendan's
dock
they're
not
associated
with
SIG's,
it's
just
stuff
that,
like
people
are
doing
that
they
want
to
make
sure
that
they
can
take
advantage
of
some
of
the
plumbing
in
kubernetes.
Is
that
correct?
Brennan
am
I,
remembering
right,
yeah.
D
And
so
those
are
the
projects
that,
according
to
that
dock,
aren't
part
of
the
kubernetes
project,
so
I
don't
care
about
them.
I'm,
trying
to
solve
the
problem
of
the
26
repos
that
live
in
kubernetes
incubator
today,
theoretically
are
owned
by
a
sig
and
in
the
brave
new
world
where
we
have
a
github
organization.
/
sake,
those
are
going
to
be
scattered.
Let's
that's.
F
Weak,
that's
be
clear.
That
Tim
is
exactly
right
and
saying
we
don't
have
a
github
org
/
sig.
We
have
any
sig
that
wants
to
sponsor
a
project
can
do
so
within
its
own
org.
That
doesn't
mean
we
go
proactively
out
and
we
create
all
these
orgs
for
all
these
SIG's
until
they
want
to
sponsor
something.
So.
D
B
F
D
F
D
C
There
needs
to
be
a
level
of
jurisprudence
that
the
SIG's
will
have
to
go
through,
and
it
should
be
their
responsibility
to
determine
whether
or
not
even
if
these
things
should
be
some
set
out
of
incubator
or
whether
or
not
they
want
to
maintain
the
Sun
set
of
incubator
into
an
association
associated
repo.
As
Brendan
has.
D
F
I
think
that
so
I
I
agree
that
that's
possible
I,
don't
I
mean
and
I
would
be
okay
with
a
notion
of
saying,
like
actually
even
sig,
sponsored
ones,
don't
show
up
in
good
readies
whatever,
and
you
can
just
have
a
sig
sponsored
org
wherever
you
feel
like
having
a
six-months
or
org
I.
Think
that
actually
makes
the
problem
worse
because
because
you
want
to
have
consistency,
I
mean
I.
Think
at
the
sig
sponsored
level
you
have
to
have
consistency
and
so
I
think
if
I
think
restricting
it
down
is
important.
F
I,
don't
think
you
can
restrict
it
any
further
down
than
organization
per
sig
because
I
think
other.
If
you
do
that,
then
you
end
up
with
the
tragedy
of
the
Commons,
where
you
have
an
or
where
no
one
feels
direct
responsibility
and
there's
it's
very
hard
to
point
backwards
to
people
and
say
you
need
to
fix
a
problem
here
and
that's
why
I
landed
where
I
landed.
I'm
not
wedded
to
it
necessarily
but
I.
Think
it's
the
best
solution.
I'm.
D
Just
trying
to
be
the
voice
of
everybody
who
I
have
talked
to
you
who
has
implemented
this
or
might
be
on
the
hook
to
implement
this.
They
are
cautioning
that
it
is
a
bad
idea
to
distribute
this
across
sakes,
and
we
should
instead
think
about
how
we
can
do
this
consistently
with
the
SIG's.
Sorry,
with
the
github
org
that
we
have
is
there's
some
other
pattern.
We
could
follow
to
denote
consistency,
and
can
we
just
trust
that
we
as
humans
can
do
the
right
thing
and
kick
out
bad
actors
as
appropriate?
It's.
F
A
A
Me,
like
actually
so
I
think
Erin.
That's
a
good
topic
that
I
think
we
should
discuss
in
terms
of
like
you
know
to
be
a
repo
in
the
kubernetes
org.
You
have
to
be
this
tall,
and
that
means
consistent
labels.
That
means
merge
automation.
That
means
CL
a
bot,
and
we
should
do
that
across
every
repo
we
own.
That
seems
something
that
is
totally
I'm.
Well
now,
that's
different
from
the
organization
stuff,
but,
like
I,
think
there
we
have
to
establish
Hannity
standards
of
like
to
be
this
tall.
A
B
Wait
I
want
to
do
a
time
check
please
and
we're
not
really
converging.
Could
someone
volunteer
to
go
make
a
list?
There
are
two
main
alternatives
being
discussed
which
is
repos
from
multiple
SIG's
in
the
same
org.
Whatever
that
work
is
called
and
separate,
orgs
cur
sig
can
someone
just
go
right
right
up
the
what
we
need
to
do
to
enable
distributed
decision-making
in
each
case,
the
technical
issues
and
the
social
concerns,
for
example,
about
tragedy
the
Commons
which
I
agree
he's
been
a
problem
for
every
like
contributory.
B
F
D
F
D
F
A
Pretty
frustrated
right
now,
so
I
think,
okay.
So
a
couple
of
things
here
is
that
if
we
ratify
Brennan's
doc
as
right
now
that
essentially
establishes
a
direction,
but
it's
not
enough
to
start
implementing
right
now,
because
the
details
need
to
be
done
so
there's
a
condition
of
ratification
there
and
I.
A
Think
some
of
the
frustration
Aaron's
part
is
that
this
thing
is
still
not
shovel
ready,
even
if
we
ratify
it
right
because
there
are
decisions
and
there
are
things
that
that
need
to
be
made,
and
so
I
think
like
we
can
do
both
both
say.
This
is
generally
the
right
direction
in
terms
of
the
different
types
of
projects,
but
then
also
recognize
that
it's
still
not
shovel
ready
and
there's
more
decisions.
I.
F
Agree,
I,
agree
and
I
would
also
say
that
I,
don't
think
that
we
have
to
like.
We
can
have
parts
of
it
be
aspirational
right,
like
it's
not
like
we
have
to,
it,
doesn't
have
to
be
perfectly
sit
on
day,
one
all
right,
like
we
can
say
like
okay.
Well,
that
part
is
you
know
that
parts,
an
unfunded
mandate
and
we'll
get
to
it
right,
I,
think
that
it's
about
setting
direction
not
about
speaking
of
that
I.
A
You
be
happy
if,
in
Brendan's
dock
there
was
a
you
know,
we
called
out
the
fact
that
hey
there's
still
some
there's
still
some
details
to
be
worked
out
around
like
hey.
We
want
to
have
SIG's
sponsor
projects,
we
still
aren't
quite
sure
whether
there's
an
official,
repo
or
repose,
and
that's
some
details
that
need
to
be
figured
out,
but
we
can
actually
ratify
the
rest
of
it
sure.
D
I
think
I,
like
Brian's
suggestion
of
we're,
trying
to
figure
out
how
to
best
implement
the
second
category.
I
would
love
to
see
Brian,
who
has
elaborated
a
bulleted
list
of
all
the
things
you
need
or
permissions
to
do,
and
maybe
Caleb
who
has
elaborated
all
of
the
ways
that
other
projects
have
implemented
decision-making
and
organizational
structures
to
hash
out
the
pros
and
cons
of
organization,
/
sake
and
single
organization,
and
then
I
would
like
to
not
voluntold
the
community
about
this,
but
rather
get
their
feedback
and
adjust.
F
B
F
Do
you
want
me
to
write
down
Aaron?
What
will
you
put
anything
any
comments
into
the
doc
where
you
feel
like
I'm,
incurring
pain
on
people
without
being
explicit
about
the
fact
that
I
am
incurring
pain
on
people
and
I
will
note
those
as
we
apologize
that
we
know
there's
pain
here
we
will
go
and
figure
out
what
the
pain
is
and
make
sure
that
we
don't
put
it
on
people
disproportionately
and
then
I'll
publish
it
to
kubernetes
dev.
F
A
F
Put
something
in
there
as
well
to
say,
like
that
this
stuff
is
aspirational
in
the
sense
of
like
if
it's
not
all
implemented
on
day
one
we
don't
we
don't
we
don't
care
and
Aaron.
If
it
makes
you
feel
better
I,
you
know
we
could
implement
so
Seattle.
Has
this
policy
around,
like
last
person
to
touch
the
telephone
pole,
has
to
bring
it
up
to
code
while.
F
But
but
we
could
effectively
put
that
something
to
that
degree
in
there.
It's
like,
if
you
want
a
sig
sponsored
repo
you're
gonna,
have
to
pick
up
the
shovel
and
help
helped
implement
some
of
the
infrastructure.
I'm.
Okay
with
that,
if
that,
if
sig
testing
and
contributes
feel
like,
you
know,
we're
putting
out
unfunded
mandates
on
them,
I
don't
want
people
to
feel
that
way.
C
C
I'm
slightly
confused
by
why
there's
I
know
we
had
a
conversation
in
Cygnus
ting
and
there
was
some
feedback
from
Eric
about
you
know
straddling,
and
that
was
good
feedback
and
I
agreed
to
some
of
that
around
process.
But
when
I'm,
what
I'm
struck
by
is,
why
do
we
have
by
to
be
proactively,
create
all
the
other
works,
and
why
is
there
feedback
from
a
Trebek's
to
about
for
structure
and
creation
contributor.
F
B
B
F
B
It
sit,
I
think.
The
reason
we
arrived
at
that
point
was
exactly
because
of
the
new
repo
process,
doc,
which
said
this
is
the
direction
that
we're
going
and,
as
Aaron
said,
you
know,
26
do
have
repos
right
now,
so
you
know
creating
them
and
squatting
on
them
because
they
seem
like
yeah
more
than
half.
F
A
B
A
D
G
A
G
A
E
B
E
E
A
That's
one
of
the
value
adds
for
people
writing
tabs
then,
but
then,
along
with
that
would
be
a
place
where
we
could
put
the
contributor
guide
have
the
place
to
go
for
the
latest
release
information
so
essentially
starting
to
try
and
draw
the
sort
of
pile
of
markdown
Docs
that
we
have
across
bunches
of
repos.
That
are,
you
know
and
pull
that
into
into
something:
that's
that's
more
user
friendly.
So
that's
work.
A
That's
ongoing
we're
going
to
borrow
some
of
the
tools
and
processes
from
the
sig
Docs
folks,
but
right
now
my
and
they're,
still
a
little
bit
of
like
I
am
I.
Thinking
is
that
this
thing
has
to
have
its
own
own
sort
of
life
outside
of
the
main
kubernetes
I/o
site.
Just
because
there's
things
like
freezing
on
that
for
future
branches
and
stuff
like
that,
whereas
the
community
facing
site
will
be
the
community
facing
site
will
have
its
own
life
cycle.
A
Eighty
four
and
let
me
post
this
into
the
chat,
the
there's
two
things
that
are
at
the
root
of
this
I
think
in
terms
of
there's
a
lot
to
go
through
there.
But
if
I
can
summarize
things
quickly,
there's
a
disagreement
around
the
process
of
how
we
imagine
that
folks
will
actually
create
and
modify
and
caps.
And
what
does
the
approve
will
bit
mean
around
those
things
and
then
there's
some
discussion
around
the
the
metadata.
And
how
much
do
we
lean
on
get
for
metadata
versus
actually
making
things
explicit
in
the
metadata?
A
That's
a
little
bit
separate
and
I
think
is
more
more
nitpicky.
I.
Think
the
larger
issue
here
is
is
one
of
the
things
we
talked
about
before
and
I
thought
we
had
decided
on,
but
maybe
I'm
misremembering
was
the
idea
that
we
want
to
encourage
folks
to
check
in
caps
early
in
draft
form
work
with
them
with
smaller
PRS.
So
we
don't
end
up
with
these
like
huge
hundred
comment,
PRS
and
then
and
then
have
the
approval
bid
saying
that
hey
this
cap
is
mostly
right.
It's
a
direction
that
is
widely
agreed
upon.
A
Have
that
be
something
that
happens
separate
from
the
initial
PR
that
in
the
cap,
I
don't
want
to
summarize
things
for
Caleb,
but
Caleb
I
think
is
saying
that
the
submitting
that
initial
PR
is
approval
and
and
I'd
like
to
disconnect
the
PR
process
from
the
approval
process.
Caleb
sees
those
things
as
being
jointed
the
hip
O'brien.
Yes
right.
B
So
I
actually
agree
with
the
idea
of
checking
in
the
caps
early.
What
I
would
like
is
criteria
for
merging
a
cap
should
be
kind
of
acceptance
that
the
singer
subprojects
will
actually
review
that
cap
and
assign
an
approver
and
things
like
that
that
the
cap
is
well-formed
and
will
get
attention
if
it's
not
something,
that's
welcomed
at
all.
I
think
we
can
just
or
if
it's
completely
malformed
or
it's
in
the
wrong
place
or
whatever
those
those
issues
should
just
get
resolved
before
it
gets
merged.
B
But
you
know
if
it's
actually
gonna
disconnect
the
well-formed
nosov
the
kept
from
hashing
out.
All
the
details,
I
think
is,
is
something
that
makes
sense,
and
approval
of
the
cap
should
be.
Finally,
the
final
stamp
of
this
should
go
forward
and
the
and
the
approver
who's
designated
by
the
owner
for
that
sub
project
is
the
person
who
needs
to
sign
off
for
years.
A
Okay,
so
I.
So
what
I'm
hearing
is
that?
There's
three
states
there's
the
proposing
a
cap
which
is
a
PR.
We
want
to
probably
have
a
certain
set
of
standards
of
like
the
the
owning
sig
has
to
accept
it,
and
we
probably
want
to
have
like
some
approvers
and
stuff
like
that
set
early
on
before
the
the
cap
first
gets
merged
and
then
but
then
it's
in
draft
form
and
then
there's
a
working
document,
multiple
PRS
and
then
finally,
there's
there's
an
approval
with
the
PR
force,
flipping
the
approval
bed,
and
that
is
somewhat
significant.
A
A
G
G
In
some
reason
the
time
frame
was
one
approval
means
and
then
that
the
detail
design
would
come
in
the
south
IPR
that
same
cat
as
the
conversation
perceived
and
you
have
a
clear
direction
of
where
to
go,
and
so
that's
all
I
meant
by
approval.
So
it
would
happen
quickly
as
to
whether
something
was
reasonable
or
not,
and
the
pion
merging
would
be
the
solution.
I
was
saying
by
the
sig
as
to
whether
it
was
approved
as
we
agreed
with
the
motivation.
G
We
are
going
to
defer
until
some
other
time
we
know
more
or
we're
going
to
reject
it.
We
don't
want
to
lose
this
liberation,
so
we've
merged
anyway.
I
think
not
that
they
PR
emergency
little
girl
did
the
prom
merge
a
signal
that
it
had
been
processed
by
the
sig
and
it
was
resolved
into
one
of
those
states
or
the
discussion
or
closure.
G
A
A
My
my
understanding
is
that
approved
is
actually
looking
at
the
bulk
of
the
cap,
not
just
the
motivation
section
and
and
stands
in
for
the
fact
that
our
previous
process
was
that
we
would
hold.
Pr
is
open
until
everything
is
perfect
and
then
we
would
submit
the
PR
and
we
ended
up
with
this.
Like
you
know,
200
comments
on
a
PR
and
was
unreadable
the
the
in
my
mind.
A
The
approval
process
is
the
moral
equivalent
of
checking
in
those
mondo
PRS
that
we
had
before,
and
so
that
means
that
we're
looking
at
the
bulk
of
the
cap,
including
the
high
points
of
the
design
and
the
approval,
covers
the
whole
cap,
not
just
the
motivations
and
I
would
mean
like.
If,
if
we
introduced
a
state
instead
of
draft,
we
called
it
accepted
right
in
that
and
accepted
means
that
hey
we're
going
to
work
on
this,
the
sig
has
accepted
it.
A
G
Believe
it's
actually
at
odds
with
your
previous
desire
for
having
non
large
PR
is
daily,
that
if
the
joinder
themselves
are
small-
and
you
won't
necessarily
know
the
design
of
price
I-
think
there's
in
fact
entirely
reasonable
to
separate
the
use
case
from
a
concrete
implementation
that
that
is
a
cheap
that
attempts
to
achieve
that
use
case
and
that
the
important
thing
is
to
agree
on
that
better.
This
is
a
direction
we
want
to
go
in
or
not
by
that
feedback
early
to
contributors
as
part
of
stimulating
by.
A
Yeah
I
think
both
are
important.
Both
the
fact
that
hey
this
is
something
that
we're
working
on,
but
then
the
technical
direction
here
is
good
enough
to
start
implementation
and
people.
You
know-
and
it's
signed
off
to
the
point
where
people
won't
write
a
bunch
of
code
and
then
be
surprised
when
they
get
whiplash
later
so
for
me,
except
it
means
that
I
can
start
writing
code
on
that.
This
and
I
probably
won't
won't
get
surprised
further
down.
The
line
distinguish
those
states
somehow
and.
G
The
people
who
are
required
for
the
approval-
and
you
have
that
conversation
and
that
the
result
of
that
is
the
detailed
design
appearing
in
the
cap,
so
that
the
decisions
that
the
signal
know
that
there's
an
actual
design
there,
not
that
there's
a
state
X
field
that
says
that
I
think
it
should
be
very
clear
whether
there
is
a
design
that
you
one
could
be
doing.
Implementing
or
not.
There's
a
speaker
in
the
capital
wallet.
G
Yes
and
because
goal
I
think
they
can
either
pretty
reasonable
mechanism
for
that.
It's
not
don't
merge
that
without
a
pre
and
that's
your
the
sort
of
piece
so
that
the
conversation
happens
in
stages
to
prevent
as
having
a
very
large
mondo
PR
that
is
open
for
mice
or
a
year,
or
also
not
a
few
million
crops
that
we
have
because
we're
in
there
are
content
design
Docs.
A
I
think
some
of
the
disconnect
here
is
a
lot
of
times.
The
design
is
iterative.
There's
multiple
points
that
you
want
to
work
through
and
and
if
we
all,
if
we
hold
the
bar
that
the
only
thing
we
ever
check
in
is
stuff,
that's
totally
approved
and
agreed
upon.
I
think
that
leads
to
these
big
PRS,
because
these
things
end
up
being
interconnected
in
a
certain
level
and
so
a
lot
of
times
when
you're
doing
designs.
A
But
it's
not
final
yet,
for
me
is
a
very
useful
state
for
these
things
to
be
and
well
you're
actively
working
on
their
site.
Now.
I
agree
that
we
don't
want
to
have
a
lot
of
crossed
Chuck
check
in
there
and
that's
why?
There's
this
date
where,
if
it's
marked
as
draft,
then
that's
essentially
cruft
and
it's
marked
as
draft
and
it
hasn't
made
progress
in
six
months,
then
we
can
go
ahead
and
actually
mark
it
as
abandoned
or
something
like
that.
So
I
don't
know
Brian.
You
look
like
you
want
to
yeah.
B
It
will
encourage
the
pattern
that
we
already
have
of
not
filling
out
those
TB
DS
and
just
moving
ahead
with
the
implementation
and
leading
effectively
to
cap,
incomplete
that
a
very
common
pattern
that
we
see
today
is
people
file
proposals,
and
then
they
just
spin
because
they
don't
have
clear,
approvers
and
there's
no
clear
process
and
there's
bike
shedding
and
200
comments
and
whatever.
And
then
they
just
go
ahead
and
say
well.
I
actually
got
consensus
with
the
people
who
matter
and
they
get
their
code
merged
and
we.
G
G
And
I
guess:
I,
like
the
person
that
we
eliminate
the
status
field,
I
am
suggesting
that
the
status
field
gets
updated
at
good
event,
so
that
the
detailed
design
or
what
we
want
to
say,
I,
don't
think
that
this
field
is
I'm,
not
imagining
that
as
I
was
when
something
in
general
that
a
human
is
editing.
I.
Imagine
that
there
has
the
various
sections
of
the
cast
members
that,
as
they
bodies
doing
the
merging
it
is
updating
the
status
field,
because
it's
an
a
right
now,
a
general
document
right.
A
G
More
inspiration
from
the
rust
RFC
process,
which
newest
and
the
Python
that
process
in
the
process
that
has
was
created
in
well,
I,
guess
the
common
area,
where
we
have
erosion,
control
and
reasonable
Hosting
for
the
dead
projects
as
a
general
expectation
for
certainly
for
any
developer
who's
entering
the
industry
now,
and
so
they
were
able
to
design
what
appears
to
be
a
fairly
lightweight
process
and
it
seems
to
be
working
fairly.
Well.
They've
got
about
2000
of
these
things
and
really
through
them.
They
they
do
seem
pretty
and
formative,
and
that
is.
A
Gonna
be
I
feel
like
we've
talked
this
to
death,
because
the
Russ
process
essentially
uses
it
github
issues
as
the
sort
of
the
thing
to
discuss
this
and
we've
already
established,
for
whatever
reason,
there's
a
difference
between
the
russ
community
in
the
kubernetes
community
that
when
we
open
these
things
up,
when
we
use
a
mando
issue
for
these
things,
they
never
converge,
they
don't
close.
They
essentially
become
unreadable.
G
The
next
probably
uses
a
variety
of
mechanisms,
so
their
RFC
are
essentially
indexes
which
represent
the
chain
of
custody
for
an
enhancement.
They
wrote
two
mailing
lists
discussions.
They
linked
to
issues
that
about
the
implementation,
not
about
the
design
of
the
implementation
they
have
links
to
the
PRS
as
as
well,
and
so
that
I'm,
imagining
that
you
are
creating
a
doctor,
that's
not
just
a
design
spec,
but
also
allows
you
and
I
think
want
steal,
chases,
steal
third
comment:
that
is
a
sticker
pledge
to
an
idea
from
conception
to
implementation,
to
increment
or
retirement.
G
It's
not
just
about
the
murders,
design
proposal
as
number
positive,
plus
plus
so
we've
had
I
assume
internal
prophecies
that
focus
on
about
launching
features
as
a
large
corporation.
You
inevitably
realize
that
it's
not
only
the
launch
success
of
the
landing
and
how
do
we
empower
lifecycle
of
an
enhancement?
That's
a
major
enhancement
to
the
project
travel
in
one
single
place,
rather
than
having
to
go
through
50
G's,
a
choose-your-own-adventure
you
can
have
issues.
Philip
chose
the
Google,
Groups
mellitus
and
any
other
slack
conversations
you
may
have
had
about
a
particular
issue.
A
Hear
you
I
I,
just
don't
think
the
rust
process
of
building
very
very
large
pr's
will
work
for
kubernetes.
It
hasn't
worked
up
until
now.
You
know
when
you
read
through
the
process
here.
It
really
encourages
folks
to
keep
those
PRS
open.
Until
things
are,
you
know,
approved
and
then
things
get
merged
and
that's
our
current
process
by
and
large
and
it
just
hasn't
been
working.
I.
B
Think
the
biggest
negative
to
merging
PRS
early
is
that
one
can't
open
a
PR
and
then
just
make
comments
on
parts
that
are
not
being
changed
by
the
PR.
If
that
one
thing
we're
fixed
by
github,
then
I
think
there
would
be
no
negative
to
to
check
in
the
PRS
as
early
as
possible,
but
I
do
agree
that
it
makes
sense
for
us
to
try
something
new
compared
to
what
we
did
before
and
we
should.
We
should
give
it
a
try.
I,
don't
think.
B
We've
and
I
don't
think
it's
worth
debating
indefinitely
and
we
should
try
it
on
some
things
and
see
if
we
have
success
with
it.
If
it
doesn't
work,
we
can,
you
know,
revert
back
to
the
old
way.
That's
fine,
but
you
know
we
are
trying
to
solve
some
challenges
with
the
old
way,
which
I
think
necessitates
doing
things
differently
than
the
old
way.
A
So
I
think
it
may
help
if
we,
if
we
change
some
of
the
the
terms
in
these
states,
to
actually
reflect
some
of
what
we're
talking
about.
So,
if
we
change
draft
to
accept
it,
that
essentially
means
that
there's
some
level
of
approval
around
the
direction
around
this
stuff
approved
I
mean
maybe
we
move
approved
from
approved
to
be
kind.
A
B
Think
for
that
we
need
to
have
metadata
like
last
updated
and
things
like
that
or
implemented.
You
know
some
requirement.
Are
we
discussed
early
on?
Should
proposals
be?
Should
design
Docs
and
proposals
be
updated
as
the
design
changes
I
do
think
we
need
something
along
those
lines
may
be.
You
know
very
old
proposals
that
have
been
superseded.
You
know
we
do
have
it.
Do
you
hope
to
reflect
that
to
say?
Well
we
stopped
updating
this
as
now
superseded
by
this
other
one.
A
A
B
Don't
have
strong
feelings
about
that.
One
I
like
the
idea
of
changing
drafts
to
accepted
so
there's
some
amount
of
diligence
and
decision
making
to
ask
to
be
done,
but
a
state
transition.
It's
not
just
like.
Oh
yeah,
someone
submitted
a
cap,
we'll
just
merge
it
yeah.
You
know
it's
also
much
organizer
right.
There
are
new
bugs
and
there
are
accepted
bugs
there
are
sign
bugs
so,
and
we
could
do
something
similar
to
that.
A
G
A
He
loved
his
designer,
you
know
to
take
our
best
guess
at
designing
a
process
that
we
think
will
work
as
we
scale
this
stuff
up
and
I.
Think
you
know
it's
clear
that
you
disagree
with
where
Brian
and
I
sit
and
stuff,
but
I
think
we
have
to
do
our
best
guess
and
then,
as
we
get
some
experience,
you
know
I,
think
everybody's
open
to
changing
and
adjusting
this
stuff
over
time,
but
like
right
now,
I
think
having
these
states
I
mean
like
this
is
the
discussion
that
we're
having.
A
What
do
we
think
is
the
ideal
set
of
states
that
I'll
actually
stick
with
us.
You
know
long
enough
to
actually
start
gains
and
miles
on
this
thing.
We
don't
want
to
be
changing
it
after
every
cap,
which
is
one
of
the
reasons
why
honestly
I
didn't
think
that
the
cap
process
was
really
ready
to
roll
out
widely.
A
A
A
D
A
G
A
Think
like
people
will
read
the
process
once
and
they
won't
necessarily
read
the
process
again,
as
we
update
things
so
I
think
there's
a
certain
amount
of
like
we
have
to
have
something
that
we
think
is
workable
for
the
long-term
as
we
roll
this
stuff
out,
which
is
one
of
the
reasons
why
I
don't
think
it
was
ready
to
roll
out
a
cute
con,
because
we
didn't
have
all
those
questions
answered
at
that
point.
I.
G
A
Or
try
out
you
see
that,
like
a
lot
of
the
design
proposals
right
now
are
full
of
crust
right.
So
a
big
part
of
the
important
notion
for
the
cap
process
is
making
sure
that
they
are
actually
up
to
a
certain
bar,
because
we
do
want
to
keep
the
cap
stuff
clean.
So
we're
not
going
to
be
able
to
move
design
proposals
from
that
directly
directly
into
apps,
without
also
making
sure
that
they
meet
the
bar
for
what
we're
looking
for
in
caps.
I.
Think
that's.
G
A
Perfectly
fine
like
if
you
can
get
Tim,
who
unfortunately
had
to
leave
to
say
that
hey
I'll
be
an
approver
for
this
and
I
think
that
this
thing
is
like
ready
to
be
implemented
and
that
the
cap
is
in
good
shape.
Then
fine,
let's
move
it
to
the
approved
state
or
with
the
implementable
state
or
whatever.
It
is
right.
My
my
big
feedback
on
that
was
my
big
feedback
on
that
was
was
I,
don't
want
to
mark
something
approved
when
we
don't
even
have
an
approver.
We
can't
actually
list
who
it
is.
G
Guess
my
point
was
that
from
the
working
group
home
to
me
and
expressed
concern
that
they
didn't
want
to
adopt
the
process
because
they
didn't
see
value
in
it.
I
feel
that,
if
we're
trying
to
relate
a
new
process,
we
have
to
have
to
provide
value
to
the
people
who
are
subject
to
it.
I
feel
like
doing
D
be
getting
that
you
can
find.
G
An
arbitrary
number
of
beginning
means:
there's
going
to
be
a
bunch
of
work
on
the
part
of
people
who
are
interested
in
building
up
the
process
to
support
the
people
who
are
trying
it
out
and
reducing
the
friction
for
them.
We're
going
to
hopefully
learn
a
lot
about
those
extra
parts
and
what
is
our
value
and
there's
not
adding
value
for
the
in
tributes?
So.
A
A
Now,
if
this
stuff
is
well
underway,
they
don't
have
to
use
the
kept
process
now,
if
we
want
to
make
it
easier
for
people
to
use
the
kept
process,
if
we
want
to
make
it
easier
for
people
to
start
to
do
these
first
couple
of
caps,
we
don't
do
that
by
relaxing
the
rules
on
the
process.
We
do
that
by
helping
them
tee
things
up.
So
you
could
help
those
folks
by
finding
the
reviewers
doing
the
back-channel
with
those
reviewers
and
actually
have
them
rubber
stamp
it.
So
it
looks
like
things
go
very
smoothly.
H
A
quick
question
here,
just
just
a
quick
question,
is:
is
there
a
way
we
could,
if
we
thought
about
it
as
a
self-service
approach,
and
what
would
make
people
really
want
to
opt
into
it
like
go
to
them
and
say
why
this
is
hard?
How
do
we
make
it
easier,
but
still
look
at
capturing
the
right
amount
of
information
if
we
weren't
doing
top-down
handing
things
and
looking
to
revamp
a
process?
H
That's
top-down
but
looked
at
it
is
how
do
we
make
it
self-service
so
from
the
bottom
up,
people
wanted
to
get
involved
and
said
what
would
it
take
to
make
it
like
that
actually
asked
that
question
and
then
went
out
and
looked
to
say:
would
we
need
to
do
to
solve
it
and
go
talk
to
people?
Is
there
something
we
could
learn
in
that?
That
would
make
people
want
to
adopt
it
or
help
us
better.
This
so
I
think
that's
a
great
idea.
Matt.
A
I
think
I
don't
think
we
can
force
things
to
adopt
the
cap
process
for
their
own
internal
mechons
for
how
they
communicate
things
as
we
build
tooling,
as
we
build
exposure
on
this
stuff.
I
think
that
brings
value
to
it
and
it
brings
a
level
of
consistency
across
the
product
that
I
think
will
mean
that
folks
will
want
to
do
that.
I
do
think.
A
We
need
to
provide
a
way
such
that
it
kept
that
only
impacts,
a
single
sig
or
a
couple
of
SIG's
can
be
self-service,
and
those
folks
don't
have
to
talk
to
any
of
us
to
be
able
to
do
that
stuff.
But
I
also
think
we
want
to
make
sure
that
there's
a
level
of
consistency
so
that,
when
something
hasn't
kept,
people
know
what
that
means
that
there's
a
certain
level
of
approval
when
something
as
mark
as
approve
as
a
captain.
A
That
means
that
hey
that
sig
has
approved
that
thing,
the
early
caps,
what
I'm,
imagining
the
earliest
caps
are
going
to
be,
are
going
to
be
things
that
are
going
to
be
more
cross-cutting
across
the
project,
because
those
are
the
things
that
need
the
wide
communication
and
those
are
the
things
where
we've
really
fallen
down.
I
think
up
until
now,
in
terms
of
being
able
to
communicate
this
stuff
widely,
so
I
don't
think.
Like
I
I
agree,
we
want
to
make
it.
B
Think
our
one
point
of
confusion
at
the
moment
may
be
that
in
the
long
run,
once
the
kept
process
is
ironed
out
and
in
use,
we
would
expect
the
approvers
of
the
cap
and
the
people
reviewing
the
cap
to
be
solely
the
people
in
the
technical
domain
that
the
cap
applies
to
at
the
moment.
Since
we're
in
the
process
of
trying
to
hash
out
the
the
process
and
the
template
itself,
then
people
who
are
stakeholders
in
the
cap
process
are
also
looking
at
them.
B
So
there's
kind
of
this
sense
of
we're
trying
to
create
some
good
example
caps,
so
that
the
caps
that
follow
kind
of
know
how
to
create
well-formed
caps.
So
there
are
different
sets
of
stakeholders,
then,
hopefully,
eventually
will
be
involved
in
the
longer
term.
So
this
cap,
what
is
labeled?
Zero,
zero?
Two
there's
a
zero
zero
one
kept
I
guess
they.
B
The
cap
process
zero
zero
one
okay.
So
this
is
an
effort
that
had
a
proposal
that
was
underway.
That
proposal
was
approved
and
now
it's
being
translated,
yeah
yeah
and
my
understanding
is
the
intent
was
to
just
try
to
put
it
into
the
form
of
a
cap
and
label
the
cap
approved
because
the
proposal
was
approved.
Is
that
correct?
Yeah?
B
A
B
B
A
A
All
right
so
action
out
of
this
is:
let's
get
Tim
to
decide
on
the
on
that
particular
proposal.
If
he
gives
it
a
thumbs
up,
then
that's
great,
then
we
move
forward.
There
I'll
rewrite
the
proposal
to
talk
about
the
new
different
types
of
states,
and
then
we
can
go
ahead
and
merge
that
I'm
going
to
hold
off
Caleb
on
removing
some
of
the
metadata
from
the
thing
until
we
actually
get
the
tooling
in
the
site
up
and
running.
A
A
Roll
up
your
sleeves
apply
some
clothes
to
do
that,
but
right
now,
I
think
the
priority
is
being
able
to
present
this
to
folks
so
that
they
start
seeing
some
of
that
value.
If
we
can
find
ways
to
present
it
that
actually
leans
on
get
in
a
way
that
that
you
say
is
possible,
that's
great,
then
we
can
always
go
back
and
remove
that
extraneous
metadata
later,
but
for
now,
I
think
we've
already
decided
on
and
improved
the
set
of
metadata.
That's
in
the
caps
that
was
done
a
month
or
two
ago.
A
A
Okay,
we
are
definitely
out
of
time.
I
will
all
update
the
pr
today
or
tomorrow
and
send
that
stuff
out,
and
hopefully
we
can.
We
can
get
the
updated
kept
process
PR
up
and
running
at
that
point.
I
would
love
to
find
a
way
we
lost
Caleb
I'd
love
to
find
a
way
to
to
roll
this
out
more
widely
and
get
more
folks
using
the
process.