►
From YouTube: Kubernetes SIG Docs monthly APAC meeting for 20201125
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,
hey
you
ching,
just
you
and
I
right
now
for
the
sig
docs
aipac
meeting
today
is
november
24th.
It
is
5
p.m,
pacific
or
1
utc,
I'm
jim
angel,
the
sig,
doc's,
co-chair
and
and
I'll
help
wrangle
wrangle
the
agenda
for
today.
A
So
first
of
all
any
new
contributors
yuching,
it's
the
first
time
meeting
you
are
you
new
to
contributing
to
docs
or
are
you
from
different
areas
of
the
the
kubernetes
organization.
B
No,
I'm
I'm
the
user
and
I'm
interested
in
coordinates,
and
I
am
I'm
trying
to
do
some
contribution
vision
to
a
community,
but
everything
for
me,
yeah,
I'm
a
newcomer
or
for
all
the
sauce.
Yeah
awesome
welcome
happy
to
have
you.
What
is
your
native
language?
B
My
name
is
honey.
I'm
coming
from
china,
okay,
perfect.
A
There's
definitely
a
lot
of
there's
definitely
a
lot
of
chinese
contributors
as
well
as
the
chinese
localization
team
that
helps
out
with
that.
I'm
not
sure
if
you've
had
a
chance
to
look
at
some
of
the
chinese
documentation,
but
also.
A
B
A
A
Yeah,
I
would
recommend
joining
that
group.
Definitely
you'll
be
able
to
to
ask
them
where
you
could
help
and
if
it's
easier
for
you
to
communicate
in
chinese
as
opposed
to
english,
you
could
talk
there
as
well
in
your
native
language
and
and
actually
chi
ming
who
just
joined
now
is
also
one
of
the
contributors
for
the
chinese
localization.
So
you
might
be
able
to
speak
more
about
that.
A
C
Yeah,
no,
I
first
time
joined.
I
attended
the
meeting
last
week
at
a
kubecon,
been
writing
for
years
spent
a
bunch
of
years
at
cisco,
then
ibm
more
recently,
I've
been
working
on
some
technical
documentation
and,
frankly,
having
worked
with
a
bunch
of
open
source
as
well
as
intersource
projects
over
the
last
few
years.
C
A
Awesome
welcome
so
we
have
two
new
contributors
to
the
call
tonight
and
our
this
morning,
depending
on
what
side
of
the
world
you're
on
and
appreciate
you
joining
is.
Is
there
any
questions
since
we
have
you
know
smaller
audiences,
any
questions
we
could
help
you
with
as
far
as
getting
started.
C
Well,
I'll,
probably
just
listen
for
now
it
was
a
great
talk.
Last
week
at
kubecon,
I'm
familiar
with
that
whole.
You
know
a
workflow
right.
I've
been
doing
some
documentation
on
another
open
source
project
using
hugo
markdown,
github
netlify,
so
on
and
so
forth.
So
I'm
familiar
with
that
pipeline.
I
guess
what
I'll
start
doing
is.
Jim
is
just
looking
at
some
of
those.
C
A
Definitely
yeah
you're
more
than
welcome
to
take
a
look
at
the
open
issues.
Also,
if
you're
having
a
hard
time
getting
started
or
figuring
out,
you
know
what
an
area
to
get
started
in
would
be
feel
free
to
reach
out
to
us.
People
are
very
active
on
slack
and
very
responsive
there
as
well.
So
as
you
get
started,
leverage
to
lack
it
to
the
most
of
your
ability
and
there's
a
lot
of
folks
willing
to
help
out.
C
Absolutely
yeah
terrific
saw
that
so
that's
great.
Thank
you.
A
All
right
so
moving
on
to
our
agenda
here,
it's
a
pretty
light
agenda,
didn't
have
a
ton
on
the
agenda
to
talk
about,
but
as
far
as
updates
and
reminders,
this
week's
pr
wrangler
is
nobody.
So
for
those
that
are
new,
we
have
a
weekly
pr
wrangler
shift.
So
this
is
somebody
in
the
docs
community
who
is
an
approver
and
the
goal
of
a
pr
wrangler
is
to
wrangle
pr.
A
A
So
since
it
is
the
u.s
thanksgiving
holiday,
we
have
no
one
scheduled
for
a
pr
wrangler
shift,
but
next
week
we
have
tim
bannister
sf
tim
as
the
pr
wrangler
in
the
meantime,
if
you
anyone
needs
any
approval
or
any
sort
of
help
or
assistance
with
prs,
there's
always
the
sig
docs
channel
to
reach
out
to
for
more
folks
or
more
eyeballs
as
needed,
and.
A
Nice,
no,
I
appreciate
that.
Thank
you
and
I'll
update
the
schedule
after
this
call.
A
A
C
Hey
jim,
are
those
are,
do
we
have
pointers
to
those
pr's
again,
I
just
sort
of
in
the
interest
of
understand
how
this
whole
process
might
might
work
are
those
available
somewhere.
I
guess
they
would
be.
A
The
release
itself,
as
it
pertains
to
sig
docs,
is
an
incredibly
monstrous
task
that
could
take
an
entire
hour
just
talking
about,
but
in
short,
there
is
a
small
subset
of
docs
that
works
with
the
release
special
interest
group
and
makes
sure
that
as
new
enhancements
and
new
features
come
into
kubernetes
that
they
get
documented
properly
and
appropriately,
as
well
as
any
content
that
is
needing
to
be
scaled
out.
Refreshed
updated
as
part
of
the
release
cycle
is
also
in
scope
for
that
team.
A
There's
a
separate
team
assisting
with
the
release,
but
occasionally
like
now
the
lean
on
sig
docks
for
reviews,
assistance
as
we
approach
deadlines
and
such.
C
A
The
reason
I'm
doing
this
is
this
is
in
a
complete,
deep
dive
into
what
the
sig
release
team
does
as
it
pertains
to
docs,
and
it
has
pretty
much
a
blow-by-blow
of
what
actually
happens
on
the
box
team
from
a
release
standpoint.
A
A
A
And
before
I
continue,
is
it
you
ma.
E
E
E
A
A
And
then
also
in
addition
to
the
main
sig
docs
channel,
there
is
a
different
localization
channels
if,
if
there's
a
specific
localization
you're
interested
in
contributing
to
or
helping
out
with-
and
I
know
it's
a
ton
of
information
all
at
once
about
contributing,
but
I
would
say
the
number
one
thing
is
just
to
ask
questions.
Everybody
is
here
to
help
everybody
else
succeed.
So
if
you
have
any
questions
or
are
confused
about
where
to
start
going
into
slack
and
asking
in
those
channels
is
100
appropriate
and
encouraged.
A
All
right,
moving
on
to
the
blog
update,
we
don't
have
anyone
from
the
blog
team
joining.
As
far
as
I
know,
things
are
slowing
down
for
the
holidays,
but
overall,
the
health
of
the
blog
is
healthy
health.
The
blog
is
healthy,
it's
doing
well
and
for
the
new
contributors
here,
as
we
talk
about
some
of
the
different
about
the
different
areas
of
sig
docs,
there's
a
different
area
that
actually
supports
and
manages
the
kubernetes
blog.
This
is
our
case.
A
Dot
io,
slash
blog
resource
and
what
they
do
is
work
with
the
different
vendors
case
studies,
the
different
overall
blogs
that
you'd
see
on
kubernetes
website,
and
they
focus
on
reviewing
those
and
releasing
them
on
a
schedule.
A
All
right
moving
on
to
the
issues
in
prs,
so
I
called
this
release
things.
These
aren't
pr's
that
actually
have
issues.
These
were
two
of
the
pr's
that
anna
identified
in
the
sig
docs
channel
earlier
today
that
needed
just
additional
additional
reviewers
to
look
at
for
some
of
the
folks
who
are
new,
maybe
not
as
comfortable
with
reviewing
feel
free
to
click
on
those
links
and
just
see
what
kind
of
interactions
are
happening
here
just
for
some
context.
For
for
folks
that
are
new.
A
This
is
where
somebody
on
the
release
team
or
somebody
who
created
the
enhancement
or
feature
has
created
the
technical
documentation
for
that
enhancement.
They've
opened
up
a
poll
request
and
now
between
a
technical
review
and
docs
review
for
overall
styling
and
content.
We're
looking
to
merge
this
into
the
new
development
branch
for
the
upcoming
release
in
december.
C
Jim
just
a
general
question:
another
open
source
project,
I'm
working
on
actually
using
the
code.
You
know
I've
set
it
up
in
a
virtual
environment,
I'm
running
through
it's
like
documenting
apis
and
things
like
that.
Do
we
do
that
kind
of
thing
here,
or
do
we
loosely
couple
ourselves
with
the
developers
or
coders
or
in
general?
How
might
that
process
work?
And
I
guess,
there's
multiple
different
ways
of
looking
at
this.
C
Right
and
then
documenting
that
or
working
with
this,
you
know
this
sort.
You
know,
let
me
backtrack
for
a
second,
yes,
I'd
set
up
a
kubernetes
environment
and
say,
for
example,
if
I
was
updating
the
api
documentation,
I'd
want
to
set
up
an
environment,
so
I
could
call
those
apis.
Look
at
the
request.
Look
at
the
replies
so
on
and
so
forth.
A
C
I
guess
it's
more
about
what
would
be
the?
How
would
we
go
about
if
we
wanted
to
document
say
a
new
set
of
apis
who
provides
that
information
and
or
do
I
take
those
new
apis
set
up
a
virtual
environment
somewhere
and
then
run
those
apis
myself
and
then
see
what
comes
back
and
then
you
know,
be,
I
think,
more
confidently
and
knowledgeably
document
that.
A
Yeah,
so
that's
a
little
bit
of
a
tricky
question.
I
I
think
that's
more
of
an
advanced
topic
as
far
as
contributing
goes,
there's
a
few
different
areas
and
pitfalls.
A
That's
why
I
don't
want
to
generally
throw
a
blanket
out
there
and
say
here's
like
one
way
to
do
everything,
because
it's
really
not
not
the
case,
but
traditionally,
I
would
say:
there's
two
overall
big
areas
of
sig
documentation
or
sig
docs
and
the
one
being
just
your
general
content
that
you
see
on
case.io,
but
there's
also
reference
generated
documentation
against
the
api
server
and
some
of
the
components
like
cube
cuddle
and
some
of
the
other
utilities
there.
That
is
just
generated.
C
A
C
A
A
C
A
All
happen
in
the
code
base
itself
for
the
reference
generated
api
documents,
but
for
the
overall
general
case.io
docs,
those
are
usually
generated
in
our
kubernetes
website.
Repository
they're
they're
split
from
the
code
base
and
if
you
didn't
want
to
do
any
sort
of
testing
or
tinkering
one
example
being
I've
contributed
in
the
past
to
the
documentation
that
covered
dealing
with
mini
cube.
So
I'm
not
sure
if
you're
familiar.
A
A
Cool
not
a
problem
and
as
far
as
your
general
developer
environment,
from
contributing
to
docs,
there
is
a
make
file
and
I
think
the
kubernetes
readme,
the
kubernetes
website
readme,
will
cover
using
that
make
file
to
spin
up
containers
to
host
the
site
locally.
So
you
can
make
your
changes
locally,
see
what
that
looks
like
before
opening
the
pull
request
to
kick
off
all
of
the
automation.
C
A
A
D
Speaking
of
trs,
which
may
need
some
attention
from
the
from
the
whole
team,
maybe
I
can
share
the
screen.
D
D
What
I
want
to
bring
up
is,
I
can
feel
some
pressure.
We
want
to
get
this
merged
as
soon
as
possible.
D
D
We
design
our
own
groups
of
resources,
or
we
just
group
the
resource
tabs
by
their
api
groups.
How
do
we
organize
the
common
parameter
pages?
How
we
can
allow
the
user
to
navigate
through
the
resource
tabs
more
easily?
So
so
things
like
that
need
some
more
discussion,
so
I'm
trying
to
raise
some
attention
to
the
team.
D
The
reason
is
that
we
can
easily
get
anything
merged
in,
but
if
the
thing
is
already
there
kick
it
out,
it
would
be
difficult.
Moving
it
around
would
be
difficult.
It
involves
a
lot
of
redirects
a
lot
of
changes
and,
although
some
of
those
changes
have
to
be
replicated
to
each
localization
team,
that
would
be
terrible
so
so
that
that's
something
I
want
to
bring
out.
D
D
So,
basically,
today
we
have
api
references
for,
for
example,
1.19
the
problem
we
we
see
from
this
api
reference
is
it's
a
huge
page.
It's
a
single
page
and
the
look
and
feel
of
the
reference
is
different
from
the
rest
of
the
website.
D
People
doesn't
like
that,
and
there
are
some
feature
gaps.
For
example,
you
won't
be
able
to
search
across
documentation
using
some
search
engine,
so
that's
something
we
can
improve.
So
philip
has
started
an
effort
so
that
these
documentations
are
not
generated
directly
into
html
is
generated
into
markdown,
so
that
the
markdown,
when
rendered,
will
look
the
same
way
as
the
rest
of
the
website.
That's
that's
a
pretty
good
work,
but
there
are
a
lot
of
things
to
be
solved.
Here
is
a
huge
project.
A
Yeah
that
makes
sense
to
me-
and
I
appreciate
you
bringing
this
up
as
far
as
the
the
pressure
to
get
this
merged,
and
I
don't
know
all
the
details
on
this
so
I'll
have
to
check
with
zach
and
see
if
I'm
missing
anything
here.
But
I
do
know
that
the
individual
creating
these
this.
This
pr
is
part
of
the
google
season
of
docs
20
season,
and
I'm
not
sure
when
that.
Yes,.
D
A
A
Right
right,
I
completely
agree,
so
I
just
pulled
up
some
deadlines
here
and
it
looks
like
the
project
deadline
is
around
december
3rd
through
the
10th
which
lines
up
with
your
expectations,
or
we
both
kind
of
assumed
that
the
pressure
is
probably
coming
from
the
google
season
of
docs
timeline,
but
you're.
Absolutely
correct,
though,
there's
no
reason
to
force
something
that's
going
to
break
or
cause
a
lot
of
a
lot
of
other
challenges
just
for
the
sake
of
that
deadline.
A
At
the
same
time,
I
want
to
make
sure
that
it
has
the
full
attention
it
needs,
so
we'll
definitely
raise
this
up.
Would
you
mind
posting
a
link
to
this
in
the
doc's
channel
chat
and
we
can
definitely
boost
it.
D
Okay,
I
will
do
that
later.
Okay,
perfect,
okay.
Another
thing
I
want
to
mention
is
about
localization,
I'm
sharing
a
screen
full
of
chinese.
D
D
Sometimes
people
will
read
some
pr's
that
are
pretty
small
fix
a
table
fix
a
link,
but
if
we
merge
those
kinds
of
pr's,
we
will
lose
track
of
the
upstream
changes.
Today
we
are
checking
with
the
changes
using
timestamps
if
the
localized
page
is
updated,
but
not
fully
synchronized
with
upstream
page.
That
will
be
a
problem.
D
We
can
never
know
in
the
future.
What
happens
in
upstream
that
have
not
been
synchronized
to
to
chinese
localization,
so
we
have
put
up
a
rule
here
whenever
you
want
to
fix
even
a
small
change
in
a
page,
you
have
to
make
sure
the
whole
page
is
still
well
synced
with
the
english
main
site.
D
D
A
D
Yes,
yes,
or
else
it
will
be
a
casual
update.
It
will
make
the
change
tracking
very
difficult.
A
D
I'm
only
focusing
on
the
chinese
localization,
maybe
maybe
we
can
learn
from
other
organization
teams
as
well.
How
are
they
handling
these
kind
of
problems.
A
Cool
yeah-
I
do
know
that
this
specific
problem,
as
far
as
what
to
do
after
you
get
started,
there's
a
lot
of
help
on
the
kubernetes
contributing
to
kubernetes
guidelines
about
getting
started
with
the
localization.
There's,
not
a
lot
of
information
out
there,
how
to
maintain
a
localization
so
like
issues.
A
Definitely
come
up,
I
wonder,
are
you
part
of
or
have
you
attended
any
of
these
the
sub
project
for
localization
groups.
A
I
don't
blame
you
for
not
joining
that
one
nice
yeah.
So
what
I'm
thinking
is.
I
can
definitely
carry
this
to
the
next
meeting,
just
raising
general
awareness
and
those
two
issues
you
brought
up,
but
I
think
that
this
might
be
something
where
the
sub
project
for
localization
could
help
out
a
whole
bunch,
making
sure
that
all
the
localization
teams
are
synchronized.
A
Really.
What
we're
talking
about
here
is
there's
another
sub
project.
Much
like
there's
a
sub
project
for
blogs.
Much
like
there
is
a
subgroup
for
the
release
team,
there's
a
subgroup
for
localization
right
now,
and
it's
a
it's
a
temporary
subgroup
or
a
working
group
with
the
pure
focus
on
standardizing
how
localization
happens
and
how
to
maintain
it
moving
forward.
So,
as
I
was
mentioning
earlier,
there's
a
lot
of
great
content
about
getting
started.
A
A
D
Okay,
the
last
thing
I
want
to
discuss
is
about
the
generation
of
some
unpublished
apis.
So
you
know
we
have
api
references
for
whatever
resource
tabs.
We
are
using
today
say
path
deployment
the
demonstrate,
but
there
are
some
data
structures
not
well
documented,
for
example,
the
couplet
config
file.
D
Today,
in
our
documentation,
there
is
a
link
to
the
go
source
code.
So
that
means,
if
you
are
changing
a
couplet
configuration
file,
you
want
to
know
what
other
fields
you.
I
can
customize
what
those
fields
mean
you
have
to
check
source
code,
so
that's
that
makes
no
sense.
So
I
have
work
out
that
tool.
This
is
called
genref.
D
That's
proposed
here
in
the
native
c
reference
docs
as
a
pr.
This
is
a
reference
tool
for
for
the
team
to
generate
whatever
unpublished,
apis
documentation.
If
we
take
a
look
at
the
configuration
file.
D
I
got
some
reviews
from
karen
already
so
here
here
is
a
list
we
can.
We
can
generate
a
reference
for
couple
of
config,
coupe
schedule
of
config
controller
manager,
config
coolproxy
and
some
other
metrics
api
server,
config
web
for
webhook
admission,
and
even
some
could
admin
configurations
all
these
kind
of
configurations
we
can
generate.
We
generate
them
into
markdown.
D
So
we
will
have
some
references
for
couplet
config,
this
v1
bit
one
version
here:
the
couplet
configuration
all
the
fields
but
and
some
descriptions
for
them.
If
there
are
some
references
to
other
structures,
for
example,
kubelet
authentication
was
that
clinically
you
will
get
this
okay
now,
you
know
here
is
a
nested
structure.
D
What
hook
authentication
was
that
yeah?
So
so
everything
you
need
for
couplet
config
is
now
documented.
We
can
also
generate
a
reference
dock
for
other,
unpublished
apis
as
well.
So
this
is
a
new
tool
we
are
working
on
and
I
would
appreciate
whatever
comments,
reviews
suggestions
for
this.
A
D
It's
a
separate
tool:
okay,
it
yeah.
It
can
work
all
by
itself.
I
have
added
a
configuration
file
so
that
you
can
customize,
which
version
of
which
components
you
want
to
document.
A
D
It's
different
this
in
this
tool,
I'm
passing
the
gold
source
code
because
we
don't
have
upstream
json
file
supplies
to
use.
No.
The
api
reference
is
using
the
swagger.json
open
api
specification
as
the
source
data,
but
for
this
kind
of
reference
we
don't
have
that
luxury.
A
Gotcha,
that
makes
sense
so
the
other
question
that
I
have-
and
I
don't
have
the
answer
for
this-
is
it
might
be
worth
talking
to
some
of
the
people
in
sig
multi-cluster
life
cycle
and
the
reason
I
say
that
is.
I
know
I've
personally
came
across
this
exact
problem
where
it
was
like
cube,
adm
or
no,
I
think
it's
cubelet
I
was
trying
to
configure,
didn't,
have
the
configuration
I
had
to
go.
A
Look
at
the
source
code
or
the
godox
to
read
about
it,
and
when
I
wrote
multi-sig
multi-cluster
life
cycle,
their
general
opinion
was
that
they
were
moving
too
quick
to
maintain
or
keep
up
with
a
generated.
You
know
content
doc
like
this
is.
I
can't
imagine
there'd,
be
objections
to
something
like
this,
but
making
sure
that
they're
on
board
with
the
approach,
I
think,
would
be
appropriate.
D
Have
been
some
some
discussions
with
sig
multicultural
I'll,
propose
some
changes
to
their
rival
but
got
rejected.
D
A
That
gotcha
yeah,
that
makes
sense
so
yeah.
I
think
it'd
be
good
just
to
make
sure
that
they're
on
board
with
it
or
completely
signed
up
for
the
change,
and
then
we
can
definitely
raise
awareness
that
you
know.
We
need
reviews,
opinions
and
options
on
moving
forward.
With
this
pull
request,
it
seems
reasonable
to
me,
and
it
seems
like
there's
a
clear
boundary
that
doesn't
conflict
with
the
swagger
generation,
that
you
know
this
isn't
solved
with
with
the
same
approach.
So
I
guess
they
both
can
live
simultaneously.
D
Yeah
yeah,
if,
if
there
are
some
upstream
striker
digestion
file
generated,
we
can
deprecate
this
tool.