►
From YouTube: Kubernetes SIG Docs 20171010
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 10 October 2017.
https://github.com/kubernetes/kubernetes.github.io
A
A
We
have
a
lot
to
cover
today
our
agenda
looks
deceptively
short,
but
each
one
of
those
topics
on
the
agenda
is
quite
weighty
in
its
way
so
I'm
going
to
be
holding
us
to
a
tighter
schedule
today
and
I
may
jump
in
and
and
moderate
discussion
a
bit
just
so
we
can
make
sure
to
get
to
everything
that
we
have
so
before
we
get
started.
Do
we
have
any
any
new
attendees
today,
yeah.
B
Hello,
everyone
can
you
hear
me?
Yes,
hello,
hi,
so
my
name
is
Anthony
and
I'm,
a
on
the
customer-facing
team
at
Google
and
so
just
kind
of
wanted
to
attend
this
meeting
as
some
kind
of
interested
or
I've
been
working
a
lot
with
kubernetes
past
year
and
a
half
and
just
interested
our
special
interest
groups,
work
and
thought.
Doc's
would
be
a
good
place
to
pop
in
so,
hopefully,
I'm
not
entreating
her
yet.
But
this
sends
oh
it's
good
to
be
here.
A
C
Hopefully,
everybody
knows
what
Doc's
prints
are,
so
we've
been
approved
to
run
a
doc
sprint
at
coop
con
coming
up
so
and
we're
also
I'm
hoping
running
a
doc
sprints
at
write.
The
docs
in
Melbourne
so
I'll
be
filing
an
issue
for
the
Melbourne
doc
Sprint's,
which
is
going
to
be
pretty
casual
around
a
lot
of
fairly
non
tech
writers.
D
C
If
not
processes,
so
I
Zack
created
a
an
issue
for
the
kubernetes
coupe
con
doc
sprints
and
if
folks
here
have
ideas
of
projects
they
would
like
to
pursue
or
that
they
would
like
to
present
there
I'd
love
to
hear
them.
Please
add
your
feedback
to
the
issue.
I'm
going
to
be
writing
up
a
general
one,
paragraph
blurb
to
go
in
the
packet
that
attendees
are
given
to
the
kind
of
pitch
attending
the
the
conference
and
we'll
take
it
from
there.
So
that's
all
I
got
thank.
A
C
A
Thanks
awesome,
Thank,
You,
Jared.
The
next
item
is
onboarding
for
new
contributors,
so
Jared
and
I
have
been
talking.
We
have
some
new
contributors
coming
on
and
we'd
like
to
be
more
intentional
about
onboarding
new
contributors
in
general,
because
right
now
it's
sort
of
it's
not
sort
of.
It
is
very
ad
hoc
and
we'd
like
to
do
better
at
onboarding
new
contributors,
so
that
is
something
that
I'm
working
on
right
now:
Brad
and
Chris,
Nagus
and
Andrew,
also
from
Red
Hat,
and
we
have
a
couple
of
new,
maintain
errs
from
the
Chinese
translation
team.
A
A
It
just
seems
like
it
seems
like
an
awesome
thing
for
us
to
do
for
400
contributors.
So
if
you
are
interested
in
being
a
guinea
pig
willing
participant
for
onboarding,
please
contact
me
in
slack
or
by
email
and
we'd
love
to
get
your
feedback
on
both.
What
should
be
in
the
onboarding
process
and
how
that
goes
for
you
and
what
your
experience
is
like
that
is
onboarding
for
new
contributors,
yeah.
E
Okay,
just
to
keep
all
that
information
in
one
place,
I
think
the
only
thing
that
we
don't
want
there
is,
if
we're
getting
to
the
point
where
we're
just
talking
to
some
very
small
group
that
we
want
to
keep.
You
know
out
of
the
public
view,
but
for
this
kind
of
thing,
you're
talking
about
I,
think
this
is
information
that
just
should
be
available
to
anyone
who's
asking
themselves.
You
know
how
do
I
contribute
to
the
kubernetes
Doc's,
certainly.
C
C
C
F
A
That
is
an
excellent
question.
I,
don't
know
that
we
have
anything
quite
so
formal
as
read
before
we
begin
the
current.
What
we
have
right
now
is
the
if
you
go
to
the
kubernetes
documentation
website,
there's
a
page
of
a
collection
of
pages
called
contributing
to
the
documentation
and
that's
what
we
have
right
now
and
that's
part
of
what's
driving
the
need
to
do
better
at
this
now.
C
I
think,
right
now,
new
contributors
are
latching
on
to
folks
who
have
been.
You
know:
longtime
maintainer
and
we're
kind
of
onboarding
people
on
a
one-off
ad-hoc
basis,
which
doesn't
scale
so
surprise,
surprise.
So
we
need
to
need
to
fix
that
and
yeah
you're
asking
the
$10,000
question.
We
don't
have
a
good
answer
to
it:
okay,
we're
all
tech
writers
here
so
okay.
F
G
A
A
C
A
The
most
recent
example
is
blogger
has
bloggers,
WYSIWYG
editor
is
has
fairly
limited
functionality
and
they
were
running
into
some
formatting
issues
that
required
removing
all
formatting
and
then
manually
reapplying
it
when
taking
the
results
from
a
Google,
Doc
collaborative
was
created
and
then
pasting
it
into
the
WYSIWYG
editor.
Even
though
it
looks
good
in
the
editor,
the
out
generated
output
is
doesn't
conform
to
the
appearance
of
the
WYSIWYG.
This
is
the
1.8
launch.
Yes,
announcement.
A
And
the
workflow
process
is
that
it's,
it
doesn't
really
make
a
lot
of
sense
to
collaborate
on
a
doc
in
Google,
Docs,
publish
that
content
in
blogger
and
have
that
have
that
workflow
restricted
by
yet
another
level
of
credentials,
github,
sort
of
github.
It
has
the
answer
to
all
of
the
the
workflow
problems
and
it's
that's
a
solution.
A
It's
like
improving
we're,
close
and
github
is
something
that
we
can
all
do
collectively
for
for
Cade
stocks,
and
so
you
know
helping
helping
them
to
do
that
with
us,
rather
than
trying
to
iterate
on
an
increasingly
increasingly
obsolete
publishing
platform.
Just
like
a
better
solution.
It's
a
way
to
resolve
technical
debt
as
well
yeah.
A
It
turns
out
they
were
very
happy
to
give
that
access,
but
they
would
be
even
happier
to
not
have
to
give
us
access
and
and
just
do
everything
inside
of
the
github
repo
cool,
all
right.
Okay,
so
that
solution
as
I
looked
at
it
a
little
bit
yesterday
and
that
migration
process
looks
non-trivial,
it
doesn't
look
like
it
will
be
huge,
but
it
is
non-trivial,
and
so,
if
there
is
anyone
who
is
interested
in
adopting
that
and
kind
of
shepherding
it
along,
that
would
be
really
awesome
to
do,
especially
if
you've
had
any
any
platform.
A
Migration
experience
before
this
would
be
a
great
opportunity
to
jump
in
and
and
do
that
I
you
know
give
some
thought
to
that.
I
would
I
would
love
to
manage
it
myself,
but
with
1.8
or
sorry,
with
1.9,
with
the
with
the
doc
Sprint's,
with
everything
coming
down
the
pike
in
q4,
it's
gonna,
be
a
little
busy
and
I'd
like
to
I
would
like
to
give
it
the
attention
I'd
like
to
give
the
migration
the
attention
that
deserves
I.
Don't
know
that
I
could
do
that
for
q4.
A
G
So
I've
been
talking
to
Tim
Hawken
and
it's
kind
of
clunky
and
no
longer
accurate
for
the
docs,
repo
or
I
mean
it
I.
Guess
generally
it's
the
whole
website
right.
So
it's
no
longer
accurate,
since
we're
not
hosting
on
github,
for
it
to
be
like
github
died
for
criminais.
Is
that
github
that
io?
So
there
is
a
nice
sort
of
like
redirect
mechanism
and
github,
so
we
can
rename
the
repo
and
any
connections
will
get
like
redirected
to
the
proper
one.
G
So
the
proposal
is
to
name
it
just
thinking
more
kind
of
hobbyists
and
it
could
be.
We
could
do
it
as
career
Anita,
I,
but
I
still
think
that's
clunky
I
think
if
we
just
did
it
as
the
committee
slash
website,
I'll
be
pretty
clear
on
what
it
is.
So
when
people
look
through
it
in
the
list
of
committees
repos,
it
would
be
pretty
obvious
so
yeah
it.
G
C
G
F
A
Generated
Docs
specifically
for
cube
admin,
and
this
I
think
will
be
a
precursor
to
a
longer
a
longer
presentation
about
automation
after
Joe
and
Andrew
and
Steve
get
the
chance
to
coordinate
about
automation.
But
Joe.
You
want
to
give
us
an
overview
of
what
you
have
learned
about
generated
docks
with
Cubana
yeah.
D
Absolutely
so
I
was
hunting
down
a
bug.
Just
picked
one
up
at
kind
of
random
and
was
tracking
it
down.
There
are
a
number
of
documentation
pieces
that
are
being
hosted
in
our
github
repository
that
are
generated
from
go
code
in
the
kubernetes
repository
itself,
and
it's
been
updated
with
a
script
in
there
called
hack
and
generate
Docs
that
doesn't
automatically
move
it
over,
doesn't
even
create
necessarily
the
correct
output.
And
then,
after
that
process
it
looks
like
we've
been
editing
the
docs
in
markdown,
not
necessarily
always
regenerating
them
from
scratch.
D
So
I
know,
there's
multiple
tendrils
to
this.
I've
only
found
one
portion
of
it
and
that's
just
related
to
the
cube
proxy
documentation
because
of
the
bug
that
was
filed.
So
I
want
to
just
sorry
I
wanted
to
throw
it
out
there
that
this
process
probably
needs
to
be
tweaked
a
little
bit
and
there
it
looks
like
there's
some
portions
of
this
that
are
being
generated
in
an
incubator,
repo
that
we
also
want
to
pull
in
I.
D
Don't
necessarily
have
a
proposal
or
a
plan
or
even
know
where
all
the
pieces
are
to
this
I
was
gonna
start
off
by
just
documenting
this
in
the
how
to
contribute
to
kubernetes
Doc's
and
mentioned
where
it
is
just
in
here's
the
reality
of
today,
and
then
we
figure
out
a
way
going
forward
so
want
to
throw
it
out
there
so
that
everybody
had
something:
oh
hey,
don't
do
that
or
whatever
we
could
tackle
it.
The
other
part
that
I
was
wonder.
D
Throught
was
a
suggestion,
perhaps
that
we
put
a
note
in
the
repo
under
that
admin
section
in
Docs
to
say:
don't
edit
these
directly,
we
generate
them.
Here's
where
to
go.
Get
that
information
on
how
to
do
it
so
that
we
don't
get
into
this
hand,
edited
not
updated
in
the
sources
upstream
kind
of
space
that
were
in
now
interesting.
D
E
Can
give
a
little
history
to
why
why
certain
things
are
in
the
incubator,
so
Phil
wit
rock
back
I,
don't
know
it's
probably
a
year
ago
really,
you
know
had
this
passion
to
get
the
the
reference
Doc's
in
this
format,
this
three-column
format,
where
you
had
left,
nav
and
Docs
and
then
examples
on
the
right
and
he
couldn't
get
a
lot
of
support
from
it
from
his
engineering
group.
So
he
pretty
much.
Did
it
as
a
weekend
project
and
has
you
know
it's
been
his
effort?
E
That's
that's
kept
that
going,
and
so
you
know
he
has
it
in
the
incubator
uh-huh
at
this
point
and
he's
getting
to
the
point
where
he
can't
he
just
doesn't
have
time
to
keep
maintaining
that
as
his
weekend
project.
So
I've
actually
I
have
volunteered
to
take
ownership
of
that
code.
So
I'll,
be.
You
know,
involved
in
this
effort
to
get
all
the
auto
auto
generation
story
sorted
out,
I'm
in
complete
agreement
that
we
don't
want
to
both
auto-generate
and
then
hand
tweak
the
docs.
A
E
It's
just
one
thing:
where
I
think
we
probably
want
to
keep
this.
We
don't
want
to
put
this
in
the
public
Docs
because
I
don't
think
we
want
it.
You
know
any
contributor
trying
to
figure
out
how
to
go
into
the
kubernetes
kubernetes
api
machinery,
repo
and
you
know,
propose
a
chain:
is
there
I
mean
maybe
later,
but
for
now,
let's
keep
this
knowledge
to
the
cig.
Okay,.
D
E
H
I
put
it
in
the
chat,
but
there's
more
of
this
on
the
way
from
the
coop
conformance
workgroup,
we're
annotating
the
e
to
e
conformance
test
so
that
we
can
generate
a
conformance
talk.
So
you
know
if
you're
gonna,
if
we
need
to
worry
about
that
as
well,
let
me
know
you'll
see
what
it's
generating.
It's
gonna
be
a
reference
stock
and
you're
like
hey,
there's,
yet
another
one
off
might
be
something
to
worry
about.
H
We
only
generate
one
dock
but
I'm,
just
if
you
look
at
if
Jo's
sound
like
five
others
and
we've
been
at
a
pull
request,
that's
about
to
get
merged,
so
it
says:
hey
we're!
Putting
all
these
annotations
in
and
we'll
generate
a
little
talk
as
well.
It's
just
one
more
down
the
pipe
and
get
more
details
on
it
and
what
it
generates.
But
yeah.
C
C
Yeah
I
definitely
agree
that,
like
this
is
like
we
don't
want
it,
we
don't,
we
don't
want
to
become
like,
like.
Oh
there's,
all
these
like
little
tiny
processes,
they
have
to
run
to
generate
everything
our
docks,
but
I
also
get
the
importance
of
automation.
So
why
don't
we
started
documenting
this
process?
You
know
it
sounded
like.
C
We're
trying
to
figure
out
where
to
document
this
to
start
with
yeah,
so
I
think
why
don't
we
start
a
Google
Doc
with
that
information.
Here
it
was
the
group
and
we'll
start
from
there
and
then
we'll
figure
out
a
place
to
land
it
I
I.
Think
this,
you
know,
I
know
wiki's
in
better
didn't
get
I've,
never
get
a
lot
of
a
lot
of
attention.
C
E
I
I
D
Tell
you
is
that
when
the
code
was
originally
being
developed,
they
took
of
these
CLI
arguments
that
are
in
a
library
called
Cobra,
that's
in
one
of
the
github
pieces
and
they
used
that
to
generate
the
output.
So
it
was
specific
to
a
CLI
which
is
not
necessarily
applicable
to
the
open,
API
stuff.
That's
happening
within
swagger
and
the
rest.
Api
is
a
whole
separate
set
of
API,
simple
right.
I
E
E
Way
that
works
is
that
the
this
way
this
is
my
best
understanding,
I
think
I'm
right
about
this.
This
this
this
document,
API
API,
something-something,
folder,
swagger
JSON,
is
automatically
generated
from
source
code
from
several
kubernetes.
Repos
then
fills
two
leti
now
has
in
kubernetes.
Incubator
takes
as
its
only
source
of
input
for
that
swagger
JSON
file.
E
A
Streamlining
API
generation,
that
being
able
to
point
to
all
of
this
stuff
concretely,
is
going
to
be
really
helpful.
So,
if
my,
my
guess
is
that
documenting
how
all
of
these
things
are
generated
and,
following
all
of
the
trails
back
to
their
back
to
their
origin,
who's
gonna
be
really
valuable.
Yeah.
E
Absolutely
so
one
of
my
big,
the
big
points
I
made
in
the
retro
from
the
1.8
release,
is
that
we
have
to
know
how
to
do
this
ourselves
and
we
have
to
be
able
to
do
it
a
few
times
during
the
lead-in
to
a
release.
Not
you
know
what
the
way
it
has
worked
is
that
near
the
other
release,
we
find
the
one
person
who
knows
how
to
do
it
and
ask
them
to
do
it
if
that
person
happens
to
be
on
vacation
for
a
week
or
something
but
we're
in
a
bar.
E
I
Small
thing
a
nice
to
have
in
the
short
term
I
would
think
I
would
hope.
A
must
have
in
the
long
term,
is
the
ability
for
writers
to
touch
those
strings
in
the
code
to
clean
up
places.
Where
shall
we
say
they
aren't
less
than
completely
helpful
they're
kind
of
classic?
They
aren't
exactly
like
Java
getters
and
setters
Docs,
but
they
read
like
that.
You
know
the
blank
endpoint
gets
the
blank.
That
kind
of
thing
I.
I
A
A
Moving
on,
let's
see
generated
X,
so
Jessica
and
Andrew
have
been
working
on
a
kubernetes
glossary
and
jessica
has
offered
to
provide
a
demo
of
the
glossary
so
take
it
away.
Jessica,
hey.
J
Can
you
guys
hear
me
mm
okay,
cool,
so
I
guess
the
main
point?
There
are
two
points
to
the
glossary
that
I
want
to
highlight.
The
first
is
for
a
newcomer
coming
into
the
kubernetes
Doc's,
there's
a
lot
of
terminology,
and
it's
not
clear.
What's
kubernetes
specific,
what
is
just
applicable
to
the
general
like
I,
guess,
cloud
native
ecosystem
and
things
like
that,
so
the
glossary
is
meant
to
enumerate
all
those
terms,
and
so
you
can
go
to
it
as
a
source
of
truth.
J
E
J
Through
these
has
is
also
provided.
J
Can
you
see
my
screen
now,
so
we
decided
to
put
it
under
reference.
We
can
decide
like
whether
we
want
to
surface
it
a
little
bit
more
publicly,
but
for
now
it's
just
gonna
sit
there
because
I
think
inception.
That
makes
sense.
So
when
you
get
to
the
glossary,
we
decided
to
have
the
fundamental
tag
all
by
default,
because
these
are
the
terms
that
you
care
most
about
as
a
newcomer
and
all
these
are
expandable.
J
J
J
And
they
work
I've
tested
them,
okay,
very
cool
and
then
also
like
they
have
links
attached
to
them.
So
if
I
wanted
to
be
able
to
link
directly
to
this
there's
the
permalink
that
you
can
always
go
to
like
there
isn't
an
actual
use
case
that
we'd
play
demonstrate,
but
I
just
imagine.
That
would
be
useful
at
some
point.
Also.
J
So
basically
the
idea
is
you
have
all
these
tags
if
you
like
hover
over
them
since
I
know
extension
might
not
be
clear
necessarily
to
someone
who
comes
in
so
it
has
like
that.
Little
short
description.
That's
flashing
around
right
now,
so
you
can
select
any
set
of
tags.
So
if
say,
for
example,
we
wanted
to
include
user
type.
J
Now
you
see
that
there's
like
application,
architect,
application
developer
and
so
on
and
so
forth,
and
for
all
these
I'm,
like
every
time
you
select
one
I'm
making
sure
to
update
the
URL,
the
idea
of
being
that
the
state
of
the
screen
that
you're
looking
at
now
is
reproducible,
so
you
can
share
it
with
other
people.
I
mean
it's
not
just
like.
Oh
go
to
this
page
and
make
sure
you
select
all
these
things,
so
you
can
select
all
of
them.
You
can
select
all
of
them.
I
J
So,
basically,
the
way
that
we
are
storing
all
this
information
are
in
the
ML
files.
So
there's
like
a
directory
of
connect,
canonical
tags
on
those
corresponds,
are
the
things
you
can
select
and
then
we
also
have
yellow
files
for
each
of
the
terms.
So
I
guess,
if
you
wanted
to
see
what
an
example
would
look
like
where
all
the
possible
things
like
it's
pretty
flexible.
If
you
wanted
to
add
more
attributes,
you
can
easily
do
that.
J
J
For
someone
to
be
able
to
search
that
and
then
there's
related
so
similar
terms,
you
might
want
to
look
at
tags,
which
is
what
we
just
went
over
in
short
description
and
long
description,
and
also
like,
because
we
know
that
like
I
guess
like
humans
are
gonna,
be
adding
this
stuff
and
we
want
to
make
sure
it
conforms
to
what
we
already
have.
So
we
also
like
added
something
to
the
CI,
so
that
if
someone
is
adding
a
tag
that
doesn't
exist,
it
like
will
error
out,
and
so
we
like
know
that
it
should
fix.
J
G
J
One
thing
that
I
thought
well
I,
don't
it
also
depends
how
many
people
are
find
this
page.
But
since
these
are
all
like
a
tags
and
you
have
like
the
little
the
Google
Analytics
plug-in
it
I'm,
not
sure
you'll
actually
be
able
to
see
anything
useful,
but
it'll
be
kind
of
neat
to
see
like
the
percentages
of
people
clicking
on
tags
or
expanding
out
terms,
and
things
like
that.
It'll.
J
And
definitely
like
I
think
as
a
continuation
of
this
like
this
is
just
like
the
starter
set
of
terms.
There
are
a
lot
more
terms.
We
obviously
want
to
define
so
I
think
we'll
probably
like
make
a
list
and
stick
it
in
the
project
and
anyone
who
wants
to
contribute.
It
can
probably
just
like
chip
into
that.
That's
awesome.
A
A
Just
sitting
here
like
thanks.