►
From YouTube: Kubernetes SIG Architecture Community Meeting 20190117
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
I'm
gonna
hit
record
and
we're
recording
everybody.
This
is
Sagarika
texture
for
Thursday,
January,
17th
2019
I,
am
your
one
of
your
co-leads
Jay
singer
Dumars
and
we're
gonna
go
ahead
and
pull
up
the
agenda,
which
is
a
bit
dot;
Lee,
slash
sig
architecture
and
we'll
go
ahead
and
get
right
into
it.
And
the
first
item
belongs
to
Matt
Farina,
which
are
you
here.
Matt
I
am.
B
I'm
talking,
can
you
actually
make
me
the
co-hosts
or
the
recording,
and
everything
continues
if
you
happen
to
drop
I
will
do
that.
Thank
you,
okay.
So
the
first
thing
last
week
we
were
actually
talking
about
who
owns
what
what's
going
on
and
we
had
the
big
windows
cap
thing
a
while
ago,
where
cig
architecture
had
a
lot
of
opinions
and
right
now,
they're
looking
at
their
caps
and
the
things
that
are
going
to
go
into
them,
and
so
my
question
was
who
or
if
sig
architecture
should
have
some
approval
loop
in
that.
B
So
that
way
they
know
that
that
we
agreed
and
signed
off
to
it.
So
it
never
comes
back
to
them
and
says.
Oh
this
other
thing
happened
because
it
wasn't
known:
I
want
to
make
sure
that
either
sig
architecture
agrees.
We
don't
need
to
be
in
the
loop
on
it
or
we
have
names
to
put
on
it
to
make
sure
it's
in
the
cycle
and
everything's
tied
off
on
for
their
benefit,
and
so
that's
kind
of
where
I
was
going
with
it.
I
don't
know
I'm
guessing
Brian's,
not
on
Orion.
You
are
on
and
I.
D
You
can
you
can
put
my
name
on
that.
I
can
I
just
remind
you.
Have
notifications
are
basically
worthless.
I
have
to
do
archaeology
to
find
out
what
I
was
mentioned
on
so
I
did
I'm
stumbling
on
things.
That
I
was
mentioned
in
September
in
October
right
now,
so
please
pay
me
via
other
means,
like
slack
or
something,
and
at
least
that
way
it's
easier
for
me
to
find
them.
I
can't
generally
respond
synchronously,
but
I
will
get
to
it.
D
B
C
B
E
B
D
Well,
I'll
start
by
taking
a
look
at:
what's
there
it's
a
top
of
my
architecture
lists
which
I
was
have
been
assembling
this
week,
like
I,
said
I
was
doing
archeology.
There
are
a
number
of
API
reviews.
We
need
to
make
sure
folks
get
looked
on.
There
are
a
couple
of
conformance
things.
I
could
see.
Aaron
is
on
in
escalate
any
of
those
to
me
so
I
don't
know
if
any
are
ready.
Yet
I
saw
Clayton
also
responding
to
some
of
the
conformance
tests
PRS
but
yeah.
D
The
top
of
my
personal
list
cigar
connection
wise,
is
definitely
Windows.
I,
don't
want
them
to
get
blocked
just
because
they
didn't
get
bandwidth.
So
I
agree
with
that.
We
probably
you
know.
I
know
they're
engaged
a
ballistic
testing
and
there
was
a
PR
outstanding,
cig
Doc's,
but
we
should
probably
double
check
to
make
sure
or
to
surface
whether
there
are
other
SIG's
they
need
to
engage
with
early.
F
D
E
Yeah
so
I'll
double-check
the
reviewer
list,
but
today
I
think
sick
architecture
and
City
code
were
listed,
justify
alias
and
so
I'll
make
sure
that
you
get
on
there
as
a
specific
name
for
or
as
a
reviewer
from
city
from
cig
architecture.
You
know,
I'll
get
specific
name
from
cig
note,
it's
probably
going
to
be
you
two
or
a
DA
would
be
my
guess.
No.
G
Just
dropped
in
chat
that
was
sort
of
the
other
one
I
mean
I,
wanted
to
talk
specifics
about
your
test
plan
just
to
sanity
check
how
this
plays
out
tactically,
but
before
I
get
to
that
question
this
words
words
mean
specific
things
in
different
contexts.
Here
are
we
talking
about
approvers
or
reviewers,
because
I
feel,
like
Matt's
question,
was:
who
should
be
the
approvers
for
the
windows
cap.
B
Changes
and
sega
architecture
should
definitely
be
in
the
reviewers
loop,
but
there
is
that
approver
line
as
well.
That
is
these
are
the
people
that
we
need
sign-off
from
to
actually
make
it
so
right
there,
the
throats
to
choke
they're,
the
people
who
can
say
yes
or
no
and
last
time,
sega
architecture
made
a
very
big.
D
G
G
B
D
I,
don't
think
goalposts
move
as
far
as
I
can
tell
the
goalposts
to
people
were
not
clear
before
right,
so
I,
wouldn't
kid
I,
don't
think
it's
fair
to
characterize
it.
That
way,
like
the
release
team
raised
significant
concerns,
but
there
wasn't
clear
test
signal
and
I
think
that
was
a
reasonable
concern,
so
I,
don't
think
any
single
person
can
say
yeah.
This
will
go
forward,
no
matter
what
really
we
need
program
management
on
the
effort,
make
sure
that
everybody's
expectations
are
met
right.
F
That's
a
bit
that
things
can
happen.
I
guess
what
is
really
being
said
is
like,
let's
nominate
one
from
each
relevant
area,
that
they
are
comfortable,
delegating
the
decision
to
with
the
understanding
that
you
know
things
absolutely
can
change,
but
that
they
have
a
90%
confident
said
you
know.
Yes,.
D
I
think
it
I
think
that's
a
reasonable
approach,
Brendan
to
make
sure
that
you
know
we
talk
in
advance
to
the
really
mean
like.
If
we
were
releasing
a
feature
inside
of
Google,
we
would
talk
to
the
release
team.
We
would
talk
to
us
re.
You
know
we
would
make
sure
that
it
was
actually
ready
to
be
launched
right.
So
I
think
that
is
effectively
where
we
have
to
do
now.
They
have
been
very
engaged
with
signaled
and
suggesting
you
know.
B
G
B
Yeah
I,
in
fact
I
pasted
a
link
in
there
are
fields
for
approvers
and
reviewers
and
approvers
according
to
the
because
you
know,
we've
been
going
through
this,
so
we
really
on
this
one
should
dot
the
I's
and
cross
the
t's.
The
approvers
are
the
eventual
individuals
that
make
the
call
to
move
this
cap
to
approved,
which,
in
our
current
flow,
actually
means
implementable,
which
is
what
they
need
by
the
end
of
the
month.
There
are
currently
no
names
there
now,
and
this
is
actually
a
distinct
thing
from
the
authors.
C
C
D
Yeah
I
think
that's
that's
great.
You
know,
starting
at
the
high
level,
users
need
to
be
able
to
understand
what
the
feature
is
and
what
it
does
and
how
to
use
it,
and
that
was
one
of
the
things
we
want
to
accomplish
with
the
cap.
Is
it
usually
at
the
design?
Dock
stage
is
where
it's
described
kind
of
the
detailed
level
of
what
something
does
and
obviously
there
will
need
to
be
user
Doc's
about
how
to
use
it
as
well,
and
then
the
release
team
needs
clear
test
signal
right.
D
So
that's
why
we've
been
working
on
getting
stable,
publicly
reported
test
results
and
we
once
for
GA
the
GA
bar
specifically.
We
need
to
be
confident
that
we're
not
gonna
have
to
break
backward
compatibility
right
and
it's
not
gonna
break
their
cluster,
for
example.
So
at
the
high
level
that's
kind
of
what
the
bar
needs
to
be.
We
do
have
static
criteria
for
API
GA,
and
you
can
kind
of
take
inspiration
from
that.
It's
in
the
API
changes
documents.
I
can
dig
that
up
and
paste
it
into
the
chat.
G
So
ya
complying
saying
something
like
I:
don't
want
to
get
too
hung
up
on
the
technicality
of
words,
I'm
actually
trying
to
see
the
discussion
further,
like
I,
don't
think
we
actually
know
what
these
things
are
so
I'm
trying
to
hash
out
what
we
believe
these
set
of
people
should
be.
It
sounds
like
a
representative
from
a
sig
that
could
change
if
the
sig
decides
that
needs
somebody
else.
Instead
of
that
person,
so
we're
figuring
out
the
set
of
six
people
from
those
six
and
we'll
move
forward.
Yeah.
H
Cool
excellent,
so
so
we
will
for
the
six,
it
was
signaled
sick
dogs,
sick
architecture,
sick
release.
Those
were
the
four
six
that
really
impacted
on
Windows
and
we
need
to
get
either
approval
or
reviewer
status
from
each
of
them,
so
Craig
and
me
and
Patrick
can
work
with
both
identifying
an
individual
from
each
of
those
six.
That
will
give
the
go
no-go
decision
and
kind
of
agree
on
the
graduation
criteria
and
whether
approval
they
have
a
much
higher
say
into
the
process
versus
the
reviewer
status.
H
H
Other
things
I
want
to
talk
about
is,
if
you
have
any
questions,
rather
than
just
trying
to
hash
them
all
out
in
threads
on
github,
if
useful,
just
send
a
quick
message
and
select
either
me
or
Craig
or
Patrick,
and
you
can
set
up
a
quick
15-minute
meeting
and
you
can
talk
about
those
things
with
you
I
think
a
lot
faster
that
way
and
get
us
to
a
point
where
we
can
cover
some
form
of
agreement
on
whatever
process
or
any
of
your
concerns.
Yeah.
D
H
I
B
I
H
B
So
to
feed
back
into
the
conversation,
Tim's
asked
to
use
the
cig
Windows
mailing
list,
because
that'll
provide
traceability
and
I
also
want
to
add
real
quickly
that
one
of
the
other,
the
other
sig
that
was
suggested
here
was
cig
testing,
be
in
the
loop
as
a
reviewer
that
actually
pertains
to
the
current
one.
Although
suggesting
has
looked
at
it
and.
D
G
G
He
I
can
like
end
up
deferring
to
him,
but
I
just
want
to
like
use
an
example
of
this
or
use
this
as
an
example.
So
the
test
plan
that
Patrick
had
done
previously
I
blinked
the
PR
way
up
top.
It's
called
starting
test
plan
section
of
Windows
kept.
It
is
number
685
in
the
enhancements
repo
and
what
Patrick
had
initially
put
in
there.
I
guess
it's
still
in
there
is
the
full
list
of
each
and
every
single
test
case.
G
There
was
like
some
Google
Doc
that
we
have
tossed
around
in
this
sink
before
that
lists
out
each
and
every
individual
test
case.
That's
cool!
That's
too
much
information
for
me
as
release
team
person
and
stick
testing
I
think
we
only
care
about
the
mechanics
of
how
those
tests
are
run
more
than
we
care
about
the
list
of
individual
tests
who
on
this
list,
we
need
to
see
like
what
do.
We
need
to
spell
out
tests
to
that
level.
Dude
the
sega
architecture
need
to
review
each
and
every
test
case.
D
At
the
list
before
and
I
am
happy
to
take
a
look
at
the
list
again
once
we
have
the
automated
test
results,
posted
I
think
the
main
question
for
suggesting
was:
how
do
we
designate
windows-only
tests
by
tagging
the
tests
and
that's
the
main
thing
we
need
to
make
sure
we
have
resolved
as
far
as
the
bar
I'm
hoping
we
can
use
the
cap
to
drive.
You
know:
is
this
a
reasonable
set
of
features
for
users,
and
you
know
the
tests
would
ideally
match
the
documentation
about
what
we
say,
works
and
doesn't
work.
G
Right
so
just
like
the
mechanics
of
it
say,
testing
looked
at
the
test
plan.
Yeah
test
plan
seems
reasonable
sake.
Release
looked
at
all
of
that
and
said.
That's
way
too
much
information
for
us
to
consume
as
a
checkbox.
What
we
much
rather
have
is
just
a
dashboard
that
we
can
go
look
at
to
see
if
that
dashboard
is
all
great
yeah.
B
G
C
G
Take
to
walk
through
that
right,
potentially
we
could.
We
could
all
look
at
the
list
of
tests
that
are
in
let's
say
get
it.
You
don't
get
a
dashboard
up.
You
have
a
list
of
tests
on
that
dashboard.
We
see
what
they're
at
today
and
we
collectively
agree.
That's
the
right
list
and
then
we
go
away
a
couple
weeks
pass.
While
some
coding
happens,
we
come
back,
the
dashboard
is
green.
G
Should
we
now
see
if
that
list
of
tests
has
changed
from
what
it
initially
was
and
who
should
have
sign
off
on
that,
because
it
could
be
that
we've
kicked
some
tests
out
because
we
realized
oh,
no,
that
functionality
can't
ever
work
or
oh
we're
gonna
punt
on
that
this
release
cycle
and
that
that
seems
kind
of
tricky
to
me.
Well,.
D
G
As
the
member
of
state
testing
and
as
the
released
lead
I'm
totally
fine
with
that,
hey
okay,
that
sounds
great
I,
just
want
to
be
clear,
since
we
were
so
hung
up
on
goalposts
moving
and
the
finicky
details
of
such-and-such
just
to
walk
through
that
hypothetically.
But
trusting
us
to
do.
The
right
thing
sounds
great.
In
the
past,
see
I
signal
can
sometimes
notice
if
something
like
a
test
is
just
being
removed
to
bring
a
test
dashboard
from
red
to
green,
and
we
might
ask
like
hey.
G
J
Very
quick
comment
on
the
testing,
because
it's
that
specific
issue
as
being
a
problem
before
and
without
wanting
to
rattle
and
so
one
one
good
way
of
addressing
that-
is
to
actually
disable
tests
for
the
reason
why
they're
disabled,
because
in
the
past,
what
has
happened?
Is
you
know
if
a
test
didn't
pass
for
long
enough?
J
D
Yeah
I
mean
effectively,
we
generally
tag
tests
if
there
are
special
conditions
under
which
they
work
like
if
they're,
flaky
or
they're
slow,
or
they
don't
work
in
certain
cases,
or
they
only
work,
if
has
certain
features,
enabled
so
I
think
that's
a
good
general
practice.
Unless
the
test
is
just
totally
broken
and
nobody
seems
to
care,
hopefully
we'll
get
better
coverage
analysis
that
will
allow
us
to
determine
the
value
of
individual
tests.
So
we
can
make
more
informed
decisions
about
which
tests
to
try
to
rescue
Patrick,
yeah.
E
So,
just
to
clarify
for
planning
many
of
the
tests
we've
been
running
so
far,
our
conformance
tests
that
we've
been
trying
to
adapt
to
work
on
both
Windows
and
Linux,
and
there
have
been
cases
where
that's
not
possible
and
so
we're
not
disabling
tests
and
code.
We're
currently
disabling
them
through
an
exclusion
list,
and
so
my
expectation
is
that
you
will
see
some
test
cases
that
are
red,
fall
off
the
board
and
be
replaced
with
equivalents
that
are
tailored
to
Windows.
And
so
you
know
it's
a
really
simple
example.
E
If
you
parse
the
output
of
LS
dash
L
to
look
at
the
you
know
the
user
list.
That
is
not
going
to
work
on
Windows
and
there's.
You
know
other
cases
like
that
as
well,
but
that
was
why
I
had
started
with
the
verbose
approach
of
listing
off
test
cases.
So
that
way
that
could
be
reviewed
if
we're
not
going
to
pre
review
those
I'm
going
to
remove
those
out.
E
J
Yeah,
no,
that
makes
perfect
sense.
I
was
actually
trying
to
address
the
more
general
problem,
which
is
if
somebody
comes
along
and
says
why
the
hell
are
you
guys
not
running
this
test
that
should
be
in
instead
of
having
to
have
an
argument
about
it?
They
can
just
go
to
the
list
of
all
the
tests
and
they
can
see
why
it's
running
with
a
little
description
there
and
problem
solved,
and
if
they
disagree
with
that
pick,
and
then
you
know
raise
the
topic
as
to
the
fact
that
this
maybe
should
not
be
disabled.
A
B
I
G
I
K
I
need
to
follow
up
on
what
Patrick
mentioned
in
the
chat
two
problems.
One
is,
we
haven't
decided
how
to
mark
which
tests
will
work
on
Windows
in
addition
to
Linux,
so
that
was
one
the
other
one
is
we
do
not
skip
tests
which
are
marked
conformance,
so
we
can't
you
know
print
out,
saying:
okay,
we
are
skipping
this
only
for
Windows,
so
those
are
the
two
problems
which
we
still
don't
have
an
answer
to.
Well,.
D
I
D
D
I
D
D
Well,
yeah,
and
we
should
follow
up
on
that.
Someone
take
take
note
of
that
that
we
need
to
resolve
that
issue.
I
think
that
is
the
biggest
issue
relevant
to
cig
testing
is
how
we
want
to
identify
those.
So
it's
a
way
that's
comprehensible
to
the
release
team
or
to
people
who
ran
the
test
and
want
to
understand
why
they
ran
or
didn't
run.
D
B
Yeah
I
have
one
other
key
thing
on
it.
The
one
thing
that
we
actually
didn't
was
my
original
question.
Do
we
have
anybody
who
needs
to
be
an
approver
right
now?
I
would
suggest
the
provers
are
the
chairs
of
sig
windows,
which
would
be
the
typical
flow.
If
we
think
other
folks
need
to
be
in
the
reviewer
state
to
help
this
along,
but
no
need
to
be
there
to
approve
it
going
to
the
implementable
state,
then
we
should
probably
communicate
that
otherwise
get
a
name
and
say
you
know.
B
This
version
should
also
be
along
for
the
ride.
To
make
sure
the
eyes
are
not
you
know,
maybe
the
checklist
is
enough
complete
or
something
like
that.
Otherwise
it
would
just
end
up
following
two
sig
windows
and
we
by
default
say
that
fine
I
just
want
to
make
sure
that
we
do
dot
the
I
in
cross.
The
T
on
that
I
mean.
J
H
I
didn't
say:
approval
I,
said
approval
reviewer,
so
we'll
take
this
as
an
action
item
and
figure
out
who
can
be
an
approver
or
reviewer.
Not
all
SIG's
are
gonna,
give
us
an
approver,
and
it
doesn't
even
make
sense
for
us
to
every
sig
for
to
have
an
approver.
For
example,
sig
testing
might
be
reviewer,
seek,
release
might
be
a
reviewer,
but
signal
to
review,
or
maybe
sig
architecture
is
one
of
the
only
ones
that
will
be
an
approver
yeah
figured
out.
I.
Think.
D
You
know
in
terms
of
rationale:
some
six
have
been
effectively
on
the
project
from
the
beginning
and
they've
gone
through
this
process
many
times
right,
so
they
may
not
need
as
much
external
help
or
guidance
about
what
is
expected.
This
is
effectively
the
first
time,
I
believe
that
Windows
cig
Windows
has
gone
through
this
process,
so
I
think
you
know
it
would
be
helpful
for
them
to
make
sure
that
I
get
sign-off
from
people
who
understand
the
expectations
of
the
project
as
a
whole.
I'm
happy
to
have
my
name
on
the
approvers
list.
D
If
you
believe
that
would
be
helpful,
whether
we
call
it
approver
or
reviewer,
you
know
definitely
the
release
team
needs
to
be
comfortable,
regardless
of
whether
it's
alpha
beta
or
GA.
You
know
that
they
have
a
clear
signal
that
it's
ready
for
the
release,
so
I
would
recommend
an
approver
from
the
release
team
and
the
others.
I
would
say
at
least
review
so.
H
Sorry,
just
to
make
things
a
little
bit
simpler
right
now,
since
we're
all
here
Brian.
Would
you
like
to
be
an
approver
as
well
as
Aaron,
if
both
of
you
guys
would
like
to
be
on
approvers
from
your
two
individual
seeks?
Who
can
make
this
simple
and
then
we'll
find
reviewers
from
the
rest
of
the
six?
Yes,.
B
B
J
G
J
B
It's
in
there
approver
it
approved,
is
essentially
implementable.
Today
we
changed
the
name
and
it
was
not
consistent
throughout
the
document
in
its
language.
Essentially,
that's
what
happened
and
Windows
needs
to
get
there
by
the
end
of
the
month,
so
we
need
people
who
can
give
bandwidth
and
can
approve
it
saying
this
is
okay
to
move
to
implementable,
which
means
the
different
criteria
like
graduation
criteria,
which
is
entirely
ill-defined.
We
need
to
be
okay
with
and.
B
G
G
G
To
go
way
back
to
where
my
hand
was
raised
when
we
were
talking
about
skipping
tests
and
pending
tests
and
disabling
stuff
I,
don't
know
if
any
of
that
is
actually
documented
anywhere
like
what
our
consistent
process
is,
that
we
as
a
community
should
be
following
in
this
case
Quinton.
Would
you
like
to
take
an
action
item
to
document
what
you
proposed
so
I
feel
like
you're,
you're
you're
recalling
some
was
like
history
of
how
we
used
to
do
things
in
the
project
button
and
we
moved
pretty
fast
back
in
the
day.
G
When
you
said
like
what
we
do,
is
we
write
down?
Why
we're
disabling
a
test
I
get
really
finicky
on
the
language
of
test
versus
job
for
one
thing,
so
I
really
would
appreciate
it.
If
you
could
write
down
what
it
is
you
were
talking
about,
so
that
the
community
knows
how
to
do
that.
If
that's
the
process,
we're
gonna
use
as.
G
G
Okay,
so
we
feel
like
we're
we're
good
on
Windows,
okay,
so
the
thing
I
had
in
the
agenda
was
to
talk
a
little
bit
more
about
how
we
want
to
use
caps.
I've
been
a
bit
of
a
bull
in
a
china
shop
in
going
around
and
trying
to
suggest
that
we
should
just
use
them
now,
even
if
we
don't
necessarily
have
a
perfect
process
created
or
documented
or
automation
around.
G
All
of
that,
it's
begging
some
questions
which
I'm
happy
to
iterate
on,
but
I
don't
want
to
live
in
a
world
where
have
to
continually
get
collaboration
and
sign-off
from
a
trifecta
of
SIG's
being
sick
p.m.
sake,
release
and
sega
architecture,
because
I
kind
of
feel
like
that's
what
I
have
to
do
right
now.
G
So
what
I
would
like
to
suggest
is
that
since
cap
is
not
largely
about
process-
and
it's
largely
about
management
of
how
we
get
the
correct
information
written
down
in
a
single
place,
and
it's
all
about
the
description
of
enhancements
and
what
they
are-
and
these
are
generally
larger
things-
these
all
feel
like
things
that
product
managers
would
be
interested
in
and
that
project
and
program
managers
probably
have
more
experience
in
organizing
than
I
do.
I
think
that
figure
architecture-
you
all
have
a
lot
of
opinions
on
the
correct
information.
G
That's
supposed
to
be
in
these
things,
but
I
feel
like
we're
super
prints,
a
bike
shedding
on
process
and
I'd
rather
find
a
process
that
is
easier
for
a
bunch
of
humans
or
who
are
showing
up
and
want
to
volunteer
to
help
out
from
a
management
and
shepherding
perspective.
So
my
proposal
is
to
suggest
that,
like
say
p.m.
be
the
sig
that
owns
caps
as
a
sub
project,
and
that
stated
architecture
just
kind
of
be
actively
involved
in
reviewing
caps
and
I.
G
B
B
I
B
Okay,
so
one
of
the
things
is
to
add
to
that.
That
came
to
my
mind
here
and
it's
a
conversation
we've
been
happening.
Being
of
who
owns
the
scope
and
brian
is
starting
to
try
to
document
and
get
that
worked
out,
but
with
a
kept
process
if
it
were
under
sake,
PM
qu
burn,
sega
architecture
owns
the
scope
of
the
project,
which
is
different
from
like
any
company
where
product
management
or
yes,
that's,
project
management
or
product
management
owns
it
here.
B
Cig
architecture
owns
the
scope
of
the
project,
and
so
how
would
they
now
be
in
the
loop,
because
that
scope
section
that
talks
about
what
we're
trying
to
do
and
here's
the
use
cases
to
say
it's
in
and
out
if
sig
p.m.
boned
it?
How
would
that
then
relate
to
say
Gorka,
texture
in
the
process
and
ownership
in
that
that
that's
just
my
open
question,
Brian.
D
Yeah
I
mean
I
agree
with
Aaron,
that
I
think
cigar
kick
sure
cares
and
at
least
myself
I,
don't
necessarily
speak
for
everybody,
but
cares
about
the
content
of
the
caps,
including
the
scope
and
technical
contents
like
api's
and
designs
and
user
experience,
and
things
like
that.
So
definitely
I.
Think
cigar
cutter
should
input
and
contribute
to
you.
D
The
template
I
kept
template
in
terms
of
the
process
about
how
the
whole
project
works
and
how
it
fits
with
the
release
process
and
how
it
meshes
with
the
API
review
and
things
like
that
I
think
getting
some
project
management
program
management.
Folks
involved
in
that
is
a
great
idea
like
if
you
look
at
the
challenges
that
Windows
had
I,
think
a
big
part
of
it
has
been
the
lack
of
program
management
across
the
entire
project.
So
and
the
proposal
makes
sense
to
me
it
assuming
that
sig
p.m.
D
is
actually
interested
and
engaged,
and
that's
not
going
to
stop
me
from
continuing
to
try
to
make
sure
that
the
template
captures
what
it
needs
to
capture.
For
example,
the
graduation
criteria
section
that
currently
exists
is
kind
of
MIS,
titled
or
or
all
the
content
is
wrong
at
one
of
those
two
things,
but
you
know
so.
I
would
like
to
make
sure
that
that
gets
fixed
so
that
there
isn't
confusion
in
the
future
about
that
so
yeah
and
it
sort
of
has
a
bit
ambiguous
about
who
owns
the
cut
process.
D
D
F
I
I
I
did
a
bunch
of
work
to
reduce
the
number
of
cooks
and
kitchen
here
to
only
to
find
that
I've
not
funded
to
work
on
this,
and
so
now
we
are
here
and
I
would
love
to
work
on
that
original
problem
of
getting
this
stuff
implemented
and
useful
to
the
various
stakeholders
in
the
project
and
I.
Would
love
I
guess
for
ideas
that
that
address
that
problem
so.
B
So
Caleb
just
a
broaden
the
question
here
for
you
for
a
moment,
because
you've
been
so
intimately
involved
in
this
big
talking
to
people
and
you're
involved
in
sig
p.m.
sig
release
and
you're,
obviously
here
and
involved.
Where
would
it
be
that
would
help
get
the
people
and
engagement
to
get
it
more
involved?
Worse,
where's,
the
best
cuz
I,
don't
go
to
sig
p.m.
I.
Don't
go
to
sig
release.
I,
don't
have
the
time
for
those.
Where
is
the
best
place
within
the
our
organization
that
you
think
would
help
move
it
along
and
why
so.
I
I
guess
it
relates
to
the
in
terms
of
sig
release
in
involvement.
My
Italy
says
this:
you
know
code
I,
gotta
fight.
It
would
be
around
the
enhancements
tracking
process.
The
goal
there
would
be
to
make
that
a
forward-looking
process
that
allows
a
more
or
less
a
tracking
requests
versus
a
tracking
issue
to
be
created
more
or
less
auto
whoa
with
automatically
from
the
tech
positive
cell,
so
that
the
text
is
a
pointer
and
everything
else.
I
Well,
everything
up
with
a
pointer
to
the
text
itself
rather
than
Reckling
the
information,
a
bunch
of
different
places,
I
have
been
so
I
have
been
working
with,
or
I've
tried
to
work
with
a
few
people
who
have
stepped
up
or
have
raised
their
hands
to
pick
up
work
in
that
specific
domain
in
terms
of
enhancements
tracking
I
wrote
what
I
hope
would
be
enough
code
to
actually
make
that
possible.
I
am
still
waiting
for
that
PR
to
connect
those
two.
B
I
Week,
which
I
have
been
I
guess
increasing
my
deadline
request
to
see
forward
progress
based
on
the
work
that
I
have
foundation,
I
Drive
away.
Then,
if
that
doesn't
happen,
then
I
you
know,
will
be
forced
to
finish
that
bit
myself.
Oh,
so,
like
I
have
people
who
have
been
interested.
It
is
not.
It
is
turning
that
interest
into
into
code,
so
we
can
actually
have
you
can
iterate
and
have
these
conversations
rather
than
hand
waving
doing
next,
really,
you
know
propose.
B
I
G
G
So
so
Caleb
myself
and
Steven
Augustus
have
probably
been
the
three
folks
most
actively
involved
in
trying
to
push
this
ball
forward,
and
each
of
us
has
tremendous
experience
in
release
and
p.m.
and
Caleb
and
I
show
up
here
at
sega
architecture.
Quite
a
bit.
So
I
feel
like
we
have
the
right
minds.
I
just
want
to
kind
of
make
the
forum
for
a
lot
of
discussion
and
issues
and
such
going
forward
to
be
one
place.
G
Rather
than
repeating
the
same
discussion
three
times
in
three
different
places,
but
it's
it's
nominally
the
same
people
in
all
of
the
places.
It's
just
about
trying
to
make
sure
the
right
stakeholders
are
involved,
so
I
showed
up
at
say
p.m.
and
they
were
largely
okay.
With
this
I
had
there
were
a
number
of
new
people
who
showed
up
to
say
p.m.
who
are
eager
to
help
out.
G
So
my
suggestion
was
to
to
propose
that,
like
we
try
and
continue
the
process
of
saying
that
design
proposals
are
nominally
going
to
turn
into
keps,
and
we
should.
We
should
start
to
like
fold
that
down
there's
a
lot
of
branching
of
of
effort
that
has
to
happen
there,
but
I
do
feel
like
that's
an
effort,
that's
easily
charted
out
and
then,
with
a
little
bit
of
time
that
we
have
left
of
Brian's
point.
G
That
may
be
the
right
content
isn't
in
the
cap
template
now,
and
we
do
have
it
on
our
on
our
plate
to
kind
of
figure
out
what
graduation
criteria
are.
You
know
Phil
what
ROC
put
together
a
PR
for
what
do
we
want
to
update
the
cap
template
to
look
like
so
that,
even
if
we
don't
necessarily
have
the
automation
to
help
us
support
this,
we
could
start
to
tell
P
like
when
your
PRA
all
of
the
data
we
want
to
see
in
one
file.
G
I
G
H
I
Logic
into
that
was
obviously
help
speed.
The
overall
delivery
of
the
be
of
the
tooling
itself,
so
modifying
the
template
is
great,
but
also
connecting
that
into
the
process,
be
ongoing
development
process.
They're
also
very
helpful
and
I
can
comment
on
that
PR
as
a
pointer
to
do
that
as
well,
because
diverging
these
things,
you
know,
obviously
generates
more
work
for
someone,
and
it
seems
likely
to
be
me
so
obviously,
as
me,
I
am
opposed
to
that.
The.
G
Generally
speaking,
if
I
can't
get
my
own
employer
to
do
something
the
next
place.
I
look:
is
this
awesome
community
with
a
bunch
of
people
volunteering
to
help?
If
I
look
at
the
fact
that
we
had
a
hundred
and
something
people
respond
to
the
release?
Shadows
survey:
there's
not
that
room
for
that
many
people
on
the
release
team,
but
that
sure
sounds
like
a
lot
of
people.
We
could
put
to
work
on
doing
whatever
painful
manual
cranking
of
gears
that
we
have
to
to
move
this
forward.
D
Yeah
in
terms
of
a
strategy
of
moving
it
forward,
as
far
as
I
can
tell,
there
are
two
main
issues:
one
is
reducing
the
friction
compared
to
the
existing
legacy
design
proposal
process.
So
there
are
a
couple
of
things
that
people
have
tripped
up
on
numbering
being
one
of
them,
and
you
know
the
other
one
is
confusing
parts
of
the
template.
D
Like
the
graduation
criteria
section,
we
just
eliminated
those
problems
and
it
seems
like
it
would
be
no
worse
than
the
existing
design
proposal
process,
which
has
no
template
and
no
documented
process
or
procedure
and
so
on.
And
then
the
second
thing
is
just
communicating
it
to
people
that
it's
where
we
want
them
to
do,
and
they
can
carve
a
call
the
kept
process,
even
if
they
don't
fully
understand
it,
because
that's
what
they
were
doing
with
the
existing
proposal
process
and
then
we
would
at
least
be
pivoting
to
something
closer
to
what
we
want.
Yeah.
I
I
I
G
G
Happy
to
help
with
that
I've
been
busy
going
around
to
all
the
states
with
my
enhancements
lead,
but
my
goal
was
to
start
focusing
on
what
code
we
have
to
see
how
that
can
help.
What
we
have
I
pasted.
A
link
to
the
PR
in
the
chat.
I
can
send
this
PR
to
the
state
architecture
mailing
list
if
it
would
help
Caleb
you've
been
put
on
the
PR
as
a
requested.
Reviewer
you've
also
been
assigned
it
I
think
as
a
as
an
approver
for
this
and
I
would
really
like
the
rest
of
Sega
architecture.
G
Take
a
look
at
this,
because
this
is
about
filling
out
the
cap
to
maybe
turn
the
graduation
criteria
into
a
checklist
and
talk
about
upgrade
downgrade
strategy.
You
know
version
skew
strategy,
things
of
that
nature
I
feel
like
these
are
a
number
of
the
things
that
Ryan
was
talking
about.
I'm,
not
looking
for
a
full,
complete
enumeration,
but
I
want
to
give
enough
guidance
for
people
to
to
start
cargo,
cultic
and
I.
G
G
I
L
Working
on
my
question
is:
I
have
a
bunch
of
files
that
I
think
that
files
belongs
to
the
C
architecture.
I
just
want
to
know
how
can
I
find
someone
that
I
can
be
with
to
review
and
update
those
files,
and
or
do
you
think
you
said
it
is
a
good
idea
to
just
find
an
issue
and
go
that
way.
What
do
you
think.