►
From YouTube: Kubernetes SIG Docs monthly APAC meeting for 20210224
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,
hello
and
welcome
everybody
to
the
weekly
sig
docs
meeting
good
to
see
everyone,
I'm
jim
angel,
a
co-host
or
co-chair
of
sig
docs
and
today
is
february,
23rd
2021,
and
so
it
looks
like
everyone
here
is
returning
members
so
good
to
see
everyone
again.
Thanks
for
joining
and
as
far
as
updates
and
reminders
go,
this
week's
pr
wrangler
is
caitlin
bernard.
A
I
chatted
with
her
just
a
couple
days
ago,
and
I
know
that
she's
working
on
wrangling,
those
pr's
and
next
week
is
karen
bradshaw
or
kb
hockey
and
approvers
make
sure
you
know
your
scheduled
pr.
Wrangler
shifts.
There
is
a
link
in
the
docs.
B
Yeah
so
I'm
saying
their
status
is
yellow.
We
haven't
really
pinged
the
enhancement
owners,
we're
still
waiting
until
after
code
freeze
to
do
that
so
march
10th.
So
we
still
have
a
few
weeks,
so
we
are,
but
we
are
seeing
a
few
more
doc
prs
being
created
very,
very
slowly
so
other
than
that.
The
branch
sync
for
last
week
went
smoothly
and
was
merged
and
the
integration
branch
is
healthy,
so
yeah.
B
B
March,
it
is,
it
is
more,
more
tentative
yellow
and
since
this
this
cycle
is
a
little
different
and
how
we're
we're
still
trying
to
change
how
we
communicate
like
last
cycle,
we
would
be
pinging
the
enhancement
owners,
but
but
so
were
the
other
teams
as
well.
So
we
wanted
to
reduce
the
amount
of
of
reaches
or
touches
to
the
enhancement
owners
and
leave
it
to
a
certain
team,
and
then
the
certain
team
takes
over
so
on
march
10th
and
then
the
our
docs
team
will
take
over
with
reaching
out
to
the
enhancements
owners.
A
B
B
To
you,
so
I
have
a
few
pr's
I
want
to
talk
about.
One
is
26629,
so
there's
a
new
page
that
was
merged
onto
the
kubernetes
website.
It's
the
api
deprecation
deprecation
guide,
so
it's
out
live
on
master
and
there
is
the
pr26629
is
adding
the
pots
security
policy
deprecation
to
that
api.
Deprecation
guide
on
the
master
branch
so
just
want
to
bring
this
up
into
discussion.
I
know
I
pinged
all
the
sig
docs
lead
and
someone
else
ping.
The
sick
release
leads
on
this.
B
So
there's
gonna
be
a
lot
of
communication
on
this.
Some
feel
that
it
should
be
live
on
the
master
branch,
even
though
the
release
hasn't
is
not
here
yet
because
the
because
the
the
kkk,
the
the
code
related
pr,
has
already
merged
onto
the
master
branch.
I
saw
chi
ming,
adding
his
comments
of
that
should
be
submitted
to
the
dub
1.21
branch
and
I
think
I
think
one
of
these
sig
docs
lead.
B
I
forgot
who
mentioned
that
that
he
was
okay
with
it
going
to
the
master
branch
since
it
is
planned
out,
but
we
should
so
there's
a
lot
of
communication
about
this
and
I
think
there's
you
know
I
could
see
on
both
sides,
but
I
don't
know
where
to
go
from
here.
A
B
Yes,
so
there's
two
pr's
actually
for
about
psp
one
is
on
the.
This
is
just
this
pr,
that's
open
is
silly
just
for
the
api
deprecation
guide
and
it's
on
the
mass
targeting
the
master
branch.
A
Gotcha
yeah-
and
this
is
one
of
those
things-
that's
really
going
to
be
a
judgment
call
ultimately,
like
you
were
saying,
there's
there's
arguments
to
be
had
on
both
sides.
There.
A
A
Is
there
anybody
being
impacted
by
this
that
I'm
trying
to
see
like
what
what
the
value
is
of
this
merging
into
master
versus
going
into
121
and
going
out
the
door
when
that
releases?
Is
there
something
that
I'm
not
understanding
or
not?
Seeing
about
the
criticality
of
this
merging
into
master
versus
dev?
B
So
also,
one
of
the
reasons
why
there's
some
context
behind
here
as
well-
is
that
that
the
api
deprecation
guide
was
not.
I
did
not
sync
it
before
this
merge
was
was
this
pr
was
made.
So
there
was
no
api
deprecation
api
depletion
got
in
the
1.21
branch.
I
did
it
like
two
hours
afterwards
that
you
know
that
being
said,
that
might
have
might
have
changed
if
that
was
done.
B
If
you
know
this
pr
was
made
after
I
did
the
branch
sync
I
don't
know,
I
do
agree
that
I
believe
that
we
sh
you
know
we
talked
about
deprecations
and
how
we
should
plan
out
how
we
can
communicate
those
that
those
applications.
B
I
believe
this
is
kind
of
sidestepping
those
plants,
since
it's
gonna
be
live
on.
The
master
branch.
D
C
Okay,
by
by
conversion,
we
in
our
style
guide,
we
said
that
we
make
no
predictions
about
future
api
versions,
so
that
was
a
rule
for
the
whole
team.
But
at
this
pr
the
the
deprecation
api
page
is
breaking
that.
But
after
reviewing
the
content,
we
believe.
C
Okay,
let's
make
it
a
an
exception,
because
that
that
is
the
only
page
we
are
making
some
predictions
into
the
future.
So
if
we
are
accepting,
that
page
is
an
exception
for
the
whole
site.
Merging
it
into
master
is
not
a
big
problem.
It's
okay,
but
it's
not
the
best
option
from
my
side,
so
I
suggested
the
let's
best
put
it
into
1.21.
A
Yeah
that
doesn't
make
sense
to
recall
seeing
that
in
a
style
guide
about
you
know,
you
can't
talk
about
future
state
or
current
state,
because
that's
you
know
forever
changing.
Essentially
the
one
challenging
thing
here
and
jimmy
you,
you
I
definitely
identified
this
is
this
is
somewhat
of
a
forward-looking
document.
You
know
we're
talking
about
future
deprecations
beyond
the
current
scope.
A
Yeah,
I'm
just
trying
what
I'm
trying
to
think
about
here
is,
I
think,
no
matter
what
whether
this
goes
into
master
or
where
this
goes
into
dev
121.
It
really
is
impacting
folks
for
1.25,
and
I
know
this
is
part
of
the
initiative
to
give
folks
a
kind
of
a
further
outlook
on
the
road
map,
maybe
further
documentation,
and
so
so
I
get
the
reasoning
for
wanting
to
put
this
in
master.
A
I
really
don't
think
it's
going
to
make
that
big
of
a
deal
whether
it
goes
into
master
or
in
a
few
months
or
a
few
weeks.
It
goes
into
the
release
branch
as
far
as
impact
to
end
users.
I
think
this
is
really
gonna.
I
think
this
will
come
down
to
more
of
a
judgment
call.
A
I
think
this
page
inherently
already
violates
the
style
guide
without
this
pr
included,
and
so
it
might
be
worth
you
know,
potentially
cleaning
up
the
style
guide
in
the
sense
of
putting
a
ass
director,
an
exclusion
for
this
specific
forward,
looking
page
or
maybe
clarify
the
language
around
that,
but
that's
not
really
the
the
topic
at
hand
here
it's
really
about
where
this
goes
into
master
or
not,
and
I'm
of
the
opinion
that
that
this
isn't
something
that
is
coming
in
1.21
this
deprecation,
for
example,
it
almost
seems
like,
if
we're
going
to
allow
this
as
a
team
as
sig
docs,
it
should
go
into
master
or
whatever
branch
is
currently
active,
only
based
on
the
fact
of
that
it's
already
forward.
A
Looking
beyond
the
release.
Now,
if
we
say
docs
were
to
say
we
don't
want
forward-looking
documents,
and
we
really
don't
want
this
approach
or
maybe
there's
a
better
home
for
it.
I
think
the
argument
then
will
be
made.
Where
is
that
home
to
be
relocated
at,
but
what
I'm
interested?
What
do
other
folks
think.
B
I
just
want
to
be
cautious
because
I
know
we're
making
a
big
effort,
especially
with
the
how
we
handle
deprecations.
I
agree
that
I
don't
think
it
matters
really,
but
I
know
there's
other
people
that
are
working
on
communication
efforts
and
I
don't
want
to
you
know
I
don't
want
to
overstep
them.
So
that's
the
only
and
that's
my
personal
opinion.
B
So
ideally,
I
know
that
was
talked
about
how
that
was
discussed.
If
that
would
be
the
first
communication
points,
and
so
this
would
be
kind
of
accepting
that
gotcha.
A
Yeah,
I'm
wondering:
has
this
been
brought
up
to
sig
release?
I
would
imagine
I
see
some
of
these
folks
on
here.
Most
likely
are
being
driven
by
sig
release
as
well.
Have
they
been
aware
of
this,
or
is
there
any
conversation
around
it?
We
haven't
our.
A
A
Yeah,
so
I
think
ultimately
what
this
goes
in
master
dev.
You
know
the
121.
I
don't
think
it's
really
going
to
be
the
conversation
to
be
had
here.
It
makes
sense
in
both
because
neither
one
of
them
are
impacted
by
this
decision
impacted
by
the
stock,
whether
it
lands
a
little
bit
early
yeah.
I
don't
think
it's
going
to
be
a
massive.
A
I
don't
think
there's
a
huge
compromise
being
made
in
either
one
of
those
branches
being
merged,
but
I
do
think
you're
absolutely
right
ray
that
if
you
don't
mind
bringing
this
up
with
sig
release
tomorrow
at
the
meeting.
Let's
just
get
consensus,
it
doesn't
need
to
be
a
big
ordeal,
but
really
just
alignment
potentially
even
pinging
the
sub
project
for
the
blog,
but
then
just
making
sure
that,
or
generally
just
communication
alignment
here
is
really
what
I
see
as
being
the
gap.
Yeah.
B
A
Cool,
so
are
you
good
at
owning
that
one
ray
yeah?
I
think
that's
and
I
will
say
on
record
if
it
happens
to
merge
into
master
if
it
happens,
to
get
retargeted
to
a
dev
121
branch.
While
these
conversations
are
happening,
I
think
that's
not
not
going
to
be
too
terrible
either,
but
I
I
think
it's
the
right
thing
to
do
is
making
sure
everyone's
on
the
same
page.
A
B
I
think
the
next
one's
you
as
well
here
yeah,
so
this
is
not
really
for
a
review
because
the
cla
has
not
been
signed,
but
I
just
want
to
know
what
happens
when
a
pr
targets-
a
dev1.21
branch
and
the
cla
has
not
been
signed
yet,
and
so
you
know,
then
we
hit
release
date.
What
how
do
we
do?
I
close
it
out,
sir.
A
In
addition
to
that,
this
was
opened
up
january
15th,
there's
been
communication,
pretty
much
subsequent
approvers
reviewers
and
it's
almost
been
no
activity
from
the
original
pr
requester.
So
what
I've
done-
and
this
is
most
likely,
what
the
pr
wrangler
should
be
doing,
but
maybe
not
seeing
it
because
it's
on
the
dev
121
release
branch.
A
I
usually
take
a
judgment
call
here
and
I
look
at
something
like
this
and
I
say:
okay,
this
has
been
open
since
january
15th,
the
person
who
opened
it
up
their
current
status.
I
believe,
when
I
checked
it
was
they
may
be
slow
to
respond,
and
I
think
a
month
is
a
reasonable,
a
reasonable
amount
of
time
for
a
response.
A
So
the
the
long
story
short
here.
I
think
that
it
would
be
completely
fair
to
close
this
out
and
not
in
a
negative
connotation
but
more
of
hey.
This
has
been
open,
no
response
we're
going
to
close
this
out.
A
Whatever
that
date
range
may
be,
and
then
just
let
them
know
if
they
want
to
reopen
it
absolutely
can
within
the
time
frame.
It
looks
like
a
mistake.
However,
I
think
that
that
would
be
the
best
best
steps
forward
and
me
personally,
I
usually
rule
of
thumb,
look
around
for
about
two
weeks
of
activity,
maybe
a
month
depending
on,
if
there's
been
some
communication
or
some
sort
of
relay
communication
between
the
opener
or
the
author
and
the
reviewers,
but
the
fact
that
this
has
been
radio
silent.
A
I
think
it's
already
been
overly
generous
how
long
it's
been
open
with
no
feedback.
B
All
right
that
sounds
good.
Thank
you
for
that
yeah.
Oh
I'll!
Wait!
A
little
bit
see
now.
We
have
plenty
of
time.
You
know
before
the
121
release,
but
I'll,
probably
ping,
the
the
author
one
or
two
more
times,
but
it's
been
a
lot.
You
know
it's
been
over
a
month,
so.
A
Definitely,
and
one
other
thing
too,
that
I've
used
in
the
past
that
has
been
pretty
successful
is
leaving
a
comment
saying:
hey
look.
This
has
been
open
for
x
amount
of
time.
If
I
don't
have
a
response
by
a
certain
date,
I'm
going
to
close
this
pr
and
then
feel
free
to
reopen
that's
another
way
to
set
a
artificial
deadline
to
say:
look,
you
know
we're
not
going
around
just
closing
pr's.
We
gave
you
notice
and
nobody
said
anything.
A
Cool
all
right,
so
moving
on
jimmy,
you
want
to
talk
a
little
bit
about
the
config
api
generator.
C
Yes,
I
have
an
issue
filed
number
eight,
eight,
nine
long
time
ago,
it's
about
generating
some
unpublished.
C
C
Whatever
generating
some
references
for
the
unpublished
apis,
for
example,
people
are
using
coblet
config
more
frequently
today
and
then
using
command
line
flags,
because
eventually
command
line
flags
are
going
away
or
being
deprecated,
but
we
we
always
get
confused
how
the
config
file
should
look
like.
We
don't
have
a
reference
for
that.
It
is
not
published
from
the
api
server
or
anywhere
else.
C
Similarly,
for
good
proxy
google
scheduler
api
server,
we
don't
have
a
config
well
documented
anywhere.
So
so
that's
that's
the
the
reason
I
work
on
this.
I
have
already
proposed
a
a
pr
to
the
reference
docs
repo
using
that
tool.
We
can
generate
this
api.
This
quote-unquote
api
references
for
for
this
purpose.
C
Other
than
that,
I
also
found
that
there
are
some
places
in
the
documentation.
C
We
are
referring
the
readers,
the
users
to
go
south
code,
that
that
doesn't
always
make
good
sense,
because
not
all
users
are
go
long,
programmers
when
they
are
reading
the
go
dogs
or
the
south
code,
they
get
confused.
So
we
with
a
better
document,
then
as
regular
apis.
So
that's
the
reason
I
worked
on
this.
We
have
a
pr
to
the
reference
stocks,
repo,
that's
the
tool
for
the
reference
generation
and
several
prs
proposed
to
the
website.
I
listed
them
here.
C
I
hope
these
these
pr's
can
be
reviewed
soon.
I
would
like
to
hear
any
feedbacks.
Any
any
suggestions
on
that.
Also
related
to
this
is
when
I
was
generating
the
references
for
for
these
config
things.
Tim
bennett
raised
the
question
in
one
of
the
generated
reference.
C
He
saw
data
tabs
like
map
stream
string
string
slice.
All
those
kind
of
things
are
also
gold-
lung
specific.
It
doesn't
make
a
lot
of
sense
to
regular
users.
So
the
next
item
on
the
agenda
is
about
tuning
flag
tab
for
component
reference.
That's
another
improvement
to
the
component
reference
generation.
C
So
in
in
this
new
generator,
I'm
I'm
tuning
the
the
data
type
generation.
So
you
will
not
see
string
slash.
You
will
see
comma
separated
strings.
You
will
not
see
map
string
string.
You
will
see
comma
separated
key
equal
value
pairs,
so
that
makes
more
sense
to
the
user
and
because,
hopefully,
can
cause
less
confusion.
So
that's
my
update.
A
A
So
I
see
the
pull
request
for
the
reference
docs
and
maybe
it's
one
of
the
website
pr's.
If
there's
a
pr
to
look
at
like
the
generated
output
from
those
files,
or
maybe
it's
on
your
own
personal
fork,.
C
A
Cool
yeah,
that
would
be
great,
so
my
thought
is
this
is
actually
pretty
near
and
dear
to
my
heart,
because
I
you
know
when
I
was
operationally
supporting
kubernetes,
I
had
to
go
through
the
godox
to
figure
out
some
of
the
cubelet
configs
and
some
of
the
cube
adm
parameters
and
things
that
weren't
necessarily
clear
in
the
documentation-
and
I
remember
bringing
up
with
bringing
up
this
issue
with
sig
multi-cluster
life
cycle
and
the
general
opinion
there
was.
A
The
code
is
moving
too
fast
to
regularly
keep
docs
up
to
date,
so
the
best
source
of
truth
is
the
godox
because
they're
automatically
generated,
and
they
exist
with
saying
that.
I
completely
agree
to
ask
folks
just
to
go
and
grok
docks
or
grock.
The
godox
is
not
necessarily
the
best
contributor
experience
in
my
opinion,
so
I
think
this
is
a
great
effort.
A
C
Yeah,
so
so
that's
that's
the
only
left
item
on
my
to-do
list.
I
will
propose
some
changes
to
the
release
process,
so
that
of
the
generation
of
all
these
config
apis
will
be
included
automatically.
A
So
opening
the
pr
is
needed
for
the
instructions
for
the
release,
and
then
I
also
think
that
these
pr
should
have
some
sort
of
technical
review
or
technical
lgtm
from
either
multi-cluster
life
cycle.
I
think
that
those
would
be
the
I
think
they
would
be
the
the
people
who
who
you'd
want
to
talk
to.
I
would
imagine
you
could
bring
it
up
on
slack
or
potentially
or
potentially
join
one
of
their
meetings,
but
I
guess
what
I'm
looking
for
here
is
just
making
sure
it's
general
overall
consensus.
A
A
Cool
and
then
so,
do
you
want
to
take
the
action
item
then
for
outstanding
to-do
lists
and
maybe
or
that,
when
I
say
outstanding
to-do
list,
the
outstanding
release
changes
opening
that
pr
and
then
maybe
communicating
with
multi-cluster
life
cycle
before
that.
A
A
A
All
right
moving
on
for
the
discussion,
so
just
a
reminder.
We
had
our
quarterly
planning
scheduled
for
last
week
with
the
power
outage
and
some
of
the
craziness
in
my
life.
We
rescheduled
for
this
upcoming
thursday,
so
just
a
reminder
that
we're
planning
on
this
thursday
doing
the
quarterly
review
for
contacts
for
the
folks
in
this
call
we're
really
talking
about
what
happened
in
q4
and
what
we're
going
to
accomplish
in
q2
and
a
little
bit
of
what
has
happened
in
q1.
A
So
if
there's
anything
that
folks
would
like
to
add
to
the
agenda
to
discuss
the
agenda,
doc
is
in
the
link
there
and
I
plan
on
spending
some
time
and
just
you
know
getting
the
current
up-to-date
stats.
So
we
can
kick
off
the
thursday
quarterly
planning
as
a
success.
D
Hello,
I'm
korean
localization
team,
leader
soco
and
I
hope
to
share
korean
localization
current
status
and,
as
you
know,
korean
localization
team
using
a
milestone
strategy
and
we
are
working
on
korean
localization
branch,
current
benches
120
ku5.
It
is
actually
fifth
korean
localization
branch
and
it
is
based
on
the
master
branch.
D
If
this
branch
was
opened
around
three
days
ago
and
state
task
is
good
to
go
and
it
is
just
to
sharing
for
sharing
our
current
status.
D
It
is
the
second
blood
and
korean
localization
team
would
like
to
use
milestone
pro
command.
It
is
to
use
milestone
functionality
of
github
by
a
comment
we
are
using
milestone,
milestone
to
announce
current
korean
localization
schedule.
D
D
Announcing
new
localization
branch
and
the
target
merge
date,
and
also
we
are
using
milestone.
As
you
can
see,
we
opened,
we
created
table
120
ko5
milestone,
but
currently
we
are,
we
are
using
github
gui
for
creating
milestone,
assigning
milestone,
assigning
pr
and
issue
to
a
milestone.
D
D
D
Request
to
be
involved
in
the
marathon
branch
milestone
maintainer
for
all
korean
contentious
reviewers,
so
I'm
not
sure
it
is
appropriate
to
be
involved
in
that
my
master's
on
maintainers,
currently
korean
team
korean
content.
Chili
we
are
in
korean
team,
is
around
seven
seven
members,
so
I'm
not
sure
it
is
appropriate.
A
A
B
A
B
Yeah
you're
absolutely
right.
There
is
a
key
value.
I
don't
know
where
it's
stored,
even
if
the
milestone
is
in
the
k
website
repo.
If
it's
not
part
of
the
setup
in
prowl
like,
for
example,
I
accidentally
put
a
milestone,
1.20
a
pull
request
for
1.21.
B
It
rejected
it
because
that,
because
in
the
1.21
branch,
it's
not
the
price
wasn't
set
up
to
for
for
an
awesome
1.20,
even
though
we
know
we
have
the
k
website
well
awesome
for
120.,
so
it
does
have
to
set
to
be
set
up
in
prowl.
I
don't
know
who
the
best
person
is
to
get
that
set
up.
B
I
should
I
should
I'll
take
a
look
in
the
roll
handbooks,
because
I
think
we
might
have
to
do
that
like
post
release
to
set
up
the
the
next
milestone
for
prowl.
So
I
could
take
a
look
at
that
and
see
what
is
needed
to
set
up
prowl
for
those
milestone,
commands.
A
A
Yeah,
so
I
think
my
my
general
thought
is:
it
makes
sense
to
be
able
to
use
the
milestone
command
here.
This
once
again
has
been
heavily,
I
should
say,
heavily
regulated,
but
this
has
been
owned
predominantly
by
sig
release.
The
use
of
the
milestone
command
has
just
recently
really
been
leveraged
by
sig
docs
over
the
past,
probably
two
or
three
maybe
four
releases,
and
so
I
think
this
might
just
need
a
little
bit
of
wider
communication
once
again
with
sig
release
about
leveraging
the
slash
milestone,
brow
command.
A
A
So
as
far
as
next
steps
on
on
something
like
this,
I
I
wouldn't
mind
just
seeing
more
testing
or
maybe
just
more
concrete
information
about
leveraging
the
milestone,
proud
command.
What
I
can
do
is
I
can
take
the
action
item.
I
don't
see
soco
do
you
know
if
you're
part
of
the
milestone,
maintainers
group.
D
Not
I'm
not
involved
in
but
journey
is
involved
when
we
create
we
initiated
first
korean
localization.
He
involved
in
milestone
team,
milestone,
1819
and
other
teams
as
well.
So
maybe
I
can
introduce
a.
D
A
Yeah,
so
what
I'm
thinking
here
is,
I,
I
can
add
you
to
the
milestone
maintainer
group,
it's
a
github
team,
it's
in
one
of
our
repositories
and
I'll
take
that
action
item
to
add
you
as
a
reviewer.
I
believe
that
there's
no
issue
considering
the
fact
this
was
previously
previously
ran
by
joon
yi.
So
I
don't
think
permissions
or
access
is
any
problem
there.
A
I'll
get
you
the
access
to
run
the
slash
milestone,
maintainers
or
the
slash,
milestone,
proud
command
and,
let's
just
validate
before
moving
forward
at
a
wider
scale
that
this
does
work
the
way
we
anticipate
it.
To
that
way,
we
don't
go
creating
a
big
stink
around
something
before
knowing
whether
or
not
it
works.
The
way
we
expect
it
to
it
looks
like
it
might.
D
A
No,
those
have
been
awesome
cool
yeah.
I
appreciate
that.
Let
me
put
that
in
chat
as
well.
That's
what
I'm
fearing
is,
my
fear
is:
is
that
getting
the
access
to
run
the
prowl
command
is
not
the
big
deal
that
can
happen
no
matter.
What
my
fear
is
that
it's
going
to
be
more
complex
to
maintain,
creating
a
pr
to
create
the
branch
in
prow
for
its
awareness
and
then
going
and
commenting
versus.
A
I
think
some
of
the
leaders
for
the
korean
localization
have
high
level
access
to
right
access
to
the
repository
to
make
those
changes
through
the
the
web
interface.
A
B
D
Thank
you,
so
that's
all
for
the
korean
localization
team
update.
D
Yeah
yeah.
Actually,
I
hope
to
ask
that
comey's
question
of
pr
needs
to
be
imposed.
I
hope
to
check,
because
sometimes
there
are
some
contributors
who.
A
Awesome
yeah,
that's
a
great
question
and
I
think
the
problem
happens
on
all
the
the
documentation,
all
the
different
languages,
so
I
feel
like
you're
gonna,
get
a
different
answer
depending
on
who
you
ask,
but
I
can
talk
about
what
I
would
normally
do.
There
is
a
proud
command,
it's
a
tied
mer,
it's
a
tied
label
and
let
me
see
if
I
can
find
it
that
will
allow
you
to
squash
the
pr
through
tide
and
let
me
well,
let
me
just
find
it
and
that
way
I'm
not
looking.
While
I'm
talking.
A
Right
so
in
this
case
the
general
rule
of
thumb
that
I've
followed
is
asking
the
contributor
to
squash
the
pr
that's
just
general
best
practices.
It's
a
good
skill
to
have,
and
ideally
folks
are
self-sufficient,
they've
opened
up
a
pr.
They
can
squash
it.
However,
some
folks,
especially
you
know
doing
like
a
typo
fix
or
a
small
minor
pr.
They
might
not
really
have
the
desire
to
return
and
squash
the
the
commits,
and
we
want
to
merge
that
pr.
A
A
And
so
what
we
end
up
doing
is,
if
you
were
to
apply
this
label,
you
can
do
it
either
through
the
gui
or
through
the
prowl
command
here
with
slash
labeled,
when
you
apply
this
label
on
a
pull
request.
What
will
happen
is
when
tide
merges.
The
pr
tide
will
squash
itself
right
now.
The
way
tide
operates.
It
doesn't
squash.
The
pr
if
a
pr
is
two
commits
it'll
be
two
commits
against
master
branch.
A
If
we
apply
that
label
type,
merge
method,
squash
title
then
make
a
summary
squash
down
to
a
single
commit
and
do
it
pragmatically
via
prowl
or
yeah
via
tied
and
proud.
So
that's
been
my
rule
of
thumb.
It's
kind
of
a
loose
depending
on
what
your
overall
goals
are.
I
know
when
I've
acted
as
a
pr
wrangler
and
my
entire
goal
was
reducing
the
number
of
prs
and
increasing
velocity
for
merging
prs.
A
Cool
any
other
questions
or
comments
on
that
I'm
curious.
Does
anyone
else
feel
differently
about
that
methodology?
I
shared
how
I
deal
with
squashing
prs.
Like
I
said
it's
the
way
I
do
it,
it's
not
necessarily
right
or
wrong.
How
how
do
other
folks
handle
that
if
they
they
came
across
it.
B
I've
seen
the
same
as
you
where
we
would
ask
the
author
to
squash
their
commits
if
they
don't
after
after
a
week
or
two
and
I've
seen
that
I've
seen
that
that
command
use.
But
I
do
agree
that
squashing
is
it's
not
a
difficult
technique,
but
it
could
be
daunting
for
someone
who's
doesn't
use
git
all
the
time
right.
A
Yep,
absolutely
cool,
I'm
glad
to
hear
I'm
not
alone
there,
and
I
will
say
that
squashing
is
daunting
when
you
have
no
idea
what
you're
doing
speaking
from
past
experience,
but
definitely
once
you
understand
some
of
the
more
core
concepts
of
get
it
becomes
a
lot
easier.
Definitely.
D
I
just
hope
to
check
this
method.
Tide
label
method
is
used
to
to
or
or
proverbs
of,
english
contents
or
korean
contentions.
Here
I,
I
am
not
sure
it
is
in
a
guided
document
to
approve
earth,
so
some
new
approvals
me
inquiry
how
to
do
deal
with
this
squashing
issue,
so
maybe
it
can
be
shared
to
other
approval,
search
right.
A
A
There
is
a
slight
documentation
that
I
put
in
myself,
because
I've
ran
into
this
a
few
times
and
wanted
a
way
to
remember
when
I'm
wrangling
prs
how
to
apply
the
label
and
the
link
I
sent
is
helpful,
proud
commands
for
wranglers
applying
the
label
might
not
really
matter
that
much,
but
as
far
as
the
squash
label
and
then,
if
you
wanted
to
re-title
a
pr
those
come
in
handy
a
ton
of
times
acting
as
an
approver
or
pr
wrangler,
the
one
thing
you'll
see
is
like
you
were
saying:
I'm
not
sure
if
it
is
only
approvers
who
can
apply
that
label,
I
think
it
is,
but
you
might
see
a
reviewer
try
to
do
it,
and
maybe
your
approver
needs
to
step
in
and
make
sure
that
label
exists
prior
to
prior
to
lgtm
and
approving
that
pr.
C
C
I
intentionally
split
this
pr
into
three
commits
the
first
one
is
about
wrapping
long
lines.
I
feel
really
bad
for
long
lines.
C
So
so
that's
the
first
pr
I
didn't
change
anything
then
in
the
second
commit
I
fixed
the
links,
then,
when
fixing
the
links,
if
I
saw
some
very
old
content
in
the
pr,
so
I
put
the
third
commit
in
the
same
in
the
same
pr,
so
I
label
that
pr
with
the
pro
command
mentioned
by
baby
jim
but
later
on,
jim
instead
said
that
maybe
we
want
to
keep
these
three
commits
separate,
don't
squash
them.
So
this
is
another
story
for
your
reference.
A
Yeah,
that's
a
that's
a
great
point.
I
I
believe
the
rule
of
thumb
is
a
commit,
should
be
a
unit
of
work
and
entirely
so,
as
you're
saying
you
mean
it
might
make
sense
to
leave
these
all
individually
as
commits,
I,
I
think,
more
often
than
not
the
authors
of
prs
who
are
not
responding
and
they're
not
squashing
their
commits.
It's
usually
not
the
same
folks
that
are
managing
their
prs.
Well,
creating
individual
slices
of
commits
and
and
creating
a
wonderful
pr
like
you
did,
but
yeah.
A
I
think
that's
definitely
worth
keeping
into
consideration
that
if
the
individual
commits
makes
sense
to
leave
them
separate,
there's
no
harm
in
leaving
them
as
is
but
more
times
than
not
it's.
You
know
patch
dash
one
and
then
you
know
fix
two
and
fix
three
and
fix
four
and
it's
all
related
to
the
same
unit
of
work,
and
in
that
case
you
absolutely
want
to
squash.
It.
E
Just
a
comment:
today
we
have,
we
had
our
kickoff
meeting
for
the
portuguese
localization
and
we
think
to
follow
the
korean
thing.
Work
model.
A
A
These
are
the
experts
in
the
call
here
and
then
there's
also
the
monthly
meeting
the
first
monday
of
the
month.
I
believe,
there's
more
information
in
the
on
the
community
repo.
I
can
link
here
in
a
second.
E
Yeah,
I'm
I'm
here
because
last
year
I
attended
to
brad
topple
lecturing
in
ibm,
and
I
and
since
since
january
I
I
work.
I
tried
to
help
in
the
localization
to
portuguese
awesome.
D
D
A
Yeah
and
it's
funny
that
you
say
that
you
had
brad
topple,
introduce
you
to
the
localization
docs,
because
also
brad
topple
is
leading
the
efforts
for
the
localization
synchronization.
It's
a
lot
of
words,
but
the
the
meeting
efforts
that
are
once
a
month
there.
So
I
said
I'll
get
that
linked
here
in
chat
in
just
a
second.
Actually,
I
can
send
it
now.
A
A
That's
where
we're
at
currently
today,
the
korean
team
meeting
is
also
in
there
for
the
korean
team
localization
and
then
the
one
I
was
talking
about
with
brad
topel
is
the
localization
subgroup
meeting
and
that
one
is
the
one
that
meets
monthly
on
mondays
at
1500
utc,
and
that
localization
subgroup
meeting
is
really
focusing
on
streamlining
all
of
the
different
localizations.
A
How
folks
do
branching?
How
folks
do
prs
and
merges
and
staying
up
to
date
and
making
sure
all
the
things
are
all
under
one
roof?
A
Yep
no
problem
and
anything
that
we
could
help
with.
As
far
as
the
2021
kickoff
meeting
for
the
portuguese
localization.
A
Awesome
well,
if
we
can
help,
let
us
know
please
reach
out
to
us
and
we'd
be
happy
to
to
assist
and
happy
to
have
more
hands
helping
localization.
This
is
great
to
see
more
people
contributing
cole,
and
with
that
we
are
at
the
end
of
our
agenda.
Does
anyone
have
anything
else
they
would
like
to.