►
From YouTube: Kubernetes Sig Docs 20180605
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 05 June 2018.
https://github.com/kubernetes/website
A
B
A
C
D
A
D
A
Talk
about
the
PR
regular
queue,
I
did
it
last
week,
but
we
need
someone
to
wrangle
PRS
this
week
and
next
week
the
I
will
adjust
the
level
expectations.
Every
PR,
that's
in
the
queue
right
now
seems
like
it's
kind
of
a
monster.
There
are
a
lot
of
PRS
in
flight
and
the
ones
that
have
not
yet
been
triaged
every.
There
seem
to
be
very
few
simple
ones,
so
it
heads
up
that
this
is
kind
of
a
it's
a
little
more
intensive
role.
A
E
E
A
Agreed
I
I'm
going
to
keep
going
this
week
as
well,
just
because
the
the
queue
is
so
large
I
feel
like
if
without
multiple
people
on
it
this
week,
it
might
get
a
little
it
might
get
out
of
control.
So
I'm
gonna
stay
on
on
PR
wrangling
this
weekend,
misty
we
can
work
together
on
I'm,
getting
those
giving
those
regular
and.
C
C
Heads
up
there
there
will
be
a
clutch
of
cube,
ATM
related
new
P
of
ours,
as
of
tomorrow
afternoon,
Thursday
Friday
I
will
be
separating
those
through,
though
so
just
so,
you
know
there
might
be
a
bit
of
a
burgeoning
in
the
queue,
but
that
is
that's
a
known
issue
already
and
accounted
for
and
that
stuff
people
want
to
get
in
for
111,
so
it
needs
to
get
I'll
be
moving
on
it.
Pronto,
okay,.
A
So,
let's
talk
about,
let's
talk
about
approvers
for
individual
files,
so
this
is
an
issue
that
came
up
over
the
past
week,
whereas
a
cluster
lifecycle,
I
think
looked
at,
they
looked
at
frontmatter
for
an
individual
set
of
files,
that's
kind
of
unique
and
they
added
themselves
what
they
added
themselves
to
a
list.
There's
a
in
the
top
level
of
K
website.
A
But
what
I
think
happened
is
that
if
you
look
back
in
the
history
of
the
repo
approvers
was
not
always
a
magic
word
and
it
was
in
the
front
matter
for
several
files.
If
you
look
through
like
Chinese
content,
which
is
a
couple
of
it's
a
couple
of
releases
early
to
where
we
are
right
now,
you
can
see
files
with
approvers
in
the
front
matter.
It's
a
pre
hugo
files
all
over
the
place,
so
I
don't
think
thats
a
cluster
lifecycle
is
trying
to
stage
a
coup
against
the
sig
docs
review
process.
A
I
think
that
they
were
acting
with
the
best
of
intention
and
just
did
not
connect
that
approver
is
a
magic
word
that
grants
them
special
powers.
So
I
guess
I
want
to
be
really
clear
that
I
think
I
think
we're
all
good
here.
I
think
that
we
can
give
feedback
about
this
particular
PR
8506
and
say
thank
you
for
updating
your
info,
but
please
don't
bypass
the
sig
docs
review
process
and
I
think
they're
totally
open
to
hearing
that.
A
But
I
also
want
to
be
clear
that
there
is
no
bypassing
the
signals
review
process
except
for
very
specific
cases.
Those
are
case
studies
and
the
blog,
and
there
are
individual
owners
files
for
those
particular
areas
that
the
owners
are
well
aware
of.
So
I
think
the
the
that's
the
context.
The
short
takeaway
is,
please
don't
add
individual
file
owners
or
file
level,
individual
owners
to
files
in
a
inque
website.
Does
anyone
have
any
questions
about
that?
Any
concerns
Steve.
A
So
I'm
not
easy.
We're
muted.
F
So
it
the
owners
file
is
not
the
problem.
The
problem
is
the
approvers
designation
and
in
that
same
file
or
in
the
front
matter,
it's
fine
to
list
people
as
reviewers.
So
that's
the
message
I
think
we
should
should
send
them
in
that.
Pr
is
just
change.
What
you've
done
here
to
reviewers
that'll
help
us
get
a
the
a
good
choice
of
tech,
reviewer
and
a
good
recommendation
for
a
tech,
reviewer
or
additional
doc
reviewer,
but
it
won't
grant
that
power
that
an
approver
has
sure.
A
E
Have
any
concerns,
but
I
just
have
as
a
comment
that
this
should
go
in
the
contributor
Docs
I'm
working
on.
So
it's
just
a
reminder
to
me
that,
like
these
stuff,
these
things
should
be
defined
clearly
as
to
what
they
need.
It
seems
to
me
that
it
would
be
amazing
if
these
weren't
very
individual
files,
as
soon
as
maybe
kind
of
maintain
that
I
guess
third
search
in
our
place.
A
Sure-
and
there
are
ways
to
make
it
more
visible
than
a
top-level-
maybe
like
you
notice,
Sebelius's,
because
it's
possible
to
add
reviewers
there.
So,
let's,
let's
explore
best
practices
around
maximizing
visibility
for
reviewers
but
agreed.
Let's
make
sure
that
this
gets
into
the
contributors
guide
and.
G
A
D
A
H
So
hi
this
is
my
friend
adjust
real
quick
on
that.
Could
it
get
documented
because
there's
more
people
than
just
Ian
who
want
to
do
this
and
there's
already
a
first
pull
request
on
adding
Korean
translations
and
it
is
blocked
right
now
on
documentation
of
how
do
we
handle
internationalization?
And
so,
if
there
were
some
clear
guidelines
that
would
probably
help
yeah.
A
A
C
You're
good
to
go
with
it.
That
would
be
great
I
chatted
with
two
men
last
night,
yam
I'm,
sorry
I
probably
should
have
put
that
in
a
public
channel,
but
I
can
I
can
copy
it
to
you,
I'm.
Basically,
everything
to
generate
full
of
the
generated
bits
and
pieces
now
lives
in
kubernetes
incubator
reference
Docs
great.
We
don't
need
we
don't.
We
aren't
dependent
on
hack,
generate
Doc's
script
anymore
at
all
for.
C
Take
a
look,
take
a
look
at
the
work
that
human
checked
in
with
that
one
PR
that
looked
enormous
I
mean
we
don't
have
to.
We
can
and
continue
to
generate
the
cube
kettle
and
API
refs.
You
know
using
the
stuff
that
calls
on
the
Hat
generate
diamonds,
but
I
think
that
what
you
men
have
put
together
is
considerably
more
elegant
and
easier
to
use.
That
said,
it's
not
documented
and
the
makefile
isn't
updated
to
include
all
the
docs.
There
are
some
other
problems
with
it
too.
I
don't
have
to
take
up
this
meeting.
B
C
If
at
that
time,
I
mean
afternoon
and
I
can
I
can
fill
you
in
on
what
she
meant
told
me,
but
he
said
that
he
would
update
the
I
told
her
I,
don't
know
whether
he
was
planning
to
put
it
in
the
web
site
repo
were
in
the
readme
for
the
reference
Docs
and
kubernetes
incubator,
but
he
said
he
would
get
the
whole
thing
documented
this
week
from
what
I
can
tell
there's,
not
anything
that
that
is.
That
is
Hugo
dependence,
but
I'm
not
sure
about
that.
C
C
Yes,
but
what
he
digs
for
right
now,
if
you
take
a
look
at
the
code
that
he
wrote,
it's
all
written
and
go
now,
there's
no
more
shell
scripts
and
it's
one
file.
It's
it's
one
file
to
call
to
generate
all
of
basically
everything
I
said.
Look
you
know,
especially
for
cube
ATM.
We
need
to
be
able
to
generate
those
separately
and
that's
a
separate
item
in
the
agenda.
So
I
won't
go
there
yet,
but
I
did
call
that
to
his
attention.
That
said,
you
know
I
mean
if
I
can
figure
out
how
to
adjust.
C
C
F
And
I
think
we
still
ought
to
have
separate
topics
for
how
to
how
to
generate
the
the
cube
kubernetes
commands
how
to
generate
the
Federation
ref
Docs.
How
to
generate
that
cube
control
commands
on
how
to
generate
the
kubernetes
api
ref
doccy,
even
if
it's
all
done
by
a
more
unified
toolset
I,
think
someone
might
want
to
know
how
do
I
do
this?
One
thing
right.
A
C
F
C
Should
definitely
from
what,
by
the
twelfth
I
I,
let
you
may
know
it's
merely
urgent,
because
next
Monday,
that
we
are
the
Ducks
pr's
day
to
have
this
stuff
solid
by
then
okay,.
A
F
C
No
and
no
I'm
not
doing
that
either
and
that's
something
I
still
need
clarification
on
here,
because
the
we
actually
need
to
update
that
script
in
the
repository
right
to
copy
from
different
locations
or
a
copy
different
sets
of
files.
I'm
not
completely
clear
on
this,
because
I
haven't
had
time
to
look
at
it.
E
C
I
C
A
A
Okay-
let's
see
but
just
to
note
that
we
still
have
I,
think
a
large
number
of
broken
links
and
I
to
be
honest,
I
have
been
so
I've
been
chiseling
away
at
the
PRQ,
but
I.
There
could
very
well
be
fixes
to
a
lot
of
broken
links
that
I
just
have
not
seen
yet
so
with
just
mark
that
this
is
still
outstanding
work
and.
A
A
K
I
I
A
K
K
L
So
so
does
anybody
remember
coop
con
Austin
where,
as
part
of
the
registration
process-
and
you
had
the
list
of
options
we
were,
you
know
the
the
docs
print
was
listed
as
a
free
option
and
I
think
that
got
us
some
people
and
then
I
think
we
dropped
that
somehow,
as
we
got
more
into
the
contributor
stuff
that
that
nice
part
of
that
registration
flow
for
the
whole
big
conference,
that
was
really
cool.
Oh
hey,
there's
a
dog
spray
and
a
description.
A
A
That's
all
good!
So
I
have
an
item
to
follow
up
on
from
last
week
about
whether
or
not
we
need
to
do
another
post,
Hugo
bug
bash,
so
Andrew
and
I.
We
haven't
had
a
chance
to
talk
about
how
to
flag
issues
for
Buuren,
Eric,
Patterson
or
Steve
Francia
and
separate
out
Hugo
related
issues
into
nice,
buckets
that
would
play
well
with
another
sprint,
but
we
have
a
meeting
scheduled
to
do
that.
So
Andrew
and
I
are
gonna.
A
Take
time,
I
think
when,
when
did
we
schedule
that,
like
anyway,
it's
on
my
calendar,
which
is
why
I
don't
know
what,
in
my
head,
Andrew
and
I
are
going
to
go
through
and
take
a
look
at
the
post,
Hugo
issues
that
are
remaining
and
my
suspicion
is
that,
yes,
we
will
have
enough
material
to
do
another,
solid
post.
You
go
bash,
so
Andrew
and
I
will
come
back
with
specifics
next
week.
A
I
C
C
Up
until
well,
up
until
when
eleven
and
generating
docks
for
the
dock
site
has
been
a
one-time
thing
toward
the
end
of
the
release
cycle,
it
turns
out
that
when
there
are
new,
but
the
cube,
ATM
docks
are
built
a
little
bit
differently
from
all
the
other
docks
they
include.
The
manually
created
files
contain
include
statements
that
pull
in
content
from
generated
box.
C
This
means
that
if
there's
a
new
command
with
a
new
generated
dock
and
a
new
include
statement,
we
need
to
include
at
least
a
placeholder
and
I
would
argue,
ideally
the
actual
generated
file
itself
or
the
docks
build
breaks
yeah.
We
found
this
out
the
hard
way
right
now,
because
the
process
of
generating
the
cue
medium
docks
is
still
a
bit
mysterious
to
pretty
much
everybody
except
the
person
who
originally
developed
it.
I
E
J
F
C
It
came
up
in
this
context,
though,
because
you
know
this
is
a
typical
in
that
we
might
wind
up
with
poll
requests
earlier
in
the
release
cycle
as
part
of
something
that
should
have
changed
files,
and
it's
also
great
things
that
we
can
reasonably
sort
of
edit
and
expect
people
to
add
commits
to.
So
that's
what
makes
it
a
little
bit
different,
but,
yes,
the
check
should
definitely
be
for
any
of
them.
C
C
I
I
C
E
I
think
that's
probably
referring
to
the
idea
that
I
had
to
do.
I
get
office
hours
and
I
didn't
really
anticipate
doing
a
class,
but
I'm
happy
to
do
that.
Probably
after
111
I
think
all
the
cute
stuff
that
I
thought
that
might
be
cool
to
do
sort
of
got
preempted
by
111,
so
I
mean
I.
The
thing
in
that
office
hours
has.
E
L
E
It
makes
it
it
makes
sense
to
me
I,
just
I
feel
like
for
that
kind
of
thing.
There
are
a
ton
of
resources
out
there
and
there
are
professional
get
classes
that
you
can
take
and
I
won't
be
able
to
capture
those
things.
My
experience
with
coming
from
zero
to
being
pretty
much
an
expert
on
get
now
is
that
I
had
to
learn
it
in
bytes
and
I
had
to
adjust
my
mental
map.
E
I
went
along
everything
started
out
being
magical
commands
for
me,
just
like
it
does
for
everybody
else,
and
it
took
me
time
and
effort
and
solving
specific
tasks
to
get
the
mental
map
right
and
I
think
that's
the
way
that
most
people
learn.
So
if
you
want
to
take
a
get
class
or
you
want
to
read
a
book
or
github
has
actually
pretty
good
documentation
themselves.
E
I
Yeah
I,
don't
think
this
is
a
high
priority.
I
think
you'd
be
useful
to
have
at
least
they
go
one
pager
or
like
a
maybe
a
short
max
twenty
minute,
video
of
of
like
you're,
a
new
contributor.
How
do
you
use
git
without
destroying
everybody
else's
work?
I,
think
that
would
be
really
useful
just
to
for
do
contributors
to
know
what
they're
doing
it
not
be
dangerous.
So.
E
I
I
C
L
I
went
and
learned
it,
but
but
you
know
understanding
how
Bjorn
designed
it
I
thought
would
really
help
everybody,
because
we
feel
like
he
went
off
and
did
this
and
then
it's
kind
of
gotten
thrown
over
the
wall.
And
now
we
got
to
figure
it
out
and
some
things
are
easy.
We
figure
it
out
and
you
know
misty
figured
some
stuff
out,
but
but
some
things
that
it
might
be
good
to
have
them
kind
of
just
go
through
like
that:
hey
here's!
What
I
did
and
here's
how
this
is
all
structured
kind
of
thing.
I
H
I
L
B
I
B
I
I
I
L
D
I
F
D
So
damn
yeah
so
initially
of
one
guy
or
make
a
precast,
so
it
there
are
other
translators
in
Korean
team
so
that
we
had
pure
reviews
and
then
now
you
know.
We
all
think
that
is
a
previous
Ocana.
Translation
is
fine,
but
I
would
like
to
because
some
videos,
for
example,
some
general
structure
or
some.
What
or
should
we
do
should
Korean
team
or
do
okay.
B
K
The
I
mean,
like
an
example,
is
we
have
a
PR
that
adds
one
field
to
an
API
right?
That
requires
a
Docs
change
somewhere,
but
without
somebody
tracking
it
it
may
not
get
it
yeah
and
there
isn't
really
a
process
for
that.
The,
and
so
you
know
as
far
as
111
you
know,
is
concerned.
That
means
that
we
have
to
do
this
huge
retro
effort
looking
over.
K
Basically,
every
PR
that
went
into
111
trying
to
figure
out
whether
that
needed,
Docs
and
if
it
needed
Docs
whether
or
not
it
got
them
the
which
is
obviously
going
to
be
very
lossy
process.
The
I've
already
asked
misty
and
Zac
etc
to
do
what
they
can
on
that.
But
one
of
the
things
to
think
about
for
112
in
the
future
is:
is
there
a
better
way
to
do
this?
I.
K
K
And-
and
there
is
some
correlation
of
if
something
needs-
a
release-
note
that
there's
some
correlation-
that
mostly
things
that
need
Doc's
are
also
going
to
need,
release
notes,
and
so
we
can
filter
out
the
PRS
that
went
in
based
on
based
on
whether
or
not
they
got
a
release.
Note,
but
again,
there's
no
way
to
connect
that
to
the
websites
they
are
except
manually.
No.
E
We
already
the
kubernetes
features.
Er's
already
seem
to
have
a
format
about
them,
so
we
could
require
that
if
it
needs
Docs,
then
the
feature
owner
has
to
have
a
link
to
a
Doc's
PR
at
some
point
in
the
future,
like
they
add
it
to
the
first
field.
After
when
they
raise
the
PR,
which
would
then
connect
the
two,
the
two
PRS
or
the
issue
or
whatever
in
github
zwey
like.
If
you
link
to
an
external
issue
or
PR,
then
it
pings
both
you.
E
E
K
K
Would
be
enforceable
because
you
could
require
somebody
to
have
at
least
the
link
in
the
in
the
PR,
which
would
at
least
even
even
if
we
had
to
track
it
manually.
The
information
would
be
easier
to
find
yeah
the,
but
that's
certainly
not
happening
for
111
and
I'm
fairly
dubious
about
getting
people
to
accept
that
across
the
project.
Overall,
because
that
that
sort
of
behavior
pattern
is
already
set,
the
so
I
guess.
The
second
way
would
be.
K
Yeah
I
don't
know
a
lot
of
this
ends
up
tying
in
to
us
having
really
poor
instrumentation
on
PRS
in
general,
which
is
due
to
github
limitations,
the,
which
is
why
I'm
looking
for
creative
ideas
here,
because
the
obvious
ideas,
which
is
we
ought
to
have
some
system
that
tracks
each
PR
that
goes
in,
allows
us
to
flag
whether
or
not
that
thing
needs
Docs.
You
know
allows
us
to
then
request
Docs
from
the
PR
author
in
some
automated
Fortune
fashion
and
track.
E
People
are
not
currently
using,
it
seems
like
there
are
other
parts
of
that
people
are
using
very
consistently,
so
it
would
be
interesting
to
understand
what
would
be
the
hook
to
make
people
use
something
consistently
like,
even
if
we
expand
it
out,
it
needs
Docs.
Right
now
means
major
release
notes,
it
should
probably
be
called
needs,
release,
notes,
and
there
should
be
something
else.
That's
like
needs,
API
update
or
like
needs,
formal
documentation
or
something
like.
Maybe
it's
not
granular
enough.
K
Yeah
well,
the
other
problem
is
that
it
kind
of
needs
to
be
interactive
right
because
we
need
a
way.
Well,
you
would
I,
guess
would
be
a
lot
like
it.
Mate
might
work
a
lot
like
the
release
notes.
You
know,
which
is
we
have
the
needs.
Release
notes
doesn't
need
release
notes,
but
with
the
understanding
that
there's
already
some
problems
with
the
release
notes
mechanism
in
that
yeah
could.
J
We
potentially
piggyback
off
of
the
owners
file
possesses
not
every
change
that
VR
is
going
to
require
documentation.
Let's
say
certain
packages
are
are
sensitive
enough,
like
API
changes
or
particular
areas
of
the
code
base.
That
would
require
a
documentation
update
if
they
had
it
to
be
used
a
similar
mechanism
that
the
owners
file
does.
That
would
require
an
approval
from
an
owner
for
a
code
change.
The
same
thing
has
to
happen
for
a
Docs
like
when
a
change
is
requested
on
this
particular
thing.
It
needs
Docs.
Otherwise,
it's
fine.
E
E
J
Iii
may
have
been
not
very
clear,
I
suppose
what
I
meant
was
like
if
a
change
goes
into
the
code
base
in
a
particular
package
that
will
end
up
affecting
let's
say,
a
coop
control
command.
As
far
as
the
number
of
flags
you
can
pass
or
what
the
flag
order
are
not
ordered,
but
what
the
flag
parameters
are
that
can
be
passed
to
it
in
that
particular
case.
J
That
would
definitely
trigger
a
docks
update
and
so
inside
of
the
coop
cuttle
subfolder
inside
of
the
repo
and
inside
of
a
specific
package,
there
could
be
a
a
flag
either
inside
the
owners
file
or
a
separate
file.
That's
just
all
cat
stocks
and
basically
prowl
or
whatever
the
amazing
new
tool
is
that
we
have
at
does
PR
management
inside
of
github
we'll
have
a
label
that's
set.
J
E
An
interesting
idea,
I
am
probably
need
to
know
how
it
would
work,
but
I
will
say
that
when
I
worked
with
other
pieces
of
software,
where
api's
were
generated
from
code
quite
often,
even
though
that
is
technically
a
documentation
most
the
time,
the
docs
team
was
not
involved
in
any
way
shape
or
form
with
like
reviewing
the
PR
or
even
known
that
the
PR
existed
to
update
the
API.
So
like
that's
sort
of
a
different
kind
of
Docs
to
me
than
the
kind
of
ducks
that
were
actually
responsible
for,
but
Josh
needs
to
track.
E
C
I
suspect
that
Steve
can
speak
better
to
this
than
I
can
and
I
might
be
falling
down
the
rabbit
of
your
examples
Zack,
but
both
of
them
are
in
fact
covered
by
the
generated
Docs.
You
cuddle
anything
that
gets
added
to
queue
cuddle.
That
stuff
is
automatically
generated
and
shows
up
in
the
admittedly
unlovely
reference
Docs
for
cube,
cuddle
ditto,
the
API
reference
box.
C
Now,
that's
not
always
sufficient,
but
at
the
level
of
granularity
that
we
seem
to
be
talking
about-
and
this
is
true
for
a
whole
lot
of
other
bits
and
pieces
of
kubernetes
as
well.
Great
generate
docks
for
you've.
Already
heard
me
talk
too
much
about
cube
ATM.
We
generate
docks
for
cube,
API
server
for
a
whole
bunch
of
other
command-line
tools
and
all
of
the
content
for
those
docks
lives
in
the
kubernetes
kubernetes
repository.
C
And
yes,
it
would
be
lovely
if
we
could
generate
those
ducts
on
the
early
side
and
review
in
felicitous
strings
and
actually
get
full
requests
in
kk
merged
so
that
we
can
fix
the
strings.
We
have
that
workflow
as
an
option,
but
it's
a
crapshoot
whether
those
PRS
actually
get
any
attention.
So
I
I
guess
I
need
to
hear
a
use
case.
That's
not
about
generated
ref
ducts
for
all
of
these
different
bits
and
pieces.
I
believe
that
such
cases
exist,
but
ie
yeah
I'll,
stop
there
I'm.
J
Glad
you
asked
so
josh
has
done
a
wonderful
thing
for
us
and
has
actually
gone
through
and
looked
at.
Pr
is
on
KK
I
just
popped,
one
of
them
into
the
chat
window,
and-
and
this
is
an
example
of
a
pull
request
that
that
would
have
what
that
trips,
the
the
internal
burkas
alarm
that
says
this
should
have
some
documentation
around
it.
J
Right
so,
and
definitely
thank
you
for
all
that
hard
work
that
you've
been
doing
so
I
suppose
Jennifer
to
kind
of
address
your
your
your
specificity,
concern
I,
don't
actually
know
anything
about
this
feature.
I'm
sure
I
could
probably
go
really
really
quickly,
but
the
suggestion
that
I
was
making
is,
for
example,
a
lot
of
this
changed
inside
of
the
the
code
that
was
changed
in
this
was
in
various
packages
across
the
entire
repo.
J
It
could
be
the
case
that
that
a
owners
file
would
either
include
an
entry
for
if
something
changes
inside
of
this
whole
package
and
any
related
sub
back
edges,
it
will
need
documentation,
in
which
case
that
constraint
could
be
satisfied
by
simply
pasting
in
a
link
as
a
comment
in
the
PR.
That
is
a
link
to
kubernetes
website
or
whatever
other
documentation
system.
We
have
at
the
time
for
a
PR
that
also
updates
some
other
mechanism.
J
I
J
J
So
I
am
a
software
engineer
for
my
company.
I
did
not
get
paid
to
do
kubernetes,
though
that
would
be
incredible.
So
most
of
my
contributions
that
don't
involve
meetings
during
the
day
have
to
come
on
weekends
or
at
night
and
generally
I'm
too
tired
at
night,
so
I
was
and
I
was
thinking.
I
was
like
well,
it's
actually
was
a
lot
of
fun,
the
docs
print
that
we
did
at
coop,
conch
opening
and
I
thought.
J
That
was
a
blast,
so
I
thought
in
order
to
sort
of
increase
our
throughput
or
just
I,
don't
know,
have
a
good
times
a
cig.
It
could
be
fun
and
I'd
be
willing
to
host
the
first
few
to
have
sort
of
like
a
distributed,
Doc's
print,
where
we
have
like
a
two
hour
stretch
or
a
three
hour
stretch
on
a
weekend
day,
not
super
often
but
as
I
totally
volunteer
and
obviously
stagger
and
vary
the
time
so
that
we
can
engage
different
time
zones
in
the
effort.
J
But
then
we
could
kind
of
all
collaborate
get
on
the
same
page
if
whoever's
actually
there
at
the
sprint
and
and
move
significant
pieces
of
que
website.
Repo
forward
that
we've
been
languishing
on
or
actually
do
those
things
were
like
well,
these
would
be
nice
to
have
project.
So
that
would
be
a
perfect
time
to
engage
in
something
like
that.
So
it
was
a
suggestion.
I
know,
I
super
enjoy
working
in
a
group
of
people.
I
was
awesome
to
me
Jared
and
the
gang
in
Copenhagen.
J
L
Zack,
maybe
like
a
smaller
version
of
that,
but
I
know
like
I
did
for
just
out
of
the
blue
for
Steve
Perry
one
weekend
when
he
had
like
a
plethora
of
PRS
fixing
all
kinds
of
dock
links.
Yes,
a
plethora,
I
think
that's
the
right
word
you
know.
Maybe
having
you
know
somebody
on
call
to
do
reviews.
So,
like
you
know,
I
was
able
to
speed
a
lot
of
things
up
because
I
spent
a
Saturday
night
doing
a
whole
bunch
of
reviews
for
them.
L
So
I
don't
know
if
there's
a
model
like
that,
where
you're
like
hey,
could
anybody
I
got
a
whole
bunch
of
stuff?
I
got
to
get
done
and
you
know
is
there
anybody
who
could
spend
some
time
say
Saturday
night
being
the
on-call
review
person
I
know
I
was
I,
don't
know
if
you
remember
that
Steve,
but
that
kind
of
worked
really
well.
It's
not.
There
wasn't
anything
we
planned
I
just
knew
we
had
a
ton
of
stuff
to
review
and
I
felt
really
guilty.
L
So
I
was
I
was
sitting
in
front
of
that
computer
on
a
Saturday
night.
Okay,
no
comments
about
my
social
life.
I
thought
I,
don't
know
it
worked
really
well.
I
know
that's
kind
of
like
a
smaller
version
of
what
you're
saying,
but
maybe
that's
the
vice
is,
if
you
can't
motivate
the
troops
here
to
spend
their
Saturday
evenings
with
you,
Zack.
F
So
I
thank
you
for
that
that
it
did
work
really
well
and
thank
you
in
general,
like
I,
don't
want
to
condone
working
on
weekends
and
I'm,
trying
to
train
myself
to
not
so
I,
don't
have
a
strong
feeling,
one
way
or
the
other
on
this
question
of
you
know:
creating
opportunities
for
people
to
work
on
weekends,
I!
Think
it's
it's
a
fine
idea
for
those
who
who
would
like
to
do
it
I
think
that'd
be
fine.
I.
I
Think,
from
the
from
from
my
managerial
standpoint,
I
think,
if
there's
a
your
project
to
do
something
all
the
weekend
but
spreads
and
folks
from
from
Google
want
to
participate.
Then
awesome,
let
me
know
so
that
we
can
sort
of
like
figure
out
how
to
credit
you
that
time
back,
because
I
actually
really
committed
to
people
not
overextending
themselves
and
actually
have
a
good
work-life
hours.
So,
and
we
do
get
paid
to
work
on
Cooper
how
big
things
a
little
different,
so
I
support
it,
but
there's
some
boundary
conditions
I
have
around
it
totally
I.
J
You
know
I,
don't
think
I'm
gonna
get
much
moving
here
soon,
it
probably
month
or
two
before
we
get
that,
and
it
may
even
be
after
right
about
Cincinnati,
but
just
wanted
to
kick
the
ball
around
see
if
see.
If
anyone
wanted
to
pass
it
back,
because
I
think
it
would
be
a
perfect
way
to
gain
a
little
bit
of
visibility
as
a
sake.
Obviously,
talks
are
some
of
the
most
important
things
to
raise.
J
I
can't
tell
you
how
many
nightmare
scenarios
I've
managed
to
get
out
of
in
our
company
in
production
because
of
kubernetes
io.
So
it's
been
an
invaluable
resource
for
us
and
I.
Think
I
do
think
that
it
would
have
helped
in
engaging,
for
example,
new
contributors.
There
may
be
like
oh
okay,
well,
I,
wouldn't
this
seems
like
a
pair
to
do
approach
from
the
outside.
So
maybe,
if
I
just
spent
three
hours
with
somebody
knows
what
they're
doing
they
could
be
a
lot
of
fun.
J
I
I
know
that
we're
gonna
be
there's
gonna,
be
a
sprint
of
the
Cincinnati
right
to
das,
but
I
don't
have
the
detail
all
eyes,
so
it's
bring
in
some
people
file,
but
with
that
we
are,
we
are
over
time.
So
thank
you
for
everyone
for
attending
and
if
you
have
any
follow-up
discussion,
things
like
that
feel
free
to
have
them
on
the
slack
channel
and
I
will
see
you
all
in
a
week.
Please.