►
From YouTube: SIG Docs meeting for 20211130
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Hello,
nice
yeah
just
for
context
for
folks
watching
the
recording
I
mentioned
that
there's
the
live
on
youtube
button
under
more
here
does
that
work
for
every
host,
like
if
I
click
that
right
now
do
I
go
instantly
live
to
youtube
or
how's
that
work?
I'm
scared
to
click
it
I've
seen
it
hooked
up.
I
don't
use
it.
Okay,
gotcha
gotcha
I'll
play
with
that
later.
Good
to
know,
awesome
well
welcome
everybody.
This
is
the
bi-weekly
sig
docs
meeting.
A
It
is
10
30
pacific
on
november
30th
and
yeah,
I'm
jim
angel
a
co-chair
and
we'll
get
we'll
get.
This
thing
started,
as
I
said,
kick
this
off
and
get
us
started,
but
the
two
words
kind
of
didn't
match
together,
we'll
kick
this
off
and
get
it
started.
A
Cool
hear
nothing,
it's
great
to
see
everybody
again
welcome
back
moving
on
to
updates
and
reminders.
This
week's
pr
wrangler
is
zach.
Arnold
I
reached
out
to
zach
not
too
long
ago
about
his
involvement
with
sick
docs,
and
I
haven't
heard
a
response.
A
I
believe
that
we
might
need
a
fill-in
for
the
pr
wrangler
this
week.
I'm
waiting
on
a
confirmation
from
zach,
but
is
anybody
willing
to
step
in
in
the
interim?
In
the
meantime,.
A
And
hearing
a
whole
lot
of
nothing,
we
could
just
leave
that
open-ended
I'll.
Let
folks
know
and
sig
ducks
if
I
hear
anything
back
from
zach,
I'm
happy
to
step
in
and
help
out
too.
If
anyone
else
is
interested
in
you
know
pr
wrangling
or
what
what
that
looks
like
happy
to
happy
to
have
a
shadow
or
an
additional
set
of
hands
to
help
out
there
and
then
no
matter
what
next
week
I
will
be
the
pr
wrangler.
A
So
the
double
duty,
if
I
do
get
this
week
as
well
and
approvers
note-
make
sure
you
know
your
pr
wrangler
shifts,
and
I
wanted
to
shout
out
that
we
did
recently
update
a
shadow
section
for
the
pr
wranglers
so
for
context.
For
folks
pr
wranglers
are
usually
well.
Usually
they
are
the
approvers
of
sig
docs
weekly.
We
do
shifts
where
we
go
through
the
open,
pr's,
the
pull
requests.
A
A
So
what
we've
done
is
we've
introduced
a
a
shadow
opportunity
for
folks
who
might
not
be
approvers
but
who
are
interested
in
what
does
a
pr
wrangler
do,
and
so
that
is
a
great
opportunity
for
folks
who
are
just
curious
on
what
that
looks
like,
and
it
gives
you
the
opportunity
to
to
volunteer
to
be
a
shadow
if
you
click
on
the
link
in
the
agenda
and
I'll,
send
the
agenda
in
chat
here
as
well.
A
There
you
go
if
you
click
the
link
in
the
agenda
to
go
to
the
pr
wrangler
page
you'll,
see
that
there's
a
section
for
shadows.
I
believe
anyone
can
edit
the
wiki.
Please
correct
me
if
I'm
wrong
or
if
you
cannot
edit
it
and
feel
free
to
slot
yourself
in
there
reach
out
to
the
folks
that
are
wrangling
and
yeah
be
happy
to
help,
and
so
what
does
that
look
like
from
a
expectation
or
a
commitment
standpoint?
A
There
is
a
dock
that
talks
about
what
are
the
responsibilities
of
a
pr,
wrangler
and
I'll.
Send
that
in
chat
here,
as
well
as
just
update
the
agenda
for
context
and
the
anticipate
or
the
expectation
of
a
shadow
would
not
to
be
a
full
pr,
wrangler
but
schedule
maybe
an
hour
or
two
hour
session
with
the
shadow
and
go
over.
You
know
what
does
it
look
like
to
wrangle
prs?
What
is
your
thought
process
could
be
done,
asynchronously
really
open
to
whoever
is
currently
leading
the
the
pr
wrangler
ship
so
I'll.
C
A
D
E
D
So
we
are
intentionally
scheduled
to
release
123.0
next
a
week
from
today,
that
is
december.
7Th.
The
current
status
for
the
dock
side
is
yellow
the
dock's.
Complete
deadline
is
actually
today,
but
there
are
14
open
pr's
to
the
dev
123
branch,
there's
a
number
of
pr's
that
need
tech
reviews
or
tech
attack
lgtm.
So
I'm
going
to
go
back
and
request
for
those
excuses.
D
Part
of
me
for
my
voice
yeah,
so
I
will
go
back
and
take
a
look
at
the
open
pr
see
what
needs
to
be
reviewed
or
tech
need
tech,
lgtms
and
ping.
Those
sigs
accordingly.
D
Cool,
so
I
do
want
to
make
one
notes,
since
we,
since
the
next
docs
zoom
meeting,
is
after
the
release,
we
will
freeze
the
k
website
repo
24
hours
before
the
scheduled
release
date,
so
we
will
freeze
it
on
monday
december
6.
D
comms
will
go
out
before
that,
so
hopefully
we'll
get
everything
anything
that
needs
to
be
merged
and
by
friday,
then,
because
we'll
freeze
it
on
monday.
Technically,
you
could
merge
things
over
the
weekend,
but,
let's
just
say,
friday's
best.
A
E
A
E
I
can't
speak
for
all
of
them.
I
know
the
ones
I'm
looking
at
have
had
docs
reviews
and
just
looking
for
the
the
tech
lgtm.
A
Cool
that
sounds
good
to
me
and
there's
one
thing
I'd
like
to
to
bring
up
for
the
the
release
process,
at
least,
is
that
documentation
is
a
really
critical
part
of
the
release
from
the
sense
of
you
know.
A
If
you
can't
document
the
new
features
and
enhancements
coming,
it's
going
to
be
very
challenging
to
use
or
adopt
them
day
one,
and
so
I
I
see
sig
ducts
playing
a
critical
role
in
the
release
process
and
the
one
thing
I
like
to
share,
because
it's
not
always
obvious,
I
feel
like
docs-
are
sometimes
an
afterthought
or
they're
not
really
included
in
the
overall
process.
A
Kubernetes
in
particular,
in
the
open
source
community
has
done
a
great
job
at
tying
in
docs
to
the
release
process.
But
I
wanted
to
call
out
is
that
not
having
docs,
complete
or
with
the
tech
review
does
give
the
docs
release
team
the
opportunity
to
block
a
release?
A
And
I
think
that
not
a
lot
of
folks
realize
that
the
sig
ducks
release
team
has
that
that
power
or
that
function,
and
so
I
like
to
bring
it
up
when
we
get
to
this
point
in
a
release
where
docs
has
historically
never
postponed
to
release.
For
those
reasons.
But
at
the
same
time
it's
good
to
know
that
you
have
that
ability
or
that
that
a
little
bit
of
leverage
to
get
these
pr's
through
to
get
emerge.
And,
like
I
said,
hopefully,
that's
not
an
issue.
A
And
hopefully
we
don't
need
to
to
leverage
that
that
authority,
but
just
wanted
to
call
that
out.
E
Awesome,
I
was,
it
was
a
very
short
window
between
we
were
actually
green
like
a
week
ago,
because
we
we
had
met
like
the
the
pr
opening.
We
met
the
ready
for
review,
but
now
we're
like
it's
right
on
us.
So
was
this
a
shorter
window
ray
than
we've
had
in
the
past,
to
go
from
ready
for
review
to?
You
know,
ready
to
need
to
publish.
D
It's
the
same,
but
we
have
that
u.s
holiday
in
in
between.
So
that's
what
actually
makes
a
little
difference
for
122
the
the
some
of
the
deadlines
was
actually
even
tighter,
so
for,
but
we
have
it's
always
the
end.
The
last
release
of
the
year
is
always
has
this
issue
because
we
have
holidays,
we
have
kubecon,
so
we
have
two
weeks
that
are
just
yeah.
We
just
have
some
conflicts
with
those
two
additional
weeks.
A
Yeah,
I
would
totally
agree
with
that.
I
think
we've
always
seen
issues
when
you
start
to
get
to
towards
the
tail
end
of
the
q4
timeline
for
sure
cool
anything
else
on
the
release.
B
Tim,
I
just
have
a
question
I
just,
but
I
have
a
question
like
there
might
be
people
on
this
call
who
don't
understand
what
we
mean
by
documenting
for
release.
So
if
there's
anyone
who's
hearing
all
this
and
thinking
okay,
but
I'm
missing
the
basics,
now
ask
and
someone
will
answer
it.
D
So
some
of
those
or
most
of
those
needs
documentation
associated
with
those
advancements
or
features
for
users
to
use
them
like
some
of
the
new
features
like
pod
security
mission
controllers
go
into
beta
in
123.
So
that
means
it's
going
to
be
always
on,
so
you
don't
have
to
turn
on
the
feature
gate.
Some
new
brand
new
features
that
go
into
alpha,
we'll
need
a
feature
gate
to
be
enabled.
So
we
add
in
those
the
documentation
as
well
to
how
to
turn
on
those
feature
gates
and
how
to
use
those
enhancements
or
features.
D
A
good
point,
so,
the
very
at
the
very
beginning
of
the
release
we
asked
sigs
to
opt
in
any
enhancements
or
features
to
target
the
released.
D
So
in
the
very
beginning,
in
august
we
asked
ziggs
to
opt
in
any
announcements
or
features
for
123..
With
that
opt-in
process.
We
do
ask
if
they
need
documentation
for
those
for
their
enhancements
or
features.
Most
of
them
do
most
of
the
case.
They
always
do,
especially
if
they're
graduating
from
alpha
beta.
The
minimum
is
updating
the
feature
gates
page.
D
The
process
has
changed
since
it's
ever
evolving
so
before
we
had
to
ping
six
independently
from
them
opting
into
the
release.
So,
but
the
current
status
is
that
the
sigs,
when
they
opt
in
for
for
123
or
for
a
release,
they
also
opt
in
if
they
need
documentation.
A
And
I'll
also
add
to
that
as
well,
that
having
a
distinct
like
a
sub
group
around
docs
in
the
release
team,
so
like
the
sig
release,
docs
team
part
of
the
function
or
the
duty
of
that
team
is
to
ensure
that
if
an
enhancement
says
yeah,
we
don't
really
need
docs
and
the
release
lead
says.
I
think
you
probably
do
just
like
you
know,
I'm
doing
a
gut
check
here
and
I
think
you're
you
might
need
docs,
that's
an
opportunity
for
that
function
or
that
that
release
lead
for
doc.
A
Specifically
in
that
team
to
say
hey,
they
said
they
don't
need
docs.
I
think
they
do
or
the
people
that
say
that
they
do
need
docs
might
not
understand
where
all
the
docs
that
they
need
need
to
go.
So
that's
the
the
release
team
to
say:
okay!
Well,
not
only
should
this
be
in
this
page,
a
b
and
c,
but
you
might
want
to
add
a
glossary
term,
and
it's
really
a
great
you
know,
collaboration
between
the
release,
team
and
docs,
as
well
as
all
the
various
you
know,
horizontal
sigs
as
well.
F
F
Hi,
do
the
release
teams
give
a
blurb
or
what?
How
do
you
know
like?
Is
it
specific
text
or
or
is
it
that
they
just
give
a
okay?
This
is
what
we
want
added,
and
then
you
kind
of
have
to
do
a
little
testing
and
figure
out
what
should
be
added
to
the
documentation.
D
Most
of
the
time
they're
pretty
technical,
so
the
sigs
that
own
those
enhancements
or
features
we'll
create
those
we'll
create
the
documentation
changes.
There
is
a
part
of
the
release
that
we
do
add
a
verb
or
we
and
that's
part
of
the
major
theme
so
part
of
part
of
the
release.
We
ask
what
the
major
themes
of
the
release
are:
any
key
enhancements
going
to
stable
key
enhancements
going
to
beta
or
any
deprecations
or
removals.
So
in
that
scenario,
sometimes
we
do
have
to
write
a
blurbs
and
for
123.
D
B
You
said
what
I
was
going
to
say
is
that
as
sig
docs,
we're
often
dealing
with
you
know,
proposed
documentation,
changes
from
people
who
really
understand
that
feature,
and
so
one
of
the
things
that
that
we
do
as
a
sig
is
kind
of
translate
that
a
little
bit
to
understanding
that
someone
might
be
reading
this
documentation-
and
maybe
they
just
want
to
know
about
a
config
map,
they're,
not
interested
in
how
the
config
maps
change
between
1.22
and
1.23
they've
just
never
heard
of
config
maps
before
and
so
the
very
technical
changes
that
come
out
the
six.
B
We
we
it's
it's
it
helps.
If
we
can,
we
can
guide
people
a
little
bit
to
write
less
technical
documentation.
I
think
I've
very
rarely
had
a
challenge
where
people
have
written
it,
not
technical
enough,
but
plenty
of
times
where
I've
suggested
a
more
beginner-friendly
thing.
E
Yeah
one
thing:
it
did
surprise
me:
this
is
the
second
time
I've
worked
on
the
release
team.
I
thought
that
that
the
the
writers
would
be
doing
writing
and
it's
actually
the
responsibility
of
the
person
who
did
the
the
cap,
the
kubernetes
enhancement.
What's
the
p,
for
I
don't
know
whatever
proposal.
Thank
you.
They
basically
follow
the
the
person
did,
that
is
responsible,
then,
for
for
doing
the
first
drafts
of
the
documentation
and
so
yeah.
So
really
ours
is
sort
of
an
overseeing
making
sure
that
it
gets
done.
E
It's
it's
a
lot
of
hurting
cats
and
and
making
sure
that
the
right
people
review
it
and
not
not
a
lot
of
writing
really
associated
with
that
on
our
side.
G
Interestingly,
a
lot
of
kept
authors
don't
realize
that
they're
also
in
for
some
documentation
authorship.
So
it's
also
a
good
good
point
to
like
educate
on
that
front,
when
a
lot
of
folks
are
putting
caps
into.
E
We
do
all
our
work
from
a
spreadsheet
would
that
be
appropriate
to
share
here.
It's
a
public,
spreadsheet,
yeah.
E
Yep,
it's
a
public
spreadsheet.
Okay,
I
can,
I
can
paste
the
link
in
and
you
can
see
that.
Basically
we
we
track
all
the
caps
on
you
know
and
and
then
we
we
have
a
spreadsheet.
That
basically
says:
does
it
need
documentation?
Has
a
pr
been
open
for
it?
You
know
all
that
kind
of
thing.
So
I'll
I'll
put
it
into
the
agenda.
A
A
Perfect-
and
I
also
think
that
this
is
a
great
opportunity
to
mention,
so
this
is
great
context
setting
around
the
release
process.
I'm
glad
to
see
folks
interested
in
this
and
I'm
glad
to
see
this
conversation
happen.
You
know
somewhat
organically
and
thanks
for
tim
for
the
for
teeing
that
convo
up,
but
I
wanted
to
call
out
that
every
release
cycle
there
is
an
opportunity
to
shadow.
So
we
talked
a
lot
about
the
process
and
what
sig
docs's
roles
and
responsibilities
are
in
the
release
team.
A
But
as
far
as
the
release
team
structure
is
usually
you
have
a
sig
release,
lead
sig,
docs
release
lead,
and
then
you
have
shadows
between
three
and
five,
I
would
say
is
usually
the
number
there's
really
no
hard
rules
unless
that's
changed
right.
Correct
me.
If
that's
changed
in
the
past
couple
years,
but
there's
no
hard
cap
on
the
shadows.
As
far
as
use
your
best
judgment,
if
you
get
more
than
five,
it
starts
to
be
coming,
it
becomes
a
little
bit
unwieldy
to
manage.
A
So
what
I
wanted
to
emphasize,
though,
is
that
that
shadow
opportunity
is
a
great
opportunity
to
get
started
in
the
release
process
and
start
to
figure
out
what
is
going
on
without
actually
getting
thrown
into
the
fire.
And
so
the
idea
is
that
folks
can
join
as
a
shadow,
learn
the
process
with
low
responsibility.
A
There's
high
responsibility
in
the
terms
of
engagement
and
time
commitment,
but
low
responsibility
in
terms
of
the
actual
release,
and
so
the
shadow
opportunity
is
a
way
for
you
to
learn
the
process
and
the
the
general
promotion
path
would
be
you
shadow
two
releases,
and
then
you
leave
the
third
one
and
that's
worked
out
very
well
so
far.
It's
not
a
perfect
scenario.
That's
actually
one
of
the
ways
I
got
really
heavily
involved
in
sick
docs.
I
shadowed
two
releases
and
then
I
led.
A
I
think
it
was
114
back
way
back
when
and
it
was
a
great
learning
experience
for
me.
So
I'd
highly
encourage
folks
to
look
for
the
announcements
for
shadows
that
would
be
on
the
k,
dev
mailing
list
to
send
out
announcements
when
they
publish
it
as
well
as
reach
out
to
any
of
the
current
release
team.
Ask
them
their
experience,
get
their
involvement.
A
A
D
A
All
right
so
going
down
to
issues
and
pr's
I
added
in
there
is
a
pull
request:
three
zero
six,
eight
four,
no
actions
required.
I
wanted
to
raise
awareness
and
what
this
is
is
a
specific
file
in
the
kubernetes
website
directory.
I'm
gonna
send
it
in
chat
here
and
update.
The
issue
is
a
security
context,
markdown
file
and
in
that
file
there
is
some
references
to.
I
think
I
might
have
just
linked.
Oh
try
to
walk
and
talk
here,
I'm
failing
at
it
in
the
security.md
markdown
file.
A
There
is
a
alias
there
that
folks
can
update
to
specific
urls
and
as
a
localization
team,
it
makes
total
sense
that
you
would
see
this.
You
see.
Okay
in
this
example,
it's
the
korean
documentation
team
and
we
see
an
issue
security
security.
Md
we
see
the
alias
is
redirecting
in
this
pr
that
I
linked
changing
it
to
slash
ko
slash
security.
A
The
issue
is,
is
that
if
you
include
that
far
left
or
the
prepended
slash
in
a
url
hugo
treats
that
as
the
base
url,
and
so
it's
going
to
assume
that
anytime,
you
want
to
go
to
security.
A
B
So
this
is
a
fix
because
previously
on
sig
docs
with
the
localization
team
in
this
case
korean,
but
it
could
happen
to
anyone
just
missed
one
line
that
they
hadn't
localized
and
it
doesn't
look
wrong
because
you'd
expect
to
see
you
know
the
korean
alphabet,
hangout
and
you
you
you-
you
don't
see
hangul
there,
because
it's
url
okay,
so
it
would
you'd
expect
to
see
the
roman
alphabet.
B
It's
just
that
it
should
be
slash,
ko
slash
they
missed
this
and
what
that
meant
was
depending
on
the
site
bill.
That
was
now
a
non-deterministic
issue
where
some
site
builds
would
redirect
security
to
the
english
page,
which
is
what
we
want
using
our
alias
and
sometimes
it
would
redirect
again
using
a
hugo
mechanism
to
the
korean
page.
B
Now.
What
we
probably
want
to
do
is
use
a
a
netify
redirect,
which
is
the
second
file
in
this
pr
static,
underscore
redirects.
So
this
is
the
fix.
This
is
take
it
out,
and
one
of
the
reasons
this
has
been
raised
is
because
it
is
easy
to
miss.
A
Yeah-
and
I
think
too,
that
there's
potentially
an
alternative
solution
here,
as
well
as
far
as,
if
you
have
a,
I
feel
like
it's
just
so
hard
to
explain
without
sharing
my
screen,
I
could
just
share
out
my
screen
here,
but
ultimately
the
alias
slash
security
when
it
when
it
has
that
prepended
slash
or
the
slash
before
the
word
security.
It
goes
to
the
base
url
you
can
have
an
alias
without
that
prepended
slash
and
it
would
redirect
to
the
local
content
or
the
local
language
there.
So
an
alternative
solution.
A
Besides
this
redirect,
is
dropping
that
forward
slash
the
problem
is,
it
makes
complete
sense
from
a
localization
perspective.
When
you
see
this
document,
you
see
it
living
in
your
localized
content.
That
you'd
say
hey.
We
don't
go
to
slash
security.
We
go
to
slash
whatever
my
localization
is
security,
so
there's
multiple
solutions
here
tim
has
this
fixed
in
which
is
great
jumped
on
the
issue
really
appreciate
that
alternately.
I
know
ricardo
katz
has
talked
about
building,
potentially
some
sort
of
ci
check
to
prevent
this
from
happening
in
the
future.
A
I
did
some
digging
on
this
issue,
and
this
is
the
third
or
fourth
time
that
this
has
happened
now
and
so
I'm
kind
of
one
of
those
folks.
You
know
it's
a
fool
me.
One
shave
on
me
fooled
me
twice
a
shame
on
you
or,
however,
that
goes.
You
know.
I'm
screwed
it
up
like
george
bush
here,
but
ultimately
the
idea
being
that
that
we
want
to
make
sure
we
have
a
protection
in
place.
A
So
we
don't
have
to
relive
this
or
relearn
it
a
fourth
time
and
ultimately
that
would
be
the
goal
here.
So
whatever
the
fix
is,
we
need
to
move
forward
with
it,
but
I
wanted
to
raise
awareness
around
what
happened
why
it
happened
and
the
fact
that
this
has
happened
now
three
times
in
the
past
two
years
and
just
to
make
sure
that
we
we
are
aware
of
this.
A
G
A
B
Thinking
about
this
from
a
a
little
bit
like
a
a
workplace
safety
sort
of
context,
it's
probably
not
fair
on
localization
teams
to
say:
there's
this
really
niche
way
that
you
can.
You
can
break
the
site
and
don't
do
it
it's.
It
is
the
better
control
to
make
it
so
you,
as
a
localization
team,
you
can't
approve
a
change
that
breaks.
Another
localization
like
as
a
korean
approver,
you
shouldn't
have
a
button
marked
break
english.
A
A
That's
a
great
question,
so
there
is
a
little
bit
of
a
loaded
question,
but
ultimately,
the
way
hugo
works
is
it
can
generate
everything
from
a
static
site,
all
the
requirements,
so
your
markdown
becomes
html.
Some
of
your
javascript
becomes,
you
know
imported
as
code
and
some
of
your
localizations
or
your
aliases
and
redirects
becomes
the
way
that
urls
are
handled,
and
so
things
like
a
specific
url
going
to
another
page
or
another,
redirect
it's
basically
a
way
to
handle
content
management.
A
So
if
you
into
case.io
security,
it
would
redirect
to
the
korean
localization
the
intention
being
at
least
the
the
intended
change,
not
the
actual
change,
but
the
intended
change
would
be
that,
if
you're
on
the
korean
documentation-
and
you
were
to
go
to
security-
that
it
would
redirect
to
the
korean
specific
security
page
for
localization,
and
that
single
change
then
broke
it
for
everybody,
as
opposed
to
localizing
that
security
page
just
for
korean
localization,
and
so
the
solution
is
then
to
prepend.
A
A
Any
other
questions
comments
around
issues
or
prs.
A
Yeah
yeah,
so
you
absolutely
are
welcome
to
create
an
issue,
as
you
see
fit,
for
some
of
the
issues
that
you've
seen
on
the
documentation,
but
I'm
still
not
sure
exactly
what
page
you're
referring
to.
A
Well,
actually,
if
you
can
hear
me
feel
free
to
open
up
the
issue,
I
said
I
was
hoping
to
get
more
context
on
the
page
you
were
looking
for,
but
yeah.
I
see
no
issues
opening
up
an
issue.
If
you
see
any
sentences
that
could
be
corrected.
If
you're
talking
about
specifically
localization,
we
can
tag
them
into
that
issue
as
well.
A
All
right
moving
on
so
discussion
topics,
this
one
is,
I
brought
up
because
it's
been
quite
a
while,
since
we've
done
a
doc
sprint
at
least
two
years,
I
would
guess,
with
the
whole
pandemic
the
small
details.
You
know
why
we
didn't
hold
one
and
I
think
that
it'd
be
good
to
either
bring
one
virtually
or
potentially
the
next
in-person
event,
and
really
I
didn't
have
any
loaded
agenda
here.
I
just
wanted
to
see:
is
there
interest
in
hosting
a
sig
dac
stock
sprint?
And
if
so,
is
there?
J
I
would,
I
would
definitely
be
interested
in
helping
I
haven't.
I
have
no
idea
how
to
how
it
all
works,
but
I
would
definitely
be
interested
in
helping
out
and
I
think
it
I
think,
they're
a
lot
of
fun-
a
lot
of
work,
but
a
lot
of
fun
to
get
people
interested
in
the
community.
So.
A
Awesome,
well,
we
got
you
there
and
before
moving
on
anyone
else,
interested
looks
like
we
got
some
plus
ones
in
chat.
Let's
see
making
sure
I
caught
everybody.
If
I,
if
I
didn't
catch,
you
feel
free
to
jump
into
the
agenda
and
add
your
name,
I
think
the
more
the
merrier
here
we
can
always
divide
and
conquer
as
we
see
fit
or
potentially
run
multiple
doc
sprints
as
well,
and
so
that
goes
on
to
the
I
guess.
A
Let
me
set
some
context
here
so
doc
sprint
for
those
who
aren't
familiar
with
it
are
a
way
to
gather
a
group
of
interested
people,
technical
writers
or
folks
who
are
interested
in
contributing
to
documentation
and
you
get
everybody
into
the
same
room
or
the
same.
You
know
virtual
meeting
platform
and
you
ultimately
go
over
here's
kind
of
the
prereqs
to
get
started,
and
then
you
start
to
dive
into
what
are
the
issues
how
to
solve
them?
A
And
you
just
kind
of
have
like
a
some
folks-
might
call
it
like
a
bug
bash,
but
the
doc
sprint
is
really
just
going
through
and
cracking
at
open
prs
or
usually
there
is
themes,
and
so
that
kind
of
leads
me
to
my
next
topic
for
discussion
is:
does
anybody
have
any
thoughts
or
ideas
for
themes
for
the
doc
sprints?
A
So
to
give
you
some
context
or
examples,
many
years
ago,
when
the
site
moved
from
being
a
jekyll
built
site
to
a
hugo
built
site,
there's
a
lot
of
carryover
kind
of
like
loose
ends
there
that
really
need
to
clean
up,
and
there
was
a
doc
sprint
to
work
on
the
jekyll,
the
hugo
migration
cleanup.
We
opened
issues,
we
tracked
him.
The
whole
purpose
of
the
event
was
driven
around
cleaning
that
up
a
secondary
example
to
that
is.
A
When
we
changed
the
theme
in
hugo,
we
changed
the
theme
from
the
default
one
that
we
were
using
to
the
new
doxie
theme.
There
was
a
lot
of
changes
there
that
were
required,
a
lot
of
ketchup
that
was
needed,
and
so
then
there
was
a
doc
sprint
around
the
efforts
needed
to
clean
up
that
hugo
migration
or
the
theme
migration
there.
So
any
thoughts
for
a
topic
of
interest.
E
Topic
I
I
participated
in,
I
think
it
was
2017
austin
in
the
doc's
brand
we
had
at
the
the
kubecon
and
we
were
just
given
a
list
of
glossary
terms
and
we
each
took
you
know
one
or
more
glossary
terms.
It
was
a
really
good
way
to
start
to
start.
You
know
just
doing
your
first
prs
and
all
that.
So
if
you
can
find
little
small
bite-sized
things
that
that
you
know
that
can
be
done,
that
I
think
that
was
a
really
good
way
to
do.
It.
G
I'm
wondering
if
there's,
I
know
we
say
dog
sprint,
but
I
remember
whitney
bringing
up
a
while
back
about.
Maybe
a
cool
option
to
you
know
include
a
lot
of
video
content
and
that
could
be
a
way
to
like
figure
out.
How
do
we
weave
more
video
content
into
the
docs.
A
G
K
I
think
redoing
the
tutorials
would
be
a
good
idea.
They're
really
well
bounded
they're
easy
for
most
people
to
understand,
even
if
they
aren't
kubernetes
experts.
They
have
gotten
they've
gone
through
a
bit
of
a
weird
cycle
too,
and
that
they
haven't
been
updated
for
a
while.
I
think
we
updated
them
a
little
bit
here
and
there
to
sort
of
deal
with
technology
changes,
but
some
of
those
updates
were
quite
controversial.
K
They
don't
necessarily
conform
to
the
third
party
content
rules,
so
I
think
doing
a
bit
of
a
survey
of
the
community
saying
like
what
kind
of
tutorials
and
examples
do
you
want
to
see
for
kubernetes
in
this
year
of
2021,
2022
and
either
reworking
tutorials
or
adding
new
tutorials
would
be
both
useful
as
well
as
non-intimidating.
K
And
I
mean
in
comparison
to
the
other
things
that
could
potentially
benefit
from
adult
sprint,
like,
for
example,
revisiting
site
architecture
and
and
documentation
information
architecture.
This
is
potentially
less
troublesome
for
it's
potentially
less
troublesome.
Let's
just
sleep
there.
A
No,
I
I
totally
agree
with
that,
and
I
would
love
that's
a
that's.
Another
side
note
is,
if
folks
are
interested
in,
I
think
that
the
kubernetes
website
is
self.
The
k
slash
website
has
a
lot
of
baggage
with
it,
because
there's
no
one
there
that's
going
to
go
and
clean
it
up,
and
what
I
mean
by
that
is.
A
I
just
mentioned
that
we
did
two
doc
sprints
from
a
jackal
to
hugo
migration
from
a
theme
migration
from
the
original
theme
to
the
doxie
theme,
and
every
time
we
make
these
migrations,
we
reactively
fix
what
breaks
and
we
reactively
fix
what
issues
arise?
We
never
go
back
and
say:
do
we
need
this
data
to
still
exist?
A
Does
the
site
architecture
make
sense
and
not
from
the
visual,
like
user
experience
standpoint,
but
from
the
github
repository
standpoint,
owner's
files
develop
the
way
it's
structured,
the
content,
every
single
folder
in
there,
every
single
content,
there's
really
no
retroactive
responsibility
to
clean
up
the
kubernetes
website
repository
and
I
think,
there's
an
opportunity
there
for
folks
that
aren't
afraid
to
to
get
a
little
bit
into
the
weeds
of
you
know.
Hugo
and
the
kubernetes
website
to
really
clean
that
up
and
I
don't
think
it's
appropriate
for
a
doc
sprint.
D
So
I
want
to
add
one
more
on
the
tutorials
as
well,
so
there
are
some
tutorials
that
don't
comply
with
what
we've,
what
celeste
has
worked
on
with
the
working
group
naming
particularly
around
the
redis
tutorials,
so
maybe
just
cleaning
up
any
any
of
that
work.
That
needs
to
be
done
in
the
kubernetes
documentation.
A
Gotcha-
and
I
agree
with
that-
the
specific
tutorials
you're
talking
about
regarding
right,
as
I
thought
we
resolved
but
feel
free
to
dm
me
offline.
If
you
don't
think,
that's
fully
resolved
yet
because
I
think
that's
a
whole
nother
story
for
another
time,
I'll
save
it
but
yeah.
Let
me
know
if
there's
still
some
stuff
out
there
pending
and
I'll,
take
a
look,
but
I
thought
that
was
resolved
any
other
ideas
for
topics.
A
I
really
like
the
the
ideas
we
got
so
far
and
it
sounds
like
we
have
enough
staffing
to
to
really
see
this
through.
So
I
like
the
I,
like
the
positive
energy
so
far,.
K
So,
okay,
so
just
to
introduce
myself,
because
I
haven't
been
around
for
most
of
this
year,
and
so
I
don't
think
a
lot
of
you
know
me
so
my
name's
celeste
horgan,
I'm
a
the
staff
technical
writer
at
cncf.
So
I
do
this
full-time
and
a
part
of
the
reason
I
haven't
been
in
kubernetes
for
a
little
while
is
because
I'm
off
solving
144
other
projects,
no
big
deal,
but
so
the
reason
chris
I'm
sort
of
going
like
to
that
is
changing.
The
site's
information
architecture
is
necessary.
K
K
I
don't
know
that
the
kubernetes
project
has
the
process
infrastructure
available
for
approving
work
on
that
kind
of
change.
It's
not
something
we
can
do
unilaterally.
We
would
need
to
consult
the
entire
project.
Quite
frankly,
that
is.
That
is
a
much
more
than
a
two-week
consideration,
and
I
I
genuinely
don't
think
the
project
knows
how
to
deal
with
the
change
of
that
magnitude,
because
it
is
a
re-architecture
and
I
think
you
sound
like
you're
a
career
technical
writer.
K
E
Oh
absolutely,
I
would
think
you
would
move
something
off
to
the
side
and
prototype
something
before
you
did
anything
and
then
you
talk
to
people
and
say
hey:
should
we
even
approach
this,
but
I'd
be
glad
to
work
with
you
if
it's
something
you're
going
to
hit
at
some
point,
I
I
like
working
with
massive
amounts
of
information,
so
I
think
it
would
be
fun
to
at
least
take
a
try.
K
A
K
You're
gonna
see
more
of
me
for
the
foreseeable
future.
I
think-
and
I
guess
this
divia
isn't
here,
so
she
can't
read
out
her
update
around
apac
friendly
meetings.
A
I
just
got
to
say
I
was
going
to
say
for
the
sake
of
time:
let's
punt
the
the
sick
dogs
discussion
for
next
week.
We
can
dive
into
that
deeper,
like
you
were
just
mentioning,
is
that
the
devious
questionnaire
meetings
closed
results
being
out
shortly
and
we
have
about
11
minutes
or
so
for
celeste
to
dive
into
docker
shim,
and
if
we
need
to
go
anywhere.
K
K
Yeah,
this
is
really
just
an
fyi
for
the
group
for
right
now
and
it
will
probably
be
more
than
an
fyi
in
the
months
to
come.
So
three
releases
ago,
the
kubernetes
project
announced
the
deprecation
of
docker
shim
docker
shim
was
a
little.
It
is
exactly
what
it
sounds
like.
It
was
a
shim
to
make
docker
work.
K
Docker
now
implements
the
underlying
oci
spec,
so
the
preference
of
the
project
is
to
use
that
spec
rather
than
to
keep
supporting
docker,
which
is
a
private
company
with
private
code
bases,
open
source
philosophy
stuff.
So
the
downstream
effect
of
that
is,
I
believe,
in
124.
K
The
code
is
actually
being
removed,
so
we
gave
basically
a
year's
notice
for
this
as
such
and,
as
I
think,
the
technical
writers
on
the
call
know
when
you
remove
code,
you
also
have
to
remove
documentation
pertaining
to
that
code.
I
can
see
natalie's
face
like
that's
exactly
what
my
reaction
was
as
well.
So
as
I've
mentioned
in
addition
to
kubernetes,
the
tech,
docs
team
supports
basically
all
cncf
projects.
K
There
are
like
144
of
those
now,
which
is
a
truly
gargantuan
amount
for
two
and
a
half
people,
so
the
kubernetes
project
has
specifically
requested
the
help
of
the
cncf
docs
team
in
managing
this
change,
because
this
is
the
kind
of
change
that
gives
technical
writers
nightmares
that
keeps
us
up
at
night
and
strikes
terror
into
our
hearts.
I
am
sufficiently
terrified
for
now
there
isn't
any
action
items
for
anybody
on
this
call.
K
K
What
kind
of
communications
we
need
to
have
around
all
this
and
then
we're
gonna
figure
out
what
we
need
to
do
to
actually
staff
this
change
and
get
it
done
on
time,
because
my
suspicion
is
that
this
is
gonna,
be
quite
complicated,
but
maybe
I'm
overreacting,
so
you
will
be
seeing
more
of
me
in
the
future
the
next
coming
month,
certainly
for
the
124
release.
This
may
have
to
be
a
hands-on
deck
situation.
We
will
let
you
know,
as
required.
E
K
What
I
want
to
know
as
well,
so
I
will
have
more
answers
on
friday,
because
the
scope
of
the
change
as
described
to
the
tech
docs
team,
and
that
formal
request
for
help
seemed
to
indicate
that
they
wanted
to
remove
any
mentor.
Mention
of
any
docker
command.
From
every
clli
example,
which.
K
I
can
see
the
utility
of
doing,
but
that
is
a
huge
lift
for
this
particular
set
of
documentation,
and
perhaps
so
I
want
to
understand.
Essentially
what
is
the
minimum
viable
thing
that
we
absolutely
need
to
do
and
then
we
can
go
from
there
in
terms
of
what
we
actually
end
up
doing,
but
I
don't
think
that
anybody
has
truly
scoped
out
this
change
and
before
we
embark
on
a
large
project,
it's
always
good
to
do
that.
K
We're
starting
this
a
little
bit
ahead
of
the
124
release
so
for
ray
steven
and
the
release
managers
are
aware
from
sick
release
that
something
is
brewing.
So,
as
usual,
we
will
keep
you
in
the
loop.
A
Cool
yeah
thanks
for
raising
visibility
on
that,
and
I
do
think
if
we,
even
if
we
do
a
separate
doc
sprint,
it
might
be
worthwhile.
If
we
find
there's
a
ton
of
effort
or
an
opportunity
there,
it
would
be
good
to
have
a
really
focused
doc
sprint.
Maybe
in
summer
of
next
year,
depending
on,
I
guess
124
is
going
to
come
out
q1
then
right
april.
I
think
yeah
we'll
talk
more
about
it,
but
yeah.
I
think
that's
a
great
great
concept.
If
we
wanted
to
to
get
more
resources
helping
out
all
right.
A
L
Hey
jim
and
everybody,
I
had
a
quick
question,
so
I
saw
a
closed
issue
due
to
life
cycle
rotten
and
I
was
wondering
what
the
protocol
or
etiquette
is
to
reopening
that
issue
and
and
then
you
know,
hacking
a
pr
on
that.
L
I
did
on
the
closed
issue.
I
did
reach
out
to
the
original
assignee.
I
guess
I'll
wait
for
a
response
on
that.
A
Yeah
for
the
ones
that
are
closed
that
are
closed
by
the
the
feta
bot
and
they're
closed
by
the
kubernetes
robot.
You
can
definitely
reopen
those
really
it's
a
way
that
issues
automatically
get
pruned
out
if
there's
no
activity
on
them.
I
think
it's
30.
60
90
is
the
kind
of
warning
until
it
goes
to
the
completely
stale,
but
there's
no
no
real
hard
fast
requirement
of
when
you
could
reverse
that,
or
you
know
reopen
the
issue:
removing
those
labels,
for
example,
okay,
very
good,
so
I'll
reopen.
A
Yeah,
that
sounds
sounds
appropriate
to
me
very
good
thanks
yep,
no
problem
any
other
questions
or
comments
or
topics
for
discussion.
I
think.
D
I
saw
rolf
raised
our
hand,
go
for
it.
Rolf.
A
All
right
and
also
rope
you
might
want
to
throw
that
on
the
the
slack
there
as
well.
So
I'd
like
to
listen
in
the
upcoming
doctorship
meeting.
Okay,
where
can
I
join?
That's
a
good
question.
Celeste
tim.
Do
you
all
know
where
the
invite
is.
A
K
K
To
be
like
exclusionary,
it's
just
that
like
this,
so
just
to
give
a
bit
of
a
picture.
The
people
who
are
coming
to
this
initial
meeting
are
essentially
sig.
Dogs
leads
a
couple
of
people
from
steering
committee
and
the
cncf
tech
talks
team.
K
So
that's
already
like
six
people
and
it's
just
a
little
bit
hard
to
manage
any
more
than
that
and
have
a
productive
meeting,
and
this
meeting
needs
to
be
really
productive,
because
I
think
we
need
to
come
into
124
with
a
game
plan
and
be
able
to
come
to
the
release
team
and
say
this
is
the
work
that
needs
to
be
done.
This
is
who
the
doxley
needs
to
be,
and
they
need
to
be
aware
that
certain
things
need
to
happen
that
are
going
to
be
a
little
non-standard
but
yeah.
A
You
know
and
robust
you
saw
that
looking
to
get
involved
for
the
follow-up
meetings,
I'm
happy
to
pull
you
in
there.
I
imagine
that
we're
gonna
have
these
conversations
in
the
open
very
frequently.
A
K
Yeah,
I
think,
as
soon
as
we
have
a
better
idea,
but
the
actual
work
that
needs
to
be
done
is,
I
don't
think,
there's
a
there's
a
reason
not
to
do
this,
like
in
the
regular
sig
docs
meeting
so
like
it'll
come
into
the
open
pretty
quickly
so.