►
From YouTube: Kubernetes Sig Docs 20180130
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 30 January 2018.
https://github.com/kubernetes/kubernetes.github.io
A
Let's
see
follow-ups
from
last
meeting
bought
automation,
it's
alive,
it's
awesome,
hopefully
Joe
heck
will
show
up
here
in
a
minute
or
two,
and
we
can
talk
more
about
what
reviewers
and
approvers
what
those
roles
look
like
specifically
in
the
context
of
having
automation
but
ya,
know
it's
amazing
to
have
the
same
bot
automation
that
other
kubernetes
takes
and
repost
have
across
the
organization.
So
he's
not
here,
but
thanks.
A
Aaron
cricket,
burger,
you're,
awesome,
yeah,
okay,
Steve
I,
put
an
item
on
here
to
talk
about
the
style
guide
that
it's
important
work
and
I
want
to
make
sure
that
it
doesn't
get
dropped
or
or
forgotten
sort
of
out
of
our
stream
of
consciousness.
I.
A
Put
a
link
to
that
pr4
70/30,
which
I
think
is
really
good
work.
Is
there
anything
else
that
we
need
to
cover
or
any
initiatives
that
haven't
been
really
picked
up
yet
in
terms
of
getting
the
style
guide
really
updated?
Is
there
any
help
that
you
need
you?
Can
you
do?
You
want
to
say
a
little
bit
more
just
about
where
we
are
with
the
style
guide.
B
Yeah
I
guess
I'd,
like
people
who
have
you
know
opinions
about
this
to
chime
in
in
the
issue.
I
got
one
comment
from
Joe
who
says
it
looks
good
to
him,
but
if
people
want
to
go
in
there
and
make
comments
on
the
specific
you
know
the
specific
suggestions
I'm
making
about
to
update
and
what
areas
to
revisit
that
would
be
helpful,
and
you
know,
regardless
of
how
many
comments
I
get
I,
would
say
sometime
this
week,
I'll
start
start
a
PR
for
updating
the
style
guide.
C
Okay,
so
so
I
get
the
missing
information
bit
I
mean.
That
seems
pretty
pretty
clear
to
me
any
at
least.
What's
not
as
clear
to
me
is
the
revisiting
guidelines.
Mm-Hmm
I
can
think
of
all
kinds
of
reasons
why
to
do
it,
but
if
I
understand
why
you
want
to
revisit
especially
the
specific
ones
that
you
were
not
it
might
help
me
think
differently.
You
know,
or
maybe
more
usefully
or
hopefully
about
about
this
stuff.
C
A
B
Think
I
can
give
a
quick
answer
to
the
question
of
the
Jennifer.
Just
asked
and
it'd
be
good
to
do
that
here.
Yeah
go
for
it,
so
the
the
reason
I
listed
these
areas
to
be
revisited
is,
is
because,
when
I
was
reviewing
the
new
content,
that's
being
written
for
user
journeys,
all
of
these
guidelines,
I
saw
violated,
and
so
I
just
I
wanted
to
know.
If
people
still
agree
with
these
guidelines
and
if
so
I'd
like
them
to
be
followed.
B
C
It
does
I,
don't
know
whether
we
want
to
take
any
more
of
this
discussion
in
this
meeting
or
not,
but
I
find
it
might
I
find
it
useful
to
talk
about
this
stuff
in
the
middle,
because
I'm
struggling
with
the
stuff
myself
I
mean
I.
Think
that
you
know
the
goal
of
making
this
style
guide,
something
that
we
actually
enforce
and
making
it
enforceable.
C
D
C
I
so
especially
in
the
context
of
the
kubernetes
documentation,
I
think
to
sort
of
step
back
one
level
of
abstraction
from
the.we
versus
you,
and
it
seems
to
me
that
it's
useful
to
write
with
an
awareness
of
the
usefulness
of
both
terms
right
so,
but
that
by
if
by
default,
were
addressing
the
user.
Assuming
that
the
user
is
not
in
fact
someone
helping
create
either
the
documentation
or
the
code,
then
you
seems
most
useful,
but
then
what
that
would
let
us
do
is
reserve.
C
We
for
the
personification
of
the
kubernetes
development
community
might
not
be
a
useful
distinction
and
we
could
get
agreement
about
what
it
means.
But
I
think
like
this
about
word,
choice
and
and
I
guess
you
know
the
other
examples
and
I
mean
Steve's.
Other
examples
are
things
that
I
notice
a
lot
the
jargon
and
idioms
in
particular,
and
latin
phrases.
C
I
closely
related
right.
There
were
reasons
relating
to
disability
is
reaching
as
broad
an
audience
as
possible.
Why
those
that
guidance
in
documentation
circles
and
has
existed
for
quite
some
time?
Maybe
they
aren't
as
relevant
to
as
they
once
were,
or
maybe
they're
not
relevant
to
the
kerbin
in
his
community,
but
maybe
they
are.
How
do
we
know
and
then
it
also
comes
back
to
the
enforceability
issue,
which
is
I,
think
what
Steve
is
speaking
most
immediately
so.
A
A
So
I
mean
I,
mean
I,
know
Jennifer,
you
and
I
are
both
the
verbal
processors,
and
so
maybe,
if
we
like
have
a
schedule
time
where
we
can
just
talk
all
this
through.
That
would
be
really
good
and
useful,
but
I
also
don't
want
I
want
to
make
sure
that
that
this
discussion
gets
all
of
the
attention
it
deserves,
and
if
we
want
to
have
like
a
special
weekly
meeting
for
it,
then
sure
we
can
do
that,
but
maybe
just
another.
Maybe
a
special
topic
meeting
I'm.
C
Fine
with
whatever
I'm,
also
I,
think
that
I
will
try
to
you
know
commit
some
of
these
thoughts
of
mine
to
the
issue
comments
to
preserve
a
bit
more.
But
thank
you
for
letting
me
process
in
the
meeting
a
bit.
The
seals.
E
B
So
an
example
of
some
things
that
we
might
put
in
the
style
guide
that
you
know
Jennifer
was
saying
well,
we
might
not
want
to
get
too
detailed,
but
there
are
things
that
we
tend
to
do
and
a
word
choice
is
one
of
those,
so
in
most
style
guides.
If
you're
on
a
writing
team
you'd
see
some
list
of
words
that
are
preferred,
so
we
might
prefer
to
say.
B
Might
we
need
possibility
and
may,
when
we
need
permission
but
not
to
crisscross
between
the
two
and
that
might
be
getting
a
little
too
detailed
for
a
style
guide?
That's
it's
part
of
an
open
source
effort,
so
there's
that
second.
The
second
comment
is
that
it
might
be
okay
for
us
to
be
a
little
more
detailed
than
what
we
will
actually
enforce
in
the
open
source
world
just
so
that
we
know
what
we
as
writers
are
shooting
for.
So
I
don't
mind
having
style
guidance
like
we
prefer
might
for
possibility.
May
for
permission.
B
We
don't
want
to
save
the
words
cinch
as
a
substitute
for,
because
that
gives
that
way.
We
can
agree
on
what
you
know
how
we
want
to
write,
but
it
doesn't
mean
we
have
to
enforce
every
last
one
of
those
details
when
we're
taking
a
PR
from
someone
from
outside
our
little
group.
You
know
from
the
community
sure
so.
D
It
sounds
like
you
have
essentially
the
the
classic
80%
solution
you
put
in
the
higher
bar
and
you
know
worst
case
we're
going
to
get
80%
of
what
we
want
just
from
the
core
group
and
the
other
folks.
Well,
you
can
always
you
know,
update
their
patches
later
right.
You
can
always
let
it
go
in,
and
somebody
can
do
a
little
cleanup
later
too,
but
but
it's
not
the
end
of
the
world
either
way
right.
B
Right-
and
we
talked
last
time,
I
think
about
the
idea
of
if
someone
does
a
a
pull
request,
it's
an
edit
of
an
existing
doc.
We
don't
necessarily
want
to
take
that
opportunity
to
clean
the
entire
doc.
Usually
we
we
probably
want
to
restrict
our
our
editing
to
the
portion.
That's
been
changed
and
then
maybe
open
an
issue
to
later
revisit
the
entire
doc
sort
of
style
guide,
upgrade.
A
Is
that
what
you're
thinking
of
yes
saying
we
follow
the
style
guide,
with
the
following
exceptions
and
then
I
think
thinking
specifically
about
like
call-out
format,
which
I
think
is
unique
to
do.
Kubernetes
like
if
there's,
let's
I,
guess
what
I'm?
What
I'm
saying
is:
let's
find
a
good
example
of
a
style
guide,
we'd
like
and
make
changes
to
it
as
necessary.
B
G
There's
a
pull
request,
template
in
the
doc,
github
or
I,
think
it
wouldn't
hurt
to
plop
in
a
also
please
refer
to
a
style
guide
link
some
when
people
do
a
pull
request.
They
they
know
that
there's
a
style
guide
because
I've
known
it
was
there
and
it
wasn't
until
you
mentioned
that
I
was
like
I
should
be
checking
that
when
I
do
pull
requests
and
I
always
forget.
C
G
H
A
Okay,
anything
else
about
the
style
guide
right
in
this
moment.
H
A
A
A
A
Would
as
much
about
volunteering
for
reviewing
duties,
Joe
is
the
one
who's
puttin
a
lot
of
work
on
opening
a
pull
request,
specifically
to
talk
about
Joe
open
to
PR,
to
get
really
specific
about
call
requests
like
reviewers
and
approvers
and
has
has
done
a
lot
of
the
work
that
we've
been
talking
about
needing
to
be
done,
so
I
would
love
to
have
Joe
be
the
one
to
walk
us
through.
That
is.
Is
everyone
okay?
If
we
defer
this
a
week
for
for
Joe
to
guide
us
through
it.
A
H
A
We
have
a
number
of
teams
with
varying
levels
of
access
to
our
repo
and
I,
don't
know
if
we
want
to
try
and
clean
this
up.
If
there's
no
problem
here,
we
can
just
leave
it
be
or
if,
if
we
want
to
do
anything
in
particular
with
this,
the
the
only
thing
that
I've
done
so
far
is
gone
through
and
changed.
A
Coober
kubernetes
maintainer,
so
change
back
to
write,
x
or
read
access
Jarrid
enabled
that
for
right
access
in
the
course
of
the
1.8
release
and
then
just
never
remembered
to
set
it
back
to
read.
So
that's
the
one
change
that
I've
made
so
far.
I
guess:
I,
don't
know
enough.
I,
don't
have
enough
context,
I'm
still
new
enough!
That
I
don't
know
enough
context
about
about
all
of
these
particular
teams
and
like
levels
of
individual
access.
B
A
B
But
some
of
these
people
I
think
maybe
are
already
in
the
sig
Docs
maintainer.
So
it's
moot
that
they're
listed
here.
We
could
get
them
completely
off
this
list.
I
think
somebody
like
keep
making
I
ought
to
be
in
sig,
Docs,
maintainer,
xand
and
Brad
ought
to
be
in
sick
dogs
maintainer,
and
if
we
want
to
grant
those
two
people
right
to
access.
Just
during
you
know
the
the
week
or
so
it
takes
to
make
that
happen.
I
think
that'd
be
fine,
so.
A
Brad
I
am
100
set
behind
joining
sick
maintainers.
If
you
want
to
Brad.
Oh
please
thank
you
for
keying
in
particular,
I'd
like
for
him
to
start
attending
our
meetings
and
reluctant
to
have
someone
be
a
maintainer
and
not
be
participating
in
the
discussion
in
the
life
of
what
we
do.
Remember
they
I
can
I
can
say
more
about
that
Steve,
but
I
would
rather
have
that
conversation,
offline,
yeah,
sure,
okay,
so
Brad
yeah.
Let's
get
you!
Let's
get
you
into
sick
doc.
Sweeteners
you've
been
voluntold,
Thank,
You,
Samana
and
I.
A
H
B
If
well,
I'm,
not
sure
it
is
I
mean
there's,
there's
a
collaborator
with
read
access,
but
if,
if
you're
not
listed
as
read
access,
it
may
be
that
you
have
even
less
permission
than
that.
We
should
look
into
that.
We.
B
B
A
That's
why
it
was
so
originally
a
lot
of
these
like,
like
set
of
like
Tina
Chang
like
Larry
Avangate.
These
are
all
participants
at
the
duct
sprint
in
Austin,
so
I
think
that's.
That
was
the
sort
of
the
emergency
measure
to
make
sure
that
they
could
contribute
was
adding
them
as
individual
collaborators
to
the
repo
to
short-circuit
the
whole
joining
the
organization.
A
B
I,
don't
know
I,
don't
think
we
can
until
they're
members
of
the
kubernetes
organization
right.
So
I'll
take
this
as
a
work
item
to
go
through
that
list
of
individuals
and
primitives.
You
know
any
obvious
pruning
I'll
do
like
if
somebody's
already
in
the
organization
and
in
one
of
these
teams,
I
can
take
them
out
of
the
individual
collaborator
list
and
then
maybe
after
after
I
do
that
then
next
time
we
can
see
what's
left
and
you
know
how
much
we
want
it
sure
yeah.
E
A
A
B
A
E
A
I'm
thinking
about
Joe
heck
specifically
talked
about
that
in
his
in
his
review
all
right
say
in
the
any
additions
that
he
was
making
in
the
PR
for
reviewers
and
approvers.
My
stance
on
it
was
that,
yes,
we
can
have
a
different
group.
I
I,
don't
I'm
I,
don't
think
I'm
in
favor
of
publicizing
that
that
that
alias
is
available,
because
it's
almost
never
required
but
I'm
open
to
changing
my
mind
on
that.
A
A
E
Well,
okay,
so
we
stripped
out
the
stuff
that
we
weren't
going
to
launch
with
like
the
migration
path,
but
we
and
then
the
users
were
just
keeping
the
application
of
upper
and
cluster
operator
personas
to
start
with,
and
then
we
have
like
the
foundational
intermediate
and
advanced
topics
level
and
for
like
the
application
developer
and
for
I
think
all
three
levels.
We
have
a
Content
page,
that's
like
kind
of
a
breakdown
of
like
what
you
should
learn
it
in
what
order
you
know.
So
we
have
like
kind
of
that
gets
started.
E
You
know
pretty
much
stuff
in
an
environment,
deployment
application
and
then
understanding
some
of
the
you
know
concepts
and
then
you
know
some
additional
resources.
So
we
have
that
for
the
foundation.
Intermediate
level
and
advanced
topics
are
things
that
not
everyone
needs
to
use
for
their
cluster
or
the
application
so
and
then
for
the
cluster
operator.
I
think
you've,
enhanced
topics
I
just
linked
out
to
we
didn't
want
to
spend
time.
I
guess,
writing
a
whole.
E
Another
content,
patient
I'm,
just
linking
out
to
some
existing
content
that
we
have
so
that's
gonna,
be
our
cheat
for
now
as
the
MVP
and
then
contributors
will
have
like
the
docs
contributors
stuff,
which
is
our
existing
content
and
then
there's
code
contributor
that
links
out
to
the
community
documentation.
I.
Think
that
that
we
imported.
E
George
and
then
there's
community
contributor,
which
are
like
the
mentoring
stuff,
more
related
to
like
parros's,
and
so
that's
what
it
looks
like
right
now
and
then,
if
you're,
when
I
just
go
back
to
the
way
things
were
and
just
like
for
out
the
docs
directly.
There's
a
browse
Doc's
button,
which
will
show
like
the
high
level
topics
for
each
of
the
that
we
have
that
way.
It
should
bridge
the
gap
with
thee
from
the
old
to
the
new
Saren.
D
D
This
is
absolutely
incredible:
I
love
how
you've
got
you
know
the
different
different
ways
through,
but
at
the
same
time
I
get
to
come
there
and
it's
one-stop
shopping
for
me
on
that
page
and
I
can
figure
out
the
best
place
to
where
I
need
to
go.
I've
I've
been
dreaming
for
this.
This
is
really
cool
and
then
you've
got
browse
the
docks
just
this
is
this
is
awesome
thanks.
This
is
so
coarse.
Oh.
E
A
E
E
And
then
sorry
for
joining
late,
the
other
person
that
was
here
not
sure
where
he
went
probably
another
meaning,
is
Phillip
Mallory
and
he's
a
new
cooler
and
he's
gonna
be
in
our
container
docs
team.
So
he
may
be
popping
in
on
these
meetings.
I
think
he
will
mostly
be
on
the
gke
side
but
like
we
may
have
them
do
some
kubernetes
stuff.
Occasionally,
oh.
B
Awesome
I
have
one
comment
on
the
user
journeys
as
we're.
Looking
for
topics
you
know,
we've
talked
about
which
topic
should
we
make
a
full
pass-through
and
bring
them
into
alignment
with
the
style
guide
and
make
sure
they're
accurate,
and
all
of
that
I
think
a
great
place
to
look
for
those
is
go
through
the
user
journeys
and
see
which
topics
we
link
to
and
those
are
the
those
of
the
topics
that
should
be
high
priority
for
making
sure
they're
the
best
they
can
be
absolutely.
A
A
A
Who's
job
will
be
to
focus
on
the
content
of
kubernetes,
making
sure
that
the
the
content
is
constantly
getting
attention
and
somebody
who's
dedicated
to
actually
improving
the
the
documentation
itself.
I
am
sort
of
torn
in
many
directions,
with
various
like
managing
different
CN
CF
documentation,
projects,
managing
different
layers,
so
sort
of
more
involved
in
the
process
of
kubernetes
documentation
than
the
documentation
itself
is
more
than
I'd
like
to
be
so
I'm
hiring
I'm
looking
to
hire
a
writer
who
can
focus
on
kubernetes
content.
A
A
Yes
would
gladly
take
recommendations
or
referrals,
so
George
I
apologize
I
did
not
see
that
you
had
added
an
item
to
the
agenda.
I
thought
you
were
just
showing
up
here
under
the
goodness
of
your
heart,
not
to
say
that
you
can't
do
both
but
yes,
George.
Let's
talk
about
static
generation
of
the
community,
repo
ducks
yeah.
G
E
Yeah
so
I
mean
this
script
is,
is
in
the
website
code,
so
you
can
run
it
yourself
and
then
you
know
government
appeal,
okay,
yeah,
but
then
yeah
the
next
step
would
be
to
automated
I
think
we
were
just
doing
it
manually
now.
As
for
Steve
suggestions
to
like
work
out
the
kinks
and
then
once
okay,
if
we've
constantly
writing
it
and
it
seems
fine,
then
we
can,
you
know,
feel
free
to
build
sort
of
like
a
automated
piece
or
I
mean
we
I
guess
we
can
kind
of
figure
out
how
to
do
that.
Yeah.
E
So
we
can
find
a
different
place
in
the
documentation.
I
just
I
think
there's
an
initial
thing.
We're
just
like.
Well,
we'll
put
all
the
importer
docs
there,
but
the
script
you
can
specify
exactly
like
you
know
where
it's
coming
from
and
where
you
want
to
put
it
in
the
website.
Okay,
so
you
can
change!
You
can
change
that
right.