►
From YouTube: Kubernetes Sig Docs 20171212
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 12 December 2017.
https://github.com/kubernetes/kubernetes.github.io
A
A
C
I'll
chime
in
here
I
thought
they
went
pretty
well
I
thinking
back
on
it.
There's
there's
just
one
thing:
I
think
we
could
improve
and
would
really
make
the
difference,
and
that
is
a
different
way
for
people
to
claim
an
issue,
because
the
doing
it
in
slack
the
the
claims
got
a
little
spread
out.
So
it
was
hard
to
see
who
had
already
claimed
something
and
doing
it
in
an
issue
was
a
problem
because,
with
multiple
people
editing
the
issue
stuff
that
got
entered
by
one
person
got
blown
away
by
another.
C
A
D
So
I
noticed
an
interesting
thing
and
I
don't
know
whether
I
don't
know
what
kind
of
thing
it
is
I'm
deliberately
using
that
gloriously
meaningless
term
adjectives
interesting
here,
and
it
was
I
note
it
only
because
I
couldn't
tell
whether
it
might
have
created
a
bit
of
muddled
communication.
We
had
at
least
one
first-time
contributor,
who
was
volunteering
to
review,
pull
requests
for
the
docs
print
and.
D
This
was
okay,
but
sometimes
I
needed
to
ask
for
other
changes
and
I
was
concerned
that
the
multiple
rounds
of
review
were
not
a
great
first
time.
Docs
contributor
experience
so
yeah
that
happened.
I,
don't
know
whether
it
is
even
a
thing
to
address,
but
I
thought
I'd
raise
it
since
it
might
be.
I
was
concerned
about
the
the
committers
first
time
user
experience
right,
but
at
the
same
time
I
didn't
want
to
do
anything
too.
A
A
A
Which
I
thought?
Oh,
that's,
fine,
no
I
agree
with
you
I
think,
that's
something
that
we
can
be
really
intentional
about
in
future.
Sprints
is
directing
people
specifically
into
into
contributor
roles
rather
than
rather
than
opening
opening
the
reviewer
role
for
for
the
first
time,
especially
for
some
contributors
during
a
sprint,
just
because
I
mean
for
reviewing
PRS
in
our
repo
requires
a
great
deal
of
context
and
and
familiarity.
So
that's
it's
not
something
that
people
can
just
easily
pick
up
and
do
even
if
they're
really
good.
A
So
that's
I
think
that's
something
that
we
can
definitely
see.
I'm
just
gonna
make
a
note
that
we're
going
to
Shepherd,
first-time
contributors
into
create
a
rule.
It's
not
review
it
roles,
that's
really
good
feedback!
Jennifer!
Thank
you
other
thoughts.
They
hadn't
you
can
go
I.
Did
the
earth
had
a
coupon
go?
How
did
how
did
ducks
prints
go.
E
A
A
E
D
I
mean
it's
in
in
retrospect,
and
this
didn't
occur
to
me
ahead
of
time
either,
but
I've
done
get
volunteer
recruitment
for
all
kinds
of
things
and
helped
manage
meetups,
and
you
never
ever
ever
in
either
of
those
instances
get
all
of
your
all
of
the
folks
who
signed
up
the
standard
ROI
for
volunteer
recruitment
is
50%
and
for
meetups
it's
actually
not
much
better.
Now
this
is
more
than
a
meet-up,
but
still
seems
like
you
know.
D
A
A
So
ok,
that's
that's
something
to
consider
going
forward.
I,
don't
know,
maybe
just
exposing
the
cap
or
limiting
it.
Well,
we
can
definitely
I,
don't
know
what
the
best
option
is,
but
that's,
but
that's
something
to
consider
going
forward
is
ways
to
ways
to
get
a
better
handle
on
actual
actual
attendance,
and
it
may
just
be
factoring
in
the
really.
This
is
the
expected.
This
is.
If
we
want
this
many
people
to
attend,
then
we
should
double
that
number
for
registration,
and
that
may
be
the
way
to
go.
A
I
don't
know,
but
it's
something
that
we
can
take
a
look
at
going
forward.
I
will
share
feedback
that
we
have
gotten
from
Sprint
participants.
Everybody
had
really
good
things
to
say
about
it.
Everybody
who
was
there
was,
you
know
like
two
thumbs
up
DOS
likes
for
for
the
progress
of
the
Sprint
and
their
experience
there.
A
lot
of
the
sort
of
the
universal
feedback
that
we've
gotten
is
that
hey
I'm
a
lot
more
comfortable
contributing
to
kubernetes
documentation.
A
Having
had
the
support
to
do
this
for
the
first
time,
so
I
think
that
was
a
direct
result
of
everybody
who
worked
to
to
get
that
sprint
ready
for
all
of
the
preparation
and
all
of
the
all
of
the
support.
All
of
the
all
of
the
guidance,
all
of
the
really
good
reviews,
Thank
You,
Jennifer,
all
of
the
organization
that
Steve
and
Andrew
put
in
to
organizing
material
and
making
it
available.
A
All
of
the
thought
that
went
into
that
created
a
really
good
contributor
experience,
so
I
mean
I,
haven't
heard
any
negative
feedback
in
all
of
the
responses.
We've
gotten
I
mean
nothing
even
like
I
had
a
really
good
time,
except
for
this,
like
it
was
all
really
glowing
so
yeah
thanks
everybody,
it
was.
It
was
really
well
received.
A
E
I
think
it
turned
out
well
that
we
end
up
doing
the
glossary
stuff
because
they
were
like
small,
discreet
tasks
that
if
people
once
they
did
one,
they
could
just
do
a
bunch
of
them
and
then
you
feel,
like
you
were
being
pretty
productive
and
I,
think
that's
helpful
in
a
sprint.
That's
just
only
a
few
hours
long.
D
C
A
A
Yeah,
Jared
and
I
are
going
to
go
and
two
days
after
that,
we
fly
to
Portland
and
do
it
all
over
again
yeah
buttons
for
punishment
buttons
for
X,
dark
I
mean
all
right.
Let's
move
on
to
talk
1.9,
the
just
as
I
know
that
we
have
I,
see
you
well
I,
see
in
the
agenda
that
we
have
some
specific
questions
about
release,
project
or
release
progress,
so
I
will
relay
the
news
from
the
burndown
meeting
today
the
release
is
being
delayed
by
two
days.
A
A
C
I
just
wanted
everybody
to
know
that
that
you
know
that
was
the
result
of
all
our
work
of
learning,
how
to
do
all
of
this
ourselves,
and
so
we
didn't
have
to
ask
you
know
for
anyone
to
generate
Docs
for
us.
We've
we've
learned
how
to
do
that
now
and
we
actually
have
a
new
tool
that
one
of
the
engineers
wrote
just
in
the
last
couple
of
days.
That
makes
it
even
easier.
It's
it's
not
only
generates
the
Docs
but
copies
them
to
their
locations
in
kubernetes
website.
C
So
that's
all
great
I
still
need
to
look
at
those.
You
know
and
just
look
through
them
to
make
sure
they've
done.
What's
what's
expected
right,
you
know,
I.
Think
we've
made
some
progress
in
understanding
how
to
do
this.
Now,
oh
and
the
other
thing
is,
it
made
sense
to
me
to
save
these
until
the
last
minute,
just
in
case
anything
got
added
to
the
upstream
source
that
we
wanted
to
pick
up
during
the
auto
generation.
C
No,
you
don't.
It
doesn't
cover
all
the
different
kinds
of
generated
Docs
we
have,
but
for
set
of
them
and
that
include
the
the
kubernetes
components
like
the
cube
api
server
and
the
federation.
Components
like
you
know,
cubic
said
in
it,
and
that
kind
of
thing
those
those
are
all
now
covered
by
this
tool
and
all
you
have
to
do
is
run
it
and
it
does
the
auto
generation
and
the
the
placement
into
our
repo
all
in
one
swoop.
So
nice,
that's
nice.
A
C
A
A
C
We
it's
it's
late
enough
in
the
game
now
that
I
don't
feel
like
I
need
to
do
with
those
generations
again,
so
we
can
just
take
those
PRS
as
they
currently
are
and
merge
them
when
we
think
it's
the
right
time:
okay,
I,
so
I
I,
don't
quite
understand
what
the
doc
documentation
repo
freeze
means.
I,
do
you
mean
don't
merge
pr's
into
any
branch
or
just
master
branch?
What
what?
What
is?
What
is
meant
by
the
the
documentation,
repos
freeze.
A
So
the
goal
of
the
freeze
is
specifically
to
not
merge
PRS
into
master
so
that
we
avoid
introducing
any
breaking
changes
into
any
of
the
release
branches
like
either
the
final
cut
for
1.8
or
the
release
cut
from
one
that
night
so
I
mean
sure
if
there
are,
if
there
are
I,
mean
I,
don't
know
of
any
other
branches
out
there.
That
would
have
current
merge
activity
in
them.
Apart
from
that,
like
the
to
release,
branches
and
master,
so.
A
Well,
I
want
to
be
very
careful
about
it,
because
the
the
deadline
for
getting
all
of
that
done
was
was
yesterday.
If
there
are
things
that
still
need
to
go
in
I
think
we
can
look
at
those
selectively,
but
I
just
want
to
I
want
to
be
very
careful
about
introducing
breaking
changes
into
the
repo.
At
this
point
right
into
the
can.
C
A
A
C
A
Well,
that's
why
I
was
being
kind
of
chattery
in
in
the
sig
Docs
channel
is
to
give
folks
plenty
of
notice.
As
far
as
like
an
actual
like
enforcement
mechanism
for
the
repo,
oh
I,
don't
have
one
I,
don't
think
there
is
one,
so
we
all
just
have
to
sort
of
consensually
agree
that
we're
not
going
to
do
it.
Yeah.
E
A
D
Just
one
item,
and
because
I've
been
thinking
about
the
things
that
I
was
hoping,
we
could
do
for
1.9
release,
notes
and
pot
and
docks
to
really
that
didn't
happen
for
one
reason
or
another,
and
thinking
about
the
issues
that
Nick
and
I
have
encountered.
Managing
released,
no
content
differently
from
how
we
did
it
for
1.8
and.
D
D
A
D
In
general
and
release
note
contents,
you
know
specifically,
but-
and
one
of
the
reasons
why
I
think
is
important
now
is
because
with
1.10
you
know
at
least
I'm,
not
even
sure
whether
it's
synch
p.m.
or
whether
it's
the
steering
committee
or
which
sort
of
you
know,
kubernetes
overlords,
are
working
toward
really
trying
to
systematically
adopt
the
new
process.
D
But
release
notes
can
be
a
key
piece
of
this,
because,
if
you're
trying
to
describe
an
issue,
you
know
here's
a
feature
we
want
to
get
into
1.10
the
more
clearly
that's
described
from
the
get-go,
the
better
it
can
serve
as
the
basis
for
all
of
the
user
facing
information
and
okay.
Just
to
get
you
know
just
to
get
the
hubris
out
there
right
now
to
actually
define
what's
going
on
with
a
feature
better
to
so
but
eat,
okay
back
and
off
from
the
hubris
a
little
bit.
D
It
can
only
help
the
work
that
we're
all
already
assigned
to
do.
I
think
it's
gonna
make
it
mainstream,
like
the
lament
I
heard
during
1.8
is
well.
We
have
to
do
something
about
that
release,
notes
process
because
it
takes
30
hours
or
more
for
all
of
these
devs
to
figure
out
in
30
hours
of
dev
time
to
clean
up
the
generated
notes.
Well,
that
30
hours
is
a
low
estimate
and
B.
D
It
exists
under
any
of
the
current
efforts
to
wrangle
release
notes
it
just
it
happens
to
be
offloaded
to
Sadat's
people
as
opposed
to
people
in
other
SIG's.
At
this
point,
I'm
not
complaining
I'm,
just
saying
that
there
are
better
ways
to
do
this
in
that
I
think
one
important
piece
of
it
is
getting
sagat's
representation
onto
the
other
six.
Okay,
thank.
A
D
A
F
E
So
yeah
I
mean
we
should
have
a
deeper
discussion
like
men
Jared's
available,
but
my
one
concern
is
like
how
do
we
get
coverage
because
there's
a
lot
of
cigs
ass
cigs
now
so
like
I
mean
I
can
imagine
you
know,
maybe
first
we
talk
with
like
CPM
and
see
kind
of
what
the
overall
theme
is
and
what
the
important
things
are.
But
then
I
worry
that
like
are
there
some
cigs
that
will
just
kind
of
like
ignore
or
something
will
pop
up
and
I'll,
be
like
oh
yeah.
A
The
the
coverage
question
is
a
really
is
a
really
relevant
one,
because
I
mean
we
don't
really
have
a
lot
of
power
to
compel.
So
we
have
to
persuade
folks
that
embedding
with
a
sig
is
a
worthwhile
use
of
their
time.
We
have
to
I
mean
this.
This
is
a
wonderful
conversation
to
have
like
really
early
with
the
thing,
with
the
with
the
release
Meister
for
for
whoever's,
running
1.10,
like
really
early
like
in
the
first
couple
of
weeks
of
the
process
and
get
their
buy-in
and.
D
A
Don't
want
to
say
any
people
like
it
sure,
but
as
we
as
we
think,
as
we
start
thinking
about
this
for
future
meetings,
where
we
do
discuss
this
one
thing
I
would
encourage
us
to
keep
in
mind,
is
I,
mean
I,
think
I
think
we
can
probably
come
up
with
a
vision
of
what
this
would
look
like
if
everything
was
perfect.
But
how
can
we
start
and
what
is
what
is
the
minimum
viable
iteration
of
this
process?
A
And
how
can
we
iterate
successively
upon
it,
because
I
don't
think
that
we're
going
to
get
over
the
course
of
a
single
release?
And
that
might
be
a
great
thing
to
be.
This
would
be
a
great
discussion
to
be
having
about
the
wild
success
we
enjoyed
at
the
end
of
2018,
but
but
getting
there
in
a
single
release
cycle,
maybe
maybe
ambitious,
but
I
absolutely
think
that
we
should
try.
We
should
just
be
able
to
talk
meaningfully
about
how
to
how
to
instantiate
and
then
how
to
iterate
thereafter,
I
think.
D
That's
perfect
AK.
This
is
why
we
need
you,
you
know,
I
mean
we've
got
big
vision
and
then
we
squeeze,
you
know,
sort
of
scale
things
back
to
what
is
doable
over
the
course
of
a
single
release.
And
how
can
we,
how
might
we
we
can't
determine
everything
for
the
entire
year?
But
how
might
we
iterate,
you
know,
sort
of
to
extend
or
the
course
of
subsequent
releases
sure.
E
Hey
Jennifer,
like
so
for
the
release
notes.
Does
each
lion
have
equal
weight
or
do
they
have
kind
of
different,
so
I'm
thinking
about
log
levels
right?
So
when
you're,
when
you
have
an
application,
you
have
like,
you
can
specify
what
level
of
detail
you
want
when
you're
you
know
verbosity
like
do
we
have
a
similar
mechanism?
I
am.
A
A
A
A
In
course,
of
reviewing
1.9
documentation,
Andrew
and
I
came
across
the
can't
we
can.
We
stumbled
on
the
question
of
how
many,
how
far
back,
are
we
going
to
support
kubernetes?
How
many
versions
back?
Are
we
going
to
keep
in
documentation,
and
we
have
some
open?
Prs
are
some
open
issues
rather
from
users
requesting
that
we
specify
that
we
indicate
somewhere
how
many
supported
versions
of
kubernetes
are
in
the
documentation?
E
I
talked
to
Aparna
as
part
of
6:00
p.m.
and
then
I
us
learned
up,
did
Brian
grant
who's
been
part
of
the
project
for
a
long
time,
and
he
said
the
official
policy
for
the
Bernays
open
source
is
to
support
at
a
minimum
like
current
plus
2.
So
that
gives
us
a
lot
of
leeway
and
I
figured
and
then
I
also
checked
to
see
like
like
what
the
stats
were
for
usage
and
it
seems
like
we
should
be
able
to
cover
like
most
of
the
users.
E
A
So
for
when
1.9
releases,
that
will
mean
that
we
support
that
we
support
documentation
for
1.9,
1.8,
1.7,
1.6
and
1.5.
That's
that's
current!
So
if
you're
in
1.5
or
in
sorry
in
1.10,
if
you
are
reviewing
material
and
you
just-
and
you
see,
discussion
of
material
that
is
older
or
more
stale
than
current
plus
4
go
ahead
and
edit
that
out
use
the
opportunity
to
like
this
came
up
specifically
because
we
were
seeing
discussion
of
feature
comparisons
between
1.3
and
1.2
and
that's
stale.
We
don't
need
to.
A
D
And
if
we're
going
to
continue
to
have
signals,
folks,
wrangling
or
release
notes,
even
though
that
process
has
been
all
over
the
map
for
the
two
releases
that
that's
been
the
case,
we
are
hoping
to
regularize
it
right,
whether
it's
sick
docks
or
not.
So
that
might
be
a
place
to
add
that
sort
of
content
to
okay.
C
A
That's
a
good
point:
Tim
see
Tim's
come
in
and
chat
that
the
style
guide
includes
information
about
the
future
and
avoid
statements
that
will
soon
be
out
of
state,
and
that
would
be.
We
can
update
the
style
guy
to
be
specific,
that
the
content
strategy
is
current,
current
plus
four,
but
yes
Steve.
We
also
need
to
specify
maybe
in
the
contributor
guide,
but
maybe
in
the
overall,
like
release
in
whenever
we're
one
of
us.
A
We
put
all
of
the
the
release
strategy
under
that
that
we're
not
accepting
pull
requests
against
older
versions,
especially
as
we
start
having,
as
we
start
accumulating,
release
branches
to
open
pull,
requests
against
that
that
we're
only
accepting
pull
requests
against
the
current
version
so
yeah.
We
should
absolutely
specify
that
and
make
a
note
about
that.
Really
quick.
A
Okay,
moving
on
I
see
that
I
added
an
agenda
item
for
reviewer
conventions
and
Docs
files.
It's
a
follow
up
from
11:28
tech.
Reviewers
set
up
a
discussion
without
convention
through
bromanor,
oh
I,
see
that's
good,
like
I
was
looking
at
this
and
getting
my
speech
ready
to
be
like
I
have
no
idea
what
I
was
thinking
when
I
looked
at
that
I
have
half
an
idea
of
what
I
was
thinking.
A
So
I
wanted
to
continue
on
with
the
discussion
that
we
had
on
November
28th
about
tech
reviewers
and
about
what
specifically,
we
want
to
do.
What?
What
kind
of
a
convention
do
we
want
to
adapt
for
technical
reviewers
for
a
file
and
the
possibility
that
Steve
had
floated
was
formalizing
the
practice
of
listing
like
file
owners
in
the
title
block
for
a
document,
and
that
seems
to
work
really
well,
it's
it
makes
it
easy
to
identify
tech
reviewers,
and
that
I
mean
it
seems.
A
A
very
reasonable
thing
for
me,
like
it
seems
like
a
really
reasonable
strategy
to
do
to
easily
identify
reviewers
for
a
file
for
content.
So
is
that
something
that
that
we
want
to
adopt
I?
Don't
know
Steve
if
you
had,
if
you've
thought
about
it
more
and
want
to
refine
your
thinking
but
I'm
going
to
propose
that
we
do
it
and
I
am
interested
in
hearing
discussion.
C
C
E
C
Why
not
I,
don't
think
so?
I'm
still
wondering
about
the
frontmatter
in
the
individual
files,
we
might
want
to
look
at
right.
Now.
We
have
the
owners
file.
We
might
want
to
look
at
expanding
that
idea,
possibly
renaming
it,
the
tech
reviewers
file
and
having
something
in
that
file
that
lists
categories
and
who
the
who
the
reviewers
are.
C
C
A
E
But
they're
kind
of
two
different
right
there.
There
are
some
people
that
do
want
to
be
notified
if
their
dock
is
changed
and
so
I
think
we
should
still
maintain
that
in
the
front
matter.
But
then
there
are
a
lot
of
docks
where
it's
not
there
and
people
don't
really
care,
and
then
in
that
case
we
should
back
to
the
you
know
we
assign
the
viewers.
A
Fair
I
mean
it's
not
a
binary.
We
don't
have
to
choose
between.
You
can
find
you
know
an
amalgam
that
works
and
if
it's
possible,
like
in
the
front
matter
of
a
file
to
specify
a
sig
rather
than
like
an
individual,
alias,
you
know
that
works
that
works
just
as
well,
if
not
better
but
yeah.
That's
updating
the
owners
file.
If
we
can
I
I,
don't
know
enough
about
it,
maybe
maybe
Steve
or
Andrew.
What
did
he
do?
E
Well,
it's
sort
of
arbitrary
right
right
now
we
just
have
you
know
one
set
that
we
call
I,
think
approvers
or
something
the
thing,
but
we
can
have
multiple
categories,
so
we
could
have
one
for
each
type
of
sig
and
you're
right.
If
we
can
specify
in
the
front
matter
which
sig
it's
related
to,
then
we
can
have
the
automation
automatically
choose
cool
all.
E
C
A
A
Okay,
so
I
will
announce
in
the
finance
and
cig
Doc's
that
we're
going
to
increase
the
repo
and
rethought
or
sorry
we're
going
to
thaw
the
repo
and
refreeze
it
on
Thursday
at
noon
and
I'll
send
out
that
email
to
sig,
Doc's
maintainer
and
let
everybody
know
all
right
thanks.
Everybody
good
meeting
see.