►
From YouTube: Kubernetes Sig Docs 20171219
Description
Meeting notes: https://docs.google.com/document/d/1Ds87eRiNZeXwRBEbFr6Z7ukjbTow5RQcNZLaSvWWQsE/
The Kubernetes special interest group for documentation (SIG Docs) meets weekly to discuss improving Kubernetes documentation. This video is the meeting for DD Month YYYY.
https://github.com/kubernetes/kubernetes.github.io
A
A
A
B
A
A
So
let's
talk
a
little
bit
about
how
1.9
went
Jennifer
and
Nick.
Do
you
want
to
start
with
your
release,
notes
and
tell
us
about
how
how
they
went
this
time,
how
they
differed
from
1.8
and
that
don't
need
to
go
into
a
whole
lot
of
detail
just
by
like
by
way
of
high
level
overall
or
summary,
I.
C
Can
keep
it
short
and
leave
room
for
Nick
to
add
things
so
41.8
just
to
give
people
a
baseline
understanding
for
the
first
time
the
release
notes
were
completely
manually
generated,
so
I,
don't
remember
whether
it
was
Kalyan
or
Chase
who
put
a
markdown
file
into
the
features,
repo
and
directed
every
sync
to
go.
Add
their
release
notes
manually
to
that
one
file.
So
there
was
no
generation
from
release
note
strings
in
the
pull
requests.
The
reason
for
this
was
because
in
previous
releases
for
all
that
there
were
various
iterations
toward
improving
the
automation
process.
C
It
wasn't
working,
and
there
was
too
much
cleanup
to
be
done
at
the
last
minute
to
render
the
content
in
those
strings
actually
intelligible
to
a
user
that
was
difficult
from
managing
content.
Edits
perspective
different
folks
at
different
views
about
that.
I
found
it
difficult
because
we
had
to
write.
It
was
great
to
have
writers
also.
The
other
thing
that
was
new
for
1.8
is
that
there
were
actually
representatives
from
sig
Docs
working
on
their
release.
Notes
it
wasn't
just
the
release
lead
struggling
to
make
it
the
release,
notes
intelligible.
C
C
C
C
Note
content
simply
didn't
describe
anything
useful
either
to
code
contributor
or
to
accommodate
his
end
user,
and
so
we
had
to
go
digging
to
figure
out
what
really
needed
to
be
there
and
again
ice
can't
speak
for
Nick
I
had
to
do
a
ton
of
triage
on
that.
There
simply
wasn't
time
to
analyze
in
depth,
and
my
default
as
we
got
down
to
the
wire
was
to
whack
things
out
altogether.
C
That
seemed
to
be
fine
because
well,
Anthony
and
I
think
Lucas
and
maybe
filming
it
also
went
in
and
wacked
out
a
bunch
of
stuff
at
the
eleventh
hour
and
15
nights.
A
minute
and
I
think
this
is
a
case
where
less
is
more
but
short
version.
The
automated
process
doesn't
work
great
writer.
We
don't
have
a
good
solution,
so
Nick
is
gonna,
come
up
with
a
great
solution
that
says
all
the
things
so.
D
I
am
now
going
to
I
am
going
to
now
sound,
like
I'm
disagreeing
with
everything
that
Jennifer
said,
but
I'm,
really,
not
so
all
right,
so
I'm
actually
I'm.
Actually
a
fan
of
the
automated
process
as
I
believe
that
it
could
be,
and
and
here's
what
I
mean
by
that
I'm,
not
a
big
fan
of
the
the
manual
process,
because
you
know
we,
we
know
how
hard
it
is
to
you
know,
put
a
gun
to
people's
heads
and
make
them
to
make
them
do
what
they're
supposed
to
do.
D
And
then
they
don't
do
it
till
the
last
minute,
and
you
know,
and
there's
always
that
stress
and
are
they
going
to
do
it
and
then
you
know,
are
we
gonna
have
to
do
it
ourselves
and
and
all
of
that
stuff,
and
so
that
right
there
to
me?
That
is
a
reason
right
there
to
do
the
automated
process,
but
there
were
some
significant
improvements
that
I
think
we
can
make
to
the
automated
process
number
one
I
think
the
very
first
thing
is
to
clarify
that
not
everything
in
the
world
needs
a
release.
D
D
What
I'd
like
to
do
is
change
that
so
that,
rather
than
just
pulling
the
release,
note
string
I'd
like
to
pull
the
release,
note
string
and
then
the
description
from
the
pull
request,
because
that's
gonna
save
a
lot
of
time,
just
knowing
that
what
we
had
to
do
to
turn
those
release
notes
strings
into
something
cogent.
If
it
was
all
in
one
place,
it's
really
not
a
big
deal
to
just
go
through
read
it
does
that
make
sense?
Yes,
whack
out,
what's
extra,
it's
just
a
heck
of
a
lot
simpler
and
I.
A
D
A
D
Absolutely
but
people
put
a
lot
more
information
into
that
field
than
in
one
line
for
the
release.
Note
yeah,
that's
better
yeah
I
mean
that
and
that's
what
we
wound
up
doing
is
we
would
look
at
the
release.
Note
go.
This
makes
no
sense.
Click
on
the
link
go
read
the
description.
Oh
now,
I
know
what
they
mean
and
then
turn
it
into
a
real
sentence.
So
to
have
it
right
there
just
saves
time.
That's
all.
There's.
C
Also
I
forgot
this,
but
there
is
an
issue
with
the
the
script.
Its
generate
release
notes
now,
anyway,
I
I
kept
thinking,
I
had
figured
it
out
and
I
haven't,
but
if
the
PR
is
not
completely
appropriately
tagged,
the
release
note
tool
pulls
from
the
description
field
instead
of
from
the
release
notes
field,
even
if
there
is
released
no
content
in
there.
C
C
C
D
C
Wow,
although
one
of
the
reasons
I
started
noticing
the
script
problem
was
because
when
I
had
to
ping
adem,
because
I
couldn't
make
any
sense
out
of
what
was
going
on,
if
I
went
back
and
looked
at
the
release
know
carefully,
it
was
because,
in
fact,
the
release
notes
spring
hadn't
got
pulled
in
and
I
was
missing
it
just
because
my
eye
was
skipping
over
to
the
pier
itself.
So
yeah
there's
a
whole
lot
of
variables
here.
What.
D
My
feeling
is
we're:
gonna
have
to
do
some
work
on
the
script
anyway,
if
we're
going
to
implement
this
this,
you
know
these
flags
for
the
release,
notes
and
all
that
so
I
mean-
and
we've
got
three
months
to
do
that.
So
you
know
that
I
see
that
as
a
non-issue
right
now.
We
just
need
to
keep
it
in
mind,
but
we
got
plenty
of
time
to
to
work
on
that.
If
we,
if
we
start
on
that
now
so
the.
C
Other
thing
that
I
think
that
I'd
like
to
see
us
move
toward
again.
This
is
you
know
we
do
it
needs
to
be
iterative.
Is
what
I
grown
up
last
week
about
moving
forward
sooner
rather
than
later,
with
figuring
out
how
to
get
sick,
Doc's
representation
on
to
the
other
SIG's
and
providing
sings
with
some
hands-on
training
in
rating
good
PR
contents.
Whatever
field
we
want
to
pull
from,
I
mean
this
benefits
everybody.
Ultimately,
in
the
interest
of
time,
I'm
gonna
ask
you
guys
to
represent
in
about
30
seconds.
C
C
B
A
A
There
was
there
wasn't
so
much
a
crush,
getting
released,
notes,
I,
think
because
I
was
kind
of
it
was
kind
of
a
nervous
little
house
dog
going
after
developers
like
right
from
the
first
being
like
hey
where's,
your
PR,
hey.
Did
you
open
this
PR
milestones
past?
Did
you
open
your
PR
and
just
like
being
willing
to
hunt
down
the
future
developers
individually
and
just
work
on
a
much
more
of
an
interrupt
basis
in
terms
of
like
actually
encouraging
developers
to
Hue
more
closely
to
to
the
release
milestones,
so
that
worked
really
well.
A
What
also
worked
really
well
is
I
benefited
a
lot
from,
especially
at
the
end
Steve's
experience
with
a
auto-generating,
doc
and
so
Steve
opened
I.
Think
a
very
nice
series
of
like
for
PRS
to
handle
all
of
the
auto-generated
doc
and
getting
that
into
getting
that
into
the
release
maker
branch,
so
that
was
a
much
gentler
experience
and
I
think
Steve
had
in
1.8.
So
thanks
made
my
life
a
hell
of
a
lot
easier.
A
There
is
always
something
in
every
release.
1.9
was
no
exception
so
when
it
came
time
to
actually
merge
the
mega
branch
into
master,
what
we
had
noticed
is
that
everything
looked
fine
on
the
mega
branch
for
the
night
laughs
I
deploy
for
the
mega
branch,
but
when
we
except
there
was,
we
noticed
there
was
one
little
bit
of
the
net.
Lefay
preview
had
just
started
to
fail.
I.
A
Didn't
think
that
was
going
to
be
a
blocker,
I
merged
it
to
master
anyway
it
was
a
total
blocker,
and
what's
with
with
the
with
the
help
of
Andrew
and
Steve
on
Friday
evening,
we
figured
out
that
what
was
happening
was
that
there
was
there
had
been
an
unclean
as
the
adjective
that
I'm
choosing
to
use
an
unclean
PR
in
the
release
mega
branch,
it
was
ended
up
being
something
like
46
commits
for
nine
files
changed.
It
was
like
a
revert.
No,
they
were
like
yeah.
A
E
Didn't
so
I
just
want
to
add
to
that?
What
what
made
that
problem
sort
of
insidious
is
that
you
couldn't
tell
that
those
problems
were
there
based
on
the
the
github
interface.
When
you
looked
at
the
PR,
it
was
only
when
I
reviewed
the
actual
like
commit
notes
through
through
a
different
git
client,
but
I
could
see
that
it
had
reverted.
Some
of
the
changes
like
you
didn't
see
it
in
the
file
diff
for
that
piana.
E
So
there
was
like
no
way
to
know
so
when
we
initially
like
approve
the
PR
we,
you
know
we
were
just
looking
at
the
diff,
so
it
was
like.
Oh
that
looks
fine,
so
yeah
I
mean
it
seems,
like
it'll,
be
a
rare
occurrence,
but
mm
yeah,
I
sort
of
feel
like
just
in
general.
When
we
come
across
PRS
that
have
a
lot
of
commits
attached
to
them.
We
should
just
scrutinize
them
a
little
bit
more
yeah.
It
was
looking.
E
A
That
all
worked
out
fine
in
the
end,
but
it
was
hairy
in
the
moment
and
I
think
we
can
avoid
that
just
by
practicing
I
think
stronger
scrutiny
of
of
PRS
feature
key
ours
with
multiple
commits,
especially
something
like
4846
commits
in
it.
So
I
think
overall,
1.9
felt
like
a
much
more
gentle
experience.
That
may
also
be
just
due
to
this.
It
was
a
smaller
release,
but
it
felt
like
a
smoother
process.
A
A
Docs
and
Nick
is
going
to
handle
the
release,
notes
for
1.10
and
shadow
Jennifer
for
that
process,
and
then
Nick
is
going
to
be
the
release
Meister
for
1.11,
and
we
will
need
to
get
somebody
to
do
release
notes
for
1.11,
but
that's
several
months
off
yet
so
take
your
time.
Chris
short,
you
expressed
an
interest
in
shadowing
a
release
to
see
if
that's
something
that
you'd
be
interested
in
doing.
Is
that
something
you're
interested
in
doing
yes,
so
Jennifer
and
Nick?
A
You
will
have
a
shadow
for
1.10
awesome
right,
1.9
retrospective
moving
on
so
I
have
an
idea
about
doing
a
doc
summit
in
2018,
where
we
just
get
together
all
of
us
in
person
and
not
really
do
a
sprint
they
get
together
and
they
do
some
mutual
work
to
talk
about
Doc's
priorities
and
figure
out
like
what,
as
a
cig,
we're
going
to
prioritize
for
the
year
ahead.
So
just
very
unscientifically
a
show
of
hands
who
is
interested
in
doing
a
doc
summit
in
2018.
F
A
Could
be
potentially
wonderful
or
potentially
terrible,
depending
on
when
you
come,
you
come
in
the
summertime,
get
ready
for
the
rainy
season,
but
no
we
can
talk
about
location
I'm,
not
wholly
opposed
to
Ohio
I'm,
not
in
love
with
Ohio.
Either
we
can
get
a
we
can.
We
can
take
a
poll,
but
I
mean
it
seems
like
there's
enough
interest
to
pursue
it
as
an
idea.
So,
okay,
I
will
get
on
that
and
let's
make
that
a
thing.
A
Okay,
supported
documentation
for
just
really
quickly.
We
had,
and
we
had
an
issue,
a
user
open
issue
requesting
that
we
publicize,
which
versions
of
the
documentation
we
support
or
which
versions
of
kubernetes
are
supported
and
documentation.
There
was
a
PR
that
was
opened
and
merged
that
specified
current
plus
two
and
in
the
interim,
we've
decided
on
current
plus
four.
So
if
we're
gonna,
stick
with
that
and
I
think
it
makes
sense
to
do
so.
Then,
let's
open
another
PR
and
and
specify
a
specified
current
plus
or
rather
than
current
quest.
You.
A
G
I,
haven't
done
any
any
work
along
those
lines,
the
more
I
think
about
it,
the
more
I
like
I'm,
not
trying
to
put
owners
in
the
individual
files,
except
in
special
cases,
but
to
have
some
some
files
where
we
you
know
list
what
we
call
you
their
owners
or
reviewers
and
maybe
categorised
those
according
to
you
have
some
some
way
of
saying
this.
You
know
this
document
is
in
this
category
and
then
we
have
a
list
of
reviewers
for
that
category.
So
just
trying
to
get
really
granular
in
the
owners
file.
G
E
E
Because
we
just
need
to
have
them
modify
the
bot
so
like
we
can.
Just
you
know,
specify
whatever
category
is,
do
like
a
slash
and
a
category
name
in
the
PR
description,
and
then
it
should
just
choose
from
one
of
those
categories
in
the
owners.
Final
sure
like
I,
don't
think
that
would
be
too
hard.
Okay,.
A
Moving
on
to
the
I
want
to
say
was
like
back
in
either
October
or
November.
We
floated
the
idea
of
having
an
automation
summit
shortly
after
the
first
of
the
year
where
we
talked
about
the
state
of
auto-generated,
Docs
and
sort
of
where
we
are
and
where
to
go
forward
from
there
as
part
of
the
automation
proposal
that
Stephan
put
forward.
A
A
D
F
C
A
A
H
F
F
F
Anyway,
so
there's
k,
EP
is
there
being
cloud
and
Jo
Veda
is
like
we
should
have
these
on
the
website.
If
you
really
nice,
these
are
on
the
website
and
I
think
this
falls
under
the
bigger
question
aroused
where
does
sort
of
developer
contribution
content
land
on
the
site?
We
know,
we've
talked
about
and
I
think
Joe
and
I
immediately
descended
into
sort
of
like
cool
chain
questions.
This
thread
is
available
to
everybody
in
the
group
and
sent
out
the
big
dog,
because
sure
I
think
you
know
I,
don't
know
enough
about
Kepa.
F
H
F
There's
merit
and
having
these
proposals
in
a
single
place,
as
well
as
having
say,
contributor,
guide
lunch
in
a
single
place,
four
different
food
groups
and
something
that
exactly
I
you
and
I
taked
around
as
well
something
I
came
up
in
the
developer
summit
with
a
contributor
summit
at
Kukoc.
So
I
just
wanted
to
share
this
email
with
folks,
and
you
know,
if
there's
any
ideas
on
how
to
address
this
I
am
all
ears.
F
You
can
also
feel
free
to
jump
in
on
the
developer
edge
and
come
up
there,
but
I
think
fixing
the
contributor
process
and
having
compost
around
it
would
be
a
huge
win
for
us,
as
the
ghazal
I
think,
there's
a
lot
of
a
lot
of
knowledge
here
in
this
group.
We
can
share
with
the
developer
community
I
think
the
current
contribution
is
very
I'm.
E
Contributors
has
been
one
of
the
buckets
that
we
kind
of
designed
into
the
user
journeys
portal
and
I've
been
talking
with
Parris
Pittman,
who
who
has
some
of
that
for
community
contribution,
and
things
like
that.
So
we
can
start
populating
that
that
area,
because
because
I
agree,
definitely
the
there
needs
to
be
a
lot
more
documentation
about.
You
know
contribution
for
the
different
sort
of
things,
both
code
Doc's,
community
ecosystem.
E
Because
I
think
for
that
section,
instead
of
having
their
own
like
landing
pages
for
each
like
persona,
we
can
just
use
the
I
want
to
section
and
just
have
like
a
list
of
links
to
the
resources
for
each
of
those.
You
know
contribution
things
that
way.
We
can
kind
of
short-circuit
that
and
not
have
to
spend
too
much
time
on
it.
Yeah.
C
And
we
could
even
prototype,
you
know
just
a
bucket
for
the
for
the
cat
proposals,
in
other
words
the
proposal,
proposals
and
I.
You
know
we
could
do
that
and
and
show
people
how
that
would
work
and
maybe
short-circuit
the
tool
chain
discussion.
At
least
you
know
as
part
of
the
next
steps,
because
this
seems
like
something
where
we've
got
the
tool
chain
figured
out.
The
issue
is
the
content
and
it's
real
easy
to
fall
down
the
tool
chain
around
a
hole
here.
C
That's
real
I,
like
the
idea
of
including
that
the
caps
in
this
a
lot
because
I'm
hoping
that
that
will
also
help
us
normalize
the
release,
no
process
I'm
not
going
to
go
back
into
the
release.
Note
discussion,
but
just
to
let
you
all
know
it.
You
know
had
ideas
in
the
back
of
my
head
about
and
I've
talked
a
little
bit
with
Jase
about
piggybacking
a
better.
You
know
sort
of
release,
note
process
on
the
rollout
of
the
cap
process.
C
You
know
we're
getting
features
and
issues
well-defined
at
the
beginning
of
the
release.
Whatever,
however,
that
should
be
described
to
users
whenever
the
mix
is
done.
Should
be
something
that
we
could
get
pretty
well
defined
before
implementation
happens
and
obviously
refined
as
implementation
changes,
actual
functionality.
A
G
A
A
G
Just
I
want
to
just
throw
a
lot
of
question
not
to
talk
about
today,
but
just
so
people
can
be
thinking
about
it.
What
do
we
do
with
the
cops
documentation
like
cops
is
getting
to
a
point
where
chris
loves
would
like
like
to
have
this
efficiently
documented
and
it
he
would
like
to
see
it
under
kubernetes
dot
io.
There
are
a
lot
of
questions
around
that
like
do.
We
want
to
do
that
at
all,
and
if
so,
where
do
we
put
it?
So
that's
about
where
I
am
with
it.
G
A
G
It's
I
know
very
little
about
it,
but
you
know
my
my
short
yeah,
my
small
understanding
of
it
is
that
it's
a
setup,
setup
tool
and
it
helps
you
get
set
up
on
AWS.
G
Aws,
whatever
they
call
their,
you
know
compute
engine
like
thing
and
that
eventually
cops
could
be
used
for
other.
You
know
other
clouds,
but
I
think
right
now,
it's
primarily
an
AWS
thing.
So
that's
the
reason,
for
you
know
the
question
of
hey.
How
much
do
we
do
we?
You
know
where
do
these
things
belong,
that
they
belong
in
under
kubernetes
dot,
io
or
do
they
belong
in
someplace
like
the
AWS,
documentation,
sure
and.
A
E
A
G
Is
it's
in
the
the
repo
is
kubernetes,
slash,
cops,
I,
don't
know
how
it's
built
into.
You
know
how
it
gets
built
into
different
components,
but
it
is
a
project
under
the
kubernetes.
G
G
A
Yeah,
that's
a
I,
don't
know
that
we
need
to
put
up
a
whole
lot
of
process
structure
around
around
it,
but
it
would
be
nice
to
at
least
have
a
standard
frequency
to
think
all
the
way
through
the
question
of
what
what
do
we
support
of
all
of
the
various
things
out
there?
What
do
we
choose
to
support?
But
what
is
our
test
for
documentation
on
Kate's,
Taiyo
and
at
least
think
all
the
way
through
that
I?
Don't
know
that
we
need
to
get
super
happy
with
it,
but
I
do
think.
A
A
F
Facility
from
Joe
or
on
that
I'm
living
both
you
and
Stephen,
to
chat
about
like
how
do
we
centralize
peacock,
introduced
size,
big
contribution
contents
and
this
whole
ke
thing
expect
he's
already
asked
for
access
to
the
sites.
We
can
build
it,
and
so
then
I
have
said
I'm
saying
no
but
I'm
putting
you
two
in
front
of
him
to
get
into
it.
F
C
A
The
the
last
thing,
the
last
thing
that
I
think
any
of
the
last
thing
that
I
think
would
be
helpful,
for
anybody
is
for
a
really
enthusiastic
temporary
project
to
become
permanent,
and
there
is
no
there's
nothing
so
apartment
in
just
the
temporary
project
that
works
all
right.
Much
shorter
call
this
time,
three.