►
From YouTube: Kubernetes SIG Docs monthly APAC meeting 20200325
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,
everyone
today
is
Tuesday
March,
24th
2020,
and
this
is
the
weekly
meeting
for
kubernetes
sick
docks.
This
is
a
fourth
Tuesday,
so
we
are
meeting
at
6
p.m.
Pacific
time
and
it's
also
a
little
weird
because
daylight
savings
happened
and
it's
there's
the
right
way,
the
wrong
way
in
the
u.s.
way
and
we're
doing
it
the
u.s.
way
so
for
everyone,
who's
gonna,
show
up
in
an
hour.
A
Alright,
let's
get
to
our
agenda
our
PR
Wrangler,
our
new
contributors
know
just
as
friends
all
right.
This
week's
PR
Wrangler
is
Chi
Ming,
Thank,
You,
Chi
Ming.
Next
week's
Kia
Wrangler
is
Ryan
McGinness,
except
how
it's
not
Ryan
McGinnis
on
account
of
he
parachuted
out
of
the
project
a
while
back.
So
we
need
to
find
folks
to
replace
Ryan
in
all
of
his
PR,
and
while
we
are
looking
at
the
PR
English
schedule,
let's
see
the
last
time
Zach
Arnold
was
scheduled
for
a
shift.
He
was
a
no-show
and
I,
see
Ryan
Zack.
A
B
A
The
repo
is
currently
frozen
for
the
release,
so
please
no
one
approve
any
APRs
until
the
release
has
been
verified
and
we
thought
okay,
Doxey
template
an
update,
so
I
wrote
to
gearbox
the
contractors
doing
the
work
I
checked
in
with
them
to
see
how
how
they're
doing
in
eco
bid
19
world
and
they're
doing
okay.
They
say
that
they
aim
to
be
done
by
mid-april,
so
we're
looking
at
a
like
a
an
April
12th
April
15th
completion
date
for
the
doxy
migration.
A
A
B
So
the
quick
comment
here
is
that,
since
you
were
out
last
weekend,
is
that
our
last
meeting
is
that
we
were
going
through
the
good
first
issues
here
and
it
seemed
like
last
week
when
I
was
doing.
That
is
more
just
me
kind
of
clumsy,
around
or
good
first
issues
and
clicking
through
the
Matt.
Don't
know
what
benefits
really
were
from
that,
but
there
was
a
lot
of
discussion
around
some
of
the
PRS
that
you
know.
Some
folks
had
questions
about.
B
F
E
F
A
F
A
A
A
See
other
Docs
pieces
the
cap,
so
we
had
a
cap
open
for
a
long
time
about
what
specifically
to
do
with
third-party
content
and
dual
sourced
content
and
after
many
reviews
that
kept
us
finally
merged.
So
we
have
a
policy
in
place
in
the
documentation
now
about
how
we
handle
third-party
content
and
what
specifically
to
accept
and
to
reject
that
will
help
now
and
going
forward
for
future
PRS.
But
we
also
have
some
work
to
do
to
figure
out
what
is
there
now
and
how
to
remove
it
and
many.
A
Many
months
ago,
Amy,
you
Kasich,
if
you
remember
her,
opened
an
umbrella
issue
that
sort
of
kicked
this
whole
thing
off
and
that
umbrella
issue.
The
discussion
there
is
so
long
and
so
crowded
that
that
umbrella
issue
is
doesn't
really
serve
as
a
good
umbrella
issue
anymore.
So
I
am
going
to
write
up
a
new
umbrella
issue,
credit
Amy
with
having
done
initial
discovery
work
and
let's
continue
to
use
the
umbrella
issue,
TBD
that
I'll
open
to
track
third-party
content
that
needs
to
be
removed
and
then
start
opening
PRS
to
remove
content.
A
Also,
as
we
start
opening
PRS
to
remove
non-conforming
content,
there
may
be
some
response
that
says
whoa.
Why
are
you
doing
this?
This
should
absolutely
be
here.
No
one
asked
me
we
did
ask.
We
asked
everyone
for
a
long
time,
so
it's
not
a
question
of
whether
it's
going
only
when
and
how
so,
please
don't
spend
a
lot
of
bandwidth,
justifying
the
change
refer
them
to
the
cap
itself.
That
has
all
of
the
discussion
and
all
of
the
steering
committee
and
sync
architecture
support
there.
G
Saw
some
head
shaking
I
was
like
I
think
that
means
yes,
okay,
so
yes,
a
lot
of
thoughts
has
gone
into
what's
been
happening.
So
you
know,
we've
got
this
original
scope
of
work
that
I
started
what
seems
like
a
very
long
time
ago,
and
a
lot
of
people
gave
feedback
on
that
scope
of
work.
So
what
I
started
doing
was
coming
through
that
feedback
and
I
put
together.
G
Provided
as
a
download
through
Google
Docs
I
just
put
a
copy
there
in
the
chat
and
I've
been
kinda
messing
around
with
it,
and
one
of
the
ideas
that
came
from
the
feedback
from
the
original
scope
of
work
was.
We
can't
just
turn
over
this
project
to
a
design
team
and
expect
them
to
know
what
is
needed
because
it's
it's
very
specific
to
kubernetes.
So
what
I've
started
to
do
is
that's
harder
to
take
some
of
the
cubans
architecture.
That's
in
the
documentation,
there's
two
key
architectures
and
I
dropped
them
into
you.
G
Guys
can
click
on
that
link
if
you
want
to
see
what
I'm
looking
at
and
I
dropped
them
into
an
SVG
and
Google
like
sto
did
and
I
was
kind
of
playing
with.
How
can
I
get
this
close
enough
to
make
sense
that
if
we
did
bring
in
someone
with
some
design
skills,
they
could
not
be
starting
from
scratch,
so
that
was
from
the
advice
from
Celeste
in
Berlin
she
had
made
that
recommendation.
So
I
took
a
list
of
the
icons
in
these
two
diagrams
and
basically
said.
G
It's
been
a
very
humbling
experience
with
my
mediocre
design
skills
but
I'm
hoping
to
finish
this
this
week
and
at
least
have
a
draft
and
then
maybe
see
if
we
can
get
other
people's
feedback
and
then
maybe,
if
we
get
it
close
enough,
we
could
bring
in
an
actual
graphic
design
artist
to
just
focus
on
fixing
the
icons
and
the
graphical
pieces
and
then
have
something
like
Sto.
So
that's,
that's
part.
G
It
still
has
the
style
guidelines
too,
and
they
put
their
diagram
creation
guidelines
below
the
style
guidelines.
So
you
have
to
potentially
look
at
where
to
include
the
diagram
creation
guidelines
and
then
we'd
have
to
have
a
page
called
diagram
creation
guide.
That
would
have
a
little
paragraph
as
well
as
the
SVG
artwork
like
sto
has
that
people
could
download
and
edit
with
Google,
draw
Inkscape
or
illustrator.
A
C
G
A
G
A
G
A
D
We
got
a
few
additional
blog
posts
out
last
week,
which
I
cannot
think
of
what
they
are
off
the
top
of
my
head.
We
have
a
couple
in
the
pipeline
right
now
after
the
118
release
comes
out
next
week
and
then
followed
by,
we
have
I
want
to
say
two
or
three
blog
posts
in
the
five
days
of
kubernetes
series.
A
I
remembered
the
other
thing
that
it's
important
for
us
to
discuss
as
a
community,
so
the
118
release
process
was
difficult
for
a
number
of
reasons.
One
of
the
reasons
was
that
our
default
merged
strategy
is
not
friendly
to
the
way
that
things
need
to
merge
to
keep
the
development
branch
happy.
So
Jim
opened
a
discussion
issue
to
change
our
the
websites
default,
merge
strategy
to
squash,
which,
if
you've
been
around
for
long
enough,
you
remember,
was
the
way
that
we
used
to
do
things
like
two
years
ago
and
thank
you
Jim
for
the
link.
A
A
We
were
seeing
pole
requests
with
multiple
commits
that
weren't
just
additions
of
content,
but
were
sometimes
like
revert,
commits
things
that
were
rewriting
history
and
when
those
those
commits
would
merge
into
master.
We
create
conflicts,
create
problems,
and
it
was
at
the
time
it
was
a
way
of
making
sure
that
squashed
commits
were
always
entering
the
repository
by
default.
A
That's
become
an
issue
in
the
development
branch,
for
reasons
that
Jeannie
has
laid
out
in
an
excellent
diagram
that
I
wish
I
had
opened
in
some
tab
somewhere
or
the
junii
was
himself
here
to
explain,
but
we
can
find
that,
if
you're
really
interested
in,
why
Junie
did
a
really
good
job
explaining
the
technical
details.
But
the
takeaway
is
that
it's
important
for
our
default
strategy
to
go
back
to
merge.
A
It's
going
to
be
the
friendliest
set
of
defaults
for
working
with
a
development,
a
long-running
development
branch
going
forward.
It's
on
us
as
approvers,
however,
to
make
sure
that
PRS
against
master
are
squashed.
So
approvers,
when
you
are
reviewing
a
PR
against
master,
make
sure
that
the
commits
are
squashed.
A
A
We
even
less
we
make
sure
those
commits
are
squashed.
We
will
start
seeing
the
behavior
that
we
saw
two
years
ago
and
merge
conflicts
created
where
they
didn't
need
to
be
because
we're
no
longer
squashing
by
default.
So,
yes,
again,
approvers
make
sure
that
PRS
have
been
squashed
before
you
approve
them
and
allow
them
to
merge.
B
One
thing
we
did:
oh
I
know
what
it
is.
I
recently
updated,
I
have
a
link
here
more
explaining
the
explaining
more
about
the
issues
with
the
release
process
and
why
we're
making
this
change
it's
a
little
bit
more
getting
deeper
into
the
the
whys
of.
Why
we're
doing
this,
but
I
added
a
checklist
item
I
believe
it'd
be
beneficial
for
the
entire
sigmax
community.
B
If
we
had
a
clearer
document
documented
process
of
how
to
squash
your
commits
in
the
contributing
guidelines
cited
as
a
checkbox
as
at
least
some
sort
of
pointers
how
to
get
there
before
we
make
this
change,
actually
merge,
I
think
that'd
be
a
decent
prerequisite,
bear
essential
to
have
as
well
as
maybe
potential
workarounds.
If
folks
are
not
technically
able
to
squash
them,
there
might
be
some
workarounds
there,
as
we
discussed
earlier.
A
Yeah,
that
seems
like
a
completely
reasonable
thing.
If
we're
going
to
ask
people
to
squash
their
commits,
then
at
least
providing
nominal
guidance
on
how
to
do
that
seems
totally
appropriate
there.
There
is
a
tight
workaround,
but
it
requires
right
permissions
to
use
it
and
we're
trying,
as
like
the
kubernetes
project
as
a
whole,
is
trying
to
minimize
the
number
of
write
permissions
out
there
and
I
think
as
as
a
side
effect
of
well
as
a
necessary
side
effect
of
the
way
that
we
do
things
I
think
we're.
A
A
G
So
Steve
Perry
had
put
together
this
scope
of
work
draft
about
putting
together
a
video
he
mentioned
this
I
think,
like
maybe
six
or
seven
months
ago,
I
thought
the
video
was
an
excellent
idea.
I
put
a
link
to
it
in
the
chat
and
it
might
be
good
to
add
this
to
the
cadence
of
keeping
track
of
where
it's
at
I
think
it'd
be
a
great
tool
to
you
know
someone
who
might
like
myself
who's
newer
to
PRS
and
this
whole
process
I
really
value.
This
kind
of
training
I
know
Gwen.
G
A
So
yes,
let's,
let's
talk
about
that
at
the
quarterly
review
as
well,
how
specifically
to
move
forward
and
implement
that
because
yeah,
our
last
quarterly
review
Steve,
took
that
on
and
kudos
to
Steve
for
producing
that
deliverable
so
yeah.
Let's
talk
about
that
at
quarterly
review,
I
think
we
could
make
a
couple
of
short
videos
that
would
be
well-received
about
like
how
to
squash
comments.
For
example,
things
like
that
and
Celeste
you
just
got
the
steel
in
your
eyes.
I
got
a
my
embedding
videos.
As
my
content,
there
look
I
mean.
C
A
C
E
A
A
Given
the
world
we
live
in
at
the
moment,
see
two
team
milestone:
branches,
1.17,
five
and
1.17
six
have
been
merged
into
master
one,
that
seventeen
seven
will
they're
planning
on
merging
that
into
release
one
at
17
on
March,
26th
and
they're,
looking
to
move
to
one
that
18
on
that
dates,
so
they're
keeping
a
really
tight
cadence
with
the
kubernetes
release
process
itself,
they're
marching
very
closely
behind
the
kubernetes,
quarterly
release
so
kudos
to
the
Korean
team
for
keeping
up
a
really
incredible
pace
of
localization.
So
thank
you,
Jeannie
Thank,
You
Claudia.
A
A
A
B
B
A
Ok,
let's,
let's
load
it
but
I'll
open.
The
discussion
propose
Wednesday
the
first
at
11:00
a.m.
if
that
doesn't
work
then,
like
a
second
choice
of
Friday
at
10:00
a.m.
I,
know
it's
not
ideal
for
folks.
Tim
won't
really
hate
us.
If
we
do
that.
So,
let's,
let's
try
not
to
pick
on
Tim
with
Friday
night
scheduling.
A
Ok,
but
let's
see
what
else
needs
to
be
done
there
Jim
and
Caitlin.
The
tragus
need
to
put
together
an
agenda
doc
for
the
quarterly
review
and
we
need
to
get
that
out
for
folks
to
add
changes
by
like
Friday
at
the
latest
of
this
week.
It's
not
much
time
give
folks
for
review,
but
historically
I've
found
that
it
didn't
make
a
lot
of
difference
to
have
it
open
for
a
longer
time
versus
a
shorter
one,
but
yeah.
So
we
need
to
take
an
action
item
to
produce
the
agenda.
A
B
A
A
Quarterly
review,
we
have
a
dance
break
as
a
reminder.
Everyone
can
dance
just
cuz,
I'm
enthusiastic
about
it,
doesn't
mean
that
I'm,
the
only
one
doing
it
Oh
TV,
yes,
UTC
time
in
the
agenda
docks,
that's
the
goal
of
having
to
calendar
so
TBD
is
to
when
exactly
that
will
take
effect,
but
we're
working
on
it.