►
From YouTube: Kubernetes Community 1.5 Retrospective 20161222
Description
We have PUBLIC and RECORDED weekly video meetings every Thursday at 10am US Pacific Time.
https://docs.google.com/document/d/1VQDIAB0OqiSjIHI8AWMvSdceWhnz56jNpZrLs6o7NJY
This is the 1.5 retrospective edition. With retrospective notes here - http://bit.ly/k8s15retro
A
Started
good
morning
and
good
local
time,
everyone,
it
is
Thursday
right
before
holidays,
where
much
everybody's
up
for
the
end
of
the
year
Thursday
december
twenty
seconds,
and
today
is
the
1.5
retrospective
or
cobranet
eats
so
jason
has
graciously
offered
to
facilitate
again
it
was
done
a
great
job.
He
dropped
the
link
into
the
chat
and,
let's
just
go
from
here
great.
B
B
B
So
just
briefly,
I
want
to
go
through
the
follow-up
from
the
1.4
retro,
and
these
are
things
that,
when
we're
doing
the
1.4
retro,
we
identified
as
possible
areas
for
improvement
and
I
just
want
to
get
a
consensus-based
idea.
If
we
actually
did
do
these
things
and
when
I
say
consensus,
pay
I
mean
that
if
you
don't
speak
up
about
these
things,
we're
going
to
make
the
assumption
that
these
were
improvements.
B
So
big
things
here
address
the
p0
flakes
during
the
dev
psychol
and
get
the
better
visibility
on
closeout,
stale
and
open
issues,
correct
documentation
for
version
skew
version
ski
Oh
tests
we
have
should
remain
passing
through
the
dev
psychol
define
more
spare
release
capacity
exists,
feature,
complete
definition,
means
no
open
known
issues
for
their
exceptions,
written
and
it
has
tests
testing
its
scale
with
more
cloud
providers.
Issue
owners
need
to
be
represented
and
also
update,
documentation,
update
issue
every
24
hours
once
code.
B
Freezes
start
is
you
need
to
get
help
for
Android
from
Google
who
runs
the
queue
on
Google
infra,
implement
web
hooks
or
other
method
in
the
submit
cube
and
community
management
group
codified,
a
group
of
people
who
heard
cats--?
So
if
there's
any
of
these
that
need
discussion
or
follow-up
or
if
we
want
to
bring
these
forward
into
this
retro,
you
all
have
the
floor
for
the
next
couple.
Minutes.
B
C
C
C
C
C
The
issues
around
bug,
triage
in
general,
things
like
closing
out
stale,
open
issues,
I
think
this
is
still
it's
still
an
issue,
but
the
release
team
did
a
pretty
good
job
of
going
through
release,
blocking
or
basically
1.5
mile
stone
issues
and
constantly
pinging
owners
to
try
to
get
issues
closed
or
moved
out
of
the
blocking
pass,
so
that
I
think
improved
to
some
extent.
But
there's
a
lot
of
open
items
for
bug
triage
that
that
we
listed
below
them
can
discuss
great.
B
B
D
Sure
yeah,
hopefully
you
all
can
hear
me
I-
think
that,
from
my
perspective,
the
release
branch
for
15
was
cut
early
and
I
never
heard
any
complaints
about
provisioning
infrastructure
for
the
15
release.
That's
really
cool
that
was
awesome,
like
that,
has
definitely
been
a
hurdle
every
other
release.
So
thank
you
so
much
for
that
and
then
I
think
the
other
thing
for
me
personally,
as
an
outsider,
the
burndown
meetings
continue
to
be
super
awesome
and
effective.
It
is
the
best
way
for
me
to
find
out
what
is
happening
about
the
release.
D
I
think
the
cadence
of
the
way
decadence
sort
of
ramped
up
on
the
way
to
release
was
good,
I
I.
Think
that's
a
good
thing
to
continue.
My
you
know,
I'm
trying
to
say
all
the
good
things
here,
but
just
the
the
piece
of
feedback
on
the
burn
down
meetings
might
be
like
we
never
actually
had
documented
action
items
that
were
sent
out
to
a
list
of
people
after
the
fact.
So,
if
you
showed
up
at
the
meeting,
you
got
all
the
info.
D
If
you
weren't
there,
you
totally
missed
out
and
I
feel
like
it
would
be
great
to
sort
of
document
what
we
discussed
in
what
we're
doing
going
forward
and
I
think
sought,
did
a
really
good
job
of
doing
that
in
sort
of
the
action
items
list
like
that
was
a
that
was
kept
up
to
date,
and
that
was
very
informative.
But
we
just
we
didn't
broadcast
that
some
more.
A
D
B
D
E
D
F
G
I
Yeah,
the
the
github
PM
group
that
Brian
created
was
super
helpful
arm
before
could
not.
It
was
really
helpful
to
fir
tree
housing
bugs,
like
I,
couldn't
add
labels
before
or
move
like
people
who
were
signed,
who
were
no
longer
part
of
the
project,
so
that
was
really
nice
to
expand
the
franchise
a
little
bit.
People
who
can
work.
The
mechanics
of
the
github
repo.
C
Great
son,
you
want
to
take
this
one,
oh
yeah,
so
issue
triage
was
definitely
an
issue,
and
there
is
more
about
that
later,
but
compared
to
the
previous
releases,
it
was
much
better.
A
part
of
it
was
instead
of
one
person
doing
it.
There
was
a
team
of
us,
including
dims
in
Caleb,
and
we
also
kind
of
improved
the
process
a
little
bit
by
making
sure
that
we
had
release
blocker.
C
We
consistently
used
the
release,
blocker
labels
to
figure
out
what
was
and
what
was
not
in
the
release
blocking
path
and
that
kind
of
gave
us
a
very
high
level
view
of
what's
going
on
and
whether
we
were
able
to
launch
or
not.
Second
item
is
that
last-minute
release
blocking
issues
were
handled
really
well,
especially
the
CPU
soft
lock
up
issue
which
could
have
delayed
the
release
by
weeks.
Possibly,
we
had
a
bunch
of
folks
jump
on
it
with
a
bunch
of
really
hard
repros
and
they
worked
very
hard
to
get
them
resolved
quickly.
A
B
It's
a
and
then
compare
that
if
you
go
back
and
look
at
the
1.3
retro
notes,
there's
we
are
trending
up
on
all
these
key
blockers,
which
is
good.
Anybody
else
want
to
add
anything
of
the
the
dev
summit.
I
think
that
personally,
am
is
a
great
thing
for
us
to
add
to
our
quiver
of
arrows
in
terms
of
how
we
manage
the
product.
Any
commentary
on
that.
A
No,
we
are
not
doing
it
a
in
Berlin.
We
didn't
have
enough
people.
That
said
yes,
they
could
potentially
attend
and
would
be
interested
enough
of
the
the
core
dev
team.
Initially
to
do
it
again,
we're
looking
at
doing
a
cover,
nities
leadership
summit
in
probably
the
first
half
of
next
year
and
then
another
kuber
Nettie's
dev
summit
at
KU
con
in
austin
in
november.
A
D
Here,
I
only
I
just
had
a
quick
comment
on
the
dev
summit.
We
didn't
and
I'm
sure
Sarah
can
sympathize
with
this.
We
didn't
have
dedicated
note
takers,
so
it
was
totally
up
to
the
discretion
of
the
person
running
a
given
session,
whether
or
not
notes
actually
got
released,
and
for
me
the
dev
summit
was
the
medias
part
of
kook
on
it.
Like
we
talked
about
so
much,
it
was
awesome.
It
was
great,
but
only
some
of
it
was
documented
and
the
right
mailing
list
to
look
at
right.
Sorry.
B
D
B
D
So
I
I
step
up
as
the
dude
who,
like
rope,
release,
notes,
missed
a
couple
breaking
changes,
there's
only
one
that
I
have
a
issue
that
I
can
link
to,
and
that
is
that
the
binaries
are
no
longer
included
in
the
crew
gratis
that
target
cheesy
binary
and
like
released
our
ball
right.
So
I
don't
know
about
the
rest
of
you,
I
assumed
when
I
downloaded
that
I
got
everything,
and
that
has
now
changed
and
I
totally
missed
that
in
the
release
notes
it
turns
out.
D
There
was
a
syntax
error
that
prevented
that
from
getting
caught
in
a
release,
notes,
but
also
I'm,
a
human
being
and
I
read
through
as
much
as
I
could,
but
I
missed
this
as
an
implication:
I
also
didn't
beta
tests.
So
if
I
had
been
beta
testing
or
alpha
testing,
I
may
have
caught
this
sooner.
So
it's
just
like
this
to
me.
I
was
recently
at
a
conference
where,
like
we're
sort
of
trying
to
write
the
test
for
how
you
get
certified
for
Cooper
Nettie's
and
everybody
was
surprised
about
this
change.
D
D
For
example,
I
think
persistent
volumes
have
gone
from
alpha
to
beta
in
the
last
release
and
all
the
Alpha
stuff
may
have
gotten
dropped,
I'm,
not
sure,
but
it
seems
like
the
default
storage
class
of
anything
no
longer
exists
anywhere
like
you
now
have
to
pre,
create
that
and
I
again.
This
is
something
I
couldn't
find
in
issues
or
Docs,
or
release
notes.
D
So
I
said
beta
and
alpha
testing
earlier
I
think,
like
somehow
incentivizing,
that
I've
heard
talk
of
calling
these
things
release
candidate
since
alpha
Zubaydah's
I,
don't
know
like
what
sort
of
cred
we
could
do
for
that.
But
I
think
that,
like
getting
playing
people
in
front
of
actual
releases
that
have
changed
a
little
bit,
what
would
probably
help?
Okay
so
the
other
thing.
That,
apparently,
is
your.
A
Open
take
that
to
a
meta,
a
meta-level,
and
I
met
a
theme
for
us
because,
basically
documentation
earlier
release,
notes
earlier
reviews
of
betas
earlier,
so
that
because
because
the
one
point
five
point,
one
change
fit
exactly
in
this
point:
if
more
eyes
had
been
looking
at
the
the
change
of
the
defaults,
then
we
would
have
had,
because
we
almost
as
soon
as
we
really
somebody
went
hey
this.
This
is
a
complicated
set
of
defaults
that
defaults
open.
So
we
need
to.
A
B
Another
another
thing
just
comes
to
my
to:
is
it
so
cigs
that
have
a
steak
and
some
of
these
things
so
I
think
for
me
is
hard
now
the
leadership
and
sick
cluster
ops.
This
is
this
is
an
operator
problem.
I
mean
if
I
was,
if
I
had
build
steps
for
those
that
relied
on
those
binaries
being
in
a
certain
way,
then
actual
it
in
something:
hey
cluster
operators.
Guess
what's
going
to
be
coming
down
the
pipe
for
you
so
cigs
that
have
a
stake
in
some
of
these
release
notes.
B
D
I
think
that's
maybe
my
point
is
that
I
have
gotten
some
criticism
or
commentary
from
folks
that
have
looked
at
the
release,
notes
as
the
gate
for
breaking
changes,
and
that
is
not
the
right
gate.
Sorry
it
just
isn't
it's
one
gate.
We
should
have
defense
in
depth
here
and
so
incentivizing
the
community
to
actually
test
this
stuff
ahead
of
time,
getting
the
right
people
on
accountable
for
testing
stuff.
C
So
one
thing
I
want
to
clarify
here
is
the
process
of
getting
release.
Notes
out
is
one
is
compiling
the
release,
notes
and
that's
what
Aaron
was
responsible
for,
and
he
did
an
awesome
awesome
job
on
that.
The
second
part
is
making
sure
that
the
right
data
is
fed
into
the
release,
notes,
process
and
that's
where
I
think
this
whole
thing
fell
apart
a
little
bit
and
that's
not
errands
fault
at
all.
That's
not
something
he's
responsible
for.
C
Ultimately,
it's
the
responsibility
of
the
devs
who
make
the
changes
to
make
sure
that
they're
feeding
it
into
the
right
pipeline
that
didn't
happen
in
a
few
cases
and
I'm
guessing
that's
because
we
don't
have
the
process
in
place
to
do
that,
we
do
have
the
release
note
label
on
the
PRS
to
be
able
to
say
you
know.
This
is
something
that
should
be
called
out
in
the
release.
Notes
I'm,
not
sure
whether
that
process
needs
to
be
improved
or
but
we
could
have
a
wider
discussion.
C
Something
needs
to
be
done
here
so
that
any
big
breaking
changes
get
called
out
very
loudly
and
boldly
and
are
fed
into
the
release.
The
person
compiling
the
release
notes
the
person
compiling
the
release
notes
definitely
should
not
be
responsible,
though,
to
to
make
sure
that
everything
is
there,
that
they
capture
everything.
That's
the
responsibility.
The
person
who
makes
the
change.
E
Just
a
few
words
for
me,
so
s3e
as
we've
done
during
this
release,
and
we
also
made
experiment
first
release
so
and
has
been
using
the
simple
single
leg
sorts
of
throws
death
table
that
have
been
maintained,
collecting
that
information
from
when
the
future
strip
on
from
the
home
decor
a
poor
where
these
changes
for
equipment.
So
I
learned
that
we
have
to
move
for
move
like
the
deadlines
for
reviewing
all
this
stuff,
and
we
have
to
like
work
with
the
symbol.
Such
truths
to
get
in
it.
E
So
like
people
who
are
implementing
changes
have
to
be
responsible
to
make
sure
that
these
changes
are
the
correct.
At
the
same
time,
I
suppose
we
shouldn't
drop
this
process
that
we
had
before
simply
have
to
like
make
it
better.
We
shouldn't
like
change,
Matherly
annison
here,
so
I'm
in
general
on
to
decide.
How
did
you
have
any
fear,
but
we
kept
to
simply
implement
it.
We
have
to
simply
make
it
bedtime.
Mister
great.
D
Yi
spreadsheet
was
the
only
source
of
truth.
I
could
refer
to
the
features
repo
in
my
opinion,
needs
to
die
in
a
fire
completely
unusable
like
I.
Dare
you
to
check
any
of
the
1.5
features
and
tell
me
which
one
of
them
actually
have
check
boxes
that
were
checked
off,
because
there
were
actually
a
couple
I'm
surprised.
Some
people
did
do
it
and
thank
you
so
much
to
those
of
you
who
did
but
very
very.
E
D
People
actually
followed
this
process.
It
is
not
machine
parsable
at
the
at
the
moment,
like
maybe
that's
something
we
should
just
improve
our
tools
to
do
but
like
it
is
really
really
difficult
to
work
with
that
repo.
It
means
almost
nothing
to
me.
The
spreadsheet
meant
everything
to
me
in
terms
of
tracking
who
was
actually
on
the
hook
and
what
they
were.
Shipping
I
really
want
to
hear
from
other
product.
Folks,
like
how
did
you
find
the
features
repo
useful?
How
can
we
make
this
situation
better
lek.
E
E
This
is
just
to
work
this
day
and
after
that
these
spreadsheets
will
be
much
easier
to
maintain
because
it
was
like
the
left
pane,
but
it
wasted
a
lot
of
my
time
to
collect
all
the
information
of
the
features
are
able
to
distract
you
to
make
it
usable
phone
for
for
people
like
Aaron
who
collecting
this
information
doesn't
like
the
listeners.
So
we
are,
we
have
to
like
make
feature
circle
much
much
more
user-friendly,
I.
I
Kind
of
the
way
I
think
about
you
know:
project
server
management
like
tooling
and
repositories.
Information
like
I
think
the
spreadsheet
was
fantastic,
but
it
doesn't
stand
in
place
for
the
ability
to
get.
You
know
timely
status,
updates
about
the
progress
of
any
feature,
that's
being
worked
on
for
the
project
and.
A
I
And
I,
don't
even
with
the
shorter
template,
I
think
they're
still,
it
should
be
someone's
responsibility
or
some
group
of
people's
responsibility.
The
feature
we've
been
proposed
and
accepted
by
a
cig
to
get
kind
of
continuous
feedback
on
there,
because
it
seems
to
least
to
me
and
kind
of
like
it.
I
need
naive
understanding
of
the
features,
at
least
the
ones
that
go
into
like
signode,
that
many
of
the
features
have
effectively
a
factor,
one
which.
G
A
So
I
know
a
is
working
on
a
refined
template.
Can
the
PM
group,
broadly
as
an
action
item,
work
on
refining
the
features
process
so
that
we
have
a
better
on
going
view
and
then
finding
out
finding
out
and
working
with,
maybe
even
just
building
a
document
around
expectations
for
the
future
owners,
the
future
champions
and
then
the
sig
owners
of
the
features?
A
E
A
I'm
features
specifically
so
having
the
PM
group
come
up
with
what
the
expectations
is
are
around.
Whatever
the
new
of
all
features
repo
template
is,
and
then
we
can
measure
and
making
it
less
broadly,
a
someone
should
do
this
and
more
broadly
or
more
specifically,
you
know,
the
the
sig
champion
or
the
sig
group
will
be
ultimately
responsible
for
this
or
the
champion
of
the
future
will
be
ultimately
responsible
or
you
know,
and
if
this
is
not
updated,
then
we
will
potentially
not
take
you
really.
Whatever
take
your
coat
I.
D
Things
sneak
in
like
yeah
last
second
and
like
it's
cool,
whatever
I,
totally
understand
you're
in
a
difficult
situation.
You
have
a
feature
to
ship
totally
your
your
coolest
week
in
we
shouldn't
do
that.
That's
not
yeah
like.
If
we
sent
hard
rules,
we
should
actually
abide
by
those
everybody
should
abide
by
those.
We
should
all
be
held
accountable,
but
could
we
please
say
what
those
rules
are
so.
G
E
J
Think
I
agree
it
was.
It
was
difficult
to
define
what
those
sticks
are
and
there's
no
real
I
mean
there's
some
Authority
I.
Suppose
I
think
that
the
the
main
things
that
we
have
is,
we
can
say,
hey
from
a
documentation
perspective,
here's
a
deadline,
and
if
you
don't
have
your
pieces
in,
then
you
know
on
going
to
documentation
and
therefore
it
won't
be
easy
for
users
to
discover
the
other
is
I
mean
we
have
a
release
leader
or
czars
or
whatever
it
is
now,
and
so
we
can
say
that
this
won't.
A
I,
don't
think
that
this
is
the
group
to
have
that
conversation.
I
think
the
whole
p.m.
group
should
be
deciding
what
it
is
because,
ultimately,
in
many
of
the
organization's,
the
PM's
are
responsible
for
getting
the
individual
features
into
further
their
corporate
goals.
So
you
guys
have
to
figure
out
some
way
that
you're,
okay
with
as
carrots
and
sticks
and
feature
tracking
and
again,
we
have
to
do
this
as
a
community
as
a
heads
of
agreement
so
that
we
can
all
hold
each
other
to
this
standard,
not
any
one
particular
corporate
way.
He.
I
A
B
D
A
H
J
B
Might
in
a
partner,
can
you
make
sure
that
or
Sarah
department
that
when
that
meeting
happens
and
there's
some
outcomes
from
that
that
we
just
do
a
quick
update
in
the
community
meeting?
Yes,
of
course,
yeah
we
see
what
happened.
Ok,
so
moving
right
along
there,
Brian
gran
had
a
thing
I
pulled
out
from
the
community
meeting
minutes,
essentially
that
we
need
more
concise
templates
and
auto
close
things
that
are
not
filled
in
I
feel
like
that
works
sort
of
started.
But
Aaron
do
you
want
to
speak
to
a
tour.
D
L
Getting
a
notice
that
it
soon
can't
hear
it,
but
the
feedback
that
I've
heard
from
a
number
of
people
is
that
most
of
them
just
delete
the
pr
template,
don't
use
it
at
all,
which
is
problematic
for
a
couple
reasons.
One
is
we
can
use
it
to
set
the
release.
Note
label
automatically.
There's
am
under
that.
Does
that,
but
to
any
information
that
we
want
to
convey
to
people
like
the
contributor
guidelines
are
in
there
there's
a
link
to
that.
There's
a
getting
started
like
a
link
to
getting
started.
L
All
that
just
kind
of
gets
deleted
like
step
one
when
I
open
a
PR
is
delete
that
template,
which
sort
of
means
we
need
to
rework
the
template.
So
as
part
of
contributor
experience,
I
created
a
github
project
to
try
and
track
some
of
these
tasks.
I
just
did
this
yesterday,
I
have
like
learning
how
github
projects
work
and
it's
sort
of
the
scrum
like
methodology
where
you've
got
swim
lanes,
but
I'm
hoping
to
get
someone
to
work
on
that
I
think
we
can
I.
L
That
seems
like
a
reasonable
will
stick
to
me
that
if,
if
you
are
a
member
of
the
org-
and
you
know
that
a
release
note
label
needs
to
be
set-
or
you
know
that
the
pr
template
should
be
filled
out,
if
we
can
detect
that
you
haven't
filled
it
out,
just
close
it
until
you
do
and
I
think
that
can
change
behavior
without
being
too
drastic,
because
it's
not
something
that's
totally
out
of
your
control.
You
just
go
back
and
read
copy
the
template
in
or
you
know,
open
a
new
PR
and
modify
the
template.
L
Yeah
alejandra
suggested
that
yeah
yeah
something
I,
don't
want
it
to
auto
delete.
It
may
be
just
close.
It
yeah
I,
know
I
know,
that's
a
big
disco
Shinto
so
anyway,
those
are
the
thoughts
that
I
had
I
think
it
does
need
to
be
reworked
and
I've
got
a
PR
open
in
I
guess
now.
I
haven't
submitted
it
yet
sorry,
but
I'm
working
on
updating
the
pull
request,
template
and
any
feedback
is,
is
certainly
welcome,
but
I
like
the
idea
of
closing
closing
issues
automatically
that
aren't
routed
correctly.
L
So
if
we've
once
we
decide
on
a
very
clear
and
clean
routing
mechanisms
for
opening
issues,
if
you're
a
you
know,
if
you,
if
we
have
some
indication
that
you
should
know
how
it
should
be
routed,
meaning
it
should
have
an
area,
/
label
or
a
cig
/
label.
And
if
you
have
the
power
to
do
so,
then
we
should
auto
close
the
issue
same
with
tr's.
If
you're
not
using
the
template
correctly,
we
can
have
the
bot
check
like
a
hundred
suggested
and
an
auto
close.
A
Let
me
jump
in
with
aarons
number
of
the
org
thing.
I
recommend
that
everyone
go
read
governing
md
and
comment
on
it
because
we're
working
on
trying
to
define
just
what
that
is.
What
is
a
member
of
the
old?
What
do
you
do
and
get
number
of
your
privileges?
What
are
the
different
roles
in
the
community
so
go?
Take
a
look
at
governing,
but
md.
Could
you
put
a
link?
I?
Yes,
I've
got
three
of
those
now
I.
Don't
you
put
that
in
there
in
just
a
second,
oh
I
see
that
okay.
B
C
Brian
posted
that
we
need
to
create
a
breathing
room
for
leads,
so
they're
not
reviewing
features
all
the
time,
maybe
rate
women
features.
How
do
we
make
this
more
manageable?
My
comment
on
this
is
that
one
of
the
complaints
that
we
got
from
debs
this
release
was
that
code
review
bandwidth
was
limited,
so
some
features
missed
to
feature
complete
deadline,
because
it
can
get
code
reviewed
in
time
that
you've
got
kind
of
these
competing
problems,
one
if
not
having
enough
code
review
bandwidth
other
leads
being
overloaded,
I'm,
not
sure
what
the
right
answer
here
is.
B
Okay,
that
feels
like
a
pretty
serious
issue
just
generally
speaking
about
how
we're
allocating
bandwidth
Sarah.
What
do
you
think
about
maybe
creating
some
sort
of
discussion
session
and
community
about
how
we,
how
we
address
this,
or
is
this
something
that
we
want
to
deal
with
it,
the
leadership
level
and
try
and
brainstorm
or
how?
What's?
What's
your
feelings
on
that
I.
A
I
E
I
I
Sure
so
it
again,
when
going
to
try
and
triage
these
flake
issues-
or
you
know,
as
you
open
by
a
human
or
trying
to
find
out
the
status
of
a
feature
or
get
released,
notes
on
it.
It
would
be
really
helpful
to
have
multiple
channels
of
communication.
I
know
that
you
have
notifications
for
some
class
of
project
members
like
you're
Brian
grant
are
just
not
useful
anymore.
I
A
I
Fallback
message,
I
think
also
going
to
some
of
the
work
that
I'll
see
and
Brian
are
trying
to
do
with
corporate
affiliation.
It
would
be
you
have
that
information,
because
if,
like
you're
not
responsive,
you
can
ask
right
yeah
yeah,
actually
to
someone
in
your
from
your
company
because
features
come
in
our
have
corporate
sponsorship.
So
it's
kind
of
a
little
silly.
B
B
C
It
looks
like
you've
got
a
fairly
lengthy
yeah
I
could
summarize
that
real
quick,
but
just
to
echo
a
lot
of
what
Caleb
was
saying
for
bug
triage.
One
of
the
big
challenges
that
we
had
was
the
identifying.
What
bug
should
be
part
of
the
milestone-
and
we
kind
of
had
no
way
good
way
to
do
that,
because
there's
over
4,000
issues
opened
on
github
for
Cooper
Nettie's,
and
so
we
relied
basically
on
the
community.
C
Hopefully
they
mark
the
appropriate
issue
with
the
1.5
mile
stone
or
if
we
saw
some
flakes
and
CI
we'd
go
in
and
manually,
make
sure
that
they
were
marked
with
1.5
mile
stone,
so
that
process
needs
to
be
improved
to
make
sure
that
the
issues
that
are
supposed
to
be
part
of
the
milestone
are
marked
appropriately.
Once
the
issues
were
marked
with
a
1.5
mile
stone,
we
had
a
fairly
good
mechanism
to
be
able
to
triage
them
as
release
blocking
or
non
release
blocking
by
keeping
track
of
them
with
the
labels.
C
But
the
problem
with
that
was
getting
people
to
take
a
look
at
these
choose.
Issues
that
were
created
by
humans
were
generally
pretty
easy
to
find
people
to
take
a
look
at
and
classify
as
release,
blocker
or
not,
but
issues
that
are
automatically
created.
We're
really
hard
to
find
owners
for,
especially
if
the
issues
were
these
so-called
bucket,
automated
bugs,
which
were
things
like
build
failures
or
many
tests
failed.
C
They
basically
all
get
lumped
into
one
giant
bug
and
you
end
up
seeing
like
a
flurry
of
failures,
and
then
that
goes
away,
and
you
see
another
flurry
of
failures
and
trying
to
get
someone
to
investigate.
That
is
really
really
difficult,
and
this
actually
leads
into
the
last
point,
which
was
in
general.
C
We
need
more
community
involvement
here
as
well
to
help
investigate
debug
in
triage
flaky,
flaky
tests,
I
think.
In
the
end,
it
was
mostly
folks
from
google
that
jumped
on
these
to
basically
move
them
out
of
the
blocking
path.
So
that's
my
TL
DR
on
on
bug
triage
a
lot
of
improvement
needed
there.
I
think.
A
D
C
People's
they
do
so
they're.
The
problem
with
automated
ish
issues
is
that
sometimes
they
uncover
real
issue
so,
like
the
CPU
soft
lock
issue
was
a
random
flake
that
was
ignored
for
a
long
time,
but
when
somebody
done
who's,
awesome
jumped
on
one
of
these
issues
and
started
digging
and
she
realized
wait.
There
is
a
major
issue
here
and
a
bunch
of
these
automated
issues
are
caused
by
the
same
underlying
issue,
and
that
was
something
that
we
then
marked
as
a
release,
block
or
escalated
and
and
fixed.
C
So
they
are
definitely
useful,
but
there
is
a
lot
of
noise,
so
the
signal-to-noise
ratio
is
not
great.
That
needs
to
be
improved.
I
talking
to
the
test
infrastructure.
Folks,
I
think
one
of
their
priorities
is
to
try
to
improve
that
signal.
They're
doing
a
bunch
of
things
like
reducing
the
number
of
large
bucket
bugs
on
so
try
to
tease
those
apart
if
at
all
possible
and
but
there's
still
a
lot
of
improvement
that
needs
to
be
done
in
this
area.
You.
D
Know
I
I
hear
that
I
guess
like
I,
just
I
want
us
to
consider.
If
there
are
other
ways
we
could
have
caught
the
same
thing,
could
we
have
gotten
the
same
signal
elsewhere
because
it
sounds
like
there
is
some
value,
but
it
also
sounds
like
it's
really
high
noise
and
and
triaging
the
noise
down
is
not
just
a
technical
problem.
It's
very
much
a
human
problem.
D
B
C
This
idea
that
was
tossed
around
of
having
cig
owners
for
tests
instead
of
just
individual
owners,
would
be
nice,
and
also
the
having
some
sort
of
person
to
escalate
to
within
each
corporation
would
be
pretty
awesome.
That
way,
folks,
like
Caleb
and
dims,
and
me
who
are
trying
to
go
through
these
bugs
and
trying
to
find
owners,
would
have
someone
to
escalate
to
when
we
don't
get
responses.
At
least
those
are
some
small
steps
that
we
could.
We
can
take
to
help
improve
the
process.
Great.
D
I
I
This
is
where
the
many
of
these
excuse
are
generated
from,
and
you
would
have
can
imagine
that
if
you
had
more
eyes
on
more,
you
know
people
running
the
end-to-end
test
themselves
that
some
of
these
issues
would
be
caught
more
quickly
than
the
slow
p3
p2
to
p1
p0
escalation
path
that
we
have
now
just
relying
on
the
automated
tool,
but
I
think.
Definitely
you
know
the
next
year
think
a
bit
thinking
about
the
human
technic
technological.
You
know
two
sides
of
the
same
problem
coin
I
think
will
be
for
us.
B
There's
at
any
given
point.
There
needs
to
be
some
clear
chain
of
ownership
or
custody
for
everything
that
is
always
accessible
or
whoever
is
responsible
for
it
as
custody
is
accessible
smoke,
maybe
I'm.
We
need
some
sort
of
steel
threat
initiative
to
really
look
at
the
entire
life
cycle
of
a
feature
from
Earth
to
when
it
gets
deprecated
and
assign
some
sort
of
chain
of
custody,
or
something
like
that.
B
D
E
D
E
Obvious
is
that
very
sick
document
again
or
getting
a
real
isn't
given
its
outside
of
Google
that
mostly
powers,
my
my
estate
paste
it
into
this
document.
So
the
general
idea
that
we
we
have
to
define
the
role
team
that
manage
the
release,
so
these
is
mostly
described
in
this
document,
so
we
can
go
ahead
it
in
to
discuss
on
the
document
at
all,
yes,
not
to
duplicate
in
every
item
that
we
have
dispelled
it
ever
has
highlighted,
and
so.
B
C
We
start
the
regular
release
burn
down
which
keeps
track
of
blocking
issues,
and
things
like
that,
but
prior
to
that,
perhaps
it'll
be
useful
to
have
a
maybe
a
weekly
meeting
or
twice
a
week
to
keep
track
of
what
features
are
going
into
the
milestone.
Oh,
how
they're
tracking
and
whether
they're
going
to
make
your
complete
deadline
or
not.
That
way.
We're
not
scrambling
at
the
last
minute
to
figure
out
what
is
and
is
not
part
of
the
release.
Probably
a
question
for
the
PM
team.
C
L
L
C
D
So
basically,
like
I
shouldn't
be
drafting
release,
notes
anymore.
It
should
be
kurban
high
speed
like
basically,
you
should
write
the
release,
notes
for
the
release
and,
if
you're,
not
that,
confident
that
your
feature
is
actually
going
to
ship
by.
Let's
call
it
code
freeze
code
/,
whatever
like:
let's
define
that
data
like
then
it's
not
it
and
use
that
as
the
as
the
stick
I
guess
like
give
them
responsibility,
give
them
power
and
then
let
them
define
what
the
release
is.
C
Now
that
makes
perfect
sense,
like
so
far,
I
think
what
we've
done
every
release
is:
we've
started
to
distribute
the
responsibility
for
various
parts
of
the
release
and
relief
notes.
I
think
is
one
part
that
we
haven't
done
that
yet
yeah
and
you've
been
like
heroically
taking
on
most
of
that
role,
go
to
break
that
down
and
distribute
that
responsibility
makes
perfect
sense
and
and
if
we
can
improve
the
process
to
make
that
happen,
then
let's
do
that.
I
think.
D
I
basically
solicit
collect
refine
edit
as
much
as
I
can
but
I'm
I
guess.
The
point
I'm
trying
to
make
is
from
a
feature
perspective,
the
definition
of
what
the
feature
is
and
why
it
should
matter
to
people
should
be
known
by
product
managers
far
ahead
of
when
code.
It
actually
occurs
right
like
so
developers
definitely
need
to
be
in
the
mix
for
known
issues
and
action
required
and
really
complicated
stuff.
But
to
define
like
why
this
thing
is
the
thing
I
want
to
brag
about
is
not
there's
no
developer
input
required
for
that.
D
So
I
feel
like
really
it's
the
responsibility
of
the
feature,
owners
and
I.
Don't
know,
if
that's
you
know,
crew,
bearnaise
p.m.
or
some
group.
But
let's,
let's
give
that
group
that
responsibility
and
say
by
this
date,
maybe
that's
even
the
feature.
Freeze
date,
like
the
release,
notes
actually
have
to
be
drafted
and
it's
cool
because
we
can
revise
the
release
minutes
later
via
pull
requests
thanks
to
the
process
that
sod
helped
me
put
in
place
right
but
like
it
definitely
has
to
come
from
that
group,
not
from
the
developers.
D
Thing:
I,
don't
look
at
sorry,
I,
look
at
the
spreadsheets
so
like
seriously
like
the
value
proposition,
is
not
a
thing
that
I
should
have
to
comprehend
as
its
release.
Those
writer
right.
It's
totally
something
that
the
group
should
talk
about,
and
collaborate
on
and
come
to
a
consensus.
It's
not
something.
A
single
person
should
just
come
up
with
yeah
I.
J
J
With
you,
I
mean
I
had
the
same
challenge
actually
when
I
write,
for
example,
on
the
launch
blog
post.
It's
the
same
thing
right.
It's
like
the
the
information
is
scattered
in
a
lot
of
different
places
and
actually
the
spreadsheet
the
good
job
of
pulling
it
together
and
I
think
the
process.
It
sounds
like
it's,
maybe
not
working,
but
the
process
has
been
that
are
supposed
to
be
that
the
owners
of
each
of
the
features
are
supposed
to
input.
That
information
starts.
A
Well,
this
is
this:
is
the
refining,
the
futures,
repo
process
and
template
and
expectations,
and
then
writing
up
clear
expectations
of
what
it
takes
to
get
a
feature
from
I
put
it
in
the
future
repo
all
the
way
to
it
is
in
the
release
and
the
release
notes
so
like
what
in
who
has
maybe
because
developers
have
coding
role
but
who
handles
the
release.
Who
defines
the
release,
know
what
are
the
future?
A
Is
the
future
owner
or
can't
remember,
Shepherd
or
champion
going
to
be
the
person
who
is
responsible
to
responsible
for
making
sure
that
you
know
all
of
the
code
like
who
is
responsible
for
what
components
of
this
at
what
point
in
time
in
the
cycle?
So
this
is
what
we
asked
the
PM
group
to
go
through
and
define
and
bring
forward
in
the
discussion
to
the
community.
A
A
after
ye
goes
through
and
does
a
first
pass
on
the
template,
and
you
know
a
bunch,
a
bunch
of
who
is
in
charge
of
what
to
get
a
feature.
Release
is
what
I
think
we
needed
to
point
at
once.
We
have
the
expectations
written
them,
then
we
can
apply
carrots
and
sticks
to
it.
You
say,
if
you
don't
have
this
by
the
state,
your
code
will
be
backed
out
or
whatever
yeah.
E
I'd
like
to
from
my
perspective
recently
different
or
specific
important
part
of
the
measures
like
an
idea,
world
is
a
product
manager,
but
some
personal
sensitive
have
to
define
the
feature
that
they
would
like
to
see
in
these
movies.
They
would
keep
a
track
on
the
on
the
making.
These
teachers
have
any
news,
release
and
they're,
like
mostly
making
and
maintaining
the
wall
release
process.
So
this
is
the
responsibility
of
a
specific
product
management
people
yep.
A
Which
is
roughly
why
I
asked
for
the
process
out
of
the
PM
group
and
then
then
the
wrangling
we
can
figure
out
you
know:
do
we
need
a
feature
manager
for
each
release
that
then
that
person's
role
is
to
track
all
of
what
the
product
managers
and
features
are
handling
for
each
session?
Basically,
we
just
need
more
processor
on
this,
so
it
doesn't
so
that
there
are
reasons
to
think
it
completed,
and
we
know
where
to
look
for
the
information
and
pepper.
B
D
Concrete
asked
would
be
the
release
notes.
Draft
file
that
I
created
for
15
is
something
that
somebody
from
the
Cuban
at
ease
p.m.
group
should
create
for
16.
That's
that's
the
way
that
I
would
state
it
like
it
shouldn't
be
I
mean
maybe
it's
a
release
manager
that
creates
that,
but
maybe
it
could
be
the
decision
of
the
communities
p.m.
prior
to
feature
for
these
two
then
commits
that
file
and
that's
the
checkpoint
that
we
use
to
de
mark
when.
B
A
I'm
gonna
address
caleb
comment
about
conflation
between
project
program
and
products,
and
the
answer
is
we:
we
did
that
intentionally.
We.
We
said
that
the
PM
group
handles
those
components,
and
I
don't
know
how
much
of
program
there
is
in
there,
because
it's
more
project
in
product
that
we
put
together
in
there,
but
that
that
is
something
we
chose
if
it
needs
to
look
different
and
we
need
to
propose
a
something
different.
Oh.
I
H
E
I
M
I
A
B
L
Was
happy
to
just
get
a
thumbs
up
on
that
yeah?
There
seem
to
be
like
a
little
bit
of
come.
A
few
comments
like
is
this:
should
we
have
a
release
candidate,
a
release
candidate
branch
a
week
before
the
actual
release,
and
should
we
make
the
development
cycle
just
a
week?
Longer
I
think
those
were
the
two
things
if
you
could
write
a
comment
on
that,
maybe
in
the
next
couple
days,
so
that
we
could
you
can
finalize
it
if
you
have
a
strong
opinion,
otherwise,
we'll
keep
it,
as
is
yeah.
L
A
Functionally
it's
a
branding
issue,
if
you
say
beta
people
are
like.
Oh,
this
might
might
not
get
out
there,
whereas
if
we
say
release
candidate,
there's
some
sort
of
implied
warranty
that
we're
actually
trying
to
get
it
out
so
I
think
that's
really.
All
we're
talking
about
is
relabeling
roughly
the
same
thing
so
that
more
people
might
be
more
likely
to
test
it.
But
it's
an
unknown.
It's
a
it's!
A
hypothesis
at
this
point.
E
E
This
H
we
can
promote
this
version
of
cabinet
is
to
any
people
who
are
not
perfect
and
musical
skills
of
immediately.
We
can
all
transcendental
zone,
but
people
who
are
riding
black
horse
people
who
I
use
any
communications
and
marketing
activities.
People
who
consume
abilities
for
their
own
products
can
use
this
release.
Candidate
is
the
final
product
of
this
of
this
situation.
F
Before
we
move
past
the
1.6
prepare,
so
just
keep
some
background
on
it.
At
the
cube
development
summit,
it
was
announced
that
there
wasn't
the
1.6
release,
manager
and
Google
was
looking
for
someone
external
to
release
it.
It
was
something
that
was
interested
in,
so
I
put
this
proposal
together,
but
I
be.
Ideally,
I
would
get
clarity
that
I
would
be
that
role
just
before
I
start
doing
a
lot
more
work
on
it.
So
I
own.
F
A
C
So
I
think
a
lot
of
the
test
infrastructure
is
very
Google
centric
and
the
actual
release
cutting
process
is
very
Google.
Centric.
All
other
roles
that
were
defined
in
that
document
can
be
taken
over
by
other
people
and
the
so-called
released
lead
or
manager
whatever
it
doesn't
necessarily
have
to
be
more
as
long
as
those
roles
are
fulfilled
by
Googlers,
so
I
think
it
might
be
worthwhile
as
our
first
community
meeting
in
2017
to
elect
folks.
For
that
all
those
roles.
F
A
It's
just
a
short
discussion
and
yay
dan
volunteered,
there's
a
suspect,
that's
the
way
I
go.
I
don't
I
don't
want
to
get
into
you
now.
We
will
all
vote
here.
My
my
expectations
and
if
we
get
to
a
spot
where
being
release
lead,
is
that
complicated
and
that
desire,
then
we're
gonna
be
in
an
awesome
space
right
now
I
see
this
sort
of
penance.
Thank
you.
Dan
for
volunteering.
B
A
So
I've
got
I've
got
one
point
that
I
would
like
to
make,
and
that's
just
me
being
me
being
taking
this
moment
as
the
organizer
to
choose
the
one
topic
that's
listed
and
last
for
doesn't
mention
release
timing.
Can
we
do
make
an
effort
next
next
time,
and
this
may
just
be
a
note
to
release
team
to
line
up
the
releases
earlier
in
the
day
so
that
we
can
make
sure
we
get
press
and
blog
coverage
and
all
of
that
in
a
rolling
cycle
that
works
better
than
oops?
A
We
didn't
get
it
out
last
night
because
we
didn't
know
you
know
just
it's
going
to
be
more
time
on
a
PR
and
blog
posts
timing.
Even
if
it's
just
an
effort
to
think
about
it.
I
know
we
were
running
up
against
the
soft
block
up
and
trying
trying
trying
to
get
it
out.
So
it
got
out
when
it
did,
but
yeah.
C
C
J
A
M
Here,
can
you
hear
me:
well,
yes,
yeah
great
so
yeah.
That
is
something
that
we
want
to
do
and
like
I
mentioned
into
that
and
the
document,
that's
definitely
the
better
way
to
go
than
to
try
to
shoehorn.
Getting
functionality
get
external
people
to
be
able
to
do
it.
Just
have
the
continuous
thing
that
anybody
can
send
an
ack.
You
know
ankle,
you
know,
people
who
are
in
charge
can
send
an
ax
to
say
yes
release
that
one
is.