►
From YouTube: Kubernetes SIG Docs: A Deep Dive - Jim Angel, Google; Chris Metz, Independent; Brad Topol, IBM
Description
Don’t miss out! Join us at our next event: KubeCon + CloudNativeCon Europe 2022 in Valencia, Spain from May 17-20. 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.
Kubernetes SIG Docs: A Deep Dive - Jim Angel, Google; Chris Metz, Independent; Brad Topol, IBM
This session covers Kubernetes (K8s) documentation. We'll do an overview of the docs--how they're organized, and how they're maintained--then contribute to the docs ourselves. During the introduction, we'll look at the docs repository (kubernetes/website) and how we organize content. We'll also look at the website stack: how we preview and publish docs to kubernetes.io. We'll talk about the docs workflow: how SIG Docs does the work to review and publish docs. During the deep dive, we'll explore the docs contributor guide and do some hands-on contribution. Remember that contributing to docs is a pathway to Kubernetes membership!
A
So
starting
off,
who
are
we?
We
are
sig
docs
and
we
run
the
kubernetes
dot,
io
website
or
kas
dot,
and
with
that
the
kubernetes
website
serves
about
1.3
million
users
every
single
month,
and
it's
pretty
incredible-
and
you
can
see
here
on
this
first
slide.
We
do
have
a
few
of
our
popular
pages
called
out.
Judging
by
traffic
monthly.
A
So
before
we
get
started
like
I
said,
I
wanted
to
go
deeper
into
the
technology,
and
this
is
one
of
the
common
asks
that
we
get
as
part
of
sig
docs
is
how
does
kubernetes
do
documentation?
What
is
the
actual
thing
that
makes
the
docs
real,
and
so,
while
I
am
going
to
go
deeper
into
the
technology
here,
the
specific
technology
isn't
important.
It
is
understanding
that
journey
from
start
to
finish
and
how
those
pieces
all
come
together.
A
So
my
goal
is
not
to
go
into
every
single
little
detail
on
how
the
how
the
kubernetes
website
is
published,
but
my
goal
is
to
give
everybody
in
this
room
a
little
bit
more
further
literacy
when
it
comes
to
kubernetes
documentation,
and
so
when
you
go
to
the
kubernetes
website,
you
actually
know
what
you're
looking
at.
You
can
see
how
the
things
are
operating
and
understand
the
overall
process
to
get
started
more
effectively.
A
A
Before
we
get
further,
we
want
to
talk
a
little
bit
about
markdown,
so
those
who
aren't
familiar
markdown
is
a
way
of
writing
specific
features
that
represent
the
html
counterpart,
and
so
what
I
mean
by
that
is
you
can
see.
There
is
four
asterisks
down
the
side
here
about
what
markdown
has
to
offer
those
four
asterisks
when
generated
with
a
static
site
generator
which
I'll
talk
about
more
in
a
second.
A
So
I
mentioned
all
of
the
magic
happens
with
a
static
site
generator
there's
a
handful
of
them
out
there,
there's
jekyll,
there's
hugo
and
a
handful
of
other
ones.
All
serving
the
same
purpose.
Give
me
markdown,
give
me
html,
partials,
layout,
shortcodes,
mash
them
together,
give
me
a
static
website.
A
So
I
mentioned
hugo
hugo
is
the
engine
that
we're
using
to
generate
our
static
websites
and
when
I'm
learning
a
new
technology,
I
need
to
know
what
the
thing
is.
You
know
what
are
we
talking
about
when
we
talk
about
hugo?
At
the
end
of
the
day,
hugo
is
written
in
golang,
it's
a
go
binary.
You
could
run
it
in
a
container.
You
could
run
it
as
a
binary
on
your
host
system.
A
The
idea
being
hugo
is
that
magic
power
that
we
just
showed
here,
where
it's
taking
your
markdown,
it's
jamming
it
with
html,
is
creating
your
beautiful
web
page
at
the
very
end
of
the
day
and
it's
all
written
and
go
so.
The
few
key
points
here
is
extends
goaling
built-in
templating
for
organizing
and
building
the
website.
All
content
is
contained
in
markdown
files,
and
then
it
is
a
binary
at
the
end
of
the
day
that
can
be
used
in
many
different
ways.
A
Now,
if
you
give
it
this
directory
config,
where
you
have
the
arc
types,
you
have
config.toml,
and
you
have
a
few
of
these
different
components
here.
If
hugo
sees
that
it
understands
where
and
how
to
render
each
page
so
breaking
down
the
various
directory
structure
of
hugo.
Here
we
have
archetypes,
which
is
writing
templates
and
I'm
going
to
kind
of
fly
through
this
slide.
Here
we
have
a
config.tama,
which
is
a
configuration
of
hugo,
so
right
now
we're
only
talking
generation,
we're
not
talking
hosting
we're,
not
talking
anything
outside
of
that.
A
A
A
The
second
and
or
I
guess
not
second,
but
the
next
item
here
is
the
static,
which
is
your
files
and
images.
This
would
be
things
like
your
javascript
css,
you
name
it
more
of
the
things
that
aren't
going
to
change
much
like
images
as
well.
Now,
the
last
piece
there
is
theme,
so
themes
is
not
a
required
piece
of
hugo.
You
can
write
your
own.
A
So,
having
said
all
that
about
hugo
and
about
directory
structures,
and
what
hugo
understands
looking
at
this
now,
it
might
make
a
little
bit
more
sense
than
when
I
first
showed
it.
You
see
we
have
archetypes,
we
have
content,
we
have
data,
there's
some
other
folders
there
I
didn't
talk
about,
but
if
I
run
hugo
inside
of
this
website
directory,
it
will
build
those
pages
and
you'll
serve
that
html
page
at
the
end
of
the
day.
A
So,
if
you're,
following
what
I'm
talking
about
when
it
comes
to
hugo,
when
it
comes
to
generation,
it
sounds
like
we're
living
in
this
magical
fairyland
of
the
website
just
working.
Unfortunately,
the
reality
is:
is
data
changes?
Kubernetes
changes
a
lot
of
things
change
fast.
So,
for
example,
if
you
look
at
this
site
here,
where
we're
talking
about
supported
version
sku,
if
we
wanted
to,
we
would
have
to
change
so
many
different
areas
in
the
file
for
each
release.
A
So
here
we
are
looking
at
markdown.
This
markdown
is
going
to
call
a
hugo
short
code,
you'll
see
in
the
parens
or
the
brackets,
a
piece
that
says
skew
latest
version.
That
is
a
hugo
short
code
that
is
calling
some
of
the
superpowers
inside
of
hugo,
and
what
I
mean
by
that
is
there's
certain
things
that
are
driving
this
data
when
it
gets
generated,
and
so
it
makes
us
change
one
place
that
reflects
across
multiple
pages.
We
leverage
the
data
in
the
config.tamil.
A
A
I
mentioned
the
config.toma
before,
but
here
you
can
see
at
the
very
bottom
there
there's
the
latest
version
is
v1.22,
and
so
what
that
shortcode
does
is
take
it
and
changes
it
on
the
fly
at
build
time.
So
every
single
release,
every
single
change,
happens
one
time
in
the
config
file
and
then
hundreds
of
times
across
the
website.
A
It's
really
the
magic
behind
the
scenes
of
what
is
keeping
kubernetes
dot.
Io
running
I
mentioned
before
we
leverage
a
theme.
There's
hugo
hugo's
theme
called
doxy
is
created
by
some
of
the
tech
writers
at
google
and
it
is
supposed
to
be
the
best
way
to
present
technical
documentation
in
a
very
opinionated
way.
A
Once
again,
kind
of
demystifying,
what
that
theme
is,
it
is
actually
a
sub
module
that
is
inside
of
the
kubernetes
website
folder
and
it's
a
git
sub
module
that
is
maintained
out
of
band.
So
this
means
now
I
kind
of
talked
about
the
importance
of
data
and
how
we
manage
data.
Now
we're
talking
about
the
theme
and
how
do
we
manage
the
theme
and
so
by
taking
it
and
bringing
it
in
as
a
sub
module?
A
We
only
have
to
update
that
theme,
sub
module
as
opposed
to
doing
multiple
updates
to
a
custom
built
theme,
for
example.
So
a
couple
key
points:
everything
is
code.
It's
all
driven
with
code
hugo
generates
html
files
from
markdown
sources
and
shortcodes
are
the
secret
sauce
that
build
the
various
components
and
config.toml
is
hugo's
boss.
A
Hugo
knows
where
to
look
at
to
get
the
information
that's
needed
to
run
successfully,
so
this
is
all
great.
But,
however,
we
need
something
to
host
it
up
until
this
point
we're
talking
about
markdown
and
mashing
it
with
hugo
to
generate
a
static
website.
Now
we
need
a
host
and
kubernetes.io
uses
netlify.
A
I
just
talked
about
and
netlify
says,
give
me
a
git
provider,
give
me
a
repository
and
then
let
me
go
to
town
and
build
a
site,
so
you
could
actually
deploy
the
kubernetes
website
with
your
fork
on
netlify,
almost
one
to
one
with
what
is
running
in
production
today,
and
I
believe
this
is
part
of
the
netlify
free
tier
and
you
can
play
with
just
like
it
would
be
in
production.
But
now
you
have
full
control
over
the
repo
how
it
works.
You
can
try
to
break
it.
You
can
do
whatever
you
want.
A
A
And
the
netlify.tamul
says
some
of
the
build
variables
that
netlify
should
use
when
publishing
the
kubernetes
website.
Some
of
the
commands
that
it
would
use-
and
some
of
the
key
points
here
is
that
netlify
is
looking
for
the
netlify.yaml
in
the
actual
kubernetes
website
repository
at
the
end
of
the
day,
netlify
is
going
to
call
hugo
dash
minifi.
If
you
start
to
pick
apart,
some
of
the
underlying
commands
that
are
being
called
inside.
So
when
netify
deploys
a
website,
it
doesn't
build.
A
I
think
it's
containerized,
I'm
not
entirely
sure
it
builds
the
website
using
the
netlify.
Yaml
runs
the
hugo
command.
The
hugo
command
runs
in
that
directory,
realizing,
there's
a
config.tamil
and
then
netlify
has
the
ability
to
wait
till
the
site
is
completely
up
and
running
prior
to
switching
the
traffic
over.
A
A
So
when
a
new
release
comes
out
and
it's
a
whole
different
talk
for
another
day,
you
could
actually
create
a
new
branch
and
operate
off
of
that
branch.
Build
netlify
using
that
branch
and
have
those
custom
features,
data
points,
you
name
it
all
compartmentalized
by
that
single
branch
itself,
and
so
with
that,
I'm
going
to
pass
it
over
to
chris
to
talk
a
little
bit
more
about
getting
involved.
Thank
you.
B
Thanks
jim
last
year
about
this
time,
I
was
checking
out
some
of
the
virtual
talks
from
kubecon
while
sitting
on
my
exercise
bike,
and
I
realized
that
wow,
this
documentation
stuff
is
very,
very
cool.
So
here
I
am
a
year
later,
as
a
member
of
the
new
contributor
class
class
of
late
2020,
and
I
wanted
to
share
with
you
some
of
the
things
that
I've
learned
over
the
last
year.
B
Again,
I
came
about
this
from
the
from
the
world
where
I'd
be
sitting
in
these
meetings,
and
this
happened
for
years
where
we
bring
in
a
new
piece
of
software,
and
invariably
someone
would
ask
hey,
is
there
any
documentation
on
this
and
the
answer?
The
answer
99
of
the
time
was
no
all
right.
So
our
job
and
it's
been
a
great
job
so
far,
our
job
as
a
community
is
to
try
and
make
the
kubernetes
documentation
the
best.
B
Be
okay
so
contributing
to
sid
docs.
You
can
look
at
some
of
these
bullets
they're
pretty
standard,
but
I'm
gonna.
Look!
I'm
gonna
state
these
right
off
the
bat
number
one.
It's
about
learning
number
two!
It's
about
knowledge
number!
Three!
It's
about
working
with!
Really
smart
people
really
cool
people
using
advanced
tools
and
automation;
number
four!
B
So,
like
I
say
it's,
it's
a
lot
of
fun.
Okay,
many
people
ask:
where
do
I
go
from
here?
The
docs
are
to
go
into
it,
but
I
thought
I'd
put
together
this
little
sort
of
graphic
to
explain
that
on
the
left.
You
just
need
to
sign
up
and
it
may
be
as
simple
as
just
signing
up
for
the
you
know
for
the
slack
message
board
joining
that
and
participating
either
in
the
bi-weekly
slack
stand
ups
or
the
every
other
week.
Zoom
call.
B
So
just
come
in
announce
yourself:
the
community
is
extremely
inviting
all
and
everybody
are
welcome,
start
looking
around
probing
around
at
some
of
the
documentation
and
how
it's
structured,
jim,
went
through
some
of
how
things
are
organized
in
in
hugo,
so
install
that
play
around
with
it
get
you're
gonna
have
to
work
with
some
of
the
get
commands
if
you're
fluent
in
git.
This
will
be
no
problem.
If
people
are
new
to
git,
that's
perfectly
okay,
we
can
help
you
through.
That
is.
B
One
has
has
had
to
learn
some
of
the
more
advanced
get
cake
capabilities,
because
in
one
of
my
earlier
projects
I
was
the
the
single
docs
maintainer.
So
I
pretty
much
was
able
to
do
my
own
thing,
but
in
this
environment
we're
collaborating
with,
like
I
say,
a
bunch
of
smart
people
and
it's
important
to
be
able
to
understand
how
git
can
operate.
B
And,
finally,
you
need
to
open
a
pr.
You
can
open
a
pr
and
cover
just
about
any
topic,
whether
it's
improving
content,
generating
new
content,
maybe
fixing
something
up.
Brad
will
talk
about
localization
any
and
all
contributions
are
welcome
and
don't
think
like.
I
have
to
be
a
craft
up
sort
of
a
technical
spec
on
some
advanced
kubernetes
capability.
B
It
may
be
as
simple
as
just
reorganizing
a
paragraph
so
that
it's
much
more
accessible
and
understandable
to
the
greater
community.
Okay,
the
cli
you're
required
to
sign
this.
It's
relatively
straightforward.
You
have
a
pointer
right
here.
If
you
don't
sign
it
and
you
push
a
commit,
the
system
will
yell
at
you
and
you'll
have
to
go
back
and
make
sure
you
do
sign
that.
So
that's
one
of
the
initial
sign
up
actions
that
you
certainly
want
to
take.
B
Okay,
opening
a
pr
there's
a
couple
of
slides
on
this.
I
won't
go
into
a
super
amount
of
detail.
The
instruction
details
from
the
documentation
are
linked
via
that
url,
but
basically
you
go
into
github
you
hit
edit,
the
page
you
edit,
the
page.
You
fill
out
a
couple
of
fields
in
the
panels
below
you
push
it
up
and
boom
a
pr
is
open.
B
B
B
Okay,
if
you
want
to
open
your
pr
from
a
fork,
again
won't
go
through
these
in
details,
but
but
the
instructions
are
there.
I
will
say
that
the
simple
github
method
is
good
for
very
short
changes.
Maybe
you're
correcting
some
a
sentence,
structure
or
grammar
or
adding
in
some
punctuation
or
updating
a
term.
B
If
you
won't
need,
if
you
need
to
do
some
more
sophisticated
changes
or
the
the
changes
are
a
little
bit
longer
than
what
might
make
sense
using
the
github
process,
then
you'd
want
to
open
it
up
from
a
from
your
fork
and
work
off
a
local
copy
of
your
fork.
Okay,
code
review,
automation,
that's
performed
by
a
tool
called
prow.
B
The
end
game.
The
goal
here
is
to
get
the
slash
lgtm
and
the
slash
approve
from
the
technical
leads
and
those
folks
that
make
sure
that
the
pr
is
good
to
go.
I've
always
I've
also
used
hold
to
say,
I'm
still
working
on
this.
It's
not
ready.
Please
don't
do
anything
with
it
more
on
the
proud
commands
in
that
link
the
automatic
preview.
Now
this
is
the
second
way
of
looking
at
the
changes
that
you've
made.
As
jim
pointed
out
once
you
push
the
commit,
the
pr
is
open.
B
Netlify
will
build
a
a
site
for
you,
a
preview,
build
of
the
site
and
you
can
go
in
there
and
look
at
it,
and
this
is
how
other
folks,
other
reviewers
other
tech
leads,
would
look
at
that
particular
pr
as
well
and
by
pr
I
just
mean
a
change
in
content
or
structure
of
the
documentation
itself,
so
good
place
to
look
at
the
changes
right
there
see
how
they'll
look
at
see
how
they'll
look
out
on
the
internet
once
they're
deployed
also
a
good
place
to
add
a
pr
description.
This
can
be
really
helpful.
B
You'll
become
your
people
will
like
you
more
than
they
probably
already
do,
if
you
do
add
a
better
description
of
the
pr
and
also
any
changes
that
to
the
also
any
of
the
pages
that
are
changed
or
modified
via
your
via
your
pr,
okay,
I'm
gonna,
zip
through
here
now.
This
is
before
approval
right.
You've
pushed
your
pr
up
to
the
branch
github
notifies
netlify
of
this
pr.
B
It
builds
and
then
publishes
a
preview
of
the
website,
and
also
it's
also
going
to
check
to
make
sure
that
you
have
the
cla
cla
signed.
So
that's
before
approval
once
you've
made
all
the
correct
changes,
and
everybody
says
that
looks
good.
You
got
the
lgtm
and
slash
approved
you're
all
good
to
go
that
pr
is
merged
and
deployed
out
there
at
k8s
dot
io
boom,
okay,
the
local
preview.
Again,
this
is
very
useful
when
you
want
to
examine
or
review
the
changes
that
you're
making.
B
Anything
no
contribution
is
is
too
small
or
too
large
to
make
these
documents
make
this
documentation
better
style,
that's
something
that
is
important,
particularly
in
the
technical
documentation,
environment,
there's
certain
ways
of
of
defining
code
blocks
or
code
snippets,
there's
a
certain
syntax.
For
example.
We
want
to
use
active
voice
so,
instead
of
saying
a
is
sent
by
b,
it's
much
easier
to
just
say,
b
sends
a
so
little
things
like
that.
B
You
could
take
those
thoughts,
put
them
out
onto
a
github
issue
where
you
would
have
the
community,
maybe
review
and,
and
you
know,
assist
or
help
guide
you
towards
what
might
be
the
best
way
of
of
phrasing
or
structuring
this
documentation.
Then
you
can
go
off
and
open
a
pr
and
add
it
into
the
documentation.
B
There's
always
there's
also
the
point
about:
don't
try
and
be
too
verbose.
You
know
zach
mentioned
always
be
deleting
obviously
that's
something
we
didn't
do
with
the
50
plus
slides
that
we
have
to
show
you
in
about
half
an
hour,
but
anyway
yeah
I
used.
You
know
active
voice,
keep
things
short,
keep
them
simple,
no
need
to
get
into
a
a
lengthy
article
with
a
with
a
a
number
of
you
know,
words
that
you
need
to
look
up
in
a
dictionary.
B
Keep
it
simple
diagrams,
I'm
real
big
into
diagrams
there's
a
dearth
of
diagrams
within
the
documentation.
They
make
any
documentation
more
accessible,
it's
easier
to
comprehend,
and
it's
much
clearer
now
you
don't
have
to
do
documentation
for
every
single
piece.
Excuse
me
diagrams
for
every
single
piece
of
documentation,
but
it
is
helpful
if
you
think
that
golly
it
takes
too
much
time
or
I
you
know,
I
don't
want
to
get
into
powerpoint
in
that
nonsense.
B
Mermaid
by
virtue
of
the
doxy
dev
theme,
is
a
package,
that's
included
with
the
cube
docs
platform,
so
the
nice
thing
about
mermaid
is
that
it
has
a
very
simple
markdownish
type
syntax
to
create
relatively
simple
diagrams.
So
as
you've
got
your
documentation
there,
it's
straightforward
to
just
add
a
few
lines
of
mermaid
code
inline
into
your
text,
and
it
will
generate
a
nice
little
diagram.
Again.
B
A
diagram
could
be
as
simple
as
some
boxes
representing
components
connected
by
arrows
that
talks
to
another
component
or
represents
a
flow
very
useful
to
those
that
are
just
not
familiar
or
just
learning
about
kubernetes.
For
the
first
time.
The
nice
thing
about
mermaid
as
well
is
that
it
has
an
offline
live
editor
where
you
can
build.
These
diagrams
see
how
they
look
and
then
also
each
diagram
generates
a
rest
api.
So
you
could
fling
that
around
to
your
colleagues
and
ask
them,
for
you
know
hey.
This
is
what
it's
going
to
look
like.
B
What
do
you
think
and
then
they
can
go
in
and
work
on
the
diagram
as
well,
so
it's
a
great
way
of
collaborating
with
diagrams,
rather
than
sending
powerpoint
and
various
svg
svg
files
to
those
to
those
colleagues
anyway.
This
is
a
lot
of
fun.
You'd
make
a
huge
contribution
not
only
to
the
open
source
community,
but
your
colleagues,
your
colleagues
at
your
day,
job
or
your
studies,
and
it's
really
a
good
thing
to
be
part
of
so
with
that
I
think
I'll
hand
it
over
to
to
brad.
C
Thank
you,
chris
okay.
I
believe
I
am
standing
between
all
of
you
and
the
booth
crawl
with
alcohol.
So
I
assure
you
we
are
going
to
end
on
time
it's
nice
to
have
control,
so
I'm
here
to
talk
quickly
about
wrangling,
prs
and
localization
and
and
bring
us
home
one
of
the
great
things
that
we've
we
kind
of
innovated
in
sig
docs
was
the
notion
of
a
pr
wrangler.
C
What's
going
on,
we
took
great
pride
in
sigdoc's
at
being
able
to
have
a
very
quick
response
time
to
at
least
an
initial
response,
say:
hey
or
pr
has
somebody
assigned
to
it,
and
if
there
were
easy
ones
that
the
pr
wrangler
can
actually
go
ahead
and
approve
them,
but
otherwise
their
traffic
cop
routing
it
to
the
right
folks
and
you
can
feel
comfortable.
Your
pr
is
going
to
get
handled
in
a
timely
fashion.
C
C
Some
of
them
are
farther
along
than
others,
but
thanks
to
hugo
and
its
support
for
localization,
we
are
able
to
to
add
this
type
of
support
and
we
have
a
really
a
vibrant
community
that
does
it
and
you
can
see.
This
is
a
an
example.
The
china
team
is
one
of
our
most
advanced
teams.
That
does
localization,
and
this
is
the
what
is
kubernetes
page,
and
you
know
I'm
smart
enough
to
look
at
the
english
and
then
do
the
translation.
That's
how
I
know
it
is
the.
C
What
is
kubernetes
page,
and
you
can
see
that
you
know
it-
it
helps
to
have
it
in
the
language.
So
these
are
the
ones
that
we
have
now.
We
just
recently
added
hindi
and
punjabi.
So
new
teams
coming
on
board,
we
have
great
documentation
in
the
documentation
on
how
to
get
started
with
creating
your
own
localization.
C
We
also
have
a
sig
docs
localization
subgroup
that
I
share,
and
this
is
a
group
that
meets
once
a
month
we're
doing
our
run
out
of
time.
Five
minutes
not
a
problem,
gentlemen,
not
a
problem.
We
will
get
there
so
with
the
sig
docs
localization
subgroup
we
meet
once
a
month
and
all
the
different
localization
teams
talk
to
each
other
and
they
share
best
practices,
so
they
share
best
practices
and
they
also
share
tooling.
So
we
have
really
great
tools.
C
The
china
team
pioneered
some
great
tooling,
and
the
korea
team
also
have
some
great
tooling
about
how
to
identify
what
needs
to
be
changed.
What
what
needs
the
localization
to
to
be
applied
to?
So
we
have
great
tools
that
are
all
described
and
we
have
the
ability
great
documentation
on
how
to
get
started.
If
you
have
your
own
localization
that
you
want
to
get
started,
we
have
a
slack
channel,
we
have
our
own
slack
channel,
we
have
our
own
mailing
list
and,
like
I
said,
we
even
meet
once
a
month.
C
One
thing
to
know
about
localizations
a
common
mistake:
is
people
want
to
update
something
across
multiple
languages,
so
one
pr
makes
this
tiny
little
fix
across
five
or
six
languages
turns
out.
That's
a
really
bad
idea.
I
know
it
seems
like
something
you
want
to
do,
but
it's
much
better
that
your
pr
should
stay
for
inside
a
single
localization,
because
otherwise
it
causes
problems
down
the
road
for
our
folks
in
their
branching.
So
just
a
safety
tip
there.
C
We
also
support
blogs
and
sig
docs,
it's
kind
of
its
own
little
mission,
but
you
know
here's
some
great
guidelines
on
doing
a
blog
should
not
be
a
vendor
pitch.
That's
not
the
place
for
these.
Please
don't
put
them
there.
Try
and
make
the
content
future
proof,
so
it
stays
stays
fresh
should
be
original
content,
and
so
anybody
can
write
these
and
submit
these.
C
So
if
you
have
a
great
idea
for
a
blog,
ideally
original
content,
please
go
ahead,
and
so
just
to
recap,
so
many
great
ways
to
come
join
us
and
contribute
it's
a
great
place
for
new
people
to
get
started.
There
is
not
a
friendlier
crowd
in
the
kubernetes
community
than
sig
docs
and
we
wonderfully
want
to
help
you
get
started
and
getting
contributing.
So
again,
you
can
help
with
web
design
create
report
bugs
you
can
do
some
reviews.
C
C
If
you
want
to
lurk,
but
we
are
always
here
to
help
we're
always
here
to
help
and
we're
always
here
to
help
with
our
meetings
to
to
help,
let
you
know
who's
working
on
what
and
and
how
you
could
help
and
how
you
can
be
involved
again,
some
more
information
here,
there's
the
sig
doc
slack
and
the
sig
docs
localization
slacks
we've
got
a
google
group,
kubernetes
docs.
We
have
a
meeting,
that's
about
twice
a
month
that
we
have
and
it's
the
schedules
are
out
there.