►
From YouTube: Kubernetes Sig Docs 20180410
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 10 April 2018.
https://github.com/kubernetes/kubernetes.github.io
A
A
A
A
See
some
updates
and
reminders
I
would
encourage
folks
if
you
have
not
signed
up
for
rotation
as
the
PR
Wrangler.
The
weekly
role
of
shepherding
call
requests
through
our
queue.
I
would
encourage
you
to
sign
up
for
a
shift
on
that
rotation.
If
you
want
to
shadow
someone
else
as
they
do
it
and
use
that
as
a
chance
to
grow
more
confident,
go
ahead
and
sign
yourself
up
as
a
shadow
next
to
somebody
who's
already
who's
already
taking
that
shift,
it's
actually
kind
of
fun.
A
Let's
see
another
reminder
from
last
week's
discussion:
there
is
no
cookie
licking
permitted
and
in
this
case
cookie
licking
is
not
a
disgusting
habit,
but
rather
the
practice
of
leaving
a
comment
or
any
other
anything
less
than
a
PR
on
in
a
comment
or
on
an
issue
to
try
and
claim
it
as
your
own
short
of
the
way
to
claim
an
issue
is
to
open
a
PR
against
it
and
to
do
that
within
three
days
of
indicating
any
interest.
Otherwise,
issues
are
fair
game.
A
A
A
C
Okay,
the
accessibility
guidelines,
it
I
just
started
putting
up
maybe
two
or
three
guidelines
that
I
was
familiar
with,
based
on
my
experience
in
other
companies
and
I
realized
that
it
was
much
more
than
that
and
the
reference
link
that
I
have
there.
That
has
more
details
about
how
you
go
about
with
the
accessibility
guidelines.
C
Maybe
we
have,
we
all
have
to
work
together,
read
through
the
guidelines
and
then
actually
adapt
it
based
on
our
requirements
for
this
website
and
the
other
one
was
about
capitalization
and
it
was
more
about
just
looking
for
the
words
I
I
just
saw
only
two
words
in
the
I/o
list
and
that's
when
I
started
looking
up
for
the
words
that
probably
had
some
consistency
and
in
some
places
they
were
inconsistent
and
I
added
them.
So
that's
the
only
thought
I
applied
to
that
nothing
more
yeah.
We
need
to
discuss
more
on
that
yeah.
A
D
Added
a
comment:
I'm
admitting
a
bit
opportunistic
here,
I
added
a
comment
to
Reggie's
capitalization,
pull
request
on,
because
Jo
see
see
the
sig
Docs
maintain
errs
only
because
I
thought
that
you
invited
us
possibly
to
consider
a
slightly
different
but
related
question
about
how
how
we
call
out
the
names
of
kubernetes
objects,
we're
not
consistent
anywhere
and
I.
Doubt
very
much
that
will
achieve
consistency,
but
getting
to
some
practice
that
we
all
agree
on
would
be
optimal
and
trying
to
at
least
and
work
towards
it.
D
I
think
might
be
a
good
idea
and
because
so
many
kubernetes
objects
have
in
fact
have
names
that
are
common
words
in
the
land
of
cluster
management
right
they're,
not
just
common
words
period.
They
are
common
words
in
clusters
that
you
wouldn't
necessarily
capitalize
if
they
weren't
the
names
of
objects,
and
then
we
wind
up
with
odd
pluralization
of
things
like
persistent
volume
claim
so
I,
don't
want
to
slide
into
mic
shedding
territory
here,
however,
so
I
will
cheerfully
back
off.
I
just
wanted
to
call
out
the
comment
in
the
PR,
so
this
has
come.
E
Up
a
few
times-
and
we've
decided
in
the
past
that
that
we're
ok
to
have
this
trade-off
in
the
interest
of
not
having
a
style
guide,
be
too
complicated
and
the
trade-off
we
came
up
with
is
that
if
we're
gonna
say
persistent
volume,
we
just
use
it
as
as
the
API
object
is
capitalized.
So
it's
all
one
word
and
it's
camel
capped
and
if
it
needs
to
be
plural,
we
just
put
an
S
on
it,
and
we
understand
that.
That's
a
shortcut
to
persistent
volume
objects
and
we've
discussed
before
that.
B
Yeah
I
always
have
I
always
have
an
interesting
trade-off
of
like
what
what
benefits
the
end-user
and
how
much
time
where
we
going.
This
I
was
focusing
on
capitalization
the
verses
like
the
impact
on
the
end-user,
so
I
do
think,
there's
like
a
scope
that
we
should
define
before
we
start
defining
what
all
the
terms
are
within
the
kubernetes.
I
also
think
that
these
sorts
of
things
like
capitalization
and
naming
should
be
separate
for
the
POW
guide
in
a
separate
branding
guide
for
terminology
guideline,
because
style
is
a
very
different
thing.
D
That
seems
like
a
useful
distinction
from
sort
of
contributory
usability
perspective
to
write,
because
we
don't
want
contributors
to
get
bogged
down
in
capitalization
details
if
that's
gonna
be
a
hindrance
right,
I
mean
I
liked.
I
appreciated
your
explanation.
Steve
and
I
really
apologize.
If
I
was
asking
for
like
going
over
soon
as
a
retread
and
I
guess
we
need
to
do
this
periodically
right.
D
It
comes
down
to
a
question
that
Steve's
raised
in
the
past.
To
you
know
how
much
do
we
want
to
put
in
the
style
guide
how
much
weight
we
want
to
take
out
even
of
the
current
abbreviated
style
guide,
because
there's
a
need
for
solid
technical
content
and
what
is
sort
of
too
much
Mike
managing
right.
We're
constantly
trying
to
figure
this
out.
I
guess
it
seems
like
this
kind
of
discussion,
false
someone
into
that
category,
but
separating
it
out
into
a
word
list
or
a
terminology
list,
might
help
Corral
it
to
boot.
C
A
A
It's
a
success
that
I
think
deserves
more
discussion,
but
it's
a
suggestion
that
I
think
also
needs
to
wait
until
after
we've
finished
the
migration
to
Hugo,
because
any
any
specifics,
any
it's
not
really
possible
for
us
to
have
us
a
discussion
of
specifics
for
variable
implementation
right
now
and
until
we
have
migrated
fully
to
the
new
platform.
So
I
would
ask
that
I.
Think
that's
a
I
think
that's
an
excellent
suggestion.
Raji,
it's
a
discussion
worth
having,
but
let's
defer
it
until
after
the
Hugo
migration
yeah.
B
F
If
I
could
just
jump
in
for
a
minute,
there's
a
couple
things
that
I
thought
about,
while
I
was
listening
to
this
discussion,
one
thing
is:
it
seems
like
possibly
a
heavyweight
solution
to
have
a
variable
for
every
API
object
type
and
it
seems
like
that
would
drift
if
it
wasn't
automated
somehow
and
if
it
was
automated,
it
I,
don't
know
it
seems
heavyweight
to
me.
That
was
one
thought
and
the
other
thought
is
there
could
be
an
impact
on
localization.
F
If
we
decide
we
always
want
to
use
the
API
object
for
something
like
persistent
volume.
The
way
that
you
translate
persistent
volume
in
different
languages
as
a
noun
phrase
that
that's
probably
translatable
content,
but
the
API
object
is
not
going
to
be
translatable
content.
So
that's
something
or
localization
people
to
maybe
give
us
advice
about,
but
I
know
that
I've
seen
problems
like
that
in
the
past
yeah.
A
B
G
B
Is
fun
because
we're
all
in
different
parts
of
the
room,
beginning
the
computers,
because
we
don't
have
a
conference
I,
think
you
know
misty
well,
you
and
I
took
a
swing
at
me
organize
know
and
we
can
make
additional
changes
because
I'm
kind
of
figure
out
where,
like
a
branding
guidelines,
lab
and
seems
like
it
would
actually
land
in
there
based
on
their
career
board.
So
yeah
was
just
reach,
others
on
that
and
see
I'll
team
up
with
me
other
injuries
out
for
the
week.
A
A
A
It's
we
all
have
many
projects
in
flight
and
some
is
stopping
to
dedicate
ourselves
fully
to
one
is
going
to
be
less
effective
than
simply
doing
what
you've
already
done
and
implementing
a
PR
and
asking
for
discussion
around
it.
So
I
would
encourage
you
to
keep
to
keep
doing
what
you're
doing
and
start
bringing
in
pieces
of
accessibility
and
and
just
moving
forward,
moving
forward
with
the
path
that
you're
already
on
chef.
A
Thank
you
all
right.
So
speaking
of
the
Hyuga
migration,
we,
the
docs
meditators,
met
with
Eric
Patterson
last
week
to
talk
about
his
two-day
assessment.
After
two
days
of
work
on
the
migration
process,
he
gave
us
his
assessment
of
what
the
migration
might
look
like
and
how
long
it
would,
how
long
it
would
take
him.
A
The
the
summary
from
that
meeting
is
that
yes,
he's
going
to
proceed
with
migration,
so
migrating
to
hugo
is
a
thing
that
we
are
doing,
and
there
were
two
concerns
of
technical
implementation
that
rose
out
of
that
meeting.
One
was
the
glossary.
The
way
that
we
have
the
glossary
implemented
right
now
is
there's.
A
The
glossary
is
primarily
implemented
through
scripting
and
Hugo
has
a
a
different
tree
based
way
of
handling
glossary
contents.
I
think
the
the
majority
of
the
glossary
can
be
migrated
as
part
of
the
the
actual
like
site
migration
process,
but
for
glossary
entries
that
reference
other
glossary
entries.
Those
are
going
to
require
manual
intervention,
you're
going
to
have
to
go
through
and
revise
those
glossary
entries
by
hand
to
remove
any
script
links
inside
of
a
glossary
entry
to
another
glossary
entry.
A
A
A
So
sorry,
I'm,
just
monitoring
the
chat
in
the
meeting
chat
I
would
like
to
come
back
to
it.
But
let
me
finish
with
the
the
Hugo
migration
piece.
First,
the
other
piece
of
technical
difficulty
that
arose
as
part
of
the
the
migration
was
the
the
way
that
we
have
our
site
laid
out
right
now
we
use
llamo
files
to
indicate
the
the
structure
of
the
site
its.
How
Jekyll
do
is.
A
There
are
yellow
files
that
indicate
they
give
the
structure
for
the
table
of
contents
and
the
what
Hugo
does
instead
is
it
uses
a
tree
based
structured,
so
uses
the
actual
directory
structure
of
files
to
to
set
up
the
the
site
table
of
contents,
and
it's
it's
nothing
that
we
needed
to.
There
isn't
a
lot
of
heavy
lifting
involved
if
anything,
there's
less
because
there
will
be
any
structural
yamo
files
after
the
migration
is
just
something
to
be
aware
of
that.
A
D
We
will
need
to
be
careful
about
the
file
structure,
file
and
folder
structure,
especially
when
adding
new
Docs,
because
that's
gonna
determine
I
mean
I
in
my
recollection
of
the
conversation
last
week.
Is
that
we're
aware
that
the
TOC
straight
out
of
the
gate
is
probably
not
going
to
be
quite
what
we
want
it
to
be,
and
that
we'll
need
to
do
some
content
rearranging
to
support
this
approach,
but
that
the
the
eventual
result
is
more
than
worth
the
trade-off
or
worth
it
anyway.
Remove
hyperbole
Oh.
F
Doc
I
used
two
years
Hugo
and
then
we
migrated
to
Jekyll
and
I.
Remember
that
we
had
front
matter
in
Hugo
that
it
defined
the
parent
for
a
page
and
it
also
defined
the
relative
weight
with
the
for
the
page
among
siblings,
so
that
the
table
of
contents
was
sort
of
manipulatable.
That
way
and
I'm
not
sure
if
that
was
functionality
that
was
in
Hugo
or
if
that
was
customization.
That
docker
had
but
I
know
that
the
directory
based
navigation
was
necessary,
but
not
sufficient
and
I.
F
A
F
That
it
is
alphabetical,
and
then
you
can
wait
things
so
pretty
much.
I
believe
that
the
only
unit
of
organization
is
what
the
parent
node
is
and
then
siblings
within
a
node
I
think
there
may
be
a
way
to
manually
wait
I
mean,
of
course
you
could
assign
a
way
to
every
page,
that's
difficult
to
maintain
when
you
add
new
pages,
I'm,
not
sure
if
they're
decimal
points
in
there
or
not,
but
anyway,
it's
maybe
something
that
we
should
explore,
because
there
may
also
be
multiple
ways:
it's
possible.
D
A
H
That
was
kind
of
just
related
to
to
miss
these
comments
back
then.
So,
once
the
contributor
guidelines
are
updated
them.
What
I'm
willing
to
give
my
opinion
as
well,
if
this
makes
sense
enough,
because
currently
I'm
a
bit
lost
they're
like
three
four
things
in
the
docs
that
where
I
would
like
to
make
some
contribution
updates
and
those
improvements,
but
yeah
like
until
I,
fully
understand
how
it
actually
works
for
the
workflow
works.
It
feels
like
kind
of
a
waste
of
my
time
and
your
time
as
well.
A
F
A
D
That's
not
content
related
on
and
Andrea
is
not
on
the
call
and
I
think
he
might
be
the
person
with
the
answer
to
this
question,
but
one
of
the
thing
I
go
to
the
contributor
guidelines,
all
the
time
to
check
things
that
I
don't
remember,
because
I
have
contributor
guidelines
to
refer
to,
and
even
you
know
they
are
suboptimal,
but
there's
still
information
there
that
I
need
to
check
and
right
now,
if
I
go
to
the
doc
site
and
I
don't
find
an
obvious
place
without
scrolling
around
or
navigating
through
too
many
clicks
to
land
on
the
actual
page,
where
the
POC
shows
up
so
we've
kind
of
user
journey
fun.
D
B
E
The
user
journeys
currently
have
some,
you
know
a
set
of
buttons
where
you
say:
Who
am
I,
you
know
I'm
a
contributor,
and
what
do
you
want
to
contribute
to
docs
and
then
it's
it
gets
you
there,
but
maybe
we
could
fine
tune
that
with
more
of
a.
What
do
you
want
to
do?
I
want
to
you
know,
open
a
pull
request
or
I
be
phrased
even
more
generically
than
that
I
I
want
to
make
a
contribution
to
the
docs.
That's
maybe
I.
E
Think
if
you,
if
we
go
in
with
fresh
eyes
to
the
user
journeys
that
are
on
the
homepage,
it's
not
that
tricky
to
find
okay,
who
are
you
contributor
and
is
it
Docs
or
code
and
and
there
you
are
so
I-
think
I'm
all
for
making
it
easier.
But
I
do
think.
Those
of
us
who
are
familiar
with
the
old
way
have
to
be
careful
to
look
at
it
with
fresh
eyes.
E
E
I
F
I'll
say
that
for
searching
I
just
searched
for
contributor
and
contributor
guide
was
the
number
one
result
so
I
don't
know
if
I
was
a
contributor,
if
I
would
be
searching
for
contributor,
I
have
a
hard
time
putting
myself
in
the
shoes
of
somebody
who
doesn't
know
what
the
document
is
called.
So
that's,
maybe
if
we
could
do
some
user
acceptance
testing
on
I,
don't
know
if
that
was
done
on
the
doc
site.
Redesign
I
wasn't
quite
here
yet,
but
it
would
be
interesting
to
maybe
I'm
right,
the
Docs
or
something
like
that.
F
B
You're
speaking
on
behalf
of
Andrew
I,
think
yeah
I
think
the
original
doc
crate
was
the
contributor
page
that
you
would
land
on
the
docs
home
and
it
would
just
say
that's
how
you
contribute
to
the
cares
affection.
So
when
people
landed
on
that
page
they're
kind
of
confused
they're,
like
I,
don't
want
to
interview
I
just
want
to
read
the
contact.
So
there's
a
flip
there,
but
I
think
we've
gone
extremely
in
the
opposite
direction
or
the
contributor
contact
is
impossible.
The
five
so
I
think.
E
B
C
Experience
I
think
all
the
content
is.
There
is
just
not
too
accessible
it's
hidden,
so
probably
based
on
one
the
experience
of
the
contributor
or
how
new
or
how
old
they
are,
the
search
with
different.
So
that
would
become
more
context
driven.
So
the
content
is
already
there.
We
only
have
to
present
it
to
them
in
what,
in
that
context,
they're
looking
for
I,
don't.
F
A
One
second
I
just
need
to
look
at
the
agenda,
looks
like
the
only
thing
that
we
have
left
is
a
proposal
from
Joe
heck
about
some
or
heavyweights
to
the
SS,
but
I
don't
see
Joe
here
so
I
think
we
can
defer
that
discussion
and
continue
this
one
I
do
want
to
jump
in,
though,
and
I
want
to
separate
out
this
I
want
to
separate
out
what
we're
talking
about.
Let's
remember
that
this
isn't
the
the
initial
proposal
that
Rashi
is
talking
about
is
implementing
a
chatbot.
A
So
let's
talk
about
searchability
and
an
information
architecture
separately
from
implementing
a
chatbot
implementing
a
chatbot
is
an
interesting
idea.
It
also
sounds
to
me
pretty
heavyweight.
It
sounds
like
that
would
be
all
of
the
effort
that
we
could
put
into
implementing
a
chatbot
might
be
better
directed
at
improving
our
information
architecture.
So,
in
terms
of
let's
implement
a
chatbot
to
solve
this
problem,
do
folks
have
an
up-or-down
just
an
easy
up
or
down
on
is
the
chatbot.
The
right
way
to
go
is
the
chatbot.
A
F
B
Yeah
I'm
unsure,
if
I
would
use
it
either
I'm
also
unsure
of
how
they
created
into
the
existing
workflow
or
the
tooling
necessary
for
it
I.
Do
you
think
we
make
the
problem
that
it's
trying
to
attack
is
important
and
I?
Think
it's
well
stated:
finding
Inc
I
need
people
through
the
contributor
content.
We
don't
do
a
good
job
of
it.
We
need
to
improve
it,
but
I,
don't
think
a
chatbot
makes
a
lot
of
fun
to
me.
I
guess.
D
I
would
hate
to
see
the
effort
to
create
a
chatbot
take
priority
over
cleaning
up
content
right.
It
seems
as
though
that's
the
first
order
of
business
white
folks
are
not
landing
and
I'm
not
talking
about
navigation
here.
I'm
talking
about
the
project
that
misty
is
leading
on
to
those.
Presumably,
you
know
improve
the
information
architecture
start
with
what
really
feels
like
a
true
entry
point
for
first-time
contributors
and
build
from
there.
I'm,
not
I'm,
being
very
general
here,
because
I'm
not
trying
to
make
any
assumptions.
I'm
gonna.
D
Focus
on
the
chatbot
folks
I.
Well
so
I'd
like
to
see
us
focus
on
that
work
first
and
then,
if
we
decide
that
a
chatbot
could
help,
you
know
sort
of
improve
the
presentation
of
the
content.
You
know
I
guess
I
think
best
case
for
a
chatbot
is:
let's
defer
I'm,
not
in
favor
I'm,
certainly
not
in
favor
of
front-loading
it
right
now.
Montana
shoes.
Okay,
if.
A
E
Okay,
so
this
is
the
newly
designed
you
know
front
door
to
the
docks
and
front
center
there.
We
see
a
button
labeled
contributors,
okay,
so
if
people
are
finding
this
difficult
to
find
and
now
what
do
you
want
to
be?
A
docks
contributor
or
a
code
contributor
or
you
know-
is
this
difficult
for
people
to
to
click
contributors
and
then
click
Doc's,
contributor,
I,.
G
F
It
should
be
contribute
to
dot
dot
and
then
the
choices
should
be
Doc's
or
code
or
community
I,
don't
know,
like
obviously
you'd
want
to
prove
that
with
some
kind
of
testing.
But
it
seems
to
me
that
Doc's
contributor
just
makes
a
lot
of
button
text
and
also
Doc's
and
code
are
the
same
number
of
letters
and
have
similar
letters
in
them.
That's
kind
of
hard
to
visually
parse,
like
that's
kind
of
a
dumb
thing
to
say,
but
that
just
jumped
out
at
me.
It's.
E
Change
either
yeah
at
any
rate.
If,
since
this
is
our
most
recent
attempt
at
at
putting
a
front
door
on
the
docs,
this
I
think
is
where
we
should
concentrate
our
efforts.
If
we're
going
to
improve
discoverability,
we
should
first
look
here
and
say:
what's
what's
working
here
and
what's
not
working
here?
How
could
we
make
this
better,
so.
F
One
thing
that
I
think
would
help
I
think
that
a
lot
of
people
have
been
really
trained
on
the
Internet.
To
expect
the
left
now
and
I
know
that
we
specifically
went
away
from
a
left
nav
but
I
wonder
if
there's
a
way
that
we
could
it
optional
to
have?
Who
left
now,
I
think
some
people
probably
just
feel
insecure,
because
they
can't
see
all
the
context
of
where
they
are.
D
Misty
said
is
exactly
to
the
point
that
wanting
the
context
it's
not
I
mean
I
have
to
keep
clicking
the
next
part
of
the
user
journeys
separates
out
the
different
components
you
know
this
is.
This
is
a
somewhat
artifice
and
Andrew
and
I
worked
on
this
page,
and
this
is
a
really
artificial
attempt
to
shoehorn
the
Ducks
contribution
guidelines
into
the
model
that
we'd
already
established
for
the
code.
D
You
know
for
the
kubernetes
user
journeys
so
that
that's
a
piece
of
history
there
there's
you
know,
there's
some
artificial
attempt
to
create
parallelism
here,
and
this
is
where
my
brain
falls
over.
It's
like
okay,
I
know,
I
need
to
click
on
one
of
these
and
then
I
will
get
to
the
page
where
I
can
see
all
the
left
nav-
and
you
know
sort
of
remember
which
bit
it
is
that
that
I
actually
need
to
look
up,
but
we're
at
how
many
mouse
clicks
now
and
my
brain
is
still
going
wait.
D
A
minute
I,
don't
remember
quite
where
which
which
one
of
these
my
bit
falls
into
now.
I'm,
an
experienced
user
I,
don't
know
about
power
user,
but
so
that's
you
know,
possibly
not
what
we
want
to
optimize.
The
content
for
I
would
just
like
to
suggest
that
for
those
of
us
who
need
to
refer,
often
all
the
names
might
be
a
nice
alternative
and
I
know
you
can
keep
scrolling
down.
That
means
you
need
to
keep
scrolling
down
I'm,
not
even
sure
it
shows
up
here.
D
Oh
yeah,
okay,
eventually
very
bottom,
and
that
again
is
a
piece
of
the
story
of
optimizing.
This
page
or
you
know
the
kubernetes
content,
not
the
contribution
content.
What.
E
D
There's
no
there's
no
solid
usability
or
design
reason
for
the
numbers.
It
was
a
ship
and
be
piecing.
E
E
C
E
Yeah,
this
is
sort
of
substance
opposed
to
substitute
for
having
the
left,
nav
I
guess
what
I'm
more
interested
in
right
now
is
at
the
top
of
the
page.
What
needs
to
be
different,
I'm,
not
sure
people
get
to
this
bottom
stage,
that
that
much
but
experiencing
I'm
having
trouble
finding
this
or
that
then
I
think
at
the
top
of
this
page.
That's
where
we
need
to
try
to
do
better
so
having
a
left.
Nav
is
one
concrete
suggestion
that
might
help,
but
what
else
might
help
here?
I.
F
C
F
Get
trained
and
how
to
experience
websites
and
they're
sort
of
like
certain
archetypes
of
websites,
and
this
doesn't
fit
any
of
those,
so
I
think
people
may
have
trouble
just
accepting
this
and
trusting
the
way
that
it
works
just
because
it's
so
different,
I
can't
really
think
of
another
website.
That
seems
to
work
like
this.
E
The
reason
I
think
the
reason
Andrew
launched
this
whole
project
was
I
mean
there
were
the
two
ends
of
this
are
the
way
it
used
to
be.
Is
we
felt
like
there
was
so
much
there
that
people
couldn't
even
imagine
where
to
start?
So
this
was
the
design
to
help
you
narrow
down
what
you're
going
to
look
at,
depending
on
what
you're
interested
in
and
now
at
the
other
end,
there's
this,
which
leaves
you
leaves
people
feeling
a
little
nervous
that
they're
not
seeing
the
whole
picture
right.
So
we
it's
tricky
for.
E
F
Think
a
core
principle
for
me
with
tech
writing
is
that
tech
writing
is
not
supposed
to
be
shiny.
It's
supposed
to
get
out
of
the
way
like
this
is
sort
of
the
same
kind
of
thing.
Where
we
say
we
don't
we
use
repetitive
language.
We
don't
use
fancy
language,
we
use
the
simplest
terms.
We
can.
We
use
good
typography,
so
the
things
are
readable,
I
sort
of
think
like
we
don't
need
to
be
too
fancy
with
the
design
of
the
site
for
the
same
kind
of
reasons
like
I.
F
D
B
D
B
One
thing
before
today:
it's
kind
of
kind
of
crappy
to
hand
it
off
the
way
I
like
there
I
just
want
that.
You
know
I
know
that
this
was
always
a
sort
of
minimum
viable
product
and
there
was
always
an
effort
to
do
a
lot
of
revamping
on
those.
So,
like
you
know,
if
this
new,
your
feedback
and
commmunity
like
totally
welcome
a
simplified
the
slack
and
make
the
updates
that
need
to
happen
and
with
that
joke.
I
That's
great,
this
is
real
simple
I
need
help
with
CSS,
especially
someone
who's
familiar
with
cross
browser,
implementations,
cuz,
that's
the
thing:
it's
buggering
up
the
Safari
pulldown
of
the
different
prior
versions.
It's
only
Safari
and
I've
been
unable
myself
to
kind
of
figure.
It
out,
I've
taken
a
number
of
stabs
a
bit
over
the
couple
days,
but
I'm
just
a
weak
Punk
when
it
comes
to
CSS,
so
I'm,
hoping
that
somebody
else
here
knows
someone
who
can
we
can
drag
into
this
and
say.
I
I
I
J
B
D
Okay,
we
can
do
on
sticker
links
to
the
planning
Docs
for
the
project
in
the
channel.
People
can
take
a
look
at
the
documentary
history
of
it,
I'm,
not
sure
how
well
that's
gonna
translate
into
understanding
how
we
got
to
where
we
are,
but
it's
what
we've
got
in
the
way
of
an
archive
as
your
resident
archivist.