►
From YouTube: Kubernetes Sig Docs 20171017
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 17 October 2017.
https://github.com/kubernetes/kubernetes.github.io
A
All
right,
so
we
are
recording
hello
and
welcome
to
the
weekly
sig
Doc's
meeting.
This
is
the
sig
Doc's
channel.
If
you
were
expecting
cube,
admin,
maintenance
or
core
API.
Sorry
wrong,
meeting
I'm
happy
to
provide
you
to
look
the
link
to
the
community
calendar
with
all
the
goings
on
in
kubernetes,
but
this
is
sig
Knox,
so
welcome.
A
A
A
A
Okay,
crazy,
excellent,
alright.
Moving
on
to
recent
updates,
we
have
to
see
oscy
area
I've
seen
oh
Jessica,
okay!
Well,
I
will
note
you
down
and
put
a
note
here
that
you
will
follow
up
okay,
so
moving
on
to
recent
updates,
we've
got
to
sort
of
notable
updates
to
to
bring
to
light.
One
is
Andrew
and
Andrew.
Chen
and
Jessica
Yao
have
added
a
glossary
of
standardized
terms
to
the
kubernetes
reference
and
it
is
awesome.
A
A
A
So
the
glossary,
the
addition
to
the
standard
glossary,
awesome
DOS
likes
another
update-
is
that
in
the
Chinese
translation
process,
andrew
has
done
more
work
to
to
add
collaborators
for
the
Chinese
translation
teams
into
the
Cates
org,
and
has
also
done
some
of
the
groundwork
of
emptying
out
an
existing
repo
and
preparing
it
to
host
a
Chinese
translation
materials.
So
the
TLDR,
the
translation,
is
going
a
pace.
It's
coming
along
nicely,
uhh.
A
A
The
other
projects
that
Jared
is
proposed
for
docs
prints
are
improving
user
journeys,
adding
to
the
glossary
and
improving,
giving
better
documentation
for
the
release.
Note
process.
So
that's
that's
still
very
much
an
open
field,
though.
So,
if
you
have
ideas
for
what
we
can
do
at
docs
print,
this
would
be
a
great
time
to
add
them
great
time
to
bring
them
to
light,
because
we've
got
to
we've
got
to
start
narrowing
down
that
window
soon
and
start
choosing
what
we're
actually
going
to
do
and
start
preparing
for
it.
A
That's
okay,
think
about
it
and
if
ideas
come
to
mind,
if
you're
like
oh
yeah,
we
could,
if
we
just
got
like
a
whole
bunch
of
people
working
on
this
and
banging
it
out,
we
can
make
this
really
good
drop
us
a
note
or
drop
a
note
in
the
cig,
Knox
Channel.
B
Okay,
just
one
things
like
a
while
back
I
think
it
was
Andrews
working
on
a
contributors
guide
and
I
know:
I've
done
a
blog
article
about
how
to
use
tools
to
help
contribute.
Could
that
become
part
of
a
sprinter?
Is
that,
like
a
totally
different
work
item
kind
of
thing?
Well,.
A
B
A
That
would
be.
That
would
be
if
you
have,
if
you
have
something
in
particular,
that
like
a
particular
path
along
a
user
journey
or
a
particular
focus
area.
Inside
of
that,
that
would
be
a
great
that
that
would
be
a
great
thing
to
consider.
So
if
I
don't
know,
if
you
want
to
like
open
an
issue
for
it
or
just
like
write
a
paragraph
about
it,
well,.
A
A
I'm,
probably
and
yeah
just
I'm,
trying
to
think
about
the
best
way
to
communicate
that
information,
I,
think
yeah.
You
can
open
an
issue
either
drop
a
line
or
open
an
issue
either
those
are
available
to
go.
Okay.
Okay,
thank
you.
Let's
see,
I
see
a
note
from
Jennifer.
We
should
probably
figure
out
a
way
to
document
who's
already
working
on
currently
to
find
user
journeys.
That
would
be
awesome,
and
that
would
be
a
great
thing
to
put
it
in
issue.
C
So
far
we
are
were
maintaining
this
pages
manually
and
we
want
to
improve
making
some
something
similar
to
what
was
already
done
for
Cuba,
CTL
or
Fed,
where
part
of
the
reference
doc
is
generated
from
from
the
cobra
combo
command
description
and
Earth.
So
we
want
to
move
from
maintaining
pages
manually
to
generating
part
of
the
documentation
automatically,
and
so
we
have
a
guarantee
to
keep
the
documentation
line
with
the
code
and
and
as
well.
We
want
to
maintain
some
Estrada
to
explain
advanced
edit
topic,
Advanced
Edition
topics
which
are
already
embedded
in
the
documentation.
C
C
D
Pretty
oh
sigh
since
I'm
the
one
who
probably
wrote
a
vast
majority
of
that
document,
you're
now
digging
through
realized
that
it's
a
lot
more
archaeology,
even
necessarily
it's
the
way
that
you
should
do
it.
That's
you
know
it's
not
a
bad
thing.
It's
just
I
think
this
section,
where
we
mix
between
hand
edited
and
generated
mutation
has
grown
fairly,
organically
and
outside
of
the
area
that
so
what
rock
is
really
put
in
some
Yeomans
labor
to
manage
it's
gotten.
D
A
So
we
too
are
trying
to
figure
out
how
to
get
to
the
root
of
our
own
automated
dock
processes.
There
has
not
been
a
lot
of
institutional
knowledge,
preservation
or
transfer
between
when,
when
the
automated
processes
were
first
set
up
and
how
they
are
maintained.
Presently
so,
like
Joe,
said,
a
lot
of
what
he
is
doing
is
archeology
he's
digging
through
the
the
layers
of
process
and
providing
investigative
findings,
rather
than
providing
a
sequential
how
to
document.
That
is
our
ultimate
goal,
but
we
are
not
there
yet
so.
E
C
C
C
A
Generally,
the
best
way
to
make
when
it
comes
to
actually
updating
the
documentation.
The
best
way
is
to
open
an
issue
or
open
a
poll
request
against
the
documentation,
with
the
actual
changes
that
you
want
to
make,
but
in
terms
of
coordinating
which
PRS
to
open
against
which
material
and
what
to
change.
A
A
E
F
F
F
They
are
and
then
also
like
the
lines
of
code,
and
then
Steve
Perry
mentioned
that
he
wanted
to
be
able
to
add
commentary,
and
it's
like
super
janky,
but
I
was
like
I'm,
just
gonna,
stick
a
box
over
on
the
right
and
so
like
when
you
hover
over
it
like.
If,
if
there
is
like
an
attached
comment,
it
will
like
change
so
I,
don't
know
we
can
talk
more
about
the
UI.
I
can
show
the
clipboard
actually.
F
So
if
you
copy
the
code
to
your
clipboard
and
then
go
over
here,
I
make
it
so
that
it
only
copies
the
lines
that
actually
are
code.
So
like
these
two
lines
and
it
doesn't
copy
everything
else
and
so
I
guess
like
if
you
guys
have
feedback
on
the
UI
immediately
I,
don't
know
if
we
should
talk
about
that
first
or
if
I
can
go
into
the
second
part,
which
is
like
the
Jekyll
integration.
A
There
was
a
discussion
about
a
month
ago
about
whether
or
not
to
include
the
command
prompt
when
we
give
or
in
code
samples
whether
did
not
to
include
the
command
prompt
and
Jessica
offered
to
provide
a
demo
of
kind
of
a
best
of
both
worlds
solution
where
we
can
show
the
show
the
command
line
prompt
in
code
samples,
but
they,
but
when
you
go
to
copy
to
code
like
the
actual
code
sample,
the
command
prompt
doesn't
copy.
So
that's
what
this
demo
is
is
what
that
might
actually
look
like
in
practice.
Sorry.
F
So
I
guess
like
maybe
it
will
provide
a
bit
more
context
about
like
what
I've
been
working
on
there
thinking
about
so
this
is
just
like
what
it
would
render
to
like
the
markdown
would
render
to
this.
But
the
reason
it's
been
taking
me
more
time
is
that
I
want
to
keep
it
as
similar
to
the
old
markdown
syntax
as
possible,
where
you
have
like
those
back
ticks,
and
then
you
specify
the
language,
because
that's
what
people
are
familiar
with
like
hypothetically,
it
would
be
easier
if
I
just
made
it
a
new
Jekyll
type.
F
I,
don't
know
if
people
would
like
you
know
to
use
it,
and
so
the
question
that
I
want
to
ask
you
guys
is
what
how
the
markdown
should
look
to
get
this
get.
This
thing
up,
like
I,
can
take
care
of
actually
like
writing
the
parser
and
things,
and
that's
what
I've
been
working
on,
but
I
want
to
have
a
UI,
that's
more
friendly,
so
I
had
three
options
here
and
obviously
there
might
be
other
things.
I
haven't
even
considered.
So
this
is
something
that
I
there's
a
existing
sample
online.
F
That
looks
similar
where
it
keeps
like
the
little
language
thing
here,
but
it
also
adds
other
options
I'm,
so
like
user
root
host
local
host
output,
a
zero
indexed
exciting,
like
a
lot
of
programmers,
are
used
to
that.
But
it's
basically
saying
that
lines
1
through
5
aren't
going
to
have
the
little
prefix
thing
and
then
for
Steve's.
F
Just
yet,
but
like
that's
a
limitation
with
this
kind
of
syntax
and
so
like
another
ID.
Another
idea
is
having
something
that
looks
more
like
this,
where
you
just
tell
you
just
indicate
whether
or
not
there's
a
prefix
that
we
should
be
looking
out
for
and
whether
or
not
they're
comments,
and
if
so,
it's
completely
custom.
So
you
can,
it
doesn't
just
have
to
be
localhost.
It
could
be
any
other
thing
and
then
like.
F
That
will
make
sure
to
fill
in
that
comment.
Blurb
like
this
black,
this
gray
box
thing
with
whatever
content
is
in
here,
but
the
thing
about
this
is
I.
Just
don't
like
these.
These
two
I
think
are
definitely
more
readable
than
what's
here,
but
I
also
think
that
also
means
that
they're
kind
of
more
annoying
to
write,
because
then
you
have
to
like
stick
prefix
up
readers
everywhere.
F
So,
like
I,
don't
even
know
if
this
is
like
something
that,
if
it's
user
friendly
enough,
that
people
would
want
to
write
this
kind
of
stuff
if
it
provided
this
sort
of
functionality.
So
if
people
feedback
on
that
I
think
that's
pretty
important.
So
that's
I'm,
open
to
like
people,
can
just
chip
in
now.
If
they
want.
B
B
Were
like
you
know,
I
almost
felt
to
me,
like
the
other
two,
yes
they're,
more
customizable,
but
then
it
felt
like
I
had
to
work
really
hard
to
get
that
cool
feature,
whereas
in
the
first
one
I
was
like
boom.
I
got
that
cool
feature
pretty
much
right
away
and
that
that's
what
popped
in
my
head?
Okay,.
F
D
Jessica
this
is
Joe
the
for
the
comments.
I,
don't
know
if
there's
a
an
easy
way
to
handle
this,
but
many
of
the
larger
code.
Samples
you'll
often
want
comments
on
their
own
mind
or
above
or
below
and
I
think
you
can
probably
accommodate
that
reasonably
well
with
just
including
it
like
your
shell
commands
with
just
a
comment
prefix,
so
that
they
would
normally
be
hidden
from
a
shell
command.
If
you
copied
and
pasted
it,
we
got
away
with
it.
So
that
might
be
an
alternative
to
putting
the
commentary
on
the
side
that
sits
off.
F
F
A
A
Raters
and
that
makes
a
code
sample
less
maintainable
and
less
less
shareable
overall
and
the
ability
to
for
human
to
parse.
It
is
important,
but
if
we
I'm
also
thinking
about
the
future
like
if
we,
if
at
some
point
for
whatever
reason,
we
decide
to
separate
like
two
separate
code,
samples
to
extract
them
from
the
documentation
or
two
to
import
them
by
reference.
Yeah,
it's
having
a
good
sample.
That's
maintained
on
its
own
I.
A
F
D
A
A
Alright
anything
more
Jessica,
that's.