►
From YouTube: Intro to Kubernetes Docs - Celeste Horgan, Linux Foundation; Brad Topol, IBM; Tim Bannister
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2021 Virtual from May 4–7, 2021. Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Intro to Kubernetes Docs - Celeste Horgan, Linux Foundation; Brad Topol, IBM; Tim Bannister, The Scale Factory; & Irvi Aini, Spotify
This session introduces the Kubernetes website repo. SIG Docs chairs and tech leads cover how to add and update docs for Kubernetes features, docs in the release cycle, how to localize your content, and where to get help when you need it. We'll walk through the website repo's branching strategy and content architecture, and explore some of the tools to help folks write better docs. We'll also cover how and when to add third-party content for components like CNI plugins. We'll also spend plenty of time answering any questions you have.
https://sched.co/ekHA
A
So,
as
I
mentioned,
this
is
the
kubernetes
documentation
special
interest
group.
We
maintain
the
kubernetes
website
at
k8s.io
now
the
main
thing
that
that
documentation
provides
is
that
website
provides,
is
documentation
and
the
documentation
is
categorized
into
several
broad
areas.
First,
one
I
want
to
talk
about
is
concepts
high
level
overviews
of
topics,
there's
also
tasks
and
tutorials,
so
these
provide
detailed,
step-by-step
instructions
explaining
how
to
accomplish
a
specific
outcome.
A
A
A
I
want
to
mention
why
the
documentation
for
kubernetes
is
a
really
important
way.
I
think,
of
contributing
to
kubernetes,
because
documentation
is,
you
know
as
much
as
code
delivers
features.
Documentation
drives
adoption
of
those
features
by
making
them
accessible
to
people
who
are
not
already
involved,
and
so,
if
you're
interested
in
contributing
to
the
documentation,
your
work
there
helps
make
kubernetes
accessible
to
a
wider
audience
and
indeed
might
help
bring
on
more
contributors
in
the
future.
A
A
Markdown
is
similar
to
plain
text,
but
you
add
extra,
highlighting,
for
example,
with
these
asterisks
or
underscores
basic
markdown
also
offers
lists
hyperlinks
code
snippets
and
a
few
other
things
I'll
talk
more
about
how
we
extend
plane,
markdown
to
add
additional
features
in
a
bit
before
then
I
want
to
talk
about
some
different
ways
to
contribute.
So,
let's
going
to
talk
about
that
in
detail,
if
you're
wondering
where
to
start
sig
docs
curates
a
list
of
good
first
issues,
we've
identified
these
as
a
good
choice
for
making
your
first
contribution.
A
Now,
when
I
say
first
contribution
that
could
be
that
you're
new
to
kubernetes
at
all,
you've
not
contributed
anything,
but
it
could
also
mean
that
you're,
actually
someone
who's
contributed
to
code
already
or
another
part
of
the
organization.
You've
not
contributed
to
the
documentation
website,
so
in
either
those
cases
these
good
first
issues
are
for
you.
A
A
Now,
if
this
is
your
very
first
contribution
to
kubernetes,
there
is
some
sort
of
paperwork-
that's
online,
but
paperwork
to
get
through
before
we
can
review
your
pr
and
move
it
forward
to
getting
merged.
We
need
you
to
sign
a
contributor
license
agreement,
there's
two
ways
to
get
this
signed,
depending
on
whether
you're
signing
as
an
individual
or
whether
that
actually
you're
associated
with
an
organization
that
has
signed
as
a
corporation.
A
A
I've
got
a
tool
called
prowl
which
is
used
not
just
in
the
website
repo,
but
across
kubernetes.
Some
of
you
will
be
really
used
to
it
for
others.
This
might
be
your
first
encounter
with
this.
This
robot
prowl
merges
pr's
when
they're
marked
as
looks
good
to
me,
I'll
talk
more
about
what
that
means.
Later.
They're
approved
and
they're
not
held,
for
you
know
some
action
to
happen,
but
actually,
after
you
submit
a
pr,
the
netlify
tool
which
hosts
the
website
does
a
complete
build
of
the
whole
site.
A
Based
on
your
changes,
if
you've
got
a
pr,
you'll
see
that
a
comment
turns
up
on
that
pr
see
the
arrow
linking
to
a
preview.
You
can
click
on
that
link
and
what
you'll
see
is.
Basically,
it
looks
like
the
same
website,
the
url's
a
bit
different,
and
so
this
is
a
version
of
the
website
that
you
can
click
click
on
to
check.
If
your
code
is
okay
and
it's
also
what
reviewers
will
look
at
if
they
want
to
make
sure
that
your
changes
are
valid.
A
Now,
if
you
want
to
get
some
extra
credit,
what
you
can
do
is
you
can
go
and
find
the
page
that
you
changed
in
your
pr
now.
Netify
doesn't
do
this
for
you,
so
it's
it's
nice.
If
people
do
this
find
that
particular
page
dig
out
the
link
and
add
a
comment
to
your
pull
request,
saying
this
is
the
exact
page
I
changed
and
maybe
like
this
is
the
original
page
and
if
you
do
that,
you're
making
life
easy
for
reviewers
and
approvers
by
letting
people
directly
compare
your
changes.
A
A
So
a
reviewer
will
have
a
look
at
your
pr
if
it's
technically
sound.
In
other
words,
if
you
you've
put
in
some
changes,
they
make
sense.
The
markdown
is
valid
down.
There's
no
egregious
violations
of
the
style
guide
more
on
that
in
a
bit
and
it
matches
the
pr
description.
Then
the
reviewer
adds
an
lgtm
label.
A
The
approver
has
a
different
job.
The
prover's
job
is
not
to
to
verify
your
changes
technically.
Is
to
look
at
that
pr
description
and
just
agree
that
that
change
is
an
appropriate
one
to
make
for
the
website,
but
once
both
of
those
things
has
happened
and
the
pr
is
ready
to
go
forward.
If
it's
a
small
change
like
fixing
one
spelling
mistake,
often
one
person
can
do
both
of
those
roles.
A
A
A
There
is
a
separate
branch
process.
It's
relevant
if
you
are
contributing
features
that
aren't
don't
need
documentation
documenting
it
quite
yet,
if
you're,
making
changes
for
a
future
kubernetes
release
find
the
development
branch
instead
and
put
your
changes
on
that
branch
or
propose
a
merge
into
that
branch.
Using
a
pr.
A
A
B
So,
as
tim
mentioned,
the
high
level
overview
is
that
you
create
a
fork.
You
make
some
changes
and
then
you
open
a
pull
request:
we're
gonna
back
up
a
little
bit
and
talk
about
how
to
make
the
changes
that
make
it
into
that
pull
request.
So,
typically,
as
tim
mentioned,
we
work
on
local
forks
of
the
documentation,
repo.
B
Nobody
can
create
branches
directly
against
maine
unless
it's
for
a
release
or
a
translation.
So
you're
gonna
pull
down
your
local
fork
onto
your
computer
and
then
you're
gonna
run
two
commands
make
container
dash
image
and
make
container
dash
serve.
So
we
deploy
hugo
locally
into
a
container
because
here
in
kubernetes
land
we
love
containers,
but
it
also
gives
us
a
consistent
environment
to
build
against,
which
means
that
what
you
see
locally
is
going
to
reflect.
B
B
So
when
it
comes
to
contr
like
doing
a
contribution
as
a
whole,
we
think
that
everybody
is
welcome
to
contribute
to
documentation
there
isn't
a
baseline
level
of
technical
skill
needed
other
than
being
able
to
wrangle,
hugo
and
git,
and
contributions
from
all
different
levels
of
technical
still
are
super
super
welcome,
as
well
as
contributions
from
people
speaking
other
languages.
So
the
majority
of
our
contributions
happen
in
english,
but
as
we're
going
to
talk
about
later,
there's
about
13
different
localizations
of
the
kubernetes
docs,
and
they
all
need
contributions
as
well.
B
B
So,
as
to
mentioned,
we
do
have
a
documentation
style
guide
and
what
the
style
guide
lines
out
is
things
like
capitalization
rules
and
grammar
rules
and
words
that
we
try
to
avoid
and
words
that
we
try
to
use
instead
and
in
general,
we
we
do
a
check
for
any
egregious
errors
against
the
style
guide.
So
take
a
look
when
you
have
a
chance.
B
B
B
We
also
have
a
mailing
list,
kubernetes
sig
docs,
and
if
you
join
that
you
get
an
automatic
invitation
to
the
weekly
sig
meetings
on
zoom,
they
occur.
I
live
in
vancouver,
so
in
my
time
zone
they
occur
in
at
10
30
on
tuesdays
most
weeks,
and
I
believe
it's
about
5
or
6
utc,
another
great
way
to
get
started.
If
you
can't
make
it
to
to
the
sig
meetings
and
zoom
and
slack
isn't
going
to
work
out.
For
you
take
a
look
for
good
first
issues
in
github.
We
are
generally
very
good
about
tagging.
B
Those
next
slide,
please
most
contributors
to
the
kubernetes
project
are
not
technical
writers
by
trade.
However,
I
am
and
as
are
a
few
other
people
on
sig
docs,
and
so
I
wanted
to
take
a
moment
to
talk
about
just
how
to
write
good
documentation
for
people
who
aren't
writers
by
trade.
The
first
thing
to
keep
in
mind
is
that
all
writing
contributions
are
valuable
to
sig
docs
you'll,
see
below
an
example
of
a
one-word
change
to
documentation
in
other
cigs.
B
That
might
be
viewed
as
a
bit
of
a
spammy
change,
but
for
us,
that's
super
valid
because
that
actually
corrects
the
grammar
of
that
sentence
and
makes
the
documentation
easy
to
understand
by
letting
the
language
get
out
of
the
way.
So
edits
and
type
of
corrections
are
incredibly
welcome.
As
a
rule,
we
kind
of
like
it
if
you're
gonna,
if
you're
gonna
submit
an
edit,
maybe
edit
the
whole
page
and
not
just
one
area.
B
New
content
is
super
super
welcome
and
we
feel
that
developers
are
the
people
to
write
that
content
by
and
large,
but
also
if
you
are
a
writer
by
trade
or
just
very
comfortable
with
the
english
language,
we
really
really
welcome
editing
and
reviewing
pr's,
because
a
lot
of
the
contributions
we
get
from
developers
are
not
by
people
who
have
english
as
the
first
language,
and
they
do
actually
need
that
help
with
grammar
to
bring
up
the
quality
of
the
documentation
next
slide.
Please.
B
If
you're,
taking
on
a
big
new
documentation
task,
just
some
general
tips
for
writing,
well,
first
off
break
down
what
you're
writing
into
the
smallest
sections
possible.
It's
really
really
hard
to
say.
I'm
going
to
document
stateful
sets.
That's
a
really
really
big
thing
to
talk
about,
but
it's
easier
to
think
of
it.
In
terms
of
I
need
to
introduce
staple
sets
as
a
concept
or
something
that's
explained
at
a
high
level.
B
Then
I
need
to
explain
to
people
what
tasks
they
can
do
with
staple
sets
like
adding
or
removing
them,
and
those
are
step-by-step
instructions
or
tasks,
and
then
I'm
going
to
provide
a
table
of
reference
of
any
flags
or
options
that
you
can
set
on.
Stateful
sets
that
are
useful
to
to
know
as
a
piece
of
reference
for
people
who
are
working
with
them
actively
and
those
are
called
reference
tasks,
so
I
think
breaking
it
down
and
then
understanding
the
different
categories
of
writing
is
a
really
good
strategy.
B
I
personally
find
writing
in
bullet
points
first
and
then
translating
those
into
full
sentences
very
helpful
and,
as
the
lead
tech
writer
at
the
cncf,
zach
coralison
often
says
always
be,
deleting
try
to
be
as
brief
as
possible
and
to
write
and
then
delete
a
whole
bunch
down
next
slide.
Please
a
few
last
tips
right
in
the
present
tense,
so
I
am,
or
the
stateful
set
does
rather
than
I
will
do,
or
the
stateful
set
will
do
or
in
the
past
tense.
B
I
won't,
or
I
was
doing,
the
staple
set
was
in
general,
keep
sentences
short
use,
plain
language
when
possible,
avoid
complicated
words.
There's
a
great
app
called
hemingway
app.
It's
free,
it's
online
and
it
automatically
scans
anything
that
you
put
into
it
for
complicated
words
and
sentences
that
are
too
long,
and
I
highly
recommend
using
it
and
finally
ask
for
help
in
sig
docs,
because
there
are
technical
writers
hanging
out
in
there
next
slide.
B
Please
so
once
you've
made
your
wonderful,
well-written,
first
request,
what
you're
going
to
do
is
you're
going
to
commit
it
and
then
open
a
pull
request,
as
tim
stated
against
kubernetes
website,
and
this
is
where
the
pr
wrangler
comes
in.
So
the
pr
wrangler
is
a
approver
in
sig
doc,
so
somebody
who's
fairly
high
up
the
contribution
ladder
and
on
a
weekly
rotation.
One
person
in
that
list
is
assigned
to
look
at
the
prs
that
week
and
approve
them
for
content.
B
So
these
are
people
who
are
going
to
provide
you
detailed
feedback
and
suggestions,
they're
going
to
put
that
approve
label
on
your
pr
so
that
it
can
get
merged
and
if
you're
writing
something
fairly
technical.
These
are
the
people
who
will
flag
down
the
appropriate
sig
to
make
sure
that
the
information
is
technically
accurate,
so
the
rotation
for
that
is
on
the
wiki
and
now
I'm
going
to
hand
this
over
to
irby
who's,
going
to
talk
about
localization,
the
blog
and
next
steps
for.
C
C
So
what's
the
difference
between
translation
and
localizations,
while
in
translation
we
translate
the
whole
page
from
one
language
to
others
in
localization,
we
try
to
make
sure
that
the
content
of
this
page
is
appropriate
when
we
translate
it
into
the
other
language.
So
it's
more
like
adapts
the
message
into
the
local
audience
of
the
language
that
we
will
translate
it
into,
and
in
these
subgroups
we
try
to
tackle
some
kind
of
common
problems
for
each
of
the
localizations
team.
C
For
example,
if
let's
say
one
localization,
half
team
have
problems
with
how
to
sync
the
diff
branch
between
the
master
upstream
and
their
own
branch,
and
the
other
team
is
having
the
same
problems.
We
will
try
to
kind
of
discuss
whether
we
have
kind
of
solutions
for
this
kind
of
problems
or
other
teams
have
already
already
have
the
solution
for
these
problems.
C
So
the
first
important
thing
is
make
sure
of
the
code
of
your
iso
language,
and
then
you
can
take
a
look
into
this
vr
here.
There
is
an
example
of
how
france
at
their
organizations
and
then
there's
also
a
content
on
how
you
can
localize
your
content
from
the
upstream,
of
course,
english,
and
then
you
can
try
to
localize
it
into
your
your
own
language.
C
It
is
make
sure
that
when
you
start
with
your
pr,
it
is
for
one
language
and
of
course
there
is
exceptions
for
this
kind
of
vr.
For
example,
when
we
create
a
realist
branch
that
branch
for
specific
release-
and
we
try
to
sync
with
the
master
branch-
there
is
changes
from
different
organizations
included
in
that
pr
and
but
but
it's
it's
also
applicable,
because
that's
the
process
that
we
have
on
when
we
are
trying
to
create
a
rails
branch.
C
The
other
example
is
when
we
switch
the
whole
site
into
dot
c,
and
another
example
here
is
the
security
notice
for
certain
features
next
slide.
Please
and
there's
also
another
subproject
here,
which
is
vlogs.
So
there
are
several
guidelines
for
this
sub
projects.
When
you
are
trying
to
start
with
your
blog
post,
the
first
one
is
the
article
should
be
applicable
for
all
users,
so
it
shouldn't
be
a
specific
offender.
C
And
if
it's
more
like
strict
in
the
terms
of
schedules,
you
might
consider
talking
to
the
cncf
marketing
and
it
should
be
our
original
path
and
aim
to
be
future
proof.
Since
the
kubernetes
has
a
high
velocity
development
and
try
to
plan
to
cover
long-term
technical
content,
you
can
check
the
blog
on
the
link
that
provided
here
and,
of
course,
anyone
can
write
a
blog
post
and
submit
it
for
a
review
next,
please,
here
you
can
try
to
contribute
by
filling
on
issues
like
suggesting
a
features
or
reporting
box.
C
C
Localizing
existing
pages
writing
a
new
content
and,
of
course,
you
can
also
help
by
improving
existing
contents,
adding
text
or
diagrams
sig
docs
in
general,
uses
kit
and
github
hugo
and
notify
to
make
it
all
work.
You
can
edit
pages
and
open
pull
requests
directly
within
github
website,
and
if
you
are
suggesting
changes
you
can
review
them
locally.
First
next,
please.
C
C
So
how
can
we
get
in
touch?
You
can
try
to
sign
up
for
slack
in
the
slack
dot,
kayat
ace,
dot,
io
and
drop
by
in
our
channel
in
sick
dogs
and
there's
also
a
different
kind
of
channels
for
our
subgroups,
which
is
the
sig
docs
dash
localizations
and
seek
dash
docs
desk
log
comment,
say
hello,
feel
free
to
ask
questions
next,
please.
C
B
Yeah,
so
we
wanted
just
to
thank
everybody
who
attended
this
talk
and
we
hope
you
learned
a
lot
about
documentation,
believe
it
or
not.
This
is
a
very
high
level
overview
of
what
the
sig
does
and
there's
a
lot
more
that
we
could
go
into.
So
all
of
us
will
be
available
after
the
session
for
a
q
a
and
we
hope,
you'll
join
us
there.
We
also
hope
to
see
you
at
our
weekly
meetings
and
in
the
sigdoc's
channel
on
kubernetes
slack.
So
thank
you
very
much
and
have
a
great
day.