►
From YouTube: Kubernetes Sig Docs 20180904
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 04 September 2018.
https://github.com/kubernetes/website
A
A
C
B
A
B
So,
while
your
doesn't
so
basically
the
basically
this
is
this
bot
that
runs
out
in
the
kubernetes
users
Channel
and
like
a
couple
other
channels.
So
what
is
it
really
doing?
Is
just
monitoring
conversations
as
people
are
asking
questions,
we
try
to
find
answers
to
those
questions
and
automatically
respond,
so
I
can
kind
of
give
you
a
more
concrete
example
in
this
in
a
second,
but
so
it's
kind
of
two
parts,
one
part
is
just
people
are
asking
questions.
B
Have
actually
like
automatic,
like
detection
of
questions,
so
that
if
somebody
what
often
happens
somebody
goes
on
the
channel
says:
hey
everybody,
how
do
I
do
this
thing
a
lot
of
times
those
questions
actually
left
unanswered
because
you
know
attention
or
whatever,
and
the
other
side
of
that
is,
you
know,
ends
up
happening.
That,
like
somebody,
keeps
answering
the
same
exact
question
over
and
over
a
while,
you
know
all
the
kind
of
more
interesting
questions
or
the
unique
questions,
or
not
necessarily
the
answer.
So.
D
B
Do
is
yeah,
we
detect
these
questions
and
we
send
them
referenced
us
to
either
so
right
now
it's
kubernetes
Doc's.
So
what
we
do
is
we
went
and
scraped
all
of
the
docs
divided
into
sections
so
that
it's
not
like
sending
you
know
like
somebody
says
how
do
I
delete
a
pod.
It's
not
sending
like
the
giant
like
you
know,
resource
about,
like
the
coop
siku
controller,
like
what's
called
the
command
line
reference,
it's
actually
sending
like
the
kind
of
small
tidbit
of
like
what
actually
needs
to
happen.
B
So
we're
sending
kubernetes
knocks
we're
sending
Stack
Overflow
questions,
and
the
third
category
is
where
what
we
actually
do
is.
While
people
are
having
conversations,
if
somebody
has
to
question
and
another
person
answers
it,
what
we'll
do
is
we'll
ask
for
the
person.
That's
answering
the
question
like
hey.
This
looks
very
useful.
Do
you
mind
if
we
store
it
in
the
future
and
once
the
person
kind
of
says
yes,
it's
cool,
we
can
store
it
then
we'll
kind
of
reiterate
those
same
answers
back
to
future
people
asking
the
same
questions.
E
B
Actually,
a
great
question,
so
a
lot
of
what
the
bot
does
is
is
actually
trying
to
leave
to
get
other
conversations.
Part
of
idea
is
that,
like,
let's
say,
there's
two
people
having
a
conversation
next
to
each
other.
What
that
does
is
it
doesn't
identify
like
okay
person,
a
and
B
are
talking
over
here
person,
C
and
D
are
talking
over
here
so
we'll
you
know,
combine
kind
of
all
the
texture,
a
and
B,
so
it
tries
to
do
that.
It's
not
gonna
be
perfect.
B
You
know
still
using
some
kind
of
like
it's
still
using
like
a
I,
and
you
know
NOP
in
the
background
so
but
yeah
we
that's
one
of
the
goals
is
actually
to
combine
all
the
conversations,
even
if
it's
kind
of
like
you
know
kind
of,
even
even
if
the
response
to
a
question
is
like
you
know
forty
lines
now
and
we'll
try
to
find.
What's
the
like,
what
was
the
person
asking
for
you
know,
we
tried
to
try
the
conversation
of
like
who's
talking
to
who
and
what's
most
likely,
their
question
and
answers
are.
E
B
A
B
Okay,
so
yeah
listen,
I'll,
send
everybody
like
a
link.
I,
don't
know
if
there's
a
chance,
you
guys
and
see,
if
there's
an
email
that
I
can
share,
it's
everybody
or
something,
but
so
I
found
some
kind
of
like
one
of
the
most
useful
dogs
for
the
most
useful
questions
so
far,
because
the
longer
term
has
been
running
for
the
questions
that
are
kind
of
being
re
answered,
like
the
longest
thing
that
we've
been
kind
of
answering
questions
with,
is
other
previous
conversations.
There's
a
lot
more
answers
for
that.
B
B
Is
it
a
you
know,
search
optimization
thing
or
is
it
just
people
don't
know
where
to
find
it
or
is
it
people
just
are
lazy,
so
I
could
send
more
of
this
stuff
and
a
like
I
know
separately.
Also
new
kind
of
like
the
report
I
have
of
some
of
the
kind
of
interesting
questions
and
stuff
a
little
bit
do.
B
So
I
mean
I,
think
people
do
say
in
general,
like
hey
I've
tried
this
I.
You
know
because
this
is
all
like
I
bought.
It
can't
read
all
the
conversation,
so
probably
people
say
something
like
this
I
hadn't
noticed.
The
one
thing
I
was
just
thinking
about.
Is
that,
like
one
potential
thing
we
could
do
is
to
do
something
like
a
survey
right
so
that
when
somebody
answers
so
right
now,
when
we
answer
a
question
for
somebody
would
say,
hey
was
this
useful
to
you
like?
B
Yes,
is
useful
and
answered
my
question,
this
was
useful
or
no
it's
not
useful.
So
we
can
do
is
when
somebody
says
yes,
this
was
useful,
we
can
say
hey.
Do
you
want
to
fill
out
the
survey,
and
we
can
ask
questions
like
this
like?
What
did
you
try
to
search
beforehand?
You
know:
did
you
go
to
Google
good
you
go
to
Docs?
Did
you
go
to
like
all
these
different
sources,
so
I
think
it's
something
we
can
actually
try
to
figure
out.
B
A
Ton
of
questions
too,
so
what
I'm
noticing
is
that
we
probably
all
are
going
to
so
maybe
this
would
be
better
to
have
like
a
dedicated
conversation
where
we
can
hammer
out
some
of
the
some
of
the
technical
details
and
get
I'd
be
able
to
do
some
more
deep
dive,
so
glad
you're
nodding.
So
it
sounds
like
you're
open
to
that
excellent.
So
I
will
take
an
item.
A
You
set
up
a
time
for
Q&A,
because
yeah
I
have
a
ton
of
it
sounds
like
lots
of
folks
have
lots
of
questions,
so
that's
awesome
and
yeah
I
will
I
will
set
that
up
and
glad
I
put
also
a
link
to
our
kubernetes,
the
kubernetes
sig
Docs
email
in
the
chat
or
resume
chat.
Sorry,
ok!
For
now,
however,
let's
move
on
and
let's
go
to
our
agenda
and
vlad
feel
free
to
stick
around
if
you
want,
but
otherwise.
Thank
you
very
much
for
joining
and.
F
G
So
we
had
this
huge
air
table
that
has
129
PRS
for
this
milestone
and
we've
done
a
pretty
good
job
of
parsing
through
most
of
them,
but
as
it
turned
as
it
got
closer
and
closer
to
Doc's
deadline,
which
is
today
turns
out
people
weren't
responding
as
quickly
as
I
had
anticipated
and
I'm
sure
all
of
the
previous
Meister's
are
laughing
because
they
knew
that
this
was
gonna
come,
but
anyway,
optimism
still
pays
off.
In
most
cases,
there
are
29
large
features
that
are
missing
documentation.
G
Even
placeholder
PRS
I
have
received
some
input
from
from
Tim
pepper.
We
have
managed
to
out
of
the
63
now
features
that
are
supposed
to
be
shipping.
42
of
them
need
updates
to
documentation
and,
and
out
of
these
29,
we
have
permission
to
hold
them
out
of
the
milestone.
If
they
opt
to
not
have
any.
Oh
I
should
send
this
feature
tracking
spreadsheet.
So
you
guys
can
see
what
I'm
talking
about
which
is
disappointing,
so
we
will
be
as
Zack
core
lessons
slack
statuses,
herding
cats
now
for
the
better
part
of
probably
the
next
week.
G
That
does
also
mean
that
PR
reviews
are
starting
today.
So
if
any
of
you
have
just
a
really
big
desire
to
review
poll
requests,
I
would
welcome
that
effort.
We
really
appreciate
it
Tim
and
Jim.
My
two
associates
have
been
doing
excellent
job
of
wrangling
and
and
getting
stuff
done,
and
them
have
been
extremely
helpful
in
this
effort.
So
I've
appreciated
what
they've
brought
to
the
table.
I
think
that
Tim
is
on,
but
my
guess
is
Jim
is
I,
don't
know,
he's
there
to
awesome,
so
thank
you.
G
G
Team
people
I
am
documenting
a
lot
of
the
code
that
I'm
doing
to
automate
my
job,
so
I
will
be
sharing
that
so
people
can
use
that
with
their
own
personal
tokens
so
that
you
can
appear
on
github
commenting
as
you
and
as
well
as
reaching
out
to
people
on
slack
as
you
to
people
personally,
which
I
have
seen
a
much
higher
engagement
rate
than
the
general
spam
of
when
I
send
a
somewhat
personal
message.
So
API
is
in
personalized,
toasts
and
so
API
is
and
personal
exit
access
tokens
for
the
win.
G
So
I
believe
one
of
Jim
or
Tim
or
maybe
I
had
that
wrong.
We're
taking
a
look
at
helping
to
fix
some
of
the
bugs
that
were
in
the
generated
reference
documentation
so
that
we
could
actually
use
it
as
the
commands
actually
specify
in
the
KK
repo
timber
Jim.
Correct
me.
If
I
had
that
super
wrong
and
did
not
agree,
I.
D
C
C
I
I
went
through
and
ran
the
Python
script,
and
so
at
the
output
was,
which
is
like
the
last
comment
on
there.
So
you
can
kind
of
see
what
actually
gets
generated
with
the
command-line
tools.
Cube
CTL,
set
of
tools
for
cube
ADM,
but
Jennifer's,
alluding
to
I'm,
not
sure
if
it
fixes
the
overall
problem
or
just
a
single
subset
of
some
of
the
issues
were
seeing
with
Doc's
generation.
C
H
So
I
I
spin
them
my
assignment
here
at
Google
has
changed
to
focusing
you
know
pretty
much
all
my
time
on.
Google
kubernetes
engine
instead
of
on
the
kubernetes
open
source
Docs,
so
I'll
be
I'll,
be
you
know,
working
less
on
the
kubernetes
Doc's,
but
I
think
one
thing
I
can
offer
to
do
is
is
if
anybody
needs
help
getting
you
know
with
ref
Doc's
generation.
You
can
bring
me
into
it
because
I've
done
it
several
times
in
the
past.
I.
G
Have
a
Google
document
that
has
a
lot
of
the
knowledge
that
you've
written
down
I
was
gonna,
go
start,
taking
a
look
at
it
now.
Well,
not
now,
but
in
a
week
or
so,
and
then
I
was
probably
going
to
bother
you
so
as
long
as
you're
still
willing
to
be
bothered,
I'd
be
happy
to
do
that,
but
I
may
have
to
confer
with
my
compatriots
first
to
make
sure
that
what
we
have
done
with
respect
to
the
other
fixing
of
generated
Docs
bugs
might
address
some
of
it.
Yeah.
H
H
So
I
I
sort
of
thought
of
myself
as
the
owner
of
that
for
a
while
and
I
did
work
on
it
for
a
while,
but
as
it
turns
out
I'm
not
going
to
have
time
to
really
sink
into
that.
But
it
looks
to
me
like
he
really
is
he's.
He
submits
full
requests
at
kubernetes,
incubator
reference
Docs
and
he
seems
to
be
taking
it.
As
a
you
know,
one
of
his
primary
projects
I
saw
that
I
see
him
as
a
key.
A
key
player
going
forward.
I.
G
D
A
H
H
A
G
C
Can
I
just
call
it
a
related
thing?
Cuz
I
did
a
relatively
poor
job
of
PR
wrangling
last
week,
but
what
I
did
do
was
to
make
sure
that
everything
against
master
belonged
against
master
I
did
have
to
request
that
a
couple
of
PRS
get
rebased
against
the
112
branch.
So
just
a
reminder
to
whoever
is
wrangling.
You
know
you
can't
trust
well
trusted
verified
on.
C
You
know
which
branch
the
the
PRS
are
coming
in
against
the
other
thing
that
I
did
was
I,
went
in
and
Mark
everything,
including
the
ones
I
requested
and
with
a
112
milestone,
because
it
helped
me
sort
so
that
I
could
focus
on
the
ones
against
master
insofar
as
I
found
them
last
week.
Sorry
about
that
I
will
try
to
help.
They
are
wrangling
generally
this
week,
and
especially
the
112
ones,
though,
to
make
up
for
my
last
week.
E
Back
knows
this
already,
but
the
it's
good
to
set
that
milestone
on
those,
but
there's
also
a
way
that
you
can
query
the
PRS
to
see
what
branch
they're
against,
and
that
is
really
a
nice
way
to
spot
ones
that
are
against
one
cup.
It's
a
little
more
reliable,
like
it
doesn't
fix
the
opposite
problem
where
people
basing
it's
the
wrong
thing,
but
it's
more
reliable
than
the
milestone,
because
not
everybody
knows
to
set
the
milestone
and
see
you
don't
get
the
syntax
see
exactly
right.
It
doesn't
work
right,
I
mean.
C
A
A
A
A
G
Right,
trying
to
think
of
I
actually
was
just
recently
sent
this
really
wonderful
presentation.
I
have
no
idea
if
this
was
a
more
elaborate
proposal
from
them
after
we
chatted.
G
But
basic
thought
was
right
now
we
struggle
with
the
fact
that
there
are
two
separate
repositories.
It
was
forked
from
K
website,
so
they
do
have
the
original
initial
get
directory,
meaning
their
histories
aren't
diverged
and
they
can
be
merged
into
one
another
in
a
very
interesting
fashion,
but
the
problem
in
having
to
long-running
branches
in
both
repositories
that
need
to
stay
synchronized
in
both
places,
without
adding
a
lot
of
kerfuffle
to
use
a
technical
term
when
it's
being
merged
back
into
the
base.
Master
branch
in
both
repositories.
G
So
this
was
this
is
kind
of
the
what
ended
up
being
the
proposal.
I
have
no
idea
if
juni
had
a
better
way
of
being
able
to
present
this,
but
but
basically
we
were
thinking
about
almost
a
scenario
that
kind
of
the
ke
ke
team
does.
So
when
it
comes
to
release
time,
a
branch
is
formally
made
from
from
master
and
then
as
pull
requests
are
approved
into
that
particular
reach.
They
are
cherry,
picked
out
of
the
master
branch
into
the
release,
branch
and
so
I
think
in
a
similar
fashion.
G
G
If
we
wanted
to
do
the
other
way,
sync,
but
basically
coming
up
with
similar,
tooling
of
being
able
to
just
take
commits
out
of
each
master
branch
as
they
get
merged,
so
that
these
branches
can
stay
in
sync
and
that
we're
not
having
like
a
huge
mess
when
we
have
to
rebase
everything
or
we're
trying
like
a
merge,
commit
strategy
or
some
other
different
and
possibly
dangerous
way
of
trying
to
merge
in
287
commits
before
we
want
to
add
one
commit.
And
then
we
have
a
merge
conflict
and
it's
a
mess.
So.
A
Before
we
dive
into
this
discussion,
I'm
going
to
note
that
we
have
looking
at
our
agenda,
we
also
have
a
proposal
from
Luke
to
talk
about
on
updating
or
an
update
on
the
tooling
and
infrastructure
working
group.
There's
a
proposal
document
there,
so
we've
got
about
a
half
hour
left,
take
care
Jennifer.
Thank
you.
We've
got
about
a
half
hour
left,
so
I
want
to
I
want
to
pull
folks
like
either
up
or
down.
Do
folks
want
to
get
more
into
the
particulars
of
this
branching,
this
branching
strategy
proposal
now.
E
G
Fluid
does
for
sure
already
so
as
soon
as
the
commit
is
merged
into
the
release,
112
branch,
the
localization
team-
needs
to
take
it
into
their
own
dev.
112
branch
translate
it
update
their
own
dev
112
branch
and
finally
issue
a
pull
request
against
our
master
branch.
When
112
was
ready
to
go
for
the
Korean
box,
okay,.
A
G
J
Wrong
ideas
loosely
held
it's
okay,
okay,
yeah,
so
y'all,
look
in
the
chat,
you'll
see
a
link
to
a
Google
Doc.
This
is
something
that
vibrated
on
by
myself:
I
entered
Chen
in
Raji
over
the
last
week,
or
so
so
I.
This
is
still,
you
know
very
much
a
work
in
progress
in
terms
of
how
this
group
is
going
to
work
but
yeah.
If
you
all
want
to
have
a
look
and
I've
opened
it
to
the
to
the
public,
so
anybody
can
make
comments
if
necessary.
J
Or
just
like
a
short
overview
would
be
helpful
sure.
So,
over
the
last
several
weeks
and
months,
the
content
this
meeting
has
tended
to
split
up
into
two
tracks.
So
on
the
one
hand,
we've
been
talking
a
lot
about
about
internationalization
about
how
we
can
get
help
and
volunteers
from
people
basic
content
strategy.
Things
like
that
and
I
think
to
me
and
to
ative
Lee.
J
So
so
that
was
the
basic
impetus
behind
this
proposal
and
if
you
look
there
I'm
proposing
a
handful
of
I,
guess
you
could
say
core
competencies
for
the
group,
so
the
static
state
generation
side
of
things,
the
net
worth
I
host
instead
of
things
continuous
integration,
side
performance,
not
an
optimization
and
an
SEO.
So
it's
kind
of
you
know
it's
not
about
everything.
That's
not
tech!
Writing,
but
it's
I
think
it's
pretty
close!
So
that's
my
basic
little,
my
little
spiel
there
in
terms
of
the
process
and
how
it's
all
going
to
work
pragmatically.
J
That's
that's
still
under
discussion,
I
would
say,
but
but
the
proposal
does
provide
at
least
a
kind
of
baseline
picture
of
how
that
might
look.
So.
J
Taken
from
here,
that's
a
good
question
so
down
at
the
bottom
of
that
doc.
There's
a
section
called
process
where
I
I
suggest
what
I
call
an
initial
baseline
of
what
those
next
steps
could
be.
So
a
slack
channel
potentially
setting
up
a
weekly,
a
weekly
update
here
in
the
sig
Docs
meetings
that
that
can
act
as
a
two-way
communication
channel
on
this
set
of
issues,
and
the
third
is
very
simple
that
we
could
potentially
have
a
separate
github
tag
that
people
can
can
add
to
issues
and
PR.
J
Yeah
so
last
week
I
mentioned
the
group
in
the
issue
and
actually
got
Rajee
as
a
as
a
volunteer.
So
it
looks
like
there's
there's
three
of
us
right
now
that
have
that
have
signed
on.
You
know
the
three
I
don't
know
raashi
well
personally,
but
I
know
that
the
Andrew
and
I
are
people
who
are
very,
who
are
very
keen
about
these
about
some
of
these
issues
that
are
that
are
maybe
a
little
bit
more
arcane
and
drys
are
the
people
I
personally
love.
J
G
A
A
A
E
Some
of
you
probably
know
this
already,
but
I
am
going
to
be
taking
on
the
role
of
tech
lead
for
gke
Docs,
which
is
also
going
to
be
limiting
the
amount
of
time
that
I'm
able
to
dedicate
to
the
open
source
side
of
things
right
now,
just
like
Steve
I'm,
not
going
away
I'll
still
be
doing.
Pr
wrangling
I'll
still
be
available
for
other
stuff,
I'll
be
in
the
slack
channel.
I'll
be
in
these
meetings,
maybe
not
everyone.
E
So
this
is
just
kind
of
an
expectation,
reset
I,
suppose
and
yeah.
That's
pretty
much.
It
I
I
hope
that
yeah
I
think
it's.
E
E
Definitely
yeah
that
office
hours
thing
is
still
open
like.
If
anybody
has
questions
about
get
it.
Let
me
know:
if
I
can't
help
you
synchronously,
then
we
can
set
up
a
time.
It
seems
to
be
that
one
on
one
works
better
than
kind
of
things,
because
almost
every
like
every
problem
is
sort
of
unique
in
its
own
way,
and
so
you
like
they're,
not
really
unique
to
me
but
they're,
unique
to
the
people
experiencing
them,
because
maybe
and
your
mental
map
of
git
is
just
not
fully
filled
out
in
that
area.
E
You
have
some
blurry
tiles
but
I
think
like.
Overall
we
will.
We
have
already
gotten
better,
as
a
group
and
I
think
we
will
continue
to
get
better
as
a
group
I'm.
Also
not
the
only
one
in
the
group
who
knows
a
lot
about
kids,
so
among
all
of
us,
I
think
we'll
be
able
to
muddle
through
awesome.
A
E
A
D
A
E
I
did
the
shareable
link
thing
I,
wonder
if
I'm
able
not
I'm
not
able
to
do
the
shareable
link
for
people
outside
of
Google
or
something
because
I
did
specifically
share
it
to
Zack?
Maybe
I
can
share
it
to
sig
Docs
the
email
list.
Let
me
see.
Sometimes
we
have
kind
of
funny
extra
rules
on
us
about
what
we're
allowed
to
share
we're.
E
Let
me
try
this
and
in
the
meantime,
I
can
kind
of
just
talk
about
it,
because
it's
not
anything
very
earth-shattering,
okay.
So
it's
kind
of
a
a
little
bit
of
a
throwback
to
what
we
as
a
cig,
we're
doing
before
I
did
111,
because
it's
effectively
a
merging
strategy.
I
have
shared
that
dock
with
the
group
now,
so
anybody
who's
on
that
email,
alias
may
be
able
to
get
access
to
it.
Hopefully,
maybe
so
the
object.
E
My
objectives
were
when
I
developed
this
and
I
developed
this
in
collaboration
with
Zack,
and
also
somebody
in
Google
called
gabe
weiss.
Who
is
like
a
branching
strategy
expert.
He
actually
used
to
work
at
perforce
before,
and
he
gave
me
a
lot
of
consultation
on
this.
So
we
wanted
to
make
it
easier
to
understand
for
contributors
to
understand
where
to
put
their
pull
requests.
We
wanted
to
allow
for
continuous
improvement
in
the
currently
published
docs,
which
means
putting
things
in
a
place
where
they're
gonna
get
published
right
away.
E
That
is
part
of
our
pattern
as
a
Doc's
team,
which
also
means
that
we
have
a
whole
lot
more
pull
requests
per
release,
then
something
like
KK
has,
because
we
do
a
whole
lot
of
different
sizes
of
fixes.
I
guess,
to
put
it
mildly,
and
we
also
want
to
have
the
ability
to
have
release
branches
where
we're
putting
release
specific
stuff
so
that
it
doesn't
accidentally
leak
out
into
the
publish
Docs
before
it's
actually
available,
and
we
want
to
have
the
ability
to
have
feature
branches
for
other
long-running
work.
E
Things
like
site
redesigns
and
some
of
the
CI
CD
work
that
Luke
and
Zack
have
been
talking
about.
So
the
those
things
should
probably
be
segregated
from
the
main
Doc's
until
they
are
ready
to
be
rolled
out.
So
those
are
our
strategies
right
now.
What
we
have
is
something
like,
broadly
applicable
fix's,
go
into
master
release
where
it
goes
into
a
branch
called
release,
112
or
whatever
the
release
is
at
that
time
and
those
get
reconciled
by
master
being
merged
into
the
release
branch
periodically.
E
We
also
can
do
the
same
thing
for
feature
branches,
but
I
feel
like
when
we've
used
feature
branches
in
the
past
we've,
actually
let
the
future
branches
get
fairly
out
of
date,
which
means
a
whole
lot
of
back-loaded
work
at
the
end,
reconciling
it
and
right
now.
We
also
have
this
weird
situation
with
archived
branches,
where
we're
reusing
the
pre-release
feature.
Branch
for
the
release.
E
Work
also
is
the
archived
branch,
which
means
that
there's
like
a
whole
cycle,
where,
technically
that
release
branch
should
be
matching
master
one-for-one
all
the
time,
but
we
never
actually
go
and
update
those
the
release
branches
so
even
like
during
the
time
that
111
is
current.
The
111
release
branch
is
stale
because
nobody's
going
and
maintaining
that
so
my
proposal
sort
of
addresses
some
of
those
things.
So
one
of
the
things
that
I
think
that
we
should
be
doing
is,
we
should
be
using
a
different
branch
name
for
pre-release
and
post
release.
E
So
I
think
that
I
mean
this
is
gonna
sound
silly,
because
it's
just
naming
but
I
think
that
when
we
have
a
release
branch
it
should
be
called
dev
whatever
and
then
that
development
branch
kind
of
becomes
dead
or
we
could
actually
delete
it
once
the
branch
is
released,
which
means
merging
that
branch
in
a
master.
So
once
that
branch
is
merged,
any
of
it
gets
deleted
or
it
just
like
stays
there
and
nobody
uses
it
anymore.
E
And
then,
at
the
time
that
a
new
release
is
gonna
happen,
then
there
needs
to
be
an
archived
release
cut
from
master
at
the
time
right
before
the
release
happens.
That
represents
like
the
final
state
of
that
release
before
we
start
referencing
a
new
one
in
master
so
like
before
one
thirteen
comes
out,
we
need
to
cut
a
branch
called
release
112
and
that's
the
archived
branch
for
112.
E
So
what
else
is
involved
here?
It's
basically
the
same
kind
of
maintenance
cycle
would
happen
for
feature
branches
where
master
got
merged
into
the
future
branch
on
a
regular
basis
to
keep
it
up
to
date.
So
then,
at
the
time
that
the
feature
needed
to
be
released
effectively,
the
only
difference
between
master
and
the
feature
branch
would
be
the
commits
relevant
to
the
feature.
So
I
won't
go
over
the
mechanics
of
this.
E
Now
it's
a
lot
like
what
you
guys
had
before,
except
that
there's
an
extra
branch
thrown
in
but
I
do
outline
and
mechanics
in
the
proposal.
Dock
and
I
also
talked
about
why
it's
better
than
what
we
have
now,
because
it
may
seem
kind
of
subtle
the
differences
to
what
we
have
now,
but
at
least
from
to
my
mind
and
as
somebody
who
fairly
recently
ran
a
release,
it
makes
more
sense
to
me.
G
The
only
question
I
had
was,
you
know,
I
I,
assumed
now,
with
with
Luke
and
and
what
we'll
be
doing
in
the
infrastructure
side.
I
didn't
really
see
a
lot
of
places
where
there
would
be
a
lone
running,
dev
branch
that
had
anything
other
than
release
related
stuff,
but
but
I
did
like
the
renaming
at
the
end
and
how
I
kind
of
just
let
it
go.
I
thought
that
was
that
was
really
good,
so
I.
G
E
Like
or
when
we
did,
the
big
site,
redesign
and
I
think
that
there's
another
site
redesign
coming
at
least
I've,
seen
some
reference
to
that
I'm
not
involved
in
that
at
all,
but
that
sort
of
thing
should
go
in
a
feature
branch
that
effectively
has
all
the
same
stuff
as
master.
If
nothing
else
just
for
smoke.
Testing
of
the
feature-
that's
my
opinion.
A
Just
looking
over
this
really
quickly,
I
think
me:
I
need
to
spend
more
time
with
this
proposal,
but
I
do
I.
Think
your
assessment
of
we're
using
like
release
branches
as
both
archival
and
occasionally
as
development
branches,
for
like
really
specific
updates.
That's
that
has
never
worked
especially
well.
It's
always
been
kind
of
there's
a
reason
why
we
have
our
designated
like
prior
release
branches
as
archival,
and
yet
that
doesn't
change
the
fact
that
occasionally
work
has
to
go
into
them.
So
I
think.
E
It's
a
little
bit
confusing
the
way
that
we
are
dual
purposing
them
and
I.
Think
that
just
such
a
subtle
thing
as
having
a
name
change
can
maybe
communicate
something,
maybe
not
maybe
I'm
wrong.
Like
people,
people
don't
really
read
like
we
have
the
pull
request,
template
and
human
nature,
there's
something
about
human
nature,
where
people
seem
to
not
think
that
the
instructions
are
for
them
or
they're
in
too
much
of
a
hurry.
I,
don't
know
what
the
motivations
are.
E
Cherry-Picking
would
also
work,
though,
like
just
a
sort
of
transition
to
his
ax
thing.
If
there
was
a
bot
that
was
automatically
cherry
picking,
there
would
be
some
cases
where
the
cherry
pick
would
fail,
and
somebody
you
have
to
manually
intervene
because
there's
a
especially
metadata
stuff
is
going
to
always
be
different
in
the
release
branches.
It's
going
to
be
a
head
I
like
the
variables
that
talk
about
what
release
this
is,
and
things
like
that
they're
going
to
be
ahead
of
master,
and
that
sometimes
makes
some
foraging
hard.
F
Well,
I
mean
in
general
anything
that
towards
more
automation
and
I.
Guess
you
know
that's
what
Zack
was
going
to
talk
about
automation
and
cherry-picking
that,
to
me,
I
know
it's
harder
and
more
work,
but
that
to
me
seems
like
we'll
have
less
headaches
in
the
future,
because
I
know
it
seems
simpler
to
you
but
just
hearing
how
it
was
described.
You
know
you
have
different
people
who
come
and
contribute
at
different
levels
of
understanding,
and
my
concern
would
be
that
there
are
certain
group
of
folks
that
this
approach
might
cause
more
havoc
for
I.
F
E
A
G
So
really
like
when
it
comes
to
it's
like
as
a
normal
process
merging,
it
makes
perfect
sense.
But
when
I
started
thinking
about
now,
we
have
two
repositories
and
technically
for
long-running
branches,
a
master
in
both
places
and
a
release
branch
in
both
places,
and
they
all
need
to
have
some
level
of
synchronization.
G
Unless
you
can
have
something,
that's
granular
enough
or
automatic
enough,
they
can
get
to
the
commit
level
and
make
these
decisions.
I.
Think
you
run
into
a
problem
where
you
stand
and
like
we
were
looking
at
like
what
it
would
take
to
quickly
fast
forward.
The
Korean
dev
112
branch
to
release
112
and
it
was
278
commits
and
I
stood
there
and
I
was
like
I.
G
My
thought
was
created
some
tooling
around
basically
hey.
If
there
is
a
branch
of
this
regular
expression,
Devlin
number
dot,
number
number
and
there's
another
branch
in
the
other
repository,
that's
of
the
same
exhibit
that
matches
that
then
perform
a
two
way
sync,
and
that
is
because,
like
what,
if
it
was
just
copying,
the
K
website
stuff
into
the
Korean
localization
would
be
fine,
but
it
isn't
right.
G
E
G
E
G
C
A
I
have
to
confess
I
fell
asleep
last
night.
Thinking
about
this
and
like
thinking
about
the
the
the
merge
tree
structure
and
thinking
about
how
how
much
possibly
how
many
possibilities
for
conflict
there
would
be
between
syncing
English
content,
going
one
way
from
K
website
into
a
star
knocks
star
and
how.
D
A
E
A
What
Bjorn
is
working
on
right
now?
So
that's
just
context
for
contextual
awareness,
that's
the
the
long-running
feature
branch!
That's
that
your
impaired
person
is
working
on
right
now
that
may
go
in
at
any,
depending
where
he
drops
it.
They
go
in
and
either
what
not
twelve
or
1.13
but
yeah
working
on
how
to
separate
that
out
cleanly
and
make
it
possible
for
localization
teams
to
have
localization
specific
layouts.
His
his
part
is
Paul's
in
the
scope
of
the
work
that
he's
doing
with
I'm
sorry
exact.
G
G
The
configuration
the
nonsense
that
not
nonsense,
but
you
know
this
stuff
that
we
need
to
be
able
to
generate
the
full
website
and
then
that
itself
could
be
technically
a
parent
and
get
to
get
repository
for
three
sub
modules:
the
Chinese
documentation,
the
en
documentation,
the
Korean
documentation,
and
then
you
kind
of
effectively
split
out.
What
is
the
content
versus
what
is
the
stuff
required
to
generate
the
website?
G
It
does
make
it
complicated
from
a
perspective
of
contributing
only
kind
of,
though,
because
you've
effectively
separated
that
which
is
marked
down
from
that
which
is
in
your
docker
and
build
tooling,
and
all
of
that
good
stuff.
And
then
those
histories
can
be
as
separate
as
they
want,
and
then
we
can
pull
in
at
a
particular
release,
exactly
which
gets
sha
from
this
particular
repository.
We
want
as
the
stamped
this
is
now
the
new
master
of
the
parent
repository
build.
It
and
that's
not
kubernetes
at
I/o
I.
A
A
Directory
for
so
there
are
some
problems
with
that,
namely
so
what
you
would
be
talking
about
would
be
taking
like
from
the
top
level
content,
/
content
/ko,
for
example.
Having
that
be
a
separate
repo,
but
Hugo
requires
like
slash
static
you
in
order
for
like
Hugo
server,
to
run
in
the
local
environment.
It
requires
the
whole
case
right
right.
G
So
that's
why
I
was
talking
about
it
as
a
sub
module,
so
get
sub
modules
are
interesting,
but
you
can
just
you
can.
Essentially
you
can
copy
down
the
que
website
repo
and
then,
if
you
change
directory
into
a
subdirectory
of
que
website,
namely
content,
KO
you're
technically
in
another
get
directory
which
can
have
a
separate
remote.
So
you
can
update
all
day
long
from
that
remote
without
affecting
the
base
history
of
que
website
at
all,
and
they
can
be
in
separate
origins.
G
They
can
be
in
different
places
and
then
you
can
have
separate
histories
and
different
configuration
and
whatnot,
and
then
you
know
basically
all
config
lives
in
the
que
website.
Repo
and
static
generate
assets,
CSS
all
that
good
stuff
within
all
language.
Specific
implementation,
details
in
terms
of
markdown
files
and
content
live
in
the
individual,
get
directories
of
the
languages
themselves,
actually,
the
more
like
it
can.
G
A
A
Mm
yeah,
just
something
that
is,
that
is
opaque
to
that
branch
rather
than
art,
yeah.
Okay
to
that
branch,
rather
than
it
blind
to
it
that
didn't
make
any
sense,
I
English
for
a
living,
something
that
acknowledges
the
feature
branch
that
neuron
is
doing
rather
than
pretends
it
doesn't
exist.
Okay,
yeah.
G
I
have
not
seen
that
so
I'll
have
to
go
check
that
out.
Well,
then,
that
my
two
best
proposals
are
that
which
I
just
came
up
with
right
now
and
cherry
picking,
which
is
just
picking
the
individual
commits,
which
shouldn't
be
a
problem
because
they
aren't
in
affective
directories
but
anytime.
There's
a
config
change
in
like
a
network
like
Tamil
I,
understand
time's
running
out
so
cut
me
off,
but
that
will.
A
A
A
H
Back
to
here,
because
already
it's
gone
to
a
point
where
I
don't
feel
like
I
can
contribute
to
the
discussion,
because
it's
gone
to
a
point
that
is
past.
My
understanding
and
I'd
have
to
do
some
heavy
studying
to
even
participate,
so
I
kind
of
feel
like
it
should
go
to
a
smaller
group
and
then
and
then
that
group
could
report
back
to
us.
I
wonder.