►
From YouTube: SIG Architecture 20180118
Description
A
Good
morning
afternoon,
etc
welcome
to
cig
architecture
for
Thursday
January,
18th
2018.
This
is
our
regular
schedule
meeting
as
opposed
to
the
office
hours
version
and
the
agenda
and
notes
will
be
available
after
this
meeting
at
HTTP
colon,
slash,
slash
bit
dot,
Lee,
slash,
cig
architecture
and
I
am
your
co-host
along
with
Brian
grant,
and
we
are
going
to
go
into
the
agenda
and
knock
some
stuff
out
today.
So
first
thing
on
the
agenda
was
just
a
quick
review
on
action
items.
I
don't
want
to
go
through
these
unless
somebody
has
something
to
add.
A
B
There
hasn't
been
a
huge
amount
of
progress,
I
reviewed
all
those
talks
yesterday
and
today
this
morning,
I
think
where
we
were
following
up
on
some
of
the
legal
issues
with
the
new
repo
process.
For
example,
we
had
discussed
stripping
that
dock
down
to
just
goals
and
the
overall
idea
that
we
would
have
these
three
flavors
of
repos,
and
since
that
discussion
there
have
been
zero
changes
to
the
dock.
So.
B
B
C
B
The
PR
that
changes
some
of
the
kept
language
is
still
open.
It's
not
clear,
I
mean
again
after
our
discussion
last
time.
There
was
there
were
no
updates
to
it.
So
it's
kind
of
it's
stalled.
I'm,
pretty
sure
we
had
discussed
some
a
number
of
concrete
things
like
changing
some
of
the
names
of
the
kept
states
and
things
like
that.
None
of
those
comments
were
propagated
to
the
PR
and
no
changes
they're
actually
in
there,
Brian
really
yeah.
B
B
B
B
B
D
So
yeah,
so
so
I
did
push
that
stuff.
That
turns
out
I'd
love
for
you
to
take
another
look
Ryan
and
let
me
know
what
you
think
is
missing.
Specifically,
with
these
sort
of
states,
we
moved
to
accepted
implementable,
implemented,
deferred,
rejected
withdrawn
and
replaced
as
the
states
right.
So
there
is
no
approved
States.
It's
like
either
accepted,
which
means
that
the
the
sig
has
said.
Yes,
this
is
something
that's
worth
working
on,
implementable.
It's
like
okay,
we
feel
like
there's
an
update
here
that
people
can
get
started
implemented
is
okay,
it's
pretty
much
done.
D
D
Know
cuz
I
when
I
first
looked
at
it,
I
thought
I
forgot
to
push
also,
so
it
should
be
so
take
a
look.
Let
me
know
what
you
think:
I
think
it's
all
approved.
I
listed
you
since
this
is
a
cap
and
we
should
try
and
use
the
cap
process
for
the
cab.
I.
Think
I
listed
you
as
a
as
an
approver
for
this,
so
I
would
really
love
to
get
your
LG
TM
on
it
and
then
like.
D
D
F
E
D
E
B
Yes,
okay,
so
I
started
to
just
edit
the
backlog
here
a
little
bit,
so
we
are
continuing
to
work
on
the
kept
iterating
on
the
kept
process
and
discuss
how
to
roll
it
out.
The
new
repo
process
is
also
under
discussion.
It's
evolved
a
little
bit,
I
think
in
a
positive
direction.
Initially
we
said
that
the
sega
architecture
would
be
approving
new
repos.
B
We
still
need
to
develop
that
process
for
any
repos
that
are
going
to
get
into
core
and
the
new
stratification
of
different
categories
of
repos
there,
the
Associated
repos,
the
sinc
repos,
where
six
can
decide
and
the
core
so-called
core
repos,
which
would
be
those
in
the
kubernetes
org,
where
it'd
still
be
up
to
Sagarika
textures.
So
yeah,
that's
in
scoped
for
kubernetes
or
not
so
as
part.
G
B
So
it's
not
the
ones
that
are
currently
in
the
org,
so
I
guess
there's
a
couple
of
caveats.
One
is
that
it's
not
the
ones
necessarily
that
are
currently
in
the
org
another
is
we're
still
fitting,
actually
figuring
out
what
the
optimal
github
mechanics
are
for
the
current
functionality.
It
may
be
that
we
need
to
use
topics
or
something
else
instead
to
distinguish
the
different
flavors,
but
one
possible
implementation
of
the
proposal
would
be.
We
just
have
one
one
org.
B
Instead
of
incubator,
we
have
one
org
for
all
the
sig
related
repos
and
we
tag
them
with
which
sig
owns
them
and
then
a
separate
org,
the
kubernetes
org
for
the
things
that
are
considered
core
for
whatever
for
whatever
that
means.
That's
one
possible
implementation.
I,
don't
know
that
it
will
be
done
implementation,
but
the
basic
idea
is:
we
want
to
categorize
the
repo
and
we'll
have
the
most
stringent
requirements
in
terms
of
consistency
and
governance
and
oversight
and
whatnot
on
the
core
repos
we're
still
also
trying
to
define
what
that
should
really
mean.
B
Is
it
just
things
that
go
into
the
release?
Bundle
that
the
project,
ships
or
is
it
more
inclusive,
so
a
bunch
of
those
things
need
to
be
figured
out.
But
the
basic
idea
is,
you
know,
if
say,
architecture
owns
kind
of
the
definition
of
what
kubernetes
entails.
Then
it
would
make
the
decision
yeah,
that's
that's
included,
but
we
don't
want
to
stop
SIG's
from
building
the
things
they
need
or
from
innovating.
So
this
new
proposal
would
explicitly
delegate
those
that
decision
level
making
to
the
six.
B
B
A
Can
I
go
back
to
the
repo
think
for
one
minute,
because
there's
a
sort
of
urgent
matter?
That's
gonna,
come
up
soon.
That's
gonna
block
a
lot
of
work,
which
is
the
cloud
provider
working
group
has
decided
to
have
repose
in
the
kubernetes
org
per
the
entry
cloud
providers.
So
essentially
entry
cloud
providers
would
be
moved
up
to
their
own
repos
under
the
communities
org.
So
it
falls
under
neither
a
cig
nor
under
us.
A
B
H
This
is
Tim
I'm
off
camera,
there's
a
there's,
a
medium-term
plan
to
get
the
cloud
providers
to
just
ingest
those
themselves
and
not
keep
them
in
the
communities
org
anymore,
but
we
need
to
work
through
the
copyright,
whatever
hurdles
assignment
and
I
cut
right,
but
all
the
licensing
stuff
right.
So
we
just
haven't
tackled
that.
Yet
we
just
said
it's
much
easier
to
just
get
things
out
as
step
one.
It's
clearly
obvious
that
there's
a
hard
boundary
then-
and
we
deal
with
the
next
bridge
when
we
get
there.
Okay,.
B
I
actually
do
related
issues
that
have
come
up
in
the
new
repo
process.
I
did
some
investigation
on
booting
things
out.
It's
actually
reasonably
straightforward
effectively.
It
becomes
like
a
fork.
Even
if
we
just
transfer
the
whole
repo
to
them,
they
would
leave
the
existing
copyright,
notices,
boilerplate
and
whatever
and
plaster
a
new
one
above
it
and
put
their
own
CLA
or
TCO
or
whatever
in
place
the
existing
license
and
things
would
would
just
remain
so
it'd
be
it's
kind
of
similar
to
been
during
its.
That
seems
obvious.
H
B
Right
so
documentation
I
had
there
are
a
number
of
discussions
leading
up
to
keep
Kahn
and
probably
even
earlier,
about
updating
definition
of
what
committees
is
on
the
website.
So
that's
kind
of
on
the
table.
I
would
like
to
get
back
to
the
architecture
diagrams
at
some
point
that
I
created
a
doc
with
a
backlog
of
design
decisions
that
have
been
made,
but
not
documented,
so
I'm,
adding
a
link
to
that
in
the
official
backlog
here
of
things
to
do
the
along
those
lines.
B
Right
now
for
people
who
aren't
aware
there
is
a
discussion
right
now
about
whether
the
deena
set
controller
should
continue
to
be
a
scheduler,
so
that
discussion
started
in
cig
scheduling.
I
actually
can't
see
the
chat
with
with
this.
With
this
thing
up,
but
anyway,
I've
shown
most
of
the
backlog
years,
so
I'm
gonna
stop
sharing
for
a
sec.
So
people
who
are
interested
in
that
discussion,
you
know,
take
take
a
look.
It's
affects.
B
But
it's
clear
there
as
just
one
example
of
why
we
need
to
document
the
how
the
design
of
the
system
is
intended
to
work,
including
the
division
of
responsibilities
among
the
components
and
things
like
that,
because
it's
easy
for
these
properties
to
erode
over
time.
If
they're
not
documented
and
not
tested.
C
Well,
I,
don't
think
the
properties
of
this
have
been
there's
a
conflation
because
there's
a
specific
set
of
problems
that
kind
of
caused
this
to
occur
when
we
start
evaluating
priority
and
preemption,
that's
when
diamond
set
starts
to
break
down
a
little
bit
in
its
current
form
and
where
the
boundary
lines
of
who
does
what
become
fuzzy
right.
So
it's
not
clean
or
clear.
That's
the
reason
why
we're
having
this
problem.
B
Yeah,
it's
not
just
diamond
set,
it's
a
knee
replacement,
scheduler
or
additional
scheduler
and
having
diamond
set
in
the
system
as
a
second
scheduler
just
exposed
those
issues
earlier
than
they
otherwise
would
have
been,
which
I
think
is
one
of
the
main
values
of
keen.
Is
this
isn't
as
a
scheduler
honestly?
H
Someone
came
up
yesterday
with
an
idea
I
fried
even
the
details
of
it
was
for
something
that
seemed
reasonable,
that
we
should
do
it,
but
they
didn't
want
to
write
a
kept
because
they
weren't
actually
committing
to
do
the
work
they
just
want
to
put
it
somewhere
so
that
we
consider
it
and
solicit
community
involvement
is
issues
still
the
right
place
for
that
is.
Is
proposals
the
right
place
for
that
I
sort
of
hate
proposals
that
are
opened
and
approved,
but
nobody's
working
on
I'm
just
curious.
E
One
of
the
things
that
I
like
about
the
rest,
RFC
process
is
that
you
don't
have
you,
don't
necessarily
have
to
be
the
implementer
of
an
RFC.
You
can
work
on
outlining
the
problem
that
you're
trying
to
solve
and
then
just
checked
in
to
source
control.
Once
there
is
agreement
that
it's
a
reasonable
thing
to
work
on,
so
you
don't
have
to
you
know,
lose
it
or
anything.
H
B
No
good
way
to
find
those
things,
even
if
we
would
like
to
have
it
done,
there's
always
competing
priorities
and
things
like
that
to
get
them
to
have
enough
review
bandwidth
or
you
know
often
refactoring
is
required
which
may
interfere
with
other
work.
That's
ongoing,
so
I
think
if
it's
significant
enough
to
require
a
proposal,
and
but
it's
not
high
enough
priority
for
someone
committed
to
do
it
to
actually
do
it,
then
it's
not
clear
how
valuable
it
is.
Maybe
an
issue
is
final,
though
we're
gonna
get
pinged
by
the
bot.
B
H
I
mean
I'm
personally
I'm
a
big
fan
of
using
issues
as
backlog
and
some
of
these
idea,
like
I'm
the
details.
Now
it
was
substantial
but
not
enormous.
I
have
a
terrible
memory.
I
will
forget
about
it
if
it's
not
somewhere
in
issue,
I
know
that
we
have
a
problem
with
creeping
issues.
Well,
we
have
a
problem
with
still
having
five.
B
B
B
H
D
Know
so
I
mean
I
I
mean
they
can't
process
is
a
baby
process,
so
I
really
hate
to
sort
of
overload
it
with
more
stuff.
Before
we
really
have
have
a
feel
on
it,
I
I
think
it's
compatible.
I
mean
like
I,
definitely
see
that
there's
a
duality
here
between
issues
and
documents
on
this,
especially
just
because
this
is
kind
of
a
sort
of
create
one
thing
and
throw
it
off
and
make
sure
it
doesn't
get
lost
type
of
thing
and.
H
D
H
G
G
Them
so
when
you
create
a
new
repo,
though
on
the
kubernetes
org
I,
think
you
automatically
get
all
the
labels
right,
because
we
make
them
consistent
across
everything
and
remain
a
bot
still.
Does
it
so
you're
still
gonna
have
all
of
those
labels
on
this
new
org
and
fada
bots
still
gonna
come
through
and
closed
off
that
stale,
but.
B
G
B
H
Like
if
we
are
going
to
tell
people,
this
is
not
where
these
issues
go
over
them
there.
We
need
to
do
it
consistently,
because
we
have
a
huge
mishmash
of
things.
We
already
have
several
repos
for
trucking
issues
in
that
we
aren't
doing
a
good
job
of
redirects
using
kubernetes
communities.
Is
the
central
repo
I
have
a
feeling
that
over
time
there
will
be
less
and
less
actual
meaningful
code
in
there
and
looking
more
and
more
it
becomes
the
meta
repo
but
I'm.
H
D
So
one
thing
that
we
can
do-
and
you
know
as
we
start-
and
this
is
something
I'm
working
with
the
contributes
folks
around-
is,
as
we
start
getting
more
of
a
community
portal
where
we
can
actually
like
we
could
have
links
to
sort
of
standard,
github
queries
for
these
types
of
things,
sort
of
like.
Oh,
you
want
to
see
all
the
ideas.
Here's
how
you
go.
You
want
to
see
all
the
stuff
in
this
milestone.
D
Here's
where
you
go
right,
I
think
some
of
it
is
that
we
don't
have
standard
queries
that
people
use
against
labels,
so
everybody
makes
their
own.
And
so
then
it's
like
well
there's
this
mishmash,
but
if
we
have
like
here's,
the
five
queries
that
start
slicing
and
dicing
stuff
that
might
help
steer
people
in
the
right
direction,
but.
B
E
Currently,
only
three
Kylie
balls
that
are
supposed
to
be
propagated
across
all
repos
I
think
it's
bug
news
kind,
its
bug,
docks
and
feature.
We
if
we
greatly
reduce
the
number
of
concrete
posts
that
are
used
uniformly
across
all
repos
I,
don't
think
it
would
be
that
confusing
and
it
would
help
a
lot
with
dev
stats
for
some
other.
Some
of
the
dashboards
already
like
fragment
based
on
the
current
levels,
feature
is
not.
B
D
So
Aaron
so
so
I
mean
here's.
This
is
kind
of
a
tooling
consistency
question
but
like
let's
say
that
we
have
those
three
types
of
kinds
you
know
different
repos
are
gonna
want
to
have
their
own
sort
of
labels,
but
we
also
want
to
have
standardized
tools
for
querying
and
and
finding
this
stuff,
that's
fine.
This
is
why
I
was
trying
to
be
really
diligent.
E
It
just
makes
interacting
with
the
github
API,
pretty
painful,
so
like
tied.
For
example,
we've
we've
tried
to
standardize
on
having
it
do
not
merge,
slash
prefix
for
any
label
that
describes
why
you
might
not
want
a
merger
PR,
but
when
it
comes
to
asking
github,
we
still
have
to
individually
list
out
every
single
to
not
merge
label
that
we
are
aware
of
I
mean.
H
E
D
Guess
what
I'm
trying
to
say
Aaron
is
that
if
we
build
a
standard
dash
that
says
ok,
let's
look
at
the
trend
of
numbers
of
issues
in
this
particular
repo
based
on
kind
right.
Do
we
want
to
actually
like
under
like
say,
like
you
know,
there's
only
three
different
kinds
and
then
there's
subcategories
under
that
it
may
be
easier
to
build
dashboards
and
toolings
if
we
do
get
more
restrictive
about
the
label.
That's
that
steps.
That's
Joe,
I
know,
I,
know
that
stem
stands
but
like
like.
G
G
H
H
B
A
C
B
Well,
yeah
just
I'll
bring
I'll
just
bring
it
share
it
again,
because
what
I
showed
was
the
version.
I
was
editing
for
this
share
button.
F
B
B
Take
a
look
at
so
just
coming
back
to
the
kept
process.
1.10
is
underway
already
I
assume
people
are
already
starting
to
file
features,
issues,
not
sure
which
ones
have
outstanding
proposals,
or
we
think
SHINee
proposals
can
I
get
a
volunteer
for
someone
to
go.
Look
at
that,
so
we
can
try
to
I
think
we
said
we
were
going
to
try
to
apply
the
kept
process
to
another
couple
of
things.
A
Yeah
I
hate
to
even
volunteer
for
this,
but
I
will
cuz
I
got
it.
I
gotta
go
through
that
stuff
anyway,
for
the
110
release,
cuz
I'm
I'm,
leading
it
so
I.
D
B
Well,
it's
a
little
bit
blurry,
because
I
wear
multiple
hats
I
actually
think
that
horrible
more!
Is
this
during
anything,
a
combination
of
steering
committee
and
contributor
experience,
maybe
on
the
two
inside
the
sub
projects
and
owners
proposal,
is
the
first
step.
Then
I.
Do
you
plan
to
go
through
and
enumerate
the
sub
projects
that
I
think
exists,
get
some
feedback
from
the
SIG's
on
whether
they
agree
or
not,
but
that
that
proposal
is
my
kind
of
big
step
in
that
direction.
Ya
know.
D
B
But
one
thing
we
had
talked
about
is
having
the
more
explicit
technical
escalation
process
where
you
know,
if
SIG's,
if
there
are
issues
that
affect
multiple
SIG's
or
something
like
that,
and
they
can't
come
to
an
agreement,
they
could
request
a
decision.
So
so
I
think
we
said.
Sig
architecture
is
the
most
appropriate
place
for
those
kind
of
technical
decisions
with
project
wide
impact,
or
at
least
multi
e-cig
impact.
D
Think
the
prerequisite
there
and
I
think
this
is
on
the
backlog.
It's
yeah,
it's
sort
of
small
I,
think
the
decision
process
because,
right
now,
it's
like
you
know
if
somebody
escalates
to
save
architecture
and
there's
an
assumption
that
they
want
some
sort
of
final
decision.
It's
already
contentious
at
that
point,
having
some
clear
predefined
sort
of
like
how
decisions
get
made
in
this
segment
of
like
hey,
it
seems
like
the
mobs
against
you.
Type
of
thing
would
be,
would
be
good
yep.
B
D
Think
part
of
any
process,
when
you
have
a
group
of
people
making
a
decision
you
have
to
route
it
also
like
who's.
That
group
decided
right
how
you
know,
how
do
you
actually
sort
of
maintain
that
membership
and
I
think
a
lot
of
places
there's
like
here's,
the
set
of
folks
making
decisions,
but
there
isn't
that
clarity
about?
Why
are
those
the
folks,
or
at
least
how
does
that
some
group
of
folks,
you
know,
evolve
over
time,
I
think
it's
missing
piecing
the
API
review
process,
at
least
which.
E
B
D
D
Here.
This
is
not
final,
but
it's
gonna
be
like
you
know
they
have
to
have
a
decision-making
process
for
choosing.
You
know
the
the
folks
that
have
power
they.
They
have
to
document
that
and
it
has
to
be
a
fair
and
equitable
right.
Now,
that's
gonna,
there's
so
there's
gonna
be
a
set
of
requirements
for
a
sig.
Now
for
a
lot
of
SIG's,
it's
gonna
be
like
what
we
have
to
invent
this
process
out
of
whole
cloth,
so
I
think,
along
with
that
is
going
to
be
like
here's.
D
Some
sort
of
you
know
reasonable
starting
place
for
for
the
sig
to
take,
and
then
they
can
modify
that
and
make
it
work
for
them,
as
it
makes
sense
right.
So
it's
going
to
be
sort
of
a
set
of
requirements
along
with
you
know
some
template
Docs
that
you
can
take
if
you
don't
otherwise
have
opinions
or,
if
you're,
just
looking
for
a
place
to
start,
but.
G
G
G
D
Standards
for
all
SIG's
right,
along
with
maybe
a
starting
point,
there's
the
decision
for
this
sig
about
like
how
does
this
sig
do
they
want
to
you
know,
do
we
want
to
adopt
that
as
of
not
yet
written
sort
of
templates,
or
do
we
want
to
come
up
with
our
own
process?
What
is
the
appropriate
thing
for
this
sake,
right,
which
is,
which
is
a
separable
thing
that.
D
B
G
I
noticed
earlier,
we
were
talking
about
sub
projects
and
SIG's
what
we
were
talking,
one
of
the
things
that
occurred
and
repos.
One
of
the
things
that
occurred
to
me
was
as
kind
of
the
guidance
and
ideation
is
happening
around
this.
Is
anybody
engaging
with
the
people
who
currently
own
the
sub
projects
and
the
sub
repos
to
collaborate
with
them
based
on
their
experiences
so
that
they
have
input
into
the
process
that
they're
going
to
be
part
of
and
live
under
and
work
with?
Is
there
any
of
that
happening
right
now,
so.
B
G
And
part
of
this
is,
you
know,
there's
a
difference
between
collaborating
to
come
over
the
solution
and
even
having
a
straw
man
to
start
that
collaboration
and
creating
something
and
handing
it
down.
And
so
my
concern
is
there's
certain
elements
you
don't
want
to
have
things
handed
down
to
them,
but
want
to
be
engaged
in
the
collaboration
that
creates
something
and
so
I'm
just
looking
to
make
sure
and
asking.
How
are
we
embracing
that
collaboration
and
bringing
people,
and
you
do
this
stuff
so
that
they
can
be
involved
and
actually
share
their
experiences
so
I'm.
E
Sort
of
seeing
like
a
two
pronged
approach
here,
where
I'm
trying
to
work
on
technically
implementing
it
in
a
machine-readable
format
and
making
sure
that
this
information
is
appropriately
communicated
in
all
of
the
SIG's
reach
to
rebase
in
the
community,
repo
and
I.
Think
Brian
is
attempting
to
iterate
on
what
that
content
actually
is.
E
So
what
are
the
sub
projects,
and
so
I
think
we
can
have
collaboration
and
pull
request
format
over
whether
or
not
the
implementation
is
sound,
and
we
can
also
have
collaboration
and
whatever
format
is
most
appropriate
over
the
content
of
what
are
the
appropriate
sub
projects,
and
you
can
do
they
belong
to
you.
Does
that
sound
fair.
E
E
So
that's
that's
sort
of
a
separate
effort
for
this
I
would
view
that
more
as
something
that's
in
line
with
Brendan's
proposal
about
sort
of
creating
three
different
tiers
or
classes
or
three
posts,
and
saying
that,
depending
on
which
of
those
you
fall
under
there's
a
different
set
of
sort
of
process
and
automation.
Guidelines
that
you
are
expected
to
follow
being
most
stringent
and
common
in
core
and
then
sort
of
laxing.
E
That
up
as
we
go
to
different
things,
so
I'm
sort
of
trying
to
just
pilot
how
one
might
go
about
setting
that
up
for
a
brand
new
organization
and
a
brand
new
repo
and
document
it
as
I
go
and
then
I
think
we
can
sort
of
iterate
on
what
are
the
guidelines
that
make
the
most
sense
for
core
repos.
And
how
can
we
lacks
those
blowing
out
words?
Yeah.
G
And
what
I'm
actually
asking
is
when
we
do
this,
how
are
the
people
who
actually
owned
the
repos
today
manage
the
sub
projects
today?
How
are
they
engaged
in
the
collaboration
to
create
that
is
the
steering
committees?
Gonna
come
up
with
a
proposal,
they're
gonna
iterate
on
it
hit
up
a
few
people,
get
feedback
and
then
hand
it
down
or
the
people
who
own
sub
projects
and
manage
the
repos
today
involved
in
the
collaboration
for
giving
feedback
and
discussing
it
along
the
way.
G
So
they
have
input
on
their
experience
and
what
they
think
and
how
it
will
affect
their
process
as
it's
being
created.
No
one
is
some
people
go
off
and
create
something
and
then
hand
it
to
others.
The
other
is
a
collaboration
that
involves
the
co
the
affected
people
during
the
process,
I'm
kind
of
curious.
G
What's
the
process
on
this,
because
it's
been
brought
up
that
some
of
this
is
happening
and
I'm
curious,
how
people,
who
own
mini
cube
and
dashboard
and
helm,
and
all
of
these
other
things
the
people
who
own
and
work
on
them
day
in
and
day
out,
are
part
of
the
effort.
That's
going
to
define
how
things
move
forward
and
what's
gonna,
be
required
of
them,
so
I
feel
like
it
would
be
incorrect.
C
In
collaborating
in
this
process,
so
I
want
to
interject
and
you
know
so
we
can
move
on
because
Brian
want
to
get
other
topics.
We
talked
about
this
during
their
steering
committee
meeting
and
there
was
a
general
consensus
that
we
need
to
define
a
phased
rolling
policy
where
we
get
feedback
and
iterate
on
any
policies
that
we
steering
committee
decides
or
that
even
get
implemented
within
the
larger
structure.
Right
because
it
needs
to
be
an
iterative
process,
worried
it's
done
by
one
that
it's
done
by
two.
C
Then
it's
done
by
four
something
of
that
nature,
where
there's
a
strategy
for
how
we
deploy
and
implement
these
processes,
so
is
part
of
the
conversation.
I
highly
recommend
that
you
watch
the
video
that
should
have
been
posted
to
YouTube,
because
I
know
other
folks
did,
and
if
you
have
a
discussion,
we
can
have
it
on
the
steering
committee
list
and
right
now.
That's
a
policy
question
and
I
think
I
kind
of
want
to
move
on
to
the
other
topics.
For
today,
all
right,
yeah.
B
I
see
Jace
lgt
and
my
backlog
update,
so
that
just
got
merged,
and
we
will
continue
to
follow
up
on
those
things
now
that
cleans
here,
if
you
still
here,
will
follow
up
on
the
API
review
process
that
is
I
think
is
one
of
the
top
priorities
so
that
we
can
get
those
review
meetings
going
and
have
some
kind
of
addendum
to
the
kept
process,
that's
more
specific
to
API
changes.
So
what
are
the
next
steps
you
plan
to
take
on
that
claim?
B
E
Is
a
list
of
recommended
changes
that
need
be
made?
Most
of
them
involve
either
capturing
existing
status
and
so
I
think
the
most
productive
thing
is
to
open
a
small
set
of
PRS
that
can
engender
discussion
and
give
a
period
of
time
for
people
to
react
to
that
it
would
be
I.
Think
I've
captured
all
feedback
that
I've
heard
from
various
folks
about
API
review
in
general,
including
Joe's
comments
and
the
discussion
about
having
a
technical
meeting.
E
E
B
E
D
So
I
am,
I
opened
a
PRI.
I
put
this
in
the
in
the
chat,
but
I
just
wanted
to
do
announce
I
opened
a
PR
to
move
the
the
kept
process
from
accepted
to
implementable,
which
emerged
already
what
temp,
which
merged
already
no
no,
it
emerged
already
anyway,
keep
going.
No,
no
this
one,
this
one
didn't
merge
those
there's
a
new
one.
Okay,
so
this
is.
This
is
a.
This
is
a
way
for
us
to
actually
sort
of.
D
Like
you
know,
final
read-through,
let's
make
sure
that
there
aren't
any
sort
of
like
issues
that
we
haven't,
discussed
and
heard
out
and
then
I'll,
let
Brian
I'll.
Let
you
be
the
the
arbiter
of
like
you
know.
Do
you
think
this
is
sort
of
settled
enough
that
that
we
can
start
building
tooling
and
sort
of
rolling
this
out
in
a
wider
way?
D
Okay,
so,
sir,
it's
a
little
bit
of
a
last
call
type
of
thing,
but
I
think
this.
The
idea
here
is
that
a
commit
like
this,
where
you're
just
changing
it,
is
a
good
way
to
sort
of
get
that
final
sort
of
cathartic
discussion
and
decision
making
versus
getting
in
the
weeds
about
all
the
in-flight
stuff
along
the
way.
B
The
yeah
so
the
content
from
Phil's
previous
PR
I,
guess
earlier
we're
saying
you
know
if
we
have
some
template,
that's
specific
to
API
reviews
that
we
want
to
include
in
caps
that
involve
changing
the
api's.
Then
maybe
that
makes
sense
to
have
as
a
kind
of
separate
document,
with
a
link
from
the
process
to
that
for
people
who
are
doing
API
changes
that
sound,
reasonable
Clayton,
yeah.
E
And
reaching
consensus,
and
then
the
corollary
or
the
volume
of
reviews
and
the
amount
and
then
the
corollary
corollary,
that
has
come
up
repeatedly
and
releases
that
it
trails
towards
the
end
of
a
release
process
and
so,
like.
We
said
for
other
comments.
Scaling
making
that
process
more
efficient
in
the
short
term
and
more
a
transparent
to
a
larger
push
across
the
project
is
probably
going
to
be
the
most
practical
improvement.
We
can
make.
B
B
E
F
E
These
are
the
things
that
I
see
and,
like
maybe
Jordan,
if
you
want
to
pipe
up
like
there's
a
huge
surge
of
last-minute
oh
there's,
this
huge
redesign
at
this
API,
maybe
not
like
it-
would
not
like
the
more
like
traditional,
like
API
management,
but
like
I,
have
this
feature.
It
went
really
late.
It's
really
important
for
this
release.
It's
in
the
features
repo
I
didn't
either
know
where
I
didn't
get
I
didn't
implement
it
until
right
until
feature.
Freeze
and
I've
got
this
massive
PR,
and
can
you
just
go
through
this
process
like.
H
That's
what
I'm
most
concerned
about
yes
and
I
Clayton
like
you
and
Bryan,
like
we
all
get
pounded
by
this
in
the
last
three
weeks.
This
cover
everybody
took
a
vacation
and
left
me
alone,
so
I,
that's
part
of
what
spawned
my
email
about.
Maybe
we
should
actually
have
a
regular
meeting
for
this.
They
think
that
a
deadline
during
the
development
cycle
to
say
like
if
you
think,
you're
gonna,
make
an
API
change.
You
have
to
have
a
proposal
and
a
sketch
in
place
by
the
first
half
of
the
design
of
the
wing.
H
B
E
Not
this
should
not
be
a
clue
to
prevent
really
large
features
from
landing,
really
really
really
late
in
the
release
and
emotionally
those
things
have
to
be
spread
back
out,
and
that
has
to
be
addressed.
This
is
a
good
way,
though,
of
tracking
I
would
expect
API
review
to
be
busiest
during
the
last
four
weeks
of
a
release
and.
E
B
So
we're
overtime.
So
let's
follow
up
on
the
mailing
list
about
the
next
steps,
just
so
that
because
beta
Boz
dossing,
my
so
badly
I,
just
when
I
thought
I
was
close
to
having
under
control
it's
totally
out
of
control
again,
so
it's
it's
horrible.
But
if
you
can
just
post
links
to
the
PRS
and
whatnot
to
the
mailing
list,
that
will
help
me
find
them.