►
From YouTube: Kubernetes SIG Contributor Experience 20170823
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).
B
A
A
A
A
I'll
put
you
in
touch,
so
I
can
give
kind
of
an
update
on
what's
going
on
with
this
I've
talked
with
Dan
Cohen
from
the
CN
CF
a
few
times
and
I
think
we
want
to
still
go
through
kind
of
an
evaluation
period
with
Sappho
we're
not
sure
if
that's
100%
the
right
tool.
So
if
you
guys
don't
recall,
there's
a
tool
called
Sappho,
that's
used
for
some
of
the
visualizations
that
we
have
and
whether
that's
the
right
solution
for
what
we're
looking
for
or
velodrome
was
some
question
that
we're
looking
to
get
answered.
A
So
for
a
few
months,
we're
going
to
or
CNF
is
gonna
fund
both
and
so
there's
a
contributor
who
has
worked
on
a
few
other
things.
For
us,
his
name
is
Lucas
something
I
can't
pronounce
and
I
can
link
to
his
PRS
and
he's
working
on
extending
velodrome
to
see
if
he
couldn't
get
some
of
the
metrics
that
we're
looking
for
he's,
also
working
on
using
the
github
archive
to
do
it
and
I
mean
at
the
same
time,
in
parallel,
Sappho
is
working
on
doing
some
of
the
similar
efforts
and
we're
gonna,
compare
and
I.
A
Think
make
a
decision
in
a
few
months,
so
I'll
follow
up
with
Brian
I
started
with
Dan
on
that
we
do
need
to
define
the
metrics,
though.
So
that's
really
on
us
is
to
define
the
what
they're.
Both
tools
are
there
to
help
us
actually
implement
them,
so
we
can
have
help
with
that,
but
I
think
Caleb
and
it
looks
like
to
some
extent.
Aaron
has
the
contributor
ladder
metrics.
Have
you
gotten
a
chance
to
talk
to
the
steering
committee
at
all
Aaron
if
Aaron's
on
there.
A
B
E
My
experience
in
1:7
when
I
was
kind
of
excited
that
we're
gonna
have
a
recording
tool
around
test.
Lakes
cuz
I've
been
a
pain
point
in
1-6,
so
it
kind
of
I,
don't
know
if
it
was
not
useful
like
it
was
kind
of
buggy
and
not
reliable,
so
I
ended
up
just
having
to
do
stuff
manually.
I,
don't
know
if
it's
changed
since
then,
but
my
experience
thus
far
hasn't
been
great.
A
A
E
Mean
I
might
have
just
been
that
when,
when
it's
when
it
needed
to
be
working
reliably
because
I
needed
to
depend
on
it,
it
just
wasn't
there,
and
so
it's
like
it
just
was
just
like
alpha
and
I
needed
to
be
stable
or
something
like
that
not
saying
they
couldn't
get
to
a
good
point,
and
maybe
you
know,
having
a
longer
period
to
shake
out
issues
would
be
worthwhile.
They
yell
I'll
provide
that
feedback
specifically.
E
I
mean
I
wasn't
really
using
it
for
tests
flakes
1:7.
It
was
more
like
trying
to
track
trying
to
kind
of
reduce
the
number
of
open
issues
and
having
reporting
mechanism
to
indicate
like
where
issues
were
and
like
this,
the
the
summary
stats
they
were
providing
were
just
inaccurate.
I
would
go
change
things
and
there
would
be
a
huge
lag
in
some
cases.
Issues
would
never
update,
so
it
was
like
oh,
not
useful
anyway.
Okay,
so
we
need
faster
updates.
Yeah
I
mean
it
needs
to
be.
E
A
Yeah,
that's
hugely
problematic,
all
right,
okay,
good
know
who
forward
to
the
next
one.
The
next
thing
that
we
were
looking
at
was
providing
a
consistent
experience
across
rebo's,
so
the
standard
subset
of
labels
seems
to
be
stuck.
I
am
going
to
just
sit
down
this
the
same
guy
who's
working
on
velodrome,
the
PR
I
think
is
done.
It
needs
a
final
review,
he's
tested
it
and
it
worked.
The
only
thing
that
I'm
gonna
say
is
when
we
roll
this
out.
This
is
going
to
be
something
we're
gonna
roll
out
to
a
couple
of
repositories.
A
I
was
thinking
community
and
test
impress
and
we're
kind
of
involved
in
those
repos,
and
we
can
or
I
can
work
on,
turning
it
off
or
rolling
back
without
too
much
pain,
as
opposed
to
doing
it
across
40
repos.
All
at
once,
and
as
a
reminder,
this
is
getting
a
consistent
subset
of
labels
available
across
all
repos
and
it's
not
gonna,
be
all
the
labels,
but
we're
gonna
start
with,
like
the
cig
labels
and
the
kind
labels,
I
think
and
maybe
the
priority
labels.
A
The
PR
is
in
a
good
state,
like
I
said
it
has
worked
before
we
just
need
a
final
review
in
lg
TM
and
I
think's
fixture
Joe
Finney
from
testing
for
us
said
you
didn't,
have
any
additional
bandwidth
to
review,
so
I'll
try
and
get
on
that
or
if
anyone
else
has
some
been
with
to
review
that
PR
that'd
be
awesome.
It's
lazy
and.
C
A
A
A
A
C
Yeah
so
I
was
on
holiday
last
week,
so
I
wasn't
able
to
really
work
on
that
other
than
executing
the
live
office
hours.
But
it's
the
same
kind
of
structure
there,
so
I'm
planning
on
getting
to
the
actual
live
user
location
and
more
of
a
offline
office
hours.
So
right
now,
I'm
calling
office
hours
like
the
livestream
and
then
the
hey.
Let's
organize
people
in
kubernetes
users,
so
I'm
gonna
split
that
to
be
obviously
separate
things.
But
I
just
did
a
live
stream
this
morning
and
we
learned
a
bunch.
I've
got
a
ton
of
notes.
C
I'll
put
the
links
in
on
what
we
need
to
do
to
make
that
better.
We
had
about
50
people
show
up,
so
that
was
pretty
cool
new
support
from
the
developer
side,
so
I
felt
that
it
was.
It
was
a
value.
We
should
definitely
run
it
every
two
weeks
so
over
the
next.
Between
now
and
our
next
contributes
meeting
I
plan
on
starting
the
actual
users
for
rotation
and
the
slack
focused
on
office
hours,
I
guess
whatever
we
want
to
call
I,
don't
know
if
we
should
call
it
that
or
we've.
A
C
So
there
was
this:
there's
this
document
on
the
github
community,
section
called
user
support,
rotation
and
I
guess
what
that
is.
Is
it
was
like
a
little
chart
of
when
people
would
be
responsible
for
monitoring,
Stack,
Overflow
questions
and
a
slack
Channel
and
whatnot
and
I
guess
that
came
from
like
an
internal
Google
document
from
back
in
the
day,
I
don't
know
I,
guess
people
who
are
assigned
so
the
idea
was,
is
like
hey.
C
Can
we
expand
that
to
be
more
community
focus
so
that
people
can
just
say
hey
I'm
available
for
one
hour
week?
What
do
I
do
right
so
things
like
we're
to
look
for
questions,
how
to
do
proper
support?
You
know
here,
reusable
templates,
you
can
use.
You
know,
here's
the
links
of
the
docs,
how
you
link
to
the
right
things
correctly.
C
I
started
streaming
to
where,
like
the
community
meeting
streams
to
instead
of
this
this
thing,
so
we
had
a
whole
bunch
of
people
mobilize
and
go
to
that
and
then
to
tell
people
to
come
to
the
right
thing
and
then
so
the
first
10
minutes
are
up,
but
once
we
got
going,
it
felt
really
good
people
were
asking
the
right
questions.
We
were
able
to
determine
scuzz.
Some
questions
are
like
hey
man.
I
can't
ask
this
agent.
C
Do
your
stuff
check
IP
table
like
you
know
there,
but
so
people
started
to
ask
kind
of
more
generic
hey.
What's
what's
what's
that
sort
of
thing,
so
we
were
able
to
kind
of
steer
it
in
the
right
direction.
So
Ilya
and
I
are
definitely
gonna
do
another
one
in
two
weeks,
so
we
got
just
the
right
amount
of
feedback
we
needed
and
all
the
feedback
we
got
is
something
we
can
fix.
So
you
know
checking
people's
microphones
ahead
of
time,
silly
things
like
that
that
we
just
had
to
codify.
C
A
Alright,
then,
the
last
thing
that
we
have
for
our
goal
was
the
support,
the
release,
team
and
Maura.
You
might
be
familiar
with
this
as
well.
This
came
from
Don
for
one
from
1:7.
It
was
lets
do
with
that
approved
for
milestone
label
and
the
whole
policy
around
automatically
generating
released,
notes
that
are
organized
by
sig
by
component
by
issue
and
then,
finally,
by
PR.
So
there's
some
kind
of
hierarchy
and
there's
not
400-plus.
A
A
Hours
just
duping
and
organizing
release
notes,
there's
some
work
being
done
there.
Specifically,
there
are
two
new
employees
that
join
the
google
kubernetes.
The
the
effort
from
Google
and
kubernetes
and
they're
gonna
be
focused
on
on
that
for
the
first
few
weeks
at
least
so
there
are,
there
are
people
working
on
it
and
you'll
probably
see
some
PRS
going
in
there
in
the
release
infrastructure
area
working
with
the
tool
that
currently
automatically
generates
the
release,
notes
and
they're
gonna
try
and
follow
Don's
proposal.
A
The
the
other
thing
that
we
need
to
work
on
is
the
approved
from
milestone
label,
so
that
was
part
of
Don's
proposal,
as
well
as
having
SIG's
accept
issues
as
a
proof
from
milestones
so
that
we
have
a
really
clear
signal
of
how
healthy
the
milestone
is
or
how
healthy
the
release
is,
and
currently
only
people
with
write
access
can
add
that
label.
So
we
need
to
get
some
work
done.
A
Need
some
automation
that
allows
people
to
add
a
proof
or
milestone
and
it
needs
to
be
tied
to
sig
leads
and
as
far
as
I
know,
there
are
no
label
adding
privileges
associated
with
sig
leads
right
now,
so
how
we
do
that
is
going
to
be
something
we
have
to
define.
I
had
an
idea
for
it
which
I
talk
tomorrow
about
using
the
owners,
alias
file
and
having
a
sig
leads,
but
prowl
does
not
read
the
owners
alias
so
there's
some.
A
E
D
Yeah,
it
also
loved
it
and
learn
more
about
it.
Is
there
any
reason
why
we
wouldn't
expand
the
list
of
people
who
could
fly
the
label
to
the
approvers
first
sig,
rather
than
just
the
sig
leads
since
for
I?
Guess,
I,
don't
think
we're
gentlemen
operating
under
the
assumption
that
sig
leadership
is
like
a
TL
room
more
like
a
believer
like
a
reaching
consensus
on
that's
a
facilitation
yeah.
B
E
The
that
just
needs
to
be
some
restriction
on
who
can
add
that
label
because,
during
especially
during
code,
slash
code,
freeze,
there's
lots
of
cases
where
someone
who's
in
a
saying
and
it
is
an
approver-
is
adding
improved
to
milestone
because
they
think
it's
important.
But
there's
no
oversight.
There's
no
communication
and
that
really
slows
down
cutting
of
like
getting
a
release
table.
So.
A
E
I
mean
I
think
it
should
be
easier
than
the
owners
file,
because
we're
not
talking
specific
about
code
ownership,
we're
just
saying
within
a
sake
who
has
responsibility
for
having
oversight
over
things
that
are
like.
You
know,
milestone
I,
think
that
should
just
that
can
be
a
small
subset
of
people.
It
doesn't
have
to
be
just
the
sig
leads,
but
the
idea
is
just
people
who
know
that
when
you're
adding
something
to
the
milestone,
especially
during
codes
closure
code
freeze,
you
have
to
communicate
that
you
can't
just
this
is
my
pet
issue.
E
A
Okay,
so
maybe
I'll
get
a
I'll,
take
it
as
an
action
item
for
myself
or
George.
Can
you
read
this
down
to
the
first
pass?
P
are
done
that
adds
that
owners
alias
like
a
cig
leads
owners,
alias
and
I'll.
Just
Auto
generate
it
from
the
60ml
file
in
community,
and
then
we
can
show
that
PR
tomorrow,
Sara
or
whoever's
leading
the
community
meeting.
If
any
of
you
are
there,
maybe
we
can
do
this
during
the
release.
A
E
B
C
And
then
just
PM
me,
the
the
PR
and
I'll
make
sure
it
gets
added
to
the
agenda
for
the
the
update
for
the
release.
Okay,
and
just
just
for
my
edification.
What
is
the
proper
lifecycle
around
the
peripheral
milestone
label?
I
mean
what
is
what
is
the?
What
is
the
actual
use
case
intended,
because
I
have
an
idea
that
I
want
to
make
sure
that
my
assumptions
are
right.
E
Yeah
you're,
probably
the
best
one
to
talk
about
it.
Specifics
I
was
assuming.
It
was
just
during
code,
freeze
code
slush
to
sort
of
make
sure
that
we,
when
issues
are
added
to
the
milestone
we
sort
of
had
an
indication
of
whether
sig
has
had
a
chance
to
review
and
indicate
that
this,
indeed,
should
be
in
the
milestone.
But
I
mean
some
of
the
notes
here
suggest
that
maybe
it's
should
be
doing
the
entire
development
cycle.
E
A
Think
we
should
start
with
the
former
which
is
enforced
this
during
code
freeze
and
kind
of
see
where
it
goes
from
there
we're
defining
what
it's
used
for.
J
stands
to
your
question
and
what
I
think
we've
agreed
on
or
what
I've
heard
spoken.
The
most
is
that,
during
during
bird
down
it's
difficult
to
get
a
signal
of
how
healthy
the
release
is
going
to
be
and
having
sig
leas
clearly
say:
I
own.
This
will
help
us
do
that,
so
just
ordering
burndown
for
now
so.
E
C
A
C
Week
no
I
wasn't
I,
wasn't
here
last
week,
I
reached
out
to
the
person
who
did
this
at
at
the
golang
events
and
I
was
like
hey.
Do
you
mind
if
we
totally
rip
off
this
idea
and
he
was
like
absolutely
let
me
know
what
you
need
so
I'm
gonna
reach
out
to
him.
As
far
as
getting
that
leaders
leaderboard
that
he
had
set
up
a
father
link,
it
has
a
link
to
how
they
set
it
up.
C
A
A
A
C
D
C
D
A
So
this
was
the
big
one.
I
don't
know
if
anyone's
followed
the
thread
on
kubernetes
dev,
but
there's
some
concern
about
the
approvers
and
reviewers
mechanism.
A
while
ago,
the
policy
changed
from
using
the
owners
files
reviewers
for
LG
TM
to
anyone
in
the
org
canal
GTM,
and
this
was
sort
of
a
byproduct
of
a
couple
PRS
that
went
in
pretty
quickly
and
the
goal
I
think
was
to
improve
project
velocity.
We
never
really
discussed
it
too
much.
So
there's
a
few
things
that
have
happened
in
response.
A
This
started
by
the
way
in
response
to
a
thread
from
Steve,
Kuznetsov,
I,
think
red
hat
on
implicit
self
approval,
and
the
idea
is
anyone
in
the
org
can
write
LG
TM
and
if
an
author
isn't
an
owner's
file
and
they
implicitly
approve
their
PRS
getting
in
even
if
it's
kind
of
a
work
in
progress.
So
a
few
things
happen.
One
we've
got
work
in
progress.
A
Steve,
okay
and
the
idea
is,
it
won't
merge
pr's
that
have
work
in
progress
in
the
title,
but
the
other
thing
that
came
out
of
that
was
like
I
said:
should
we
revert
back
to
the
old
policy
where
reviewers
actually
amend
something
more
than
right?
Now
our
viewers
are
solely
being
used
for
assigning
pr's
out
for
review.
So
if
a
new
PR
is
created
and
it's
unassigned,
the
blunderbuss
Lunger
in
lunge
github
looks
at
reviewers,
looks
at
all
the
owners
files
and
it
assigns
weights
to
various
owners
based
on
something
it
might
be.
A
E
Is
I've
never
really
understood
this
I
mean
in
my
mind
you
have
you,
have
code
owners
and
any
code
going
in
the
tree
should
have
at
least
one
person
looking
at
I.
Just
to
make
sure
that
you
know
it's
not
completely
crazy,
we're
all
human
right,
but
I
mean.
Why?
Is
there
a
difference
between
approve
and
LG
TM
sure.
A
That's
a
good
question:
this
is
the
first
project
that
I
worked
on.
So
the
idea
is
that,
as
we
grow
the
project,
we
want
to
grow
leadership
and
we
want
two
kinds
of
we
want
people
that
are
really
familiar
with
the
code
to
obviously
be
looking
at
just
about
everything
before
they
go
before
it
goes
in.
A
But
as
the
project
grows,
they're
not
gonna
have
the
ability
to
give
everything
thorough
review,
which
is
like
making
sure
that
everything
matches
the
style
guidelines,
making
sure
that
the
codes
well
tested
so
LG
TM
should
be
coming
from
someone
who's
done.
A
thorough,
a
review
to
review
of
the
code.
Approval
is
more
of
a
high-level.
A
A
So
it's
more
like
a
high-level
stamp
of
approval
and
people
in
the
approvers
file
have
generally
been
on
the
project
for
a
very
long
time
have
committed
a
lot
of
code
or
a
lot
of
the
design
at
the
very
least,
and
are
very
familiar
so
they're
the
stamp
of
approval
where's,
the
other
ones
more,
like
a
long,
thorough
review.
Does
that
make
sense.
B
E
I
mean
I,
guess
I'm
used
to
gerrae.
This
is
Garrett's
plus
two
yeah,
so
you
have,
you
know,
prove
er
is
a
+
2
+
a
+
1
is
basically
it
could
be.
Just
an
you
know:
a
newer
viewer
who's
indicating
that
they
think
it's
good
I
mean
it's
a
way
of
sort
of
building
your
reputation
that
you're
actually
reviewing
or
it
could
be
a
subject
matter
expert
who
doesn't
have
approval
rights,
but
it's
still
like
for
a
given
specialty
thing.
E
You
need
some,
you
need
this
person
to
review
and
if
they
give
a
plus
one,
that's
essentially
like
they're
approving
so
the
LG
team
I
mean
I.
It
makes
sense
that
you
have,
you
know
improving
LG
TM,
but
like
I'm,
not
sure
that
it's
clear,
like
I,
think
there's
a
process
of
Education,
because
the
tooling
doesn't
really
make
it
explicit.
What's
going
on,
which
I
think
is
problematic.
F
E
E
Minus
one
so
there's
like
there's
more
signal
and
github,
it's
kind
of
like
you
have,
you
can
say:
I
want
changes
which
is
the
equivalent
of
like
a
1-2
thing
and
you
can
approve.
But
you
have
to
do
that
through
comments,
and
so
it's
like
it's
just
this
bifurcated
like
indication
of
what's
a
to
PR,
is
in
which
I
think
is
problematic.
I,
don't
know
how
to
fix
that
be
honest,
but
I'm,
just
pointing
out
the
obvious.
E
C
E
C
E
A
E
I
mean
there's
a
there's,
a
section
below
github
concerns
and
suggestions
and
I'm
I
guess
I
would
hope
that
we
could
given
that
were
what
the
biggest
github
project
by
far
that
we
could
hopefully
provide
feedback
and
drive
change
any
UI
so
that
we
don't
have
to
maintain
special-purpose
stuff
on
our
side.
If
possible.
I
don't
know,
may
not
make
sense,
because,
like
the
approvers
mechanism,
like
owners
and
all
that,
that's
not
really
github
be
no.
E
A
E
Was
just
thinking
that
like
what
what
maybe
what
we
could
talk
to
them
about
doing
is
providing
like
a
consistent
machine?
We
could
drive
with
an
API,
so
it
doesn't
necessarily
just
have
to
be
in
response
to
you
know.
I
requested,
you
know
changes,
but
it
could
be
like
okay.
My
boss
says
that
this
person
has
approval
right,
so
go
change
that
state
machine
that
make
sense.
Yeah,
I.
B
Think
it's
worthless
re-engaging
with
github,
I
and
I.
Think
somebody's
took
that
as
an
action
item,
because
we
tried
a
year
year
and
a
half
ago
and
didn't
get
very
far
with
our
requested
changes,
but
I
think
in
the
same
way
that
we
are
suddenly
getting
a
pile
more
attention
everywhere
we
might
get
a
pile
more
attention.
It
could
help
yeah.