►
From YouTube: SIG Architecture Community Meeting 20171109
Description
A
A
B
B
D
A
A
All
right,
the
time
is
11:30
we're
gonna,
give
people
a
couple
minutes
to
show
up.
If
you
are
so
inclined,
add
anything
to
the
agenda.
I'd
also
request
that
you
add
your
name
to
the
attending
list.
Just
so
we
know
who
is
here:
the
cats
out
the
bag
were
already
recording,
so
fYI
anything
you
say,
including
slinky
demonstration
can
be
available
on
the
Internet
till
the
end
of
time.
A
All
right,
so,
let's
go
ahead
and
jump
into
the
agenda
so
right
now
we
have
a
cook
on
breakout
session
scheduled
and
right
now
we
don't
have
an
idea
about
exactly
what
we
want
to
accomplish
during
that
time.
This
is
a
critical
time
for
us
to
get
together
with
stakeholders
firsthand
and
have
discussions
or
get
some
of
our
key
takeaways
across
to
people
and
also
get
feedback.
So
what
I
would
like
to
know
is:
does
anybody
have
any
specific
things
that
they
would
like
to
propose
for
that
time
and
if
so,
what
are
those.
E
I'm
sorry,
oh
well,
I
just
is
my
making
way
to
jump
up
which
I
just
like
I'm,
more
of
like
a
passive
observer
of
save
architecture
and
I,
guess
like
what
I
would
observe
passively
is
that
it
doesn't
seem
to
be
talking
about
architecture
or,
as
in
technical,
architectural.
It
seems
to
be
talking
more
about
project
architecture
like
you
know,
who
moves
the
pieces
of
paper
from
A
to
B
and
I.
Think
that
an
understanding
of
what
Sagarika
texture
is
trying
to
achieve
would
certainly
help
me.
B
B
So
I
I
definitely
think
that
the
sig
is
not
hitting
its
stride
yet
just
sort
of
I
think
that's
another.
Take
on
that.
What,
in
my
mind,
sort
of
the
precursor
to
us
really
getting
where
we
want
to
go
is
going
to
be
having
sort
of
a
pipeline
of
proposals
that
we're
evaluating
with
live
meetings
discussing
those
because
that's
when
I
think
there
will
be
sort
of
real
decisions
at
stake
and
that's
what
I
think
people
will
be
sort
of
more
invested
in
actually
what's
going
on
on
that
stuff.
B
So
so,
for
me,
the
quickest
way
to
get
to
the
point
where
we
actually
do
this
as
being
productive.
Looking
at
sort
of
architectural
issues
is
we
got
to
get
our
process
house
in
order
right
and
I.
Think
a
lot
of
that
comes
around
that
cap
process
which
which
you
know
I'm
as
guilty
as
I,
think
everybody
is,
as
you
know,
other
things
have
come
up
and
it's
become.
B
You
know
getting
that
process
too
fine-tuned,
and
really
you
know
evangelizing
that
it's
not
something
that
we've
done
yet.
We've
started
on
it,
but
it's
kind
of
you
know
it's
been.
It's
been
fits
and
starts
so
between
now
and
then
in
a
cube
con
until
we
have
that
kept
process
sort
of
figured
out
in
a
couple
of
beta
testers
running
through
the
process,
I
think
we're
gonna
have
a
hard
time
focusing
discussions.
A
So,
in
light
of
that
observation
Joe,
what
would
you
think
would
be
a
good
you
set
the
the
coup
I
mean
my
feeling
is
that's
a
great
time
to
radiate
information
about
what
the
cap
is,
what
we're
trying
to
accomplish
via
that
and
how
it
ties
into
the
big
picture.
You
know
to
get
some
additional
buy-in,
because,
frankly,
a
lot
of
people
are
confused
about
it
and
don't
really
know
that
it's
actually
happening.
Yeah.
B
Mean
so
this
this
time,
I'm
slot
is
Thursday,
it's
at
the
same
time
slot
where
I'm
giving
my
talk
so
I'm
not
going
to
be
able
to
actually
attend
it
and,
like
you
know
it
overlaps
with
a
bunch
of
other
stuff,
so
I.
This
is
the
cigar
architecture,
deep
dive
that
Brian's
doing
right,
yeah,
I
I
think
it's
gonna
be
difficult
like
first
of
all,
I,
don't
know
what
the
hell
Brian's
gonna
say,
because
it's
not
like.
We
have
anything
decided
but
I'm
sure
he'll
have
stuff
to
talk
about.
I
I.
B
Think
there's
a
difference
between
like
what
do
we
want
to
say
there
versus
what
do
we
want
to
get
time
done
in
time?
For
that
I
mean
that's
not
going
to
be
a
working
session.
That's
not
going
to
be
a
discussion
thing
most
likely
I'm
assuming
it's
45
minutes,
probably
a
Brian
talking
at
an
audience.
A
Well,
I
mean
so
this
is
this
is
a
sake
time
slot
and
a
deep
dive
can
mean
a
lot
of
different
things
for
everybody
here
in
the
sake
and
I.
Don't
think
necessarily
that
Brian
is,
is
the
Grand
Poobah
of
that
time
slot?
If
that's
not
what
the
sake
necessarily
needs
to
accomplish.
I
think
he's
open
to
getting
some
input
on
what
what
is
the
best
thing
to
do
there
so
I,
don't
necessarily
even
get
some
best
assumption
on.
A
B
I
think
it
might
be
useful
for
us
to
set
ourselves
a
goal
in
time
for
kube
Khan
to
actually
have
kept
process
down
to
the
point
where
we
can
look
at
it.
We
can
dry
lab
it
in
our
brains
and
we're
like
okay.
This
is
this
is
saying
okay,
I'd,
like
to
also
in
that
time
identify
a
couple
of
things
that
we
want
to
sort
of
Shepherd
through
this
in
terms
of
a
beta
test
and
I.
B
Think
part
of
that
process
is
determining
like
one
of
the
things
I
think
we
were
talking
about
what
the
cap
process
was.
Having
you
know,
human
sort
of
Shepherds
I,
don't
know
what
we
call
them
sort
of
assigned
to
this
to
actually
help
these
caps
through
in
sort
of
a
random
scattershot
type
of
thing
right.
Yeah.
We
have
are
getting
some
of
that
process
in
place.
Then,
by
the
time
we
get
to
cube
con,
we
can
have
some
some
beta
testing
of
this
stuff,
going
on
I
think
having
a
working
session
during
the
contributor
some.
B
It
might
make
sense
where
we
really
take
a
bunch
of
feedback
of
like
what's
working.
What's
not
working
around
this
and
then
having
the
the
sig
architecture,
deep-dive
be
more
focused
on
what
is
you
know
essentially
getting
people
to
the
idea
that
hey
we
want
to
do
this
kept
process.
I
I,
honestly,
like
Brian's,
not
here
so
I,
can't
ask
him
about
that.
Stuff.
I,
don't
know
what
he
has
planned.
For
that
thing.
What
I
don't
think
is
appropriate
is
for
Brian
to
actually
talk
for
45
minutes
about
what
he
thinks.
B
The
architecture
is
when
this
group
hasn't
sort
of
decided
it,
and
we
haven't
actually
come
to
sort
of
sort
of
group.
Understanding
on
that,
I
think
that
we
have
to
move
past
sort
of
unilateral
decisions
on
what
the
architecture
is
and
we
have
to
move
to
something.
Where
we're
you
know,
there's
there's
a
sort
of
scale
doubts
understanding
of
what's
going
on
so
so.
F
I'm
gonna
jump
in
real
quick
here
with
the
community
meeting.
I
saw.
We've
got
something
later
one
of
the
things
that
I
was
approached
side-channel
because
I'd
created
those
diagrams
based
on
our
conversations
just
trying
to
put
two
pictures.
What
I
think
Brian
and
folks
were
saying-
and
there
are
folks
who'd
like
to
have
that
stuff
discussed
in
the
community
meeting
and
I'm,
not
I'll.
Let
other
folks
decide
when
it's
ready
and
whatnot,
but
actually
communicating
and
having
discussions
on
architecture
where
you've
got
a
whole
bunch
of
people
in
that
room
even
going
beyond.
F
That
might
be
a
use
of
time
for
that
slot.
So
people
don't
ask
questions,
try
and
understand
intent,
because
this
is
cig
architecture
and
if
we've
got
something
that
can
display
that
diagram.
Why
is
that?
We,
as
a
group,
are
happy
on
that
might
be
a
useful
time
for
that
slot.
I,
don't
know
just
spitballing
yeah.
B
So
I
mean
one
of
the
things
that
and
I
think
those
those
diagrams,
and
thank
you
for
doing
that.
Man
I
think
those
are
super
useful,
but
to
a
certain
degree,
the
map
is
not
the
territory
right,
so
these
diagrams
are
a
good
way
to
help
orient
people
I
think
we
need
to
be
careful
that
we
don't
view
those
diagrams
as
a
straightjacket
in
terms
of
like,
like
they
are
an
approximation
of
what
we
want,
the
architecture
and
the
project
to
be.
B
That
way,
I
just
think,
as
we
present
this
to
folks.
We
got
to
be
careful
that,
like
these
are
some
ways
to
view
it
and
I
think
that
a
lot
of
times
it's
very
tempting,
to
sort
of
view.
These
things
in
a
very
rigid
sort,
categorization
type
of
thing
and
I'm,
just
not
convinced
that
that
categorization
always
holds
up
to
to
sort
of
the
harsh
light
of
reality.
Yeah.
F
Yeah
and
the
only
reason
that
I'm
suggesting
even
putting
the
stuff
out
there
or
coming
up
with
something
to
put
out
there,
is
that
it's
being
requested
and
right
now,
I
think
a
lot
of
folks
see
kubernetes
as
this
giant
spaghetti
monster.
They
can't
get
their
mind
around
and
when
we
can
put
it
into
a
picture,
it'll
help.
People
who
weren't
part
of
this
group
who
aren't
part
of
the
core
of
it
have
a
better
understanding
of.
A
Think
one
really
important
clarification
about.
That,
though,
is
we're
in
this
state
of
having
something
out
there
I
mean
we
can
describe
take
pictures.
You
know
of
what
exists
right
now,
but
that's
actually
not
going
to
notice
that
much
value
in
terms
of
architectural
speaking.
What
we
really
need
to
do
is
focus
on
the
the
migration
transition
movement
forward
of
these
components
that
we
already
know
and
also
developing
a
model
around
that
so.
B
That's
tricky
yeah
anytime.
We
have
these
discussions
and
and
I
think
a
lot
of
times
they
get
rattled
in
terms
of
some
of
the
mechanical
things
that
we're
talking
about
like
how
are
we
gonna
break
up
a
repost?
How
are
we
gonna
manage
the
community
as
it
grows,
separated
from
which
grew
architecture
issues
of
like
how
are
we
gonna
actually
have
the
components
in
the
system
relating
to
each
other?
What
is
sort
of
the
patterns
that
we
want
to?
Actually,
you
know
encourage
people
to
use
as
they
build
out
new
features.
B
How
do
we,
how
do
we
actually
grow
the
ecosystem?
How
do
we
build
an
architecture
that
enables
a
growing
ecosystem
in
a
decoupled
way?
So
those
things
are
an
inseparable
from
the
mechanics
of
how
do
we
actually
break
all
this
stuff
out
and
I?
Think
so
many
times
when
we
have
those
discussions
that
stuff
gets
all
muddled
together,
yeah.
D
The
architecture
should
be
this
and
this
should
be
in
and
this
should
be
out
and
whatever,
but
they
don't
seem
to
persist
very
long,
because
there's
no
well
stated
goal
for
the,
whereas
if
we
said
what
we're
trying
to
do
is
enable
a
minim,
kubernetes
installation
with
you
know
arbitrary
extensions
via
you
know,
what's
the
right
word
approved
and
endorsed
additions,
as
well
as
unapproved
unendorsed
additions
are
the
following
mechanisms.
Here
are
some
examples:
I
think
that
would
go
a
long
way,
and
then
we
can
say
right
now
to
achieve
that.
D
F
G
That's
fundamental
to
what
every
sync
should
be
doing,
but
I
totally
agree
with.
If
we,
if
we
lead
the
way
by
example,
you
know
I
think
that
would
be
a
good
thing,
because
then
we
can,
because
we
can
bound
the
scope
of
conversation
pieces
in
the
future
too,
as
well
like
that's
outside
of
our
purview.
That's
inside
of
preview
type
of
thing
well,.
A
Not
to
be
too
meta
here,
but
it
seems
like
we
need
a
proposal
around.
We
need
people
to
be
bringing
proposals
to
sig
architecture
as
much
as
any
other
so
because
the
problem
is
at
the
end
of
the
day,
what
gets
done
is
what
gets
done
and
right
now,
there's
nobody
doing
anything
and
I.
Think
Brian
is
trying
to
do
as
much
as
you
can
in
the
background
and
I
give
him
major
props
for
that,
because
he's
probably
one
of
the
busiest
people
I
know
and
he's
still
cranking
out
stuff.
A
A
We
need
to
do
it
during
this
meeting
and
hack
on
getting
stuff
done
and
not
just
by
chatting
or
we
need
to
have
people
actually
spending
time
in
the
background
and
doing
things
and
presenting
to
this
group
and
saying
yay
or
nay,
and
and
also
this
group
presenting
I
think
being
really
positive
and
not
just
like
tearing
things.
Apart
of
our
knits
like
we
need
to
get
past
knits
where
we're
never
gonna
get
anywhere
so.
B
I
think
I
think
there's
there's
dual
missions
for
this
group
and-
and
you
know-
and
this
is
importing
some
of
the
discussions
that
we've
been
having
the
during
committee-
I-
think
that
there
is
on
this
group
there's
there's
this
idea
that
we
want
to
have
a
definition
of
what's
inside,
of
kubernetes,
what's
outside,
of
kubernetes
and
sort
of
like
like
what
is
the
boundary
around
what
we're
doing
and
why?
What
is
the
well
recent
way
around
that
I
think
that
goes
beyond
a
diagram
to
sort
of
like
it's
building
a
shared
understanding
of
like
well.
B
This
is
what's
appropriate
to
be
in
kubernetes
and
stuff,
that's
not
appropriate
and
maybe
defining
different
levels
of
that.
So
there's
there's
and
that's
not
architecture,
that's
in
some
ways,
product
right,
but
I,
think
the
these
things
become
sort
of
conjoined
in
a
pretty
fundamental
way.
The
the
way
that
we
build
the
thing
defines
what
it
can
do
and
what
it
can
do
you
know,
and
so
there's
there's
definitely
a
zambian
biosis
there.
The
second
thing
I
think
we
need
to
do
is
we
need
to?
B
D
So,
just
to
go
back
to
your
point
about
you
know
what
the
boundaries
of
the
system
are,
etc.
That
is
precisely
the
discussion
that
seems
to
go
run
around
in
circles.
Every
time,
I
and-
and
my
observation
is
the
reason
it
does
is
because
it's
not
entirely
clear
what
the
goals
of
setting
that
boundary
are.
D
So
so,
if
we
said
you
know,
goals
are
a
B
and
C,
and
if,
for
those
determine
that
boundary
is
XYZ,
you
know
that
that's
a
way
of
making
chord
progress,
but
if
you
just
have
a
bunch
of
people
sitting
around
saying
I
think
the
boundary
should
be
here
and
somebody
else
saying
I
should
be.
The
boundary
should
be
here.
D
The
conversation
gets
run
around
in
circles,
so
my
question
to
you
is
is
very
direct:
do
you
do
you
think
that
the
right
starting
point
is
to
decide
what
the
goals
are
and
therefore
those
determine
where
the
boundaries
are
or
I
mean?
It
sounds
like
the
boundary
discussion
sort
of
went
ahead
without
explicitly
stating
what
the
goals
of
the
boundary
are.
Yeah,
so
I
think.
B
I
think
there's
a
certain
amount
of
like
I'll
know
it
when
I
see
it
going
on
here
for
sure
I'm
not
sure
that
we
can
get
away
from
that,
because
there's
there's
sort
of
like
any
definition
of
goals
is
that
going
to
immediately
be
sort
of
like
mapped
in
people's
minds
to
okay.
That
means
X,
Y,
&,
Z
and
so
therefore
I'm
for
or
against
it
I
I
think
that
we
need
to
make
forward
progress
there
I,
you
know,
Brian
has
a
document
that
is
you
know
what
is
kubernetes
I.
B
You
know
that
he
points
everybody
at
for
this
stuff.
This
is
useful
in
some
ways.
I
think
this
is
the
one
that
it's
not
it
hasn't
been
number
one
is
I,
don't
think
it's
been
vetted
by
everybody
and
I,
don't
think
it's
been
tested
in
terms
of
being
able
to
make
decisions
about
what's
in
and
out,
I
think
it
might
be
worthwhile.
B
It
might
be
worthwhile
for
us
to,
as
a
group
form
a
set
of
people
who
are
gonna
actually
go
through
and
write.
A
document
saying
this
is
what
we
think
the
boundary
should
be.
We
can
discuss
it
in
tune
that
I,
don't
think
we're
gonna
hit
perfect
agreement,
but
I
think
like
we
can
probably
like
I
mean
part
of
the
problem-
is
that
none
of
the
SIG's
have
a
formal
decision-making
process
right.
B
We
can
actually
say
these
are
the
people
in
cig
architecture
and
then
we
can
have
the
the
steering
committee
ratify
that
or
what
we
can
do
is
we
can
work
cooperatively,
try
and
get
to
some
sort
of
consensus
without
an
approved,
formal
approval
process
and
then
and
then
let
the
the
steering
committee
go
through
and-
and
you
know,
approve-
reject,
modify
that.
But
at
least
we
can
tee
it
up
for
the
steering
committee
to
be
able
to
make
that
decision.
I
feel.
A
Like
this
is
really
out
of
bounds
for
the
steering
committee
and
I
know
that
I'm
not
on
the
committee
and
to
say
that,
but
I
mean
there
was
an
explicit
statement
that
they
don't
want
to
get
involved
in
technical
arbitration.
So
the
best
thing
that
we
can
do
is
to
self-govern
around
Korea
s
Asian
model,
because
we
also
have
to
use
those
powers,
those
decision-making
powers
around
the
the
proposals
that
are
getting
to
send
to
us,
ergo
yeah.
A
B
F
Can
I
make
a
suggestion
to
come
back
to
me?
Bj's
is
practical
thing.
We're
talking
very
meta
here.
What
about
the
idea
of
just
starting
with
will
right
here's
the
bounds
of
sig
architecture,
here's
the
goals
of
sig
architecture
and
then,
if,
if
when
it
comes
to
the
decision-making,
we
can
wait
until
the
last.
You
know
just
in
time.
If
we
have
a
problem
where
the
kind
of
the
consensus
of
the
people
here
doesn't
work
and
we
need
something
more,
then
we
go
tackle
the
okay.
How
do
we
implement
process?
F
Because
this
just
isn't
working
and
then
we
can
handle
that?
So
it's
kind
of
the
just-in-time
approach
and
it
gets
us
kind
of
the
practical
of
here's,
the
goal
and
here's
the
bounds,
and
then
we
can
start
hopefully
that'll
help
us,
you
know
start
attacking
diagrams
and
communication
and
how
we
handle
the
cap
process
and
things
like
that
as
well.
I
mean.
B
I,
like
that
idea,
III
I
don't
have
high
confidence
that
we
won't
immediately
get
deadlocked
on
some
contentious
things.
I
think
this
is
more
than
a
lot
of
the
other
things.
This
is
one
of
those
places
where,
where
we're
gonna
see
things
come
to
a
head
and
we're
gonna
see
people
with
a
lot
of
different
priorities.
You
know,
you
know,
have
you
know
working
against?
B
You
know
not
against
each
other,
but
a
lot
of
priorities,
sort
of
meeting
up
and
not
matching
well,
and
that's
just
natural
and
any
sort
of
big
group
of
people,
but
I
think
this
is
one
of
those
places
where
we're
gonna
see
a
lot
of
that
stuff
happening
so
more
than
any
other
city.
I
think
we
actually
do
need
some
sort
of
decision-making
process
in
this
sig
that
that
you
know
we
can
use
moving
forward.
A
G
A
Let
me
look
at
the
agenda
real
quick,
because
there
is
a
cap
thing
on
there.
I
just
want
to
make
sure
that
there's
not
something
okay,
so
I
do
have
a
tactical
thing
too,
that
we
absolutely
need
to
address
this
meeting,
which
is
what
are
we
going
to
tell
the
community
in
in
an
hour
when
we
have
that
community
meeting,
because
we
have
an
update
to
give
and
I
I
need
have
at
least
some
something
to
say
other
than
boy
we're
having
a
great
time
being
deadlocked
right.
So
I.
E
Have
a
quick
suggestion
which
I
think
helpful
so
with
some
of
the
bigger
picture
which
is
like
I'm
very
happy
to
hear
that,
like
the
goal
is
actually
to
get
more
like
you
know,
technicians
being
made,
it
feels
like
maybe
a
problem.
Is
we
don't
have
like
this
pipeline
of
techs,
whatever
it
is
coming
in
yeah?
So
if
you
use
the
floor
to
say
like
here's,
what
stick
of
architecture
can
do
for
you?
E
B
I
think
that's
great
and
I
would
love
to
get
to
the
point
where
we're
publishing
this
stuff
like
a
couple
days
beforehand.
If
people
can't
make
the
meeting,
they
can
actually
get
some
opinions
in
over
email
yeah.
It
can
really
be
something
where
it's
like
hey.
This
is
something
that
the
community
is
taking
a
look
at.
Let's
all
sort
of
laser
focus
on
that
and
see
if
we
can
actually
sort
of
you
know,
work
some
of
this
stuff
out.
So
that's
yeah.
That
is
this:
the
kept
process
I'm
looking
at
I'm.
B
Looking
at
the
the
cig
architecture
charter,
which
the
first
thing
it
says
this
is
work
in
progress.
One
of
the
things
there
is:
what
is
it
isn't
out
of
scope
and
then
some
of
it
is
document
evolving.
The
system,
architecture
I
think
the
cap
stuff
is
really
part
of
that
and,
of
course,
this
links
to
oh
here
is
the
yeah
okay,
so
we
can
do.
We
can
do
two
things
at
once.
B
Right
I
mean
we
don't
have
to
I
mean
in
terms
of
does
somebody
want
it
like,
like
we
have
the
the
scope
of
kubernetes
is.
Is
that
is
that
what
is
kubernetes
thing
I?
It
might
be
worthwhile
for
somebody
to
actually
take
a
look
at
that
through
the
eyes
of.
Is
that
useful
for
this
group
to
be
able
to
make
decisions
and
say
this
is
in
this?
Is
out
and
I
think
this
is.
B
Ya
know
I'm
looking
for
a
volunteer
to
take
a
look
at
the
what
is
and
is
not
kubernetes
and-
and
you
know,
come
to
an
opinion
of
that
with
respect
to
is
that
useful
to
this
group,
because
I
think
it's
a
little
bit
so
you
have
a
little
bit
focused
on
end
users
versus
versus
something
that
is
more
sort
of
architectural,
technically
focused
for
this
group.
I
I'll.
F
Jump
in
and
say,
I
think,
there's
a
good
reason
that
it
is
relevant
to
this
group,
because
what
is
this
group
debating
and
who
are
the
end-users,
and
what
does
this
group
need
to
architect
for
so
like
Joe?
Earlier,
you
talked
about
the
ecosystem,
right,
that
is,
a
class
of
user
somebody,
who's
building
cloud
providers,
volume
plugins
those
kinds
of
things,
those
are
different
end-users,
and
so
we
need
to
have
architectural
patterns
that
we
get
folks
around.
That
enable
them
to
be
successful,
and
that
is
a
class
of
user.
F
But
we
have
to
define
what
is
and
what
is
not
kubernetes.
If
kubernetes
is
not
all
those
volume
providers,
then
we
need
to
make
sure
we
have
a
clear
interface
and
I
saw
sure
that
document
is
end-users,
but
there's
still
more
end-users
that
aren't
covered
there,
and
we
probably
need
to
refine
that
pitcher
to
enable
the
ecosystem.
As
you
said,
and
I.
B
Think
this
document
is
very
much
about
the
community
zeikos
right.
What
is
the
kubernetes
way
of
approaching
the
world
which
is
different
from
what
is
the
kubernetes
project,
which
is
going
to
be
a
subset
of
the
larger
ecosystem?
I,
don't
think
that
we
have
a
clear
line
in
terms
of
what
the
project
is
versus
the
wider
ecosystem.
B
Yeah,
that's
all
very
meta
I.
You
know
I
I'm
signed
up
to
do
everything
but
like
if
nobody
else
wants
to
I
can
I
can
actually
do
that
and
actually
make
me,
maybe
take
a
stab
of
like
like
how
do
we
actually
start
drawing
a
line
between
kubernetes
project
in
the
ecosystem?
I
know,
Brian
also
volunteer.
Ninel
tried
to
take
a
hack
at
that
also,
but
you
know,
he's
he's
is
were
able
to
join
us
right
now.
Is
it
possible
that
you
and
Brian
could
pair
on
this
and
I
had
that
dry?
We
could
try.
B
E
Like
politics
too
much
but
like
I,
feel
that
you
don't
want
to
like
you
want
you
want
to
work
in
terms
of
like
as
things
arise,
you
define
your
responsibilities.
You
don't
want
a
constitutional
document
which
therefore,
like
people,
try
to
parse
and
slice
and
say,
like
you
know
what
this
is
not
in
our
balance
right,
you
wanna
say
we
who
else
is
going
to
sign
this?
We're
gonna,
decide
and
I.
B
Would
I
mean,
like
I,
think,
let's
discuss
that
also
I,
don't
want
to
like
rathole
on
that
right
now.
I
think.
That's
a
good
point
of
discussion
is
this
sort
of
like
law,
or
is
this
a
guideline
and
it's
case
law
in
terms
of
like
it's
an
evolving
thing
over
time,
right
and
I.
Think
that
that
there's
one
of
the
things
that
why
there's
humans
in
the
loop
with
this
is
that
we
actually
do
want
to
have
an
opportunity
for
this
group
to
actually
sort
of
be
realistic
about.
F
And
to
complement
that
I
mean
so
I
threw
this
out
yesterday
an
idea
of
a
ecosystem
working
group
to
deal
with
those
ecosystem
projects,
and,
and
how
do
you
enable
them
and
worse
the
interface
and
just
to
do
that?
Work
of
saying?
Okay,
if
sega
architecture
is
the
core
of
the
kubernetes
project
and
then
there's
that
ecosystem?
F
This
say:
Goins
everything
and
there's
ecosystem
and
there's
all
of
this
and
the
diagrams
that
I
produce
based
on
our
conversations,
talked
a
lot
about
ecosystem
and
where
that
line
is
so
to
kind
of
have
an
area
that
covers
that
as
well
and
I've
been
talking
to
folks-
and
this
is
kind
of
cute.
You
know
I
curated,
the
ideas
and
the
thoughts
of
a
number
of
people
to
write
that
up.
F
But
it's
it's
by
no
means
mine
and
in
those
conversations
with
folks,
I
found
that
there's
actually
you
know
those
pictures
that
I
drew
based
on
our
conversations
here.
It
kind
of
sat
well
with
people
as
far
as
the
dividing
line,
they
kind
of
like
that
and
I
think
it's
worth
going
out
and
validating
that
with
a
wider
audience,
because
that
may
help
you
Joe
and
Brian
kind
of
come
to
conclusion
on
it,
because
at
least
that
conveys
it
in
a
picture
in
a
way.
B
A
We
need
to,
we
need
to
move
on
a
little
bit
because
we're
again
in
the
meddler
I
think
that
one
thing
just
is,
as
my
closing
thoughts
about
this
is
that
we
also
need
to
be
thinking
about
risk
and
the
a
sloppy
roughshod.
Kubernetes
architecture
is
a
project
risk,
and
so
we
need
to
be
really
cautious
and
cognizant
of
what
role
we
play
in
that
and
where
we
can
step
in
to
avert
risk.
So
you
know
there
may
be
a
high
level
risk
with
with
things
being
put
in
tree.
A
There
shouldn't
be
or
some
of
those
things,
and
we
need
to
keep
our
eye
on
that
ball
in
some
ways
more
than
diagrams
and
things
six
or
easy
for
the
community
digest,
because
there
is
real
risk
in
the
code
right
now
that
we're
sitting
on
top
of
that
can
easily
blow
up
on
us,
and
we
need
to
just
watch
for
that.
So
well.
A
B
A
G
I
had
my
hand
on
the
green
button.
I
just
said
to
find
the
mute
as
everything
shifted
around
when
I
hit
the
thing.
So
here's
the
actual
cap
template
that
existence
exists
in
the
main
repository.
So
if
you
go,
let
me
just
back
up
for
you.
G
If
you
go
to
an
area
contributors,
design,
proposal,
architecture,
so
zeros
your
cap
template
right
and
I
like
looking
at
the
raw
just
because
then
I
can
compare
back
and
forth
with
the
example
now
right
off
the
bat
there's
this
section,
which
is
like
the
metadata
right
and
the
metadata
is
great
and
it
sucks
at
the
same
time
it
sucks
because
all
of
our
documents
are
in
markdown
and
we're
embedding
the
ml
and
markdown.
So
there's
a
problem
here
that
exists
when
you
want
to
put
references.
G
So
so,
if
you're
trying
to
put
a
markdown
reference
inside
of
C,
also,
basically
to
point
to
the
other
document,
it
doesn't
work.
So,
instead,
what
I
did
is
I
actually
put
a
I
put
references
directly
in
the
summary
portion
of
my
thing
right,
so
the
the
metadata
section
doesn't
work
so
well,
because
your
again
you're
embedding
the
animal
inside
of
markdown
so.
B
I
think
I
think
so.
Tim,
the
the
the
thinking
behind
this
and
I
don't
know
whether
it's
same
thinking
or
not
was
that
the
the
raw
github
interface
for
this
stuff
is
probably
not
good
enough
and
that
doing
some
sort
of
specialized
render,
with
cross
references
and
the
ability
to
slice
and
dice
these
things
and
search
is
actually
going
to
be
the
thing
that's
going
to
be
most
valuable.
So
that's
one
of
the
reasons
why
the
metadata
is
there
like.
B
D
G
G
F
Can
I
can
I
make
a
proposal
here,
just
real
quick
on
this
sure,
if
you
look
at
how
I
mean
static
site
generators,
use,
markdown
and
yamo
all
the
time
to
do
this
or
other
things,
and
they
actually
structured
the
document
differently
instead
of
embedding
it
as
a
snippet.
Here
they
put
it
first
and
then
the
markdown
follows
it.
In
fact,
a
lot.
F
B
F
G
F
B
For
folks
that
are
running
a
lot
of
documents,
as
there's
this
utility
out,
there
called
grip,
which
is
essentially
does
local.
It
uses
a
web
service
at
github
to
actually
do
rendering
of
a
markdown
file
using
the
github
engine,
and
so
you'll
actually
see
exactly
what
it's
going
to
look
like
on
github
as
you
do
it,
but.
G
The
that
was
one
of
the
logistical
things
that
I
noticed,
because
if
you're
gonna
do
references
and
you're
gonna
link
documents,
you
have
a
slight
conundrum.
The
the
second
thing
is
I,
like
the
talked
a
lot
to
forcing
people
to
write,
to
talk
at
the
after
the
initial
metadata
information,
but
the
the
how
we
break
down
pieces
here
in
summary
and
motivation,
I
change
the
nomenclature
because
I,
it
seemed
weird
right,
because
if
you
look
here,
I
have
a
summary
section,
exactly
like
it's
specified,
but
then
there's
motivation.
G
It
has
guide
level
explanation
of
reference
level.
Explanation
and
I've
I've
been
working
in
the
software
engineer
for
umpteen
years
and
I've
never
seen
it
broken
down
this
way
as
a
human,
readable
explanation,
so
I
I
tried
to
simplify
it,
but
I
said
summary,
and
here
are
my
objectives,
and
these
are
my
goals
and
my
non
goals.
I
just
tried
to
simplify
it
because
just
from
reading,
just
as
reading
it
and
referencing
other
documents
that
we
have
internally,
it's
the
same
process
right
so.
B
G
Yeah,
because
the
the
new
nature
here
is,
unlike
anything,
I've
seen
right,
it's
very
I,
I,
look
I,
don't
want
to
use
the
word
Byzantine,
but
it's
just
it's
weird
right,
like
I've,
never
seen
it.
This
is
much
much
simpler
nomenclature
for
defining
what
you
you
know.
What
are
your
objectives
essentially
right?
What's.
G
B
G
Scope
or
object,
here's
where,
like
you
know,
things
start
to
get
fuzzy,
but
I
think
motivation
is
part
of
it
right
and
scope
objectives,
goals,
motivation
all
have
similar
things,
but
I
think
breaking
down
the
goals
and
non
goals
is
actually
a
good
part
of
of
that
triumvirate
of
words.
Whatever
way
you
want
a
wordsmith
or
what
about
your
thesaurus
on
things
that
are
similar
right,
the
one
thing
that
I
thought
was
weird
is
they
have
reference
level
excellent
explanation,
and
this
other
part
here
and
I'm
like
why?
Don't
we
just
say
like?
G
B
One
of
the
things
that
we're
struggling
with
this
team
and
I-
don't
know
if
you
saw
all
this
is
that
when
Caleb
came
at
this,
he
very
much
viewed
this
as
a
tool
to
be
able
to
generate
release,
notes
that
made
sense
right.
So
his
take
on
this
was:
oh,
these
things
are
actually
tied
to
releases
and
a
release
includes
a
bunch
of
caps.
G
That's
true
I
think
you
might
want
to
have
a
little
bit
of
both
like
some
of
the
implementation
history
is
actually
in
like
replaces
or
supersedes
by
right,
so
it's
kind
of
tied
together
in
a
little
bit
having
English
explanation
of
implementation.
History
is
also
good,
but
let's,
let's
walk
down
through
here.
So
the
again
I
changed
this
part
to
just
be
proposal
and
I.
Underneath
the
proposal
I
outlined
via
user
stories.
Right
like
this,
is
going
from
A
to
B
outlined
the
user
stories.
G
One
thing
that
Clayton
brought
up,
which
I
thought
was
really
interesting,
is
not
a
topic
in
in
the
cap
is
what
are
the
security
implications
of
the
changes
that
you're
making?
And
you
know
you
could
outline
none
if
there
are
none
but
I
think
that's
kind
of
a
good
thing
to
have
in
a
template
because
it
forces
you
to
think
about
it.
Could.
A
D
G
Could
be
like
it
could
be
risk
and
then
a
subsection
security
and
a
person
could
just
copy
the
template
and
they
could
add
those
bits
in
there.
My
goal
is
to
have
a
template.
That
is
sane,
that's
that
people
can
just
copy
and
paste
and
it
just
they
fill
in
the
bits
and
every
proposal
has
a
similar,
feel
and
you're.
You
know
when
you
go
from
one
proposal:
ADA
prose
will
be
you're
not
like
reinterpreting
the
universe,
to
try
and
make
it
cents
out
of
it
right.
So.
B
Every
time
I've
done
kind
of
looks
like
this
there's
this
discussion
around
sort
of
like
should
we
have
a
heading
here,
that's
required
for
somebody
to
fill
out
a
section
vs.
having
guidelines
saying
make
sure
you
think
about
XYZ
and
invariably,
over
time.
Everybody
comes
in
and
says:
oh
I
want
to
have
my
section
in
the
template,
because
it's
important
to
me
and
then
you
end
up
with
a
template.
B
That's
like
30
pages
long,
so
I
think
monitoring,
documentation,
accessibility,
internationalization,
like
all
those
things
end
up
being
like
things
that
can
get
tacked
on
that
are
going
to
be
important.
You
know
in
some
cases
less
important
than
others.
I
do
think.
Security
is
an
important
thing,
but
I
think
we
need
to
be
a
little
reticent
about
adding
too
many
sections
I'm
totally
cool
with
having,
as
part
of
the
template,
saying,
make
sure
you
are
considering
XY
and
Z
and
having
a
list
of
sort
of
like
considerations
that
people
should
be
thinking
through
I.
G
Yeah
I
I,
agree,
I,
think
what
we're
trying
to
accomplish
is
the
coarse
grain
break
out
of
the
tree
and
there
could
be
a
bunch
of
branches
and
leaves
but
we'll
leave
that
up
to
the
people
to
decide
and
but
as
long
as
the
coarse
grain
feel
is
similar
and
solves
the
problem
of
the
documentation
so
that
they
has
a
similar
feel
and
has
enough
meat
there
for
people
to
chew
on
I
think
that's
kind
of
the
ultimate
goal.
I
know.
D
G
G
So
other
thing
here
there
was
one
other
piece
that
people
called
out
and
again
this
could
be
one
of
those
things
where
we
could.
We
could
have
a
guide
lines
or
guide
rails
was
how?
How
are
you
testing
this
thing
right?
So
I
I
copied
the
other
bits
that
were
there,
which
was
graduation
criteria
and
implementation,
history
and
then
I
have
other
links
reference
below,
but
the
one
thing
that
people
asked
for
was:
how
is
this
being
tested?
B
Yeah,
so
one
thing
I
think
that
we
should
make
clear
in
this
template.
I'm
not
sure
it
came
across.
Is
that
like
if
you
have
a
feature-
and
you
want
to
take
it
to
alpha
and
then
to
beta
and
to
GA?
Is
that
a
single
cap
across
that
entire
thing
or
is
it
a
or
is
it
a
or
do
you
do
a
separate
kemp
for
each
step
in
that
process?
I
think.
G
B
A
So,
just
from
a
purely
implementation
standpoint,
what
happens?
Is
you
have
the
cap
which
is
document
in
markdown,
and
then
you
have
for
every
release
milestone.
You
have
a
series
of
issues
that
are
describing
the
work
to
be
completed
in
the
milestone,
the
chip
away
at
the
cap
and
then
the
PRS
referenced
the
issues,
so
you
can
actually
drill
down
from
any
PR
in
any
milestone
to
see
exactly
what
CAPA
ties
to
so
so
that
thread.
Ergo
means
that
the
the
cap
is
is
a
high-level
multi,
milestone,
type
of
and.
G
I
think
that
that
solves
the
big
problem
of
the
features
repo
if
we
force
it
right,
because
the
features
repos
this
unmaintained
goo-
and
this
actually
would
force
the
live.
It
doesn't
force
unless
we
say
that
it's
going
to
enforce,
but
I
think
that
that
would
help
to
enforce
getting
rid
of
the
features
repo
and
having
some
canonical
reference
of
a
living
document.
That
outlines.
G
B
G
Simplifying
the
nomenclature,
a
lot
because
I
don't
like
what
was
here
I,
it
seems
it
seems
like
it
was
cribbed
from
some
other
location
like
you
mentioned
from,
and
they
had
some
breakdown
there
of
how
they
want
to
do
it,
but
it
does
not
jive
with
other
thing.
Other
documents
that
are
well
defined,
architectural
instructions
like
if
you,
if
you
read
like
Carnegie
Mellon's,
got
a
whole
set
of
books
outlining
how
to
describe
software.
Architectures
is
all
about
simplicity
and
user
stories,
so.
B
D
It's
a
quick
question
about
the
the
deprecation
of
the
features
reaper.
So
so
what
are
we
replacing
and
this
this
document
in
front
o
an
instance
of
this
template
would
tell
us
about
a
particular
feature
or
set
of
features.
But
where
does
one
go
for
you
know,
I
want
to
see
what's
lined
up
for
release
whatever
it
is
one
point
ten
or
whatever.
How
do
I
know
what
features
are
likely
to
land
in
three
or
six
months
time
that.
G
D
A
Not
that's
not
entirely
accurate
I,
so
there
is
a
planning
portion
that
it
precedes
every
release
milestone
during
which
SIG's
will
determine
what
they
will
and
won't
commit
to
deliver
during
that
particular
milestone
that
the
cap
will
have
the
entirety
of
the
value
described,
but
the
implementation
details
are
going
to
be
done
at
the
last
responsible
moments.
So
we
don't
have
a
bunch
of
people
working
on
things
that
aren't
teed
up
for
work.
A
So
there's
a
specific
document:
that's
going
to
be
used
for
planning
purposes
and
translate
into
issues
that
get
specified
for
each
milestone
ahead
of
the
milestone.
So
if
you
want
to
look
in
what's
in
110,
you'd
go
search,
get
github
issues
and
it'd,
be
110,
would
be
the
milestone
and
don't
give
you
everything
you
need
to
know.
It'll
say
what
keppa
ties
back
to
and
so
forth,
but
so
that'll
be.
There
will
be
pre
work
done
at
an
issue
level
because
that's
that's
waste.
G
Yeah,
so
what
I'll
do
is
I'll,
do
a
PR
against
this,
but
like
one
of
the
things
to
make,
the
automation
simpler
will
just
be
like
there's
no
milestone
here,
but
yes,
because
milestone
generation.
That
could
be
really
super
simple.
If
you
had
in
the
midde
dinner,
did
you
have
a
link,
Matt
I,
don't
like
so
what
you
were
talking
about
earlier.
I
did.
F
F
Do
and
start
playing
with
that
into
a
pull
request
to
see
what
happens.
I
mean
already
created
one
and
it
didn't
render
it
in
a
table,
but
it
rendered
it
in
a
code
chunk
at
the
top
instead
and
I'm
gonna
go
see
whether
that's
totally
valid.
It
looks
the
same
way
it
does
now,
except
it
uses
the
formal
separation
yeah.
B
B
Like
this
may
assume
that
you're
like
doing
some
Tamil
type
of
thing
or
just
some
symbol,
every
type
of
things,
and
so
we
have
more
structure
in
ours
right
now,
but
regardless
I,
don't
think
it's
unreasonable
for
us
to
assume
that
most
folks
will
be
consuming.
That
kept
me
as
some
sort
of
automation,
slicing
and
dicing
type
of
thing,
I
we're
not
good
at
building
that
stuff,
but
we
should
be
I
mean
this
is
one
of
those
things.
That's
fascinating
between
say,
like
the
node.
B
F
We
actually
have
okay,
so
coming
from
say,
gaps.
We
actually
have
people
like
that.
The
question
is
always:
where
do
we
host
it
and
who
does
it
and
those
kinds
of
things
if
we
had
like
a
CNC
F
place,
where
we
knew
we
could
host
things
like
that,
it
would
be
a
lot
easier
to
start
building
them
totally.
B
Agree,
yeah
I
mean
yeah
I,
think
there
is
talk
of
having
a
kubernetes
cluster
for
hosting
kubernetes
projects.
You
know
and
stuff,
like
you
know,
like
dashboards
and
such
right
I,
you
know,
Jason,
don't
know
if
you're
up
on
that,
but
I
mean
this
is
part
of
this
sort
of
like
let's
try
and
break
a
bunch
of
the
infrastructure
stuff
out
of
doable
yeah
well.
A
B
B
A
B
A
Excellent
thanks
already
alright
Tim.
Thank
you
so
much
for
going
through
that
process
with
the
cap
that
is
real-world
work
getting
us
forward.
So
that
is
super
useful.
Thank
you,
okay,
so
I
Joe
you've
got
it
to
do.
Is
there
anybody
else?
That's
committing
to
work
before
the
next
full
meeting?
What
is
Mike
to
do?
Let
me
find
it
alright,
you're
gonna,
what
I'm,
with
Brian
about
yeah.
G
A
B
I
think,
right
now,
with
the
amount
of
stuff
that
we
need
to
do
and
I
think
it
would
be
useful
for
this
group
to
meet
every
week.
I
think
making
one
of
those
meetings
be
a
working
session
where
we
actually
go
through
and
do
like
what
we
did
with
Tim
would
be
super
useful.
I
know
nothing
focuses
my
attention
more
than
like,
actually
being
live
in
a
meeting
working
on
something,
otherwise
it's
so
easy
for
other
stuff.
B
D
I
think
I
would
be
totally
reasonable
to
have
a
booking
sheet
of
some
sort
and
people
who
wanted
to
come
and
talk
to
sit
architecture
could
look
on
that
sheet
and
if
there
was
nothing
on
that
sheet,
we
would
you
know
meet
anyway
and
discuss
whatever
else
we
needed
to
do.
But
I
don't
think
we
should
get
rid
of
the
opportunity
for
SIG's
to
have
a
well-defined
way
of
interfacing
with
us,
and
maybe.
B
That's
nice
to
bring
up
in
the
community,
meaning
Jase
is
that
another
like
we
want
to
be
a
meeting
point
for
first
thing
could
have
problems,
but
we're
trying
to
actually
work
through
questions
about
how
best
to
actually
sort
of
render
this
idea
into
the
uber
Nettie's
world
is
is
definitely
something
that
we're
here
for
so
maybe
we
yeah
I
like
the
idea
of
actually
having
a
fee
you'll
purpose.
If
we
don't
have
an
agenda,
then
we
assume
it's
gonna
be
a
working
session
as
we
work
through
some
of
our
okay.
F
A
What
I'm
gonna
say
and
I'm
gonna
I'm
gonna
posit
this
to
the
group
here,
is
that
if
we
do
do
working
group
type
of
thing
are
working
meeting
on
on
the
alternate
weeks.
I
would
like
to
be
a
rel,
the
iron-fisted
facilitator
for
that,
and
it's
like
if
people
start
wandering
off
in
the
weeds
or
we
start
having
bike
shedding
type
stuff,
I'm
gonna
cut
it
off
at
the
knees,
but
I
want
to
have
that
explicit
facilitation
par
from
the
group.
So,
as
somebody
who
takes
things.
F
A
B
F
A
A
I'm
already
breaking
out
the
airline
all
right,
everybody
well
with
that.
I
sincerely
appreciate
everybody
being
constructive
about
this
because,
like
Joe
said
this
can
be
contentious
and
it's
our
duty
to
try
and
serve
the
community
as
best
as
we
can
without
infighting.
So
thank
you.
Everyone
for
that
and
I
will
see
you
in
a
week.
Thank
you
guys.
Thanks
take
everybody.