►
From YouTube: Kubernetes Sig Docs 20180206
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 06 February 2018.
A
Right
good
morning,
everyone,
this
is
Tuesday
February
6,
and
this
is
the
weekly
meeting
for
sig
sig
docs
for
kubernetes.
We
have
a
really
full
schedule
today.
So
let's
get
cracking
I
see
Paris
is
here
hello
Paris
before
we
get
rolling,
is
there
anything
that
you
would
like
to
add
to
our
agenda
today.
A
A
A
Okay
welcome,
so
this
is
a
pretty
typical
meeting
format.
We
have
an
agenda.
I
will
post
the
link
to
that
agenda.
Well,
it's
already
posted
in
cig
Docs
and
if
you
have
anything
that
you'd
like
to
discuss,
please
tack
it
onto
the
agenda
at
the
end,
as
mentioned,
we
have
a
full
agenda
today,
so
we
may
or
may
not
get
to
it
all
right.
Let's
do
follow-ups
from
last
meeting
sig
that
are
CNC.
A
F
is
hiring
if
you
want
to
work
for
the
Linux
Foundation
and
get
paid
to
care
about
the
quality
of
kubernetes
documentation.
That's
a
full-time
gig.
Come
talk
to
me.
Message
me
on
sick
dachshund,
muhabba
chat
all
right.
Let's
talk
about
the
style
guide
Steve!
Last
week
we
talked
about
the
idea
of
adapting
an
existing
style
guide,
for
example
like
google
developer
or
google
cloud.
A
C
C
D
So
Steve
and
I
talked
about
this
a
bit
last
week,
and
one
of
the
things
I
suggested
was
that,
as
part
of
an
effort
to
promote
the
style
guide
better,
because
that
really
is
a
piece
of
I
mean
there's
not
a
lot
of
point
in
doing
a
whole
lot
more
with
the
content.
Until
we,
you
know,
figure
out
how
to
evangelize
it
better
and
one
of
the
things
that
I
suggested
was
that
the
current
content
is
good.
But
some
reorganization
of
it
might
help.
People
find
the
parts
that
we're
seeing
less
compliance
with
more
easily.
E
E
D
Really
didn't
want
to
fall
down
a
rabbit
hole,
but
the
content
best
practices
are
things
that
if,
even
though
we
see
non-compliance
in
a
lot
of
the
formatting
stuff,
also
the
content
best
practices
seem
to
be.
People
seem
sometimes
not
even
to
be
aware
that
they
exist,
let
alone
you
know,
sort
of
how
to
follow
them.
So
I
suggested
moving
things
around
and
possibly
fiddling
with
the
TOC,
and
you
know
just
to
see
whether
we
can
give
some
more
visibility
on
areas
that
we
think
could
use
more
attention.
So.
A
Yeah,
that's
a
I,
definitely
see
it's
a
consistent
pattern
of
of
quality
issues
as
well.
So
I
yeah
there's
also
like
reasonable
suggestions.
I
agree:
let's,
let's
not
inherit
the
entirety
of
a
style
guide
that
we
don't
necessarily
need
to
use.
Let's,
let's
take
what
we
have
and
address
its
problem,
well,
not
exactly
problems
but
make
it
as
good
as
it
can
be,
promote
its
visibility
and
and
effectiveness
more
and
address
the
particular
pieces
that
we
that
we
do
see
on
a
regular
basis.
A
A
A
Steve
and
I
last
week
took
on
some
cleanup
tasks
and
Steve
has
done
a
wonderful
job
of
wrangling,
access
for
individual
contributors
for
the
repo,
so
thank
you.
Steve
I
took
on
the
task
of
adding
or
of
doing
some
team
Queen
up
for
the
repo
and
I
said
specifically
that
I
would
add
reviewer
teams
to
coumadin
to
kubernetes
website,
as
specifically
for
repo
teams,
as
it
turns
out.
Not
only
can
we
not
do
that,
they
would
end
up
being
kubernetes
organization
teams
anyway,
so
working
fine
as
they
are.
A
Thank
you
very
much
for
your
contributions.
So
all
of
that
we
adhere
to
the
cumbia
standards
for
kubernetes
maintainer
outlined
in
the
kubernetes
community.
Repo
and
Joe
has
more
than
adequately
met
the
standards
to
be
a
kubernetes
maintainer,
the
other,
the
other
person
who
had
right
access
but
doesn't
and
would
like
it
is
Brad
to
a
ball.
Brad
meets
the
qualifications
for
reviewer
right
now,
so
I'm
going
to
he's,
got
I
think
a
key
are
open
to
become
a
reviewer
yeah
go
ahead.
Joe
yeah.
F
G
A
G
G
A
Vice
versa:
okay,
let's
talk
about
the
approval
workflow.
So
when
we,
when
we
talked
about
enabling
prowl,
we
decided
initially
that
LG
TM
was
going
to
replace
tech
review
and
approve,
was
going
to
replace
doc
review
and
general
merge
ability
and,
as
it
turns
out,
there
is
a
there's
a
tooling
chain.
I,
don't
want
to
call
it
a
problem
because
it's
not
necessarily
a
problem,
just
a
difference
in
expectation
about
how
LG
TM
works
so
Jennifer
you
thank
you
for
tracking
that
conversation
in
tests
infra.
D
Historically
and
different
opinions
and
I've
been
thinking
about
it,
son
that
the
larger
issue
is
to
what
extent
can
we
for
that
kubernetes
website
repository,
bring
our
practices
into
alignment
with
that
case
case
repo
and
to
what
extent
does
that
complicate
things
for
us,
because
we
do
have
different
needs
for
reviews
from
code
review
and
well.
The
branching
strategy
is
another
is
another
aspect
of
that
right,
but
for
now
so
that
so
prow
what
happens?
D
This
happened
because
an
upstream
reviewer
who
has
approver
permissions
and
did
a
tech
review
on
a
pull
request
for
1.10
Docs
and
gave
it
an
LG
TM,
because
that's
what
she's
used
to
doing
and
lo
and
behold
there
it
went
emerged
that
was
not
her
intent
and
when
it
was
merged.
She
pinged
me
in
a
DM
and
said:
wait
a
minute.
Why?
How
did
how
and
why
did
this
happen?
Please?
D
D
Thank
you
that
is
holds
if
we
use
that
for
a
tech
review
on
we're,
gonna
have
to
make
sure
that
or
anybody
who
comes
in
doing
a
tech
review.
You
know
in
this
case
it
was
a
sig
lead.
There's
no
she's,
not
particularly
identified
as
a
tech
reviewer
for
us
anywhere.
So
we
have
both
the
decision
about
which
come
to
use
and
then
how
to
effectively
communicate
that
I
think
no
matter
what
we're
gonna
have
to
be
a
bit
hyper
vigilant
on
things
for
a
while.
So.
C
I
have
a
very
strong
feeling
on
this
and
I.
Don't
know
if
this
is
possible,
but
my
strong
feeling
is
that
LG
TM
should
not
have
different
meanings
depending
on
who
you
are
LG
TM
for
us
should
mean
one
thing:
only
tech
review
and,
and
you
don't
get
automatic
merging
unless
someone
who's
given
an
LG
TM
and
someone
has
given
an
approve
the
you
know.
This
idea
that
LG
TM,
if
you
are
an
approver
means
both
LG
TM
plus
approves
I,
think
is
where
the
problem
is
I.
D
F
It's
it's
great
conversation.
I,
don't
mean
to
cut
it
off,
I
think,
regardless
of
where
we
go
with
the
future
of
this,
and
if
they
make
it
configurable
which
I
would
love
but
yeah
I'm.
Looking
at
the
same
comments
and
it's
it's
unclear
if
they
want
to
make
that
sort
of
variability,
an
option
that
we
should
implicitly
start
to
use
hold
as
a
common
option
and
just
you
know,
say:
hey
up
front
hey
this
doesn't
mean
anything
bad
about
your
PR.
F
A
C
Well,
I
think
some
strategy,
like
always
putting
a
hold
on
until
we
unhold
is,
is
fine
for
now,
but
I
I'm
really
against
this
idea
of
LG
TM,
meaning
different
things.
It's
it's
complicated.
It
has
to
be
explained
to
people
and
how
hard
is
it
to
write?
/L
GTM
approves.
If
that's
what
you
really
mean,
what
you
know,
I,
don't.
C
G
Yeah
I
agree
with
Steve
and
also
specifically
I,
like
you
know,
saying,
defaults
and
so
I
don't
think
it's
good
to
have
to
explicitly
say
hold
every
single
time,
because
then,
if
you
forget
and
it's
going
to
get
merged
and
that's
not
the
behavior
that
we
want
I
would
rather
it
be
clean
and
be
like
yeah,
LG,
LG,
TM
and
then
and
then
also
add,
slash
approve.
You
know
if
you
want
to
do
both.
It's
like
yep.
D
It's
also
clear
just
to
summarize
some
of
the
discussion
in
the
any
issue
for
those
who
haven't
looked
at
it.
It's
clear
that
different
people
have
different
expectations
of
the
blast
behavior,
even
though
they
say
it
ought
to
mean
this
that
or
the
other
thing
whether
it's
present
behavior
or
some
other
behavior
they've
got
different
expectations.
D
The
devs
who
LG
TM
the
PR
that
raised
the
issue
for
me
clearly
did
not
expect
a
merge
right,
and
you
know
she's
working
in
you
know
Kate's
case
and
did
not
and
isn't
used
to
that
happening
there
either
and
I
also
agree
that
it's
it's
just
way.
It's
a
matrix
to
have
a
command
mean
something
different
depending
on
what
your
role
is
in
an
owner's
file.
That's.
A
A
A
A
Yes,
well
done
all,
and
let's
talk
a
little
bit
about
what's
next
I
have
seen
issues
opened
talking
a
couple
of
from
Steve
talking
specifically
as
know
Steve
and
Jennifer
talking
about
specific
changes
to
make
next,
do
you
do
you
want
to
cover
briefly
less
the
less
the
specifics
and
more
about
the
I
guess
the
development
cycle
for
for
what
you
see
happening
with
user
journeys?
Next.
C
Are
you
thinking
about
the
issue
that
I
can
remember?
I
opened
was
about
navigation,
and
it
was
just
things
that
I,
you
know
it.
It
works
okay,
now,
I
think
it
could
be
better
in
certain
certain
ways
like
the
way
it
does
automatic
scrolling.
The
way
the
back
arrow
doesn't
always
work
on.
First
click,
an
a
so
I
listed
all
those
things
other
than
that
I.
Don't
remember!
Other
changes
that
I
suggested.
A
D
G
So
now
that
it's
out
I
want
to
have
a
concerted
effort
to
basically
test
it
like
have
people
use
it
get
some
feedback
see
you
know
where
it's
working
well,
where
it's
not
and
where
we
can
improve
things
and
then
also
you
know,
I
think
we
can
also
add
some
things
to
like.
You
know
like
what's
next,
so
if
they
are
part
of
this
user
journey
thing
that
we
can
kind
of
make
that
path
more
smooth
between
the
different
topics
and
I
also
want
to
try
to
understand
the
analytics
better.
F
G
G
F
G
D
Want
to
take
this
too
far
down
the
rabbit
hole
of
details,
but
I
will
post
a
link
in
the
in
the
agenda
and
to
some
really
good
articles
along
these
lines
by
Bob
Watson,
who
has
done
a
ton
with
the
both
the
opportunities
and
the
limitations
of
analytics
for
documentation
and
where
the
interaction
is
not
primarily
transactional.
But
he's
also
he's.
Oh
he's
good
about
the
limitations,
but
then
he's
also
really
good
about
what
else
you
can
do
to
measure
the
effectiveness
and
the
quality
of
content.
So
I
will
find
the
right
links.
A
A
What
what
we
need
to
be
thinking
about,
like
as
a
cig,
is
a
way
to
measure
the
impact
of
what
we
do
and
your
thank
you
for
thinking
about
the
the
site
and
although
the
site
analytics
specifically
in
the
context
of
what
to
do
with
the
reference
hits
from
search
yeah,
that's
a
that's
I
think
that's
worth
sort
of
a
longer
ongoing
discussion,
I,
don't
know
if
we
need
to
silo
it
or
if
we
can
just
cap
it
and
sing
docs,
but
that's
definitely
a
conversation.
I'd
like
to
continue.
A
Okay,
let's
see
so
I
have
next
on
the
agenda
expectations
and
how
to
volunteer
for
review
duties.
This
is
really
important,
but
I
also
want
to
make
sure
that
we
get
time
to
talk
about
how
to
host
cluster
registry
Doc's.
Joe.
Are
you
okay?
If
we,
if
we
switch
the
order
of
cluster
registry
and
volunteer
at
risk?
Okay,
awesome.
Thank
you.
I
think
we
can
still
get
to
it
today.
I
just
want
to
make
sure
that
we
really
get
to
talk
about
hosting
cluster
registry
Docs
yeah,
okay,
so.
A
A
Just
to
recap
how
we
got
here
as
Ivan,
you
joined
sig
Docs
and
asked
what's
the
best
practice
for
where
to
host
Docs
and
how
to
make
sure
the
docs
that
are
generated
from
cluster
registry
are
properly
hosted
in
kubernetes
website
and
like
about
the
tooling
chain
and
about
how
to
make
that
happen,
and
is
that
it
am
I.
Correct,
yeah.
E
Regarding
you
know
what
is
the
best
practice
for
an
official
repository
and
official
kubernetes
repo?
Is
there
precedent
with
some
other
project
that
we
can
use
as
a
reference
point?
You
know
those
those
types
of
questions
and
I
see
that
you
know,
for
example,
Federation
does
exist
in
the
existing
kubernetes
docks
and,
while
that's
the
Federation
repo
has
been
has
been
moved
out,
I
would
suspect
that
that
it
will
continue
to
host
the
documentation
inside
of
kubernetes
dot
io,
so
yeah
I
just
wanted
to
kind
of
get
feedback
from
the
sig.
E
You
know,
regarding
what
you
see
is
the
best
solution
moving
forward
and
granted.
We
are
in
the
process
of
potentially
splitting
out
the
repo
into
maybe
a
cluster
registry,
API,
specific
repo
and
maybe
a
client
repo,
because
we
do
have
a
lot
of
dependencies
on
various
different
X
third-party
libraries
and
things
that
make
it
a
little
bit
cumbersome
to
vendor
in
the
cluster
registry.
But
I.
E
A
A
Guess
one
of
my
questions
about
is
about
what
what
your
particular
like,
what
kind
of
what
kind
of
content
you
specifically
are,
though,
that
we
need
to
talk
about
in
terms
of
hosting
requirements,
I
see
so
Chris
Nova
has
some
questions
I
see
that
she
just
dropped
out,
but
let's
see,
let's
defer
on
those
momentarily
see
if
she
rejoins
us
Joe.
If
you
you
had
your
hand
up,
I
was.
A
E
There
is
currently
discussions
on
potentially
sort
of
refactoring
parts
of
the
cluster
registry
into
some
core
primitives.
Something
like
an
environment
registry.
I
know
that
API
machinery
is
very
interested
in
coalescing.
Some
of
the
aspects
of
the
cluster
registry,
such
as
like
the
kubernetes
api
endpoints,
to
be
able
to
maybe
put
that
in
API
machinery
sometime
long
term,
and
then
the
cluster
registry
would
then
use
that
core
primitive
and
build
on
top
of
it.
Some
of
the
cluster
registry
aspects
of
it,
okay,.
A
E
No,
we
actually
have
our
own
separate
release
since
we're
outside
of
the
kubernetes
reap
already
were
not
gated
by
the
kubernetes
releases
themselves.
I,
don't
foresee
that
changing,
but
right
now
we're
kind
of
on
under
our
own
release
charter,
where
we've
recently
released
a
few
versions
of
alpha
right
now
and
it's
on
our
own
cadence
gotcha.
A
C
Just
that
that
might
serve
as
a
model
for
one
way
of
doing
of
getting
these
new
reference
Doc's
into
kubernetes
data.
Oh
I
see
there
that
there
might
be
three
possibilities.
The
simplest
one
is
Andrew
could
talk
about.
That's
automatically
pulling
and
markdown
files
from
another
repository
into
our
repository
and
just
having
the
markdown
files
viewable
and
then
the
next
easiest
thing
would
would
probably
be
to
do
something
similar
to
what
the
Federation
Doc's
do.
C
They
have
scripts
and
and
golang
code
that
takes
markdown
files
and
generates
a
big
HTML
file,
and
then
that's
what
we
publish
and
then
the
most
complicated
would
be
what
we
do
with
our
kubernetes
api
docs.
That's
in
the
same
section
of
the
table
of
contents
that
I
linked
to
just
now,
and
that's
where
we
use
the
code
that
Phil
with
what
ROC
wrote
and
it's
at
kubernetes
incubator
slash
reference
Docs.
So
those
are
what
I
see
is
the
three
possibilities
in
order
of
simple
you
know
most
most
work,
sure.
A
I
I
can't
recall
the
history
of
Federation
immediately
to
mind
in
terms
of
like
when,
when
in
the
in
the
lifecycle
of
Federation,
like
Federation
docks,
specifically
like
when
we
started
hosting
those
or
cube
ADM
I
wish
I
wish
for
BCA.
Was
here,
I
don't
know.
Does
anyone
remember
when
we
when,
in
the
Federation
lifecycle,
we
specifically
began
hosting
Federation
docks.
F
At
least
in
Fabrizio's
use
case,
it
was
when
they
kind
of
went
beta.
They
wanted
to
explicitly
move
it
in
and
merge
it
with
the
rest
of
it,
and
so
that
was
kind
of
their
big
marker
point
in
terms
of
shifting
it
in
and
then
they
were
adopting
that
same
kind
of
release,
cadence
as
the
rest
of
the
kubernetes
project.
At
that
time,
mm-hmm,
okay,.
A
So
that
that's
that's
a
really
good
question
I
then
I
don't
know
if
we
have
a
really
good
answer
for
you
for
when
the
when
we
would
start
to
begin
toasting,
but
that
I
think
discussion
that
we
need
it's
that's
a
longer
discussion.
I.
Think
that
how
to
do
it
is
probably
easier
to
answer
as
we've
done
it
before.
A
But
the
the
when
the
when
in
the
lifecycle
of
cluster
registry
is,
is
a
more
nebulous
question
and
that's
the
thing
I
think
we're
going
to
have
to
chew
on
so
I'm.
Just
thinking
about
like
what
specifically
we
can
do
next
and
how
to
answer
that
question
and
who
needs
to
who
need
who
we
need
to
talk
to
about
that.
C
A
A
I
suspect
that
will
like
create
some
file
divergence
as
we
as
we
are
like
editing
and
working
on
documentation
files
in
website,
so
we'd
have
to
figure
out
a
way
I,
even
to
make
sure
that
changes
made
in
website
we're
getting
ported
back
to
the
originals
in
in
in
the
cluster
registry
repo,
so
just
to
avoid
merge
conflicts
for
one,
but
also
to
make
sure
the
documentation
is
stays
current.
Jennifer.
You've
got
your
hand
up
with
like
why.
D
C
So
I'd
like
to
hear
Andrews
thoughts
on
this,
but
it
seems
to
me
we
we
would
want
to
set
it
up,
so
we
don't
have
merged.
We
don't
maintain
things
in
two
places.
I
think
that's
what
we're
doing
now
with
a
community
dogs
that
are
pulled
in
and
hosted
under
kubernetes
website
is
that
that
the
definitive
source
is
in
some
other
repo,
and
all
we
do
is
have
a
mechanism
for
pulling
those
in
and
displaying
them.
C
It's
the
same
would
say
that
the
kubernetes
or
the
cube
control
reference
Docs
that
the
definitive
source,
so
that
would
be
the
kubernetes
source
code
itself
and
the
comments
that
are
in
the
source
code
files,
and
so
we
don't
ever
make
direct
changes
to
those
Doc's
that
then
get
into
conflict
with
the
definitive
source.
That's
fair
and
you.
F
G
Right,
okay,
so
I
think
then
we
need
sort
of
like
the
second
phase,
because
we
have
that
script
that
can
import
Docs.
But
then
we
might
want
to
create
some
automation
around
it
so
that
it's
more
frequent
than
the
the
releases.
And
then
we
should.
We
should
come
up
with
some
guidelines
specifically
like
what
they
need
to
what
format
they
should
have
for
the
markdown
files
for
us
to
import
it.
G
Like
specifically,
they
need
to
include
like
the
the
title
and
the
front
matter,
and
we
should
probably
also
have
them
put
in
comments
or
somewhere
so
that
it
says
like
the
where
the
source
is
right
like
this
is
the
repo
where
the
the
canonical
version
is
that
you
should
change,
and
then
we
should
also
in
the
front
matter
market
so
that
there's
like
a
no
edit
like
flag.
So
if
you
have
that
on,
then
it
won't
have
that
edit
button
on
our
on
our
repo
or
on
on
our
site
so
that
they
can't
edit
it.
A
I
agree
with
you
that,
having
especially
for
a
project
that's
approaching
beta,
like
the
frequency
of
updates,
is
going
to
be
faster
than
them
in
our
own
update
schedule.
So
I
even
I
think
what
that's?
What
that's
turning
into
in
terms
of
concrete
action
for
the
cluster
registry
team
for
docs
is.
Are
you?
Are
you
willing
to
adopt
the
kubernetes
style
guide
in
terms
of
like
how
how
your
markdown
files
are
formatted
there?
A
There
are
a
couple
of
things
like
Andrew
mentioned
that
we
would
need
to
add
like
a
no
edit
flag
on
the
the
generated,
or
you
know,
on
the
results
that
we
publish
on
the
on
the
site
and
some
mention
in
the
content
somewhere
that
points
to
a
canonical
source
for
editing
and
and
updates.
I
are
those
all
agreeable.
A
E
I
think
so
I,
you
know
we
haven't
really
implemented
a
documentation
strategy.
Yet,
and
so
can
you
hear
me?
Okay,
okay,
zoom
was
just
freezing
up
on
me
for
some
reason,
and
so
since
we
don't
have
a
strategy,
yet
this
is
kind
of
the
the
discussions
that
I
was
hoping
to
foster
and
and
be
able
to
move
towards
as
we
achieve
beta
and
looking
at
what
what
the
documents,
the
document
eight
can't
speak.
E
The
documentation
strategy
should
look
like
so
I've
taken
a
look
at
some
of
the
things
you
guys
have
some
of
the
tools
you
guys
use
and
some
of
the
tools
it's
some
of
the
other
repos
use,
so
I
think
we
can
definitely
leverage
a
lot
of
that
stuff.
I
know
Jose
pointed
a
lot
of
that
stuff
out
to
me
as
well
to
the
slack
channel
so
I've
taken
a
peek
at
that
stuff.
So
incorporating
that
stuff
shouldn't
be
any
issue.
A
A
B
G
It's
not
that
advanced
yet
so
right
now
it
just
basically
is
it's
a
ghost
script
that
you
run
manually
and
it
will
like
copy
the
repo
and
you
just
specify
from
where
and
then
to
where,
but
yeah
we
can.
If
someone
has
some
spare
cycles,
like
you
know,
well,
actually
we
should
not
have
to
do
like
a
div
to
compare
the
two.
We
should
just
always
pull
in
what
the
source
is,
and
that
way
we
can
just
have
some
simple
automation
that
will
do
it.
G
The
other
option
I
was
thinking
is
we
could
add
it
to
the
build
the
bill
commands
for
like
the
production
site
so
that
when
it
does
a
build,
it
will
pull
in.
Like
a
you
know,
a
fresh
copy
of
the
docks
so,
but
that
would
probably
slow
things
down
a
lot,
because
we're
going
to
be
doing
this
for
a
bunch
of
repos.
C
Just
one
more
thing
about
the
complexity
of
this,
and
that
is,
if
you
want
to
pull,
if
you
want
to
get
from
the
kubernetes
source
code
say
into
our
documentation,
you
need
to
be
say:
if
you
want
to
update
something
in
our
1.9
documentation,
you
need
to
be
pulling
from
the
source
code.
That's
in
the
kubernetes
1.9
branch.
Well,
it's
kind
of
tricky
to
get
things
into
a
kubernetes
release
branch.
E
No
I
guess
just
as
a
summary,
just
to
figure
out
what
kind
of
action
items
there
are.
It
sounds
like.
We
need
to
figure
out
the
beta
strategy
once
that,
once
the
API
becomes
beta,
we
should
have
a
better
idea
of
how
the
repos
may
or
may
not
be
split
weather.
Api
missionary
adopts
any
foundational
cluster
registry
things
in
the
meantime,
it
sounds
like
I
can
probably
communicate
with
the
sig
regarding
how
to
start
incorporating
those
tools
to
start
generating
the
markdown.
That's
needed
and
perhaps
that's
a
discussion
we
can
have
at
that
point.
Yes,.
A
And
also
to
adopt
the
some
of
the
specific
file,
the
individual
file
formatting
for
kubernetes
documentation
like
the
title
block,
like
some
call-out
formatting,
some
of
the
some
of
the
things
that
are
specific
to
how
we
publish
markdown
files
in
the
in
the
turbinates
website.
There
yeah,
basically
just
adopting
the
style
guide
for
content
list.
Okay,.
E
Yeah,
though,
that's
a
something
that
I'll
be
interested
in
so
it
sounds
like
I
can
be
in
contact
with
somebody
from
the
sig
regarding
incorporating
that
into
your
infrastructure
tool
to
pull
in
whatever
we
need
published
and
assuming
that
we
are
adopting
the
style
guide
that
that
you
guys
would
request.
So.
C
E
A
E
A
F
Absolutely
it
sort
of
spurred
out
of
multiple
side
conversations
that
kind
of
came
in
on
the
edges
of
the
cig
slack
channel.
Where
I
had
people
asking
me,
how
do
I
become
a
reviewer?
How
do
I
get
involved
in
this?
You
know
just
that
whole
cascade
of
things
and
then
some
also
some
side
conversations
I
was
Jennifer
about
well,
you
know
we're
not
being
necessarily
very
good
about
always
managing
to
apply
the
style
guide.
F
A
A
A
A
A
Don't
there,
there
may
not
be
like
a
hard
and
fast
rule
that
always
works
for
us
given,
given
that
you
know
we
travel
to
conferences-
and
you
know
holiday
schedules,
and
things
like
that,
but
I
mean
what
what
is
a
reasonable
general
expectation
for
us
to
respond
to
a
PR
assignment
like
is,
is
to
is
48
hours
too
fast.
It
seems
fast
to
me
is
4
days
72
hours
enough
time,
Jo
yep.
F
Originally
I
was
thinking
you
know
hey
if
you
haven't
had,
if
a
once
it
gets
assigned
to
somebody.
If
you
haven't
had
a
chance
to
look
at
it
within
a
week
or
two,
that's
the
sort
of
timeframe
I
was
thinking
about,
then
maybe
we
need
to
allow
you
know
somebody
else
to
come
in
or
explicitly
reassign
it
to
somebody
else
so
that
it
doesn't
get
lost
in
the
in
the
weeds
and
it
never
gets
attention.
A
I,
don't
know
what
are
what
are
folks
thoughts.
What
is
I
mean?
Even
if
you
don't
complete
the
review-
and
you
know
I
think,
like
a
surface,
a
level
agreement
for
when
to
complete
when
the
merger
PR
I,
don't
that's
not
a
discussion.
I
think
we're
ready
to
have
yet,
but
at
least
for
like
just
even
like
a
comment
on
it
say:
hey
I'm,
reviewing
this
PR
just
some
kind
of
response
to
to
a
review
assignment.
But
what
is
what's
a
reasonable
expectation.
C
I'm
kind
of
thinking
one
week
that
the
if
somebody
submits
a
PR
they
ought
to
hear
something
from
us.
You
know
see
that
it's
received
some
attention
in
a
week
and
I
sure
I
don't
always
get
to
that,
because
the
trick
is
trying
trying
to
do.
You
know
my
own
writing
and
blend
that
with
looking
at
other
people's
writing.
It
can
be
tricky
sometimes,
but
I
know
if
I
submitted
a
PR
and
it
and
it
got
no
attention
so
we
starting
to
feel
neglected.