►
From YouTube: Kubernetes Sig Docs 20171024
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 24 October 2017.
https://github.com/kubernetes/kubernetes.github.io
A
A
B
D
A
It's
a
I've,
seen
your
contributions
all
over
through
the
repo
it's
nice
to
actually
get
to
talk
to
you
in
person,
okay,
so
moving
on
to
dock
Sprint's
for
cube
con
Jared.
Are
you
in
here?
If
you
want
to
say
anything
about
that,
I
do
not
see
Jared.
Okay,
so
I
talked
to
Jared
about
stock,
sprint
zakat
coop
con
yesterday
and
he
pointed
out
that
we're
going
to
have
two
rooms,
so
it
would
be
ideal
to
run
a
two
different
sprints
and
the
ones
that
came
in
at
the
Oh.
A
A
C
C
Jo
has
been
has
been
working
on,
like
the
clothes
drop
finger
and
Luke
who's
on
right
now
has
been
helping
out.
So
if
we
can
kind
of
it
out
so
that
the
doc
sprints
in
like
I,
don't
know
kind
of
either
supplement
what
they're
doing
or
help
augment
it
like
I.
Just
don't
want
to
sort
of
stuff
upon
the
work
that
they're
doing
right
now,
because
the
glossary
is
much
more
like
well
defined.
Right,
like
each
person
can
just
write
additional
fairly
small
containing
street,
but
the
user
journey.
C
Yeah
I
think
that's
better
right.
Yeah
yeah,
like
I,
said
the
the
glossary
stuff.
That's
it's
pretty
straightforward
because
they
can,
just
like
discreetly,
add
individual
terms
and
that's
fine,
but
the
user
journeys
is
since
we're
still
kind
of
hashing
it
out
like
we
don't
have
the
kind
of
the
full
frameworks
and
recommendations
for
what
people
should
do
just
yet.
A
C
E
Think
user
journeys
is
a
good
thing
to
try
to
do
in
a
sprint,
I
think
it's
the
opposite
or
what
you're
doing
a
sprint?
It's
something
that
requires
some
deep,
long
thought
and
it
requires
thinking
about
whether
you're
going
to
to
have
a
journey
through
existing
content
or
write,
new
content
or
some
combination
of
those
two
and
I
just
don't
think
it's
a
fit
for
a
sprint.
Yeah.
G
I
absolutely
agree
that
we,
like
user
journeys,
is
too
broad.
Getting
something
more
specific
nailed
down.
I
think
is
vital
to
have
it
be
useful,
but
if
we
made
it,
if
we
thought
in
the
planning
stages
in
terms
of
something
that
would
support
the
user
journeys
effort,
even
if
we
labeled
it
someone
differently
like
right
now,
I'm
still
planning
refactoring
that
all
of
the
mini
cube
content,
because
it's
all
over
the
place
and
bits
and
pieces.
G
And
how
can
we
make
this
sort
of
a
clearer
set
of
and
smaller
set
of
topics
that
you
know
both
point
people
to
a
bunch
of
different
resources?
And
then
do
so?
You
know
in
a
more
predictable
way,
there's
tons
more
content
like
that,
and
maybe
this
could
also
be
a
place
where
all
of
the
work
that
Steve
did
in
his
github
project
to
identify
refactoring
existing
content.
G
F
I
think
it's
well
said.
Thank
you.
I
I
totally
agree.
If
we
have,
if
we
have
a
framework,
what
we
want
people
to
work
on
through
user
journeys,
excellence,
if
we
don't
think
we
can
add
that
on
time,
I
do
agree
that
the
conceptual
work
of
your
user
journeys
is
not
something
we
want
to
do
during
the
docs
bread.
So
this
being
like
a
month
and
a
half
out,
is
that
something
we
could
have
ready,
it's
so
great.
If
not,
then
we
should
pick
something
else.
I.
C
G
D
G
A
G
G
A
I'm,
just
thinking
about
like
a
possible
Plan
B,
another
thing
to
Jarrett
and
I
talked
about
was
going
through
going
through
the
open
issue
log
and
like
looking
at
issues.
That
would
be
like
very
simple,
very
well
bounded
small
enough
they're
bite-sized
pieces.
That
would
be
good
to
work
on
in
this
print
and
it
would
be
more
of
a
grab-bag
approach,
I
guess,
to
to
improving
documentation,
but
that
might
not
be
a
bad
way.
A
bad
alternative
is
just
to
look
at
sort
of
general
and
ambient
improvements
to
the
quality
of
documentation,
yeah.
F
I
think
I.
It's
it's
interesting
too.
Well,
because
I
showed
up
late.
Can
we
agree
that
the
glossary
is
also
a
good
project
to
work
on
amazing?
We
have
two
rooms,
so
that
makes
sense
to
do
two
projects.
I
I,
think
if
our
goal
is
to
get
better
content
out
of
this,
then
that's
maybe
the
user
journey
is
sort
of
orient.
That's
the
project
to
work
on
this
better.
E
We
have
the
project,
that's
called
something
like
kubernetes
documentation,
I
put
a
link
to
it
in
the
meeting
notes
that
has
things
you
know
suggested
things
that
people
can
work
on
and
it
comes.
They
come
in
small,
medium
and
large,
so
I
would
think
we.
We
could
use
that
as
a
place
to
add
any
additional
things
that
we
think
are
the
right
issues
to
work
on
that
could
kind
of
be
a
home
base
for
a
thing.
You
know
where
people
can
find
things
that
they
can
work
on
during
a
dock
sprint.
A
That's
also
I,
like
that
idea.
I
like
having
a
ready
resource
at
hand
and
Jennifer.
Yes,
you're
you
are
right
is
a
we
don't
have
to
just
you
know,
have
to
two
projects,
and
they
will.
They
are
one
size.
They
will
fit
all
it's
possible
to
come
with
an
array
of
possibilities,
but
I
also
feel
like
that's
an
easy
way
to
to
defuse
very
quickly
in
to
defuse
energy
very
quickly.
G
Agree
absolutely
agree
as
as
you
and
Jared
were
speaking,
no
I
was
thinking,
okay,
so
sort
of
coming
through
the
issues.
That
approach
is
kind
of
like
what
we
used
at
write
the
docs
earlier
this
year
and
I
think
that
worked
well
in
that
context,
and
if
we
get
a
bunch
of
contributors
sort
of
at
that
novice
level,
then
that's
appropriate.
H
A
A
E
Can
work
on
that
I
think
it
should
be
the
same
projects
that
we
already
have
and
we
might
want
some
way
of
marking
things
in
there
that
we
think
these
are
the
you
know
nice
opportunities
for
the
docs
print
mm-hmm,
but
I,
don't
think
we
need
a
separate
process
and
I
think
we
can
use
that
same
one
and
here's
another
thought
I
like
this
idea
of
asking
people
the
experienced
ones.
Is
there
something
that
you've
always
wanted
to
add
to
the
doc
something
you
have
a
strong
feeling
about?
E
If
so,
what
is
it
and
we'll
talk
to
you
a
little
bit
about
maybe
where
it
would
fit
and
and
go
because
one
thing
I've
noticed
about
contributions
from
people
is
that
if
you
put
a
list
of
things
in
front
of
people
and
say
here's
the
things
we
think
should
be
done,
you
don't
get
as
much
traction
as
if
people
say
you
know,
I've
got
this
thing.
I
really
want
to
do
that's
when
you
really
get
traction
sure.
A
F
And
I
think
that
ties
in
well
with
Jennifer's
comments
around
freeing
multiple
projects
that
people
sort
of
select
so
I
like
this,
like
flexibility,
I,
think
getting
feedback
from
people
like
our
Doc's
working.
What
should
we
do
to
improve
like
not
only
the
content
and
what
they
want
to
build,
but
also
what
are
our.
H
G
Invite
people
to
speak
in
very
specific
sorts
of
ways
if
I
hear
more
person
say
the
kubernetes
documentation
sucks.
Well,
you
know,
I
did
I
did
screen
shot
that
tweet
about
how
good
it
was
compared
to
I
forget
who
else's
and
I'd
you
know,
I'll
just
put
that
in
an
auto-reply
or
something
anyway,
I
mean
I
doubt
that
we
will
get
people
coming
into
a
sprint
preparing
to
work
in
a
sprint
with
that
kind
of
sort
of
splat
mentality.
But
you
never
know
there.
A
F
C
Is
there
a
way
to
contact
the
people
that
are
interested
in
in
doing
the
sprint
ahead
of
time,
because
we
could
like
one
possibility
to
say
like
hey
if
there's
a
particular
issue,
you're
interested
in,
like
specifically
I,
could
get
hub
issue
or
one
that
they
create,
they
can
bring
that
in
and
we
can
kind
of
help
them
work
on
it
themselves.
You
know,
and
then
we
can
tag
all
the
issues
with
the
docs
print
like
milestone
or
something,
and
that
way
we
can
easily
find
them
yeah.
Let
me
check.
A
A
A
E
Their
idea,
I
can
talk
about
it,
a
little
just
to
kind
of
get
us
all
thinking
about
it
sure
the
proposal
is
to
use
our
master
branch.
The
same
way.
Development
teams
use
their
master
branch,
which
is
new
material.
That's
not
ready
to
be
published,
yet
gets,
gets
written
in
master
and
then
at
some
point,
when
you're
ready
to
have
a
1.9
release,
you
you
make
your
cut
a
1.9
release,
branch
off
a
master,
and
then
that
becomes
a
1.9
release
and
that's
it's
that
branch
that
net
áfive
builds
our
public
docks
from.
E
So
the
advantage
to
this
is,
it
would
just
be
more
familiar
to
most
of
the
engineering
teams
who
work
that
way.
They
find
it
backwards
that
masters
where
we
do
continuous
improvement
and
a
side
branch
is
where
we
put
stuff
that's
going
into
the
next
release,
and
so
here
this
is
the
way
if
it
were
going
to
work.
I
think
it
would
work
this
way
right
now.
E
We
would
only
have
two
branches
we
would
have
released,
1.8
and
and
our
public
docks
would
be
presented
off
of
that
branch
and
it
continuous
improvement
would
go
into
that
branch
and
that
would
be
the
default
branch.
When
people
open
pull
request,
then,
if
somebody
has
a
one
piece
of
1.9
works,
they
would
check
it
into
master,
and
that
is
not
where
we
would
publish
from
so
those
would
be
the
only
two
branches
we
would
have
right
now.
I
C
Problem,
I
think,
is
with
the
ambiguity
of
the
name
master,
because
it
doesn't
really
tell
you
which
version
you're
on
and,
like
you
know,
the
developers
use
it
as
like
the
current
working
wine
and
we
use
it.
As
you
know,
the
one
that's
like
the
current
stable
version.
That's
like
live
on
the
site,
so
my
problem
with
it
is
just
like
I'd.
E
The
thing
is
the
only
reason
we
would
do
this
is
to
please
the
people
who
think
of
master
in
a
certain
way
right.
So
if
we're
going
to
do
this
to
make
the
engineering
teams
comfortable,
that's
the
whole
point
is
that
we
treat
this
master
branch
the
same
way
they
do.
So
if
we
I
don't
I,
don't
think
it
would
make
sense
to
change
the
name
of
it.
So.
E
F
E
E
J
J
A
Merge
1.8
into
master
is
that
it
would
be,
it
would
create
consistency
across
all
of
the
different
SIG's
for
for
development
teams.
I
have
not
like
if
we,
if
we
adopted
this
change,
would
we
be
resolving
or
creating
technical
debt?
That's
I
mean
let's
break
that
down.
Would
we
is
there
any
technical
debt
that
we
would
resolve
by
adopting
this
approach.
E
G
So
I'm
not
sure
about
the
technical
debt
question
here
that
there's
a
conceptual
one
that
troubles
me
so
the
model
that
the
developers
are
used
to
is
one
that
does
not
in
fact
continuously
does
not
in
fact
continuously
deploy.
You
know
if
you're
not
continuously
deploying
improvements
to
the
codebase
right.
The
whole
point
is
you
fill
up
work
on
master
and
then
you
cut
a
release
and
you
cut
a
patch
to
that
release.
G
The
whole
model
for
releasing
the
deliverable
based
on
the
relationship
between
branches
is
fundamentally
different
for
codes
and
products
where
we
are
continuously
improving
the
content.
Whatever
the
current
version
is
we
don't
worry
about
porting
back,
we
don't
do
patches,
we
don't
cut
releases.
We
do
this
continuous
development
that
doesn't
ever
get
deployed
so
I'm
a
little
concerned
that
there's
a
false
equivalency
here.
That's
maybe
at
the
heart
of
some
of
why
we're
having
a
hard
time
talking
about
this
stuff
about
it.
Take.
I
That
one
step
further,
if
they
had
higher
quality
contingent
evasion,
tests
and
quality
Suites,
they
would
be
moving
more
towards
a
model
of
running
off
of
master,
so
they
would
new
ports
towards
us.
We're
just
able
to
do
it
because
we
make
changes,
not
fewer
things
are
breaking
so
that
makes
this.
Ideally
they
should
be
moving
more
to
us
and
be
able
to
run
two
weeks
off
mask.
Or
what
have
you
not
do
release
this?
If
you
have
a
better
quality
testing,
suite
am
I
going
to
get
Clemson
saying
that
I'm
looking
around
not.
A
I
A
Also
there
there
is
a
piece
of
technical
debt
that
I
can
see
being
created,
which
is
right
now
on
document
are
on
individual
pages
for
documentation.
We
have
a
link
for
opening
an
issue
in
the
repo
for
a
particular
page
of
documentation.
Saying
is
there
an
error
goes,
you
can
click
the
button
and
it
goes
to
the
open.
An
issue
I
mean
that's
a
that.
That
is
an
implementation
change
right
there
that
we
would
have
to
make,
and
we
would
have
to
figure
out
how
to
do
that
across
multiple
versions.
A
E
Not
to
me
like
most
of
us
like
it
the
way
it
is
I
think
if
Jordan
Liggett
wants
to
come
to
one
of
our
meetings
and
present
his
case,
we
should
we
should
hear
him
out,
but
since
he's
not
here
today,
it
sounds
like
most
of
us
are
leaning
towards
leaving
it
the
way
it
is
absolutely.
A
E
A
I'm
happy
to
take
this
to
take
the
discussion
into
the
sig
Docs
channel
on
slack
and
say:
hey
we
talked
about
this.
This
is
this.
This
is
where
discussion
went.
If
you
want
to
talk
more
about
it,
we
are
absolutely
happy
to
hear,
hear
your
case
and
hear
what
you
have
to
say
about
it,
but
otherwise
the
the
the
way
we
do.
It
works
fine,
I,
okay,
so
that
is
Ducks
development
branch
I'm,
just
looking
at
where
we
are
for
time
well,.
C
C
A
Additional
benefit
to
that
is
that,
once
we
get
translation
rolling,
if
we
get
people
who
are
interested
in
doing
other
translations
having
a
stable
release
branch
that
we
only
like
merge
master
into
that
release
branch,
having
a
having
a
fair
like
that,
a
term
of
frozen
release
makes
translation
a
lot
easier
because
there's
not
a
daily
merge
against
content
or
a
weekly
emerge.
Even
if
we,
if
we
only
update
a
release
branch
when
the
next
release
is
about
to
go
out,
I
mean
that's
kind
of
it
just
makes
translation
a
lot
easier.
C
Alright
I'm
getting
kicked
out
here,
I'll
I'll
talk
to
you
guys
over
there.
A
But
as
we
started
looking
at
the
actual
404s
themselves
at
the
urls
like
where
the
source
URL
was
coming
from
the
actual
formation
of
the
urls,
it
turns
out
that
we're
in
a
much
better
place
with
site
fluorophores.
What
we
were
seeing
were
a
lot
of
bot
crawls
in
different
forms.
We
were
seeing
like
some.
Some
go
engine
was
constructing
URLs
and
trying
to
ping
the
site.
We
were
getting
crawlers
that
were
crawling
text
files
through
they
weren't
even
crawling
the
web
site.
A
They
were
crawling
the
repo
taking
anything
that
looked
like
it
might
be
for
mobile
as
a
URL
and
trying
to
submit
it
against
the
site.
So
things
like
URLs
in
the
human's
text
file
the
robots.txt
file,
basically
bots
were
crawling
any
available
any
any
visible
file,
taking
things
that
look
like
valid
urls
and
submitting
them
against
the
site.
So
the
actual
number
of
404s
was
like
what
we
would
consider
these.
These
things
need
a
redirect
was
very
low
as
less
than
20,
and
that
is
a
vast
improvement
over
previous
months.
A
A
A
I
there
it
could
easily
eat
all
of
the
attention
that
we
could
give
it,
and
it's
not
a
going
to
be
the
best
use
of
our
time
or
focus
as
a
cig
and
I.
Think
the
thing
that's
going
to
be
the
thing
that's
going
to
be
most
valuable
for
us
to
focus
on
is
a
prototype
for
a
translation
process.
What
an
actual
trends
like
setting
expectations
for
all
right,
if
you
are
interested
in
doing
a
translation.
F
E
What
caused
us
to
have
the
Chinese
translation
effort
going
on
I
mean
the
the
only
work
it
has
caused
me
is
that
the
Chinese
translators
find
mistakes
in
the
English
document
and
they
submit
many
pull
requests
with
small
typo
fixes
and,
and
things
like
that.
So
what
are
the
other
tasks
that
come
our
way
because
of
translation.
A
Andrew
I
seen
your
back
I,
don't
know
if
you
have
been
back
enough
to
I,
don't
know
where
you
came
back
in
in
the
conversation.
I
think
you
can
talk
more
about
some
of
the
scope
of
the
work
that
that
has
been
involved
in
just
getting
in
like
getting
getting
a
translation
team
to
a
point
where
they
can
contribute
what
we've
been
asking
of
them.
Setting
expectations
I
think
I
can
give
it
a
little
bit
of
an
update,
but
I
think
you
could
give
a
better
one.
A
C
So
it's
really
just
sort
of
getting
them
in
a
place
where
they're,
self-sufficient
right
and
one
of
the
tasks
is
moving
their
existing
repo
into
the
gooeyness
org,
because
there's
one
that
they
created
called
like
Kate's,
meetup
or
whatever.
Were
they
basically
are
copying
our
Docs
content
and
translating
it
before?
They
then
submit
it
back
to
the
repo?
E
Think
that
reasonable
to
say
that
fixing
the
English
document
is
a
non
goal
of
translation,
suite
that
that
really
does
overwhelm
us,
and
you
know
we
get
to
those
kind
of
fixes,
as
we
have
time
so,
yeah
I
think
that
that's
at
least
a
possibility
is
to
say
here's
the
the
process
is
to
translate,
but
not
to
fix
the
English
Docs.
As
you
go.
A
Think,
where
the
real
overhead
is
I
mean
like
Andrew,
you
point
out
that
the
stuff
is
it's
not
a
huge
burden,
but
where
the
it
is
a
large
burden
to
be
figuring.
All
of
this
out-
and
some
of
this
is
some
of
this-
we
would
have
to
figure
out
for
any
translation
project,
but,
like
Jared
pointed
out,
none
of
us
have
the
expertise
to
do
this
effectively.
None
of
us
have
any
any
real
experience
or
history
working
on
large-scale
internationalization
projects
before.
F
So
I
think
there's
also
a
concern
of
mine
when
it
came,
there's
been
a
lot
of
talk
of
like
how
are
we
gonna
onboard
the
next
five
languages
and
I'm
like
so
it's
that
sort
of
thing
terrifies
where
it's
like.
It
might
not
be
a
lot
of
work
now
to
do
Chinese,
but
imagine
managing
five
different
other
communities
doing
other
languages
like.
A
I
I
did
did
have
experience
for
this
in
another
open
source
community
project
we
used
a
tool,
I
think
was
called
Sanada,
but
the
basic
model
is,
is
you
gotta
have
a
whole
separate
team?
That's
basically
crowdsource!
We
can't
take
this
on
ourselves.
You,
you
may
be
putting
the
things
in
place
so
that
basically,
what
happens
every
time
one
of
us
makes
a
change.
I
There
are
Docs
and
and
we're
ready
to
merge
in
the
master
in
English
there's
a
model
where
you
send
it
over
the
little
changes
one
by
one
and
they
all
get
queued
up,
and
this
other
system
like
zenana,
and
then
you,
you
crowdsource,
that
where
they're
there,
you
know
that
you
get
that
separate
team.
Doing
it
and
there's
a
nice
wiki
page
I
can
go,
dig
up
the
link
where
this
other
community
stores
did
do
this
and
they
were
able
to
make
it
work.
But
it's.
I
I
We
donated
a
whole
bunch
of
translations
because
we
didn't
have
a
whole
bunch
of
all,
but
but
ideally,
what
takes
over
is
this
crowd
sourcing
model
and
teeny
tiny
little
translations
as
opposed
to
an
enterprise
company
at
IBM
for
a
product
we
typically
would
say,
bringing
all
the
translators
twice
a
year
for
each
release
and
that
model
actually
is
pretty
dinosaurs
compared
to
what
you
can
do
in
crowdsourcing.
It's
just
so
much
work
to
get
all
that
set
up,
investigate,
Sanada
and
all
that
stuff,
so
it
can
be
done.
I
F
G
C
A
A
What
is
yeah?
What
is
the
driver?
Because
I
don't
know
right
now
and
that's
that's
something
that
I
think
we
all
need
clarity
about
and
also
being
clear
that
whatever
process
we
adopt
cannot
cannot
overwhelm
us
the
way
that
the
the
sort
of
avalanche
of
small
improvement
PRS
as
over?
Well,
it
has
gotten
better,
but
I
mean
I.
Remember
like
Andrew,
where
you
and
I
in
Steve
are
closing
like
75
PRS.
Every
every
two
days
was
a
little
nuts
and
I.
Don't
I
don't
want
to
go
back
there
so.
A
And
it's
just
like
thinking
about
what
is
actionable
out
of
this
conversation.
I
I
am
going
to
have
a
conversation
with
Dan
Khan
about
what
is
driving
it
from
the
CN
CF
side.
What
is
driving
specifically
that,
what's
the
driver
for
the
Chinese
translation
project,
I
think
I
think
we
need
to
just
continue
I
think
what
we
are
already
doing,
Andrew,
but
also
set
expectations
that
we
are
not
going
to
drive
the
process
through
to
the
end.
On
our
side.
A
We
just
need
to
set
expectations
about
what
those
milestones
look
like
in
order
to
like,
before
we
add
a
language
translation
to
a
language
selector.
We
need
to
have
like
X
percentage
of
documentation.
Translated
here
are
the
essential
pieces.
We
just
need
to
focus
on
setting
expectations
for
this
translation,
and
any
translation
needs
to
do
as
a
as
an
MVP.
A
L
A
E
K
E
So
the
question
is:
if,
if
someone
is
reading
the
1.8,
Doc's
and
they're,
going
through
some
sort
of
task
or
tutorial
where
we're
having
them
do,
steps
is
in
the
is
one
of
the
prerequisites
that
their
underlying
kubernetes
cluster
be
running.
Kubernetes
1.8
works,
you
know,
should
that
be
kind
of
our
default.
So
if,
as
you
scroll
down
this,
let's
look
at
prerequisites
is
where
it
says.
Before
you
begin,
it
says
you
need
to
have
the
kubernetes
cluster.
It
doesn't
say
you
need
to
have
a
1.8
kubernetes
cluster
right.
E
So
right
now
this
is
always
say.
So
we
go
down
a
little
bit
to
the
Amal
file
and
the
first
line
in
the
animal
silence,
someone
thinking
they
were
doing.
The
right
thing
changed
this
API
version,
2
apps,
Z
1
beta
2,
which
is
it's
a
1.8
thing.
If
you
don't
have
a
1.8
cluster,
this
yamo
file
will
fail
and
if
you
had
the
next
step
so
spilled
down
a
little
bit
to
the
next
step,
where
we
see
act,
cute
control
apply,
and
then
we
name
this
animal
file.
E
Well,
if
you
don't
have
a
1.8
cluster,
this
step
will
fail.
In
fact,
right
you
know:
I
just
started
up
a
container
engine
clustered
this
morning,
and
even
today
it
comes
up
with
1.7
cluster,
and
so,
if
I
run
this
command
by
just
doing
that,
you
know
very
simple,
giving
me
the
default
container
engine
cluster.
This
command
fails.
So
we
need
to
decide.
E
You
know
up
in
our
tree
in
general,
in
our
prerequisites,
if
someone's
reading
the
1.8
docs
do
we
want
to
say
you
must
have
a
cluster
and
it
must
be
running
kubernetes
1.8.
Or
do
we
want
to
be
more
relaxed
about
this,
in
which
case
we
might
use
the
the
older
version
that
yeah
Mel
Fowler?
We
might
have
tabbed
instructions
for
1.8
and
versions
less
than
1.8,
so
we
don't.
We
don't
have
to
answer
this
right
now,
but
I
I
just
want
to
put
this
out
for
people
to
think
about.
A
Is
a
really
good
point
and
that's
it's
also
a
fairly
it's
easily
extensible
to
I
mean
to
anything
that
looks
like
a
tutorial
or
any
sort
of
procedural
content
is
specifying
a
needed
version
or
providing
options
for
versions.
I,
don't
know.
I'm
I
am
super
in
favor
of
being
as
specific
as
possible
about
requirements.
A
E
We
either
have
to
give
them
an
option
here
at
cute
control
apply
or
we
have
to
go
into
the
prerequisites
and
say
you
must
have
a
1.8
cluster
and
what
I
wanted
the
other
I
kind
of
lead
towards
giving
them
an
option.
I
I,
don't
think
we
want
to
require
everyone
who
reads
the
1.8
Docs
to
be
running
a
1.8
cluster.
A
No
I
mean
that
raises
an
interesting
question
that
was
like:
how
do
we
it
raises?
The
versioning
question
is:
how
do
we,
how
do
we
keep?
How
do
we
version
content
appropriately
to
have
potentially
multiple
versions
of
the
same
content
available,
depending
on
what
version
of
users
is
looking
at
yeah.
E
E
A
There's
a
it
is
a
much
larger
question
about
versioning
content:
yeah!
That's,
let's
do
research,
let's
revisit
this
next
week
and
plan
to
dedicate
some
time
to
it,
because
it's
it's!
It's
not
a
small
question
and
it
is.
It
is
one
that
we
need
to
address
sooner
rather
than
later.
So,
let's
come
back
to
this
next
week,
thank
you
for
raising
this
Steve.
This
is
really
good.
Okay,.
L
I
think
most
of
my
updates
are
just
text
not
text
but
like
words
rather
than
demonstrating.
Okay,
basically
I
was
working
on
it
this
morning
and
I'm
almost
done
with
Ruby
plug-in,
but
it's
not
completely
working
yet
and
I
would
have
to
make
sure
that
the
CSS
and
JavaScript
is
okay,
I
guess.
The
one
question
that
I
want
to
raise
is
that
I
I
haven't
checked,
but
I
suspect
that
this
has
been
a
slow
down
the
build
time
for
the
site
and
I'm
wondering
as
we
start
to
like
I
guess
like.
L
Are
we
trying
I'm
worried
that,
like
they're,
like
these
neat
features
that
we
can
add
like
this,
like
this
parser
plugin?
But
at
a
certain
point
like?
Are
we
going
to
overload
Jekyll
and
be
extending
it
to
the
point
where,
like
with
all
the
content
that
we
have
building
it
might
take
like
I,
don't
know
how
long
it
takes
now,
but
when
I
build
it
locally,
I
have
to
sit
around
and
like
go
to
another
tab
and
do
some
other
stuff
and
then
come
back
to
it.
L
I'm
just
like
wondering
if
the
stuff
I'm
working
on
might
make
that
worse
and
whether
we
should
be
talking
about
that
sooner
rather
than
later,
and
it
also
related
to
that
on
the
glossary
page
right
now.
It
loads
fine,
but
I
imagined,
as
we
add
more
and
more
words,
it's
literally
just
all
HTML
on
that
page,
so
I
I,
don't
know.
I
haven't
tried
to
like
optimize
a
site
before,
but
I
was
worried
that
that
might
also
become
slower
with
time.
So
just
things
to
raise,
if
any.
L
L
L
Jacko
actually
has
I
was
looking
into
this
in
Jekyll
has
a
built
in
version,
so
I
think
like.
If
worse
comes
to
worst,
you
can
identify
the
pages
that
really
need
to
get
fixed,
I
think
like
the
worst
ones
like
35
seconds,
which
is
not
but
like
they
get
called
multiple
times
so
like
actually
I
will
I
will
follow
up
and
like
link
the
command
that
I
use
to
this
group
or
the
slack
group,
so
that
you
can
run
it
yourself
and
see.
L
C
All
right,
hey
Zach,
can
we
can
we
jump
back
for
a
second
to
the
glossary
thing
for
the
dock?
Sprint
shabam,
because
there's
an
issue
I
added
that
had
like
a
list
of
additional
terms
we
should
add,
but
I,
just
wanna
mention
if
other
people
have
office
of
what
other
keys
like
concept
of
terms
that
we
should
have,
they
should
add
it
to
that
issue.
That
way
will
will
have
sort
of
a
list
for
people
that
you
know
they
can
work
on
at
the
dock.
Sprint
do.