►
From YouTube: Kubernetes Sig Docs 20170926
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 September 2017.
A
B
Documenting
I've
been
documenting
docker
containers
kubernetes
things
like
that
for
quite
a
while
and
I'm
here
to
see
how
I
can
help
awesome.
A
D
Yeah,
if
you
can
hear
me,
my
sound,
is
working
yes,
excellent!
Sorry,
it's
like
3:30
in
the
morning
here
so
I'm,
a
little
old
man
I'm
a
bit
scattered
my
name's
Andrew,
but
I'll
throw
him
over
to
be
on
for
sec.
Oh
yeah
enter
Daniel
I
also
work
at
Red
Hat,
and
my
experience
with
this
is
working
through
open
ship
documentation.
A
C
E
I'm
actually
going
to
be
just
right:
the
docks
in
Melbourne
doing
a
kubernetes
dock,
sprints
number
24.
So
you're
more
than
welcome
to
join
me.
So.
D
A
F
F
Only
so
there's
still
some
outstanding
real
content
issues
that
I
think
we're
successfully
chasing
down
today,
places
where
either
we've
got
something
inadequate
information
or
missing
information,
and
we
are
at
the
same
time
trying
to
go
through
and
just
clean
up
some
of
the
language
for
tightness
clarity
whatever,
and
we
will
have
a
lot
of
space
in
the
retrospective
fingers,
but
just
saying
okay,
you
know
we
can
propose
better
and
more
automated
processes
going
forward.
There
are
also
a
lot
of
dependencies
because
it's
not
really
about.
F
We
could
propose
a
release,
notes
template,
but
until
the
whole
process
of
defining
what
constitutes
the
release
is
clarified,
there's
not
a
whole
lot
more.
We
can
do
except
say:
okay,
here's
a
template,
here's
how
we
can
automate
skooby
content
in,
but
you
all
have
to
get
your
issues
and
PRS
stuff
sorted
before.
That's
really
useful.
That.
E
I
just
had
a
quick
question:
I
noticed
that
the
when
it
comes
to
that
one
line
that
people
are
supposed
to
send
in
with
their
PR.
So
what
to
add
to
the
to
the
release?
Notes
good
that
people
really
didn't
fill
that
out.
How
are
you,
how
are
you
getting
information
about
what
goes
in
the
release
notes
so.
F
So
what
happened
is
for
one
seven
people
were
using
that
line
and
I
think
it
was
dawn.
Chen
wrote
a
script
to
scoop
that
stuff
in
automatically
I
am
not
quite
sure
why
that
approach
was
abandoned
for
1.8,
but
it
was
and
there's
a
single
markdown
file
in
the
release
folder
in
the
futures,
repo,
where
people
have
been
manually,
adding
content.
Some
folks
have
chosen
simply
to
scoop
out
copy
paste.
The
release
note
strings
that
they
add
it
to
their
PRS.
F
F
E
F
Yeah
ad
hoc
from
this
pigs
chasing
down
Said's,
say
and
put
it
in
put
it
and
we've
been
doing
that
for
weeks
and
there's
one
at
least
one
last
minute
thing
chunk
of
content
that
I
actually
have
identified
this
morning.
So
that's
good
and
I've
got
a
meeting
right
after
this
one
I
mean
I
need
to
drop
off
at
11:00
to
chase
down
a
few
more
details
about
some
stuff
that
could
use
a
little
more
love.
F
F
Do
think
that
whether
we
get
the
overall
whether
the
larger
group
gets
the
overall
issues
and
PRS
stuff
sorted
four
one:
nine
that
even
providing
a
better
template
will
help
it's
not
the
whole
solution.
But
you
know
folks,
who
are
being
invited
to
write.
Please
know:
content
need
some
better
guidance
about.
What's
right,
yeah.
E
E
F
F
Exactly
exactly
there's,
there's
no
difference
here
really
at
a
certain
point.
It's
a
matter
of
how
to
get
the
right
content
into
the
right
place
and
I
think
that's
all
I
have
to
say
about
that
right.
Now:
okay,
but
yeah,
good
question:
I
was
a
little
confused
about
them.
Moving
away
from
the
automated
process,
but
I
didn't
have
enough
information
to
even
ask
the
right
questions
at
that
point
and
I'm
sure
that's
gonna
come
up
during
the
retro
yeah.
A
I'm
curious
for
the
retro
I
think
it'll
be
good
feedback
for
like
Jace
to
Mars
for
like
what
what
went
well,
what
can
go
better
specifically
for
the
release,
notes
process.
So,
yes,
I'm
really
looking
forward
to
to
the
retrospective
and
hearing
what
emerges
and
what
can
be
better
for,
like
1.9
1.10.
F
Clear
about-
and
this
really
affects
how
I
contribute
to
a
release-
notes
discussion
is
the
way
that
issues
versus
PRS
are
managed
for
kubernetes,
because
it
doesn't
meant
to
any
previous
project
experience
that
I've
got
I'm
accustomed
to
release.
Note
content
belonging
to
an
issue,
not
a
PR
and
PRS.
All
of
them
being
clearly
mapped
issues
referring
back
to
there
being
real
virtuous
cycle
there.
That
doesn't
seem
to
be
how
kubernetes
releases
work.
E
F
F
Then
individual
PRS
will
point
most
often
to
issues
not
to
features
okay,
I'm
glad
I
said
something.
I
didn't
want
to
take
up
too
much
of
this
meeting
with
these
with
this
discussion,
but
this
is
really
useful
because
it's
helping
me
think
about
how
to
present
to
the
retro
yes
murky.
For
me
for
quite
a
while
and
it's
getting
clearer,
clear
earth,
please
notice
it's
not
so.
F
Haven't
yet
because
I've
been
well
a
worried
more
about
the
release
content
and
be
thrashing
around
with
what
to
put
right
so
y'all
have
just
helped
me
at
least
clarify
what
I'd
like
to
contribute
to
that
document.
So
thank
you
very
much
and
obviously
it's
open
anybody
else
can
go
in
and
say
well
what
about
this?
So
maybe
I
can
toss
additional
questions
in
there
and
if
you
all
want
to
take
a
look
and
like
clarify
things
that
I
just
don't
know
because
I
haven't
had
enough
experience
with
release
cycles.
That
would
be
awesome
too.
F
G
A
That
that
I
remembered
from
the
1.7
retrospective,
that
there
was
a
specific
reason
for
moving
away
from
automation,
that
that,
like
feature
developers
had
been
using
that
field
for
information,
other
than
release
notes
and
basically
the
the
auto-generated
results
were,
were
not
helpful
and
not
useful.
That
there
was
that
it
was
that
it
was
scooping,
whatever
people
were
putting
in
there,
which
is
designed
to
do
but
people
weren't
putting
in
good
information.
And
so
that's
what
I
think
I
remember
from
1.7.
A
E
Historical
context,
I
mean
I.
Well,
what
do
you
to
your
comment?
I
think
it
refers
to
PRS
because
we're
using
we're
tracking
documentation
as
PRS
that
relate
to
a
huge
feature
that
then
relate
to
each
of
larger
logs,
there's
kind
of
like
a
tree
where
you
have
like
one
dates
and
then
a
set
of
features
and
a
set
of
PRS
that
relate
to
those
features
and
then
all
notes
each
of
those
PRS
each
those
features-
it's
not
it's
not
clear,
nobody's
actually
likes
that
done
documented.
E
That
said
like
this
is
how
it
is
everybody's
just
kind
of
running
around
with
that
some
she
version
about
that
model
in
their
head.
For
for
the
previous
release,
you're
right,
there
was
an
engineer
driving
that
efforts
who
do
a
lot
of
automation
around
it,
and
it
was
scooping
up
a
lot
of
content,
but
then
nobody
was
reviewing
and
they
were
just
kind
of
throwing
it
in
the
rowboat.
So
it's
I
think
there
is
some
space
between
automating
things
and
then
putting
a
getting
a
human
involved
to
make
sure
it
makes
sense.
F
Considering
highest
level,
that's
how
I've
always
worked
right
with
so
there's
a
requirement
for
something
that
looks
reasonably
like
release
note,
content
produced
by
a
dev
or
an
architect
or
a
p.m.
somewhere
in
an
issue
or
a
feature
or
of
whatever
sort
of
planning
at
the
beginning
of
a
release
item,
and
then
that
stuff
is
automatically
scooped
out
and
then
curated
by
a
human
and
when
I
started.
Looking
at
the
release
notes,
things
were
sparse
enough.
That
I
feel
like
that.
C
A
F
And
clarified
the
role
I
mean
this
is
1.8
is
the
first
release
where
they're
been
raters
worrying
about
the
release,
notes,
I
mean
there's
been
a
Doc's
person,
who's
had
to
Shepard
all
the
content,
and
that's
just
been
too
much
and
with
you
know,
any
dedicated
writer
resource
to
the
release.
Notes
as
opposed
to
the
documentation.
E
I
mean
just
to
be
I,
I
think
when
you
go
into
the
the
like
post-mortem,
it's
it's
important
to
go
in
with
a
set
of
suggestions
like
hey
here's
all
the
problems
I
saw
I
saw-
and
here
are
my
suggested
improvements,
and
just
because
I
I
I,
wouldn't
like
the
engineers
have
already
given
up
on
doing
this.
That's
why
I
hand
it
off
to
us
like.
F
That's
why
this
is
helpful,
because
it's
helping
me
understand
what
current
practices
are
like
or
aren't
like,
and
that
lets
me
brainstorm
solutions.
What
I
think
I'll
try
to
do
then
is
start
writing
something
up
share
it
with
the
group.
Just
write
it
up
separately.
Don't
worry
about
putting
it
in
the
retro
notes,
yet
write
it
up
separately.
Share
it.
We
all.
Maybe
we
can
put
it
on
the
agenda
for
next
week,
because
the
retro
won't
be
until
next
Thursday's
community
meeting.
F
A
Yeah,
let's,
if
we
can
I,
think
Jarrett's
right
if
we
can
go
into
the
retrospective
with
a
suggestion
for
action
and
saying
hey,
this
is
what
we
observed.
This
is
this
is
how
this
could
be
better.
With
these
specific
actions,
I
think
going
into
the
retro,
with
with
a
plan
of
action,
is
the
best
way
to
approach
that,
and
you
just
workshopping
that
in
the
week
leading
up
to
the
retrospective
yeah,
exactly
and.
F
A
Moving
on
to
feature
Docs
like
as
mentioned
earlier,
Steve
is
in
the
burndown
meeting,
but
he
has
left
notes
and
actually
he
just
joined
us.
Oh
I'm,
perfect,
Steve,
I
noticed
that
you
have
put
in
notes
about
the
future
Docs.
Is
there
anything
that
you
want
to
add
or
elaborate
on
about
where
feature
Docs
are
at,
but
one
that
ate.
I
I
A
A
I
H
I
was
searching
around
I
just
wanted
to
know.
If
there's
any
current
efforts,
I
wasn't
able
to
find
on
that
the
any
open
issues,
but
efforts
for
documenting
a
cloud
provider
config
but
specifically
the
OpenStack,
there's
been
quite
a
few
questions
around
the
cinder
configuration
and
things
like
that
within
cloud
provider
and
I,
don't
see
anything,
that's
documented.
Currently
in
that
area
for
any
of
the
cloud
providers.
Do
we
have
any
progress
there
or
am
I
looking
in
the
wrong
place
or
what's
the
best
way,
to
start
that
effort
I.
A
H
Thief:
yeah
the
well
the
format
of
the
cloud
config
itself
for
each
of
the
cloud
providers
and
the
options
that
can
be
passed
for
those
cloud
providers
is
the
is
the
item
in
the
OpenStack
sig.
That
recently
was
asked
and
it
seems
to
be
usually
a
link
to
an
external
blog
or
tutorial
somewhere
out
in
the
ether
and
not
within
the
kubernetes
documentation
itself.
That's
easily
linked,
where
I
can
figure
out
that
ocation
OpenStack,
for
example,
right.
E
E
H
E
H
H
F
E
G
H
E
E
Some
person
who's,
not
here
Luke
Lewis
pub
on
and
approved
by.
I
E
H
C
H
Would
be
a
gopher
cloud
and
then
trickled
up
to
the
cloud
provider?
Is
there
any
talk
about
when,
as
the
cloud
providers
are
pulled
out
of
the
main
repo,
how
we
would
still
document
those
those
cloud
provider
configuration
those
cloud
providers
within
the
committee's
documentation?
Or
is
that
expected
to
be
maintained
for
all
for
each
cloud
provider
itself?.
I
This
is
a
big
question:
we've
been
discussing
on
and
off
for
the
last
year
and
a
half,
and
our
tendency
is
to
think
that
we,
we
won't
have
the
time
or
the
knowledge
to
maintain
those
docks
and
keep
them
up
to
date
as
part
of
the
kubernetes
core
documentation,
so
that
we
would
probably
rather
have
links
to
external
documentation.
That's
maintained
by
the
people
who
you
know,
have
the
expertise
in
those
different
areas,
but
it's
it's
still
an
open
discussion.
So
that's
the
state
of
it
right
now.