►
From YouTube: K8s SIG Docs Meeting for 20201201
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
All
right
looks
like
we're:
recording,
hey,
everybody
welcome!
Welcome
back,
it's
the
weekly
sig
docs
meeting
today
is
december
1st
and
it
is
12
30,
central,
10,
30
pacific,
I'm
jim
angel,
and
let
me
turn
on
my
video
here
that
might
help
I'm
jim
angel.
I
am
one
of
the
co-chairs
of
sick
docs
and
let's
pick
this
thing
off
so
before
getting
started,
are
there
any
new
contributors
joining
us
or
folks
new
to
the
call
who
care
to
introduce
themselves.
B
Hi,
my
name
is
rolf,
I'm
a
senior
tech
writer
at
red
hat
and
I
work
on
the
openshift,
build
and
logging
teams,
and
I
heard
about
you
at
cubecon,
and
so
here
I
am.
C
Hi,
my
name
is
bretta
mccolgan
and
I
work
in
ibm
and
I
attended
a
talk
that
brad
gave
several
months
ago
was
took
a
middle
now
to
actually
join
one
of
your
meetings,
because
it's
quite
late
and
evening
for
me
I
am
based
in
ireland.
I
was
a
tech
writer
for
many
years.
It
has
been
a
tester
for
the
last
several
years,
but
I'd
like
to
get
back
into
writing.
C
So
one
of
the
delays
along
the
way
was
that
I
wanted
to
learn
a
bit
about
kubernetes
before
I
started
to
help
out
on
this
project.
So
I've
done
a
course
now.
So
I'm
here
hope
I
have
some
time
to
help.
I'm
going
to.
C
C
A
A
That's
probably
the
number
one
place
to
get
help
to
get
feedback
and
there's
so
many
nooks
and
crannies
to
docs
to
the
way
we
approach
the
release
cycle.
The
way
we
actually
manage
and
deal
with
documentation
in
the
kubernetes
open
source
project,
but
there's
no
way
you
can
really
learn
everything
all
at
once.
So
I
encourage
asking
questions
interrupt
me.
You
know
I
want
to
make
sure
folks
get
the
most
out
of
these
weekly
meetings
as
well
as
anything
we
can
do
to
help
out
on
slack.
A
Cool,
I
think
it
might
have
only
froze
up,
in
my
end,
not
a
problem
at
all
I'll
move
along
while
everyone
else
is
frozen.
It's
okay,
this
week's
pr
wrangler
is
tim
bannister.
Thank
you
tim
tim.
I
know.
You've
pulled
double
duties
over
the
the
kubecon
breaker
over
the
thanksgiving
break
as
well.
So
appreciate
that
and
then
next
week
is
dimini,
and
I
don't
recall
if
I've
heard
from
dominion.
Well
has
anyone
here
on
the
call
chatted
with
the
meaning
in
the
past.
I
guess.
A
A
Moving
on
to
the
agenda
here,
release
120:
is
there
someone
from
the
120
release
team
who
would
like
to
to
give
us
an
update.
E
Sure
this
is
kristin,
and
so
we
have
three
open
prs
for
120
and
they
all
are
needing
action
from
the
pr
owners.
Anna
was
very
proactive
and
dm'd
all
those
pr
owners,
so
we're
just
awaiting
action
on
their
part.
The
docs
merge
deadline
is
end
of
day
tomorrow,
december
2nd
and
the
dev
120
branches
is
healthy
and
with
sync
last
week,.
A
Have
any
action
on
those
pr's
feel
free
to
you
know,
raise
up
some
stink
and
sig
release
sig
docs
and
see
we
can
do
to
to
light
a
fire
under
that.
F
I
think
a
couple
of
those
pr's
they
could
merge
as
is
and
get
fixed
post
release,
which
is
not
ideal,
but
it
will
unblock
things
and
then
I
think
one
probably
wants
like
a
fix.
A
Cool
yeah,
I
agree
and
it'd
be
great
not
to
have
to
merge
it,
as
is
if
we
can't
get
responsive
pr
owners.
You
know
you
you'd
like
to
think
that,
if
they're
having
a
new
enhancement
or
a
new
doc,
you
know
requiring
feature
going
into
kubernetes.
At
least
the
documentation.
Pr
owner
could
be
responsive
enough
to
address
feedback,
but
that's
my
personal
opinion
on
the
matter.
I
guess.
E
There's
definitely
been
a
lot
of
pinging
on
those
those
last
stragglers
and
yeah.
It's
pinging
dming
slacking
commenting
on
the
prs
themselves,
so
any
ideas
for
the
next
release
are
definitely
welcome.
A
And
I
recall,
I
don't
know
if
the
celeste
that
brought
this
up-
and
I
don't
mean
to
throw
under
the
bus
lest
if
it
wasn't,
but
I
recall
talking
a
little
bit
about
having
documentation
owners
or
maybe
anna,
maybe
as
you
that
brought
this
up.
But
we
were
talking
about
potentially
having
each
enhancement
owner
having
a
doc's.
You
know
point
of
contact
for
the
next
release,
which
might
be
in
handy.
D
Yeah
celeste
actually
brought
it
up
and
I
actually
wrote
it
down
in
the
1.20
retro
documentation.
So
it's
gonna
be
discussed
there
and
I
think
celeste
will
join
me
there.
Hopefully
and.
A
F
Are
wrong?
That's
an
ambitious.
I
know
there
is
one
article
waiting
for
steps
to
move
it
forward.
Jim
and
possibly
I
don't
actually
like
we
if
it's
very
likely
there'll
be
some
blog
articles
around
the
release.
So
I
think
we
might
need
to
look
at
additional
people
to
be
doing
vlog
reviews
and
moving
those
forward.
F
Anyone
on
the
court
is
this:
someone
who
likes
reviewing
blogs
and
is
it
someone
who's
for
whom
blogging
is
an
interest.
F
Cool
and
oh
I've
lost
the
agenda.
F
Please
put
me
at
the
end
of
that
list
as
well:
jim
cool
we'll
do
we
might
need
to
check,
make
some
ownership
changes
and
I
will
I
will
pick
up
considering
that.
F
In
the
document,
or
for
blog,
as
in
yeah,
changing
the
the
the
prowl
concept
of
ownership
and
approval
for
blogs,
as
well
as
also
inviting
people
to
to
join
in
less
formally
so.
F
If
you're,
if
you're
relatively
new
here
a
lot
of
kubernetes
uses
a
tool
called
prowl,
proud,
is
very
opinionated
about
how
it
decides
what
merges
and
so
on.
It
is
essentially
the
part-time
thinking
is
essentially
a
set
of
rules,
but
as
well
as
having
those
rules,
there's
absolutely
there's
room
for
people
to
contribute
by
providing
less
formal
reviews
and
rather
than
approving
things,
simply
providing
feedback
to
to
blog
authors.
So
there's
room
for
for
approval
contributions
and
there's
room
for
every
other
kind
of
contribution
too.
A
F
A
Thank
you
for
that
all
right.
Moving
on
to
issues
and
prs,
so
the
one
that
came
to
my
mind
was
the
google
season
of
docs
pr.
This
is
the
one
that
was
created
as
part
of
the
google
season
of
docs
by
philippe
martin.
This
to
give
some
context
on
this,
we
generate
our
api
reference
documentation
using
scripts
and
things
that
goes.
A
You
know
basically
scan
through
source
code
and
compile
these
documents,
and
what
we've
looked
to
do
is
leverage
something
like
swagger
that
we
could
actually
go
in
and
leverage
the
existing
apis
as
opposed
to
the
technical
source
code
for
documentation
and
being
able
to
generate
those
in
the
fly.
So
it's
no
longer
manual
grab
the
source
code
run
this
tooling
pr.
The
generated
docs
make
it.
So
it's
a
little
bit
more
of
a
living,
breathing
self
updating,
self-updating
animal.
A
A
We
can
generate
some
of
the
components
there
and
that's
really
what
the
work
that
has
been
done
for
the
api
reference,
pr
that
I
linked
in
the
agenda
and
so
we're
at
this
kind
of
split
road
here
where
the
google
season
of
docs
is
now
coming
to
an
end.
This
pr
is,
I
would
say-
and
this
is
a
total
ballpark
number-
it's
around-
80
percent
feature
complete,
but
it's
lacking
that
additional
20
of
a
full
solution
for
generating
the
the
documentation
here.
A
So
the
conversation
ultimately
became
potentially
merge
this
in
at
that
80
effort,
as
well
as
iterating.
On
top
of
this,
basically
we're
up
against
the
deadline
of
google
season
of
docs.
Is
it
smart
to
move
this
forward
and
I
know
there's
some
different
opinions
on
that?
I
know
this
came
up
last
week
at
the
apac
meeting,
as
well
as
more
of
a
word
of
caution
about
hey,
let's
not
merge
this
in
if
it's
not
feature
complete
and
I'm
curious
I'll,
open
up
the
floor
for
discussion
or
further
context
on
that.
G
Sorry,
I'm
eating
cookies.
The
question
I
have
is
so
is:
is
it
not
being
100
feature
complete
a
result
on
our
end
as
a
project,
because
we
don't
have
all
the
swagger
api
specs
available
or
is
it
a
result
of
like?
There
are
just
features
that
have
not
been
built
out
as
a
part
of
the
google
season
of
docs
project.
A
I
believe-
and
I
could
be
completely
wrong
about
this-
I
believe
it's
related
to
the
tooling
that
we're
generating
the
reference
docs
from.
I
think
the
api
is
one
of
the
stronger
ones
that
works
well
with
swagger,
but
I
think
some
of
the
other
tools
might
not
and
that's
more
of
an
open
source,
kubernetes
repository
or
organization
issue,
potentially.
G
Having
worked
with
swagger
before
it's
always
a
bit
cumbersome
at
first,
because
it
it's
yaml,
so
you're
not
really
specifying
anything
like
concrete,
really
or
validating
it
in
any
like
legit
way,
because
it's
supposed
to
be
a
little
bit
free
form.
So
we
can't
really
be
feature
complete
without
having
the
spy
respects
available
for
all
the
things.
F
G
F
Yeah-
and
I
I
mentioned
this
in
the
documentation-
is
that
well,
actually
I
haven't
made
this
explicit
is
that
we
should
look
at
merging
the
tooling
and
accepting
the
tooling
is
a
work
in
progress,
but
we
should
not
at
this
point
merge
the
the
work,
the
pro
the
pr
that's
there
to
demonstrate
the
tooling,
but
I
think
we
are
very
near
to
being
able
to
take
the
tooling
and
actually
use
its
output.
I
think
we're
not
quite
there.
Yet.
F
There
is
a
little
bit
of
challenge
as
well
around
if
we
change
the
uris
for
things
we
are
committing,
you
know
in
documentation,
get
bookmarked,
and
so
you
want
to
be
a
little
cautious
there
as
well,
but
I'm
really
keen
to
get
the
tooling
pr
merged.
G
I
think
that
sounds
interesting
to
me
tim.
I
think
the
other
approach
is
maybe
forget
about
all
the
things
that
are
not
currently
inspired,
because
we
that's
outside
of
our
control
as
a
group
get
the
demonstration
pr
of
the
tool
and
get
like
effectively
the
theme
component
and
the
output
component
get
that
to
a
place,
we're
happy
with
and
say,
we've
done
the
api.
G
The
api
is
in
a
place,
we're
happy
with,
and
perhaps
a
subsequent
season
of
docs
starts
tackling
some
of
these
other
tools,
because
that's
going
to
involve
communication
with
a
lot
of
the
different
cigs
to
say
hey.
If
you
would
like
us
to
do
this
shiny
thing
for
you,
we
need
you
to
start
outputting
data
in
a
format
that
we
can
read
in
that's
going
to
take
some
time.
A
Yeah,
in
addition
to
that
too,
while
we're
in
this
limbo,
while
people
are
making
the
transitions,
if
we
do
have
documentation,
we
provide
today
that's
generated,
that's
a
different
script
that
needs
to
be
managed,
maintain
the
technical
depth
that's
associated
with
the
the
previous
lingering
process.
It
seems,
like
I
would
say,
every
three
to
four
releases:
something
major
happens
in
the
code
base
as
far
as
way
things
are
documented
or
new
changes,
new
enhancements,
new
features.
A
What
have
you
that
ultimately
has
us
going
in,
and
you
know
kind
of
mucking
a
little
bit
with
the
reference
stocks
tools.
So
this
is
something
else
to
be
considering
the
other
piece
too,
that
I'm
not
sure
of
is
what
the
google
season
of
docs
criteria
is
for
successful
completion
of
it.
A
This
would
be
probably
the
lowest
priority
reason
to
merge
this,
as
is,
but
I
want
to
make
sure
that
you
know
if
somebody
signed
up
to
do.
Google
season
of
docs
had
an
outlined
set
of
deliverables
that
you
know
the
reason
that
they
can't
fulfill.
It
is
clearly
you're
explicitly
defined
and
acceptable
for
google
season
of
docs
whatever
that
may
be.
There
might
potentially
be
a
success
criteria
where
this
is
merged,
not
merged
but
potentially
represented
in
this
preview
link
pr
or
something
similar
to
that.
A
Google
season
docs
is
coming
to
an
end,
we're
nearing
a
release
cycle,
we're
not
quite
there,
but
we're
not
sure
if
we're
going
to
get
over
that
hump
in
that
same
time
frame
so
finding
out
a
solution
that
that
makes
the
contributors
happy
makes
the
k
website
repository
happy
and
also
doesn't
cause
a
lot
of
pain
for,
for
the
wider
end
users
of
of
kubernetes.
G
What
we
want
to
do,
then.
I
think
that
tim's
suggestion
is
probably
the
best
one,
which
is,
I
think
we
can
for
sure
take
the
tooling,
and
I
think,
if
we
merge
in
the
tooling,
we
can
say
like
really.
You
gave
us
like
the
hard
essentials
here
and
then
I
think
it's
about
like
scoping
out
kind
of
what
we
want
the
output
to
be
and
to
look
like
and
like
how
we
could
potentially
expand
it
in
other
ways.
F
What
might
happen
with
that
is
that,
soon,
after
the
1.20
release,
we
will
open
development
for
1.21,
maybe
1.21.
That
branch
has
the
new
generator
on
it.
A
Notes
it's
and
would
you
mind,
leaving
a
comment
with
that
feedback
if
you
haven't
done
so
already
and
then
the
other
piece
too,
I
think
it'll
be
more
for
anna
and
and
future
you
know.
Doc's
release
leads
just
knowing
that
this
process
is
going
underway.
You
know
some
sort
of
informal,
slack,
handoff
or
or
knowledge
transfer
there.
As
far
as
you
know,
I
don't
want
to
lose
this
information
in
between
two
releases.
I
know
we're
you
know
coming
up
next
week.
A
I
think,
is
the
release
date
of
the
the
new
kubernetes
release,
so
just
making
sure
that
we
can
carry
this
over
into
the
next
release
cycle
and
also
make
sure
there's
nothing
blocking
the
current
release
cycle
as
well
for
the
generated
docks.
A
Cool
so
that
yeah,
that
sounds
all
reasonable.
I
know
zack
had
mentioned
potentially
considering
merging
in
the
next
48
hours
or
so
I
I
like
tim's
suggestion
as
far
as
you
know,
doing
the
least
amount
of
damage
getting
the
tooling
or
the
the
quote-unquote
hard
part
into
our
documentation,
our
repositories,
if
for
some
reason
that
I'm
not
aware
of
that,
we
do
need
to
actually
merge
this
or
whatever.
A
We
can
definitely
carry
this
conversation
over
into
slack,
but
that
seems
very
reasonable
to
me
for
sure
any
other
questions
or
comments
on
the
google
season
of
docs
api
reference.
A
G
Okay,
so
updates
from
the
naming
working
group,
we
have
a
recommendation
in
for
removing
the
word
master
and
choosing
control
plane
whenever
possible,
asterix,
because
we've
already
found
at
least
one
exception
to
that
rule,
which
is
a
tutorial
that
references,
my
sequel,
slash,
mariadb,
in
which
case
it
makes
a
lot
more
sense
for
us
to
use
the
replacement
terms
that
maria
db
and
mysql
are
using,
which
they're
going
with
primary
replica.
G
So
it's
not
going
to
be
like
a
blanket
search
and
replace
of
the
docs
that
we're
doing
here
by
any
stretch
of
the
word
it'll,
be
a
little
more
context
specific
than
that.
On
that
note,
there
are
two
issues
open
one
in
k
website,
one
in
k,
community,
the
german
and
japanese
translations
are
most
definitely
still
using
master
instead
of
control
plane.
G
G
Please
change
this
on
your
own
schedules
for
the
localization,
so
fyi
that
work
is
going
to
be
starting
to
happen,
which
is
super
cool
as
a
follow-up
to
this
we're
looking
at
kind
of
some
of
like
the
edge
cases
around
master
and
one
of
the
edge
cases
around
master
was
an
issue
opened
by
tim.
G
Excuse
me
on
renaming
the
master
branch
to
live
so
in
general,
we're
trying,
I
think,
to
prefer
maine,
because
that's
what
github
has
decided
to
move
towards.
So
tell
me
more
or
dear
tim.
Tell
me
more.
F
G
One
must
obey
the
fang
overlords
yeah,
that's
kind
of
what
we
wanted
to
hear
too
and-
and
I
agree,
it'll
confuse
people
otherwise.
So
why
confuse
people
but
yeah?
The
next
step,
I
think,
is
gonna,
be
well
at
least
something
I'd
like
to
see
with
the
working
group
naming
and
we'll
see
how
it
goes
is
to
start
moving
slightly
lower
risk,
lower
ci
integrated
repositories
to
to
using
main
because
it
seems
like
github's
promise.
G
Rollover
has
not
materialized
yet
because
it's
december-
and
it
has
not
happened
yet
and
compared
to
say
kubernetes
kubernetes,
which
runs
like
a
massive
suite
of
tests
on
every
pr
docs,
is
both
a
a
prominent
repository
but
a
fairly
low
risk,
one
comparatively
so
yeah.
That's
a
recommendation
that
I'm
going
to
be
taking
back
to
them
and
we'll
see
if
we
feel
like
rolling
those
dice.
Thank
you
very
much.
That's
all
I
got.
A
Awesome,
thank
you
sounds
good
to
me
and
let
us
know
if
we
can
help
with
any
of
those
changes
all
right.
Moving
on
to
brad.
Do
you
want
to
mention
there's
a
cube.
Localization
meeting
not
showing
up
on
your
calendar
is
appropriate.
H
Well,
at
least
on
my
calendar:
it's
it
keeps
showing
up
at
the
11
a.m:
eastern
standard.
It
should
be
1500
utc,
which
you
know
with
the
daylight
savings
thingy
should
be
10
a.m,
and-
and
so
if
it's
just
me,
that's
fine,
if
it's
just
folks,
but
I
think
for
the
international
folks,
they
would
probably
be
okay.
Hopefully,
but
I
know
you
tried
to
change
over
to
a
utc
calendar.
I
didn't
know
if
you
wanted
to
try
and
delete
the
invite
and
and
redo
it
and
see
if
that
worked.
I
just.
A
Figured
I'd
mention
it
yeah
and
I
appreciate
bringing
that
up.
I
think
it'd
be
worth.
I
think
it
would
be
worth
sorry,
I'm
trying
to
look
at
my
look
at
my
calendar
and
talk
here.
I
think
it'd
be
worth
confirming
with
at
least
one
or
two
other
folks
to
make
sure
that
the
issue
is,
you
know
for
everybody
and
not
just
your
own
calendar,
and
the
one
thing
I
wanted
to
do
here
is:
let
me
just
copy.
A
This
link
in
chat
here
is,
if
folks
are
able
to
I'm
going
to
send
this
link
in
chat.
That's
a
link
to
the
sig
docs.
I
guess
quote-unquote
official
calendar
that
I've
shared
out
with
the
leads
tech
leads
and
the
coacher
leads
as
well,
and
what
I've
been
trying
to
do
is
before
we
had
a
lot
of
personal
folks
managing
different
invites,
and
it
is
a
little
crazy.
So
it's
kind
of
like
deal
with
some
pain
now
than
to
have
pain
later.
A
What
we
ended
up
doing
is
changing
some
of
the
meeting
invites
putting
them
all
on
a
single
centralized
calendar
did
the
same
with
the
localization
working
group,
and
then
this
is
a
little
bit
of
a
fallout
from
adjusting
the
times
to
be
utc.
So
I
had
mine
on
my
calendar
here
shows
up
local
at
8
a.m.
Central
and
I
thought
that
it
was
before
9
a.m.
Central
and
then
with
daylight
savings
time
went
to
8,
or
is
it
some
other
time
before.
H
H
A
A
A
B
A
A
A
So,
next
up
on
the
agenda
here,
I
had
an
update
last
week
from
some
of
the
folks
in
the
chinese
localization,
and
it
came
up
about
the
same
issue.
A
I
feel
like
we're
kind
of
beating
this
dead
horse
and
localization
sub
group
is
also
focusing
on
is
how
do
you
keep
up
with
content
that
has
changed,
and
in
this
case
it's
not
so
much
from
upstream,
you
know
was
changed
in
the
main
branch,
but
what
this
is
coming
from
is
the
chinese
localization
group
will
scan
their
github
repository
looking
for
the
time
modified
on
certain
files
and
the
time
modified
would
indicate
when
they
need
to
update
certain
files
which
files
have
already
been
updated
to
match
either
the
current
release-
and
I
could
be
a
little
hazy
on
all
of
the
details
here,
but
essentially
they
use
the
timestamp
of
the
repository
to
know
what
the
old
documentation
is
and
what
needs
to
be
updated
and
what
they've
had
happen
is
with
documentation.
A
Occasionally,
we'll
have
folks
come
by
and
just
do
a
quick
typo
pr
or
a
single
one-liner
pr
fix,
and
I
think
it's
a
great
way
for
folks
to
get
started.
I
encourage
small
contributions.
I
think
it's
a
a
great
gateway
into
contributing.
I
don't
think
you
should
only
do
typo
fixes,
but
I
think
that
it's
a
very
welcoming
path
to
contributing
to
documentation,
and
so
the
the
ultimate
problem
here
is.
A
So
the
suggestion
came
up
more
about
potentially
saying
if
somebody
goes
and
pr
is
a
single
typo
fix
for
a
localization
commit
that
there
might
be
a
general
rule
of
thumb
or
recommendation
to
say,
please,
you
know,
review
the
entire
page
for
accuracy,
for
content
for
freshness
and
maybe
there's
some
guidelines
around
there.
A
But
I
wanted
to
raise
this
up
if
anyone
has
any
other
suggestions.
Experience
with
this,
ultimately,
I
suggested
to
bring
it
up
with
the
localization
working
group
or
sub
project
to
to
track
it
a
little
closer
but
I'll
leave
it
at
that.
Any
any
other
thoughts
or
comments
on
that.
G
So
I
wonder
I'm
just
trying
to
think
okay,
so
in
the
world
of
like
when
you're
working
in
a
company
doing
doing
this
kind
of
translation,
you
like
contract
this
out
to
a
translation,
service
and
you're,
usually
using
like
a
platform
with
built-in
tooling
that
will
track
line
by
line
whether
something
changes,
because
you
are
typically
charged
by
the
word
for
a
translation,
so
there's
like
actually
quite
advanced
tooling
for
this
kind
of
thing,
but
it's
typically
very
expensive
and
I
like
don't
really
think
yet.
Maybe
this
is
a
future
thing.
G
I
don't
really
think
we
want
that
kind
of
overhead
in
our
lives.
So
I
wonder,
if,
like
the
essential
problem
I
think
is:
is
the
translation
teams
don't
know
whether
a
change
is
significant
or
not
like?
That's
we're
trying
to
track
significance.
G
And
I
don't
yeah
and
I
think
if
you
look
at
like
checking
through
the
whole
page,
instead
of
just
doing
one
type
of
fix
and
like
maybe
changing
some
grammar
here
and
there
maybe
rewriting
some
sentences,
like
that's
just
the
same
problem
on
a
different
scale
right.
You
still
have
a
lot
of
minor
changes
that
for
a
localization,
don't
really
merit
re-translating
a
page
but
might
show
up
as
like
a
10
or
20
line
change
kind
of
in
the
git
history.
G
Like
I
wonder
if
it's
a
front
matter
thing-
and
I
think
I've
brought
this
up
before
where
it's
like,
if
you
make
a
major
change
like
you
update
a
date
field
in
the
front
matter
saying
like
maybe
the
front
matter
is
like
the
last
major
change
is
on
date
x,
like
for
and
like
we
define
what
a
major
change
would
be,
for
example
like
if
you're
adding
a
whole
new
topic
or
if
the
page
is
going
completely
sale
and
you
had
to
rewrite
two-thirds
of
it
like
that
would
be
a
major
change
and
that
maybe
is
something
that
the
tool
can
apply.
F
But
I
am
up
for
people
logging
an
issue
to
to
implement
that
feature,
and
we
can
look
at
how
long
it
takes
to
pick
that
up.
I
I
worry
that
it
might
be
a
while.
G
F
H
H
A
Correct
it's
more
like
someone
does
a
fly
by
pr
for
just
a
quick
typo
fix
in
chinese
localized
documents
or
documentation
and
then,
like
the
new
release
cycle,
for
example,
happens
all
new
pages,
all
new
content,
and
they
want
to
look
and
see.
What's
not
been
updated
versus,
what's
been
updated
in
the
master
branch,
but
they
have
to
compare
the
two
of
those,
and
one
looks
like
it's
updated
a
little
bit
sooner
than
maybe
it
truly
has
been.
H
F
So
here's
what
I
want,
I
want
the
next
localization
meeting.
What
I
want
to
happen
is
that
at
the
end
of
it
there
is
a
user
story
as
a
as
a
localization
contributor.
I
want
a
tool
that
x
so
that
y,
and
if
that
story,
isn't
an
issue,
I
will
take
a
look
at
the
issue.
H
F
H
Okay,
I
gotta
really
process
that
so
jim
do
you
know
who
brought
the
issue
up
that
you
could
maybe
mention
that
they
should
bring
it
up
and
put
it
on
the
agenda
for
the
next
localization
meeting.
Just
just
so,
we
know
where
this
came
from
and
because
usually.
A
Yeah-
and
you
know,
shaymin
he's
the
one
who
brought
it
up
so
I
mentioned
I
bring
it
up
at
this
weekly
meeting.
It
does
sound
a
lot
more
appropriate
for
the
localization
group
to.
H
Okay,
so
as
a
chiming,
okay,
great
yeah,
we'll
make
sure
that,
let's,
let's
try
and
get
that
on
the
agenda,
because
I
would
yeah
the
chinese
team
has
been
so
advanced
with
the
localization
and
using
some
hash
hashing
and
some
other
techniques
and
their
tools.
I'm
surprised
this
is
coming
up,
but.
A
A
Cool,
thank
you.
Moving
on
is
kohei
on
the
call,
I'm
not
sure
if
he
added
this
and
then
went
to
bed
or
looks
like
yeah,
we
might
not
have
kohei
here.
So
I
took
a
look
at
this.
It
says
please
do
not
approve
localization
prs
before
confirming
each
language
owner
and
so
looking
at
pr
looks
like
one
of
our
approvers
went
through
and
approved
it,
and
really.
A
This
is
just
raising
awareness
saying
that
if
it's
a
pull
request
for
a
different
language
or
localization,
make
sure
that
there
is
an
additional
localization
representative
to
either
do
it
looks
good
to
me
lgtm
or
an
approved
before
actually
going
through
and
approving
it
as
an
english
approver
or
another
localization
approver.
A
And
moving
on
savita
had
written
this
and
asked
me
to
read
it
out
is
that
the
sig
doc
sub
project
is
planned
to
meet
on
december
3rd
at
2
pm
eastern
for
the
first
time,
so
that
is
a
thursday
and
they'll
be
focusing
on
improving
documentation,
as
it
relates
to
kubernetes
security,
creating
a
security,
hardening
guide,
cks
materials
and
so
on.
So
if
you're
interested
please
come
and
join
them,
there
is
a
mailing
list
linked
in
the
agenda
and
once
you
subscribe
to
the
mailing
list,
you'll
get
invites
the
calendar
as
well.
A
So
if
folks
are
interested
in
security
and
documentation,
that
is
a
great
group
to
get
started
with,
there's
also
a
slack
channel
there
you
can
reach
out
to
cool,
and
lastly,
we've
got
a
few
more
minutes
here.
Jeffrey
I'm
sorry
to
do
this
to
you.
If
we
want,
we
can
push
to
the
next
meeting,
if
you
think
we
can
cover
it
in
a
small
amount
of
time,
we
definitely
can.
I
I'll
cover
it
in
a
small
amount
of
time.
At
the
last
quarterly
meeting,
we
discussed
making
videos
for
the
new
contributor
experience
the
first
draft
of
the
first
video
for
that
is
ready.
I
sent
an
email
to
the
mailing
list.
It's
yeah.
Obviously
the
first
video
is
going
to
be
kind
of
a
component
of
a
series,
so
it'll
make
more
sense
when
we
have
that
finished.
I
A
A
A
You're
in
a
whole
lot
of
nothing,
I
will
give
you
all
nine
minutes
back
on
your
evening
appreciate
it
thanks
a
lot
talk
to
y'all
later.