►
From YouTube: Kubernetes Sig Docs 20180626
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 26 June 2018.
https://github.com/kubernetes/website
A
B
A
A
Cool
well
welcome
all
right.
Let's
move
on
to
updates
and
reminders,
so
a
reminder
that
our
new,
a
PAC
friendly
meeting
time
starts
today
at
7
p.m.
Pacific
and
I
would
like
to
that's.
We
didn't
cover
it
specifically.
Last
week,
I
would
like
to
propose
that
on
4th
Tuesdays
that
are
a
PAC
time
VR
only
time
for
the
sigmax
weekly
meeting
and
I
can
talk
about
specific
reasons.
If
folks
want
to
get
into
that,
but
just
a
sense
of
whether
we
need
to
discuss
that
or
not
our
folks,
they
could
up
or
down.
A
C
D
C
D
C
E
F
A
We
have
two
new
maintain
errs
for
the
repo
we
have
two
mingtang
and
Misty
Linville
who
are
now
they.
Basically
they
have
the
hat
to
go
along
with
the
job.
They've
already
been
doing
for
quite
some
time.
So
it's
happy
news
achieving
as
a
prolific
reviewer
and
is
he
gives
a
great
deal
of
love
to
parts
of
the
crew
Bonetti
stock.
Set
that
don't
otherwise
see
a
lot
of
love
and
Misty
was
just
the
release
Meister
for
1.11
and
did
a
fantastic
job
picked
it
up.
A
I
saw
the
midstream,
so
it
is
a
real
joy
to
have
them
both
on
board
as
maintained
errs
so
yay
all
right.
Let's
move
on
to
the
agenda.
We
have
kind
of
a
the
the
first
discussion
that
we
have
I
mean
it
could
well
take
up
the
rest
of
the
time,
but
it's
an
important
question.
So
Andrew
do
you
want
to
do
you
want
to
enter
this
conversation.
C
I
can
and
also
we
should
probably
bump
the
branching
discussion
to
a
later
meeting.
It's
not
necessary
to
have
it
now
and
it
seems
like
River
people
agenda,
so
111
is
effectively.
The
work
is
effectively
done.
I
have
one
more
PR
to
make
for
some
feedback
that
Andrew
gave
on
the
current
status
of
the
111
stuff.
As
far
as
like
the
Tamil
file,
and
things
like
that,
so
I
need
to
make
an
adjustment
there,
but
all
of
the
features
have
been
documented.
Those
are
all
merged.
We
got
lots
of
improvements
in
I
would
like
to.
C
The
release
is
supposed
to
happen
sometime
Wednesday,
I'm,
not
sure
exactly
about
timing.
Yet
so
I
would
propose
that
this
afternoon,
I
will
cut
110
off
of
master,
so
I'm
encouraging
people
to
review
PRS
people
who
have
the
power
to
do
that
and
get
as
many
fix
PRS
and
to
master,
as
we
can
before
that
time-
probably
not
really
controversial
ones,
because
we
don't
want
to
break
it
right
before
I
cut
it,
but
other
than
that.
Thanks
everybody
for
your
hard
work,
it's
been
an
interesting
learning.
Experience
for
me,
I
think
everything's
on
track.
A
A
F
Know
actually
I
think
I
should
probably
table
that
for
now
right
now,
I'm
working
about
2/3
to
time
with
the
Prometheus
Doc's
and
don't
quite
haven't
been
before
it,
but
I'll
put
together
like
a
Google
Doc
proposal
for
a
future
meeting,
maybe
in
a
coffee
or
three
weeks
that
sound
good.
It
sounds
good.
E
So
we
decided
last
week
I
think
that
it
would
make
sense
to
instead
of
having
the
ml
files
in
the
same
directory
as
their
topic,
to
put
all
the
EML
files
in
a
common
directory
so
that
that
work
is
underway.
Teaming
is
doing
it
he's
doing
it
in
a
sequence
of
small
PRS,
so
that
we
can
evaluate
to
success
in
little
bits
at
a
time
and
there's
an
example
of
one
of
the
PRS.
If
anyone
wants
to
take
a
look
at
it,.
E
A
A
A
Okay,
let's
move
on
and
now
let's
talk
about
the
larger
question
of
how
to
make
sure
the
docs
get
created,
updated
and
and/or
destroyed
when
code
changes
happen,
and
so
there's
I
guess
to
two
pieces
to
this
question,
making
sure
that
ducks
are
current
and
discussing
whether
or
not
or
discussing
how
to
document
doc
life's
our
feature
life
cycle
state
alpha
beta,
GA
Andrew.
Do
you
wanna?
Do
you.
A
D
Just
to
give
some
background
on
a
book
to
folks,
so
the
steering
committee
was
sort
of
having
a
long
discussion
about
this,
and
it
came
about
because
Timothy
st.
Clair,
who
sometimes
comes
to
this
meeting
is
also
on
the
steering
committee
and
he's
part
of
cluster
life
cycle
and
they
were
doing
kind
of
an
audit
of
all
the
docs
related
to
their
sig,
and
they
found
that
there
was
a
bunch
that
we're
missing
or
out-of-date
or
hadn't
been
created
during
the
cycle.
D
Because
you
know
there
was
so
many
discussion
about
like
you
know
they,
they
were
trying
to
introduce
more
into
the
keps
process
so
that
there's
documentation
earlier
on.
But
that
may
not
be
practical,
because
obviously
people
like
to
write
the
code
first
and
it
may
change
by
the
time
it's
kind
of
ready
to
go
out,
and
then
they
usually
will
do
the
documentation.
Then,
based
on
what
the
final
version
is.
So
then
it
was
like.
You
know:
how
do
we,
what
carrots
and
sticks
do
we
have
like?
D
Should
we
make
this
gating
process
so
when
things
are
going
from
like
alpha
to
beta
or
something
before
we,
you
know
as
a
community,
let
them
go
to
the
next
stage
they
have
to
have
like
you
know
checklist
of
things
done,
including
Docs.
You
know,
could
it
could
also
be
testing
code
and
other
things,
but
it'd
be
like
sort
of
like
a
NASA
go/no-go
like
checklist
so
and
they
and
also
Tim
Hawk,
and
wanted
to
make
the
point
that
we
should
ask
more
from
the
community
for
this
sort
of
thing.
D
So
if
we,
if
we
want
to
make
you
know,
I,
don't
know
these
sort
of
like
stick
requirements.
You
know
that
we
should
solicit.
The
community
say
like
this
is
what
we
need
in
order
to
ensure
that
the
docs
are
up-to-date
or
have
been
created,
or
this
of
that.
So
that's
so
I
encourage
you
to
watch
the
video,
because
it's
a
it's
a
good
discussion
and
there's
more
information
that
I'm
talking
him.
D
A
D
Yeah
cuz
right
now,
you
know
we
do
have
sort
of
a
spreadsheet
during
the
release
cycle
that
there's
you
know
people
future
owners
are
supposed
to
put
it
in
and
then
say
whether
it
requires
Docs
or
not,
but
it's
kind
of
late
in
the
process,
and
they
would
like
this
to
be
a
little
bit
earlier
on.
There
was
some
talk
about
well
what
about
creating
like
Docs
LG
TM
labels
in
other
repost,
like
in
the
code
repost.
E
So
I
I
think
they're.
One
of
the
things
we
ought
to
do
is
evaluate,
what's
failing
with
the
current
spreadsheet
model,
so
you
mentioned
one
thing:
it
being
that
we
don't
get
the
information
in
that
spreadsheet
soon
enough.
So
what
other
aspects
of
that
are
failing
is
that
spreadsheets,
failing
to
capture
certain
changes
that
we
should
have
been
aware
of
our
people
failing
to
enter
in
the
spreadsheet,
that
their
feature
needs
Docs?
What
are
the
different
ways
that
it's
not
working
right
now,
so
a
few.
D
Of
the
ways
that
I
know
is
that
one
there's
no
way
to
like
know
for
sure
that
all
the
features
that
require
Docs
made
it
into
this
right,
like
in
from
what
I
remember
from
the
release
process.
It's
like
you're,
always
just
trying
to
like
check
with
the
the
sig
leads
and
everybody
to
make
sure
things
are
in,
but
a
lot
of
times
things
still
slip
in
at
the
last
minute.
So
obviously
that's
not
you
know
it's
not
definitive,
you
know
and
then
another
way
is.
D
It
doesn't
always
track
all
the
things
that
need
to
be
updated
right
because
there's
a
lot
of
times.
You
know
a
lot
of
those
features,
are
new
or
being
introduced
and
they'll
get
it.
But
then,
if
something's
going
from
alpha
to
beta,
like
what
changes
you
know
you
know,
changes
were
made
to
the
code
and
and
the
behavior
may
have
changed,
so
we
need
to
make
sure
the
docs
are
updated
and
then
that
in
the
docs
we
say
that
it's
moved
to
beta
or
going
from
beta
to
GA.
C
They
also
want
this.
They
want
to
understand
more
about
feature.
Your
lifecycle
and
I
think
that
they
want
to
track
it.
I,
don't
know
if
they
have
figured
out
I,
don't
think
it's
gonna
be
tracked
yet
for
112,
but
it's
definitely
a
priority
for
them
and
I
think
they're
trying
to
figure
out
tooling
around
it.
So
we're
not
the
only
ones
that
one
folks.
D
C
Thing
that
I
want
to
say
Andrew
and
I
talked
about
this
in
private
a
little
bit.
If
we
had
a
hard
line
saying
that
we
don't
want
to
document
alpha
features
at
all.
That
makes
it
harder
for
us
to
do
to
document
beta
features
because
we're
starting
from
zero
foundation,
and
it
also
makes
it
harder
for
early
adopters
to
test
alpha
features,
because
it's
really
hard
to
exercise
something.
When
you
have
no
idea
how
it's
supposed
to
work.
G
I
would
worry
about
engineers
picking
stuff
over
the
wall
at
us
at
alpha,
without
without
any
contact.
So
if
we
do
document
alpha,
we
need
to
have
very
clear
guidelines
of
what
we
expect
from
the
developers
to
give
to
us,
including
the
reason
C.
Is
it
why
we
want
to
use
it,
how
customers
are
expected
to
use
it,
etcetera,
I,.
C
Honestly,
don't
understand
how
I
mean.
Obviously
this
happens
all
the
time,
but
I
don't
understand
how
a
developer
can
develop
something
without
having
some
something
to
develop
against
some
idea
about
how
it's
supposed
to
work
and
being
able
to
test
those
assumptions.
So
it
seems
mystifying
to
me
that
there's
not
something
I
mean
because
not
every
feature
goes
into
the
kubernetes
/features
repo,
which
is
sort
of
in
a
way.
Those
feature
docs
are
sort
of
alpha
dogs
in
a
way.
C
A
So
I
know
this
I
guess
just
to
continue
shedding
light
on
the
scope
of
what
we're
looking
at
I
noticed
from
the
from
the
release
process
that
the
consistency
and
quality
of
documentation
of
features
that
are
part
of
a
quarterly
release
cycle.
That's
ducks
quality
and
just
the
extent
of
feature
documentation
isn't
always
guaranteed
and
in
my
experience
so
far
very
rarely
do
features.
Get
comprehend.
A
There's
I
can
find
the
specific
PR,
but
there's
a
PR
I
looked
at
yesterday,
misty
as
part
of
closing
PRS
against
1.10.
Before
we
cut
the
branch
there
was
a
PR
against
specifically
against
no
DNS
inheritance
and
the
docs
for
no
DNS
inheritance
are
in
three
different
places
in
unrelated
feature
groups
and,
as
it
turns
out,
the
default
for
the
value
of
default
for
DNS
inheritance
is
not
in
fact
the
default.
A
So
it
pointed
it
sort
of
highlighted
an
example
of
something
that
we
see
in
other
places
in
our
Docs,
which
is
that
there
doesn't
tend
to
be
comprehensive
review.
So
how
do
we
ensure
that
that
feature
owners,
whether
that's
a
sig,
whether
that's
a
particular
developer?
How
do
we
ensure
that
feature
own?
That
feature
review
happens
regularly
and
it's
very
easy,
with
it's
much
easier
to
have
a
gate
check
on
a
specific
PR
in
a
release
cycle.
A
The
you
know,
that's
very
easy
to
you
know
up
or
down
go
no
go
for
a
PR
and
a
release
cycle,
it's
much
more
difficult
to
like
go
no
go
or
you
know,
enforce
any
kind
of
gate
check
on
ongoing
feature
accuracy
and
I.
Don't
know
the
best
way
to
do
that.
I
wish
I
wish
Jennifer
was
here,
like
sync
cluster
lifecycle
over
the
course
of
this
past,
release
decided
to
train
wreck
their
docks
and
say
all
the
docks
that
we
own
for
the
docks
for
all
of
the
features
we
own.
A
We
were
considering
these
end
of
life.
All
of
these
need
review
and
I
know
that
Jennifer
had
a
very
mixed
experience
with
that.
That
I
suspect
that
we
could
learn
a
great
deal
about
what
to
do
or
how
to
go
forward
with
that
kind
of
comprehensive
feature,
ownership
and
feature
review
because
I
don't
know
the
way
that
we
do
things
now.
I,
don't
think
is
the
way
that
we
continue
to
do
them.
I,
don't
think
that
we
can
I,
don't
think
that
fixing
the
quarterly
release
process
is
enough.
A
I,
don't
think
that's
going
to
be
enough
to
fix
the
question
of
overall
quality
in
the
documentation.
So
that's
another
thing,
I
think
it's
important
to
look
at.
You
know
with
the
quarterly
release
process.
The
stick
that
we
have
is
very
clear.
It's
a
very
binary
go
no-go,
but
what
what
carrots
and
sticks
do
we
have
like
with
an
entire
sig
sig
ownership
or
feature
ownership.
D
Well,
I'm
not
sure
how
we
can
incentivize
the
SIG's
just,
but
a
couple
ideas
of
things
that
we
could
do
to
help
would
be
one
like,
maybe
adding
like
a
sig
in
the
front
matter.
So
we
know
like
every
dock
should
have
sort
of
a
sig
owner
and
then
maybe
we
can
work
with
the
stakes
to
kind
of
do:
I,
don't
know
like
annual
audits
or
whatever
or
every
six
months
and
then,
like
all
the
ones
that
are
related
to
them.
D
They
can
kind
of
look
through
and
make
sure
that
they're,
you
know
not
stale
and
then
identify
that
wasn't
me
need
to
be
updated
or
removed.
Another
thing
we
could
do
is
to
surface
the
the
last
updated
date
because
in
our
we
had
a
you,
go
template
meeting
this
morning
unrelated
to
kubernetes,
but
there
is
a
feature
where
Hugo
can
look
at
the
commit
date
for
from
git,
and
you
can
use
that
in
the
page.
C
Nothing
else
I
think
that
that
should
be
in
a
really
subtle,
watermark
thing
at
the
bottom
of
the
page,
along
with
the
commits
that
last
updated
a
given
page
I've
seen
that
done
before,
and
it's
super
helpful.
If
nothing
else
just
for
understanding
context
about
a
page,
it
can
be
really
subtle.
It
can
even
actually
be
like
in
the
source
in
a
comment
instead
of
being
visible
on
the
page,
but
I
think
that's
really
helpful,
and
we
can
also
run
reports
on
that
yeah.
D
C
C
C
Think
in
general,
as
we
go
forward
to
encourage
people
to
use
the
the
feature
state
hugo
short
code,
instead
of
putting
that
stuff
in
the
prose
I've
been
in
the
111
PRS
I've
been
pretty
hardline
about
that
about,
like
moving
that
version,
specific
information
out
of
paragraphs
and
into
the
future
state
tag
when
I
can,
because
that's
searchable,
that's
really
easily
searchable,
as
opposed
to
just
some
random
sentence.
In
a
paragraph.
A
A
So
I
like
the
idea
of
Andrew
that
you
proposed
of
having
of
including
a
sig
in
the
front
matter
that
I
think
that's
clearer
than
individual
owners,
because
people
come
and
go
and
it's
like
well,
okay,
so
individual
individual
reviewers
I
think
are
still
really
valuable
to
include
in
the
front
matter.
But
I
mean
what
I
just
what
would
we?
Maybe
this
is
a
little
bike
Shetty,
but
like?
What
would
we
include?
Would
we
include
the
sig
as
I
guess
we
could
just
include
this
sig
alias
as
a
reviewer
or
whatever
like
PR
review.
D
Matter
I
mean
because
because
this
that
was
actually
Steve's
idea,
because
that
came
at
a
discussion
of
like
the
the
original
purpose
of
the
owners
tags
in
the
front
matter-
was
to
know
who
had
written
it
and
then,
like
you,
know,
there'd
be
in
charge
of
knowing
whether
the
talk
is
update.
But
then
we
changed
that
whole
thing,
because
now
we
have
approvers
and
reviewers
instead
of
owners.
So
maybe
we
should
still
have
something.
That's
like
author's.
So
we
know
who
the
original
author
was
or
people
who
contribute
or
something
in
addition
to
the
sig.
E
That
yeah,
there
are
a
couple
of
ways
we
could
do
it.
We,
like
Zack
just
said
we
could
have
among
the
reviewers
the
name
of
a
sig
or
the
name
of
some
group.
That
is,
you
know,
sig
lifecycle,
reviewers
or
we
could
have
a
dedicated
field
in
the
front
matter.
I
think
this
is
probably
my
preference
in
the
front
matter
have
a
dedicated
field
called
sig
and
in
most
cases
there'd
be
one,
but
in
some
cases
it
there
could
be
two
SIG's
associated
with
the
topic.
A
A
So
I
mean
these
are
good.
These
are
good
pieces
for
best
practices,
but
I'm.
Also
thinking
about
like
the
next
discussion
that
we
have
with
sig
architecture
like
what
are
the
questions
they're
going
to
ask
and
I
think
they
are
going
to
ask
about
carrots
and
stakes,
and
how
can
we
get
sig
docs
closer
to
future
development?
How
can
we
get?
How
can
we
get
writers
involved
in
gate
checks
inside
of
future
development,
repos.
A
D
Mostly
the
shoot-down
of
those
ideas,
so
just
spitballing
here
some
carrots
and
sticks
I'm,
just
thinking
of
is
for
carrots.
Maybe
we
can,
like
you
know
if
they've
clean
up
their
docks
and
stuff
for
a
particular
sigmay
B.
We
can
help
highlight
their
stuff
in
in
the
release,
notes
you
know,
and
then
four
sticks.
D
D
Over
the
line
but
I'm
just
I'm
thinking
of
possibilities
here
say
that
one
more
time
Andrew,
you
know
we
can
have
a
policy
of
like
you
know.
If,
if
a
particular
dock
hasn't
been
touched,
you
know
updated,
or
you
know
reviewed
in
like
a
year
or
two
years
or
whatever
that
we
automatically
just
deprecated
it
and
pull
it
out
of
our
dock
set.
You
know,
so
the
incentive
for
them
is
that
to
make
sure
that
their
dogs,
like
the
cig,
that
each
sig
has
their
docks
up
to
date,
otherwise
they
slowly
disappear.
A
I
think
that's
worthwhile
I
think
the
I
think
we
would
have
to
be
very
specific
about
what
review
looks
like
in
that
case,
because
it
would
be
very
easy,
for
you
know,
say,
like
we
have
say,
like
we
work
with
tests
in
front,
we
get
like
feed
about
2008
about
2000,
specifically
monitors
updates
to
pages
so
like
what
constitutes
an
update
to
a
page.
Is
it
the
simple
type
of
fix?
Is
it
a
trivial
commit
and
undo
as
if
the
mere
presence
of
a
PR
enough
to
trigger
that
to.
E
E
If,
if
they
go
in,
if
we
write,
you
know,
if
we
notify
them
and
say
your
your
document
is
going
to
be
pulled
from
the
dark
set
unless
you
do
a
review
and
give
it
an
LG
TM
by
this
date
and
if
they
go
in
and
and
give
a
review
an
LG
TM
by
that
date
and
in
the
PR
it's
explained
that
that
is
a
technical
review
from
the
cig.
Then
at
that
point
it's
on
them.
You
know
if
they
haven't
done
due
diligence,
it's
on
them.
I,
like.
A
E
E
Way
to
go
forward,
yeah
I,
like
misty,
suggestion
that
where
we
show
the
last
updated
information
at
the
bottom
of
the
page,
we
also
have
a
link
to
the
commits
or
the
PR,
so
that,
if
somebody
wants
to
say
oh
last
updated
well,
what
kind
of
update
was
it?
They
can
immediately
see
that
this
was
a
thorough
technical
review
or
it
resisted
typos.
A
A
E
You
know
we
talked
a
while
back
about
a
what
kind
of
labels
we
want.
We
decided
that
we
would.
We
would
use
the
existing
labels
for
our
purposes.
We
would
use
approve
to
mean
approved
by
a
writer,
and
we
would
use
LG
TM
to
mean
a
technical
review
and
at
the
time
the
we
talked
about
whether
we
wanted
dedicated
labels.
D
A
A
D
A
D
Okay
and
then
once
we
have
sort
of
enough
ideas
on
the
table,
I'd
be
willing
to
sort
of
put
together
a
doc
outlining
all
the
sort
of
different
areas
and
possible
ways.
We
can
address
it
and
then
we
can
kind
of
decide
on
which
ones
we
want
to
implement.
And
then
so.
We
can
have
sort
of
like
an
action
item
list
and
then
maybe
talk
with
sig
release
and
form
like
a
working
group.
If
we
want
to
make
changes
to
the
overall
release
process.
E
You
know
what
one
concrete
action
item
we
might
be
able
to
look
at
right
away
is
just
doing
the
exercise
of
seeing
if
it,
if
it
even
makes
sense
to
assign
a
sig
to
each
topic.
You
know,
as
we
do
that
exercise,
we
might
be
surprised
to
find
that
it's
it's
not
so
easy
to
identify
a
single
sig
for
each
topic
or
we
might
find
out
that.
E
D
And
I
suspect
there's
a
bunch
of
docs
where
yeah
multiple
SIG's,
because
there's
there's
a
lot
of
different
sections,
there's
some
Doc's
that
are
really
long,
so
I
suspect,
there's
a
bunch
that
we
may
want
to
split
up
or
like
yeah.
We
have
to
work
with
several
different
SIG's
or
a
particular
doc.
I
think.
A
We
may
encounter
as
well
some
sort
of
signal
man's
land',
like
specifically
for
DNS
inheritance
I,
was
thinking
yesterday
about
like
which
sig
do
I
a
scientist
is
a
node,
is
a
cluster
lifecycle,
Pig
and
it
might
be
it
might
meet
both
or
and
or
neither
depending
on
which
specific
aspect
of
DNS
inheritance.
The
specific
aspect
of
the
mechanics
that
we're
talking
about,
so
that's
a
really
good
idea.
Steve,
like
I,
would
so
maybe
like
with
every
PR
that
we
touch
as
part
of
reviewing
it.
A
A
It's
also
not
necessarily
something
that
we
necessarily
it's
not
something
that
we
necessarily
need
to
do
alone.
I
think
we
can
also
invite
other
SIG's
that
could
be
good
at
the
community
meeting
and
say:
hey
other
SIG's,
please
tag
yourself.
Here's
an
example.
Pr
of
what
tagging
yourself
in
the
front
matter
looks
like
go
through
and
tag
the
docs
that
you
think
are
yours,
and
that
might
be
another
10%.