►
From YouTube: SIG Contributor Experience 20180314
Description
Weekly meetings, find more information here: https://github.com/kubernetes/community/tree/master/sig-contributor-experience
B
Right
welcome
to
today's
episode
of
contributor
experience.
This
is
technically
he
people
only
meeting
as
we're
dubbing
it.
What
that
means
is
that
only
if,
there's
time
allowed
at
the
end,
we'll
talk
about
automation
and
workflow
topics,
they
definitely
tend
to
control
the
conversation.
So
we
try
to
have
off
weeks
for
things
like
contributor,
guide
and
mentoring
and
everything
again.
This
involves
the
people
element
to
what
we
do
here
so
first
on
the
agenda,
as
always,
is
our
reoccurring
meeting
topics-
and
this
is
just
to
make
sure
that
we
have
something
straight
for
the
week.
B
C
B
Lert
lurk
away
my
friends
lurk
away.
All
of
our
agenda
like
I
said
all
of
our
items
are
are
in
the
notes.
The
way
that
we
communicate
process
changes
is
via
github
issues
to
our
mailing
list,
as
well
as
talking
sigelei
distros,
as
well
as
k-dubb
distros
qdubs,
meaning
kubernetes
development
at
Google
Groups.
So
you
should
think
you
should
see
our
things
come
out
of
there.
I
can
also,
after
after
the
call
share
some
other
materials
buta
see
if
you
have
any
interest
in
jumping
in
with
some
of
the
things.
C
D
B
Definitely
yes,
this
is
more
of
the
more
public
forum
for
that
and
others
can
both
weigh
in
and
help
us
execute
on
the
the
tasks
that
you
need
us
to
do
so
so
welcome
and
I
will
go
ahead
and
actually
put
you
on
our
agenda
right
now,
and
so
after
we
run
through
a
few
more
things,
then
we'll
get
to
your
point.
Okay,
thanks
yeah
sure
so
going
on
one
moment
there
all
right
all
right.
So
as
old
was
I
saying
George,
do
you
want
to
ask
for
office
hours,
volunteers,
I,.
A
B
And
on
that
same
note,
George
and
I
do
George
takes
here.
These
are
office
hours
I.
Do
the
contributor
quote
office
hours
we're
calling
that
meet
our
contributors?
Both
of
us
always
need
more
contributors
to
help
out
with
both
of
those
events.
If
you
would
like
any
other
information
about
that,
please
reach
out
to
us
it's
a
very
quick
and
easy
way
to
reach
two
different
types
of
audiences
for
contributors.
B
E
B
All
right
and
then
the
let's
just
jump
right
into
our
agenda
at
this
point,
so
I
did
I
need
to
link
all
in
the
doc
right
now,
I'm
going
to
do
that
right
now,
through
my
email,
but
I,
we
did
propose
save
leadership
and
composition
changes.
This
was
due
to
the
steering
committee
having
passed
down
at
the
Charter
template
for
us
inside
of
the
Charter
template
is
the
new
composition
and
structure.
B
Basically,
this
means
that
LC
and
I's
current
title,
which
is
Sigma
need,
will
be
changed
to
chair,
so
each
one
of
us
will
be
co-chairing
this
project
and
that
just
means
running
it
from
an
operational
perspective
helping
to
patch
together
our
vision,
goals
and
objectives
for
the
quarters,
etc,
and
then
garrett
rodriguez,
who
also
is
a
sega
lead.
We
would
like
to
nominate
him
as
a
technical
lead
ferret
for
the
most
part
on
his
contributor
experience.
B
Journey
has
been
working
on
things
like
automation
and
workflow
improvements,
so
we
think
that
this
is
a
better
fit
for
him
from
both
the
skill
set
perspective,
as
well
as
a
leadership
perspective
and
making
those
kinds
of
technical
decisions
for
us.
We
also
wanted
to
nominate
Christoph,
Blocher,
Christoph
I,
don't
know
if
you're
on
the
phone.
Let
me
look
yes,
he
is.
B
We
would
like
to
nominate
Christoph
Blocher.
He
has
been
so
amazingly
supportive
to
the
entire
project,
especially
contributor.
Experience
in
the
issue
is
not
necessarily
issue.
Actually
it
was
in
the
mailing
list.
Email.
There
is
a
list
of
his
qualifications
that
he
typed
up
himself
recently
to
become
a
maintainer
of
the
project
which
ultimately
did
get
approved.
So
we
do
need
to
weigh
in
on
his
nomination
as
well
and
then
I'm
not
going
to
go
into
all
the
sub-project
leads.
B
While
we
talk
right
here,
but
the
Charter
does
really
start
to
break
down
sub
project
areas,
and
this
all
ties
back
to
owner
styles
of
the
repo
and
how
we
ultimately
have
you
know,
quote
code
ownership.
If
you
will
I
say
that
in
quotes
just
because
the
community
repo
is
mostly
Doc's
yesterday
is
definitely
some
testing
and
from
and
things
like
that
in
there
and
that's
something
that
ideally
Christophe
and
and
Garrett
would
be
leading
from
a
contributor
experience
perspective,
but
to
check
just
please
check
out
the
email.
We
would
love
explicit,
plus
ones.
B
If
you
don't
have
one,
that's
fine,
but
if
you
do
have
any
objections
and
you
would
rather
not
raise
it
via
mailing
list
or
github
issue
and
would
rather
something
a
little
bit
more
anonymous.
Please
feel
free
to
reach
out
to
me
personally
either
on
slack
or
email,
and
we
can
take
care
of
those
concerns.
B
B
Alright
I
got
a
plus
one
from
George
last
call,
plus
one
to
Kristoff
from
Quinn.
That's
awesome,
alright.
So
what
we're
doing
as
a
final
call?
We
are
time
boxing
this
until
this
Friday
at
it.
It
works
out
to
be
5
p.m.
close,
a
business
specific
time
which
is
midnight.
Utc
last
call
will
be
at
that
point
and
then
we'll
go
ahead
and
move
forward
with
changing
things
like
this
egg,
Gamal,
etc,
etc.
All
right!
B
So
the
next
thing
on
our
list,
as
we
steamroll
through
here
the
contributor
site,
can
we
do
a
Jo
on
the
line
as
well?
Jo
is
being
awesome
with,
as
we
go
through
our
very
first
kept
process
and
for
folks
on
the
line
who
are
new
chef.
Is
the
kubernetes
enhanced
the
proposal
process
very
similar
to
rustling
and
python,
and
some
other
projects
that
were
kind
of
tailoring
this
to
be
our
own?
F
F
I
think
these
things
become
especially
useful,
as
you
start
trying
to
coordinate
things
across
SIG's
where,
where
it's
not
like,
hey
everybody's
friendly
here,
we
know
each
other,
you
can
make
decisions
pretty
quickly
within
a
cig,
but
sometimes
when
you're
trying
to
work
cross
sig
having
a
little
bit
more
structure
and
stuff
written
down
can
help
there,
then
the
other
other
thing-
and
you
know
just
backing
up
a
little
bit
on
the
whole
sig
Charter
I.
You
know
from
the
steering
committees
point
of
view,
that
is
a
template.
F
F
Think
that
the
big
idea
out
of
that
is
that
there's
a
few
few
ways
that
we
sort
of
interface
SIG's
with
the
rest
of
the
organization
and
that's
where
things
like
chairs
and
and
the
tech
lead
roles
come
in,
is
it's
a
way
to
sort
of
you
know
it's
an
interface
between
the
sig
and
the
rest
of
the
rest
of
the
project,
so
don't
feel
restricted
by
the
by
the
template.
Please
so.
B
F
Yeah,
so
on
the
kept
stuff,
though
I
mean
on
kept
five
specifically
around
the
community
site,
I
I'm
kind
of
a
little
bit
of
a
holding
pattern.
Just
waiting
to
you
know
a
you
know,
some
of
it's
coming
from
you
Paris
in
terms
of
where
you
want
to
go
with
this
stuff,
I'm
happy
to
start
prototyping
I'm
happy
to
make
an
update
to
the
cap.
Just
give
me
a
little
bit
of
a
direction
on
sort
of
where
you
think
things
should
go
and
and
I'm
happy
to
follow
your
lead.
There
yeah.
B
So
I
think
we
definitely
need
I
know.
I
know
it
sounds
weird
saying
that
we
need
to
stop
calling
a
community
site,
but
we
really
should
start
calling
a
contributor
site
because
there
is
a
community
site
and
I
do
need
I.
Think
I
am
gonna
put
in
an
issue
separately
from
this
to
make
the
community
site
better
or
figure
out.
What's
gonna
happen
with
that
once
we
do
the
live
with
the
contributor
site,
because
the
one
currently
is
not
rendering
right
on
mobile
and
I
say
one
meaning,
the
kubernetes
satire
slash
community
site.
B
So
we
really
do
really
really
should
care
about
the
full
and
facing
deal
there,
but
I'm
ready
to
proceed.
I,
don't
think
anyone
has
come
to
me
with
major
objections.
I
think
our
next
step
really
would
be
to
socialize
this
for
final
comments
and
then
Joe
have
you
get
started
on
a
prototype
and
then
I
guess
we
all
regroup
again
for
comments
based
on
that
and
just
keep
iterating
from
there.
What
are
your
goals
there?
So.
F
That
sounds
great
I'll:
rework
the
kept
the
the
Pierre
that
I
have
in
flight
I,
don't
know
the
numbers
off
the
top
of
my
head,
but
I'll:
rework
that
I'll
make
sure
that
we're
consistent
talking
about
contributor
site
to
eliminate
some
of
the
confusion
there
I
think
there
was
some
pros
and
cons
that
I
didn't
summarise
correctly.
I'll
make
sure
that
those
things
are
accurate,
also
separately.
F
Does
it
make
sense
to
and
I
think
this
is
a
this
may
be
a
bigger
change,
but
does
it
make
sense
to
rename
kubernetes
slash
community,
the
github
repo,
it's
kubernetes,
slash
contributors
or
contributing
right,
because
I
think
my
idea
here
is
that
a
lot
of
the
stuff
that's
currently
in
the
community
repo
would
show
up
on
this
site.
Not
everything
I
mean
I'm,
sure,
there's
stuff,
that's
that's
missing,
et
cetera,
et
cetera,
but
but
I
think
part
of
the
confusion
around
contributer
versus
community
comes
from
the
the
naming
of
that
particular
repo
yeah.
B
A
I
feel
like
renaming.
That
would
be
like
a
long
discussion
that
would
happen
on
death,
but
I
think
that
you
could.
You
could
do
this
stuff
in
the
contributing,
folder
and
maybe
generate
age
per
sig
like
they're
reading
these
or
whatever,
so
they
have
a
space.
You
know
and
then
that
would
get
us
like
90
percent
yeah.
F
F
Wants
to
put
something
up
on
a
site
that
gets
indexed,
we
actually
have
a
way
for
them
to
do
that
and
so,
and
that
all
that
stuff
right
now
is
at
the
root
level.
So
I
think
it
would
be
disruptive
to
move
that
stuff
around
too
much
and
I.
Think
it's
not
unreasonable
to
say,
hey,
look,
you
know,
contributes
owns,
you
know
by
and
large
that
that
repo
right,
because
I
think
one
of
the
things
we're
trying
to
do
is
create
a
in
equivalence
between
repos
and
and
and
SIG's
and
I.
F
Think
sort
of
the
root
of
that
repo
is
relatively
like
Unown
sort
of
a
little
bit
of
a
you
know,
tragedy
of
the
commons
type
of
thing.
So
so
it
might
be
worthwhile
to
try
and
and
really
solidify
ownership
of
that
repo
under
control
box
and
make
that
clear
and
maybe
actually
make
the
needed
reflect
it.
Just
something
I
want
to
throw
out
there
yeah.
E
B
A
F
So
some
of
that
I
mean
so
you
know
and
again
I
think
I
think
over
time
will
get
better
and
for
the
community
this,
because
we're
still
figuring
this
out
but
I,
think
one
of
the
things
that
we
want
SIG's
to
do
is
actually
have
a
reasonable,
fair
process
for
doing
things
like
choosing
chairs
right.
So
that's
like
a
requirement
to
be
part
of
kubernetes.
F
You
have
to
do
that
and
that's
actually
specified
in
the
Charter
and
you
know,
and
so,
if
you're
doing
the
template,
then
you
know
that
that
checkbox
boom
you're
done,
if
you
know,
but
if
you,
if
you
said
hey,
we
want
to
do
you
know,
take
chairs
based
on
rotating
every
week,
based
on
you
know
this
list
of
people
with
alphabetical
path.
Last
name,
that's
like
okay,
I
think,
that's
fair,
maybe
something
some
change
like
that.
We
might
want
to
have
some
water
review
and
approval
around
so
I
know
I'll.
F
B
And
then
to
get
back
on
to
the
contributor
say:
cap
I
am
making
notes
in
our
agenda
that
Joe
you're
going
to
make
some
make
some
more
edits
the
proposal
and
then
we're
going
to
socialize
it
to
both
the
contributor
experience,
contributor,
experienced
mailing
list,
k-dubb
mailing
list
and
maybe
say,
bleed
mailing
list
for
a
final
call
for
comments
before
prototype
and
then
Joe
you'll.
Take
it
away
with
the
prototype
yeah
that
sound
good
to
you.
That.
F
Sounds
good
and
I
think
you
know
I
think
you
know
there's
the
status
on
the
cap
in
it
and
I
think
right
now
it's
in
I
don't
know
what
we
made
me
chose
for
the
status
thing,
but
it's
essentially
provisional
as
right
now
is
that
it's
the
name
not
draft,
because
people
didn't
like
draft,
so
it's
provisional.
The
next
up
there
is
implementable,
so
I
think
like
it
at
some
point
when
we
think
hey
this
looks
reasonable.
We
can
take
it
to
implementable
if.
G
B
A
Just
one
extra
st.
pairs
can
you
can
you
summarize
and
put
that
actually
in
the
request
itself,
because
I
don't
want
to
get
us
in
the
habit
of
posting
links
to
youtube
videos
of
our
discussions
that
way,
people
can
just
see
the
steps
as
opposed
to
yeah.
Is
it
wasn't?
It
wasn't
obvious
still
not
obvious
to
me
what
the
next
step
is
on
a
cap.
When
someone
does
something.
B
F
F
B
B
Yeah,
alright,
alright,
so
we're
gonna
go
ahead
and
move
on
Tim.
Unless
you
had
any
more
comments
about
that
all
right
and
then
next
on
the
agenda
is
Thomas
and
Thomas.
If
you
could
do
me
a
favor,
because
the
folks
here
we're
not
on
the
initial
email
that
I
remember
reading
about
your
concern.
So
if
you
could
just
start
with
your
concerns
and
then
and
then
ultimately
we'll
start
we'll
strike
a
conversation.
D
D
We
asked
the
engineering
team
for
every
lounge
and
for
every
major
upgrade
hey.
Please
provide
us
architecture
Doc's,
give
us
an
insight.
What
are
the
components?
Where
do
they
run
and
traditionally
those
would
be
Bork
shops
running
on
Google
infrastructure,
and
we
have
good
understanding
how
they
work
where
to
find
the
code
how
to
navigate
it
with
kubernetes.
Everything
is
different
and
also
the
velocity
of
kubernetes
is.
D
So
we
need
something
better
and
we
need
more
support
from
GK
engineers
promised
gke,
so
the
Googlers
working
on
kubernetes.
They
are
only
a
fraction
of
all
the
kubernetes
engineers.
So
if
I
now
go
during
a
launch
review
to
the
Googlers
and
awesome
hey,
we
need
more
dogs
about
this
feature.
That
is
in
the
new
kubernetes
version.
Then
they
tell
me:
oh,
this
was
developed
by
redheads,
we
don't
know
about
it,
but
I
and
my
team.
We
should
support
it,
so
we
need
better
docs
and
better
architecture
dogs.
D
So
we
don't
need
better
dogs
for
users.
We
need
dogs
for
people
that
need
to
debug
stuff
when
it
breaks
or
when
it
does
surprising
stuff,
and
my
idea
is
what
I
learned
is
documentation.
People
agree
that
the
best
place
for
this
kind
of
dogs
is
directly
nearby
the
code
in
the
same
repository
and
that
it
should
be
updated
with
every
commit.
You
should
also
think.
Oh
does
this
affect.
D
Actually,
the
architecture
should
I
also
update
the
architecture,
dogs,
and
my
question
is:
how
can
we
now
get
started
that
developers
see
it
as
part
of
their
job?
Hey
when
I
do
something
in
kubernetes
there
is
readme
nearby
the
code
that
also
needs
updating
to
document.
What
is
this
component
doing?
What
is
it
talking
to?
What
are
the
known
consumers
of
this
component
where's,
the
entry
point?
What's
the
execution
flow,
what
are
the
major
data
structures
and
where,
in
the
code,
do
I
find
them,
and
what
is
the
roadmap?
E
F
I
The
one
thing
that
I
would
ask
is
do
use.
Is
there
any
particular
trends
like
do
you
see?
Is
it
like
a
particular
feature
set
you're,
not
seeing
the
white
docks
or
is?
Are
you
seeing
this
basically
across
the
project
where,
from
your
perspective,
in
trying
to
like,
consume
and
understand
the
underlying
architecture,
where
you
are
just
not
seeing
the
documentation,
you
need.
D
Pots
in
a
stateful
set
wouldn't
get
deleted
and
it
turned
out.
It
was
actually
I
think
it
was
a
buck
in
any
case
in
engineers
form
something
that
they
didn't
expect.
But
what
I
noticed
while
I
worked
on
the
support
case?
Hey
I
have
no
idea
what
the
current
implementation
of
stateful
sets
is,
how
it
is
supposed
to
work
internally
and
then
it's.
D
D
Strange
collection
of
supports,
while
the
stateful
set
controller,
is
doing
its
thing
and
where
is
this
documented
and
we
support
three
different
versions
of
kubernetes
at
every
given
point
in
time
and
all
the
point
versions,
the
minor
point
versions,
so
I
also
needs
to
be
able
to
go
and
check
out
a
branch
of
the
code
and
check.
Ok,
how
was
this
supposed
to
work
in
kubernetes,
1.7
and
kubernetes
is
moving
so
fast.
D
Like
a
year
ago,
a
bit
over
a
year
ago,
when
I
started
specializing
on
gke
I
had
the
impression
of
Kay
I
can
still
compare
what
is
moving,
what
is
going
on
and
what
are
the
major
blocks
of
kubernetes
and
now
I
observe
it's
not
possible
anymore,
even
for
somebody
specialized
in
gke
to
keep
up
with
all
the
development
we
already
split
our
team
in
eight
people
for
different
parts
of
kubernetes
and
even
then
it's
hard
to
keep
up
with
all
the
development
just
in
your
area
of
responsibility.
What
is
what
other
developments?
D
What
is
the
current
state?
So
yesterday
a
vendor
asked
me
hey:
what
is
this
container
deep
process
and
I
was
struggling?
Hey.
Do
we
still
have
docker
d
running
on
nodes
and
do
we
use
the
container
runtime
interface,
actually
ng
ke?
So
many
of
these
questions
are,
of
course,
GK
is
specific
and
those
should
be
handled
in
our
Doc's,
and
that
is
our
problem,
but
when
it's
about
how
the
stateful
set
works,
this
is
nothing
that
is
cheeky
specific,
and
this
should
be
properly
documented
in
the
controller
for
the
stateful
set.
I
So
I
just
have
like
a
couple
high-level
comments.
So
I
know
at
a
point
in
time
in
pointing
history
along
one
of
the
design,
proposals
and
architectural
documents
were
moved
out
of
the
quarry
PO
and
that
had
to
do
with
the
the
velocity
that
the
core
repo
and
the
code
moves
out
and
how
many
contributions
and
how
many
changes
there
are
the
keeping
the
architectural
diagrams
close
was
was
misleading
as
it
was.
It
was
difficult
to
keep
them
up
to
date
with
every
every
flag
of
the
implementation.
I
So
that's
point
number
one
point
number
two.
As
far
as,
if
there's
like
a
specific
part
of
the
project
where
you're
seeing
deficient
documentation
the
documentation
czar,
ultimately,
the
documentation
is
ultimately
distributed
out
to
the
six.
So
if
it's
like,
you
know
something
to
do
with
Q,
proxy
or
IPPs,
that
would
be
sig
Network
versus
something
like
stateful
sets
would
be
sig
apps
or
the
container
D
process.
Will
you
know
whether
we're
using
CRI
or
docx,
or
how
that
would
present
on
the
nodes
that
would
be
sig
node?
I
So
those
the
documentation
is
distributed
out
to
the
groups
that
are
ultimately
responsible
for
those
parts
the
code
base,
if
it's
something
that
is
overreaching
where
you're,
seeing
like
large
parts
of
the
documentation
are
just
out
of
date
and
that
need
to
be
need
to
be
tied
up
or
we
need
like
some
policy
across
the
project.
Ultimately,
that
would
be
sig
architecture,
because
they're,
the
only
cig
that
kind
of
has
that
mandate
to
tell
cigs
hey.
D
Okay,
thank
you.
So
the
auto-generated
API
Doc's
are,
of
course
essential
and
one
cannot
live
without
them,
but
they
are,
of
course
not
the
same
as
a
design
or
architecture
doc,
because
they
just
give
you
the
doc
about
the
surface.
That's
exposed,
but
not
what
is
going
on
internally
in
and
don't
have
you
that
much
to
understand
the
codes
and
the
move
of
design
or
architecture
dogs
out
of
the
code
base
with
the
justification
hey,
we
cannot
keep
them
current
because
the
code
is
moving
so
much.
D
D
We
have
the
problem
for
new
contributors
who
want
to
understand,
what's
going
on
and
find
the
point
in
the
code
where
to
start
doing
their
contributions,
which
is
also
one
feedback
that
I
got
from
Google
engineer
internally,
that
hey
we
have
the
same
problem
with
our
new
engineers
to
get
them
up
to
speed
with
the
codebase.
So
it's
not
only
supported
yeah.
C
I
think
coming
from
someone
who's
who's
looked
at
the
codebase
with
the
view
trying
to
contribute
recently,
just
the
not
even
necessarily
the
complexity,
but
just
a
sprawl
and
the
fact
that
things
live
in
so
many
different
places
and
there's
no
clear
pathway
through
the
functionality
and
how
components
interact.
It
has
been
a
really
big
blocker
at
the
interested
CF.
If
we
have
any
like
metrics
on.
You
know
whether
that's
a
big
item
that
puts
people
off
contributing
or
at
least
makes
it
really
difficult.
I
think
it
makes
sense.
C
D
B
D
Internal
concrete
proposal
was
I
want
for
every
owners
file
that
we
have
in
the
kubernetes
code.
I
want
to
also
see
you
read
me
that
describes
because
an
owner
file
for
me
indicates
ok.
This
is
something
that
is
one
component
where
some
people
have
distinct
ownership
for,
and
in
that
case,
it's
also
a
place
to
document.
Ok,
what
is
this
thing
that
people
are
owners
of,
and
how
does
it
work
together
with
other
other
things
and
I
wanted
to
ask?
D
D
D
Will
actually
find
ways
on
their
own?
What
is
good
stuff
to
put
their
in?
Sometimes
it's
just
that
you
don't
have
the
idea
that
I'm
supposed
to
write
this
and
where
should
I
put
this,
and
once
there
is
it's
easy
to
put
the
information
there
may
be
things
already
improve,
so
I
would
start
not
with
a
guideline
or
demand
hey.
You
must
write
this,
but
with
documented
best
practice
hey.
D
B
I
Just
just
a
comment
on
that
I
think
I
think
that's
actually
a
in
my
personal
opinion.
I
think
that
that's
a
fair
ask
to
have
if
you
have,
if
you're
delineating
a
folder
enough,
that
there
is
a
separate
owners
file
to
have
some
sort
of
description
of
what
it
is.
I,
don't
know
that
necessarily
takes
the
form
of
what
I
would
consider
an
architectural
dock,
but
I
think
that
might
be
a
fair
ask.
What
I
would
definitely
say,
though,
is
something
like
that
and
having
that
be
a.
I
Having
that
be
a
requirement
because
to
be
perfectly
honest,
with
the
number
of
contributors
that
we
have
across
the
project,
unless
you
have
some
sort
of
mandate
around
something
where
you
have
even
like
a
recommended
policy
or
recommended
best
practice,
it's
not
gonna
happen.
I
know.
There's
lots
of
lots
of
things
that
I've
created
that
have
ramiz
I,
know,
there's
probably
a
few
things
that
I've
treated
the
don't,
but
unless
you
happily
have
some
sort
of
recommended
or
mandated
best
practice,
it
probably
won't
happen.
B
G
Sure
yeah,
and
as
long
as
I
don't
know
if
in
my
mouth
too
much,
let
me
know
if
I'm,
not
speaking
clearly
yeah
so
in
general.
I
think
this
is
a
totally
fair
ask
and
I'm
also
would
like
to
say
that
we
should
bring
this
to
stick
architecture
because
a
contributor,
a
potential
contributor
came
to
us
and
said:
hey
I
am
experiencing
problems,
so
I
think
Thomas
came
to
the
right
people.
Thank.
G
G
Don't
I
personally
think
it's
totally
fair
to
mandate
documentation,
it's
the
way
things
are
done
at
my
org
well,
I
mean
at
least
is
the
ideal
and
I'm,
usually
the
one
that
demands
that
people
add
some
because
I'm,
usually
the
one
that
is
new
to
something
or
the
other
and
doesn't
quite
understand
it.
So
that's
kind
of
when
my
suggestion
was.
It
would
be
really
amazing
if
we
could
find
a
we
could
devise
a
program
or
some
efforts,
maybe
similar
to
the
mentoring.
G
The
group
mentoring
that
Paris
has
designed
and
we're
a
potential
new
contributor
can
be
may
be
paired
up
with
a
code
owner
sort
of
almost
like
it
as
a
mentoring
or
basically
like
a
mentoring
thing,
but
some
of
the
results
should
be
readable
documentation
because
it's
really
hard
to
write
documents.
If
you
don't
know
what's
going
on,
and
it's
also
really
hard
to
write
documents,
if
you're
in
the
thick
of
it-
and
you
don't
even
know
what's
hard
anymore.
B
That's
where
I
was
going
with
changing
the
culture
I
mean
demanding
document
yeah,
just
using
the
D
word
in
general
and
open
source
is
a
culture
change
and
overarching
changes.
So
that's
why
I
feel
like
this
is
a
long-term
problem
that
we're
about
to
head
into.
We
can
probably
do
some
short
issues
me.
Some
short
term
fixes
I'm
Thomas.
If
you
have
areas
of
the
project,
I
think
and
that's
what
kind
of
Christoph
was
alluding
to
to
if
there's
areas
of
the
project
where
you're
like
this
is
absolutely
barren
and
or
zero.
B
B
C
I
Yeah,
let's,
let's
sync
up
after
I,
really
like
to
see
Thomas
if
you're
able
to
send
out
some
of
the
like
those
questions,
that
information
to
the
I
cut
rebec's
email
list
and
we
could
kind
of
continue
the
discussion
there
and
how?
How
best
to
kind
of
bring
that
bring
that
torch
forward
to
seg
architecture
and
say
hey!
You
know
this
is
what
we're
thinking,
what
the
water,
what
would
sing
architecture
you
know?
How
would
you
weigh
in
on
this
I've
put
the.
G
So
we
have
two
action
items
here:
right
directly:
addressing
the
issues
and
coming
up
with
temporary
or
or
at
least
emergency
fixes.
I,
don't
want
to
say
emergency
I,
don't
know,
I
I,
don't
want
to
be
I,
don't
want
to
overturn
McDermott
eyes
things,
but
so
anyway,
helping
Thomas
out
for
now,
but
also
being
aware
that
we
need
to
evoke
a
culture
shift
here.
B
Yeah
I'm
kind
of
curious
to
see
if
other
cloud
providers
and
other
people
are
are
having
this
issue
too,
and
what
their
thoughts
are
I
know
we
heard
from
John.
Oh
and
John
was
sort
of
a
plus
one
as
well.
I
guess
I'm
just
curious
as
to
why
we
haven't
heard
this
sooner
I
mean
don't
know
and
I
I
mean.
That
is
a
your.
Your
comments
are
legitimate,
but
this
sounds
like
a
very
large
problem.
Yeah.
C
B
Only
like
comment
that
I've
seen
like
the
last
survey
that
we
ran,
we
had
roughly
140
contributors,
take
it
and
we
have
about
600
members
and
the
organization
I
mean
we
have
thousands
of
contributors
based
off
of
actions
on
github
like
comments
and
things
like
that.
But
members
to
the
organization
are
the
one,
so
we
consider
the
most
active,
so
I
mean
we.
B
G
Have
a
suspicion
of
why
that
is
yeah,
so
I'm
fairly
new
to
the
orc
and
I
was
lucky
enough
that
when
I
started
learning
about
kubernetes
I
was
in
a
small
office
office
with
tons
of
helpful
people,
who'd
been
doing
it
for
a
while,
so
I
was
basically
immersed
in
just
you
know.
Help
was
sitting
right
next
to
me
on
and
and
and
I
think,
as
the
project
picks
up
in
use
and
more
and
more
people
adopt
it.
Lots
of
people
are
coming
they're.
You
know
they're
bring
they're
bringing
their
entire
office.
G
G
C
A
really
interesting
point:
it
will
be
it'd,
be
interesting
to
see
what
the
feedback
have
a
feedback
correlated
to
those
who
were
in
organizations
with
a
long
history
of
contribution
versus
more
I,
see
independent
I,
mean
I
know,
certainly
in
Seattle.
Actually,
a
couple
of
friends
and
I
are
thinking
of
starting
up
like
an
in-person
working
group,
just
to
look
at
the
code,
go
through
write
our
own
annotations
for
kit
and
put
our
own
type
readme
stuff
in
and
just
try
and
understand
it.
C
C
Honestly,
someone
who's
followed,
who
understands
you
know
from
from
an
application
point
of
view
fairly
well,
obviously
working
a
docker.
We
work
with
this
stuff
all
the
time
but
I'm
not
on
the
engineering
side,
but
I
have
a
strong
interest
in
that
and
have
done
some
go.
I
would
like
to
have
contributed
to
docker
and
would
like
to
contribute
to
kubernetes,
but
their
codebase
is
fairly,
don't
afraid
to
admit.
B
D
Recent
experience
so
since
I
asked
more
engineers
when
they
came
to
me
with
a
we
made
this
and
do
you
need
anything
from
us,
I
asked
them
to
put
to
find
the
right
place
in
the
kubernetes
code,
boys
to
document
it
directly
there,
instead
of
asking
me
whom
to
inform
and
I
had
have
the
impression
that
they
actually
were
relieved.
Oh,
it's
that
easy,
I,
just
put
it
in
read
me
there
and
then
people
can
find
it
so
I
have
hope.
B
We
have,
we
have
hopes
all
right,
so,
let's
get
to
actions,
then
we
will
take
the
points
that
you
put
into
the
notes
and
I
know.
Lc
has
also
been
taking
some
notes
for
us
on
this,
so
we'll
take
those
to
Architecture
and
Christoph
and
I
will
talk
offline
about
who
and
when
we'll
do
that
and
then
we'll
go
ahead
and
send
out
a
note
to
the
mailing
list
and
go
through
our
normal
communication
process
to
get
this
circulated
cool.
J
G
I
Thanks
very
much
Thomas
for
coming
and
sharing
your
concerns
like
this,
we
did.
We
definitely
want
to
welcome
more
feedback
of
that
type
of
like
hey
I'm,
not
you
know,
I'm
not
rooted
in
the
kubernetes
tradition
right
now.
What
we're
already
do?
What
kind
of
you
know?
What
could
we
do
better?
What
can
we
do
differently
exactly.
B
And
I
want
to
quote,
and
another
thing
actually,
I
want
to
go
back
to
the
really
quick
and
the
no
one
end
this
so
that
we
can
go
to
other
things.
One
of
the
survey
things
that
I
was
that
I
noticed
as
a
trend
was
that
people
did
say
lack
of
documentation,
but
they
didn't
necessarily
go
into
where
how
or
who,
if
you
ask
people,
you
know,
tell
me
what
you
think
about
Coubertin
use
documentation.
B
You
know
generally
across
the
board
you'll
either
hear
you
know
one-word
responses
and
then,
if
it's
on
the
negative
side,
no
one
really
necessarily
goes
into
too
much
detail.
So
this
Thomas.
Thank
you
very
much
for
bringing
us
this
detail.
This
is
exactly
what
we
need
to
kind
of
push
that
needle
forward
and
make
changes
it's
when
people
are
very
descriptive
about
what
exactly
it
is
that
the
documentation
is
missing.
So
appreciate
that
all
right
now
that
was
the
last
item
on
our
official
agenda.
B
All
right
next
week
is
our
automation
and
workflow
and
people
meeting.
So
we
will
talk
more
about
things
like
the
cherry-pick
process
and
some
other
items
that
we
have
on
the
future.
The
future
items
list
and
if
no
more
comments,
then
I
bid
you
adieu,
Thomas
and
John
thanks
so
much
for
joining
us.
We
appreciate
new
contributors
on
the
line.