►
From YouTube: K8s SIG Docs Meeting for 20210119
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
A
I
see
a
bunch
of
new
folks
right
tony.
I
saw
your
hand
up
go
up
first,
so
please
feel
free
to
introduce
yourself
hi.
B
C
A
Okay,
anyone
else
here
who's
knew
this
is
their
first
call
or
they're
fairly
new.
Here,
chandani.
D
Yep,
I'm
chani,
I'm
a
senior
software
engineer
at
mathworks.
D
I've
been
working
with
kubernetes
and
docker
since
past
three
years
and
just
trying
to
come
in
here
start
contributing
savita
from
my
company
at
mathworks
suggested
me.
This
should
be
a
good
start.
So
here
I
am.
A
Cool
other
new
folks,
I
think
there
are
still
more
anyone
else
want
to
say
hello.
F
A
Welcome,
I
think
we
might
even
have
more
people
still.
G
A
A
E
Okay,
well,
I
do
see
one
other
shadow
on
the
call
victor.
I
don't
know
if
you
are
free
to
say
a
few
words
to
introduce
yourself.
I
Yeah
hi
sorry,
I
was
trying
to
reply
to
some
some
emails,
so
I'm
victor
I've
been
selected
as
a
dog
shadow
for
121.
I'm
a
software
engineer.
I
worked
in
devops
as
well.
I
worked
for
atnt
red
hat
suse
adidas
and
today
I
work
for
a
smaller
company
called
decrease.
A
Cool,
well,
I'm
not
going
to
place
any
obligation
on
people
to
say
hello,
but
if
you,
if
you,
if
you're
only
you
want
to
choose
yourself
in
the
shared
agenda,
if
you've
got
access
or
in
a
slack
or
in
the
zoom
chat,
you're
all
welcome
to
take
any
of
those
options.
A
Okay,
let's
move
into
updates
and
reminders.
This
week's
pr
wrangler
is
only
dole.
Who
is,
I
don't
see
on
the
call,
but
I'm
sure
is
ready
and
waiting
to
wrangle,
and
next
week
is
celeste
horgan.
E
All
right
so
I'll
go
so
this
is
week
two
of
the
release.
This
week
we
are
on
boarding,
shadows.
Two
two
of
them
are
here:
shin
danny
and
victor
two
others
are
chi
ming,
who
is
a
sig
ducks
docs,
member
and
maria?
E
So
today,
I'm
going
to,
I
will
create
the
integration
branch
later
today.
I
do
have
a
question
and
I
might
table
this
or
slack
this
on
the
config.tamil.
E
If
we
need
to
last
for
1.20,
we
cr
we
updated
config.toml
towards
the
end
of
the
release,
but
on
the
handbook
we
stated
that
we
do
it
early
on.
E
So
I
will
do
some
confirmation
later
on,
like
when,
when
should
be
the
best
time
to
update
config.tomol,
like
does
the
integration
branch
need
to
point
to
the
old
version,
or
do
we
or
is
it
okay?
Is
it
best
off
to
update
it
towards
the
end
of
the
release.
A
L
I
was
going
to
say
that
it's
really
up
to
the
lead
of
the
release.
What
you
might
run
into,
if
you
update
it
early,
is
like,
let's
say,
hugo
versions,
change
or
anything
changes
in
the
config.tom
will
have
to
be
brought
back
in
which
should
happen
anyway.
L
You
might
deal
with
some
more
merge
conflicts
by
doing
it
earlier
than
later,
my
general
rule
of
thumb
or
recommendation
would
be
to
do
it
earlier
and
the
only
reason
I
say
that
is
because
you
would
then
see
in
the
page
previews
when
someone
creates
a
pr
to
that
branch,
you
would
see
that
version
drop
down
updated
correctly.
L
E
Building
updates
is
that
this,
this
week's
kind
of
light,
so
I'm
just
on
onboarding
shadows
this
week
and
for
people
who
have
worked
on
the
release.
We
know
that
the
sig
docs
roles
is
kind
of
starts
to
pick
up
after
enhancements,
freeze
so
doing
three
sessions
on
onboarding
and
that's
it
for
this
week.
A
So
if
you're
relatively
new
to
the
kubernetes
sig
docs,
one
thing
I'll
mention
is
that
we
work
with
usually
very
short-lived
branches
or
we
try
to
work
with
short-lived
branches
and
merge
individual
pr's,
with
the
exception
that
documentation
for
the
upcoming
release
is
a
long-lived
branch
that
lives
throughout
the
entire
release
cycle,
and
we
have
prs
that
merge
into
that
long.
Lift
branch
to
document
features
that
shouldn't
be
in
the
live
documentation
because,
unlike
say
the
kubernetes
code
repository
the
website,
master
branch
goes
live
as
soon
as
you.
A
A
Questions:
okay,
cool
thanks,
brad,
okay,
blog
update.
Does
anyone
wish
to
give
us
an
update
on
the
kubernetes.
A
A
So
let's
move
on
and
talk
about
updating
api
reference,
so
this
is
pr23204.
I
will
stick
that
in
the
chat,
so
people
who
are
not
sick
looking
at
the
gender
on
google
docs
can
see
it
as
well.
That's
not
the
chat
button
tim.
That
is
the
chat
button.
A
So
there's
the
link
I'll
give
people
a
moment
to
bring
up
this
pull
request
so
that
people
can
see
what
we're
discussing
here
and
then
I
wonder,
zach.
Would
you
because
you've
got
a
connection
to
this?
Would
you
be
willing
to
talk
about
this
this?
This
work.
M
Certainly,
excuse
me
this
will
be
so
briefly
for
context.
M
Last
year
we
had
a
google
season
of
docs
intern
philippe
martin,
whose
fellow
is
the
pr
contributor
and
philippe's
project
was
to
update
the
way
that
we
generate
and
present
api
reference
documentation
for
kubernetes
and
the
guts
of
the
thing
have
merged.
I
think
either
late
last
year
or
very
early
this
year,
and
this
particular
pr
is,
if
I
understand
correctly,
is
now
the
generated
results
of
the
actual
generation
mechanism.
M
The
generation
mechanism
itself
lives
in
a
kubernetes,
sigs
or
kubernetes
sigs
organization
repository
and
the
way
that
reference
generation
docs
work
is
that
we
run
the
api
generation
from
the
code
that
lives
in
the
kubernetes
cigs
repository
and
then
merged
the
results
into
the
website
repository.
M
So
this
is
the
generated
results
and
if
I
understand
correctly,
where
we
are
the
we're
currently
discussing
what's
needed
in
order
to
merge
this
successfully
with
a
minimum
of
breakage,
am
I
doing
that
justice
tim.
A
Yeah,
I
think
that's
an
excellent
summary.
Thank
you
very
much.
Zach
karen
bradshaw
I'd
see
you've
joined
the
call.
Thank
you
very
much
really
pleased
to
see
you
here
as
well.
We
are
talking
about
the
pr
from
feli
philippe,
which
is
pull
request.
Two
three,
two,
nine
four
karen
is
there
anything
you'd
like
to
say
about
this.
A
I
mean
I
know
that
you've
you've
definitely
been
very
active
in
reviewing
this
pr
in
its
journey
to
today.
You
might
not
have
seen
the
latest
thing
if
there's
anything
you'd
like
to
say
about
generally,
you
know
your
views
on
what
we
should
do
and
how
things
are
going.
Then
here's
an
opportunity
for
you
to
speak.
K
I
only
get
one
second,
no,
which
pr
are
we
talking
about
here.
I'm
sorry.
A
K
A
Just
also
checking
for
raised
hands
rather
than.
K
A
K
Anyone
else
talking
so
what's
what's
the
question
I
mean
this
has
been
going
on
for
a
long
time
right
and
it
seems
like
it's.
It's
been
thoroughly
reviewed,
but
by
a
small
set
of
people.
So
if
you
think
that
there
should
be
a
larger
set
of
people
engaged
to
review
it,
then
now's
the
time
to
do
it,
because
it's
it's
just
I
don't
know
it's
been
months
and
months
and
months
of
work.
So
I
think
it's
you
know
it
represents
a
new
way
of
displaying
the
api
resources.
K
But
right
now
we
have
the.
I
think
the
original
plan
was
to
actually
maintain
the
the
one
page
reference
side
by
side
with
the
new
pages,
until
we
felt
that
we
were
ready
to
remove
the
one
page
reference
and
there
are
remaining
questions
that
are
outlined
in
the
pr
and
you've
brought
up
a
few
timmy
few
questions
yesterday.
I
guess
so
so
I
don't
know
what
people
think
about
moving
it
forward.
K
M
Karen
I
notice
one
of
your
pieces
of
feedback
was
about
breaking
bookmarks
and
about
see.
Where
is
it?
There
will
be
broken
external
connections
to
the
single
page
reference?
I
think
that's
absolutely
true,
and
I
also
don't
know
that
it
should
be
a
blocker.
I
think.
M
Cool
I
was
about
to
go
into
the
whole
song
and
dance,
but
if
we
agree
then
I.
K
Totally
agree,
I
I
think
it's
a
it's
just
the
way
it
goes,
so
I
don't
see
it
as
a
blocker.
I
see
it
as
kind
of
we're
taking
a
step
forward
in
kind
of
a
new
direction,
and
you
know
that's
the
way
it
goes.
M
Fair,
I
don't
recall
talking
about
maintaining
the
references
side
by
side,
but
I
I
frankly
think
that's
a
that's
a
good
idea.
You
know
if
we
wanted
to
frame,
why
we're
doing
that,
we
could
certainly
call
it
like
a
either
an
alpha
or
a
beta
feature
for
testing
use
the
the
liveness
of
it
to
test
in
production
and
do
do
all
the
cleanup
work
and
get
the
thing
out
there.
M
At
this
point,
I
think
we're
at
the
stage,
as
you
say
karen,
where
the
same
pool
of
folks
has
reviewed
this
so
many
times.
I
don't
know
that
we're
going
to
get
any
new
wisdom
or
any
particular
breakthroughs
out
of
this
until
we
see
what
happens
with
it,
live
on
the
site,
so
maintaining
a
side-by-side
reference
availability
with
both
the
existing
model
and
the
the
the
newly
generated
model,
I
think,
makes
sense.
M
I
do
think
that
this
is
a
time-boxed
solution,
because
by
merging
the
mechanism
in
kubernetes
cigs,
we
basically
have
this
release
cycle
to
to
do
things
about
that
that
need
to
be
fixed
and
then
we're,
I
think,
fully
committed
for
1.21.
If
I,
if
I
understand
correctly.
A
Okay,
really
good
summarizing
there,
karen
and
zach
the
concern.
I
think
that
that
you
thought
was
from
carrie
is
actually,
I
think,
mine
zach,
that
I
was
concerned
about
potential
for
breaking
hyperlinks
and
it's
a
concern
I
still
have.
I
I
like
the
idea
that
we
run
them
in
parallel,
because
that's
a
much
more
generous
way
of
moving
forward
than
than
suddenly
breaking
all
the
links
that
exist
so
yeah.
A
Sorry,
I'm
trying
to
talk
and
get
the
document
open
and
feel
a
bit
like
a
meeting
chair.
At
the
same
time.
M
So
tim,
I
wonder
if
so
it
that's
a
valid
concern
about
breakage.
I
wonder
if
we
could
adapt
one
of
our
existing
deprecation
warning
short
shortcodes
for
the
api
reference
and
apply
that
to
the
1.20
page,
to
give
folks
a
warning
that
that
we
are
moving
to
the
to
the
new
reference
generation
model
and
just
broadcast
clearly
that
folks
will
need
to
update
their
links
due
to
impending
breakage.
C
C
M
It
will
probably
have
the
least
seo
impact
if
we
do
the
cut
over
at
at
the
release.
Sorry
during
a
release
cycle
or
like
at
the
actual
release
time,
because
that
is
sort
of
the
periodic
window
when
our
results
generate
or
when
links
start
to
repoint
to
the
most
current
version
rather
than
the
previous
version.
That's
our!
What
our
robots
do,
I
think,
do
we,
we
have
a
robots.txt
that
gently
suggests
that
scrapers
use
the
most
modern
version.
If
I,
if
I
think
so,.
A
A
I
think
I'll
put
this
you
know
I'll
put
this
for
discussion
is
that
we
could
merge
the
revised
api
reference
and
then,
for
some
time
I
hope
just
a
few
weeks,
mark
it
as
not
indexable
or
ask
circs,
and
you
cannot
to
index
the
new
new
reference.
Whilst
we
work
out
what
the
application
strategy
is,
but
we
get
it
merged.
A
L
Curious
if
we
should
be
doing
more
pr,
maybe
like
a
community,
the
mailing
list
for
kubernetes
developers
announcing
that
we're
running
these
side
by
side.
Potentially,
you
know
reiterating
this
in
some
of
our
meetings,
I'm
just
thinking
of
how
we
can
advertise,
maybe
a
blog
post
or
something
similar
to
that.
So
folks,
don't
think
we
come.
You
know,
fly
by
night
and
switch
out
their
api
reps
and
break
all
their
bookmarks
and
then
go
back
to
our
own
dwellings.
A
M
If
it
helps
tim,
there
was
a
blog
post
late
last
year
from
philippe
about
the
project
and
about
the
the
new
way
of
generating
api
reference.
It
was
really
close
to
the
holidays,
so
I
don't
think
it
got
a
lot
of
visibility,
but
there
is
a
blog
post
to
which
you
can
point.
A
Yeah,
so
we've
got
the
blog
post.
I
think
we
can.
You
know,
I
think
I
think
an
amount
of
pr
campaign
is
appropriate
and
I
I
think,
is
there
another
group
that
I
should
talk
to
within
the
the
wider
kubernetes
project
about
communicating
this
sort
of
thing.
M
A
Okay,
anyone
who's
not
spoken
already
and
has
questions
or
views.
I'm
gonna,
I'm
gonna
give
a
bit
of
time
now.
So,
if
you've
not
spoken
already
on
this
topic,
please
here's
your.
A
L
Quarterly
reviews
and
planning
yep,
so
I
put
in
a
slack
chat
robot
and
for
the
folks
who
are
just
joining
us.
Let
me
back
up
and
give
a
little
context
on
this,
so
part
of
sick
docs.
We
definitely
do
kind
of
the
day-to-day
operations
and
work.
You
know,
wrangling
prs,
making
sure
tech
reviews
are
in
place,
docs
reviews,
etc,
etc.
L
We
also
have
the
release
team,
which
you
know
ray
and
we've
chatted
about
earlier
in
this
meeting,
and
on
top
of
that
we
do
quarterly
planning
sessions,
and
what
that
is
is
where
we
take
a
look
at
the.
I
guess,
broader
strokes
of
what
sig
docs
is
responsible
for,
and
we
make
sure
that
we
have
a
plan
in
place
for
what
we
want
to
achieve
so
major.
I
guess
accomplishments
major
action
items
that
can't
be
accomplished.
L
You
know
I
guess
asynchronously
in
slack,
so
it's
a
good
way
for
all
of
us
to
come
together,
set
some
goals
that
are,
you
know,
spanning
quarters
months
years.
What
have
you
and
attract
those?
So
what
I
wanted
to
talk
about
is
the
q4
review,
q1
and
q2
planning,
and
what
I
wanted
to
bring
up
is
the
fact
that
you
know
we
we
kind
of
hit
the
holidays
hard
late
in
the
year,
and
we
we
planned
the
q4
really
late
in
the
session.
L
We
were
a
little
late,
getting
started
there
and
now
we're
already
in
q1
kind
of
rolling
forward
there
and
we
haven't
yet
reviewed
q4.
My
thing
that
I
wanted
to
bring
up
for
this
group
is:
do
we
want
to
just
start
with
a
q2
planning
kind
of
bundle
in
q4
and
q1
together?
And
I
don't
know
what
folks
thoughts
are.
That's
why
I
wanted
to
get
feedback
from,
but
really
I
think
we
lost
a
lot
of
time
with
the
holidays
with
cube
county
you
I
think
at
least
I
can
speak
for
myself.
L
I
had
a
hard
time
getting
started
earlier
this
year
and
I'm
starting
to
get
the
train
back
on
the
tracks
and
I
think
if
we
were
to
have
a
q1
planning
and
review
session,
we're
going
to
find
ourselves
doing
a
q2
review
and
planning
session
almost
immediately
after
that
to
get
back
on
track.
So
I'm
pitching
the
idea
of
doing
a
kind
of
combined
q4
q1
review
and
then
do
a
q2
planning
session
here
in
the
next
couple
weeks,
and
I
want
to
get
some
feedback
on
that.
L
Cool
sounds
good
awesome.
Let's
play
let's
plan
on
that,
then
we'll
plan
on
scheduling
a
q4
q1
review,
cue,
one
being
kind
of
an
implied,
q4
carryover
and
then
q2
planning
and
I'll
get
that
scheduled
here
shortly.
A
Sounds
good.
Okay.
Next
up
is
an
item
I
put
on
the
agenda
about
github
discussions,
so
github
has
added
a
new
feature
that
I
think
is
available
to
some
organizations,
github
discussions.
So
do
I
have
questions
about
what
github
discussions
look.
A
Essentially,
it
looks
a
lot
like
the
discussion
that
you
can
have
in
a
github
issue
without
having
an
issue
issue
description,
and
they
I
mean.
I
bet
the
code
looks
pretty
similar,
but
they
let
you
have
a
discussion
on
a
topic
without
having
to
say.
Oh,
this
is
a
bargain.
This
is
a
feature.
This
is
something
a
bit
more,
you
know
a
bit
different
and
there
are
some
things
which
are
going
to
live
a
long
time
that
you
know
maybe
especially
contentious.
A
I
think
we
might
have
used
that,
for
example,
for
let's
localize
the
documentation
or
how
are
we
doing
banners
there
are.
There
are
topics
where
discussions
make
sense
and
the
sort
of
the
rules
of
moderation
can
be
a
bit
different
for
issues.
A
So
what
do
people
think
about
that
release
might
be
another
one
right.
You
might
have
a
view.
E
So
I
sig
release
is
already
using
this
feature
for
some
topics,
so
it's
already
implemented
by
some
some
by
sig
release.
I
am,
I
am
one
in
favor
of
it.
That's
my
personal
opinion,
where
there
is
example,
is
for
for
a
release
cycle.
We
create
an
issue
to
track.
Who
is
the
localization
contact
for
each
language?
E
A
Cool
thanks
ray
any
any
more
thoughts.
Anyone
not
keen
on
it,
but
also
anyone
just
want
to
say
you
know
what
they
feel.
N
Hey,
I
had
a
question
so
I'm
familiar
with
the
the
other
items
that
you
mentioned
tim.
You
know
slack
github
issues,
maybe
some
comments
and
a
pr
these
calls
right
here.
Do
we
run
the
risk
of
discussion
tool
overload
or
maybe
not
being
all
on
the
same
page
in
terms
of
this
would
be
the
right
place
to
have
this
discussion
so
to
speak.
A
I
guess
what
I
would
add
is
that
we
can
be
confident
that
all
contributors
have
got
github
access.
Some
may
not
be
able
to
access
slack.
I
think
we
have
some
contributors
who
cannot.
L
L
Chris
has
a
very
valid
concern
about
communication
overload,
but
I
think
if
there
are
specific
reasons
for
using
github
discussions,
like
you
mentioned,
such
as
the
release
team
or
you
know
what
have
you,
I
think
it
makes
sense
for
a
very
specific
purpose,
but
I
don't
think
it
should
be
a
kind
of
open
can
of
worms
of
you
know.
Are
we
in
slack?
Are
we
in
issues
or
we
have
discussions,
have
very
clear
purpose
for
the
use
of
it,
but
other
than
that
it
seems
like
a
reasonable
suggestion.
J
A
Okay,
I
think
what
I'm
hearing
there
is
like
soft
soft
minus
naughts,
but
no,
no,
no,
no
strong
objections,
and
I
think
I'm
I'm
seeing
consensus
that
for
specific
topics
it
is
appropriate.
A
Does
that
look
right?
I'm
seeing
nodding
cool
okay
thanks
for
that
discussion,
discussion,
people,
and
because
we
have
so
many
new
contributors
on
the
call.
This
is
a
large
number
of
new
contributors.
A
Let's
spend
a
few
minutes
with,
I
guess:
if
people
want
to
you
could
and
you're
not
a
new
contributor.
This
could
be
a
moment
to
drop
off,
but
for
everyone,
who's
interested.
Let's
have
a
discussion
about
helping
people
who
are
new
to
sick
docs,
make
their
their
first
contribution
or
or
their
second,
if
you're,
if
you're
new,
but
not
that
new.
So
that's
what
we'll
talk
about
now.
N
I'm
so
I
I
had
one
tim:
I've
been
sort
of
passively
monitoring.
What's
going
on
here,
I'm
working
on
another
project,
but
I
find
the
whole
thing
extremely
interesting
and
hope
to
learn
from
it.
So
my
question
is:
is
there
some
sort
of
sample
pipeline
that
we
could
take
a
look
at
or
is
there
some
place
that
we
could
maybe
practice
or
come
up
with
a
like
an
example
pr
from
looking
at
it
then
commenting
on
it
and
then
doing
that
sort
of
thing.
N
So
I
guess
my
question
is:
is
there
some
place
where
we
could
look
at
again
the
the
whole
pipeline
from
pr
submission
to
reviewing
it?
So
I
guess
we
could
practice.
I
guess
for
for
lack
of
a
better
term.
A
Sure,
okay,
thanks
chris,
anyone
feel
like
they'd,
particularly
like
to
answer
that
question.
L
This
doesn't
need
review,
I'm
just
sampling
or
testing
this
out.
Potentially
I
I
believe
that
would
be
welcome
to
the
community.
It
also
might
be
a
little
bit
of
noise
for
folks,
but
I'm
happy
to
hear
objections
to
that,
but
I
would
have
no
problem.
Seeing
hey
I'm
a
new
contributor,
I'm
just
testing
this
out.
You
know
no
one's
going
to
bite
your
head
off
for
for
trying.
N
A
So
I
will,
I
will
mention
as
well
that
github
has
a
facility
to
open
a
pull
request
as
the
draft
as
draft
or
to
convert
a
pull
request
to
draft,
but
also,
if
you
haven't
found
that
button.
Just
like
what
jim
said,
if
you
opened
a
pr-
and
he
said
I'm
just
trying
things
out
and
you
didn't
find
the
draft
button,
like
don't
think.
Oh,
my
god,
I
can't
open
this
this
pr,
because
I've
not
found
the
draft
button
tim
mentioned.
A
I'm
going
to
add
into
the
chat
the
list
of
good
first
issues
or
the
the
filter
that
you
can
you
go
to
this
link
and
see
our
current
good
first
issue
list
yep
this.
Essentially,
if
you
find
an
issue
here,
then
anyone
is
welcome
to
open
the
pr
that
addresses
these,
but
we
especially
recommend
that
people
save
these
for
those
folks
for
whom
it's
their
first
or
second
issue,
so
that
these
are.
Ideally,
these
are
issues
that
are
straightforward
to
get
going
with.
A
M
Yeah,
I
just
pasted
a
link
in
the
chat
chris.
You
can
see
what
the
process
looks
like
for
an
entire
pr
from
opening
to
discussion
to
merge
by
looking
at
the
list
of
merged
prs
for
the
repo,
and
you
could
oftentimes
you'll,
see
like
in
the
header
that
there's
also
a
linked
issue.
You
can
look
at
closed
issues
as
well,
and
that
will
give
you
an
idea
of
what
discussion
on
issues
looks
like
that
leads
to
prs.
That
leads
to
approval.
M
Maybe
the
most
non-intuitive
piece
of
merging
prs
is
interacting
with
prow
prow
is
the
kate
ci
robot
sorry
gates
is
an
abbreviation
for
kubernetes.
That
was
that
wasn't
clear
the
kci
robot.
It's
a
chat,
bot
style
bot
that
wrangles
commands
for
repository
actions.
M
So
that's
why
you'll
see
like
slash
commands
like
slash
lgtm,
that's
actually
command
to
the
ci
robot,
so
yeah,
but
take
your
pick.
You
can
look
through
that
list
and
get
a
survey
of
what
what
discussion
and
approval
looks
like
excellent.
Thank
you.
Zach.
N
Oh
yeah,
I
saw
that
that
was
that's
what
sort
of
sparked
my
interest.
M
C
Is
it
safe
to
say
that
if
the
issue
is
assigned
to
someone
that
it's
going
to
be
active
being
actively
worked
on
by
that
someone,
or
is
it
worthwhile
to
ask?
Is
this
something
you're
working
on
or
that
I
could
try
out
for
those
good
first
issues
just
because
there
are
so
many
of
them
that
are
already
assigned
to
people?
M
So
we
have
what's
called
a
no
cookie
licking
policy
if
you're
familiar
with
you
lick
a
cookie
to
say
this
is
mine,
so
yeah
there's
a
no
cooking
cookie,
licking
policy,
but
just
because
of
an
issue
is
assigned
to
someone
doesn't
mean
that
other
people
can't
work
on
it
so
absolutely
feel
free
to
chime
in,
say,
hey,
I'm
interested
in
working
on
this
as
well,
honestly
feel
free
to
open
a
poll
request
if
there's
not
already
a
pull
request,
that's
actively
being
reviewed
for
a
particular
issue,
open
a
pr,
because
an
open
pr
is
gonna
mean
a
lot
more
in
the
end
than
somebody
assigning
something
to
themselves.
A
I'll
go
on
mike
sorry,
I'm
not
going
to
talk
over
you.
I
was
just
saying
thanks,
in
which
case
I've
got
an
anecdote,
then,
which
is
the
extent
to
which
we,
I
think
we
live.
This
policy
is
that
we
actually
had
two
people
spot,
that
some
deprecated
documentation
or
some
deputy
deprecated
api
for
pod
preset
had
not
been
removed.
We'd
missed
that
out
in
the
1.20
release
process
and
we
should
have
removed
it.
We
didn't
and
two
people.
I
opened
basically
identical
pr's
and
pull
requests.
A
They
require
a
review
and
an
approval,
and
you
don't
have
to
worry
about
that.
If
you're,
a
new
contributor
we'll
take
care
of
that
for
you,
but
if
you
keep
contributing
we'll
invite
you
to
become
a
reviewer
and
then
you'll
have
to
learn
about
it
and
what
I
did
was
I
got
the
person
open,
the
second
pr
who
happened
to
be
a
reviewer,
and
I
was
like
okay,
that's
great!
Thank
you.
This
other
one
came
in
a
couple
of
hours
before.
Would
you
go
and
review
it?
L
But
there's
no
problem
there
and
one
quick
thing
I
did
want
to
add
too
is
even
though
there
is
the
no
cookie
looking
policy.
Sometimes
cookies
do
get
licked,
and
so
what
I
want
to
mention
is
if
you
were
to
see
an
issue
that
looks
like
somebody
was
assigned,
let's
say
four
or
six
months
ago,
or
it
looks
like
it
might
be
inactive,
there's,
no
shame
or
no,
I
guess
punitive
action
to
go
into
slack
and
saying:
hey.
Look,
I'm
wondering.
Is
this
active
or
commenting
on
that
issue
itself?
L
I
guess
what
I'm
getting
at
is
just
because
someone's
assigned,
if
it
looks
like
they
have
been
enacted
for
a
certain
amount
of
time.
It's
an
issue
that
you're
interested
in
working
on
try
to
reach
out
to
the
individual
reach
out
to
sick
docs.
The
slack
channel
like
I
said
I
think,
we're
a
pretty
friendly
bunch.
I
hope
and
looking
to
help
you
know
contributors
be
successful
in
any
way.
We
can.
A
D
A
I
guess
I'll
have
a
try
and
answer
that
so
kubernetes
has
a
blog.
If
you
go
to
k
s
dot,
io
blog,
we
have
some
articles.
In
fact,
I
wrote
one
of
them
and
we
published
that
using
the
same
mechanisms
that
you
can
read
about
in
our
documentation
readme.
So
it's
it's
a
hugo
site
generator
and
the
hugo
tool
has
built-in
support
for
blog-like
content
and
that's
what
we
use.
A
There
are
a
couple
of
sub
teams
in
sig
docs
and
the
blog
team
is
its
own
little
team.
So,
if
you're,
putting
a
blog
article
up,
the
blog
team
will
approve
that.
I
mentioned
that
review
and
approval
are
slightly
separate
processes.
Blog
articles
want
review
from
the
blog
team.
Usually
unless
that's
really
urgent,
we
might
bend
the
rules
a
little
bit
with
with
good
reason.
A
A
You
know
it
is
blog
content,
so
it's
it
doesn't
have
to
stand
the
test
of
time
in
quite
the
same
way
that
other
content
does
we,
we
always
publish
in
english
first,
both
for
the
blog
and
for
the
main
website
and
where,
on
the
main,
documentation
we're
a
bit
wary
of
putting
in
solutions
that
talk
a
lot
about
technologies
outside
of
kubernetes
there's,
I
think,
there's
a
bit
more
scope
in
the
blog
to
explain
how
kubernetes
works
with
things
and
explain
kubernetes
in
the
real
world,
even
if
the
idea
isn't
completely
complete
so
long
as
it's
informative,
that's
a
kind
of
article
we're
welcome.
A
A
Welcome
any
questions
about
the
blog
because,
there's
more
to
say.
A
Cool,
if
you're
thinking
of
suggesting
a
blog
article,
then
absolutely
we.
We
would
absolutely
welcome
blog
articles.
It's
not
a
way
of
contributing
that
I've
mentioned,
but
a
good
way
to
get
started
is
to
open
an
issue
and
then
open
the
pr
for
it.
With
the
blog
article.
A
You
can
also
sort
of
talk
to
the
blog
team
and
start
drafting
something
like
a
google
doc
or
something,
and
the
blog
team
will
help.
You
take
the
text
that
you're
thinking
of
and
turn
it
into
a
blog
article.
So
if
you're
not
familiar
with
markdown
or
with
web
development
and
you're
more
of
a
writer
than
a
web
developer,
there's
help
there
to
get
your
your
thoughts
onto
onto
the
screen
as
well.
A
The
same
goes,
if
you
know
people
who
are
you
know
good
at
writing.
Good
at
communicating
not
mark
down
writers
by
any
means,
we'll
work
with
them,
and
we
have
people
in
the
communities
project
who
are
very
happy
to
help.
A
Okay,
don't
forget
we're
on
slack
if
you've
not
joined
slack,
you
can
go
to
slack.kubernetes.io
and
request
an
invitation
to
join
the
kubernetes
slack
organization,
and
then
you
can
find
us
in
a
channel
called
sig.
Docs
last
call
for
any
thoughts
on
this.