►
From YouTube: Kubernetes SIG Docs APAC meeting for 20210526
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
Cool
that
was
a
new
new,
for
me,
at
least,
is
that
announcement
about
the
meeting
recording.
B
A
Yeah
same
well
welcome
everybody!
Welcome
to
the
weekly
or
I
guess
this
is
the
monthly
apac
friendly
meeting
for
sick
docs.
I'm
jim
angel,
one
of
your
co-chairs-
and
I
was
just
caught
totally
off
guard
by
my
zoom's
automation,
saying
that
we
are
going
to
be
recording.
A
A
B
B
A
A
A
All
right,
moving
on
to
release
updates
release
122.
I
saw
victor
this
morning,
does
not
look
like
he's
able
to
join
the
car
right
now.
As
far
as
I
know,
we
are
green
from
a
release
perspective
and
chris
you're
shadowing
correct
yep.
C
Okay-
well,
I
I
just
put
it
in
it's:
the
integration
branch
is
healthy,
47
enhancements
need
docs
and
where
we
basically
contacted
everyone
so
far
to
to
ask
them
to
open
a
blank
pr,
placeholder
pr
and
you
know
to
start
the
docs
process
moving
so
far,
nine
pr's
ready
for
review
six
drafts
and
one
merged,
so
that's
kind
of
the
status
for
right
now.
We've
we've
been
in
touch
a
lot
too.
It's
just
still
early
on.
C
A
C
A
Five
now
it
looks
like
yep
cool
things
are
rolling.
I
always
I
feel
like
it's
a
repeated
trope,
at
least
in
sig
docs,
but
it
does
seem,
like
things
are
a
little
slower
early
on
and
then
everything
gets
caught
on
fire
towards
the
end
there
so
week,
five
I
feel
like
without
even
looking
at
the
status
I
feel
like.
We
can
assume
it's
healthy,
but
it's
awesome
to
get
the
details.
It
seems
like
we're
definitely
on
track.
C
A
All
right
moving
on
to
the
issues
and
prs,
so
I
only
had
one
carryover
from
last
week
I
wasn't
able
to
attend
the
sig
docs
meeting,
but
I
did
send
out
to
the
sig
doc's
mailing
list
kind
of
starting
the
discussion
around
switching
over
from
the
master
branch
to
the
main
branch.
The
new
github
default
just
to
go
over
a
little
bit
more
details
here.
I
don't
want
to
spend
a
ton
of
time.
I'd
really
hate
to
dwell
on
this,
especially
if
this
is
already
covered
in
last
week's
meeting.
A
A
Once
we
have
those
merged,
we
can
start
to
make
a
plan
a
little
bit
more.
I
guess
a
plan
on
more
of
the
exact
dates
and
deadlines
of
when
we're
going
to
make
the
switches
over.
I
know
talking
to
victor
the
release
lead.
We
want
to
get
this
in
sooner
rather
than
later,
so
we're
not
kind
of
stumbling
on
each
other
here
towards
the
tail
end
of
the
release.
So
it
is
a
top
priority
of
mine.
A
I
just
wanted
to
clarify
that
we
haven't
talked
dates
yet
because
I
want
to
get
the
prereqs
done
and
merge
prior
to
talking
dates,
because
that's
going
to
be
the
first
kind
of
priority
zero
step.
If
you
will
before
moving
on
any
questions
or
comments
around
that
rename
or
what's
all
involved.
A
Yeah,
definitely,
let
me
see
if
I
can
pull
up.
A
So
in
the
the
link
that
I
sent
there's
this
really
handy
link.
I'm
saying
the
word
link
it's
on
here,
but
there's
a
really
handy
url
for
actually
doing
the
change
over
from
kubernetes.dev,
so
I'll
take
a
kind
of
a
meta
step
back
and
explain
that
kubernetes.dev
has
been
led
by
contrib
x
as
the
kind
of
website
for
contributor
resources.
So
a
lot
of
the
contributor
scheduling,
planning
things
of
that
nature.
That's
the
clear
delineation
between
kubernetes.dev
and
kubernetes.io.
A
A
A
your
own
github
account
right
now
and
you
were
to
create
your
own
repository.
The
default
branch
in
that
repository
would
be
set
as
main,
and
so
what
is
in
this
interesting,
I
guess
predicament
between
switching
these
branches
over
is,
if
you're,
let's
say
github,
for
example,
the
company.
You
can't
make
everyone's
branch
change
without
impacting
ci
cd
systems,
deployment
systems,
code
bases,
other
things
referencing
that
same
code
base.
A
I
view
this
change
as
being
incredibly
low
risk.
I
think
sig
docs
is
one
of
the
the
early
changers
in
the
overall
kubernetes
org
for
this
initiative.
There
was
some
testing
already
done
and
I
want
to
say,
testing
infra.
I
think
I
just
saw
another
post
of
some
other
sig
doing
this
change
as
well.
A
Does
that
answer
your
questions
about
what
we're
doing?
Why
we're
doing
or
how
we're
doing
it.
B
Yeah
we've
got
a
bunch
of
stuff
going
on
to
do
that
internally,
on,
like
in
our
company
as
well.
It
was
nice
to
see
github
finally
make
that
switch.
It
took
them
a
few
months
after
the
whole
movement,
but
yeah.
A
Yeah
yeah
definitely
so
yeah,
really
just
general
alignment
and
there's
other,
like
you
think
about
the
kubernetes
kubernetes
main
repository,
the
amount
of
tie-ins
and
the
amount
of
sprawl
and
dependency.
That's
going
to
be
a
lot
more,
a
lot
more
challenging
to
migrate
over
than,
for
example,
the
website.
So.
C
So
will
all
that
will
the
defaults
just
like
if
you
do
a
new
clone
new
fork
and
clone?
Will
you
just
get
that
will
be
the
default
and
if
you
go
forward
and
you
just
you-
know,
click
and
don't
change
anything,
it
would
like
your
pull.
Request
would
go
there
and
all
that
kind
of
stuff
by
default.
Is
that
how
it
will
work.
A
Correct
and
I'm
not
too
sure
exactly
what
gets
left
over
if
there
is
still
a
master
branch
in
that
repository
or
not.
I
would
imagine
maybe,
for
some
time
being.
I
know
for
a
fact
I
forget
which
repo
I
was
working
out
about,
maybe
community,
I
can't
recall,
there's
one
I
was
working
out
of
where
I
had
a
fork
that
previously
was
set
to
master,
and
so
I
went
to
it.
I've
created
a
branch
I
made
some
changes.
I
committed
it
back
up
when
I
went
back
to
the
website.
A
I
realized
that
the
changes
were
against
master
and
not
main,
and
so
it
didn't
appear
up
for
a
pull
request
and
I
had
to
switch
my
branch
and
switch
to
their
upstream
main,
create
the
branch
off
of
that
re-push
it
and
was
pretty
much
good
to
go.
So
there
were
some
issues,
but
I
would
say
that
if
you're
aware
that
this
change
is
happening,
you'll
see
some
of
the
errors
that
get
spits
out
at
you
and
really
kind
of
connect.
A
A
Cool
and
then
there
is
some
instructions
as
well
in
that
link
that
I
sent
out
about
changes
post
rename
as
well
as
in
the
email
that
I
sent
out,
updating
your
local
clone
to
to
rename
a
branch
there
in
in
the
email
that
I
sent
out.
So
let
me
I
already
already
hit
that
link
there.
Okay,
yes,
you
see
a
couple
things
worth
considering
in
my
email
impacts
the
docs
release
cycle,
which
victor's
already
mentioned
localization
efforts.
A
So
I
haven't
heard
much
from
that
standpoint
and
then
impact
inflate
pr
is
a
master
branch
and
then
impact
to
folks
doing
local
dev,
which
would
be
updating
your
local
clones
and
then
that
url
brings
you
to
the
document
to
to
switch
over
that
branch.
A
A
Sounds
good
cool,
so
yeah
look
for
the
dates
once
we
get
those
pre-flight
pr's
merged
or
the
non-disruptive
pr's
merged
and
we'll
go
from
there.
A
All
right:
well,
we
had
a
pretty
light
agenda.
The
next
topic
area
is
discussion,
but
there's
no
content
in
there
so
with
the
smaller
audience,
I'm
happy
to
open
this
up.
If
there's
any
other
things
that
folks
would
like
to
talk
about
whether
it's
issues
in
pr's
or
general
discussion,
there's
not
a
ton
of
content
and
if
y'all
have
nothing,
I'm
happy
to
cut
this
a
little
early.
C
I
I
just
quick
question
about
issues.
I
don't
want
to
point
out
a
particular
show
I'm
talking
about,
but
in
general,
when
someone
files
an
issue
and
then
something
gets
done
to
to
basically
take
care
of
that
issue
is:
does
the
original
person
posting
and
have
to
agree
that
it's
been
done
or
how
does
that
ultimately
get
closed?
The
issue.
A
Yes,
so
I
feel
like
this
might
be
a
loaded
question
a
little
bit
by
your
intro,
but
but
I
withhold
judgment
there
and
what
I
will
say
is
that
usually,
when
there's
a
pr
that
fixes
an
issue
you'll
have
in
the
description,
you
know
fix
this
colon
pr
number.
So
when
the
pr
does
merge,
the
issue
automatically
closes
now,
whether
not
that
satisfactory
to
the
original
issue
opener.
I
don't
think
I've
really
came
across
like
reopening
the
issue
and
re-having
another
conversation
beyond
there.
A
You
know.
I
think
that
that
I
haven't
seen
a
lot
of
scenarios
where
the
original
issue
opener
wants
to
continue
reopening
the
issue
or
repoking
at
the
issue.
Once
there's
a
resolution
saying
that,
like
I
said,
I
feel
like
there's
a
loaded
scenario
here,
happy
to
go
into
details
happy
to
not,
but
generally
it
seems
like.
I
have
an
issue.
I
have
a
solution
pr.
It
fixes
that
issue
it
merges
and
it
closes.
The
issue
is
the.
C
Issue
with
some
more
details,
yeah,
it
was
kind
of
a
general
issue.
It
said
you
need
to
cover
this
topic.
This
topic
isn't
covered
and
then
something
was
done
to
cover
that
topic,
but
then
the
person
said
well,
I've
moved
on
I'm
not
really
looking
at
that
anymore.
A
Yeah
and
it
sounds
like
in
that
scenario,
I
would
honestly
if
I
were
to
be
pr
wrangling
or
going
through
and
seeing
that
issue
I
would,
I
would
go
through
and
most
likely
close
it
if
it
were
to
be
reopened.
Just
given
the
fact
that
anyone
can
open
a
pr,
anyone
can
open
up
additional
issues
link
back
to
it.
I
don't
see
any
harm
in
closing
the
pr
or
closing
the
issue
in
a
friendly
way.
A
There's
also
the
feta
bot,
which
will
go
around
and
freeze
issues.
I
think
it's
30
days
and
90
days,
but
it
might
be
90
days
and
180..
I
forget
the
actual
time
and
rotten
stale
and
rotten
yeah
yeah.
So
there
is
that
veda
bot
that
will
go
around
and
say,
hey
look.
This
is
still
there,
you
know
life
cycle
rotten
and
it
will
ultimately
close
after
a
certain
amount
of
time.
C
B
Also
is
I've
gone
through
and
like
assigned
myself
push
to
pr
and
then
usually
like
I'm
still
not
sure
about,
like
the
k,
the
kids
plot,
but
it
seems
like
once
you
assign
yourself
to
an
issue
at
some
point,
you're
able
to
close
the
issue
yourself,
but
that
doesn't
always
seem
to
pan
out.
Sometimes
I
get
an
error
saying
you
need
to
be
a
contributor,
because
I've
gone
through
seen
some
issues
where
the
issue
has
been
fixed
but,
for
example,
the
person
submitting
the
pr
didn't
use
the
word
fixes
or
they
used
the
wrong
syntax.
B
So
it
didn't
auto
close.
So
if
I
assign
myself
and
then
I
try
and
close
it
right
away,
it
doesn't
seem
to
work.
It
says
you
have
to
contribute
it.
So
I
think
there's
some
criteria
like
if
you
push
the
commit
in
the
pr
that
reference
that
issue
then
you're
able
to
close
it.
But
what
I've
been
doing
is
I've
just
been
tagging
people
who
have
access
and
asking
them
to
verify
it's
been
closed,
but
yeah
I
mean
there's.
B
C
Okay,
that
sounds
good.
I
was.
I
was
just
curious
about
the
process.
I
you
know.
I
haven't
been
doing
this
for
very
long
with
this
project
and
I'm
just
curious
every
time
I
stumble
into
something
where
I'm
not
sure
what
the
hell
the
process
works.
I
just
ask
yeah.
A
And
hopefully
answer
your
question,
I
think
really,
especially
with
open
source
and
and
the
community
and
all
that
good
stuff.
I
really
lean
on
taking
action
very
friendly
in
a
sense
of
I
see
no
problem
in
closing
issues,
cleaning
up
owner's
files,
making
comments
on
pr's
weather,
not
to
merge
them,
and
I
feel
like
making
action
and
actionable
items
or
requests
or
actions
upon
the
actual
issues
or
pr's
are
going
to
be
beneficial.
A
The
overall
direction
of
the
open
source
community
we're
talking
about
github,
you
know
like
issues
can
be
reopened
whatever
and
at
the
end
of
the
day,
we
want
to
make
sure
everyone's
getting
work
done
and
being
productive.
And
you
don't
know
what
folks
are
going
through
and,
like
I
said,
approach
it
with
as
you'd
like
to
be
treated
type
mentality,
and
I
feel
like
you
can't
go
wrong.
B
Yeah
I
keep
seeing
like
especially
pr's
are
like
people.
You
know
that
the
pr
or
the
issue
isn't
assigned
everyone's.
Like
is
someone
working
on
this.
I
want
to
work
on
this.
Can
I
work
on
this?
It's
like
dude,
it's
not
a
sign
like
like.
There
was
even
one
where
I
you
know
I
I
was
thinking
about
working
on
it,
but
I
purposely
hadn't
assigned
myself
because
I
hadn't
started
and
then
I
get
a
message
saying:
are
you
working
on
this?
B
I
want
to
take
it
like
dude
and
there's
so
many
issues
like
that
where
people
are
so
hesitant
to
actually
like
touch
it,
I'm
just
like
all
right.
I'm
taking
this
we're
gonna
do
this
like
this
is
annoying
there's
a
lot
of
tiny
little
issues
on
the
website,
repo
that
just
takes
like
five
minutes
to
push
a
fix
and
get
done.
A
Yeah
yeah,
definitely,
I
will
say
one
caveat
to
that
is
there
is
a
no
cookie
looking
policy
in
sig
doc
so
that
what
they
mean
by
that
is
you
can't
lick
the
issue
and
say:
oh
I'm
claiming
this.
You
know
licking
the
cookie
to
claim
it's
yours.
You
can't
lick
an
issue
and
say
I'm
gonna
work
on
this.
You
know
next
week
or
two
weeks
from
now
we
definitely
value
prs
and
contributions
over
you
know
assigned
issues.
If
you
will.
C
Yeah
yeah,
that's
the
kind
of
conversation
I
was
looking
for.
Actually
you
know
to
to
understand
how
that
process
works
because
I
didn't
claim
the
thing
beforehand.
I
did
the
work
and
then
kind
of
went
back
later
and
didn't
and
tried
to
say,
hey.
I
did
this
and
you
know
anyway
yeah
it's
good
to
understand
how
the
process
works
and-
and
I
I
think
that
people
bend
over
backwards
to
be
kind
which
is
really,
which
is
really
a
good
thing-
that
I've.
A
B
No,
I'm
good
for
the
pr
wrangler.
Do
you
like?
What's
easier
tagging
on
github,
like
on
the
actual
pr
or
messaging
into
slack
or
both.
A
So
the
pr
wrangler,
as
the
role
has
like
an
actual
description
on
what
to
do
is
over
searches.
I
think
you
go
from
searching
smaller
pierre's,
going
all
the
way
to
larger
pr's
and
kind
of
grok
over
the
open
pr's
that
are
going
on
right
now.
A
If
you
need
my
direct
attention,
the
best
way
to
get
a
hold
of
me,
specifically
I'm
not
talking
about
pr
wrangling
in
general
me
specifically
get
or
a
slack
direct
message
is
the
best
way
to
get
a
hold
of
me,
but
that
doesn't
mean
any
pr
ring,
I'm
not
saying
any
pi
wrangler
just
dm
them
and
it
go
there.
But
if
there's
something
that
needs
direct
attention
feel
free
to
reach
out
to
me
directly.
A
Otherwise
there
is
a
on
the
kubernetes
repository
and
let
me
just
pull
this
up
here.
There
is
a
channel
with
sig
docs
maintainers
on
it
and
usually
the
pr
wrangler
is
active
there,
so
the
channel
is
called
sig
dash,
docs
maintainers
and
the
conversations
around
maintainer
specific
topics.
So
if
you
want
a
pr
review
over
your
pr,
you
can
definitely
call
out
and
sync
doc's
attention
to
it,
but
then
there
is
the
maintainers
track
there.
If
you're
talking
more
procedural
policy,
administrative
type,
questions.
B
A
In
my
personal
opinion,
this
is
not
like
an
official
sig
docs
posture
or
anything
like
that,
but
my
personal
opinion,
if
you've
had
it
open
for
a
significant
amount
of
time,
I
would
start
to
reach
out
to
folks.
If
you
just
open
it
today,
I
don't
think
it's
necessary
someone's
going
to
come
across
it.
We
have
very
active
tech,
leads
on
our
group
channel
and
I
feel
like
someone
will
eventually
merge
it,
especially
a
simple
fix
like
that.
A
If
it
has
been
open
for
a
significant
amount
of
time,
I'll
leave
significant
to
your
interpretation
of
it
feel
free
to
start
bugging
folks,
then
I
I
see
no
problem
in
that,
but
but
you
know
opening
a
pr
then
immediately
pinging
someone's.
I
feel
like
not
the
best
out
of
kid.
C
A
You
know
I
really
feel
like
some
of
these
smaller
sessions
are
incredibly
valuable
because
you
get
more
of
a
direct
interaction
with
different
folks,
like
I
feel
like
having
the
three
people
in
this
meeting
here.
I
can
address
both
of
you
directly,
almost
I'm,
not
speaking,
broadly
generally,
to
the
entire
group.
So
we
can
go
through
the
agenda.
We
can
talk
about
hot
topics
and
it
definitely
serves
a
purpose,
a
little
different
than
the
traditional
weekly
meeting
and
I
enjoy
it.