►
From YouTube: Kubernetes SIG Docs Meeting for 20210202
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
welcome
to
the
weekly
sig
docs
meeting.
It
is
february
2nd
2021,
which
is
crazy
february.
Already,
I'm
jim
angel
a
co-chair
of
sick
docs,
kicking
off
our
regular
weekly
meeting
here.
So
before
we
get
started
started.
I
know
we
were
just
chatting
because
the
comment
feel
so
just
start
chatting
with
cameraville
about
new
contributors
and
I'd
like
to
give
an
opportunity
cameraville,
if
you'd
like
to
introduce
yourself
as
well
as
if
there's
anyone
else
joining
us
who
is
new.
B
Well,
hello,
I'm
from
uruguay.
I
think
my
video
stream
is
good,
but
I'm
not
sure
so
you
tell
me-
and
I
just
want
to
be
here
and
mostly
in
mute
mode
because
I
just
want
to
I
don't
want
to
participate.
I
just
want
to
listen.
Maybe
a
few
questions
I
will
be.
I
will
do
some
questions
on
the
chat,
but
not
too
much
talk.
If
you
agree
with
that
or
if
you
have
any
personal
question
or
you
need
to
know
more
about
me,
just
ask-
and
I
will
own
my
boom
yet
to
microphone.
A
B
One
more
thing
I
say
this
to
jim,
but
not
to
everyone,
I
I
will
learn
the
process
of
contributing
the
documentation
and
I'm
not
get
I'm
not
ready
yet.
So.
Thank
you
for
your
contribution
to
to.
Let
me
know
how
this
works.
A
Awesome
yeah:
that's
that's
exactly
what
we're
here
for
and
happy
to
help
out
and
what
I
added
to
the
agenda.
We
have
a
relatively
short
agenda
today.
I
believe
so.
A
A
C
Well,
happy
to
have
you
do
you
want
to
take
over
for
the
status
out
for
one
yeah
so
for
the
release
1.21
for
really
stocks,
the
status
is
green.
Last
week
we
did
a
branch
sink
for
the
dev
121
branch,
and
that
was
merged.
Have
the
pr
listed
in
the
agenda
a
week
from
today
is
enhancements.
Freeze,
so
that's
on
february
9th
there
are
32
enhancements,
curling,
there's
actually
34.
C
Now
that
number
is
going
to
fluctuate
until
until
enhancements
freeze,
so
that
even
this
32
might
be
40,
it
might
be
35
or
it
might
be
28
my
next
week.
So
keep
that
in
mind
also.
I
am
starting
to
sign
this
enhancements
to
the
rest
of
the
docs
team
and
so
we'll
have
that
finalized
at
the
end
of
the
end
of
the
week,
and
that's
it
for
me.
A
Awesome
sounds
great
and
if
you
I
know,
I
brought
this
up
last
week
about
something
that's
coming
down
the
pipelines
this
week.
I
think
you
would
do
it.
Do
it
more
justice.
Talking
to
this
point,
if
you
don't
mind
explaining
a
little
bit
about
what
you
wanted
to
bring
to
zigdac
awareness
and
how
we
can
help.
D
Yeah
so
hello,
everyone,
I
am
the
band.
D
I
have
worked
with
the
sick
dogs
before
for
the
as
a
release
channel
for
the
release
stocks
in
1.19
this
this
cycle
and
the
release
comes
lead,
and
we
we
tried
to
streamline
the
process
around
communications
for
every
release,
since
it's
not
so
well
structured,
and
it
mostly
involves
us
going
around
and
asking
a
lot
of
folks
for
the
the
feature
blogs
and
then
having
a
last
a
couple
of
days
after
the
cycle
ends
trying
to
get
reviews
in
and
that's
potentially
something
we
want
to
avoid
this
cycle.
D
So
one
of
the
things
that
we
were
looking
at
doing
is
actually
setting
some
soft
deadlines
around.
D
You
know
the
feature,
block
delivery
and
the
merging
the
merging,
of
course,
will
draw
from,
I
think,
tim's
automation
when
we
can
specify
the
merge
or
publish
it
prior
and
prior
to
the
you
know
when
we
actually
write
the
blog
actually,
so
we
can
do
that,
but
I
you
know
I
wanted
to
hear
your
views
as
well,
so
that
you
know
we
all
as
a
team
could
work
together
and
have
a
consensus
on
the
way.
D
The
feature
blogs
are
published
and
reviewed
because
that
that
was
one
of
the
pain
points
that
came
up
last
release
during
the
retro.
So
that's
point
a.
D
The
second
point
is
that
there
is
also
a
major
deprecation,
that's
going
in
the
cycle,
but
we
haven't
figured
out
how
to
you
know
sort
of
the
communication
process
around.
It
hasn't
been
again
streamlined
because
we,
we
are
still
in
the
in
the
phases
wherein
the
alternatives
haven't
actually
been
put
in
place
and
sick
contrabex
actually
has
been
working
on
a
blog
for
that.
So
I
also
wanted
your
views
on
how
we
could
publish
this
blog
better
in
a
better
fashion,
in
order
to
avoid
the
document.
D
You
know
that
happened
last
cycle,
so
this
is
a
deprecation
for
the
psp
policies
and
as
of
now,
we're
trying
to
the
cigar
folks
are
trying
to
get
in
the
alternatives
into
this.
You
know
cycle,
but
in
the
form
of
a
kvp,
but
it's
not
it
might
or
might
not
be
possible
and
that's
something
we'll
only
know
once
the
enhancement
fees
is
in.
D
So
I'm
not
sure
how
how
to
figure
out
the
dates
around
this
and
we've
been
having
discussions
with
the
release
leads,
and
you
know
the
enhancement
owners
as
well.
So
wanted
your
opinion
as
well.
On
this.
A
A
A
You're
here
not
a
lot
of
volunteers
here,
no
big
deal,
so
my
thoughts
are
on
the
process
is
really
and
let
me
back
up
and
give
a
little
bit
of
context
on
the
release
process
as
it
pertains
to
communications,
I
want
to
say
in
the
early
teens
you
know
1.11
1.12,
of
the
kubernetes
release
cycle.
A
The
communications
were
originally
handled
by
the
cncf.
There
was
an
official
person
delegated
from
the
cncf
to
help
get
those
communications
out
the
door
and
it
was
kind
of
like
they
did
it.
We
didn't
really
worry
about
it
and
never
kind
of
went
along
doing
their
own
thing.
There
was
a
decision
maker
and
kind
of
a
leader
in
that
process,
and
since
then-
and
this
is
totally
my
opinion-
it's
possible-
it's
different.
A
I
haven't
worked
in
the
the
actual
comms
special
interest
group
or
the
release
team,
but
it
seems
like
what
has
happened
over
the
past
couple
of
release
cycles,
at
least
as
of
late.
Is
it's
more
of
a
community
effort?
It's
more
volunteer
based
more
contributor
based
and
what's
happened
is
there's
no
real,
clear
leader.
There's
a
lot
of,
I
guess
interested
parties
such
as
big
doc.
The
release
team
folks
are
trying
to
get
enhancements
in,
but
there's
no
clear
person
to
say
this
needs
to
go
out
the
door
at
this
time.
A
You
know,
and
that's
kind
of
my
two
cents
and
and
where
I'm
at
today
but
happy
to
hear
other
folk
thoughts.
E
I
guess
my
opinion
is
that
deprecation
is
such
a
duplication
of
something
like
pod
security
policy
is
such
an
important
thing
that
if
we,
if,
if,
if
we
had
a
comes
person
and
they
reached
out
to
the
sick
and
the
sig,
was
like
oh
we're-
we're
reluctant
to
do
comms
we're
at
capacity,
we
can't
liaise
with
you
to
get
the
comms
out
on
time.
I
would
be
like
thinking
delay
the
deprecation
or,
like
you
know,
turn
the
release
red.
It's
that
important.
D
Yeah,
so
I
agree
with
you
tim
in
that
respect,
but
we
have
a
blog
and
we
have
a
sort
of
you
know
outline
ready,
but
the
problem
here
is
that
when
we
are
suggesting
a
deprecation,
we
obviously
have
to
sort
of
outline
the
alternatives
as
well,
and
alternatives
is
something
that
specifically
hasn't
been
addressed.
Yet
I'm
not
I'm
not
taking
a
look
at
the
kp's
yet
because
my
laptop
unfortunately
crashed
a
couple
of
hours
ago
and
I've
been
trying
to
revive
it
but
yeah.
D
That's
that's
where
we
were
at
in
the
morning
when
I
checked,
and
there
was
no
alternative,
there
were
no
alternatives
outlined
for
that
specific
deprecation
and
if
we
actually
put
out
a
block
saying
that
hey
this
particular
feature
is
going
to
be
deprecated
and
what
this
means
for
you
as
an
end
user.
We
also
have
to
sort
of
give
the
other
side
of
the
coin,
wherein
we
lay
out
the
alternatives.
D
So
that's
why
we're
currently
holding
out
on
you
know
the
on
releasing
the
blog
and
I
guess
cigar
folks
have
sort
of
gotten.
I
don't
know,
do
you,
how
do
you
put
it?
So?
A
lot
of
folks
have
been
instrumental
in
getting
the
blog
in
place
and
sigoth
has
sort
of
contributed
their
technical
expertise
and
the
contributor
experience
guys
have
actually
gone
through
the
law
once
the
pains
of
actually
writing
the
blog.
D
So
a
rough
draft
is
ready,
but
we
are
going
to
be
holding
back
and
understanding
what
would
be
the
alternatives
if
they
are
going
in
this
cycle.
If
not,
we
have
to
give
the
end
user
a
broad
list
of
available
stuff,
that's
already
available,
so
yeah
that
that
was
a
plan,
but
I
was
not
really
sure
of
how
to
actually
go
ahead
with
the
publishing.
D
So
that's
that
that's
what
me
and
nabaroon
and
me
and
stephen,
and
a
lot
of
folks
from
segota
and
contrabax
have
been
discussing
so
far,
because
one
viewpoint
is
that
if
we
are
actually
going
to
be
publishing
something
before
the
release,
it's
it's,
we
need
to
decide
a
timeline
again.
How
soon
is
it
to
publish
a
blog
and
how
soon
is
it
to
actually,
you
know
disclose
that
sort
of
information.
D
On
the
other
hand,
if
we
actually
put
it
after
the
release,
it's
going
to
be
like
the
talkation
panic
that
happened
last
cycle,
so
we
we
need
to
sort
of
decide
on
that
timeline,
and
I
was
looking
for
your
opinions
as
well
on
that
if
you
had
any
sort
of
views
around
when
this
could
be
published,
so
this
I'll
be
communicating
back
to
the
release
lead
tomorrow.
D
F
D
Yeah
we
sort
of
had
that
last
cycle
when
our
applicator,
but
it
was
unnecessary
panic
and
it
was
because
there
was
a
tweet
and
someone
had
gotten
a
look
at
one
of
our
release
notes.
I
guess-
and
I
loaded
up
out
of
proportion.
So
a
lot
of
folks
had
to
come
in
and
mitigate
the
impact
that
it
had
caused
by
reassuring
folks
that
it's
not
that
big
a
deal
so
yeah.
F
Having
having
seen
my
organization
red
hat,
go
through
this
recently
on
a
completely
different
issue,
you
know
it's
it's
never
too
soon
to
send
out
bad
news.
I
understand
that
you're
waiting
for
more
detail,
more
alternatives,
but
the
way
you
can
do
is
you
can
stage
it.
You
can
say
yeah.
F
Here's,
some
bad
news
coming
your
way
this!
These
are
the
alternatives.
We
know
about
we're,
not
sure
about
this
area
and
we'll
we
will
communicate
with
you
we'll
follow
up
with
you
on
this
date.
So
let
them
know
specifically
when
your
follow-up
comms
will
come
out
and
in
some
sense
they
may
wait
and
hold
back
for
that.
F
E
Essentially,
deprecation
is
telling
people
that
that
it's
not
going
to
be
available
in
the
future,
so
they
can
get
begin
planning
for
it.
So
we're
planning
about
the
comms
around
the
deprecation
announcement.
Really
I
mean
I
I
don't
know.
E
I
think
it's
pretty
set
in
stone
and
it's
going,
but
I
don't
know
that,
like
it's
a
hundred
percent
going
like
if
there
was
a
real
problem,
I
guess
we
could
put
security
back
pod
security
policy
back
in
what
I
think
is
more
likely
is
you
know
it's
going
and
we
we
want
a
good
story
so
that
the
deprecation
announcement
that
happens
as
early
as
possible
is
a
good
announcement.
E
In
my
mind,
there
are
three
dates
that
are
important.
There's
the
date
when
we
make
you
know
the
announcement,
there's
the
post
release
date.
When
we
remind
people
that
we've
made
the
announcement
say:
okay,
we've
released
it
now,
it's
not
just
announced
it's
a
it's
official,
it's
happened,
here's
your
reminder.
E
We
meant
it
the
first
time
and
then
there's
a
third
date
which
is
kind
of
what
I
was
trying
to
try
to
say
about.
You
know
when
is
it
getting
a
bit
worrying?
This
is
what
divya
and
the
doc's
release
team
are
wearing
around.
What's
the
date
that,
by
which
time
we
want
the
relevant
people
to
have
committed
to
say,
like
we
have
identified
an
alternative
we
have
committed
to
whatever
what's
that
date,
because
that
is
kind
of
a
deadline
we
want
to.
E
A
A
I
guess
if
you
will,
but
I
I
do
agree
that
no
one's
going
to
be
mad,
that
we
over
communicated-
or
you
know
I
say
we
as
a
collective
kubernetes
org-
not
just
big
doc,
but
we
as
a
community
over
community
team
communicated
some
of
these
changes
and
you
know
being
right
under
the
radar
with
the
exact
information
that's
needed.
A
I
feel
like
it's
hard
to
get
upset
about
over
communication,
at
least
in
this
sense,
and
I
think
that
it
would
be
valuable
to
emphasize
you
know
sooner
rather
than
later,
at
least
getting
it
publicized
out.
There
now
saying
that
I
do
feel
like
this
is
relevant
to
the
folks
who
are
on
bleeding
edge
kubernetes,
and
they
know
the
pains
that
come
with
dealing
with
bleeding
edge
kubernetes,
and
you
know
I'm
one
of
those.
A
I
wear
the
bleeding
edge
hat
and
I
know
the
pains
and
the
problems
that
come
with
you
know
dealing
with
leading
edge
kubernetes.
However,
I
think
being
realistic
here.
What
we
want
to
do
is
get
this
on
people's
radars
for
their
their
upgrade
cycles.
So,
if
they're
saying
you
know,
n
minus
one,
they
know
in
two
upgrades
now,
they're
gonna
be
dealing
with
this
pain
and
whatever
that
cycle
means
to
them,
they
can
plan.
A
E
Who,
on
the
call
saw
sort
of
like
the
twitter
storm
or
the
related
media
storm
around?
You
know
the
docker
ship
deprecation.
What
did
we
get
wrong?
Oh.
C
For
me,
that's
where
we
we
got
wrong
where
yeah,
the
the
the
our
graph
release
notes,
are
available
on
github
and
people
could
go
through
them
and
find
them,
but
I
believe
that
the
main
communication
should
come
from
this
community,
even
just
when
those
draft
release
notes
are
are
out
because
they
are
available
for
people
do
look
at
them.
F
Can
I
can
I
put
up
my
in
my
opinion
it
it
was
that
one
word
was
the
problem.
It
was
the
word
deprecation
when
you
say
we're
deprecating
docker
engine
right
when
you
say
we're
replacing
docker
engine
with
cli
and
container
d,
which
comes
from
docker
engine,
and
it's
essentially
the
same
thing.
Everyone
goes
okay,
so
exactly.
H
G
So
like,
if,
if,
if
whoever
tweeted
it,
I
can't
remember
who
tweeted
it
had
checked
and
had
that
tweet
reviewed
by
someone
like
mike
brown,
who
works
on
container
d,
they
would
have
caught
this
immediately
and
said:
hey
wait
a
minute
this
this
is,
you
know,
would
have
said
it
the
the
way
that
that
you
describe
it's,
it's
a
replacement,
it's
reducing
one
layer
of
shim,
it's
not
a
big
deal,
so
I
mean
I
I
guess
a
couple
things
I
mean.
G
G
F
And
also,
I
think,
the
hesitation
that
I'm
hearing
from
you
right
now
says
that
the
hesitation
about
this
new
deprecation
notice
tells
me
that
you've
learned
the
lesson
from
that
other
situation:
you're
you're
empathetic
with
your
audience.
How
are
they
gonna?
How
are
they
gonna
read
this?
How
are
they
gonna
feel
about
this
and
so
you're
already
trying
to
anticipate
and
address
that
up
front?
And
that's
a
very
good
thing.
F
I
think
that
other
deprecation
of
docker,
it
seems
like
whoever
communicated
that
wasn't
being
empathetic
with
how
your
audience
would
react
and
feel
about
it.
A
Yeah,
I
think
everyone's
spot
on
here
and
I
believe,
we're
all
have
the
same
mindset
and
there's
not
gonna.
Be
that
clear-cut
answer
of
what
the
next
steps
are.
I
do
think
there's
the
overwhelming
theme
of
you
know
more
communication,
the
better
and
just
real
quick.
A
I
know
we
asked
who
is
you
know,
part
of
or
who
saw
some
of
the
twitter
saga
for
the
folks
that
didn't
see
just
for
some
context,
and
what
we're
talking
about
here
is
someone
on
twitter
saw
some
of
the
release
notes
which
currently
go
out
the
door
as
soon
as
we
start
cutting
the
you
know
alpha
and
beta
releases
of
a
new
release.
A
We
automate
all
of
our
release,
notes
communications
to
be
generated
when
we
build
all
the
you
know,
pre-release
releases,
and
what
that
means
is
that
anyone
can
go
into
our
github
repository
and
look
at
releases
before
they
go
out
the
door
and
see
the
changes
that
are
upcoming
in
future
releases
and
normally
that's
a
good
thing,
and
it
still
is
a
good
thing.
I
shouldn't
say
normally
and
what
happened
was
the
user
saw
those
release
notes
in
github
posted
on
twitter?
You
know
emphasizing
the
deprecation
of
docker.
A
Ultimately,
it
was
a
plan
for
event
that
was
only
impacting
users
who
are
on
the
bleeding
edge
when
they
were
using
the
not
the,
not
the
actual
cri
shim
itself,
and
I
could
be
screwing
up
some
of
the
details
here,
but
essentially
it
wasn't
as
big
of
a
deal
as
saying
deprecating
docker,
and
I
I'm
speaking
from
personal
experience.
A
lot
of
folks
who
are
talking,
kubernetes
will
kind
of
mix
up
kubernetes
and
docker
and
containerization.
It's
you
know,
kind
of
one
big
blurry
umbrella
see.
A
It
can
be
very
scary
to
hear
that
a
big
major
component
of
kubernetes
is
getting
deprecated
when
that
may
or
may
not
be
the
case,
and
in
this
case
it
wasn't
just
for
context
for
folks
in
the
call
may
not
have
saw
that
it
raised
up
a
lot
of
issues
with
overall
communications
in
the
community.
How
that
was
handled.
It
seemed
like
it
was
very
poorly.
A
The
tweet
went
essentially
viral
and
in
the
sense
of
all
the
folks
that
cared
were,
you
know
all
over
it
and
we
started
to
see
then
subsequent
articles
getting
published,
and
you
know
trying
to
set
the
record
straight.
It
was
overall
somewhat
of
a
mess.
You
know
to
be
completely
honest
with
everyone
here
and
it
sounds
like
we're
on
the
right
path
to
do
things
better.
In
my
opinion-
and
I
believe,
we're
all
on
the
same
page
here
and
go
ahead.
Tim.
E
I
I
think
that
the
I'd
like
to
see
the
blog
like
byline,
I
don't
mind,
who's,
actually
writing
the
blog.
But
if
the
blog
byline
mentioned
sig
security
and
there
was
input
from
kubernetes
security,
I
think
that
would
go
a
way
to
reassuring
people,
and
I
think
it's
like
important
to
make
sure
we
we
figure.
We
don't
accidentally
bypass
that
sig.
D
I
could
definitely
post
the
draft
draft
pull
request
the
pull
request
that
has
the
first
draft
on
the
chat.
If
it's
required,
and
maybe
we
can
actually
maybe
you
could
actually
provide
your
inputs
on
that.
I
guess.
A
Yeah
and
for
the
sake
of
time,
I'll
put
the
pr,
if
you
don't
mind,
throwing
in
chat
I'll,
put
it
in
the
agenda,
and
we
can
definitely
review
that
and
either
discuss
more
of
it
next
week
or
we
can
do
it
asynchronously
in
the
sig
doc
channel.
But
I
would
like
to
sum
up
time
boxes
if,
if
you
feel
like
we've
answered
the
questions
or
kind
of
answer
all
the
questions
you
had
for
at
least
initial
meeting.
D
Yep,
it
totally
did
adam
and
I've
kind
of
noted
down
whatever
we've
spoken
about
today
and
I'll,
make
sure
to
provide
that,
as
updates
in
tomorrow's
meeting.
A
Thank
you,
cool
and
so
moving
on
blog
update
is
there
anyone
here
who
wants
to
give
us
an
update
on
the
blog.
A
A
Item
is
a
blog
update
and
I
was
asking
if
there's
anyone
who
is
involved
with
this
subproject
group
involved
with
the
blog,
who
wanted
to
provide
an
update.
A
Not
hearing
a
ton
of
not
hearing
a
ton
of
volunteers,
so
we
will
move
on.
Let
me
copy
this
link
here
into
the
chat.
As
always,
the
blog
is
a
sub
project
of
sig
docs
and
if
anyone's
interested
in
helping
out
with
the
blog
there
is
a
special
blog
meeting,
I
believe
it's
on
thursdays
and
there's
more
details
in
the
channel
itself
on
slack
so
moving
on.
There
is
nothing
currently
listed
under
issues
in
pr
so
I'll
open
this
up.
A
D
I
Did
send
an
email
out
to
the
group
last
week,
just
sort
of
send
out
some
highlights
of
this?
I
have
a
doc
listed
here.
Do
you
want
me
to
kind
of
go
through
that
talk
or
yeah.
A
I
Yeah,
okay,
so
the
basic
overview
of
the
project
is
to
basically
track
sale
content
in
the
website,
repo,
so
building
out
a
way
so
that
we
know
when
the
last
time
things
have
been
updated
so
that
users
will
have
more
confidence
that
what
they're
actually
seeing
is
has
been
updated,
has
been
verified
as
being
the
most
most
accurate
and
then
hopefully,
that'll
translate
into
some
alleviating
some
support
issues
that
come
to
the
things
themselves,
so
that
the
people
are
using
the
most
recent
version
of
the
docs.
I
So
they
don't
have
to
run
into
these
issues
and
have
to
be
resolved
by
by
whatever
sig
comes
across.
They
asked
questions
too,
so
that's
sort
of
the
goal
so
well,
that's
like
why
we're
doing
it
and
then
the
goals
that
we
have
for
this
project.
I
I
If
something
has
been
updated
by
something
small
like
a
pr
or
a
pr
for
updating
a
typo,
the
sort
of
assumption
right
now
is
that
we
have
like
a
good
faith
that
people
who
are
updating
the
typo
would
have
reviewed
the
whole
page
or
that
the
reviewer
themselves
would
have
reviewed
the
whole
page
and
sort
of
looked
into
anything
else
that
looked
sort
of
out
of
date.
That's
obviously
something
we
could
talk
about,
and
that
might
be
something
we
have
to
find
grain
later
on.
I
But
that's
sort
of
right
now
we're
just
going
off
of
the
last
commit
date
of
at
least
a
year
ago
or
more
that
hasn't
been
touched,
and
it's
sort
of
how
we're
planning
to
do
this
is
to
go
through
the
site,
specifically
the
the
english
language
version
of
the
site
and
just
the
content
that
is
published
through
the
documentation
section
of
the
site,
so
not
anything,
that's
out
and
blog
or
community.
I
So
just
the
docs
and
sort
of
find
who
the
owners
are
and
add
in,
like
some
metadata
at
the
top
of
the
file.
That
say,
you
know
like
a
sig
owner,
sig
storage
or
something
so
we
have
some
reference
of
who
would
be
the
owning
sig.
So
if
it
comes
up
as
flagged
as
stale,
then
we
know
who
to
reach
out
to
this
is
something
that
we'd
have
to
talk
to.
I
Each
zig
about
we'd
also
have
to
manually
go
through
the
files
to
sort
of
identify
who
that
is
so
that's
sort
of
a
big
project
to
sort
of
put
put
together
so
so
doing.
I
This
would
would
actually
take
a
lot
of
would
take
a
lot
of
investment
to
get
it
all
set
up
and
then
how
how
we're
planning
to
sort
of
do
finding
things
that
are
fail
is
to
set
up
a
script
and
have
it
just
check
files
in
the
content,
docs
folder
and
any
like
of
the
yaml
files
to
see
if
it
hasn't
had
the
update
and
sort
of
spit
out
like
a
little
report,
or
you
know,
whatever
related
information,
that
we
need
to
identify
pages
that
are
sale.
I
If
I'm
saying
that
correctly,
so
this
would
be,
you
know,
coordinating
with
sig
release
to
get
something
put
into
that
tool
and
then
also
our
idea
for
running
this,
like
continuously,
so
that
we're
continuously
checking
everything
is
working
with
the
release
team,
specifically
the
the
docs
release
person
early
in
the
release
cycle
to
sort
of
run
the
script
get
an
issue
created
with
anything
that
comes
back
as
being
stale
and
then
working
with
any
of
the
sig
owners
who
would
own
that
content
so
that
they
could
go
through
and
check,
say
yes,
this
is
stale,
should
be
either
updated
or
removed,
or
it's
actually
fine.
I
It's
old
content,
but
it's
still
fine,
like
we
didn't
have
to
update
it
in
that
time.
So
that's
sort
of
the
process
that
we
had
and
it's
not
I'm
not.
This
isn't
going
to
be
something
that's
release
blocking
we're
just
trying
to
integrate
it
into
the
beginning
of
the
release
cycle
to
sort
of
have
it
happen.
I
Frequently,
we
have
to
also
work
with
sig
release
and
get
a
lot
of
buy-in
for
this
process
to
be
put
into
place,
and
then
I
think
those
are
the
highlights
if
that
sort
of
makes
sense
as
a
good
stopping
point.
If
people
have
some
feedback.
I
C
I
think
putting
it
in
the
in
the
release
cycle
is
is
good
for
the
release
docs
team,
usually
in
the
first
several
weeks,
it's
kind
of
quiet
until
enhancements
for
use.
So
that
would
be
good
time
frame
to
run
the
script
and
you
know
add
additional
tasks
to
you
know
to
track
still
content
or
to
in
track
and
contact
cigs
to
either
update
or
approve
the
stale
content.
A
Yeah,
I
would
definitely
plus
one
this.
I
know
abigail
we've
chatted
a
handful
about
this
process
and
one
of
the
challenges
we've
had
with
this,
and
this
has
been
up
for
discussion
for
I
wouldn't
I
want
to
say
the
better
part
of
about
two
years,
and
I
think
you
know
we
have
made
more
progress
in
the
past
six
months.
Many
thanks
to
the
work
that
abigail's
done,
formalizing
his
stock
and
and
what
I
think
the
fundamental
problem
is
with
this
approach.
A
How
this
approach,
but
with
this
problem,
is
the
fact
that
it
spans
so
many
different
sig
and
it
spans
so
many
different
parties
that
are
involved
that
you
know
to
grasp
it.
You
know
either
by
github,
commit
by
front
matter
by.
However,
it's
automated
generated,
there's
gonna,
be
hairy,
thorny
problems
that
we
run
into
and
really
once
again
going
back
to
the
communication
piece.
A
I
don't
think
we
can
over
communicate
this
piece
enough,
and
I've
said
that
no
one
should
be
caught
off
guard
by
separating
the
stale
content,
and
so
what
I
see
is
so
this
doesn't
lose
steam
in
the
what
ifs
and
what
about
isms.
I
feel
like
we
really
need
to
find
what
is
that
mvp
to
get
this
off
the
ground
and
get
it
started?
A
You
know
whether
it's
you
know,
maybe
not
even
taking
action
day
one
but
starting
the
you
know,
release
team
getting
them
involved
or
up
to
speed
on
what
processes
could
be
done.
Maybe
there's
an
mvp
script.
Maybe
there's
an
mvp
approach,
really
I'd
hate
to
see
this
loose
theme,
especially
how
dragged
out
this
has
been
mainly
due
to
the
multiple
complexities
of
it.
I
I
just
to
agree.
I
I
definitely
think
that
that
there's
a
lot
of
blockers
of
communication
here
so,
like
you
pointed
out
so
I
I
agree
like
I
think,
definitely
doing
something
on
like
a
much
smaller
scale
and
maybe
only
focusing
on
one
sig,
like
storage
or
something
that
have
identifiable
sections
of
docs,
that
we
can
sort
of
run
it
against,
and
maybe
we
don't
find
sale
content
or
maybe
we
do,
but
we
can
have
a
little
style
script
to
sort
of
put
together
to
test
just
a
very
small
section
and
sort
of
do
like
a
little
test,
whatever
to
sort
of
run.
I
F
Yeah
so
you're
proposing
to
do
is
a
pilot,
essentially
a
pilot
with
the
storage.
I
haven't
actually
touched
your
doc
repo.
F
A
E
A
E
I
I
think
I've
got
a
suggestion
for
for
an
mvp,
and
I
also
want
to
scare
people,
because
I've
got
a
list
of
scale
content.
It's
our
content.
We've
we've
got
an
issues
tracker
and
if
I
just
look
at
the
last
page
of
the
issues
tracker,
it
lists
the
pages
that
we've
had
issues
about
the
longest.
I
Do
you
mean
sorry,
like
the
part
and
the
doc
of
like
just
removing
content
that
wasn't
updated?
I
just
want
to
make
sure
I
know
what
you're
referring
to.
E
I
definitely
don't
like
the
idea
of
finding
stuff-
that's
not
been
updated
in
in
too
long
and
removing
it,
because
I
can
identify
stuff
that
really
has
needed
an
update
for
a
long
time
and
like
I'm
like,
for
example,
auto
scaling.
The
page
on
auto
scaling
is
poor.
I
know
it's
poor.
E
I
could
write
a
better
page
and
you
know
if
someone
wants
to
fund
me.
I
will
I'll
put
forward
a
proposal
and
we
can
do
that,
but
I
don't
spend.
I
don't
work
full
time
on
kubernetes
and
I
don't
I
don't
know
if,
even
if
I
did
that,
I
could
do
it
on
my
own.
So
it's
fine,
but
I'm
not
sure
that
removal
is
is
the
way
forward.
I'm
not
sure
it's.
Yes,
it's
the
stick
that
will
get
things
done.
I
Yeah,
I
I
definitely
hear
what
you're
saying-
and
I
I
don't
remember
where
I
had
if
I
had
it
written
down
in
here,
but
I
know
we
had
talked
jim
and
I
talked
about
using
before
really
getting
to
the
point
of
just
like
flat,
removing
stuff
like
that's,
not
what
we
were
trying
to
suggest
but
sort
of
going
through
and
getting
trying
to
get
help
from
the
sigs
to
sort
of
say
that
this
content's
deleted
whatever
and
having
that
process
of
checklist
things
to
check
before
we
remove
stuff
and
also
using
like
the
github,
the
google
analytics
to
see
if
it's
like
a
widely
used
page
like
we
can't
just
remove
it
without
having
you
know
very
making
very
much
making
sure
that
this
isn't
gonna,
disrupt
people's
lives
and
then
also
can
over
communicate.
I
When
there
is
an
actual
deprecation.
I
don't.
I
don't
think
we
have
a
deprecation
process
specifically
for
content
on
a
site,
so
we
might
need
to
put
together
something
like
that
to
communicate
when
pages
are
going
away,
if
they
are
no
longer
needed.
E
So
here
are
two
ideas:
one
is
if
we
have
a
last
review
date
and,
for
example,
we
could
take
all
the
stuff
that
it's
on
that
list.
I
mentioned
cron
job,
auto
scaling
secrets
find
the
pages
that
have
had
no
commit
within
three
years
like
they
definitely
you
know
if
they,
if
they've
got
an
open
issue
against
them
and
they've
not
been
updated
in
three
years.
E
I
think
we
can
confidently
say
we
know
what
the
last
review
date
is
and
it's
a
while
ago
now,
that's
great
because
hugo
the
site
generator
can
take
that
information
and
add
a
warning.
Saying
sorry.
Folks,
like
this
content
is
a
bit
stale
and
we
know
you
know
here's
the
contribute
button.
We
can
add
that
with,
I
think,
not
much
effort.
We
can
target
the
oldest
pages
because
we
know
those
and
we
can
automate
working
out
how
old
it
is
and
we
can
automate
working
out.
E
G
E
E
E
A
A
A
Lots
of
communication
is
going
to
be
necessary
and
I
don't
see
us
automating
anything
right
out
of
the
gate
and
I
think
even
something
as
an
automatic
hugo
warning
about
stale
content
is
still
a
little
bit
offensive
to
somebody
who's.
Unaware
of
these
changes
coming
through.
You
know
from
a
sig
doc
perspective
that
would
be
great
as
a
as
a
down
the
road
state
where
okay,
this
is
well
known.
We've
been
rolling
with
this
for
three
or
four
releases.
A
Now
now
we've
automated
things
that
will
say
hey
this
content's,
probably
still
it
hasn't,
been
updated
in
x,
amount
of
time.
Alternatively,
alternatively,
to
a
hugo,
deprecation
or
a
scale
content
type
flag
in
the
site
itself
is
potentially
white
listing
sites
that
don't
need
to
be
updated,
not
that
they
couldn't
be
better.
But
if
the
fact
is
the
matter
is
that
the
sig
is
happy
with
the
content.
It
is
genuinely
accurate
to
the
best
of
their
ability
and
no
one
is
going
to
make
those
changes.
A
We'd
have
the
ability
and
sorry
we
have
the
ability
to
add
a
allow
list,
for
you
know
things
that
aren't
scanned
or
aren't
addressed
and
there's
solutions
here.
These
problems
that
aren't
we're
going
to
run
we're
going
to
run
a
script
and
delete
all
the
pages
based
on
github
commit.
You
know,
I
don't
want
to
give
that
impression
and
I
don't
believe
abigail
wants
to
give
that
impression.
Either
we'd
have
a
lot
of
angry
folks
in
different
cigs.
You
know
knocking
on
our
door.
G
G
E
Like
we
have
the
issues
like
look,
look
at
page
20
of
the
issue
list
the
frozen
ones,
and
I
mean
maybe
we
want
to
give
those
visibility.
Maybe
another
label
beyond
priority
important
long
term.
E
I
Yeah,
I
think
part
of
this
is-
I
mean
it's
like,
maybe
like
just
like.
Definitely
a
hopeful
part
of
this
is
by
by
being
able
to
flag
things
to
cigs
more
regularly
to
maybe
get
more
eyes
throughout
the
sig,
without
people
necessarily
having
to
go
to
the
repo
in
that
way,
so
we
can
kind
of
poke
people
a
little
bit
more
more
frequently,
which
hopefully
will
get
more
people
in
the
sig
to
kind
of
contribute.
I
It's
definitely
kind
of
a
wishful
thinking
sunny
day
attitude,
because
it
still
would
take
a
lot
of
time
to
get
get
these
pages
updated
from
someone
in
the
community.
So
that's,
hopefully,
a
positive
effect
of
this
project.
But
I
I
hear
what
you're
saying
that
we
need
to
like
tim
with
with
the
older
issues
and
getting
eyes
on
them.
F
G
Again,
I
throwing
issues
on
pages,
makes
me
a
little
bit
nervous.
We've
put
a
lot
of
years
into
you
know,
building
up
a
pretty
good
perception
of
the
docs.
I
I
think
there's
real
problems
here
and
I
think
there's
you
know.
One
thing
we
could
think
about
is
jimmy.
G
We've
got
the
the
planning
meeting
coming
up
is,
if
we
can
identify,
say
the
top
five
most
awful
candidates,
the
top
five
most
stale
pages,
and
maybe
each
one
of
us
takes
one
and
we
become
a
liaison
to
the
sig
to
keep
reminding
them,
I'm
going
to
say
liaison,
but
I
really
mean
nag
but
just
say
hey.
We
just
want
to
show
up
in
the
meeting
and
every
so
often
say
I
just
want
to
remind
you.
G
This
page
is
really
out
of
date.
Could
could
somebody
take
a
look,
so
I
I
don't
mind
going
after
the
top
priority
ones.
I
just
think
I
am
a
little
nervous
about
any
type
of
automatic
slapping
labels
on
all
our
content.
Yeah.
I
know
we've
got
some
old
content,
but
in
general
those
those
words
can
have
a
lot
of
meaning
and
and
and
we've
you
know-
could
could
build
up
a
bad
optics
that
I
don't
think
we
really
deserve.
G
A
And
I
completely
hear
where
you're
coming
from
too
brad-
I
I
totally
get
that
and-
and
I
think
that
I
would
be
more
in
favor
of
talking
about
folks
becoming
liaisons.
I
would
like
to
see
five
folks
become
liaisons
of
this
overall
process
as
a
whole
document
deprecation
making
those
communications
clear.
A
But
I
completely
agree,
though
you
know
going
around
the
removal
hammer
or
you
know,
scripting
and
automating
everything
under
the
sun
probably
isn't
the
initial
solution,
as
we
figure
out
what
works
and
what
doesn't
work.
I
do
believe
automation
will
come
into
play,
but
I
think
initially
it's
going
to
be
a
lot
of
communication,
the
liaison
aspect
of
it
I
like
a
lot,
but
I
would
say
instead
of
focusing
on
specific
docs
focus
on
those
liaisons
being
advocates
of
this.
You
know
process
and
improving
this
process
as
a
whole,
but
yeah.
G
I
I
think
I
think
that
that
we
could
we
have
it's
not
something
that
I
have
looked
into,
but
I
think
that
we
can
really
look
at
what
are
doing
a
combination
of
what
you
said
to
sort
of
identify
the
areas
that
are
maybe
the
most
stale
or
the
most
prevalent
or
whatever,
and
put
that
into
into
into
practice.
For
for
maybe
a
list
of
instead
of
pages.
But
things
to
sort
of
coordinate
with.
E
A
So
real,
quick
just
to
be
considerate
of
everyone's
time.
Here
we
got
about
a
minute
left.
It
sounds
like
there's
still
further
discussion
to
happen
on
this
topic.
I
think
this
discussion
that
we
just
had
was
great
around
here
and
I
I
believe
that
there's
still
more
to
talk
about,
so
I
suggest
that
we
pump
this
to
the
next
meeting
as
well
as
long
as
abigail
is
able
to
attend.
We
can
pick
this
up
where
we
left
off.
A
I
did
want
to
give
a
quick
shout
out
that
we
are
going
to
do
our
quarterly
planning
on
thursday
february
18th
at
5
p.m.
Pacific
I'll
send
out
a
meeting
invite
here
shortly
after
this
call
today,
as
well
as
a
document
in
our
slack
channel
for
those
who
are
just
joining
us,
we
don't
know
the
quarterly
planning
talks
about
what
we
accomplished
in
the
previous
quarter,
as
well
as
what
we
want
to
do
in
the
upcoming
quarter.
It's
the
ability
to
talk
about
some
of
the
larger
projects
that
we
want
to
accomplish.
A
That's
just
you
know,
we
can't
talk
about
in
our
you
know,
hourly
meeting,
or
you
know
week
week
in
slack
some
of
the
overarching
pieces
here.
Much
like
this
is
that
for
the
abigail's
leading
to
resolve
still
content,
that
was
one
of
our
quarterly
goals.
Last
time
we
got
together
as
a
example
of
what
those
quarterly
efforts
look
like
so
calendar
invite
coming
there
fred
we're
at
time.
But
do
you
want
to
give
a
quick
shout
out
to
your
localization
topic?
You
have.
G
The
question
was:
is
it
possible
for
us
to
add
a
little
message
inside
there
saying
hey
if
you're
doing
a
a
localization
pr
for
a
specific
language?
Could
you
add
the
following
code
in
in
the
actual
pr
title,
so
it
could
be
easily
searched,
and
I
had
so.
I
was
the
one
to
add
to
make
the
request
and
then
see.
G
Could
we
do
this
and
how
do
we
do
this
and
add
that
in
so
just
a
quick
discussion
there?
I
mean:
does
the
idea
make
sense
any
any
concerns
for
why
they
want
to
put
that
in,
and
you
know,
I
know
we
have
the
label,
but
the
label
only
helps
in
certain
situations
so
having
it
in
the
pr
title
helps
too.
A
I've
got
no
issues
with
it.
It
sounds
reasonable
to
me.
The
only
thing
that
I
would
be
interested
to
know
is
if
it
impacts
anything
with
the
ci
robot,
which
I
doubt
it
would,
but
I
know
we've
had
things
with
you
know
user
names
and
commit
messages
being
in
the
title
causing
conflict.
I
can't
imagine
why
breakfast
would
you
know,
cause
an
issue,
but
I've
seen
weirder
stuff.
G
So
so
it's
already
being
done
a
little
bit.
So
it's
just
that
the
adding
the
message
for
new
contributors
in
the
in
that
little
welcome
pr
message
and
is
that
just
a
standard
template
somewhere
that
I
can
update?
I
can
do
follow
this
up
offline
with
you,
jim,
and
hopefully
you
can
point
me
to
hey
brad.
You
should
have
known
this,
but
it's
right
here.
A
No
there's
definitely
a
file,
and
I
can
definitely
help
you
out
with
that
or
someone
else
on
slack
and,
and
we
can
definitely
look
at
making
that
change
for
sure.
Does
anyone
else
have
any
other
questions
or
comments
around
that
change?.