►
From YouTube: K8s SIG Docs Meeting for 20201208
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
So
hello,
everyone,
this
is
the
sig
docs
weekly
meeting
for
the
8th
of
december
2020,
also
kubernetes,
release
day
on
the
agenda.
Brad,
you
were
just
asking:
let's
essentially
copy
last
week's
agenda
and
narrow
it.
Let's
do
that.
B
Yeah,
I'm
learning.
I
would
love
to
contribute.
A
C
B
A
Cool,
well,
that's
great
walid.
I
think
I'll
I'll
put
a
if
we
get
time
I'll
ask
if
there's
anything
you
want
to
know
at
the
end
of
the
agenda.
A
A
A
D
I
will
yes,
like
tim,
said
today's
the
release
day.
We
are
good
to
go.
It
has
started
already,
so
I'm
just
on
standby
to
make
sure
once
it's
been
cut,
I
can
release
the
docs
and
then
we
are
gonna
coordinate
so
that
the
announcement
goes
after
the
release.
Blog
gets
first
done
so
yeah
we're
all
good
from
here.
D
I
actually
wanted
to
mention
one
thing.
So
if
you
had,
if
you
have
any
like
feedback
on
the
docs
process
in
general,
like
how
the
release
docs
team,
how
they
interacted
with
sick
dogs
for
this
release
like
I
think
we
should
make
time
for
that
in
the
next
meeting,
so
I
just
wanted
to
get
everyone's
like
just
mention
that
so
that
everyone
thinks
about
it
and
then
like
next
week,
I
like
to
just
hear
from
everyone.
A
Okay,
cool-
and
I
will
be
helping
with
that-
I
am
going
to
ban
fireflies.ii.
A
E
D
E
And
then
sorry
was
there
any
for
the
feature
blog
post
coming
out.
D
Well,
yeah,
so
all
the
pr's
are
public
were
made
yesterday
from
what
I
have
seen,
and
I
think
that's
something
I'm
gonna
actually
mention
to
the
team,
because
that
was
cut
like
pretty
cutting
it
close
in
my
opinion,
like
I
think
the
release
blog
should
have
at
least
been
open
like
at
least
few
days
before
I
don't
know
what
the
like
the
process
is
from
the
last
release,
but
I
feel
like
a
day
before
is
not
like
a
good
time.
E
Yeah
yeah,
I
saw
a
couple
things
come
through
with
this
release
that
I
think
could
have
been
smoother
and
that's
on
us.
I
think
as
well
from
the
blog
team.
I
think
there's
been
some
confusion
around
the
the
blog
process
and
I
just
wanted
to
kind
of
give
a
refresher
on
what
the
blog
process
looks
like.
We
have
done
it
a
little
bit
different
for
releases
in
the
past,
just
in
terms
of
efficiency,
but
there
is
a
dedicated
team
of
blog
reviewers
that
automatically
get
assigned
to
the
blog
post.
E
There's
a
list
of
that
in
the
blog
blog
project
group
that
I'll
include
here
as
well.
I
think
there
might
be
a
little
bit
something
going
on
with
the
with
that
process,
because
I
think
some
of
the
blogs
haven't
been
getting
assigned
to
the
right
people,
so
we
have
a
meeting
on
thursday.
E
I
know
a
couple
of
people
are
interested
in
being
part
of
the
blog
review
group,
which
we
are
always
looking
for
new
reviewers
there
as
well,
so
we're
gonna
be
taking
a
look
at
that
and
then
kind
of
flushing
out
that
process
a
little
bit
better,
because
I
think
it's
gotten
a
little
bit
messy
over
the
last
couple
of
months.
It
looks
like
and
then
yeah.
E
I
would
love
to
sync
with
you
more
on
kind
of
how
that
release
blog
process
worked
this
time
around
and
how
we
can
help
make
that
smoother
for
next
time.
E
Yes,
definitely
I'll
check,
I
don't
know
who
that
was
this
time
around
so
I'll
check
that.
A
Cool,
let's
talk,
localization
brad
I'd
like
you
to
lead
on
that.
G
Sure
so
we
had
our
monthly
meeting
yesterday
and
it
was
really
productive.
There
were
several
issues
that
that
we
were
able
to
to
come
through
and
and
look
at,
one
of
which
is
there.
There
seems
to
be
two
different
styles
that
the
localization
teams
have.
G
Pretty
much
say:
oh
no,
if
you
have
the
typo
on
a
page
and
that
page
hasn't
been
updated
recently,
you
can't
just
fix
the
typo.
You
need
to
update
the
whole
page
where
we
have
some
other
teams
like
korea,
where
they're
not
so
up-to-date,
and
they
do
things
more
in
batches
and
they're
a
little
more
behind,
in
which
case,
there's
typically
working
off
snapshots
that
are
more
stable
because
they're,
not
in
say
the
most
recent
version
of
the
docs,
and
in
that
case
they
can
fix
typos.
G
So
what
I've
asked
the
the
folks
involved
is,
since
we
have
two
kind
of
popular
models
depending
on
how
on
the
volume
and
the
level
of
people
that
they
have
doing
localization,
you
know
you,
you
need
to
fit
into
one
of
those
two
models
and
you
need
to
be
very
careful
to
to
to
follow
the
best
practices
so
that
you
don't
cause
harm
and
and
mess
up
the
translation
and
again
along
those
lines.
G
There's
sort
of
two
approaches:
there's
the
time
stamp,
based
way
where
they
just
check
timestamps
to
see
what's
been
already
updated
and
then
there's
also
a
tool
in
the
script
folder
for
diff
based.
G
So
I'm
trying
to
get
folks
understand,
there's
sort
of
two
different
models:
they
both
are
very
popular
and
to
make
sure
the
models
are
explained
and
the
best
practices
for
each
so
that
if
a
new
localization
team
comes
on
board
that
they
fit
into
one
of
those
two
models
and
they
stay
in
the
groove
and
and
use
the
right
tools
and
the
right
processes
to
save
themselves.
A
lot
of
pain
and
suffering.
G
Another
thing
that
we
we
noticed,
which
was
a
good
interesting
thing,
is-
and
this
is
for
folks
that
are
on
the
leadership
if,
for
example,
you're
on
the
leadership-
and
you
speak
a
foreign
language,
and
you
see
something
like
let's
say
you
speak
japanese,
for
example-
and
you
you
see
it's
just
a
simple
pr
and
you
have
approval
because
you're
on
the
leadership
team-
and
you
say
oh
well,
let
me
just
go
fix
that
well
turns
out.
G
The
japanese
team
has
a
different
approval
model
where,
basically,
you
need
two
lgtms
they're
they're,
very
careful
with
what
they
do.
And
so
you
know
there
was
just
sort
of
a
warning
to
say:
hey
if
you
turn
out
to
be
on
the
the
sig
doc
leadership
team
and
you
have
overall
approvals
and
you
speak
a
foreign
language
just
be
careful.
There
are.
There
are
some
localization
teams
that
have
sort
of
special
approaches
for
how
they
do
approvals
and
that'll
save
us.
G
G
I've
noticed
that
if
you're
on
a
localization
team-
and
you
do
a
pr
to
put
in
the
prefix
of
the
title
for
the
pr
sort
of
your
language
country
code
and
say
a
colon
because
some
people
don't
go
look
at
the
issues
with
the
labels,
they
look
at
just
their
email
streams,
what
they
get
from
the
emails,
and
so,
if
that's
in
then,
let's
say
you're
on
the
chinese
localization
team,
you
can
easily.
If
the
little
prefix
is
there
in
the
subject
line,
you
can
actually
go
see
the
ones
you
need
to
focus
on.
G
So
some
of
those
teams
are
going
to
look
and
put
that
in
as
a
best
practice
to
put
that
in
the
subject
line
and
then
the
other
feedback
for
sigdoc's
leadership
was
the
toml
files
tim
you're,
familiar
with
that
type
of
file,
the
for
good
reasons.
The
the
localization
teams
do
not
have
authority
to
update
those,
because
if
they
do
it
wrong,
they
can
cause
all
kinds
of
problems.
G
But
just
I
noticed
that
there
are
some
times
that
they
have
a
process
to
get
an
accelerated
review
from
the
sig
docs
leadership
team,
because
there
are
times
when
they
need
changes
and
they
feel
like
there's
a
lot
of
latency
and
since
they
can't
get
authority
to
do
that
themselves,
just
something
we
need
to
look
out
for
that
that
they
are
able
to
get
prioritization
and
that's
all
right.
G
Well,
do
you
want
to
give
them
access
or
to
make
sure
that
there's
a
priority
model,
I
think,
give
them
access?
I
think
that
is
hard
to
fix.
I
I
think
there
was
some
historical
concern
about
it,
but
I
will
open
the
issue
just
like
you
said
I
could.
G
A
Cool,
if
brad,
would
you
also
chuck
that,
as
the
last
item
in
the
agenda
slash
minutes
about
the
the
issue.
A
Okay,
I'm
gonna
move
on
to
open
issues
and
prs
the
first
one
is.
Philippe
martin
has
been
working
like
a
trooper
to
update
the
api
reference.
I
has
anyone
been
following
that
and
would
like
to
to
speak
on
behalf
of
philippe
about
how
that's
going.
A
Okay,
I
can
speak
to
this,
so
this
was
done
as
the
google
season
of
docs,
which
has
now
closed,
the
tooling
has
been
merged
and,
as
discussed
releases
is
very
imminent.
Thank
you,
anna,
and
so
the
approach
that
we've
sort
of
agreed
to
take
is
that,
after
the
1.2
release
is
out,
we
will
focus
on
what
we
can
do
to
get
that
new,
tooling
in
use
and
switch
the
api
documentation
for
the
1.20
release,
which
will
be
current
to
use
this
new
tooling.
A
Tooling,
change
merged
update
for
reference.
A
So
it's
slightly
different
to
what
we
discussed
last
week,
we're
looking
at
rather
than
targeting
dev
1.21
we're
looking
at
targeting
the
primary
branch,
changing
things
on
master
and
doing
a
swap
there.
A
Tooling,
you're,
muted.
A
So
I'm
gonna
summarize,
if,
if
explain
again,
but
I
wonder
since
you've
been
following
this-
the
work
that
philippe
martin
has
been
doing
on
the
updated
reference
and
the
tooling
to
generate
the
updated
api
reference.
Would
you
like
to
speak
about
that.
H
Message:
yeah,
I'm
not
completely
set
up;
I'm
sorry,
I'm
late,
something
about
the
reference.
The
g,
the
google
season
of
dots
that
we're
talking
about
or
sorry.
D
H
You
want
an
update
on
where
it's
at
or
what's
gonna
happen
or
all
the
above
I
don't
know
I
mean
I
think,
that
with
1-2-0
today
or
soon
that
there's
a
there's
reference
in
place,
but
the
the
next
version
for
the
reference
docs
it's
close,
but
there's
there's
linking
changes
that
will
need
to
be
made
right
in
order
for
it
to
merge.
I
think
because
there's
a
lot
of
references
to
the
existing
api
reference
documentation.
H
That's
the
main
concern,
I
think,
is
that
there's
going
to
be
missing
links.
Otherwise
I
mean
the
pages
are
there
and
it
will
be
a
change
from
what
readers
are
currently
used
to,
but
I
think
the
biggest
concern
I
have
right
now
is
just
to
get
the
links
cleaned
up.
A
Yeah,
I
think
in
fact,
action
on
me
to
log
an
issue
about.
H
We
also,
we
also
lose
a
single
point
of
I
don't
say
reference,
but
we
lose
a
single
point
to
actually
link
to
there's
no
longer
one
page.
So
there's
many
pages.
So
that's
another
difference
that
maybe
there
will
be
outside
groups
that
want
a
single
page
or
one
or
will
lose
that
connection,
so
they
will
no
longer
have
a
1.20
to
reference.
A
So
that
does
sound
like
the
sort
of
thing
that's
worth
tracking
as
an
issue,
I
I
you
know,
I
can
think
right
away
about
some
ideas
that
I
might
have
about
being
able
to
keep
the
best
of
both
worlds.
So
I'm
going
to
take
an
action
on
me
to
log
that
issue
and
move
that
discussion
forward,
and
I
will
copy
people
in
philippe
and
karen
in
particular.
Anyone
else
want
to
be
informed,
mention
it
in
the
chat.
A
Cool,
so
is
everyone
clear
like
wave
if
you
are
not
clear
or
mentioned
in
the
chat,
if
you'd
like
to
know
more
about
that
particular
task.
A
A
Adam,
if
you,
if
you,
are
able
to
stay
and
and
talk
about
the
security
docs
recommendation,
please
do
otherwise.
I
will
try
and
put
that
up
for
you.
A
Okay,
thank
you
right,
so
yeah
I'll
log
that
issue.
Essentially,
the
plan,
is
to
do
the
work
so
that
we
have
high
quality
release
high
quality
reference,
api
reference
documentation
in
the
repo,
and
that
will
be
for
the
1.20
documentation
app
for
the
1.21
documentation
of
all
those
and
all
all
subsequent
versions.
H
H
A
Okay
next
issue:
we're
gonna
talk
about
sig
security,
docs
and
some
recommendations
that
I
mentioned.
I'm
gonna
just
read
these
before
I
talk
about
these.
Would
anyone
else
like
to
speak
about?
This
is
a
topic.
Anyone
else
is
familiar
with.
A
Okay,
so
sig
security
has
a
a
doc
sub
project
which
obviously
is
tied
closely
into
segdocs,
and
the
feature
request
here,
that's
anna's
discussing
is
to
warn
people
about
using
a
particular
kind
of
secret
secrets
have
a
sort
of
a
type.
A
This
is
not
the
same
as
the
kind
field,
but
the
secrets
have
a
type
in
kubernetes
and
the
idea
is
to
document
that,
if
you're
using
an
ssh
auth
secret,
that
this
is
not
enough
on
its
own
ssh
or
secrets,
do
not
protect
you
against
man
in
the
middle
attacks
and
attacks
of
that
nature.
C
I
mean
from
a
purely
like
documentation
perspective.
This
pr
seems
totally
legit
to
me
and
I
trust
security
to
make
good
recommendations.
So
I'm
happy
to
review
it
from
that
perspective,
but
I
can't
provide
a
security
perspective
for
the
obvious
reasons.
A
Cool
yeah
cool.
Thank
you.
If
you
would
so,
let's
move
forward
to
sort
of
remember
to
get
your
commit
messages
right
and
other
feedback
on
that
that
would
be
cracking.
Thank
you
very
much.
A
That
is
it
for
the
agenda.
Would
anyone
else
like
to
add
a
topic
that
they
they
would
like
to
discuss.
I
I
would
like
to
mention
something
quickly.
Let
me
pull
it
up
on
github,
I
proposed
some
changes
to
the
style
guide
and
a
couple
people
in
here
have
been
contributing
on
that
pr.
I
appreciate
it.
I
I
did
another
revision
on
the
examples
for
capitalization
and
I'm
going
to
paste
in
the
url
of
both
the
pull
request
and
the
preview
the
preview
page.
So
if
anyone
has
any
has
any
problems
with
the
new
examples,
please
feel
free
to.
Let
me
know.
A
Sure,
I
guess
you
have
access
to
the
live
agenda.
Jeffrey.
A
Okay,
if
you
join
the
sig
docs
google
group,
you
need
a
google
account
for
this.
Then
you
can
have
more
than
read
access.
I
I
I'll
check
into
it.
I
believe,
I'm
a
member
of
that
google
group.
A
Okay
and
if
you
don't
have
access
mentioning
slack
and
I
think
we
can
get
it
sorted,
but
that
stands
for
for
other
people.
This
document
is
something
that
is
participatory
kind
of
like
a
wiki
and
if
you're
on
this
call
and
you're
not
being
behaving
inappropriately,
then
it's
fine
for
you
to
have
access
and
if
you
are
behaving
inappropriately,
then
we
are
bound
by
the
kubernetes
code
of
conduct.
That's
going
to
be
a
problem!
A
I
might
screen
share
this.
This
change
that
you've
put
up
geoffrey
and
have
a
bit
of
a
discussion
here
to
see.
If
there's
any
disagreement
really
have
people
got
this
pr.
A
A
This
one
text
I'm
highlighting
concerns
me
jeffrey.
A
F
A
Yeah,
absolutely
using
a
persistent
volume
there
would
would
clear
away
that
that
challenge.
A
Cool
that
what
that
that
that
feedback,
I've
just
offered
around
things
that
are,
in
the
rest,
api
versus
fields
that
exist
in
the
documents.
The
rest
api
accesses
is
that
making
sense
to
people
any
questions
about
that.
Have
I
explained
myself
clearly
enough.
I
I'm
I'm
a
bit
confused
because
are
you
suggesting
that
volume
shouldn't
be
capitalized
in
that
sentence.
A
I
Okay,
the
problem
is
calling
volume
a
resource.
Okay,
that
I
appreciate
you
clarifying
that.
So
I
now
the
change
to
be
persistent
volume
makes
sense
or
volume
object.
A
Cool-
and
I
will
put
that
after
this
call-
I
will
put
that
feedback
in
in
the
pr,
as
well
as
a
review.