►
From YouTube: K8s SIG Docs Meeting for 20201215
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).
B
I
guess
you
can.
This
is
my
first
time
attending
sigdocs,
so
I'm
joseph
sandoval,
I
was
the
comms
lead
for
120.,
so
grateful
to
be
here.
C
D
A
Perfect
cool
well
welcome
everybody,
whether
you're
sitting
in
for
a
retro
discussion
that
we'll
talk
about
in
a
few
minutes
here
or,
if
you're
here
for
the
the
long
haul
and
want
to
get
involved
with
sick
docs.
We're
glad
to
have
you
and
happy
to
answer
any
questions.
So
if
this
is
anyone's
first
meeting
here,
these
are
relatively
informal.
We
have
an
agenda
that
we
follow
just
to
make
sure
we
can
have
a
structured
discussion.
But
if
there's
any
questions
comments,
don't
hesitate
to
interrupt,
ask
questions.
A
A
Cool,
so
moving
on
to
the
updates
reminders,
this
week's
pr
wrangler
is
beneath
and
next
week
we
do
not
have
a
pr
wrangler
for
the
holidays,
and
that
was
one
thing
that
I
did
want
to
bring
up
here
and
I'll
most
likely
raise
it
up
again
in
slack.
A
Is
that
next
week
is
the
apec
friendly
meeting
time,
but
we're
also
getting
into
the
u.s
holidays
kind
of
end
of
year,
wind
down
what
are
folks
thoughts
on
either
canceling
it
or
still
continuing
to
host
it,
because
we're
so
I'll
be
honest,
I'm
a
little
torn
because
it
is
the
apac
meeting.
So
it's
not
really
impacted
by
the
us
holidays.
However,
there's
a
lot
of
folks
from
the
us
that
will
be
supporting
that
meeting
and
maybe
aren't
available
me
being
one
of
those
any
strong
feelings,
one
way
or
the
other.
A
I'm
definitely
not
the
boss,
but
what
I'll
do
is
I'll
bring
it
up
on
slack
and
see
what
the
general
opinions
are.
You
know
I
think.
D
A
The
the
folks
who
are
invested
in
this
most
likely
are
sleeping
right
now
and
make
sure
that
there's
some
general
awareness
from
the
folks
that
would
actually
get
value
out
of
that
apec,
friendly
time
zone,
meeting
cool
so
I'll,
bring
that
up
on
slack
and
as
always,
approvers
make
sure
you
know
your
pr
wrangler
shift
and
there's
a
link
in
the
agenda
there
and
I'll
throw
the
agenda
in
the
chat
as
well.
For
folks
who
don't
have
it.
A
And
pretty
light
agenda
today,
so
I
know
that
last
week
there's
a
discussion
around
having
the
release,
120
retro
and
be
a
perfect
time
to
kick
that
off
today,
so
I'll
hand
it
over
to
anna.
If
you
want
to
kick
us
off
and
start
the
discussion
and
we
can
go
from
there.
F
Sure
so,
basically,
it's
open
floor
to
everyone.
It's
an
open
discussion.
If
anyone
has
thoughts
about
what
went
well
and
what
we
could
improve
on
like,
I
would
love
to
hear
it
from
anyone
who
has
thoughts.
A
Before
opening
it
up
anna,
do
you
want
to
give
a
brief
summary
of
your
opinion
on
you
know
some
general
context
and
the
review
on
the
release
process,
your
own
opinions
on
the
release
process,
where
we're
at
today
how
things
went
and
then
I
think
we
could
open
it
up
to
sovereign,
has
context.
F
Sure
so,
from
my
point
of
view
like,
I
think
the
release
went
really
well,
because
one
of
the
things
that
I
really
wanted
to
focus
on
for
this
release
was
not
getting
a
lot
of
prs
piled
up
before
the
deadline,
and
I
think
we
did
a
really
good
job
this
sprint.
F
I
mean
this
release
if
you
think
back
to
all
the
deadlines
we
had
except
the
first
one,
which
was
the
placeholder
deadline,
the
other
deadlines
we
only
have
maybe
like
five
ish
like
we
were
looking
at
like
a
day
before
the
deadline,
I
mean
there
were
some
that
got
extended
after
the
deadline,
but
I
think,
from
my
perspective,
like
I
think,
the
following
the
last
release
process
and
just
making
sure
that
we're
more
actively
participating
with
sick
docs
on
reviews
and
getting
approvals
like.
F
I
think
we
did
a
good
job
there
in
my
opinion,
so
yeah,
but
then
there's
also
another
thing.
I
actually
didn't
know
that
we
had
to
communicate
with
the
communications
team
from
the
sake
really
it's
like
I
didn't.
Actually,
that
was
not
in
the
doc's
world
handbook
and
I
knew
that
there
was
a
blog
post
somewhere
in
my
responsibilities,
but
then,
like
I,
never
realized
that
I
had
to
like.
F
I
should
reach
out
to
them
and
then
work
with
them
to
get
the
blog
post
published,
because
that's
one
of
the
things
that
lee
does
they
publish
the
blog
post
during
the
release
day,
and
I
wish
I
have
known
that
sooner.
So
I
did
actually
update
the
doctoral
handbook
to
like
reach
out
to
the
comms
team,
and
I
think
that's
why
joe
is
here
as
well.
F
G
I'll
chime
in
I
was
on,
I
was
one
of
the
shadows
for
the
docs
team
and
I
just
say
that
I
think
it
went
very
well
as
well,
and
the
communication
between
the
doc
shadows
and
doc's
team
itself
by
anna
was
was
was
was
amazing,
like
we
were
always
updated
with
what
went
on
every
week
and
any
action
items
we
had
for
the
upcoming
week
having
been
on
previous
release
teams
but
for
different
sub
teams.
I
thought
the
communication
was
was
great
amongst
the
docs
release
team,
so.
B
I
guess
I
can
chime
in
on
from
the
comms
perspective,
because
I
think
just
like
anna
then
maybe
I'll
first
start
off
for
saying,
and
I
think
anna
just
from
an
outside
being
a
lead
watching
her.
She
was
amazing
during
this
release
cycle.
I
was
even
able
to
draft
off
of
like
what
she
was
doing
as
well.
So
I
think
you
know
it
was.
It
was
great
and
I
could
see
it
with
her
team
as
well,
and
it
was.
B
It
was
helpful
for
other
groups,
but
specifically
about
like
the
the
cons
of
communication
yeah
in
our
in
our
handbook.
There's
not
any
mention
of
this
relationship,
and
I
think
it
wasn't
really
until
the
last
week
when
we
just
got
added
to
like
oh
hey
there.
I
I
knew
that
jorge
castro
and
bob
were
the
ones
that
were
gonna
do
some
approvals,
but
that
there
was
a
whole
channel
that
was
available
to
us
to
be
able
to
kind
of
get
feedback.
B
Ideally,
it
would
have
been
great
if
we
could,
because
we
were
kind
of
already
building
droughts
for
the
release
frog
as
well
as
feature
blogs,
and
we
could
have
already
been
submitting
for
review
and
getting
feedback
from
sigdocs,
which
we
got
in
the
last
couple
days,
and
so
it
was
just
race
to
get
input
and
it
was
great
in
regards
to
kind
of
amplifying
the
need
to
have
that
peer
review.
So
I
think
definitely
we're
going
to
add
to
our
you
know.
You
know.
B
B
B
She
said
that
she's,
like
she
thought
one
of
the
things
we'd
have
benefited
from
knowing
earlier
was
a
sig
doc's
blog
bit
also
if
we
could
get
docs
to
sort
of
agree
upon
a
cadence
on
the
approval
and
amendments
of
the
comms
release
and
feature
blocks
towards
the
end
of
every
cycle.
That'd
be
great,
that'd,
be
good
too,
and
by
cadence
I
mean
a
firm
set
of
timelines
like
we
have
for
doc
enhancements,
after
which
the
blogs
from
our
side
cannot
be
submitted.
B
Only
amended
reviews
are
permitted
and
she
said
I
went
through
the
comms
lead
notes,
and
although
there
are
some
suggested
timelines,
I
felt
the
undue
pressure
from
all
sides
can
be
reduced
if
we
have
a
firm
timeline
in
place
for
this
bit.
So
I
kind
of
I
think
agree
with
that.
There
wasn't
really
a
clear
like
we
have
some
loose
kind
of
guidelines
about
when
things
should
kind
of
magically
appear
or
be
ready,
you'll
be
be
published,
but
nothing
that
kind
of
leads
up
towards
it
like.
What
are
the
interim
steps?
B
So
you
know
there
is
some
call
outs
that
the
cons
lead
meets
with
the
enhancements
and
talks
about
noteworthy
things,
talks
to
release
out
teams
as
well,
but
I
definitely
think
there
could
have
been
some.
You
know
feedback
from
the
docs
teams
to
help
us
as
well,
and
I
think,
we're
all
kind
of
challenged
in
the
release
teams
as
well
of
like
how
do
we
even
get
commitments
to
you
know
for
topics
I
mean.
That's,
that's
always
been
every
cons
challenge
that
I've
seen
over
the
last
three
cycles.
B
I
think
we
all
kind
of
face
that,
but
it
gets
really
tough
and
then
we
get
hammered
right.
The
last
two
three
weeks
to
like
produce
something
magically.
So
I
think
that's
where
I
think
areas
of
opportunity,
I
think
going
forward,
is
maybe
tighter
alignment.
You
know
with
release
notes
with
docs
may
help
ease
some
of
this
challenge
at
the
end,
as
well
as
like
not
expect
everybody
at
the
last
minute
to
start
reviewing
feature
blogs
or
release
blogs
in
the
last
week.
B
I
kind
of
feel
like
it's
probably
still
going
to
be
a
thing,
but
at
least,
if
there's
a
little
bit
more
communication
and
upfront
about
hey,
expect
all
these
things
to
drop
here.
We're
going
to
need
you
to
come
in
after
release
notes
is
done.
That
may
even
be
helpful,
but
this
time
around
it
just
felt
like
it
landed
on
everybody
in
that
last
couple
days,.
H
And
I
would
just
love
to
quickly
add
a
little
context
on
that
one
piece
on
blog
review:
historically,
we,
the
blog
team,
has
actually
kind
of
taken
ourselves
out
of
that
review
process
just
because
there
are
so
many
people
on
the
comms
and
dockside
that
you
know
like.
We
trust
that
the
blog's
in
a
pretty
good
place
before
it
gets
to
us
I
and
like
we've
kind
of
always
just
helped
review.
H
If,
like
the
team
wants
it,
I
think
it
would
be
great
to
get
in
like
make
a
decision
one
way
or
the
other.
If
we
want
blog
team
review
or
not
just
as
so,
we
can
be
more
involved
in
the
commons
process
from
the
beginning,
I
don't
mind
either
way
just
I
think
I
think
you're
right
that
it
should
be
really
clear
in
the
process
whether
we're
involved
or
not.
H
That
if
the
blog
team
is
not
involved
historically,
it's
been
a
combination
of
the
comms
team
and
then
the
release
leads
and
enhancement
leads,
so
like
an
enhancement,
lead
will
say.
Yes,
this
looks
right.
The
release
lead
will
kind
of
give
their
final
blessing
on
it
and
then,
at
that
point,
like
you
know,
it's
gone
through
enough
eyes
for
us
to
be
comfortable
with
it.
Let's
see.
A
Yeah,
I
think
this
is
this
is
a
great
feedback,
I'm
curious
on
how
we
got
to
this
point
and
just
to
give
some
context
in
some
of
the
earlier.
I
guess
teen
releases
so,
like
you
know,
13
14
or
so
was
when
I
was
more
involved
with
the
doc's
release
process.
I
believe
there
was
a
transitional
period
where
coms
was
handled
by
cncf
directly.
There
was
a
little
internal
cncfcoms
team
and
I'm
looking
for
caitlyn
for
for
confirmation
or
awareness
of
this.
A
I
want
to
make
sure
I'm
not
telling
fibs
here
and
it
transitioned
more
into
a
community
aspect
where
there's
actually
the
comms
team,
calm,
shadows
and
a
little
more
of
a
you
know,
kind
of
like
a
traditional
open
source
culture.
We
see
in
the
kubernetes
community
as
opposed
to
direct
cncf
involvement
for
the
communication
and
release
process,
and
so
from
that
transition.
In
the
early
teens
of
kubernetes,
I
say
early
teens,
as
in
the
early
dot,
the
patch
release
teams
of
kubernetes
all
the
way.
Now
you
know
eight
to
ten
releases
into
1.20.
A
H
Yeah,
so
the
comms
position
itself
was
originally
created
by
the
cncf
team
natasha
and
myself
with
a
really
close
partnership.
I
think
even
beyond,
like
when
we
were
doing
when
we
wrote
the
leads
for
that
role,
with
the
really
close
partnership
with
the
cncf
pr
team.
H
Beyond
that,
like
it's
become
this
really
amazing
community
role,
but
I
think
everything
you
said
jim
was
was
correct,
but
I
do
think
we've
lost
some
of
that
in
the
iterations
of
the
release,
handbook
of
the
roll
handbook
like
what
that
used
to
look.
H
F
For
the
blogs-
and
I
think
it'd
be
really
good
to
actually
discuss
what
would
be
a
good
time
to
actually
make
a
pr
to
get
the
release
blocks
like
reviewed
and
stuff
like
that
as
well,
and
have
the
docs
team
involved,
like
stick
dogs
involved.
If,
if
needed,
and
the
blog
team-
and
I
don't
know
I
wish
like
there's-
there
should
be
an
action
item
for.
F
Cops
team
and
the
docs
team
if
to
make
this
process
better
for
the
next
release,
and
I
just
want
us
to
agree
on
something-
I
guess.
B
So,
just
to
give
some
context
on
the
handbook
itself,
like
so
there's,
there's
kind
of
starting
around.
Like
you
know
week,
five
is
when
we
kind
of
start
getting
like
a
skeleton
framework
of
like
just
what
the
release
blog
enhancements
kind
of
look
like.
I
found
that's
not
always
true,
because
we
know
how
it
is
like.
I
have
to
look
at
like
the
on
this
on
the
enhancement
spreadsheet.
B
Really?
It
didn't
really
come
together
until
about
week,
eight,
and
that's
when
I
kind
of
knew
for
sure.
Like
all
right.
I
know
we
can
start
writing
about
these
things.
Let's
start
reaching
out
to
enhancement
people
as
well
and
start
seeing
who
we
can
get
committed
to
maybe
write.
You
know
specific
blogs
about
specific
tips,
but
then,
after
that,
like
the
handbook
only
really
has
week,
10
and
11.
B
There
is
no
mention
up
until
that
point
week.
10
is
when
you
publish
and
finalize
a
feature,
a
release
blog
or
you
publish,
release
blog,
and
then
you
finalize
a
feature
blog
and
then
week
11
is
publish
the
feature
blogs.
So
it's
it's
kind
of
like
everything
comes
at
the
last
there's,
no
like
call
outs
about
hey,
go
out
and
get
feedback
or
or
even
like.
Now
we
know,
let's,
let's
set
bob
and
and
jorge's
expectations
that
we're
gonna
need
them
to
take
a
look
at
these
things
towards
the
end
of
the
cycle.
B
So
we
could
add
some
call
outs
for
the
three
steps
that
are
needed
to
hey,
engage
sig,
docs
or
you
know,
or
something
like
that.
I
don't
know.
If
that's
what
you're
thinking
anna.
F
Yeah,
definitely,
I
think,
maybe
even
joining
the
segdos
meeting
during
that
time,
just
like
to
give
awareness
of
like
which
block
there's
a
pr
for
like
these
vlogs.
That
needs
to
be
reviewed
for
the
release
and
stuff
like
that
or
yeah.
I
guess
just
more
communication
between
the
team,
but
earlier
would
like
get
better
reviews
and
get
the
process
ready
so
that
I
can
be
published
on
time,
because
I
that's
what
I
was
thinking.
A
Yeah,
and
so
I
think
we
can
definitely
come
up
with
the
decision
here.
This
is
one
of
those
strange
things
where
there's
not
really
going
to
be
a
like
key
decision
maker.
You
know
that's
one
of
the
beauty,
beautiful
things
about
the
open
source
community.
Is
it's
not
going
to
be
here's
the
right
way,
here's
the
wrong
way.
A
Let's
go
the
right
way,
you
know,
so
I
think
we
have
the
ability
to
make
the
decision
if
we
want
at
a
very
high
level,
at
least
from
what
I'm
hearing
it
sounds
like
it'd,
be
beneficial
for
just
some
sort
of
cross-collaboration
it
sounds
like
putting
in
the
handbook
would
be
a
good
way
to
establish
that
I
guess
foundational
instruction
and
then
to
echo
what
anna
was
saying.
You
know
these
meetings
are
wide
open.
A
So
if
someone
from
collins
wants
to
jump
into
one
of
the
docs
meetings
midway
through
the
release
and
just
say-
hey
look,
I
don't
really
have
too
much
to
add
to
this
meeting
today,
but
I'm
just
trying
to
open
up
this
communication
channel
here's
my
challenges.
Here's
what
you
need
help
with
you
know
there
could
be
an
opportunity
there
just
to
introduce
yourself
and
say
hey
and
pop
into
one
of
the
sig
doc's
meetings
at
the
halfway
point,
and
I
think
that
the
the
communication
goes
both
ways.
A
I
think
that
the
docs
handbook
could
also
have
the
docs
release
lead
or
the
docs
shadows
join
a
comms
meeting.
You
know
a
scheduled
session
and
say:
hey,
look
we're
in
progress
of
doing
documentation.
How
can
we
help
here's?
What
we're
seeing
here's?
What
we're
you
know
currently
doing
I
do
know
for
docs
in
particularly
things,
are
pretty
slow
in
the
beginning,
so
there's
really
not
much
to
update
or
you
join
in
a
meeting,
and
you
say:
well,
we
don't
even
know
what
the
enhancements
are.
A
We
don't
know
the
status
of
the
docs,
so
this
seems
like
it.
It
by
nature
has
to
come
late
in
the
release,
but
by
no
means
needs
to
come
a
day
before
the
release,
and
I
think
that
it
makes
sense
for
that
communication
to
be
open
on
both
ends
but
but
happy
to
hear
if
anyone
has
any
other
opinions
on
making
it
more
formal,
adding
it
more
to
the
handbook,
like
I
said,
there's
not
gonna
be
a
right
answer
here,
but
I
think
we're
heading
in
the
right
direction.
G
Personally,
I
believe
that
getting
things
done
earlier
as
possible
is
better
being
on
a
few
teams
where
you
just
do
everything
at
the
end
so
like
maybe
docs
and
comps
teams
could
work
together
earlier
earlier
on
before
week,
11
like
midway
through,
like
like
anna,
says
or
and
yeah,
and
I
know
sig
docs-
I
I
know
we
rely
on
you
a
lot-
the
releasing
does
with
all
the
reviews,
getting
things
merged
and
now
also
with
blogs
as
well.
H
And
then
I
just
want
to
say
just
I'd
love
to
work
with
you
to
update
the
role
handbook.
I
have
some
historical
documentation
that
might
make
sense
to
go
in
here,
but
then
you
kind
of
know
better
how
it's
gone
this
time
around.
So
I'd
love
to
partner
with
you
to
update
some
of
that
information.
B
B
A
Cool
any
other
feedback
on
this
topic.
It
sounds
like
there's
some
informal
actions,
moving
forward
and
general
consensus
as
well,
and
and
we're
recording
this
meeting
too
for
reference.
If,
if
need
be
so
I
feel
comfortable,
we're
at
anna
joseph
ray
do
y'all
feel
good
where
we're
at.
G
Yup
yup,
I
do
the
only
one
other
topic
I
want
to
bring
up
is
deprecations
and
how
we
handle
that,
but
that's
an
ongoing
subject,
that's
being
discussed
in
github,
also
with
cigar
release
as
well.
I
don't
know
if
this
is
a
good
time
to
to
talk
about
it
or
until
later
on.
Until
once,
that's
off
all
the
discussions
have
been
flushed
out
and
on
github
and
secretly
so.
A
Just
curious
what
in
particular
about
deprecations
and
handling
that
is
up
for
discussion.
G
Just
what
wanted
just
to
process
on
how
sig
release
how
they
learn
of
deprecations,
like
the
big
one
for
120
with
docker
shim
and
who
is
responsible
to
which
team
or
who
is
responsible
to
to
communicate
these
deprecations
and
what
the
timeline
is.
G
I
think
in
this
morning's
call
was
someone
said
like
once
it
gets
once
it
hits
the
release,
notes
or
the
change
log,
it's
already
kind
of
late
and
it
came
and
it
might
yeah
it
goes
goes
out
on
the
social,
so
yeah,
and
so
there's
there's
still
a
lot.
It's
still
a
lot
of
discussions
to
be
had
I'm
about
that,
so
that
thing's
been
finalized,
but
just
something
to
bring
up
for
121.
G
B
Yeah
as
well,
because
I
think
because
of
the
docker
deprecation
kind
of
like
you
know,
explosion
monday
that
day
up
so
release
blog
was
just
about
finished
and
then
we
had
the
exact
probe,
timeout
handling
kind
of
drop,
and
so
they
were
trying
to
say
all
right.
We
need
to
put
something
in
so
we
were
writing
on
that
monday,
one
last
edit
to
the
release
blog
so
that
we
could
kind
of
preemptively
tackle
that
deprecation
and
going
back.
B
I
looked
through
my
notes
and
I
and
I
don't
know
how
I
missed
you-
I
had
that
called
out.
I
just
didn't:
ask
the
question
about
like
hey:
is
there
anybody
concerned
about
these
deprecations,
and
so
I
think
definitely
one
of
the
things
I
thought
about
is
just
I
think
some
of
us
recognized
it,
but
we
just
weren't
planning
to
and
even
before
release
notes
was
coming
out.
We
were
calling
some
of
these
things
out,
but
for
whatever
reason,
we
just
didn't
really
put
the
dots,
everything
together
to
say:
hey.
B
G
A
Awesome
yeah
I
agree,
and,
and
once
again
this
is
going
to
be
ongoing
and
you
know
I
think
that
the
best
effort
from
or
I
should
say
the
best
effort,
one
of
the
things
that
we
could
do
from
a
sig
docs
perspective
is
just
raising
awareness.
You
know
early
on
in
the
cycle
talking
about
it.
When
we
talk
about
the
121
release,
you
know
I,
I
think,
there's
levels
of
deprecations
and
levels
of
what
folks
actually
think
not
what
they
think
I'm
trying
to
get
the
correct
term
here,
but
basically
like
for
116.
A
There
was
a
lot
of
deprecated
api
versions
that
broke
a
lot
of
stuff
and
a
lot
of
folks
stayed
on
115.
Because
of
that-
and
I
should
say
it
broke
stuff.
It
just
forced
people
to
make
changes
that
they
weren't
necessarily
ready
to
make
with
the
120
release
in
in
this
example,
with
the
docker
shim
being
deprecated
is
not
being
removed.
Just
yet
it's
going
down
that
you
know
process
and
it
seems
to
me
at
least
my
bubble
of
kubernetes
or
my
ecosystem
or
social
sphere.
E
It's
that
I
think
it
was
also
how
to
put
this
nicely.
E
Yeah
I'm
aware,
I
think,
there's
also
a
an
issue
around
kind
of
educating
people
in
general
about
release
etiquette.
We
are
open
source.
You
can
technically
just
go
and
look
at
the
release,
notes
and
process
in
progress,
but
in
general,
leaving
announcements
to
the
time
of
actual
release,
rather
than
jumping
the
gun
and
tweeting
about.
It
is
usually
a
better
option
and
what
I,
what
I
really
think
is
maybe
the
core
things
surrounding
all
this.
E
E
Is
that
the
critical
mass
of
use
at
this
point
where
deprecations
are
going
to
affect
a
lot
of
people
and
people
may
not
necessarily
have
the
ability
or
desire
to
upgrade
their
nodes
to
the
latest
version
right
at
every
new
release
like
they
have
reasons
for
staying
on
on
old
versions,
even
if
they're
not
great,
and
we
kind
of
just
need
to
mature
and
start
communicating
those
things
correctly,
because
the
outrage
or
outrage
is
a
strong
word,
people
are
going
to
feel
negatively
about
deprecations,
no
matter
what
you
do,
because
there
is
somebody
who
is
using
every
little
thing.
E
However,
we
do
need
to
deprecate
things
as
a
product
organization
of
some
sorts.
So
it's
really
just
about
communicating
that
in
a
slightly
more
responsible
way.
I
don't
think
this
needs
to
be
have
a
ton
of
overhead.
It's
really
just
a
series
of
blog
posts,
two
or
three
of
them
on
the
same
deprecation
announcement,
so
that
when
people
say
you
didn't
tell
me
you
can
say
well,
we
told
you
three
times
so
anyways.
That's
all
I'll
say
on
that.
F
Well,
I
just
have
like
one
more
topic
that
I
wanted
to
bring
up,
but
did
you
have
a
comment
on?
What's
the
last
side,
tim
or.
F
Okay,
then
I'll
go
first,
so
it's
actually
idea
that
ray
brought
up-
and
I
just
want
to
mention
it
here
too,
because
it's
going
to
be
discussed
during
the
1.20
release
retro
as
well.
F
But
I
just
want
to
get
your
opinion
on
moving
the
placeholder
deadline
to
match
the
code
freeze
deadline,
because
right
now
for
this
release,
specifically,
we
had
the
placeholder
that
I
deadline
a
week
before
the
code
freeze
and
there
was
a
lot
of
problems
of
getting
that
getting
everyone
to
create
a
placeholder,
because
I
remember
like
a
week
like
a
day
before
we
had
like
maybe
15
or
something
and
then
like
the
leads
had
to
like
all
reach
out
to
different
things
and
then
like.
F
We
did
make
the
deadline,
but
I
think
it'd
be
really
beneficial
to
actually
have
it
match
the
code
phrase.
So
this
is
something
that
we
wrote
down
in
the
retro
item
and
I
was
just
wondering
what
sig
dogs
thought
about
that
idea
as
well.
E
Oh,
it's
just
it's
easier
to
communicate
where
it's
like.
You
got
to
have
your
stuff
done
or
in
a
state
where
it
could
theoretically
be
done
on
exactly
one
day
right.
It's
one
less
thing
for
people
to
remember.
A
F
Yes,
it's
like
you
have
to
no.
So
after
the
placeholder,
it's
like
you
have
to
have
your
dogs
ready
for
review,
and
that
comes.
I
actually
have
to
look
it
up,
but
I
think
it
was
like
two
weeks
or
three
weeks
after.
A
Gotcha
yeah
and
it's
not
a
big
deal.
My
personal
opinion
on
this
is
the
release.
Lead
can
help
dictate
the
timeline
they're
running
the
show
if
it
makes
their
life
easier
by
any
means.
100
percent
has
the
backing
of
at
least
my
support
there,
and
my
only
thought
was:
are
we
squishing
the
time
in
between
two
other
deadlines?
A
If
we
were
to
move
that
one
forward,
I
mean
it
doesn't
sound
like
you
know,
losing
that
one
week
I
I
think
the
folks
who
are
cramming
to
put
in
their
placeholder
pr
are
also
going
to
be
the
ones
cramming
to
you
know,
get
that
ready
to
review
draft
as
well
so
strong
plus
one
to
whatever
makes
the
release
leads
life
a
little
easier
opened
any
other
comments
or
concerns
there.
I
So
one
of
the
things
that
I
like
about
having
the
placeholder
pls
come
in
a
bit
earlier,
is
that
it
spreads
out
the
review
effort
over
a
longer
period,
as
some
people
get
in
their
their
documentation
in
earlier.
Some
people
are
later
what
what's
bad
for
sig
docs
is
if
all
of
the
stuff
becomes
ready
for
a
review
over
say
four
days,
and
it
is
fairly
close
on
release,
because
you
know
it's
a
contended
resource
and
there's
also
been
a
thing.
I
I
think,
which
is
kind
of
tacit,
not
really
stated,
which
is
that
for
me,
placeholder
pr's
have
been
a
chance
sort
of
my
first
sight
of
what's
likely
to
end
up
in
the
release
and
what
things
might
need
calling
out.
Like
informally.
Oh
you
know
you
need
to
mention
this
in
the
future
gates
table
informally.
You
know
you
need
to
communicate
this.
Somehow
don't
forget
to
do
that,
and
I'll
have
often
put
in
some
comments.
Saying
thanks
for
the
placeholder
here
are
some
things
that
you
know.
I
know
it's
a
draft.
I
I
G
I
I
think
it's
a
good
point.
I
think,
from
my
perspective
on
that
suggestion.
That
was
because
we
had
people
still
writing
code
and
and
didn't
know
if
their
enhancement
or
feature
is
going
to
make
it
to
the
release
of
the
they
weren't
responsive
to
our
touches
to
get
them
to
create
a
placeholder
dock.
I
One
more
suggestion
on
that
then
see
what
you
think
of
this,
especially
ray
and
anna.
I
reckon,
if
you're
too,
busy
to
create
a
placeholder
or
you're,
not
keen
like
for
me.
It's
a
bit
of
a
signal
like
I
don't
think
features
are
ready
to
graduate
if
people
haven't
got
time
to
open
a
full
line.
Pr.
I
A
I
almost
wonder
if
we
could
have
the
best
of
both
worlds
ever
cake
and
eat
it
too.
If
we
can
move
the
placeholder
deadline,
making
the
general
assumption
that
maybe
the
the
folks
that
are
cutting
it
really
close
to
that
deadline
might
have
a
other
slew
of
issues
with
it,
but
potentially
from
a
release.
Lease
or
the
docs
release
leads
perspective.
A
Maybe
there
could
be
additional
communication
going
out
saying
like
yeah,
the
placeholder
deadline
is
code
freeze
but
like
the
sooner
you
get
it
in
the
sooner
we
can
review
it,
and
I
I
don't
know
how
you
can
promote
that.
You
know
I've
been
in
the
same
boat
or
I've
worn
those
shoes
where
you're
commenting
on
github
saying
like
is
there
any
updates
you're
following
finding
people
in
slack
you're,
not
getting
movement
there?
A
And
I
truly
believe
that
the
folks
that
are
going
to
be
on
top
of
this
and
creating
documentation
early,
don't
need
those
comms
and
then
the
folks
that
you're
going
to
communicate
to
saying
that
hey
earlier
the
better,
it's
great
they're
still
going
to
wait
most
likely
till
the
deadline.
But
in
my
magical
dream
world
I
see
that
that
communication
piece
being
beneficial
and
then
still
moving
that
deadline.
So
you
have
that
review
if
needed,
for
the
folks
who
are
on
top
of
it,
but
I
don't
know
if
that
would
actually
work
or
not.
I
I
also
have
some:
if
people
want
to
talk
more
about
the
the
deadline
move,
we
can.
I
had
some
general
feedback
on
the
release.
My
notes.
F
I
So
my
overall
feedback
is
I've
been
sort
of
watching
sig
docs
for
three
four
releases.
Now
this
one
went
the
smoothest
I've
seen
so
good
work,
anna
good
work
and
his
team
good
work.
All
the
sigs
because,
like
what
I'm
seeing,
is
that
there's
there's
kind
of
there's
six
that
take
a
responsibility
for
an
area
of
functionality.
You
know
like
sigourth
or
cygnode
and
then
there's
sort
of
cross-cutting
sigs
like
sig
security.
I
I
I
guess
you
could
you'd
stay
there,
and
this
is
good
and
then
it's
sort
of
enabling
six
sig
release
is
an
enabling
sig,
said:
contributor
experience,
sig,
docs
and
it
felt
like
you
know:
sigs
were
coming
together
to
enable
those
sort
of
feature
teams
or
whatever
you
want
to
call
them
to
deliver
the
thing
like
where
our
job
is
to
help
those
other
teams.
You
know
deliver
test
like
I
want
to
test
my
feature.
I
want
to
get
my
feature
accepted.
I
want
to
communicate
about
my
features
so
the
world
knows
about.
I
E
I
have
one
question
for
you,
anna,
which
is,
I
know
you
were
concerned
slightly
before
kubecon,
about
the
fact
that
the
doc's
deadline
was
like
directly
after
kubecon.
Is
there
anything
we
could
have
done
differently?
Did
that
go
well
in
the
end
first
off,
and
secondly,
is
there
any
way
we
could
have
organized
better
support
for
you
in
that
regards.
F
Yeah,
but
I
think
because
I
like
I
mentioned
that
like
a
way
beforehand
like
for
sick
dogs
to
keep
eyes
on
the
reviews
and
stuff,
I
think,
like
generally
like
our
communication
with
the
docs
team
and
the
sick
dogs
like
made
it
all
possible,
like
I
didn't
think
I
don't
know
about
you
guys,
but
there
was
a
lot
of
pr's
open
at
by
the
deadline
and
the
deadline
did
get
moved.
I
don't
know
if
you
remember
for
like
few
days
like
three
days.
F
I
I
believe,
and
even
without
that,
I
think
we
would
have
been
a
good
place
regardless,
and
I
think
it
was
all
because
of
the
communications
that
we
have.
You
know
done
in
the
sick,
docs
meeting
and
just
like
in
slack
and
stuff
like
that.
So
I
mean
it
was
all
mostly
because
you
guys
were
all
on
top
of
reviewing
and
approving,
and
I
think
that's
why
it
was
still
successful,
regardless
of
like
thanksgiving
and
ku
khan
and
all
the
events
that
happened
in
november.
A
Cool
yeah,
definitely
you
know
I
do
want
to
add
as
well
from
from
my
perspective.
You
know
I
I
thought
that
each
subsequent
release
has
been
better
and
better
after
the
last
and
when
I
joined
the
release
team,
I
want
to
say
it
was
like
111
or
112..
A
A
I
feel
like
I
love
technology,
but
I'm
definitely
not
like
a
github
guru.
I'm
definitely
not
up
on
all
of
the
open
source
processes,
and
things
like
that
at
the
time
that
I
joined,
where
I
didn't
feel
like,
I
was
properly
given
the
instructions
or
the
tools
that
needed
to
perform
a
release
cycle.
So
I
wanted
to-
and
I
want
to
say,
like
dumb
down
the
handbook
for
myself,
but
but
not
really
dumb
it
down.
I
wanted
to
over
explain
the
details
in
the
handbook
and,
as
a
result,
we
had
this
handbook.
A
A
It's
been
improved,
it's
been
modified
to
match
the
needs
as
the
release
changes
as
the
teams
change
and-
and
I
can't,
but
I
can't
begin
to
explain
how
happy
I
am
to
see
the
amount
of
frequent
prs
to
the
handbook.
It
was
a
dead
and
dying
document
when,
when
I
looked
at
it
a
few
years
back
and
I
think
as
a
valuable
asset
and
the
amount
of
effort,
whether
it's
large
or
little
on
the
handbook
benefits
like
it's
like
compounding
benefit
for
the
next
and
future
release
leads.
A
So
I
was
really
thrilled
to
see
that
see
the
continuation
and
then
to
echo.
The
comments
that
have
already
been
made
is
to
see
the
additional
communications,
and
I
think
that
that
release
channel
for
sig
doc's
release
was
new.
This
cycle
in
1.20,
and
that
was
incredible
to
see
the
amount
of
communication,
the
daily
updates
of
statuses.
A
You
know
I
feel
like
I
was
just
scrolling
through
slack
and
I
was
able
to
see
the
current
status
of
the
docs
team.
You
know
it
wasn't
in
a
private
messaging
channel.
How
it
was
done
historically,
was
all
wide.
It's
all
done
out
in
the
open.
I
think
that
that
channel
was
huge
from
a
communication
and
openness
standpoint
that
that
really
helped
the
release
out.
So
the
tl
dr,
is,
I
thought
the
release
went
awesome
and
he
did
an
awesome
job.
A
All
right
here,
nothing,
I
know
we
got
about
five
minutes
left.
We
definitely
spent
a
ton
of
time
on
that
topic,
but
I
think
the
conversation
is
very
valuable
for
for
me
and
then
the
sig
docs
organization,
definitely
so
moving
on
for
the
blog
update
is
there.
Another
call
wants
to
give
us
an
update.
A
H
Really
nothing
that
new
and
exciting
other
than
you
know
we
need
to
do.
I
think
some
more
kind
of
awareness
and
visibility
building
around
the
blog
process.
Again
we
kind
of
go
through
this.
Every
couple
quarters-
or
so
I
would
say
so-
we're
going
to
be
meeting
on
thursday
to
talk
a
little
bit
about
that
and
then,
as
usual,
we
are
always
looking
for
new
reviewers
for
blog
posts
as
well.
H
We've
made
it
pretty
easy
for
people
to
get
involved,
and
you
know
showing
up
to
that
blog
review
meeting
on
thursdays
is
really
the
best
way
to
to
get
kicked
off,
but
the
idea
is
that
you
would
kind
of
review
as
a
standard
github
member
go
through
a
few
cycles,
see
if
it's
something
you're
interested
in
get
a
feel
for
the
process
and
then
you
would
essentially
move
to
kind
of
a
formal
approve,
a
formal
approver
with
permissions,
and
all
of
that,
after
a
few
cycles
of
that
so,
like
I
said,
if
anyone's
interested
show
up
on
thursday
or
just
ping
me
on
slack,
I
know
we
have
a
couple
people
interested
so
we'll
probably
be
doing
a
couple.
A
Awesome
sounds
good
and
then
would
you
mind
throwing
the
the
team
meeting
link
or
something
similar
for
folks
who
are
interested
in
the
agenda.
There.
A
Sweet
awesome,
cool
moving
on
celeste,
you
have
some
issues
and
pr's
you'd
like
to
talk
about.
E
I'm
wondering
if
it's
actually
better
to
push
these
to
next
week,
just
because
they
are
a
slightly
involved
conversation,
but
I
will
give
you
a
preview
and
then
everybody
can
just
take
a
whole
luxurious
week
to
look
through
these.
E
The
tl,
dr,
is
the
two
prs
listed
in
the
agenda
under
my
name,
are
around
updating
the
guestbook
tutorial
on
the
website,
so
that
involves
updating
the
example
as
well
as
updating
the
text
they
were
opened
in
the
name
of
working
group
naming
on
behalf
of
thank
you,
anna,
oh,
no
you're,
something
else.
Anyways
the
they
were
open
on
behalf
of
kind
of
working
group
naming
to
remove
some
problematic
language
that
did
exist.
In
those
examples
and
from
a
naming
perspective,
we
are
comfortable
with
the
change.
E
However,
the
implementer
decided
to
make
these
changes
by
wholesale
replacing
database
in
the
example
with
redis,
which
is
a
very,
very
large
change.
We
are
changing
from
a
database
to
something
which
is
not
quite
a
database
now
for
the
positive.
The
example
still
works
from
a
kubernetes
perspective.
We
are
still
teaching
people
the
basics
of
working
with
kubernetes
in
a
particular
way.
E
However,
at
this
point
we
need
sig
docs
to
kind
of
jump
in
on
that
and
provide
a
bit
of
review
as
to
whether
we're
okay
with
a
change
on
the
magnitude
that
that
was
made.
So
that's
kind
of
thing
number
one
thing
number
two:
it
is
very
likely
that
this
particular
committer
puzzler
will
be
too
busy
to
actually
push
these
pr's
over
the
line.
So
we
may
need
to
take
over
the
pr
on
their
behalf,
at
the
very
least
the
website.
E
A
Awesome
thanks
for
that
celestia
yeah,
and
I
think
this
would
be
a
little
bit
of
a
wider
discussion
better
suited
for
next
week
or
the
week
after
that-
and
I
thought
about
that
when
we're
shifting
over
to
your
your
agenda
item,
but
I
was
like
you
know,
I
feel
like
it's
a
less
action
item,
for
whatever
reason
it
is
had
to
get
pushed
for
a
few
weeks
that
I
don't
know.
However,
many
weeks
ago,
I
don't
know
what
it
is.
You
know
it's
just
timing.
I
guess
yeah.
E
A
Cool
so
we're
out
of
time.
Unfortunately,
so
there's
not
room
to
continue
on
the
agenda.
I
will
end
up
moving
some
things
around
and
opening
up
the
next
meetings
agenda
too.
If
we
wanted
to
add
additional
topics
there
as
always
be
great
to
each
other
and
that's
a
sig
docs
meeting.
Okay
talk
to
y'all
later.