►
From YouTube: Kubernetes Contributor Experience SIG 20180321
Description
We meet every Wednesday to discuss Kubernetes Contributor Experience projects. Join us!
https://github.com/kubernetes/community/tree/master/sig-contributor-experience
A
A
We
have
a
very
light
schedule
today,
so
feel
free
to
also
pop
some
items
on
the
agenda,
or
we
can
obviously
have
free
conversation
or
let
us
out
early
and
for
those
that
are
on
the
call,
if
you
don't
mind
putting
your
name
in
the
attendee
information,
that
would
be
awesome
just
so
we
can
keep
track
of
that
as
well.
So
we
know
where
conversations
are
starting
and
stopping
the
first
thing.
We
always
do
at
our
meetings
as
handle
reoccurring
items
that
are
less
than
at
the
top
of
the
agenda.
A
C
B
A
D
A
Very
cool
welcome
and
then,
let's
see
we
do
have
hosts
I
believe
this
week
for
the
community
meeting.
For
those
that
don't
know,
we
have
a
weekly
kubernetes
community
meeting
that
happens
every
Thursday
at
10:00
a.m.
in
this
group.
We
just
make
sure
that
everything
for
that
meeting
is
running
smoothly
and
on
schedule.
A
E
A
All
right
well
reach
out.
If
you
need
anything
at
all
and
they
can
help
me
okay
and
then
we
typically
do
do
a
graph
of
the
week.
Sometimes
we
do
sometimes
we
don't
and
for
those
I
don't
know
a
graph
of
the
week
is
its
dev
stats
and
done.
Stats
is
a
product
of
the
CNCs
and
that's
a
list
of
several
several
dashboards
that
we
use
to
collect
metrics
on
the
health,
velocity
and
many
other
items
of
the
project.
Josh
I.
Remember
you
wanted
to
do
one.
Are
you
up
this
week.
A
Cool
all
right
so
worried
we
will
go
ahead
and
skip
the
graph
this
week,
if
I
can
think
of
a
graph
to
show
then
I'll
just
jump
in,
but
we'll
go
ahead
and
skip
so
Chris
short
just
make
note
make
a
mental
note
that
when
you
get
into
the
dock
on
Thursday
that,
if
there's
nothing
in
there,
then
we'll
just
take
it
out.
Okay,
all
right
and
then
the
next
item
of
business
is
outreach
for
meet
our
contributors
in
office
hours.
A
George
is
actually
on
the
west
coast
this
week,
so
he
couldn't
be
with
us
for
this
meeting,
but
he
did
kick
off
office
hours
this
morning
and
heard
that
was
very
successful.
Meet
our
contributors
is
another
version
of
that
except
its
contributor.
These
questions
we're
office
hours
is
these.
Are
these
questions
we're
always
looking
for
new
folks
for
that?
A
So
I
have
the
first
item
on
the
agenda
is:
are
there
any
open,
automation
or
workflow
issues
that
we
need
to
discuss
on
today's
call
better
immediate?
It
looks
like
print.
It
looks
like
first
of
all,
if
you
actually
put
one
for
bot
configuration
change
for
K
community,
do
you
want
to
talk
about
that
and
explain
it
a
little
bit
in
case
people
haven't
read
their
mailing
list
yet.
G
Those
one
proposed
change.
The
other
proposed
change
was
changing.
The
merge
method
in
community
from
the
default,
which
is
the
bot,
will
click
the
merge
button,
like
the
equivalent
of
a
github
merge
button
which
creates
a
merge
commit
which
retains
the
full
commit
history
in
the
PR.
The
difference
here
would
be.
It
will
squash
all
the
commits
in
the
PR
into
one
and
the
bot
will
generate
that
commit
at
the
head
of
of
the
repository.
G
A
A
A
A
A
So
yes,
I'm
a
fan
of
that
I'm.
Also
a
fan
of
explicitly
approving
a
guide,
explicitly
approving
your
PR,
because
right
now,
currently
I
do
have
the
rights
in
K
community
to
to
just
be
the
PR
author,
who
naturally
gets
approved,
but
I'm
really
looking
for
consensus
on
a
lot
of
the
things
that
I'm
putting
in
and
also
feedback.
A
So
when
it
comes
up
as
approved
I
think
I've
gone
to
Christoph
so
many
times
so
I
told
my
gosh
make
it
stop
like
how
do
I
do
this
and
you
know
eventually
get
to
the
approved,
cancel
piece.
I
just
feel
like
more
times
than
not.
Most
people
want
a
second
glance
and
a
second
review
and
that's
the
practice
that
we
should
be
in
preaching
and
I.
A
Think
Tim
pepper
actually
brought
that
point
up
on
the
mailing
list,
as
well
as
it's
good
practice
and
not
just
practice,
but
it's
good
practice
period
and
it
looks
like
Chris
short
plus
one
as
well.
I
mean
at
the
thing
is
I.
Think
most
of
the
people
in
contributor
experience
are
gonna
plus-one,
you
Kristoff
its
I
think
everybody
else
that
we
need
to
listen
to.
But
at
the
same
time,
if
we're
testing
that's
only
in
cake
community,
then
maybe
we
should
just
go
ahead
with
it.
Cuz
I,
don't
think.
A
G
Yeah
on
the
approved
piece,
I
kind
of
I
kind
of
want
a
canary
job,
because
everybody
currently
I
would
say
most
experienced
contributors.
The
project
understand
how
approve
works,
and
most
people
expect
that
if
they
have
approved
rights
that
it
will
implicitly
approve
them
as
a
PR
author,
this
would
be
more
kind
of
experiment.
To
see
like
is
the
opposite.
Can
we
train
people
on
the
office
at
work
flow
and
is
that
opposite
work
flow
better,
at
least
with
paid
community
is
a
kind
of
smaller
subset.
G
We
are
disrupting,
like
could
coop
the
kubernetes
core
repo,
which
will
be
the
one
where
we
have
like
the
most
adjustment
period,
because
that
one's
had
the
approval
plug-in
for
the
longest
on
the
squash
bit.
The
thing
that
I'm
kind
of
leaning
towards
Ryan
hitch
men
from
Sig
testing
had
mentioned
yesterday
that
maybe
there's
a
way
to
say
on,
like
a
/
PR
basis,
whether
it
needs
a
squash.
Because
then,
if
there
is
like
an
intent
inside
the
PRS
commit
history,
we
can
retain
that
most
of
the
time.
G
But
if
it's,
the
big
situations
would
be
like
new
committers
or
committers
that
are
using
things,
went
to
github
UI,
where
it's
more
difficult
to
pull
down
and
then
squash
your
commits
manually,
because
github
doesn't
offer
that
as
a
PR
author,
an
option
of
just
going
squash,
there
might
be
a
way
to
kind
of
expand
the
bought
command
side
to
say
on
PR
on
an
individual
PR
basis.
Hey
this
PR
I
want
to
squash,
but
the
majority
of
them
retain
the
people
of
the
PRS,
commit
history.
G
H
Well,
I
was
just
well
first
of
all,
agreed
I.
Think
the
we
were
saying
Christophe
was
a
great
suggestion.
I
was
like
having
select
ability
because
yeah
I
definitely
I've
encounter
situations
where
you
know
certain
times
like
you
know,
the
PR
is
good,
but
I
want
it
to
be
squashed
and
I.
Don't
necessarily
want
to
wait
some
interpreter
cycles,
or
maybe
you
know
it's
a
new
contributor
they
might
just
vanish,
which
is
problematic.
H
I
was
gonna,
say
with
respect
to
the
approval,
stuff,
I
think
one
one
reason
possibly
you're
getting
some
pushback
to
this.
Also
is
that
at
least
inside
Google,
which
is
kind
of
where
some
of
the
owners
stuff
is
based
on,
we
use.
Basically,
we
I
think
implicit
self
approval
is
the
norm
there,
so
sort
of
having
a
different
workflow
for
at
least
for
Google
developers
might
be
one
point.
That's
a
little
different.
That's
not
necessarily
a
reason
not
to
do
it.
That's
at
least
possibly
one
source
of
some
of
the
disagreement.
H
It's
just
because
it's
different
than
the
way
it
works
inside
Google's,
that's
kind
of
what
we're
used
to
the
other
thing
is
I.
Think
I.
Think
one
of
the
motivations
I
think
as
Paris
was
saying,
is
that
you
know
we
want
to
have
a
way
to
sort
of
indicate
that
more
people
should
look
at
something
review,
something
but
I'm,
not
sure
like
I.
H
Think
that's
still
one
thing,
that's
not
entirely
clear
is
like
it's
not
clear
if
I
remove
approval
from
my
own
self
approval
like
how
am
I
supposed
to
indicate
that,
like
I,
want
more
people
to
look
at
or
like
you
know,
how
do
we
indicate
that
I
want
to
have
a
consensus
around
this?
Is
it
just
comment,
or
is
there
something
in
the
infrastructure?
That
kind
of
indicates
that
you
know
we're
doing
this
because
I
want
to
get
make
sure
that
you
know
some
number
of
people
actually
approve.
H
B
Strongly
disagree
with
the
idea
of
self
approval
anyway,
like
the
entire
purpose
of
code
review,
is
that
you
make
mistakes
and
you're
blind
to
your
own
mistakes,
and
you
know
other
the
you
know,
leaders
and
the
you
know
for
that.
Repository
should
review
that
and
make
sure
it's
correct,
I
mean
I've
I,
don't
have
a
lot
of
contributions,
but
I've
had
contributions.
Merge
that
you
know
I
haven't
wanted
to
go
in
because
of
you
know
kind
of
a
lacks
review
process.
B
F
The
other
thing
is
when
this
came
up
in
community
meeting
before
some
of
the
people
who
are
asking
for
a
change
specifically.
What
they
wanted
to
change
was
the
implicit
self
approval,
because
they
said,
hey
I
put
something
up
here
as
a
trial
balloon
you
know,
saying
hey
what,
if
we
did
things
this
way,
and
you
know,
and
because
I'm
an
owner
was
automatically
approved
the
as
long
as
we
have
self
approval,
it
makes
it
very
awkward
to
actually
use
PRS
in
that
way
as
a
way
of
proposing
an
alternative
approach
for
something.
G
And
there's
there's
a
different
one
like
a
number
of
different
patterns
we
could
possibly
use
here.
I
know
like
in
the
test
info
repo.
A
very
common
pattern
is
using
the
hold
command
like
if
the
if
the
reviewer
was
to
say,
like
this
looks
good
to
me,
but
allow
the
owner
to
leave
the
PR
author
to
have
more
say
on
it.
They'll
put
a
hold
on
it,
so
it
won't
automatically
merge.
G
That's
this
one
pattern,
there's
also
just
withholding
LG
TM
right
now.
Anybody
who's,
an
ordered
member
can
lgt
m
any
PR
in
any
repo
across
the
org,
which
that
was
also
a
discussion
point
that
came
up
is
like.
Is
that
what
we
want
like?
Do?
We
have
a
problem
with
drive
by
LG
TMS
from
people
who
may
not
necessarily
know
or
understand
whether
they
have
the
experience
to
properly
code
review,
something
because
LDL
GTM
is
supposed
to
be.
That's
the
in
depth.
Code
review
like
that
was
the
original
intent.
G
If
LG
TM
is
post,
video
and
depth
code
review
where,
as
approve
the
inn,
hence
as
I
understand
it
is
this-
is
the
code
owners
for
the
files
that
own
this
code
have
said.
The
like
the
overall
idea
and
design
are
okay,
but
the
approvers.
Don't
necessarily
do
the
in
depth
code
review,
but
you
know
again
with
these
differ
ways
of
handling
it.
G
I
think
Italy
at
the
very
least,
switching
off
the
implicit
self
approval
and
moving
to
an
explicit
approval,
whether
it's
a
self
approval
or
not,
I
think
at
least
at
least
we
can
understand
intent
there.
It's
a
PR
author
says:
hey
slash,
approved
I
am
confident
enough
in
this
code,
but
I
am
going
to
self
approve
it.
As
a
coke
code,
owner
they're
still
going
to
be
a
review
process
because
you
can't
sell
LG
TM,
that's
the
one
of
the
only
restrictions
on
LG
TM,
and
you
can't
do
it
yourself.
A
A
G
I
think
it
is
I
think
it
is
a
bit
of
a
bigger
change
like
I'm,
not
I'm,
not
I.
You
know
tied
to
what
we
have
today,
because
it's
what
we
have
today
I
know
that
doing
something
like
that
would
be
a
much
bigger
workflow
change
for
a
lot
of
developers,
and
it
would
definitely
definitely
have
like
a
larger
day-to-day
impact.
With
you
know,
new
commands
and
new
workflow
from
the
get-go,
maybe
like
I,
would
I'd
be
open
to
is
maybe
maybe,
if
we
run
this
like
the
implicit
approved
experiments.
G
If
we
run
this
for
30
days
in
community
and
see
how
it
works,
how
you
know
do
people
do
people
get
that
they
need
to
if
they
are
a
PR
author
and
they
do
want
to
sell
to
prove
that
they
need
to
add
the
command
in
see
how
people
take
to
that.
If
we
get
a
ton
of
pushback
to
changing
the
workflow
once
it's
once
the
workflows
actually
in
place,
then
I
would
be
I'd,
be
more
cautious
about
more
radical
changes
to
workflow.
But
if
that
works,
then
maybe
I'd
be
open
to
talking
about
okay.
G
What
if
we
were
to
remove
the
concepts
of,
but
what
we
have
today
take
like
say
for
a
second
that
that
doesn't
matter
what
we
have
today?
What
would
the
ideal
workflow
be
as
far
as
reviewing
approving
and
merging
PRS?
Maybe
maybe
a
more
radical
workflow
would
end
up
working
better,
and
maybe
we
can
advertise
that
around
like
hey.
C
C
H
B
Actually,
like
it
a
lot
because
the
meanings
of
those
things
are
all
very
clear
that
it
that
it,
you
know
it's
clear
who
that
people
who
can
merge
are
because,
because
of
the
the
plus
to
minus,
you
know
minus
2,
and
it
also
separates
that
that
process
from
from
the
actual,
you
know
saying
that
you
want
a
patch
to
merge,
and
so
you
know
you
could
have
several
owners
I'll
give
plus
twos.
But
you
know
you
know
if,
if
it's
it's
the
people
don't
want
it
to
merge.
B
They
don't
know
they
don't.
Like
approve.
Ursa
looks
good
to
me.
You
know
there.
There
are
they're
a
very
deep
cultural
significance.
You
know
signifiers
behind
those
and
they
vary
from
repository
to
repository
and
it's
it's
not
clear,
what's
happening
where,
if
you
just
say
that,
like
workflow
plus
one
means
that
the
workflow
process
starts,
you
know
that's
very
clear
and
it's
unambiguous
and
it's
consistent.
So
I
know
that
I
know
that
this
is
kind
of
a.
We
can
also
talk
about
vim
versus
Emacs
as
our
next
topic.
A
Yeah
I
think
everybody
I
mean
we
just
went
through
the
whole.
What
does
LG
TM
mean
to
you
really
experiment
and
came
up
with
quite
a
few
different
definitions.
There
alone,
so
I
mean
I'm
all
in
favor
of
anything.
That
will
take
the
any
ambiguity
out
of
what
certain
words
mean,
including
making
up
our
own
words.
B
C
A
C
A
C
A
C
A
G
A
A
Last
week,
we
had
a
discussion.
An
engineer
came
on
the
line
and
talked
about
oh
I'm,
losing
my
train
of
thought,
already
read
Me's
and
get
that
there
should
be
a
reading
readme
for
every
owners
file
to
help
with
like
the
what
is
this
code,
and
why
should
we
care
and
really
helps
with
troubleshooting
users
and
things
like
that
and
Christoph
I
know
you
had
some
thoughts
and
I
believe
our
next
steps
were
to
talk
about
those
thoughts
and
also
discuss
our
next
steps
and
I.
G
Well,
I
think
the
takeaway
from
last
meetings
we're
going
to
kind
of
look
over
those
and
then
and
then
take
a
big
architecture
which
I
think
is
still
the
right
way
forward.
I
just,
unfortunately,
have
not
had
time
to
to
dig
through
Thomas's
notes
from
from
last
week,
so
yeah
I,
like
I
I'm,
going
to
do
that
myself.
G
If
anybody
else
you
know
wants
to
dig
through
them
as
well
and
and-
and
you
know,
pull
out
anything-
that's
important
I
think
probably
I
may
just
start
a
discussion
on
a
mailing
list
about
it
like,
so
that
we
have
a
thread
on
this
topic
and
that
we
can
then
carry
that
thread
over
to
Sagarika
tech
chure,
like
hey
sig
architecture.
Can
you
like
take
a
look
at
this?
This
particular
thread
on
the
on
the
west
and
tell
us
what
you
think
like?
Is
this
something
that
is
sustainable
or
workable
for
for
kubernetes?
G
A
So
it's
like
how
would
where,
and
why
do
we
start
so
I
mean
play
it's
Christoph
mentioned.
We
were
thinking
that
we
would
take
this
to
save
architecture
and
discuss
kind
of
like
how
we
could
improve
in
this
area.
There
were
several
people
in
the
last
call.
That
said,
why
don't
we
kind
of
mandate
this
and
that,
like
M
word,
scares
me
a
little
bit
and
that's
why
I
would
like
as
soon
as
someone
says,
the
M
word
I'm,
like.
A
H
B
A
All
right,
all
right,
so
the
only
other
thing
that
I
had
on
the
agenda
today
is
the
bunny
program,
and
that
has
to
do
with
mentoring.
The
buddy
program
for
folks
that
don't
know,
is
an
idea
that
was
actually
born
from
gopher
con
and
it
was
it's
very
specific
to
their
events,
and
so
what
they're
ideally
doing
is
pairing
experienced
gopher,
Con
attendees
up
with
non-experience
gopher
Con
attendees,
because
the
experience
like
you
know
for
I
mean
even
for
folks
that
go
to
puke
on
for
the
first
time
can
be
pretty
daunting.
A
There's
a
lot
of
activities.
People
don't
necessarily
know
like
the
best
things
if
they
should
go
to
so
these
kind
of
mentors
get
matched
with
them
and
like
help
them
throughout
the
event
and
like
give
them
advice
on
what
they
should
do,
but
then
they
also
have
like
a
one-hour
breakfast.
Where
they
said
talk
about,
you
know,
life
and
all
things
go
so
I
was
actually
thinking.
We
could
take
that
further
and
do
a
very
similar
thing
for
kubernetes
and
do
one-on-one
matching,
but
there's
a
there's,
a
cat,
but
there's
a
button
here.
A
It
is
a
one-time
one-hour
session,
so
it's
very
much
like
meet
our
contributors
where
we
have
a
bunch
of
contributors
on
the
line
and
it's
an
ask
us
anything
for
for
an
hour.
But
it's
a
very
tailored
one
hour,
one
person
session
and
you
can
do
anything
you
want
with
that
one
hour.
So
you
can't
repair
program
with
the
person
and
you
can
do
code
reviews,
and
this
is
a
person
that
you
probably
wouldn't
be
able
to
have
that
kind
of
one
hour.
A
A
A
So
wolf
and
I'm
gonna
send
that
out
to
the
K
dead
list
shortly
and
the
reason
why
we're
voting
is
because
I've
talked
to
three
different
marketing
professionals
and
also
myself
and
many
of
you
about
what
we
should
name
kubernetes
mentors
and
everyone
kind
of
like
we're
out
of
greek
words.
But
guess
what
the
the
Greek
word
for
mentor
is
mentor.
That's
a
Greek
word.
So
a
lot
of
people
have
said
why
not
kubernetes
Mentors
but
I
think
that's
kind
of
bland
and
dry
I.
Don't
know
about
you,
but
I.
A
Don't
want
to
update
my
twitter,
bio
and
say
kubernetes
mentor,
it's
kind
of
like
and,
like
I
said,
a
user
mentor
like
am
I
helping
people
learn
kubernetes
like
it,
doesn't
necessarily
describe
that
you're
helping
contributors
climb
a
ladder,
at
least
from
my
perspective.
It
doesn't
so
like.
Docker
captains
are
evangelists.
These
people
are
not
evangelists,
I
mean
sure
they're
evangelizing,
maybe
the
contribution
process
and
the
effects
that
they're
getting
more
people
into
it
or
helping
the
people
that
are
currently
in
it,
but
that
doesn't
necessarily
dice.
It
doesn't
describe
it.
A
So
what
I'm
gonna
do
is
we'll
create
a
short
list
of
ten
words.
I'll.
Take
that
the
steering
committee
they'll
break
it
down
into,
hopefully
maybe
five,
and
then
we
can
like
take
it
to
a
vote
on
kubernetes
dev
mailing
lists
and
only
throw
in
a
hoodie
I
ran
the
winner
kind
of
thing.
So
that's
updates
on
mentoring,
stuff,
it
is
10/10.
Does
anyone
have
a
10/10
on
the
west
coast
I
apologize?
Does
anyone
have
any
other
items
or
questions
about
mentoring
or
anything
about
contributor
experience?
A
I
A
I
Sure
sure
yeah
I'll
give
a
real,
quick,
there's
a
umbrella
issue,
I'll
make
sure
to
post
that
to
the
meeting
notes
today.
If
anyone
wants
to
jump
in
or
be
collaborate,
collaborate
in
any
capacity,
definitely
paying
me
and
we're
planning
on
I'm.
My
plan
with
this
is
to
kind
of
extend
the
work
that
Gwen
has
already
done
as
far
as
the
basic
contributor
and
and
some
of
the
chat
offs
interactions
and
then
talk
about
how
to
actually
set
up
a
basic
dev
environment
and
maybe
submit
a
code
change
and
review
that
locally.
I
I
A
And
I
need
to
also
make
changes
to
the
Charter
today,
so
I'm
gonna
put
that
on
the
agenda
as
well.
I
said
I
was
going
to
yesterday,
and
here
we
are
and
those
changes
are
nothing
necessarily
to
the
content,
but
it
is
adding
our
utl
christophe,
yeah
christophe,
it's
officially
all
Christophe
has
been
has
gone
through
the
rigmarole
loops.
A
The
rocket
ships
and
everything
else
that
we
have
put
in
place
to
the
FTL
Garrett
is
also
coming
down
to
TL
hood
from
chair,
LC
and
I
will
remain
chairs,
and
then
we
have
several
new
sub
project
owners.
I
mean
technically
they're,
not
necessarily
new,
but
new
ones,
and
we
are
officially
labeling
them
advertising
them
and
putting
them
out
to
dry
people
like
George
Castro.
A
I
think
there's
some
other
people
also
that
I'm
totally
not
remembering
right
now,
but
I'm,
laying
all
that
out
in
the
Charter
today,
just
so
that
it's
clear
who's
doing
what
right?
Now?
It's
just
a
blob
of
processes
at
this
point
and
a
few
names
at
the
top,
so
I'll
I'll
make
that
better
and
then
I'm.
Also.