►
From YouTube: Kubernetes Community Meeting 20170105
Description
We have PUBLIC and RECORDED weekly video meetings every Thursday at 10am US Pacific Time.
https://docs.google.com/document/d/1VQDIAB0OqiSjIHI8AWMvSdceWhnz56jNpZrLs6o7NJY
Release team for 1.6; SIG-CLI roadmap; 1.6 stablization release discussion.
A
Good
morning,
everyone
and
good
local
time
to
you,
if
you
don't
happen
to
be
on
the
pacific
time
zone
today,
is
thursday
january
fifth
to
2017,
which
is
makes
me
stutter
to
say,
but
this
is
the
cooper
Nettie's
community
meeting,
which
happens
once
a
week.
Today's
agenda
is
actually
kind
of
light.
I
don't
have
a
demo
unless
someone
has
something
in
their
pocket
right
now
and
wants
to
share
I.
A
This
meeting
so
going
forward,
we
will
be
using
sig
leads
for
this,
which
is
very
awesome.
You've
been
conscripted
all
right.
So
let
me
find
the
topics
and
I
updated
the
document
for
our
topics
in
order
to
give
us
an
archived
documents
which
has
the
all
the
meeting
notes
from
14,
15
and
16,
and
then
now
in
our
formerly
110
page
long
agenda
document
it
loads,
it's
much
shorter,
there's
only
the
last
couple
of
meetings
of
16
and
then
the
new
meetings
in
2017
so
far,
all
right.
A
So
with
no
demo
today
and
thank
you
Jason
for
jumping
in
and
doing
notes.
Let
us
talk
about
1.6
and
really
because
we
have.
We
have
the
opportunity
to
build
out
the
1.6
release
team
and
an
Gillespie
has
written
a
lovely
proposal
about
how
to
move
forward
and
try
to
broaden
the
release
team
so
that
it
isn't
as
dependent
on
google
or
sir
dan.
Do
you
want
to
jump
in
and
talk
a
little
bit
about
the
proposal
that
we
link
here?
Yeah.
B
Julie,
so
it
just
goes
over
some
of
the
roles
and
so
I
put
together
back
that
sort
of
replicate
some
of
the
stuff.
So
eventually
this
will
go
on
to
a
P
of
our
alongside
his
attack,
but
it
sort
of
it
in
orig
the
rules
that
could
be
useful
if
very
nervous
and
we've
got
some
feedback
on
those
and
some
just
some
additional
prophecies
that
mostly
just
from
previous
release
managers,
their
comments
I
put
together
and
some
of
the
people
work
on
testing.
So
awesome.
A
And
you
have
volunteered,
the
link
is
already
in
the
notes
and
agenda
Joe
and
for
everyone
here.
Dan
has
volunteered
to
be
our
release.
Manager
lead
for
the
team
on
1.6,
so
we
are
now
offering
or
actually
asking
for
volunteers,
for
some
of
the
other
roles
that
are
josh
is
chatting
to
josh
is
saying:
hey
Dan,
so
dan
has
volunteered
to
be
the
release
manager
lead
for
this,
and
we
will
fill
in
more
of
the
roles
who
are
looking
for
volunteers.
C
A
Saw
your
PR
on
that.
Thank
you,
your
so
we've
got
a
team
of
three
already
and
I
think
there
is
a
docs
release
person
that
we're
looking
to
get
help
with
as
well,
and
then
we
will
need
an
engineer
from
inside
google
absolutely
on
the
team
to
make
sure
that
we
can
facilitate
the
things
that
are
still
google,
google,
some
limited.
So
if
we
don't
get,
I
didn't
see
many
of
the
Google
team
on
here.
A
A
All
right,
well,
1.6
work
continues
down
in
the
notices
section.
I
have
the
the
PM
group
is
going
to
meet
approximately
weekly
for
the
next,
for
the
next
few
weeks,
at
least
to
go
through
2017
planning
make
a
consolidated
road
map
from
the
special
interest
groups
and
also
go
through
the
retrospective
action
items
to
try
and
help
push
those
out.
A
There
also
is
going
to
become
the
discussion
next
week
about
using
about
how
the
contributor
experience
working
group
is
using
the
using
the
github
projects
in
order
to
do
more
of
the
project
management
for
varying
portions
of
their
work.
So
we'll
get
to
see
how
that
works.
All
right.
So,
on
the
topic
of
releases,
1.5
community
award
nominations,
so
there
was
no
one.
The
last
two
retrospectives
have
had
one
person
called
out
over
and
over
and
over
as
really
holding
together
the
release,
and
there
wasn't
particularly
that
that
one
name
that
came
up
this
time.
A
So
I
am
seeking
community
award
nominations
for
four
and
from
the
community
to
find
out
who
people
think
did
went
the
extra
mile
in
1.5.
So
please
send
me,
nominations
and
we
will
see
where,
where
we
end
up
with
a
1.5
community
award
this
time,
I
would
like
to
be
able
to
at
least
an
ounce
it's
when
one
or
at
kuchen,
berlin
or
before,
depending
on
our
timing
on
all
of
that.
So
please
send
me
nominations.
A
A
D
Us
to
beta
in
16
it's
going
to
take
us.
You
know:
Ruth
lose
prioritization
there,
so
your
favorite
feature
may
not
be
on
our
cut
list,
but
if
you
want
to
come
help
out
on
a
plus
or
life
cycle
feel
free
to
come,
join
us,
but
I'll
post
that
into
the
chat
I'll
take
up
the
the
right
to
right
doc.
There
thanks.
A
A
E
We
go
okay,
so
we
have
last
last
year,
at
the
last
year,
we
kind
of
put
together
the
document
and
had
a
discussion
around
what
our
2017
goals
were,
as
well
as
our
q1
goals,
and
we
found
it
useful
to
group
logically
things
in
the
themes
we're
trying
to
tackle
the
themes
have
some
overlap.
That's.
Why
would
it
mainly
figure
out,
like
a
frustrated
strategic
perspective,
that
we
have
broader
objectives
that
we're
trying
to
tackle,
and
so
briefly
the
ones
we
settle,
our
users
or
education?
This
is
around.
E
We
see
a
lot
of
times
bugs
or
issues
or
questions
on
stack
overflow
from
people
not
fully
understanding
how
it
works.
The
CLI
tools
are
supposed
to
be
used,
feature
requests
for
things
that
already
supported,
or
that
are
supported
by
other
tools
that
can
be
used
together
with
this,
you
lied
to
also
I
think
just
making
sure
we
have
a
holistic
walk
through
how
all
the
pieces
fit
a
little
is
pretty
important.
Their
engineering
velocity.
E
Lifecycle
management
is
a
theme
that's
this
is
this
is
one
of
the
feature
based
themes
and
it's
really
about
the
core
utility
of
what
we
view
the
control
CLI
about
and
that's
how
do
we
take
code,
that's
developed
from
an
end
user
and
then
make
sure
that
their
children,
I
system
is
running
it
and
everything
is
healthy
and
there
being
a
profitable
business,
and
so
that's
actually
there's
a
bunch
of
different
components
about
that.
You
can
think
about
in
a
while.
E
There
is
yes,
the
like
to
control
applied,
takes
care
of
shipping,
your
configs
to
the
system,
there's
a
lot
of
other
pieces
like
Heidi,
a
structure
consisting
directories,
and
how
do
you
factor
them?
So
you
don't
have
a
bunch
of
duplication
in
config
code
and
how
would
you?
How
do
you
handle
a
broader
orchestrations?
That
say
this
needs
to
be
pushed
before
that.
That's
what
I
think.
So
this
is
around
holistically.
E
Taking
a
look
at
all
those
pieces
that
fit
together
to
make
sure
then
user
has
he
is
able
to
do
those
things
they
may
not
involve
us
writing
all
of
them,
but
is
that
we
at
least
know
what
the
solutions
in
place
are
and
what
other
people
are
doing
in
phases
and
Jason
net
or
using
something
else.
We
want
to
make
sure
that
it's
well
documented
how
those
integrated
and
what
the
issues
are
there
and
what
the
alternatives.
E
E
Extensibility,
this
is
another
kind
of
feature
area
theme,
and
this
is
there's
a
lot
of
extensibility
in
the
kubernetes
cluster
itself,
with
third-party
resources,
federated
API
servers,
and
we
want
to
make
sure
that
the
CLI
makes
this
all
those
extensions
feel
native
and
then
coo
control
as
a
platform
is
about.
There's
infrastructure
within
cube,
controlled
that
folks,
we
find
folks
using
such
as
authorization
to
talk
to
the
server
or
how
our
commands
structured
or
even
our
flag
naming
conventions,
something
really
small
but
would
fall
under.
This
we
think
is
important.
E
Is
that,
like
the
flag
name,
conventions
are
consistent
across
all
the
CLI
tools
in
the
ecosystem?
Right,
so
is
it
dry
Ron?
Is
it
dry
dash
to
run
these
sorts
of
things
like
you
should
be
able
to
switch
from
1-12
to
another
and
make
sure
that
you
just
know
how
to
use
everything
so
I'm
figuring
out
how
to
make
I
feel
like
just
in
platform,
regardless
of
what
CLI
tool
you're
using
and
then
there's
some
technical
deck
pieces
I.
Think.
Arguably,
these
pit
fall
under
engineering
velocity.
E
So
here's
a
spreadsheet
of
pretending
the
step
would
like
to
see
completed.
The
first
ones
are
around
user
education,
better
logical
and
grouping
of
commands.
This
is
really
about
like
how
do
we
provide
a
information
architecture
for
how
the
commands
are
set
up
right
now
we
have
a
large
set
of
control
commands
and
how
do
we
bird
thinks?
E
You
are
quickly
directed
away
from
the
fans
you
don't
want
and
torque,
which
means
you
do
want
to
fulfill
your
actives
there's
some
commands
that
are
poorly
documented
right
now,
we're
completely
undocumented,
so
we
should
fill
in
those
gaps
and
then
this
user
friendly
reference
documentation
is
something
that
I've
been
working
on
for
a
while
and
showing
our
prototypes
to
and
there's
pro4
now.
But
that's
just
on
the
list.
E
So
there's
a
lot
and
application
lifecycle.
I
think
this
is
the
again
from
the
core
piece
of
case
that
we
view
the
LCL
I
cackling,
and
so
the
first
just
do
research
to
figure
out
what
the
processes
and
methodologies
are
for
integrating
to
control
into
our
customers.
Workflows
are
these
in
Jenkins.
How
are
these
include?
Control
with
Jenkins
are
the
factoring
their
configs.
These
sorts
of
things
partner
to
is
there
are
things
we
know
that
don't
work
that
are
broken.
E
We
have
lists
of
any
box
for
apply
that
impact
our
users
ability
to
rely
on
it.
So
we
want
to
tackle
the
highest
impact
ones
there
we're
going
to
do
an
audit
of
existing
resources
just
where
we're
having
issues
that
get
filed
and
say
this
apply,
hasn't
work
with
resource
X
arm
and
their
face
that
we
could
have
discovered
if
we'd
actually
look
through
and
get
a
full
audit.
So,
just
looking
at
all
the
resources
and
looking
for
the
common
issues,
we've
seen
another
resources.
E
E
E
Certificate
support
we
want.
We
want
to
be
able
to
support
extensions,
to
keep
control
so
that
this
is
part
of
that
name.
Native
feelin,
phor
Thor
acquire
resources,
Confederated
api
resources
would
like
to
have
a
design,
a
proof
that
we
can
implement
on
a
future
porter
and
on
same
thing
with
you.
Guys
would
like
to
be
able
to
have
you.
I
support
the
same
sort
of
native
feeling
that
the
CLI
does
and
then
last
leave
the
as
a
platform
pieces.
E
We
want
to
reduce
the
dependency
on
cobra,
the
couple
of
cobra
from
the
actual
business
logic,
behind
running
the
commands
and
move
logic
out
of
the
client
and
the
server
to
reduce
that
version.
Ski
wish
you
were
talking
about
earlier
and
then
the
technical
that
piece
here
is
just
to
try
and
get
a
better
handle
on
the
incoming
issues.
We
have
a
ton
of
issues
include
control
right
now
and
it's
it's.
E
It
makes
it
hard
to
say
like
how
many
we're
actually
going
to
get
completed
and
how
many
get
done
and
have
reliable,
metrics
around
that
and
so
arm
putting
them
together.
First,
like
maybe,
SL,
allows
for
how
many,
how
many
shoes
we're
going
to
leave
open
and
how
many
we're
gonna
tackle
and
how
many
p
zero
issues
we're
going
to
tolerate
that
sort
of
stuff
so
that
we
ourselves
to
know
what
our
focus
should
be.
If
it's
tackling
open
issues
and
robotics
versus
developing
features.
E
F
D
E
One
of
the
motivating
factors
is
that
upgrading
the
so
there's
the
CLI
and
the
server
have
expectations
around
how
the
other
one's
going
to
behave
right
now,
if
you
have
a
logical
quote
example,
this
is
like
garbage
collection
when
the
server
introduces
garbage
collection,
but
the
older
versions
of
cl.
I
still
thought
that
they
had
to
do
child
rebe.
E
If
you
use
a
skewed
version
of
the
client
with
a
different
version
of
a
server
now
they
both
think
they're
supposed
to
be
doing
this
garbage
collection,
piece
and
they'd
end
up
causing
just
weird
behaviors
that
constants
right
a
little
bit.
So
we
had
to
tell
our
users
don't
use
version.
1.3
could
control
with
version
1.4
server
if
you're
doing
this
command,
because
it
breaks
things
right.
So
what?
But.
D
E
D
D
Yeah,
and
so
that's
you
know,
that's
the
type
of
thing
it
makes
sense
there
I,
don't
I
just
feel
like
I
feel
like
if
we
do
it
flying
inside.
You
have
this
issue
where
you
don't
have
consistency
across
clients,
but
you
also
have
the
ability
to
to
you
know
you
know,
support
multiple
versions
be
much
more
flexible
about
sort
of
like
which
ones
you
want
to
activate.
B
Of
think
is
a
concrete
example
we're
taking
things
that
have
already
been
done,
client-side
and
are
ready
to
move
to
the
server
side
and
for
the
way
up
to
the
server
side.
You're
right,
we
probably
wouldn't
and
I,
don't
think
anything
on
Phillip.
Your
list
was
something
that
hasn't
already
been
in
a
client
that
someone
else
that
another
client
has
wanted
to
go
we
like
to
apply.
Is
it
great
actually.
D
E
E
A
Just
it
how
it
lines
up
with
what
answers
did
you
get
from
the
the
very
questions
that
you
know
included?
Where
did
they
go?
Does
your
sig
on
code?
Where
is
it
reflected
in
the
owners?
Well,
do
you
spend
enough
time
too
much
time
answering
issues
on
github,
Stack,
Overflow,
balancing
between
new
features
and
stabilization?
How
have
you
done
over
the
last
couple
of
release
through
the
introspection
questions,
Tesco's,
comfort,.
E
Yeah
I
think
those
are
actually
all
things
we've
been
talking
about.
Awesome
ready,
some
of
this
stuff,
we're
well
aware
of
right
like
and
we've
been
working
on.
Stabilization
for
past
releases,
like
this
last
released,
was
a
big
focus
on
coop
control,
apply,
fixing
birds
there
and
that's
going
to
continue
to
be
the
case
for
the
next
quarter
issued.
That
was
also
another
thing.
I
think
independently
talked
about
how
like
how
do
we
manage
excuse
and
what
are
our
goals
around
tackling
them?
E
A
Good
good,
good
yeah,
the
idea
with
them
is
exactly
that.
It's
a
framework
to
have
you
know
relatively
consistent
discussions
across
the
different
special
interest
groups.
So
thank
you.
Do
any
other
cigs
want
to
volunteer
to
talk
about
the
2017
planning,
q1
planning
or
answers
to
those
introspective
questions
that
we
set
forward.
G
They
just
Bob
not
fully,
but
one
of
the
topics
that's
been
coming
up
last
year
and
this
year
in
six
scaling
is
the
etsy
iii-v
migration
and
I
just
wanted
to
call
everyone's
attention
to
that.
The
Tim
Tim
sent
committees
I
think
this
is
this-
was
one
we're
pretty
excited
to
see
it
pushed
over
the
line
and
for
16
that's.
A
B
A
A
B
So
the
SCD
team,
hi
I'm
Kayla
mock
ahora
les.
The
HED
team
would
like
to
help
with
improving
the
documentation
about
deploying
and
operating
at
ced
in
the
Trinities
context,
and
so
we
have
put
together
a
Google
Form
to
collect
responses
to
try
and
see
how
people
are
deploying
at
CD
for
communities
today
and
what
topics
you'd
like
us
to
addressing
documentation
so
I
also
sent
out
a
mailing
post
to
the
communities,
dev
mailing
list,
with
the
target
getting
responses
within
a
few
weeks.
So
please
click
that
and
fill
out
responses.
A
H
I'm
not
going
to
let
us
the
FCD
comment:
go
without
a
showering,
an
enormous
amount
of
compliments
on
core
OS
and
all
the
great
work
they've
done.
It
is
very
difficult
to
overstate
the
level
to
which
this
improvement
in
at
CD
makes
our
scaling
goals
for
Cooper
Nettie's
possible,
so
really
enormous.
Compliments
to
them
and
Daniel
on
on
our
team
and
who's
helped
integrate
that
so
enormous
amount
of
work.
Please
do
take
note
because
it
is
awesome.
Yes,.
A
Core
OS
is
a
fantastic
core
set
of
contributors
to
Gubru
Nettie's,
as
are
many
of
our
partners,
but
around
etsy
d,
etsy
d,
specifically
that's
been
a
huge
help,
all
right
any
other
six.
Oh
yes,
we
all
hard
the
core
OS
team.
Alright.
So
then
I
will
go
open
the
floor
to
other
topics
which
may
or
may
not
have
been
on
our
agenda
because
we
have
a
little
bit
of
extra
time
today.
A
B
I
had
two
questions
that
I
put
on
the
agenda
there:
okay,
the
first
was
around
on
moratorium
that
Brian
grant
posts
over
the
holidays
on
feature
and
design
proposal
reviews.
The
idea
was
since
everybody's
out
for
the
holidays:
let's
not
bother
coming
up
with
a
process
for
designed.
Herbalism
they're
still
seem
to
be
some
like
moving
of
documents
from
the
Cuban
editors
repo
to
the
community
Rico.
So
we
figure
it
was
easiest
to
like
let
the
dust
settle.
So
it's
now
a
20-17.
B
My
question
is
whether
or
not
we
want
to
open
that
up
and
start
actually
reviewing
design
proposals
or
if
it
wanted
to
keep
going.
The
only
reason
I
prefer
keep
going
is
because
Brendan
Byrnes
just
sort
of
responded
to
the
thread
that
I
looked
in
the
meeting,
notes
and
he's
proposing
that
we
sort
of
freeze
design
proposals
for
the
entirety
of
this
release,
since
this
is
a
stabilization
release
and
theoretically,
anybody
who
wanted
their
feature
in
should
have
already
gotten
it
by
now.
B
I
To
be
clear,
I
was
proposing
that
I
wasn't
man.
I
was
proposing
the
discussion,
not
not
that
it
should
be
the
way
it
is
and
and
claim
just
chatted
in
that
their
design
proposals
for
things
like
stabilization,
so
I
think
that,
if
what
you're
talking
about,
maybe
we
should
make
a
distinction
between
internal
and
external
design
proposals
I
you're,
talking
about
how
we
stabilize
some
internal
piece
of
the
API
service
that
no
person
is
ever
gonna,
see.
That's
probably
just
fine
well.
B
Try
and
be
clear
here:
I
guess,
I
you
the
path
to
not
someone
steps.
It
is
if
you
want
something
new
in
16
needs
an
open,
a
feature
issue.
If
you
want
to
open
a
feature
issue,
one
of
the
first
things
you
need
to
do
is
have
a
design
proposal
that
you
can
link
that
feature
issue
too.
So
you
can
describe
the
design
of
the
feature
you
want
to
actually
implement,
and
so,
if
you
put
a
roadblock
on,
let
me
put
a
roadblock
on
all
new
features.
Doing
any
16
right.
I
B
These
are
interesting,
I.
Think
one
of
the
things
that's
interesting
is
at
your
listening
on
a
bunch
of
the
cigs
talking
about
this.
A
few
of
the
cigs
felt
that
they
are.
They
paid
out
a
lot
of
their
stabilization
debt
and
I.
Think
some
of
them
reported
that
back
here,
I
mean.
Do
you
feel
that
a
blanket
statement
across
the
cigs
makes
sense,
or
is
this
more
of
like
we
should
bias
towards
not
features
or
do
you
think
no
features
is
important.
I.
I
Guess
bias
would
be
my
my
steam.
I
guess
my
experiences
that
in
the
absence
of
saying
absolutely
not,
then
people
slip
everything
in
and,
if
you
say
absolutely
not,
then
the
people
who
really
care
and
really
think
it's
important,
come
to
you
and
ask
for
you
know
well,
but
this
like
just
like
you
said
well
like
there
are
some
stabilization.
I
You
know
there
are
some
stabilization
proposals:
okay,
well,
that
makes
sense
right,
like
let's,
let's,
let's
figure
out
the
internals
of
how
we
restructure
something
or
you
know
cook,
if
there's
a
proposal
for
how
we
build
the
new
abstraction
into
the
api
codex.
So
that
code
isn't
so
it
isn't
so
much
of
a
nightmare.
That's
great
right,
but
I
think
that
we
should
be
very
careful
about
just
opening
the
door
to
features
because
we
won't
do
the
stabilization
work.
In
that
context,
I
guess.
J
J
More
like
well,
if
we
talk
about
the
monitoring
pipeline
right,
like
the
monitoring
pipeline
was
discussed
for
over
a
year
and
now
we're
down
to
the
details
of
how
we're
actually
going
to
do
the
monitoring
pipeline
and
so
like
the
core
metrics
proposal
that
I
think
they
would
just
opened
or
like
the
custom.
Metrics
api
client
api.
It
like
my
team
open
but
like
it's
a
number
of
things
that,
like
the
high
level
vision,
have
been
discussed.
But
now
you
get
down
to
the
details
that
require
designs.
I
I
think
I've,
like
a
good
statement.
F
Mean-
and
we
have,
we
have
design
proposal
like
out
there,
just
not
merged
yet
they're,
still
kind
of
in
discussion
or
or
nearing
kind
of
that
discussion
merge
time.
So
it
look
I
feel
like
it
would
kind
of
be
a
shame
if
we
like
you,
know,
we've
gone
and
all
this
stuff
going
and
then
where
we
can't
merge
any
discipline
proposals
now
so
well,
that's
gonna
have
to
wait
for
the
next
release
email.
You
know
we
were
getting
corals
that
consensus
and.
B
So
maybe
a
me
on,
if
we're
biased
towards
stabilization,
the
that
what
you're
describing
Derek
and
softly
is
the
idea
of
long-running
things
that
are
that
were
never
single
release.
Kind
of
ticket
features,
I
mean
I,
don't
know
brenda
was
the
F
feature,
the
same
kind
of
feature
that
you
were
thinking
about?
No.
I
I
think
that
that
makes
sense
I
mean,
I
think,
that
if
I
mean
I
guess
I
would
be
okay
with
saying
like.
If
it's,
if
it's
in
flight,
then
you
can
demonstrate
its
been
in
flight
for
a
long
time
and
it's
been
and
it
just
hasn't
merged
and
you're.
Just
waiting
for
the
three
last
check
offs
and
there's
nothing.
There
is
no
big
discussion
still
open,
then
that
makes
total
sense
like.
I
Want
to
stop
work
that
is
nearly
done
arbitrarily,
but
what
I'm
saying
is
that
perhaps
it
is
a
time
to
stop
the
Orion.
You
can
even
continue
the
discussions,
I
guess,
but
but
not
come
to
new
conclusions
that
we
didn't
already
basically
understand.
All
that
makes
sense.
I
don't
know
I
feel
like
it
makes
for
a
big,
maybe.
B
Like
this
is
a
question
for
the
cigs
like
in
the
civic,
are
the
things
that
you're
proposing
to
do
in
16
brand
new
continuations
of
what
has
been
worked
on
for
a
long
time
or
are
stabilizing
and
fixing
problems
that
are
outstanding?
And
if
you
don't
feel
that
if
you
can't
clearly
articulate
that
the
things
that
you've
already
even
are
already
stabilized
and
you've
already
burnt
down
your
debt,
you
don't
have
debt,
then
you
really
don't
have
any
that
it.
There
should
get
very
strong
guidance
against
introducing
any
new
concepts.
Oh
I
think.
J
I
think
that's,
it
looks
of
coronas
signode
features,
but
we
went
through
in
our
last
cig
meeting
and
number
these
things.
First
off
we
learn.
We
have
certain
really
schools
that
are
clearly
on
getting
design
agreement.
So
if
it's
just
a
releasable
to
get
a
design
agreement
than
someone
needs
to
go
and
write
a
designs,
so
I
don't
want
to
punish
people
for
writing
design.
If
that
was
explosive
gold
early,
then
we
have
other
features
like
coming
through
here.
I
B
It's
a
really
good
point:
Brennan
like
it's.
The
idea
that
we've
devolved
the
cigs
to
be
more
independent
cigs
are
creating
roadmaps
and
publishing
them,
and
so
this
cigs
have
more
autonomy,
and
yet
we
still
need
to
be
able
to
sound
the
alarms
across
the
whole
project
and
get
you
know,
make
sure
that
focus
is
there
to
like
stabilization
as
a
goal,
ensuring
that
the
EBE
stone
slide
is
a
goal
documentation
as
a
goal
contributor
access.
This
is
a
goal.
I
And
I
would
say,
like
everything
like
this
there's
going
to
be
waste
right,
like
I,
have
to
have
to
freely
admit
like
there
will
be
places
where
it
just
stupid,
but
you
have
to
do
it
in
a
cross-cutting
way
or
Elsa.
Just
us
happen,
okay
and
I.
Don't
know,
I
think
we
should
have
the
discussion,
and
probably
this
is
not
the
right
context,
because
it
was.
You
know
something
I
emailed
to
the
list
rather
than
something
that
that
we
put
on
this
get
just.
J
I
There's
a
distinction
between,
like
on
the
clock,
time
and
YouTube
time
right,
like
I,
think
we
all
go
and
watch
YouTube
some
of
the
time
and
if
you
want
to
go
work
on
design
proposals
in
your
YouTube
time,
instead
of
watching
YouTube,
that's
great
right,
but
we
need
to
understand
and
also
but
also
we
have
to
understand
that
that
comes
at
a
cost.
Right,
like
especially,
it
really
depends
right.
Some
things
that
they're
going
to
stay
entirely
inside
of
a
cig.
I
Maybe
it
doesn't
cost
the
entire
project,
but
but
some
things
cost
the
entire
project,
because
people
need
to
learn
about
it
right
and
need
to
understand
it
and
that
costs
work
that
might
otherwise
be
headed
towards
stabilization.
So
that
leather,
that's
my
that's.
My
sense
is
it's.
We
want
to
make
sure
that
the
focus
and
the
effort
and
is
there
and
I-
think
there's
opportunity
for
things
to
slip.
If.
B
I'm,
a
new
developer
to
the
project
and
I
have
a
new
idea
and
I
want
to
submit
a
new
design.
It's
up
to
me
to
figure
out
which
sink
I
should
get
to
review
that
design,
and
then
I
should
figure
out.
If
that
sake
has
paid
down
enough
tagged
at
to
know,
if
they're
going
to
be
able
to
allocate
a
reviewer,
you.
I
B
I
I
B
B
K
See
six
storage-
we
just
had
our
planning
meeting
this
morning
and
a
lot
of
the
features
that
we
were
discussing
were
continuations
on
existing
features.
But
a
couple
of
them
were
brand
new
features
things
like
snapshots,
so
we
would
love
to
get
some
guidance
on
whether
we're
proposing
absolutely
no
features
or
not.
K
I
Do
this
on
the
mailing
list
right,
I
mean,
as
I
said
before,
this
was
an
idea
spit
to
the
mailing
list,
not
not
our
conclusion
so
like
let's
just
talk
and
and
get
that
done.
If
there's
enough
discussion,
if
there's
enough
discussion
there,
then
maybe
next
make
community
meeting,
we
can
spend
more
time
on
it
and
stop.
A
B
Okay,
I
think-
and
I
think,
there's
broad
agreement
that
anything
massive
that's
net
new
like
it
to
brian's
original
point
like
there's,
been
a
lot
of
design
backlog,
the
more
we
can
try
to
reduce
the
number
of
new
concepts
coming
in
the
easier
it
is
to
ensure
that
the
existing
concepts
get
time
and
attention,
and
so
even
just
like
on
the
future
basis.
If
it's
a
net
new
feature
and
it's
not
dramatically
reducing
the
cognitive
complexity
of
something
else,
that's
probably
very
increasing
the
cognitive
complexity.
I
And
I
think
that's
my
basic
point.
I
mean,
I
think,
there's
also
a
degree
to
which
what
you're
saying
is
effectively
like
those
are
stabilization
features
for
the
api
like
if
you're
reducing
the
cognitive
debt,
then
in
some
way
you
are
stabilizing
the
api,
whereas
phpbb
are
increases
the
cognitive
that
you're
destabilizing
the
UK.
B
C
I
was
the
yes,
yes,
I
was
the
person
made
it
so
we
bizim,
we've
been
stuck
into
brand
red
decided
to
implementing
the
current
situation
was
just
see
groups
so
answering
your
question:
where
is
the
discussion
and
where
is
the
ways
to
commit
a
pull
request
for
that?
Your
drag
all
the
stuff
keys
in
the
community
to
repo
your
is
a
pill
request
number
226,
so
you
can
open
it
and
read
all
the
information
there
and.
C
A
F
A
So
what
I'm
going
to
do
is
build
out
a
spreadsheet,
because
P,
GM's,
love,
spreadsheets
and
I
will
set
up
dates
and
start
by
asking
volunteers.
And
then,
if
we
don't
get
volunteers
early
enough
and
include
you
know
having
good
coverage,
then
I
will
start
assigning
dates
and
then
you
can
horse
trade
your
way
out
of
the
date
your
assigned
to,
but
we
will.
This
is
going
to
be
a
thing
that
I
will
send
a
broader
set
of
instructions
to
the
cooper,
Nettie's,
siblings,
mailing
lists,
so
there's
nothing
to
be
done
yet.
A
A
A
Alright,
I
will
go
through
notices,
jump
in
if
you
have
something
else,
so
two
factor
authentication
is
going
to
be
required
if
you
are
a
coup,
Brunetti
zorg
member
by
the
end
of
the
month.
So
please
turn
on
to
fa.
If
you
don't
have
it
on,
when
we
enable
to
fa
across
the
of
the
entire
organization,
you
will
be
kicked
out
of
your
organization,
which
means
you
can
still
do
pull
requests
and
such
against
the
code
base,
but
you
will
lose
some
of
the
privileges
like
labeling,
if
I
remember
correctly
and
other
other
fun
things.
A
So
that's
one
when
I
talked
about
PM
group
meeting
and
there
are
links
to
the
time
and
agenda
in
the
notes.
Also
planning
has
begun
on
the
Cooper
Nettie's
leadership
summit,
which
is
a
new
thing
which
is
going
to
happen.
I
believe
at
Dunkirk
on
we
don't
have
confirmed
rooms
yet,
but
once
we
get
there,
I
will.
I
will
bring
this
out.
A
So
the
leadership
summit
is
going
to
be
primarily
cig
leads
and
team
leads
from
the
companies
that
that
are
large-scale
contributors,
so
we
will
be
generating
an
invite
list
for
that,
and
that
will
be
happening,
as
I
said
likely
in
austin
at
or
around
dark
on
either
the
day
before,
a
day
after,
as
soon
as
I
have
facilities,
we
will
nail
that
down.
We
also
have
started
the
2017
cooper,
nidhi's
developer
summit
planning,
which
will
also
be
in
austin,
but
at
coop
con
in
november
same
same
game.
A
K
Hopped
on
a
call
a
little
late,
but
update
on
1.5
we're
planning
on
releasing
one
point:
five
point:
two:
on
Tuesday
December
10,
there
was
a
bunch
of
patches
that
went
in
over
the
holidays.
After
that
I'm
planning
on
handing
off
the
1.56
releases
our
duties
to
someone
else.
At
the
moment,
this
process
is
still
very
Google
centric.
So
it's
going
to
be
someone
will
select
from
google
but
moving
forward.
I
think
that
discussions
already
happened.