►
From YouTube: Kubernetes Sig Docs 20180619
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 19 June 2018.
https://github.com/kubernetes/website
A
B
A
A
She
did
mention
in
sigdoc
slack
that
it
looks
like
there's
a
release.
Candidate
being
cut
on
Wednesday,
so
sounds
like
good
news,
but
will
that
misty
give
us
more
details
all
right?
So,
let's
see
two
weeks
two
weeks
ago
we
talked
about
PR
wrangling
and
how
the
trying
to
get
folks
to
do
PR
wrangling
shifts
ad
hoc
worked
at
first
and
then
was
not
really
working
well,
so
I
did
a
little
bit
of
math
on
it
and
right
now,
with
our
current
maintainer
numbers,
it
looks
like
if
we
did.
A
C
It's
acceptable
to
me,
but
I
have
a
question
about
that.
Does
that
include?
Does
that
number
of
available
Wranglers
include
a
person
who
would
also
be
serving
as
their
release
Meister.
D
A
C
E
C
A
I
don't
even
want
to
get
into
so
what
I
will
likely
do
is
just
randomize
for
a
quarter
and
then
let
folks,
myself
included,
sort
out
which
weeks
work,
which
weeks
folks
are
going
to
be
out
on
vacation
and
for
things
like
major
holidays.
We
may
just
decide
not
to
have
a
regular
that
week,
like
you
know,
for
for
Thanksgiving
or
for
Christmas.
It
may
make
sense.
Just
not
have
a
regular
that
week,
so
alright
I
will
put
that
together
and
I
think
it
makes
sense
specifically
doing
to
exclude
the
release.
A
Another
thought
well
suggestion:
Erich
Raeder
gave
me
a
suggestion
about
using
putting
together
a
repo
project
to
specifically
devoted
to
PR
wrangling
and
make
it
easier
to
hand
off
the
PR
wrangling
job
from
week
to
week
was
right
now
feels
like
the
first
day
is
really
devoted
to
discovery
of
looking
at
things
that
are
like
you
know,
March
doc,
so
can
issue
and
say
alright.
Is
this
still
an
issue?
Why
is
it
still
an
issue
so
doing
some
work
to
reduce
the
burden
of
discovery
every
week
and
just
make
it
easy
to
pass
off?
F
Are
we
convinced
the
done
will
end
up
being
less
work
or
will
be
some
totally
more
work?
There's
now
you
got
to
make
sure
that
list
is
in
order,
so
good
right.
So
when
I'll
give
it
a
similar,
analogous
example.
So
when
we're
doing
the
Bucks
watch
right-
and
you
know
good
intentions-
Andrew
put
together
this
beautiful
spreadsheet,
of
all
the
lists
of
all
the
bugs
were
trying
to
squash
or
whatever,
but
then
very
quickly
that
spreadsheet
got
out-of-date
and
so
now
I
was
going
to
that
and
have
an
update.
F
Yet
when
really,
we
should
just
go
onto
the
open
issues
list
or
whatever,
because
it
was
just
more
stuff
that
was
now
out
of
sync
and
incorrect
and
people
were
looking
at
that
and
they
were
going
to
pick
a
bug
and
well
now
that
bug
was
already
done.
It
just
wasn't
updating
the
spreadsheet
that
kind
of
stuff,
so
I
think
you
know
every
time
you
got
a
new
source
to
help.
If
the
source
doesn't
stay
up-to-date,
then
then
it
can
hurt.
F
Mean
I
was
ok
with
none
of
these
have
a
name
on
it.
Let
me
go
check,
I
mean,
in
my
opinion,
if
there
was
an
extra
label
to
add
of
something
you
needed
to
highlight
for
the
next
person
to
say,
hey,
you
need
to
really
next
next
next
Wrangler
or
something
maybe
a
label
or
something
I
think
people
would
like
having
it
still
all
in
the
same
list.
Instead
of
having
to
type
now,
it's
you
I,
don't
know
anybody
else,
opinion.
A
A
H
I
think
we're
on
track,
there's
still
quite
a
bit
of
work
to
do
I
ping
in
the
channel.
If
you
are
shepherding
and
it's
our
PR
and
you're
having
trouble.
Let
me
know
it
looks
like
they're
planning
to
cut
the
first
RC
on
Wednesdays,
so
I'm
not
sure
how
many
our
seeds
are
usually
needed.
I
don't
really
know
what
to
expect
for
that.
But
I
am
going
to
do
my
best
to
have
the
111
queue
empty
before
then
so.
A
H
A
A
This,
the
perhaps
the
the
larger
question
that
we're
asking
is:
should
we
be?
Should
we
be
well
the
specific
question
of?
Should
we
be
capitalizing
containers
and
I?
Think
there's
also
a
larger
question
of?
Should
we
be
capitalizing,
API
objects?
Jennifer,
do
you
want
to
talk
about?
Is
there
a
distinction
that
you
want
to
make
meaningfully
bare
between
containers,
specifically
an
API
objects?
Generally,
yes,.
C
I
was
sloppy
in
my
first
reactionary,
did
not
go
look
at
the
PR
and
I
actually
disagree
with
Ryan's
change
in
the
PR
and
because,
as
I
understand
it,
that's
talking
about
two
container
objects.
What
I
see
elsewhere
in
the
docks
is
container
capitalized
when
it's
referring
to
the
generic
container
critter
and
that's
where
I
think
I
that
the
problem
with
capitalization
is
I.
Don't
think
that
we
can
say:
thou
shalt
always
capitalize
this
word
and
have
that
work.
C
Well,
where,
as
you
point
out,
Zach
we're
inconsistent
throughout
the
docks
in
how
we
capitalize
kubernetes
objects.
I
do
think
that
those
should
be
capitalized
and
I.
Think
context
usually
tells
us
I
had
to
deal
with
this
this
morning.
Around
service
objects
where
I
had
a
note
that
I
was
editing.
That
was
referring
to
services
lowercase,
and
it
was
simply
not
clear
from
the
context
whether
it
was
talking
about
services.
Generally,
you
know,
services,
micro
services,
whatever
or
kubernetes
service
objects.
C
F
Know
a
high
degree
we
do
jennifer
and
then
my
thought
process,
I,
don't
know
if
it's
different
than
yours
or
adds
to
it
or
not,
was
but
I
think
container,
it's
a
generic
thing
and
there's
a
couple
different,
like
you
said,
critters
that
that
that
map
to
what
a
container
is
and
and
so
to
me
that
seems
lower
case,
but
all
the
API
objects.
Your
your
replica
sets
your
pods.
Your
service
objects,
I've,
always
seen
those
capitalized
because
it
helps
you
understand.
There's
like
these
class
entities
and
super
Nettie's
to
say
hey.
F
This
is
a
first
class
primitive
and
that's
kind
of
how
I
thought
of
it.
If
that
makes
sense
where
so
the
container
is
generic,
but
those
other
things
are
you
know
not
so
generic
and
and
they
have
a
very
well
defined
purpose
and
definition
and
API,
etc,
etc.
I
don't
know
if
that's
exactly
what
you
were
saying
but
but
but
I
think
it's
pretty
similar.
It's.
C
It's
close
and
where
it
gets
tricky,
though,
is
where
we're
talking
about
containers
and
as
Steve
points
out
in
the
notes
container
is
an
API
object,
and
so
we
do,
and
we've
also
got
this
tendency
to
not
say,
contain
like
like
the
way
I
would.
The
way
I
would
have
fixed
Ryan's,
PR
and
sorry.
If
the
way
I
would
have
fixed
this
PR
94t
would
would
have
been
to
say
the
pod.
Can
the
pod
holds
two
container
objects
right,
because
that's
what
it
seems
to
be
referring
to
I
might
want
to
verify
to
make
sure.
C
So,
but
we're
not
consistent
about
that
either.
The
trouble
is
if
we
say
that
we
want
to
follow
practice
in
the
docs.
We
won't
have
any
style
guide
at
all,
because
there
isn't
a
single
rule
in
the
soil
guide
that
has
consistently
followed
throughout
the
docs
set.
So
I
think
we
need
to
establish
some
reasonable
guidelines
and
work
with
them
as
best
we
can
I
think.
H
That
if
we
capitalize
words
that
we
use
all
the
time,
then
it's
going
to
start
looking
like
Old
English
with
random
capitalization
everywhere
we
talk
about
the
all
of
the
things
that
we
talk
about.
Our
objects
may
be
capitalized
the
first
time.
You
see
it
in
a
topic
or
something
like
that.
I
don't
know,
but
I
just
think
it's
gonna
get
really
unwieldy.
If
we
are
trying
to
do
it
to
every
object.
G
I'll
chime
in
on
this,
the
history
of
this
is
that
we
made
the
easy
choice
to
just
see
it
whenever
it's
an
object,
use
the
camel
casing
that
is
used
in
the
object
itself,
and
we
did
that
for
simplicity,
because
we
thought
that
it
would
be
too
complicated
to
debate
whether
something's
generic
or
proper
name
of
an
object.
But
since
in
several
people,
have
spoken
up
and
said:
ok,
they
don't
really
like
that.
They'd
rather
have
a
guideline
that
distinguishes
between
the
generic
use
of
something
as
the
proper
name
of
an
object.
G
D
A
Agreed
part
of
the
reason
why
I
approved
90
40
is
because
I
think
that
it
is
a
correction
of
what
the
style
guide
I
think
it's
a
correction
of
the
existing
instructions.
That
said
I
also
don't
think
those
existing
instructions
are
necessarily
or
automatically
clear.
I
mean
I
had
to
think
about
that
PR
for,
like
a
good
ten
minutes
before
I
could
figure
out,
should
I
approve
this
or
not,
and
if
that's
ten
minutes
way
too
long
to
think
about
something
that
should
be
abundantly
and
fundamentally
clear
in
the
style
guide.
A
It
makes
it
very
easy
in
the
repo,
but
I
agree
with
the
logic
that
underpins
the
choice
to
distinguish
between
the
two,
whether
we're
talking
about
a
specific
instance
or
whether
we're
talking
about
an
object
or
native
or
if
we're
talking
about
specific
instances
of
them
and
I
think
it
makes
sense
to
capitalize
on
the
former
and
D
capitalized
in
in
the
latter
case.
I
guess
the
the
the
challenge
with
making
any
sort
of
style,
guide
and
well
so
I
agree
with
Steve
I.
A
Think
that
providing
abundant
explanation
and
making
the
style
guide
very
clear
is
his
paramount,
but
I
also
think
we
could
stand
to
go
through
and
make
sure
that
our
style
guide
is
consistently
applied
and
right
now
it's
not
so
I
guess
a
question
that
comes
with
this
is:
do
we
think
that
this
work
is
valuable
enough
to
prioritize
it
over
like
over
the
rest?
I,
don't
know
for
the
rest
of
2018.
G
Don't
think
so,
I
think
it's
a
priority
tip
to
decide
what
we
want
for
guidelines.
I,
don't
think
it's
as
high
a
priority
to
go
through
and
try
to
bring
every
existing
topic
into
alignment
with
that
I
think
there
are
higher
priorities
like
some
of
these
Black
Friday
issues
were
having
with
lists
broken
links.
C
A
It
may
be
helpful
to
have
like
a
standing
just
to
have
an
open
issue
and
allow
multiple
PRS
against
it,
of
I.
Think
about
like
new
contributing
new
contributors
to
the
repo
who
can
go
in
and
take
a
piece
of
content
and
apply
the
style
guide
consistently
to
it.
I
like
having
that
as
an
opening
and
then
letting
individual
contributors
like
those
are
great
first
time
PRS.
A
A
G
G
Or
do
we
mean
that
we
want
you
to
do
a
comprehensive,
bringing
this
document
into
alignment
with
the
style
guide,
because
that's
a
much
that's
a
that's
a
much
more
difficult
proposition
that
a
lot
of
these
old
topics
are
just
absolutely
contrary
to
our
style
guide
in
their
voice
in
their
tents
in
capitalization
in
in
all
kinds
of
ways.
So
you
just
want
to
be
clear
as
to
what
we're
suggesting
what.
A
If
you
want
to
do
like
an
easy,
if
you
want
to
do
an
easy
pass
on
this,
here's,
what
an
easy
pass
checklist
looks
like
so,
rather
than
just
you
know,
hand,
people
and
people
and
people
to
markdown
file
and
ten
people
to
style,
guide
and
say
you
know.
Good
luck
provides
some
some
guidance
about
what
an
easier
versus
a
more
difficult
pass-through
of
content
might
look
like
yeah.
That
makes
sense
to
me.
G
H
E
A
Yeah
I
agree
that
prioritizing
things
like
markdown
fixes
things
that
are
actually
affecting
Doc's,
behavior
and
style.
Behavior
in
ways
that
are
not
expected
is
yet
we
see
more
PRS
about
that
kind
of
break
and
I
think
that
those
are
more
of
a
barrier
than
a
selective
application
of
capitals
to
2
to
8
di
objects.
So
if
it
comes
down
to
it,
then
yeah
I
agree
that,
like
the
markdown
fixes
or
more
are
more
valuable
use
of
time.
A
Alright,
let's
move
on
to
an
asia-pacific
meeting
time.
So
I
did
the
time
zone
research,
here's
what
I'd
like
to
propose
for
an
APEC
meeting
I
think
it's
a
good
idea.
I
think,
let's
start
monthly
and
rather
than
try
and
do
it
on
a
Monday
night.
I
think
it
makes
more
sense
to
do
it
on
a
Tuesday
evening,
Pacific
time
and
that
would
translate
into
a
Wednesday
meeting
for
like
a
Wednesday
morning,
meeting
for
East
and
South
Asia.
So
here's
a
comparison
of
times
like
7
p.m.
on
the
Tuesday
Tuesday
7:00
p.m.
A
A
F
D
H
A
Agreed-
and
that
also
makes
for
a
long
Tuesday
for
I-
think
for
most
of
us
on
the
Pacific
I
mean
I
don't
want
to
if
there
are
any
Pacific
Coast
early,
risers
more
power
to
you.
But
for
me
at
least
that's
a
you
know.
That's
the
bracketing
of
the
day
is
a
10:00
a.m.
meeting
or
10:30
a.m.
meeting
and
ending
with
a
7:00
p.m.
meeting.
A
But
yes,
I,
agree
misty
that,
let's
I
don't
know,
let's
try
it
for
three
months,
see
what
happens
with
attendance,
get
feedback
from
folks
who
actually
attend,
preferably
from
from
a
pack
members
and
and
go
from
there.
I
think.
D
A
A
A
A
A
Basically
optimizing
optimizing
the
English
content
as
good
source
for
internationalization
that
it
looks
like
it's
totally
possible
to
do
with
a
relatively
low
amount
of
effort,
so
that
is
that
is
also
proceeding.
I,
don't
have
any
updates
about
a
time
or
when
that
will
start,
but
that
is
just
sort
of
secret
visibility
that
is
in
process.
A
A
Okay,
let's
see,
let's
move
on
to
how
best
to
generate
cube.
Ctl,
Docs,
Steve
I
pulled
this
out
of
the
email
thread
that
you
were
having
with
chiming,
because
I,
don't
I,
don't
want
that
thread
to
die.
I.
Think
it's
a
very
important
question
about
how
we,
how
we
approach
our
own
generation
and
I
want
to
make
sure
that
it
gets
the
the
discussion
that
it
deserves.
A
G
You
know:
did
you
see
my
reply
where
I
said
whatever
we
do,
it
must
be
different
from
what
we're
doing
now,
because
it
it
is
a
big
hassle
right
now
and
it
never
sits
still
and
part
of
the
reason
it
doesn't
sit.
Still
is
people
like
jamming
or
our
fiddling
with
making
it
better
right
then
one
of
the
drawbacks
of
someone
making
it
better
is
that
if
I
go
through
and
try
to
do
it,
the
way
I
did
it.
Three
months
ago,
I
can't
and
I've
been
trying
to
document
the
document.
G
The
process
of
generating
ref
dogs,
but
I
see
now
that
it's
such
a
moving
target
that
that's
that's
a
waste
of
my
time
to
try
to
document
how
this
is
done,
at
least
until
we
settle
up.
This
is
not
just
about
the
coop
control
dogs.
It's
about
the
kubernetes
api
ref,
dodge
federation,
api
ref
ducks
and
the
ref
ducks
for
compliments
like
you,
baby
up
server,
so.
G
G
G
G
Just
want
to
make
if
we
go
in
that
direction,
I
want
to
make
sure
that
we
really
agree
that
this
is
the.
This
is
the
direction
we
want
to
take
because
I'd
hate
to
have
to
redirect
all
you
know
if
we
create
all
those
URLs
I
hate
to
have
to
redirect
them
later.
If
we
decide
to
do
something
different
same-same.
B
G
H
A
little
bit
uncomfortable
with
the
way
that
they
all
look
sort
of
subtly
different
and
that's
also
a
problem.
It
seems
like
they
all
use
slightly
different
CSS
and
there
see
the
CSS
for
the
ref
docks
is
totally
independent
from
our
normal
layouts,
which
also
caused
problems.
This
time
and
I
guess
Steve
had
to
go
in
and
do
a
lot
of
tweaking.
H
H
Structured
then
we
can
apply
a
layout.
We
could
apply
layouts
to
them
and
make
them
fit
our
site.
Better.
Hi
I
know
that
it's
sort
of
a
tangential
problem,
but
it
all
has
to
do
with
the
way
that
they're
generated
and
I
know
at
docker.
We
managed
to
figure
out
a
way
to
get
gamal,
so
we
could
create
our
reference
stocks
based
on
EML
files
that
we
were
getting
from
scripts
and
plug
the
gamble
directly
into
the
liquid,
and
it
actually
ended
up
being
a
lot
better.
H
Also,
the
yamo
files
were
easier
to
review
because
they
only
had
yeah
Mille
keys
and
values
and
them,
and
they
didn't
have
all
the
stylings
as
well
so
I,
don't
know
how
to
get
there,
because
I
haven't
even
looked
at
how
these
are
generated.
But
that's
my
input
about.
Maybe
a
future
happier
state
I
think.
G
We
we
have
a
bunch
of
what
you're
describing
in
place
already
in
the
urban
eighties
kubernetes
repo.
If
you
go
there
and
look
at
the
under
the
hack
directory,
there
are
these
scripts
like
generate
Docs
SH,
and
when
you
run
that
script
it
generates
sets
of
documents
in
in
many
different
formats.
I
think
one
of
them
is
enamel.
G
H
So
we
were
using
something
with
swagger
files
at
docker
and
the
doctor-doctor
open
source
and
creative
comments,
so
I
can
go
and
look
and
see
how
we
were
doing
it.
But
I
know
that
we
were
taking
the
output
file
from
swagger
and
we
were
applying
a
layout
to
it.
We
had
like
a
one-page
index
file
that
had
a
layout
and
that
was
making
our
swagger
Doc's
look
the
way
that
we
wanted
them
and
I
don't
know.
H
G
G
Makes
it
brittle
is
he
didn't
just
create
a
big
configuration
file
that
says
this
is
the
layout.
He
did
it
through
a
bunch
of
heuristic
pattern
matching
and-
and
that's
where
it's
just
it's
so
hard
to
understand,
what's
happening
when
you
go
from
one
version
to
the
next
and
at
one
point
I
thought
I
could
take
that.
Oh
that's
a
project
and-
and
you
know,
fix
this
and
fix
that
change
the
code
so
that
it
wasn't
so
brittle,
but
I'm
I
see
now
that
I'm,
just
I'm,
never
gonna
have
time
to
do
it.
Justice.
A
A
Something
is
something
that
gives
us
options
rather
than
tying
us
to
the
the
generated
swagger
output,
because
that's
it's
a
it's.
Creating
the
the
problems
that
you
that
misty
points
out
the
this
slightly
off
CSS
for
for
free
each
section,
the
sort
of
the
lack
of
the
lack
of
the
unity
and
the
lack
of
a
consistent
UX
across
all
of
the
the
generated
ref
doc.
A
A
I'm
not
sure
that's
the
best
way
to
go
I'd
like
to
what
do
you
think
Steve
about
like
taking
the
approach
of
like
abstracting
a
presentation
layer
away
from
what
we
are
currently
dealing
with
it
like
if
we
could,
if
we
could
get
to
the
entire
cube
CTL
like
that,
that
single
large
HTML
file,
if
we
could
get
that
instead
and
like
gamma
or
JSON,
and
to
deal
with
presentation
separately?
Do
you
think
that's
a
worthwhile
approach
to
take,
or
at
least
to
investigate.
G
G
G
The
discussion
I
think
we
should
put
everything
on
the
table
for
this
discussion
all
the
way
from
we
get
completely
out
of
this
business
and
just
point
people
to
go
Doc's
right,
that's
the
one
extreme
and
the
other
extreme
is
we.
We
do
something
that
is
really
pretty
and
something
that
we
love.
I.
Think
the
the
pragmatic
thing
is
somewhere
in
between
agree.
A
G
Think
that
for
for
the
API
ref,
the
place
to
start
is
with
the
swagger
spec
that
that's
really
that's
really
nice.
A
nice
piece
of
source
I
think
that
we
can
use
to
then
produce
the
docs
that
we
want
for
an
API
riff
for
a
cute
control.
It's
a
different
way.
That's
not
based
off
as
far
as
I
know
off
any
swagger
spec,
it's
just
it's
a
different
process
of
creating
an
instance
of
the
tool
and
then
pulling
out
the
the
comments
that
are
in
the
source
code.
G
E
E
A
F
So
yeah,
if
you
go
look
at
like,
say
the
version
of
nine
of
the
dogs,
there's
lots
of
other
choices,
one
of
which
was
like
the
IBM
cloud,
one
or
something.
So
they
me
said
hey.
You
know
we
ought
to
write
something
up
to
show
how
you
do
this
for
the
IBM
cloud
and
I
thought
to
myself.
I
was
like
wait,
I
think
we've
added
that,
and
so
it
was
one
of
those
where
it
was
there
before
and
I.
F
Think
through
the
Hugo
translation,
it
got
lost
and
so
I
told
the
person
will
go
up
and
up
an
issue
and
let's
go
at
it.
I
don't
know
if
it
was
because
it
was
one
of
those
links
where
it
links
off
to
something
and
github
or
or
what-have-you.
But
I
told
the
person
open
up
an
issue
but
yeah.
You
know
it
seemed
like
the
those
were
some
important
links
and
I.
Don't
think
it
was
just
the
IBM
one
that
got
lost
if
you
go.
F
Do
a
diff
between
you
know
the
previous
versions
of
the
doc
and
the
current
version.
So
you
know
for
the
IBM
one
yeah
we'll
go,
handle
it
and
whatever,
but
I
still
let
people
aware
you
know
somebody
might
go
what
happened
to
my
product
thingy
and
why
we'll
only
the
other
ones,
just
just
to
be
aware,
was.
G
Kinds
of
missing
there
are
topics
that
are
still
in
the
site,
but
they
don't
show
up
in
any
of
our
left,
nav
that
you
can
get
through
from
the
horizontal
now
I'm
working
on
that
problem,
there's
another
kind
of
missing
where
they
used
to
show
up
in
our
our
left
nav,
and
when
you
clicked
the
item
on
the
left.
Now
that
took
you
to
someplace
external
chores.
F
F
G
F
So
I
told
the
person
open
up
an
issue
and
go
resolve.
It
will
take
you
through
the
process,
but
I
just
want
to
make
people
aware,
because
you
know
those
are
the
ones
were
you
know,
I
mean
you
know,
we'll
fix
it.
Obviously
we
knew
what
was
happening.
It
was
no
big
deal,
but
I
didn't
want
to
else
to
get
blindsided
by
that
that
somebody
might
be
like
we
love
the
because
you
know,
coincidentally,
it's
only
that
the
big
clouds
were
left
there.
A
Heads
up
I
will
also
point
out
that,
for
all
of
the
all
of
the
content
under
setup
right
now,
it's
still
a
long-term
goal
for
the
rest
of
the
year
that
the
goal
is
to
get
rid
of
this
stuff
and
to
point
to
link
out
to
providers
own
documentation.
So
there's
both
short
term
fixes
and
there's
the
long
term
strategy
of
it
doesn't
make
sense
for
us
to
host
what
is
essentially
external
content.
I
I
I
Yeah
anyone's
welcome
to
attend
all
forward
the
invitation
oh
yeah-
this
is
the
this
is
on.
One
of
our
one
of
our
list
of
things
to
accomplish
is
to
come
up
with
the
standardization
for
provider
documentation
so
that
to
make
the
life
of
the
docs
team
easier
and
also
provide
a
consistent
user
experience
across
all
the
providers.
So
it's
gonna
be
our
first
meeting
tomorrow.
So
I'm
sure
this
will
be
one
of
the
items
on
the
agenda.
G
I'm
sticking
notes
something
I'm
gonna
work
on
is
getting
all
of
those
topics
out
of
the
orphans
State,
and
you
know
it's
I
think
we
honor
just
right
away,
get
things
out
of
the
orphan
state,
whether
their
eventual
location
is
going
to
be
different
or
not,
and
then
from
a
from
a
place
where
they
are
now
visible.
Through
our
navigation.
We
can
decide
eventually
what
we
so
I.
D
C
This
is
tangentially
related
only
but
I
will
be
submitting
a
PR,
also,
probably
after
111
ships,
but
very
shortly
thereafter
to
reorganize
the
Kuban
am
part
of
set
up
and
to
put
that,
which
is
I
mean
not
as
stuff
that
belongs
there
and
should
stay
there.
That's
the
kind
of
content
you're
talking
about
Zach,
that's
what
we
want
featured
there
platform
specific
set
up
content,
there's
actually
a
meeting
tomorrow
to
talk
about
reorganizing.
C
A
D
So
my
current
thoughts
around
the
docs
print
were
that
if
it
could
be
around
like
the
translation
efforts,
since
it
will
be
there,
you
know
and
can
work
with
them
for
Sam,
we
can
get
all
that
stuff
in
order
and
make
sure
their
pipelines
good
I,
don't
know
what
that
entails.
Specifically
yet,
but
we
can
figure
that
out
before
we
go.
A
F
F
F
Somebody
wants
to
go
fix
this
by
tweaking
the
CSS
and
I
vaguely
recall,
I
think
it
was
last
week
where
he
said
well,
that's
not
what
we
want
to
do,
and
so
I
just
want
to
get
clarity
and
make
sure,
because
we're
going
to
run
into
people
submitting
these
types
of
PRS
all
the
time
and
I
want
to
make
sure
we're
all
on
the
same
page
for
how
we
want
to
handle
those
I
think
the
proper
fix
is
well.
They
did
the
template
wrong
right.
D
G
C
Well,
there's
been
one
exception
lately,
but
I
mean
it
was
a
fix
to
the
CSS,
but-
and
it
was
a
first-time
contributor
who
was
extremely
responsive
to
suggestions
to
sort
of
investigate
a
little
more
thoroughly
and
it
was
a
real
problem.
We
had
the
CSS
problem,
it
was
not
a
markup
problem,
it
was
not
a
template
problem.
It
was
a
tabs
we're
showing
up
wrong
problem
and
it
was
consistent
across
every
single
page
where
the
tab
options
show
up.
C
It's
now
fixed
I,
guess
I'm,
just
saying
I,
don't
want
to
say
I,
don't
want
to
see
us
blanketly,
you
know
sort
of
as
a
blanket
matter
and
not
accept
CSS
CSS
fixes
when
they
are
fixing
real
problems.
That
CSS
needs
to
fix.
That
said,
I
hear
we
just
say:
inbred
and
I
agree
with
you
about
that
particular
PR.
Cuz
I
looked
at
it
also.
You
know,
and
one
of
the
things
that
I
did
by
way
of
sort
of
backing
up
this.
C
A
K
K
From
that
I
think
in
a
future
version
of
Black
Friday,
they
they
might
make
it
right,
I
think
in
the
future
it
hugo
may
make
that
object
like
an
array
or
a
map,
or
something
that
you
could,
that
you
can
control
and
a
granular
fashion
in
terms
the
HTML
output,
but
but
right
now
you
just
basically
get
nested.
You
know
UL
li
UL
li
on
the
basis
of
the
what
level
the
the
heading
is,
and
so
the
only
way
to
eliminate
the
dot
on
that
diagonal.
G
Sorry,
sorry,
but
I
don't
think
that's
correct
I
looked
at
that
PR
and
the
reason
we
were
seeing.
The
extra
dot
is
because
that
was
a
free-form
topic.
They
were
did
not
was
not
built
around
one
of
our
templates,
and
so
the
fix
in
that
particular
PR.
The
fix
is
to
change
that
topic.
So
it
applies
a
template
rather
than
being
free
form.
You.