►
From YouTube: Kubernetes SIG Architecture Community Meeting 08-07-2017
Description
A
All
right,
everybody
today
is
Monday
August,
7
2017,
and
this
is
the
bi-weekly
architecture.
Special
interest
group
for
communities
so
without
further
ado,
I
want
to
make
sure
that
you
know
that
our
agenda
and
the
notes
are
available
at
bit.
Dot
ly
/
cig
architecture,
and
my
name
is
Jace
singer.
Dumars
I
am
co-lead
with
Bryan
grant
and
we
are
happy
to
have
this
meeting
to
discuss
all
things,
corinna,
teas
architecture,
so
to
dig
right
into
the
agenda
a
little
bit
of
explanation
about
how
this
became
the
top
item
on
the
backlog.
A
Essentially,
during
the
last
office
hours,
there
was
a
group
of
people
who
discussed
non
prioritization
for
our
time
here
and
essentially,
what
we
saw
as
a
critical
missing
link
is
the
ability
to
submit
and
ratify
architectural
proposals,
because
a
lot
of
the
work
that's
going
to
be
coming
through
this
group
is
oriented
toward
decision
making
and
vetting.
Whether
architectural
decisions
made
in
cigs
or
by
individuals
are
consistent
with
the
long-term
vision
of
that,
and
what
we
need
to
do
is
have
a
process
in
order
to
review
those
and
ratify
them.
A
So
the
first
bullet
point
is
really
to
talk
about
how
we,
as
a
group,
accomplish
that
and
there's
various
consensus
models
and
also
a
deep
proposal
by
Caleb
from
coral
s
here
to
talk
about
mirroring
some
of
the
things
that
are
happening
in
other
communities,
specifically
rust.
So
what
I
would
love
for
everybody
to
do
is
take
a
look
at
that
proposal,
even
if
we
do
so
now,
because
that
will
be
part
of
why
we
are
what
we're
discussing
so
having
some
some
background
on.
That
would
be
helpful.
A
A
So,
in
turn
puzzles
there's
sort
of
this
debate
about
what
is
the
best
way
to
present
the
proposal
initially
and
what
I
think
we've
got
a
different,
a
few
different
ideas
and
I
think
kilos
proposal
gets
into
the
actual
submission
mechanism.
So
Caleb
are
you
here
and
are
you
willing
to
talk
a
bit
about
your
your
proposal?
Yeah.
B
I
have
noticed
it's
pretty
difficult
to
generate
release,
notes
and
it
would
be
nice
to
to
raise
the
bar
or,
in
desperation,
raise
the
quality
of
those
design
proposals
to
include
a
motivation,
possibly
examples
about
the
change
that
is
being
proposed
so
that,
as
a
community,
we
could
come
back
and
summarize
that
information
for
various
different
audiences
one
is
users
when
a
change
is
merged.
At
the
at
some
point.
B
During
the
release
cycle,
it
would
be
nice
to
be
able
to
generate
a
road
map
for
people
who
build
on
top
of
communities
are
interested
and
following
along
on
our
progress,
and
it
would
be
nice
to
have
a
place
where
the
links
to
the
issues
once
a
change
is
actually
started
to
be
developed.
So
you
could
go
back
and
see.
What
is
that
motivation?
And
what
are
those
examples
why
this
changed
it
once
development
has
begun.
A
So,
just
to
a
question
about
the
scope
of
change,
so
I
mean
change,
can
be
a
lot
of
different
things,
depending
on
where,
where
you're
at
in
the
release
cycle
and
if
it's
a
feature
versus
some
sort
of
shifting
approach
to
an
existing
implementation.
So
it's
almost
in
the
bug
fix
category.
Do
you
have
an
idea
about
scope
around
what
would
constitute
a
change
yeah.
B
So
things
that
wouldn't
get
a
release,
note
may
be
exempted,
but
I
would
like
SIG's
to
be
explicit
about
what
they
consider
change
were
there
to
receive
comments
on
in
a
more
formalized
process,
so
I
think
most
changes
should
go
through
this
process,
at
least
by
recent
is
proposed
by
established
community
members.
I
think
the
on-ramp
could
be
a
little
bit
different
for
smaller
things,
but
that
I
think
needs
to
be
seeking
to
be
explicit
about
what
they
consider
to
be
a
change
of
that
magnitude
or
not
so.
A
B
You
would
have
to
require
someone
from
perhaps
this
a
Gore
from
the
steering
committee
to
be
also
looking
at
at
our
FCS
I
mean
hopefully
cross-cutting
sig
work
would
be
chartered
under
some
Cross
sig
working
group,
but
I
think
there
are
a
bunch
of
details.
We
need
to
sort
out
as
the
governance
talks.
You
know
materialize
into
concrete
recommendations
for
the
project
right
now,
there's
nothing
to
prevent
that.
So
you
could
imagine
so
phil
has
a
proposal
for
API
changes.
B
You
can
imagine
that
API
changes
get
reviewed
under
sig
architecture
because
they
are
by
definition,
cross-cutting,
but
I.
Yeah
I
think
that
still
needs
more
more
more
work
for
those
particular
types
of
changes.
I,
don't
think
they
are
the
vast
majority
of
changes,
but
I
guess.
I
definitely
agree
me
to
cover
that
case.
Cool.
B
D
He
had
a
dead
Caleb
right,
yeah,
so
I
mean
I
would
say:
I
have
almost
the
opposite
experience,
having
done
PR
based
proposals
and
discussions
and
the
problem
with
PR
based
proposals
is
that
there
is
effectively
a
barrier
for
every
single
commit
comment,
whereas
the
barrier
on
the
Google
Doc
usually
happens
once
or
answered.
So
basically
changing
everyone
paid
a
little
bit
of
cost
in
the
PR
to
someone
pays
an
upfront
and
an
at
at
most
cost
like
I.
D
Don't
know
that
I'm
like
I'd,
be
worried,
which
is
I
feel
like
that's
a
decision
that
the
proposal
authors
have
already
used
extensively
and
sound
better,
and
we
need
to
measure
it
make
sure
it's
actually
better.
But
I
do
worry
about
us,
saying
that,
like
it's,
not
working,
because
it's
not
in
my
experiments,
yeah.
E
I
would
second
it
see
her
speaking
so
I
would
propose
to
focus
on
the
Google
Docs,
as
Clayton
mentioned,
because
of
the
benefits
of
Google
and
Google
Docs
and
so
on.
Instead
of
VRS
for
like
for
the
early
stages,
some
drops
and
estimates
and
when
we
are
moving
to
some
like
public
space,
so
can
can
work
better.
E
F
Tonight,
when
I
try
to
jump
in
here,
I
think
we're
in
the
weeds,
I
think
the
bigger
issue
here
is:
what
are
the
documents
we
want
to
produce?
What
is
the
workflow
for
who
produces
those
who
consumes
and
who
approves
them,
and
then
the
mechanics
of
how
we
work
or
to
agree
that
that's
important
and
not
have
opinions
there
also,
but
in
my
mind
that
take
a
second
second
place
to
exactly
what
is
the
process
that
we
want
to
have
here?
Yeah.
D
I'm
just
gonna
say
maybe
I
was
missing
to
putting
the
question
which
is
I
would
agree
that
at
the
end
of
the
day,
the
form
of
how
the
documents
are
produced
do
need,
doesn't
even
meet
a
standard
that
we've
already
kind
of
established
of
you,
know
a
PR
and
changes
in
a
repo
with
a
history
and
a
version
for
long
term
Nathan.
So
let's
agree
that
it
cannot
stay
with
us
or
that
it
should
say
anything
about.
I
would.
B
Say
just
as
a
very
low
bar
and
then
I'll
hand
off
to
Joe
here,
like
there's
a
to
do
in
the
proposals
directory
that
says
document
our
proposal
process
right
I
would
just
love
to
at
a
bare
minimum,
have
a
standardized
format
for
what
a
proposal
should
be
and
I
think
Caleb.
What
she
put
forth
is
a
really
awesome
start
at
like
what
are
the
big
headings,
that
a
proposal
for
a
significant
amount
of
work
should
address.
B
I've
had
a
number
of
people
internally,
ask
me
this
sort
of
question
and
I've
had
to
go
just
organically
point
to
a
number
of
well
with
well-written
design
proposals
and
point
out
the
ones
that
are.
You
know
like
calling
out
objectives
versus
non
goals,
the
ones
that
are
calling
out
alternatives
and
considerations
and
stuff
I.
Think
having
all
of
that
as
a
standard
template
would
be
a
pretty
low
effort,
high
value
thing
that
we
could
do
I,
don't
know
if
this
is
the
group
that
owns
it.
D
Yeah
I
would
say
this
group
is
a
commenter
on
proposals
and
can
and
had
some
some
level
of
authority,
but
we
should
be
clear
about
who
actually
is
approving
the
proposals,
and
it
should
be
the
technical
and
process
coming
together
at
the
point
of
approval
like
if
SIG's
have
to
go
through
this
group
to
to
get
approval
for
a
proposal.
That's
sad,
but
if
simply
just
have
to
make
sure
that
this
group
is
aware
and
other
groups
are
aware,
then
that's
somewhat
consistent.
What
was
said
already.
F
Alright
guys
I
would
like
I
am
confused
honestly,
because
I
feel
like
we're,
conflating
release
planning
with
architectural
planning
and
the
proposal
process
that
you
have
here
Caleb.
It
really
looks
like
it's
filtered
around
or
it's
rotated
around
that
release,
process
and
really,
obviously
optimal
work
understanding
what's
going
in
teach
release
so
that
we
can
plan
for
that,
I
think
that's
a
really
important
thing.
F
It
would
be
careful
not
to
conflate
that-
and
this
is
this-
is
the
the
email
exchange
that
that
we
had
over
the
last
couple
of
days
here.
I
think
it's
really
important
not
to
complete
that
with
long
term
you
know
architectural
planning
of
as
we
try
and
plan
things,
I
think
one
of
the
places
where
I
look
at
the
features,
repo
and
I
think
it's
actually
fallen
down,
as
we
have
conflated
those
things,
and
so
we
find
that
we
have
these
these
issues
that
are
open
forever.
They
become
unwieldy.
F
Is
that
that,
let's,
let's
actually
figure
out
where
true
north
is
on
issues,
and
then
we
can
figure
out
how
to
stage
that
in
over
over
releases
and
we've
seen
this
with
the
features
repo,
where
you
know,
we
started
out
having
features
that
we're
going
to
actually
be
longitudinally
over
multiple.
You
know
releases
you're,
going
to
use
the
same
issue
as
you
go
from
alpha
to
beta
to
GA
and
then
over
time,
we've
actually
sort
of
said.
F
No
we're
release
is
actually
the
amount
of
work
that
actually
that,
actually,
you
know,
fits
into
a
specific
feature
ends
up
being
the
amount
of
work.
That's
fits
into
a
specific
release
and
then
they
from
the
feature
we
actually
point
to
the
design
doc,
but
that
design
doc
is
it's
kind
of
you
know:
mad
there's,
no
approval,
there's
no
process,
there's
no
format
or
status
or
that
and
so
I
think
RFC.
F
You
know
it's
interesting
that,
like
you
know,
in
IETF,
land
RFC
actually
means
standards.
It
means
request
for
comments
which
is
different
from
sort
of
a
change.
It's
sort
of
like
here's,
the
here's.
The
standard
of
the
thing
that
we
want
to
get
to
here
at
the
architecture
and
implementations
are
handled
separately
from
that
and
I.
D
Even
if
they're
not
explicitly
unable
to
support
it,
because
it's
impossible
to
do
the
Big,
Bang
style
chops
and
if
any,
what
we
want
to
do
that
we
would
never
drop
a
six
month.
Change
in
on
the
last
week
of
the
release
in
marks.
Alpha
want
to
slowly
and
cautiously
move
forward
across
multiple
releases
on
long-running
and
corny
objectives.
C
B
What
we're
working
on
is
important
now
that,
because
it
is
difficult
to
ascertain
that
today,
it
does
have
consequences
for
the
release
process,
but
I
guess
I
want
to
step
back
to
propose
a
general
mechanism
for
communicating
of
what
we're
working
on
and
why
and
have
a
general
mechanism
for
having
people
propose
changes
to
the
project,
and
so
that's
you
could
imagine
that
RFC
in
this
context
is
interchangeable
with
something
like
the
Python
enhancement
proposal.
Where
you
have
this,
you
want
to
do
this
thing.
This
is
why
we
believe
it
is
important.
B
Here's
an
example
of
how
you
would
consume
it
and
a
cig
would
say:
yes,
that's
in
roadmap.
This
is
not
important.
No,
this
is
not
in
roadmap,
so
we'll
table
that
beyond
that
motivation
and
high
level
design
goals,
then
I
think
you
can
start
talking
about
how
you
would
go
about
implementing
that
change
to
your
point,
Joe
and
I
think.
B
Yes,
these
are
definitely
different
phases
of
a
you
know:
a
development
process,
but
I
want
to
get
alignment
on
what
we
think
is
a
reasonable
process
first,
because
what
we
have
right
today
is
falling
down
at
scale,
and
thank
you
if
you
were
to
compare
our
release
notes,
for
example,
that's
the
end
of
the
process.
So,
given
our
current
develop
process,
what
can
one
glean
from
the
information
that's
available?
A
Think
Oh
magic
as
I,
say,
I,
think
I,
think
you're,
spot-on,
Caleb
that
we
do
have
a
tactical
issue,
and
this
is,
it
manifests
grossly
during
the
release
process.
That's
when
it's
it's
just
aching
and
sitting
out
in
plain
view,
I
think
what
what
Joe's
concern
is
and
I
think
that
we
find
we
need
to
find
a
way
to
reconcile.
A
It
is
that
the
the
content
of
the
changes
is
important,
but
the
idea
of
an
overarching,
architectural
narrative
that
it
has
cohesion
across
to
three
point
releases
or
even
major
releases-
is
not
necessarily
satisfied
by
just
more
tactical
implementation
of
it.
It
has
the
tactical
implementation
definitely
starts
to
align
things
because,
ideally,
let's
say
you
know
one
of
the
figs
props
up
a
proposal.
A
That
proposal
should
definitely
say
here's
how
this
ties
into
the
architectural
roadmap
we're
splitting
this
repo
out,
because
architecturally
speaking,
we
want
to
have
a
wider
variety
of
separate
repositories
to
work
on,
so
that
definitely
should
be
an
element
in
the
proposal
process
in
my
opinion,
but
it
doesn't
necessarily
fix
this.
This
problem
that
we
all
feel
in
our
bones
about
you
know:
crew
Nettie's.
A
Is
this
thing
that's
marching
forward
release
after
release
and
there
is
a
chance
that
we're
going
to
hit
an
architectural
cliff
somewhere
that
we're
not
aware
of,
and
so
really
understanding
those
those
aggregate
patterns
and
implementation,
known
anti
patterns
and
one
I
mean
kind
of
heading
those
off
and
seeing
what's
happened
to
other
projects
that
are
more
mature
does
face
similar
issues
of
scale.
Those
things
aren't
necessarily
culminated
super
well
in
an
appoint
process.
A
F
I'll
give
a
concrete
example:
here:
I
mean
you
know,
we're.
We
have
underway
this
effort
to
essentially
break
kubernetes
out
into
a
bunch
of
you
know,
extensible
things
with
API
aggregation
and
that
type
of
thing
it's
awesome,
there's
been
a
ton
of
work
impacting
everybody.
We
don't
have
a
design
doc
for
that.
That
really
sort
of
covers
out
the.
B
And
I
agree
that
as
a
concrete
example,
that
is
something
that
I
believe
like
again:
I
guess,
at
least
for
as
I
see
it
the
challenge
with
that
particular
change
the.
How
do
you
break
up
the
repository?
Because
there
is
no
place
to
track
that
effort?
There's
no
kind
of
document
that
could
be
approved.
That
would
given
a
strategy
for
doing
so
that
that
we
could
agree
on
that.
What
are
the
goals
of
breaking
up
the
repository
and
what
would
we
trade
off
already.
B
Reddit
I
think
that
and
that's
broken
it
down
into
at
least
two
phases:
there's
one
the:
how
do
you?
What
does
the
architecture
trying
to
accomplish
you're
trying
to
implement
and
two?
What
is
the
actual
repository
structure
that
mirrors
that
intent
now?
Certainly,
you
could
make
the
architectural
changes
and
still
have
the
mono
repo,
but
I
think
we
have
decided
as
a
community
that
we
don't
want
the
mono
repo.
So
now,
both
of
those
changes
are
now
somewhat
tied
together.
F
Yes,
I
I
mean
I
would
love
to
have
a
process
for
tracking.
You
know
what
is
it
that
anybody
is
doing
in
a
particular
release?
I'd
love
to
see
that
roll
up
to
some
sort
of,
at
least
for
a
certain
size
and
aspect
of
change,
roll
up
to
some
different
document
process
for
architectural
change
in
direction,
and
these
things
can
separately
and
be
named
different
things.
I,
don't
think
they
I
don't
think
we
have
to
come
up
with
a
grand
unified
process
that
covers
both
of
these.
A
You
know
when
I'm,
when
I
was
at
rally
they
they
had
a
really
good
way
of
dealing
with
these.
These
are
sort
of
these.
They
call
them
rocks,
but
they
were.
There
were
problems,
they
need
to
be
broken
down
inherently,
but
were
very
large,
and
so
essentially
you
would
take
a
rock
and
you
would
you
would
break
it
into
a
number
of
epochs.
That
would
happen
over
time
in
a
staged
fashion
and
that
breaking
down
part
between
the
the
sort
of
monolithic
problem
and
the
implementation
of
epochs.
A
That
was
a
that
was
a
really
good
insertion
point
for
architecture,
because
that
is
the
point
at
which
you
see
a
lot
of
long
term.
Decisions
go
awry
either
because
they're
you're
trying
to
implement
it
to
tactical
level,
and
you
do
things
that
necessarily
have
to
be
reworked
later.
Then
you
introduce
a
lot
of
waste
or
you
don't
have
the
right
people
in
the
room
to
make
a
decision
about
something
and
you
you
pick
a
direction
and
run
with
it
and
it's
just
inherently
the
wrong
direction.
A
F
You
what
I
would
love
to
do
is
I'd
love
to
actually
put
together
a
process
on
how
we
want
to
organize.
What's
going
into
the
community
proposals,
you
know
and
maybe
do
that
in
a
different
repo
directory.
How
do
we
organize
tag
track?
What's
current?
What's
not
current?
What's
deprecated
what
supersedes?
F
What
that
type
of
thing
with
those
design
proposals
really
encourage
folks
to
to,
if
they're
doing
stuff,
that
cuts
across
multiple
SIG's
that
that
starts
to
have
an
architecture
smell
to
it
to
actually
go
through
there
and
let's
try
and
keep
that
be
as
high
content
as
possible.
I
think
that
it
should
be
I'm
not
sure
that
every
proposal
that
goes
in
there
necessarily
have
to
go
through
and
get
some
I,
don't
know
what
the
heck
sig
p.m.
does.
F
To
be
honest,
all
so
I
think
it'd
be
great
if
every
proposal
goes
through
there,
that
impacts
multiple
SIG's
I.
Don't
think
necessarily,
like
you
know,
all
those
have
to
be
heard
officially
by
Sade
architecture,
but
I
think
that
we're
going
to
see
a
lot
of
them
will
benefit
tremendously
by
actually
having
having
those
eyes
on
on
those
proposals
and
and
it
will
ease
implementation
when
we
have
that
stuff
decided
upon
from
the
get-go.
A
So
I
think
the
Paul's
question
about
what
is
you
know,
sig
p.m.
versus
this
work
I
think
that's
a
really
interesting
thing
that
gets
into
the
heart
a
lot
of
egg,
which
is
what
is
the
horizon,
that
any
particular
sig
is
looking
at.
You
know.
Sig
architecture
is
a
sig
that
has
a
six
month
to
multi-year
purview.
If
we're,
if
we're
in
the
weeds
of
what's
happening
this
month,
we're
doing
it
wrong
or
we're
behind
the
ball,
and
that's
not
where
cigarette
texture
needs
to
be
cig
p.m.
A
A
And
then
cigs
are
at
a
more
tactical
level,
which
is
really
the
release
or
less
and
making
sure
that
the
work
that's
being
done
is
consistent
with
the
two
layers
of
product
management
and
and
architectural
management.
So
I
think
that
if
we,
if
we
look
about
horizon
that
almost
by
nature,
defines
what
are
the
responsibilities
of
any
particular
group,
I
mean.
Obviously,
SIG's
have
an
architectural
concern.
You
know
if
you're
writing
a
feature,
you
know
say
like
the
PKI
infrastructure
for
Nettie's.
That's
not
a
one
release
thing.
That's
a
multi
release
thing!
F
Has
a
PKI
stuff,
a
great
example
where
there
is
no
grand
plan
that
lays
out
what
our
goals
are
and
what
we're
doing
there
there's
a
lot
of
great
work
going
on
I'm,
not
arguing
with
that,
but
it
feels
like
we're
looking
at
each
feature
in
isolation.
Instead
of
actually
looking
at
their
architectural
direction.
There.
F
Terms
of
cig
PMI,
honestly
I
mean
it's
been
around
for
a
while.
We
haven't
seen
so
Paul
says.
I
would
argue
that
a
cig
PM
is
really
going
to
be
the
center
of
product
management
for
this
community,
that
that
would
be
the
sig
that
we
attract
these
things
they're
only
looking
at
single
release
ahead.
That
is
not
sufficient
to
track
the
grand
plan.
Again.
I,
don't
see
a
strong
connection
honestly
between
sig
p.m.
and
the
architectural
decisions
that
are
being
made,
that
that
decision
is
just
lacking
for
white
people.
B
Of
the
bounds
of
sig
architecture,
here,
I'm
going
to
sort
of
reiterate
my
ask
at
the
beginning,
then
what
we
do
not
have
today
is
a
standard
proposal
document
for
people
to
write
against.
There's
no
template.
That
says
these
are
the
headings
you
show
and
the
content
you
should
have
bearing
proposal
for
what
a
good
question
we
have
this
big
directory
called
design
proposals.
You
know
any
significant
amount
of
work,
that's
going
to
take
you
more
than
a
week
or
two
anything
you
think
could
potentially
impact
the
end
user
or
could
cross
multiple
sakes.
B
Discovery
summary
of
like
this
should
require
a
proposal
or
not,
but
I
think
you
think
in
like
meaningful
chunks
of
work
that
are
going
to
require
a
person
to
Shepherd
them
along
for
a
while
I,
probably
want
to
put
together
a
design
proposal
for
that
like
if
it's
something
I
need
a
design
document
to
implement
against
anyway.
Would
that
not
be
something
I
want
the
community
to
review?
They
get
some
I
thought
of
before
I
read
code,
I
think.
F
Some
of
this
is
emeriti.
You
know
we
do
when
we
say
proposal.
Do
we
mean
the
stuff
going
into
a
single
release,
which
I
think
that
that
that
that's
that
some
of
Caleb's
a
proposal
here
I'm
community
proposals?
Okay
or
do
we
mean
something
that
actually
is
more
architectural
and
structures
across
multiple
polycythemia
stand
up
so
I
followed
us
all.
That's.
G
F
Seems
strange
to
me
that
if
we
need
to
track
architectural
decisions
and
processes
that
we
would
do
that
in
a
cig
outside
of
save
architecture
I,
you
know
having
product
products
in
a
concentrated
in
one
spot
and
everybody
go
to
them
versus
the
other
way.
Every
way
around.
That's
the
thing
that
I'm
wondering
like
yes,
we
could
use
product
management
help
in
terms
of
tracking
this,
but
but
saying
that
that
sig
TM
doesn't
really
compute.
For
me,
yeah.
E
I
would
like
to
indicate
a
bit
on
behalf
of
6:00
p.m.
so
what
they
actually
are
doing
and
how
does
it
overlap
and
how
can
it
collaborate
with
c88
education,
so
I
can
see
siggy
a
potential
job,
mostly
in
the
technical
side
and
in
technical
strategy
and
the
technical
roadmap
for
forgiving.
It
is
the
same
time
at
6:00
p.m.
we're
mostly
focused
on
kinetics,
as
as
a
product
as
a
market
product
and
we'll
select,
a
very
innate
and
the
different
angles,
including
like
market
and
customer
collaboration
and
so
on.
So
at
6:00
p.m.
E
we're
letting
to
collaborate
with
sigit
texture
in
terms
of
of
technical
decisions.
At
the
same
time
would
like
to
leave
significative
and
ground
six
to
work
to
work
on
that
not
and
also
we
are
not
not
only
focus
on
the
perilous
cycle
or
jousuke
the
net
as
well
focus
on
the
general
roadmap,
but
again
most
from
the
product
perspective.
A
You
know-
and
it's
interesting
so
if
you
look
at
if
you
look
at
traditional
agile
development,
where
you've
got
the
product
owner
sitting
in
a
team
and
you've
got
the
development
team
in
the
scrum
master,
you
know
in
intraoral
implementations
that
the
product
team
is
really
the.
Why
of
what's
happening,
and
it's
interesting
in
the
communities
project
where
so
the?
Why
is
really
more
drawn
out
by
this
de
six
themselves?
So
people
come
to
a
cig
and
say
here's,
here's
the.
A
Why
of
what
we
want
to
do
and
then
the
the
more
the
more
technical
vetting
of
architecture
is
to
say.
I
understand
you
wanted
you
understand
your,
why
it
makes
sense,
but
here's
part
of
the.
How
is,
if
you're,
going
to
do
this,
please
don't
write
this
code
in
Fortran.
It'd
be
great
if
you
use
go
because
that's
an
architectural
standard
for
the
project,
so
you
know,
there's
there's
probably
ways
in
which
there's
there's
overlap
and
cross
concerns
here
that
that
work,
but
nobody
has
actually
gotten
together
and
figured
those
out
they're,
not
explicit
anywhere.
D
Think
there
is,
there
I
think
it's
useful
to
call
out
that
Cube
does
kind
of
have
a
mission.
That's
had
from
the
very
beginning.
Biz
came
from
some
very
some
very
idealized
schools,
and
what
we've
tried
to
do
is
go
from
a
point
where
that
is
a
in
a
vision
concentrated
in
a
few
people
to
a
more
organic
process
where
we
we
work
in
the
Bennets
to
the
benefit
of
the
users
running
the
platform,
and
so
architecture
originally
may
have
meant
kind
of
the
architectural
vision
of
the
platform.
D
D
And
then
we
didn't
in
any
successful
engineering
project
really
I
mean
I.
Don't
think,
that's
that
surprising.
The
p-n
generally
make
sure
that
the
users
requests
are
being
heard.
User
sources
are
being
heard,
and
sometimes
that's
in
the
sleeves,
and
sometimes
it
isn't
and
there's
a
technical
over
site
which
is
in
the
project
internally
healthy
and
is
able
to
accomplish.
You
know
new
reacts
to
changing
goals
that
also
have
like
a
long-term
vision
for
the
technology.
A
D
D
I,
don't
even
is
the
pro
is
a
proposal,
description
and
process
by
itself
sufficient
to
move
the
project
in
a
suit
in
a
forward
direction
such
that
there's
at
least
some
place
where
people
go
to
articulate
design,
changes
that
cross
boundaries
and
the
answers,
probably
yes,
I
mean
I,
don't
think
disagreement
on
that
I.
Don't.
D
H
Yeah
I
definitely
think
we
need
to
formalize
the
proposal
process.
That's
rather
than
pushing
that
we
have
a
lot
of
newcomers
on
the
project
and
there
is
a
fair
amount
of
cargo
quilting,
but
there
does
seem
to
be
confusion
about
how
the
pressure
should
work,
especially
since
we
moved
ox
to
the
community
repo,
where
we
don't
have
as
many
people
looking
at
the
PRS
coming
in
the
assignments
of
proposal
to
reviewer,
an
approver
has
fallen
through
the
cracks.
In
many
cases
you
know
for
the
people
who
have
it
on
the
project
for
a
long
time.
H
This
has
not
been
an
issue
because
they
just
notify
the
people
they
want
to
review
it
and
then
moot
and
they
understand
how
the
process
works
and
they
move
forward.
Although
even
in
those
cases,
we've
had
a
number
of
situations
where
were
started,
progressed
and
even
was
released
without
wrapping
up
the
proposal,
and
that
would
that
happen
a
number
of
times
over
the
past.
Several
releases
and
I
would
like
that
not
to
continue
to
happen,
and
if
we're
going
to
be
explicit
about,
we
need
more
investigation.
We're
not.
H
We
need
to
be
more
iterative
on
this
area,
we're
not
really
sure
we
and
we
don't
want
to
take
a
waterfall
approach.
So
let's
just
be
explicit
about
that,
but
I
think
that's
not
what
happens
in
the
cases
I'm.
Thinking
about
it's
more,
that
just
people
didn't
have
the
the
energy
to
wrap
up
the
proposal
and
debate
without
clear
approvers.
For
example,
you
know
closing
down
comments
from
random
participants.
H
H
You
know
some
of
the
other
items
you
mentioned.
You
know
getting
a
tag
team
together
to
make
sure
the
existing
proposals
are
moving
getting
discovered
by
the
right
people
and
so
on
sounds
like
a
great
idea.
I
would
actually
like
someone
to
reorganize
the
design
proposals
directory
by
fig
so
that
we
could
use
some
of
the
standard,
auto-assignment
mechanism
or,
alternatively,
extends
the
mechanisms
so
that
we
can
add
more
metadata
to
proposals
to
facilitate
auto-assignment
and
sit
with
the
reviewer
approver.
H
Much
so
I
think
there's
there
are
things
that
can
be
done
on
multiple
fronts
and
then
you
know
separately
as
I
mentioned
in
email.
While
on
my
way
here
we
need
to
clarify
how
approvers
and
reviewers
get
assigned
and
what
to
do.
If
multiple
people
want
the
right
to
approve-
or
things
like
that
for
PRS,
it's
not
so
much
been
an
issue
for
proposal.
H
It's
more
of
an
issue
like
who
can
say
make
the
go
no-go
decision,
for
example,
so
yeah
I
think
breaking
up
the
problem
and
starting
to
make
progress
seems
like
a
great
thing
to
do.
I
don't
want
to
boil
the
ocean
here,
I.
Think
things
are
happening
regardless
of
what
we
do
here.
So
anything
we
we
can
do
will
will
be
an
improvement,
help
things
move
forward.
A
D
H
And
that's
what
I
was
starting
on
with
the
dock
and
the
dock
needs
to
be
updated
and
broken
up
and
checked
in
to
markdown,
and
we
can
do
that
instrumentally
as
well.
But
there
are
some
long-standing
positions:
I
think
informed
people
actually
working
on
the
project
like
which
functionality
we
expect
to
be
in
queue,
control
versus
on
the
server
side
or
and
why
that
is,
or
maybe.
D
Another
word
a
diagram
and
reserves.
You
have
a
huge
amount
of
very
important
things
that
haven't
been
flushed
flushed
to
persistent
storage
in
a
way,
that's
discoverable
I
to
some
of
the
points
like
we've
talked
about
what
we
need
to
decide
what
the
process
is
before
we
write
it
down.
I
still,
I
think
from
the
architecture
side
that
arguments
a
little
bit
less
valid,
which
is
there
are
long-standing
ideas
and
principles
that
inform
the
design
of
kubernetes
and
flushing.
D
Those
into
a
form
pushing
those
to
disk
is
more
important
than
litigating
the
process,
because,
no
matter
what
the
new
process
is,
those
are
still
bedrock
assumptions
if
people
wish
to
disagree
with
them
doing
that,
discussion
in
the
open
is
actually
more
productive
than
using
using
process
to
be
litigated
folks
and
I'm
not
trying
to
frame
the
people
who
want
to
be
litigate
them
as
bad
I'm.
Trying
to
say
like
having
the
discussion
on
the
PR
is
the
best
possible
outcome
about
a
concrete
proposal
that
defines
the
fundamental
kubernetes
mindset
architectural
item.
D
H
B
It's
just
to
reiterate:
I
guess
what
Bryan
and
Clayton
said,
though
I
cannot
underscore
enough
the
need
to
just
document
the
state
of
the
world
today,
so
we
can
get
out
of
tribal
knowledge
of
what
the
process
is.
I'm
getting
requests
and
I
sort
of
just
have
to
make
off
the
top
of
my
head.
The
idea
that
well
I've,
seen
other
people
do
Google,
Docs
and
I.
Think
if
you
copy/paste
what
this
good-looking
proposal
does
here
and
try
to
include
these
headings
like
please
can
we
just
that
seems
to
be
and
I
think
I
heard.
B
G
B
Sounds
great
just
to
see
a
thing
to
do
documents
our
proposal
process
in
that
in
that
design,
proposals
directory
is
makes
it
really
difficult
to
explain
to
other
people
what
I
mean
when
I
say
that
sounds
like
something
you
should
write
a
design
proposal
for
and
it
increases
the
burden
and
I'm
sure
you
could
make
the
argument
that
that
means
I
should
take
on
the
initiative
and
crafting
a
design
proposal
process
and
documenting
the
state
of
the
world,
but
I'm
hopeful.
We
can
all
agree
that
takes
time.
F
A
A
F
A
F
A
So
we've
got
a
lot
of
steps
in
the
notes
right
now
and
I,
don't
see
any
name
except
maybe
I,
don't
know,
there's
no
names
who,
if
you
want
to
claim
one
of
these,
please
put
your
initials
or
name
after
it.
So
it's
clear
who
who's
going
to
tackle
these,
but
I
think
that
the
the
proposal
template
is
a
super
quick
win
just
to
at
least
get
us
talking
about
what
we're
talking
about.
A
B
Completely
agree
and
just
to
sort
of
try
and
close
the
loop
on
the
architecture
thing
I
was
hearing
Clayton
say
that
there's
a
lot
of
stuff
not
yet
page
to
disk,
as
far
as
the
architectural
principles
for
kubernetes,
so
I
pointed
to
a
document
called
architecture
dot
and
be
asking
if
that
was
out
of
the
Brian
said
that
talk
is
not
out
of
date.
So,
what's.
D
The
where
there,
the
total
out
of
date,
are
not
yet
committed.
I
I
was
going
to
say,
like
there's
a
whole
bunch
of
things
that
are
pieces
of
Docs
that
exist,
but
aren't
well
organized.
So
it's
somewhat
of
the
friends
architecture.
Doc
is
a
larger
set
of
architecture
than
B
and
then
there's
a
whole
host
of
other
issues
around
it,
I
mean
there
may
be
just
a
there
has
to
be
some
commitment
among
people
who
normally
feel
that
they
like
there's
some
process
of.
D
We
need
to
document
more
and
let
things
stay
undocumented
less
in
order
to
be
successful,
and
so
maybe
the
flesh
do.
This
should
be
something
ongoing
that
people
commit
to
from
a
sig
and
I
could
stick
architecture
perspective
as
well
to
try
to
keep
flushing
things
to
this
in
order
to
reinforce
them
and
reward
that
or
reinforce
and
nag
about
that
I
guess.
D
Would
say
like
we
would
reorganize
proposals,
but
I,
don't
know
why
proposal
and
like
we
talked
about
mogilev
are
seasoned.
Are
you
don't
know
why
they
would
be
the
place?
You
would
flush
it
into
disk
to
code
to
catch
things
that
are
exist
like
API
conventions
is
a
living
document,
it's
one
of
our
more
successful
ones,
but
there's
a
set
of
things
around
that
that
are
insufficiently
clear
that
don't
get
enough
attention
being
flushed
to
this.
H
F
H
F
H
F
F
H
Like
do
a
blame
on
type
stock,
go
files
where
you
have
to
do
right
now,
yeah
API
changes
are
the
only
fruit
that
we
have
to
choke
in
this
project,
but
yeah
I
mean
as
far
as
architecture.
Nd
goes
I'm
that
I
last
did
a
flush
to
disk
on
that
in
March
or
April.
I.
Think
I
think
it
reflects
the
principles
pretty
well
as
well
as
the
current
state.
It
does
not
reflect
the
big
initiatives
that
are
in
flight,
that's
more
the
Google
Doc,
and
that
needs
to
be
flushed
to
markdown.
H
You
know
at
least
the
parts
that
people
agree
on
and
they're
a
bunch
of
other
things
that
are
like
that.
Like
I
mentioned,
you
know
moving
functionality
out
of
keep
control
to
make
it
work
with
extension,
api's
and
things
like
that
or
whatever
it
is
I
know
there
are
a
bunch
of
big
changes,
should
have
been
in
flight
for
some
time
and
it
definitely
would
be
useful
to
document
those
in
some
clear
place.
A
F
B
F
A
H
B
Let
me,
let
me
be
clear:
I
agree:
it
should
all
be
audible
via
the
git
commit
log.
I
totally
think
we
going
sorry
I
thought
you
were
referencing
like
using
a
project
to
track
this
broader
effort
of
improving
our
proposal
process
and
moving
issues
around
of
that.
If
you're
talking
about
a
project
for
design
proposals
yeah,
it
gets
first
I
thought.
A
We
were
talking
about
the
second
one
I'm
talking
about
just
the
big
level,
things
there's
so
many
drags.
You
know
repo
breakup
and
it
done
yeah,
that's
going
to
be
pretty
obvious.
Yeah
I
put
on
so
I
I,
don't
know.
I
just
I
have
a
vision
of
seeing
this
in
my
head
and
it
loves
to
work
with
Joe
Brian
we're
on
C
Mac,
because
I've
managed
big,
big
epics
like
this
in
it
and
I've
seen
it
work.
So
I
would
love
to
see
that
work
here.
G
Always
write
I
had
a
specific
item
I
wanted
to
talk
through.
That
is
a
design
problem
that
we
face
in
Service
Catalog.
We
don't
need
to
do
it
here
if
books
are
willing
to
have
an
offline
discussion
about
it,
but
it's
important
to
get
resolved
with
some
expedient
so
be
great.
If
I
could
get
someone's
time
to
talk
to
that,
like
Clayton,
if
I
have,
let's.
H
Do
that
in
email
I
mean
in
general,
okay,
but
I.
Imagine
for
the
cigars
texture
meetings
is
we
do
need
to
make
forward
progress
on
things
like
the
proposal
process
getting
stuff
written
down
things
like
that,
so
I
want.
You
want
to
reserve
the
main
meeting
times
for
hashing,
that
stuff
out
office
hours
and
the
alternate
weeks
or
more
for
people
to
raise
issues,
income
with
questions
and
help
with
design
discussions.
But
you
know
if
you
have
something
that's
fairly
urgent:
let's
just
do
that
via
email
or
something
yeah.
F
F
H
Yeah
the
thing
that
you
need
to
figure
out
how
to
get
more
more
people
like
Caleb,
able
to
constructively
contribute
to
this
process.
I
didn't
really
have
too
much
time
to
respond
and
I.
Couldn't
you
know
as
a
gist
I
can
really
comment
on
it
and
in
detail.
So
I
think
one
good
thing
about
cigar
pictures.
We
can
bring
these
discussions
out
the
open
and
maybe
get
more
people
involved,
so
you
can
make
more
progress.