►
From YouTube: Kubernetes SIG Docs monthly APAC meeting for 20200923
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,
everybody!
This
is
the
weekly
sig
docs
meeting
and
today
is
the
fourth
week
or
the
free
house
phrase.
Fourth
tuesday.
After
for
the
aipac
friendly
meeting,
which
is
at
6,
00
p.m,
pacific
or
one
utc,
and
it
is
september,
the
22nd.
A
A
Moving
on
to
updates
reminders,
this
week's
pr
wrangler
is
beneath
and
I
saw
him
active
in
the
slack
channel,
so
things
look
good.
There
haven't
looked
too
closely
at
the
docks
themselves,
so
gotta
take
a
look
there
and
see
how
things
are
going
for
sure,
and
next
week's
pr
wrangler
is
peter
peterson
and
I'm
not
sure
if
anyone's
heard
from
peter
in
a
while.
I
personally
have
not.
A
All
right,
approvers
make
sure
you
know
your
pr
wrangler
shift
and
what's
coming
up
so
moving
on
to
the
agenda
release
120,
I
saw
that
anna
posted
in
the
sig
doc's
channel
that
the
shadow
selection
is
complete,
anna's
working
on
onboarding,
the
team
or
the
onboarding,
the
shadows
to
the
release
team
and,
if
there's
any
questions
or
concerns
to
reach
out
there
and
contact
donna,
there's
also
a
release
docs
channel.
A
So
for
those
who
haven't
seen,
we
ended
up
having
kind
of
duplicate
channels
for
the
docs
release
process,
as
well
as
this
release
dash
docs
channel.
So
we
deprecated
one
of
them
or
archived
one
of
them
and
now
all
the
communication
for
the
release
process
should
go
to
that
release.
Dot,
release
dash
doc's
channel.
A
Moving
on
blog
update,
caitlin,
that's
something
you
would
be
able
to
fill
us
in
on.
B
Yeah,
so
really
not
anything
that
interesting
going
on
there,
which
is
kind
of
great
we're
pretty
much
caught
up
on
content
business
as
usual,
we
are
going
to
open
up
blog
shadowing
again
for
anybody
interested
in
potentially
becoming
a
reviewer
or
approver
there.
B
A
A
All
right
so
moving
along
to
the
co-chair
transition.
This
issue
has
been
opened
up
by
zach
for
a
while
and
executing
some
of
the
action
items
that
require
someone
to
move
to
emeritus
and
some
a
new
chair
to
be
moved
into
that
co-chair
position
after
shadowing
for
some
time.
A
So,
if
you
take
a
look
at
the
issue,
the
one
big
outstanding
item
is
a
vote,
and
this
is
always
somewhat
of
a
uneventful
process.
We
have
all
the
co-chairs
here
right
now:
caitlyn
myself
and
zach
and
it's
the
magical
hand
wavy.
Do
we
vote
all
in
favor
to
have
irva
become
a
co-chair,
so
I
guess
we'll
vote
with
thumbs
up
or
thumbs
down
from
the
chairs
perspective.
A
And
there
you
have
it,
there's
the
magical
transition
there.
Any
questions,
comments
or
concerns.
C
C
It's
been
been
good,
I'll
still
be
around
as
far
as
actually
finishing
the
transition
process.
I
looked
for
every
place
with
a
file
that
needs
an
update
like
an
owners
or
an
owner's
alias
or
in
the
case
of
community.
Like
some
of
the
yaml
manifests.
C
D
C
Let's
see
the
kk
owners
aliases
k,
test,
infra.
C
K
org
and
then
we'll
need
to
open
a
couple
of
pr's
in
the
k
in
a
kubernetes
cigs
organization
in
the
reference
docs
repo
and
then
in
the
kubernetes
case.io
rico.
If
that
might
be
a
good
action
for
erv
to
open,
pr's
against
and
I'm
happy
to
approve
them.
E
C
A
C
Probably
yeah,
it's
probably
easier
if
by
transitioning
someone
out,
it's
a
lot
easier
to
approve
a
pr
than
it
is
to
open
all
of
those
prs
and
in
the
case
of
like
somebody,
who's
not
able
to
open
prs.
For
whatever
reason.
It's
a
lot
easier
for,
like
the
incoming
chair
to
open
those
prs
and
for
another
another
chair
to
approve
them.
A
You
all
right
so
moving
on
to
issues
and
prs,
and
I
took
a
look
at
this.
I
took
a
look
at
this
issue
and
I
did
follow
it
at
one
point.
I
feel
like
I've
somehow
lost
kind
of
my
attachment
to
this
conversation
or
context.
I'm
not
sure
if
anyone
on
this
call
has
more
contact
sec.
C
Yeah,
so
there's
a
pr
open.
What
is
it?
It
is
two
three
four,
nine
seven-
and
this
is
a
new
contributor
who's
opened
this
pr.
C
It
is
it's
currently
stuck
in
review.
C
Let's
see
what
was
the
pr
number
again,
two
three,
four
nine
seven,
I'm
happy
to
put
a
link
in
chat.
C
There,
it
is
so
to
the
point
that
tim
is
raising
are
valid.
C
On
the
latest
review,
it
looks
like
tim
reviewed
about
eight
hours
ago.
C
I
guess
the
question
that
I
have
is
whether
we
can
approve
this
pr
as
is
and
then
iterate
or
whether
we
need
to
address
all
of
this
feedback.
Tim
does
raise
some
valid
points,
but
this
to
be
honest,
this
isn't
the
best
new
contributor
experience
for
this
person.
C
F
I
think
we
have
to
at
this
point
it's
getting
super
super
bogged
down.
In
effect
like
details
and
like
the
print,
it
doesn't
seem
like
the
principle
of
the
change
this
person
is
trying
to
propose
is
under
debate
at
this
point
and
we're
kind
of
just
tearing
ourselves
apart
over
like
tiny
little
loose
threads.
F
F
They're,
their
opinions,
they're
just
a
thing
we
all
agree
to
when
we're
trying
to
agree
without,
like
speaking
to
each
other,
face
to
face
or
being
in
a
synchronous
space
and
time,
which
means
that
people
will
just
forever
keep
stamping
their
opinion
on
the
internet
and
daring
people
to
to
disagree.
So
I
think
we
kind
of
just
have
to
do
our
best
to
push
it
along,
or
else
it's
never
going
to
get.
A
The
question
I
would
ask
here
is
when
we
do
merge
this
pr
in
does
it
make
sense
just
to
for
us
to
apply
the
squash
label,
get
this
in
iterate
on
top
for
the
sake
of
moving
quick
or
open
that
up
and
personally
I
lean
more
towards
the
label
kind
of
the
quick
and
like
let's
just
more
focus
on
pr
velocity
than
slowing
folks
down,
for
you
know
the
sake
of
learning,
but
I
think
there's
value
in
both
I'm
curious.
If
anyone
has
any
hard
feelings
one
way
or
the
other.
C
Looking
at
the
commits,
I
don't
see
any
history
revisions
in
the
commits
and
that's
the
only
thing
that
would
concern
me.
So
I
think
the
label
approach
and
favoring
velocity
is
totally
valid.
F
Can
I
ask
a
question,
which
is:
why
do
we
encourage
people
to
squash
themselves
as
opposed
to
flat
out
just
supplying
the
label
and
the
reason
I
ask
this
is
for
a
new
contributor?
Wouldn't
it
be
easier
for
them
if
we
just
applied
the
label
as
opposed
to
like
and
now
you
have
to
learn
this
kind
of
sketchy
get
thing
have
fun.
A
The
exact
conversation
came
up
in
sync
and
tripx,
and
the
general
consensus
was
it's
a
good
skill
to
learn
for
sure
and
if
there's
time
and
ability
that
the
recommendation
was
that
the
pr
author
actually
performs
the
the
squash.
But
you
know
if
I'm
pr
wrangling
and
there's
a
pr
that's
open
with
not
a
ton
of
movement
or
action.
It
has
two
commits
on
it.
I'm
going
to
apply
the
label
and
move
forward
for
the
sake
of
getting
that
to
merge
and
zach.
You
had
your
hand
raised
sorry
to
speak
over
you.
There.
A
C
It's
all
good,
the
clean
commits
are
a
best
practice
having
one
clean
commit
that
makes
all
the
changes
obvious
and
builds
cleanly
as
opposed
to
having
to
parse
individual
commits,
ultimately
like
working
in
individual
commits,
can
be
really
helpful
during
like
a
protracted
review
but
squashing
for
a
final
review.
F
I
understood
that
I
just
didn't
understand
why
we
don't
use
the
label
more,
as
opposed
to,
for
example,
asking
the
author,
because
again
for
a
super
new
contributor
it,
it
almost
doesn't
make
sense
to
saddle
them
with
like
the
git,
if
it's
their
very
first
time
or
if,
like,
for
example,
you
sit
there
kind
of
waiting
for
weeks
and
weeks
and
weeks
for
somebody
to
squash
their
commits.
Why
aren't
we
more
trigger
happy
with
the
label?
I
guess
is
my
question,
but
I
think
jim
answered
it.
A
Cool
yeah
and
I
I
don't
think
we
have
a
hard
policy
that
I
don't
think
one
way
or
the
other.
I
I
think
we
have
that
rule
of
thumb
from
the
conversation
and
sig
control
backs,
but
if
we
wanted
to
make
it
more
widely
known
or
more
of
a
norm,
definitely
I
think
that
would
be
something
someone
could
potentially
own
or
promote
there.
But
yeah.
I
to
me
it's
a
complete
judgment.
A
Call
I
want
to
give
folks
the
opportunity
to
learn-
and
you
know,
learn
some
of
the
pains
of
squashing
to
commit,
but
at
the
same
time
I
don't
want
to
slow
down
productivity
pr
velocity
things
of
those
nature.
A
A
The
number
five
sevens,
so
it's
just
seven
five
times,
and
so
what
we
need
to
do
is
update
the
meetings
and
update
the
meeting
invites
with
the
new
the
new,
the
new
links
with
the
password,
as
well
as
update
the
community
guide
and
and
just
generally
announce
this
change
and
make
sure
it's
known
and
folks
update
any
of
their
links
or
resources
there.
So
I'll
take
care
of
this.
A
I
didn't
want
to
change
it
prior
to
this
meeting,
given
that
there
would
be
any
issues
and
given
the
way
I
kind
of
flew
into
this
meeting
like
kramer
and
seinfeld,
I
feel
like
I'm
glad
I
didn't
actually
make
that
change
prior
to
this
meeting,
but
just
be
aware,
most
likely
next
tuesday's
meeting
will
have
the
password
in
it
I'll
go
through
npr
those
changes
and
update
this
issue.
As.
A
Well,
cool.
Moving
on
to
celeste,
it
looks
like
you
had
a
action
item
here,
a
topic
to
talk
about
the
contributors
you
wanna
take
that
away.
F
Yeah,
so
the
the
issue
here
is
now
kubernetes.dev
exists
and
how
we
wanted
to
link
that
from
the
main
site
and
where
that
discussion
led
last
time
was,
do
we
need
to
say
goodbye
to
our
current
community
page
in
terms
of
content
that
is
directly
living
on
kubernetes.com
community?
At
this
point,
the
code
of
conduct
would
need
to
move
and
find
a
new
home
and,
arguably
maybe
shouldn't
be
under
community
anyways.
F
It
should
be
a
little
bit
more
high
profile
and
I
think
tim
had
a
concern
about
meetups
in
in
the
normal
times.
I
think
there's
a
feed
of
meetups
on
that
page.
That
would
need
to
find
a
a
different
home,
but,
aside
from
that,
nobody
in
the
community
had
any
attachment
to
it,
and
it's
the
perspective
of
sig
controvex
and
bob
killen
that
that
community
page
should
just
go
away
and
we
should
be
linking
to
kubernetes.dev
from
this
point
onwards.
F
F
G
Hello,
so
we
I
met
with
anna
today
I'm
one
of
the
dark
shadows,
and
there
is
an
instruction
in
the
community
page
that
is
not
in
the
handbook
now
for
for
making
placeholder
prs,
and
it
just
is
something
simple.
So
something
that
we
I
I
need
to
make
sure
that
in
the
kubernetes.dev
or
in
the
or
in
the
role
book
for
the
docs
team,
I
think
it's
in
the
in
that
community
page
I'll
have
to
go
verify.
But
that's
the
only
thing
that
I
see.
G
D
F
Yeah
am
I
understanding
of
what
they're
planning
for
kubernetes.dev
is
like
right.
Now,
it's
a
bit
of
a
skeleton,
but
it
is
supposed
to
be
the
home
for
all
things.
Community
going
forward,
we'll
see
how
that
goes,
but
I
think
top
nav
real
estate
wise
and
deduplication
wise
and
ownership
wise.
It's
probably.
B
The
best
move
so
will
meetups
go
to
kubernetes.dev
or
do
we
need
to
find
a
home
for
that.
F
B
Okay-
and
you
said,
sig
controvex
was
on
board
with
getting
rid
of
it.
That's
bob
killen's
opinion.
Okay
launched
that
thing,
so
yeah
I'd
love
to
take
a
look
at
the
issue
and
just
kind
of
take
it.
It
was.
It
was
just
a
really
big
project.
We
did
with
contribex
a
while
back,
so
I
kind
of
hate
to
get
rid
of
it,
but
it's
okay,
fair.
But
if
the
plan
is
to
duplicate
all
the
content,
then
and
they're
on
board,
then
I
think
I'm
fine
with
it.
C
C
If
you
celeste,
if
you
specifically
want
to
open
an
issue
to
make
sure
that
the
meetup
content
lives
prominently
on
kubernetes.dev,
I
think
that
the
community
code
of
conduct
is
likewise
high
profile
invisible.
That
sounds
like
an
excellent
thing
for
ren
to
be
aware
of
and
to
incorporate
into
their
work.
F
I
agree
I
I
think
I
actually
have
no
problems
with
the
community
code
of
conduct
living
on
kubernetes.dev.
Personally,
I
think
the
other
people
to
inform
of
that
are
maybe
probably
the
code
of
conduct
committee
and
say
like
this
might
be
happening.
Are
you
okay?
So
I
will
do
that
through
the
ways
in
which
I
do
that.
I
think
ascending
rin
is
also
a
good
idea
as
well,
so
I'm
totally
cool
with
that
so
yeah.
F
How
about
I
take
those
as
action
items
to
update
the
issue
that
I
linked
in
the
the
thing
and
I'll
create
some
work
for
rin
and
assign
them?
Should
I
create
it
in
signature
max.
F
Okay,
I'll
I'll
find
a
home
for
it
and
I'll
open
up
a
issue
for
rin
and
we'll
get
this
show
on
the.
A
Road
cool
sounds
good,
so
it
sounds
like
there's
direction
on
there.
Is
there
anything
else
related
to
that
page,
you're,
all
good
cool,
so
moving
on
to
the
korean
localization
update
shioko,
do
you
want
to
take
that
one
away.
E
E
E
19
119
master,
so
currently,
current
working
branch
is
the
one
19
ko2
and
it
will
be
emerged
soon.
Maybe
tomorrow
and
we
create
ko3
again,
we
hope
to
share.
We
are
looking
for
a
method
to
notify
team
milestone
schedule
to
github
only
contributors.
E
Some
contributors
does
not
participate,
participate
in
a
selectional
and
korean
team
meeting.
They
only
check
the
github
status.
So
since
we
changed
keep
changing
work
working
branch,
so
we
try
to
find
out
what
is
the
best
way
to
notify
team
schedule
and
country.
We
are
testing
github
milestone
and
we
have
opened
an
issue
to
share
team
branch
schedule,
so
you
can
check
the
links
first.
One
is
an
issue
to
our
contributors
to
have
contributors
understand
what
is
the
pr
please
freeze
and
target
date
so
country.
E
We
are
testing
and
we
put
this
issue
to
a
milestone
level,
1
19
ko2
country,
and
if,
when
we
make
119
ko3
branch,
we
will
make
another
milestone
for
kyoto
3
and
we
will
open
help
quantity
issue
for
ko3
again
so
come
to
real
testing,
and
maybe
korean
localization
team
member
will
also
give
some
ideas
and
regarding
this
testing,
so
if
it
can,
it
will
set,
it
is
settled.
Then
I
think
we
need
some
authorization
for
pro
for
my
stunt
team.
A
E
C
It's
a
very
clever
use
of
the
milestones
so
yeah.
Please
keep
us
updated.
I'm
really,
I'm
really
interested
to
hear
what
you
decide.
A
Awesome,
thank
you
and-
and
I
don't
know
if
you
have
already
notified
or
might
be
too
early
yet
there
is
the
new
sig
docs
localization
subgroup
might
be
worth
bringing
up
there
for
just
general
awareness
synchronization.
E
Yes,
I
know:
maybe
tomorrow
there
will
be
korean
localization
team
meeting
and
I
will
share
the.
There
is
new
localization
sub
group
and
I'm
not
sure
I
should
participate,
but
I
will
ask
it
to
our
team
whether
we
should
participate
or
not,
and
anyway
we
will
inform
how
we
work
to
localization
subgroup.
Thank
you.
A
So
moving
on
here
to
it,
looks
like
zac
added
a
line
item
about
community
norms
for
approving
your
prs.
Do
you
wanna
take
that
away
zach
yeah.
C
So
tim
raised
the
issue,
I
guess
in
last
week's
weekly
meeting
there
was
a
pr
open.
C
Well,
I'm
not
familiar
with
the
immediate
details,
but
I
gather
that
essentially
he
approved
his
own
pr.
He
got
feedback
and
input
from
the
community
before
he
did
it,
which
is
great
but
ultimately
approved
his
own
pr.
F
C
C
If
you
are
an
approver
in
that
repository
prow,
when
you
open
a
poll
request,
if
you're
an
approver
prowl
automatically
applies
the
approved
label,
it
assumes
that,
because
you're
an
approver,
you
know
what
you're
doing
and
smooths
the
path
to
to
approval
so
that
any
other
contributor
or
any
other
member
of
the
org
could
just
put
an
lgtm
on
it
and
emerges
because
pull
requests.
2K
website
are
high
impact
and
high
visibility.
C
I
think
having
an
explicit
review
separate
from
an
lgtm
and
that
well
two
things.
I
think
that
having
an
explicit
review
for
approval
is
a
good
thing
and
speaking
as
I
can't
believe,
I'm
going
to
say
this
as
a
chairman.
C
I
know
that
every
single
chair
has
committed
some
horrible
thing
to
the
website
at
some
point
that
we
have
had
to
frantically
revert,
so
none
of
us
are
too
good
that
we
can
just
self-approve
at
random.
So
I
guess
I
want
to
be.
I
want
to
recommend
that
we
be
very
explicit
that
we
don't
approve
our
own
pr's
even
for
easy
stuff,
because
it
sets
the
standard
by
which
others
observe
our
behavior
and
it
becomes
a
community
norm.
F
I
think
that's
fair,
so
I'm
remembering
the
context
of
this
a
little
bit
more
as
you
were
speaking
and
what
it
is
is
that
pr
was
a.
F
It
was
a
website
change
and
it
was
like
a
fairly
technical
website
change,
so
tim
in
his
infinite
brilliance
and
kindness
decided
to
parameterize
the
way
that
we
pull
in
the
cncf
landscapes,
which
is
a
very,
very
smart
thing
to
do,
and
I
think
it
actually
there's
an
underlying
issue
here,
which
is
there,
isn't
enough
people
to
approve
those
kinds
of
pr's
who
feel
comfortable
approving
web
development
type
prs.
F
We
don't
have
enough
active
approvers
with
that
skill
set
and
that
knowledge
and
we
kind
of
need
to
start
pulling
people
in
who
have
that
because
we're
doing
a
lot
more
of
that-
and
I
like-
I-
was
wrangler
that
week
and
I
put
the
loot
like
let's
go,
looks
good
to
me
on
that,
and
I
put
the
looks
good
to
me
and
quite
a
few
pr's
that
week,
which
were
effectively
web
development
and
web
improvement
prs.
F
But
I
can't
I
can't
I
can't
let
I
can't
do
both
they're
too
big
for
that
and
it's
like
beside
if
tim's
opening
it
tim's,
typically
the
other
person
who
will
put
the
approve
on
it,
because
he
and
I
are
the
most
active
approvers
for
these
kinds
of
prs.
So
it's
there's
a
problem
here.
I
don't
have
a
solution.
There's
a
problem.
C
So
I
mean
that's
a
really
valid
concern
to
raise
is
if
approval
just
amounts
to
a
blind
rubber
stamp,
then
that's
not
good,
and
that
sounds
like
something
that
we
need
to
recruit
for,
but
let's
not
let
that
lead
to
a
broken
approval
process.
C
Let's
solve
the
actual
problem,
as
opposed
to
letting
it
roll
downhill
into
a
process
problem.
If
that
makes
sense,.
H
So
I
I
have
actually
oh
hello
by
the
way
I
have
actually
yeah
there's
a
bunch
of
pull
requests
that
I
created.
So
basically
I've
done
this
many
times,
but
every
time
I
do
it,
I
always
asked
at
least
more
than
two
other
reviewers
give
lgtm.
H
So
that,
like
you
know,
because
japanese
translation
has
only
two
reviewers-
I
don't
know
owners
me
and
the
other,
so
we
don't
have
like
much
time
to
give
the
approval
label.
So
it's
kind
of
a
rule,
but
I
always
ask
at
least
more
than
two
reviewers
says
lgtm.
Then
okay,
then
I
just
merge
it.
C
You
are
brave
to
admit
that
I
don't
know
that's.
I
definitely
have
a
way
that
I
would
prefer
to
do
it,
but
I'm
not
a
chair
anymore,
so
jim
and
caitlin.
This
is
ultimately
up
to
you.
A
Nice,
I
you
know,
I
think
localization
has
problems
with
the
number
of
people
who
have
the
ability
to
approve
and
review,
and
I
think
that
this
also
stems
down
to
the
question.
That's
brought
up
at
the
last
apec
meeting,
or
maybe
it
was
a
couple
apec
meetings
ago-
is
what
does
that
latter
look
like
for
getting
more
reviewers
and
for
getting
more
approvers?
A
Personally
speaking,
I
think
if
you
have
two
approvers,
you
might
have
enough
ability
to
say
you
know,
delegate
to
the
other
approver,
but
at
the
same
time,
for
the
sake
of
pr
velocity,
it
sounds
like
we
have
a
people
problem
more
so
than
an
approval
problem
and
getting
those
people
in
positions
to
be
able
to
approve.
A
So
I'm
not.
I
don't
know
if
I
feel
as
strongly
as
zach
does
about
this,
especially
if
you
were
to
bring
it
into
the
context
of
localization,
but
I
do
think
there's
ways
to
have
other
approvers
write
the
approval
there
and,
in
the
context
of
like,
what's
less
than
zach
we're
both
referring
to
where
the
approval
is
a
simple
rubber
stamp.
A
I
almost
you
know,
I'm
pretty
much
torn
there.
You
know
I
feel
like
there
could
be
potentially
extra
effort
to
say.
Can
someone
else
take
a
look
at
this?
We
need
this
specific
expertise
in
the
sig
ducts
maintainers
channel,
but
you
know
it's
very
possible
that
there
are
only
two
subject
matter:
experts
once
again,
a
people
in
process
problem
yeah.
I
I
don't
have
enough
context
now,
I'm
just
kind
of
rambling
here
out
loud.
I
don't
know
exactly.
C
So
I
think,
specifically
with
the
pr
that
tim
opened,
that
parameterized
the
cncf
landscape,
that's
the
sort
of
thing.
I
know
that
bob
killen
would
be
fascinated
by
and
would
love
to
review
and
I'm
guessing
that
bob
isn't
the
only
one
ben
elder
would
be
another
person.
So
maybe
we
need
to
reach
outside
of
ourselves
and.
C
Even
if
they're
not
approvers
for
the
repository,
they
can
at
least
give
like
enough
of
a
review
as
a
subject
matter
expert
to
have
like
a
like
a
weighty
lgtm,
I
guess
there's
a
way
to
think
about.
F
F
C
C
C
B
Yeah,
I
mean
just
to
kind
of
speak
to
how
we've
done
these
in
the
past.
For
like
the
web
changes,
it's
you
know
pretty
much.
B
F
But
so
so
this
kind
of
comes
back
to
what,
if
you're,
making
kind
of
an
in-depth
web
change,
you
need
to
understand
what
can
possibly
break
like
you
have
to
know.
You
have
to
be
able
to
grok
the
pr
enough
to
say,
like
I
understand
what
the
change
is.
For
example,
I
understand
that
tim
is
effectively
using
data
parameters,
passing
them
into
the
cncf
thing
and
therefore
it
can
render
things
correctly.
F
F
C
Part
of
the
difficulty
is
that
the
website
may
not
break
instantaneously
because
of
that
change.
It
may
be
like
a
rolling
change
that
cascades
downhill
we've
seen
a
couple
of
those
like
in
the
past
year,
where
only
weeks
later
did
it
become
evident
that
the
impact
of
a
visible
change
was
due
to
a
change
made
like
two
or
three
even
three
weeks
earlier.
A
C
I
He's
talking
about
this,
assuming
I
have
more
also
related
questions
about
the
about
reviews
and
and
the
pro
behaviors.
I
The
pr
is
assigned
to
someone
else,
but
that
one
never
comes
up
number
never
shows
up.
So
if
I'm
reviewing
the
pr
it
it,
it
looks
not
not
so
good,
I'm
not
respecting
people.
If
I'm
not
reviewing
it
that
pr,
that's
how
it's
there.
I
cannot
contact
the
people,
so
maybe
I
can
try
comment
some
names
other
thing,
but
I'm
not
deleting
them,
but
they
are
active
again
when
they
have
cycles
to
contribute
again.
I
C
If
I
recall
correctly,
there
is
specific
guidance
in.
C
In
the
community
page,
maybe
for
like
the
the
duties
for
reviewers
and
approvers,
there
is
a
stated
expectation
that
reviewers
remain
active
and
if
I
recall
correctly,
there
is
they
do
state
a
specific
window
for
activity,
and
I
recall
it
being
pretty
short,
maybe
as
short
as
30
days,
but
possibly
as
long
as
90
days.
C
But
I
don't
think
it's
longer
than
90
days.
So
if
you
wanted
to
be
very
conservative
and
very
generous
in
the
amount
of
time
that
a
reviewer
wasn't
active
before
you
commented
them
out,
90
days
seems
like
a
reasonable
window,
but
it
would
be
worth
double.
Checking
the
the
community
page
too.
Okay,
so.
I
I
A
Yeah,
I
believe,
that's
completely
fair,
reasonable
to
raise
the
pr
up.
I
know
for
some
other
teams
I've
been
involved
with
is
that
they
have
opened
up
prs,
removing
people
actively
and
tagging
them
in
the
pr.
A
Even
in
my
experience,
some
of
those
was
less
of
a
question,
but
at
least
raising
the
awareness
of,
and
at
least
the
example
of
the
release
manager
team,
actively,
removing
and
adding
folks
and
tagging
who
you're,
adding
or
moving
in
the
description
of
the
pr
is
a
way
to
notify
them
of
the
action
being
taken.
A
Personally
speaking
from
even
the
kubernetes
website,
the
english
approvers,
I've
noticed
the
same
thing
and
what
I've
done
in
the
past,
and
it
depends
on
what
the
situation
is,
but
I've
usually
dm
folks
on
slack
and
asked
hey.
Are
you
comfortable
with
me
removing
your
permissions
here
and
if
I
don't
hear
a
response,
I
will
take
that.
As
you
know,
general
level
of
comfort
of
me
removing
your
your
inability
to
to
act
as
an
approver
and
I
think,
a
lot
of
times.
A
People
have
the
mentality
that
the
the
removal
is
like
a
negative
or
a
and
punishing.
I
just
try
to
make
an
effort
myself
personally,
when
I'm
opening
these
pr's
to
be
very
clear
that
this
isn't
punitive.
This
is
not
a
punishment
like
if
somebody
wants
to
be
active
again,
there's
history
and
github
and
the
expectation
is
like
you
were
mentioning
if
they
have
cycles
they're
more
than
welcome
to
come
back
and
join
at
that
level
of
of
a
contributor.
So
I
don't
think
there's
a
few
things.
A
I'm
saying
there
is
just
generally
reaching
out
and
then
in
the
pr
also
expressing
that
it's
not
like
a
negative
action.
It's
hey
look.
We
need
reviewers
to
be
active
and
you
know
if
they
have
more
cycles,
they
can
definitely
come
back.
F
Yeah
we
just
missed
it.
It
was
last
week.
That's
okay,
I'm
happy
to
give
the
update.
If,
if
y'all
trust
me.
A
Awesome
sounds
good
to
me.
I
put
the
action
item
in
the
agenda
there
and
we'll
we'll
just
try
to
track
that
as
we
go
along
and
make
sure
that
that
we're
there
cool
so
we're
actually
pretty
much
up
on
the
hour.
We
have
about
five
more
minutes.
Does
anybody
have
any
other
topics
to
add
to
the
agenda
that
they'd
like
to
discuss.