►
From YouTube: Kubernetes Sig Docs 20180320
Description
Meeting notes: https://docs.google.com/document/d/1Ds87eRiNZeXwRBEbFr6Z7ukjbTow5RQcNZLaSvWWQsE/
The Kubernetes special interest group for documentation (SIG Docs) meets weekly to discuss improving Kubernetes documentation. This video is the meeting for 20 March 2018.
https://github.com/kubernetes/kubernetes.github.io
A
A
A
C
1.10
is
going
that
Ken's
a
little
interesting
this
week
we
have
a
PR
in
to
revert
and
alpha
feature
because
reverting
the
PRS
for
the
feature
itself
will
break
things
and
that
just
got
approved
this
morning,
which
means
I
closed
one
Doc's
PR
unmerged.
It
was
not
in
a
great
state
anyway.
So
that
was
fortunate.
That
simply
means
less
work.
For
me
finishing
things
up,
there's
one
more
PR
that
I
discussed
with
Joe
and
Steve.
Yesterday
that
I
am
going
to
merge.
It
appears
to
a
past
technical
review.
C
It
some
more
dhoklas,
but
persuading
any
further
changes
in
the
PR
seems
burdensome
to
everybody.
So
it's
going
to
be
easier
to
merge
it
and
then
submit
a
fast
follow
to
fix
things
up.
So
that's
the
only
it's.
The
only
bit
of
content
related
work
that
I
have
later
today,
I'm
gonna
start
systematically
picking
through
generating
the
docs
for
next
week.
Otherwise
the
release
is
looking
on
target
for
Monday
I.
Think
I
dropped
off
early
because
I
wanted
to
join
this
meeting.
C
D
C
A
C
A
D
D
While
you
are
starting
implementation,
it's
not
like
it's
a
surprise
and
you're,
not
making
like
he's
kind
of
drive-by
commits
in
the
general
case.
So
I
would
love
to
explore
ways.
We
can
use
the
kept
process
just
to
try
and
help
front-load
some
of
ICH
I.
Guess
the
like
the
vomit
draft
quality
release
notes
as
part
of
an
over
normal
development
process.
So
we
can
start
fronting
this
and
start
getting
the
eyes
on
that,
rather
than
waiting
until
the
end,
because
it's
painful
release
over
release
I
mean.
D
Obviously
we
are
improving
lose
of
the
release,
but
I
still
think
there's
a
ways
we
can
improve
and
I've
been
looking
at
I've
been
following.
You
know
not
super
closely
but
tended
to
lead
to
the
Russ
project.
I
think
they
do
a
really
good
job
with
their
RFC's
in
terms
of
documenting
it.
Upcoming
large
changes
both
for
other
developers
and
for
users
of
rust,
so
I
would
to
use
their
work
as
a
guiding
kind
of
lodestar
there
and.
E
Then
maybe
I
should
give
some
background
on
the
dockside,
because
so
in
previous
meetings,
we've
talked
about
like
yeah.
How
do
we
get
involved
earlier
on
in
the
process
so
that
we
can
work
with
the
engineers
to
get
them
to
write
some
of
the
documentation
before
before
the
end
of
like
the
release
cycle?
And
you
know
I
think
we
had
discussed
some
ideas
like
you
know,
maybe
assigning
different
right.
E
Here's
two
SIG's
and
can
be
came
with
that,
but
it
seemed
like
a
lot
of
overhead
and
we
didn't
make
much
progress
on
it
yet
so
when
I
was
talking
to
Caleb,
it
seemed
like
if
if
the
idea
is
to
move
to
this
kept
process
so
that
you
know
when
people
are,
you
know
creating
features
even
before
they
write
the
code.
You
know
they
submit
a
cap
and
stuff
and
we
pull
in
some
of
the
documentation,
part
of
that
that
will
give
us
more
visibility
and
then
give
us
kind
of
involved
earlier
on.
A
Andy
so
using
the
the
kept
process
as
part
of
a
wider
or
part
of
rolling
out
the
kept
process
on
a
wider
basis
for
future
enhancements
to
kubernetes
and
using
that
as
an
opportunity
to
get,
let's
call
them
early
quality.
Early
quality
drafts
of
release
notes
into
the
publication
process
for
the
record
early
release
is
not.
E
And
then
you
know
like
email,
us
and
then
we'll
know,
Oh
like
there's
this
feature
coming
up,
there's
this
documentation
and
then
this
is
the
you
know
the
engineer
or
whoever's
in
charge
of
it,
and
then
we
can
start
working
with
them.
You
know
earlier
on
to
get
the
docs
and
release
notes
done.
Okay,.
D
Long
term
for
the
kept
process
itself
to
be
owned
by
CPM
SiC
docks
Zig
release
moving
forward,
because
we
are
these
kind
of
horizontal
SIG's
responsible
for
your
knowing
what's
coming
in
the
release
or
just
knowing,
what's
coming
in
in
general,
for
the
project
and
communicating
that,
because,
if
you
know
a
PR
without
documentation
is
not
useful
to
any
movie,
anyone
so
trying
to
get
all
of
these
processes
tied
together
would
be
wonderful.
So.
E
Then
you're,
probably
all
asking
well
then:
okay,
what's
what's
the
next
step,
so
we
were
thinking
about
first,
just
picking
like
one
kept
as
a
sort
of
a
pilot
and
kind
of
going
through
that
process
like
manually
and
then
seeing
how
that
goes,
and
then
iterating
on
that
and
Caleb.
There
was
one
that
you,
you
thought
might
be
a
good
candidate.
D
Yeah
we
may
want
to
start
with
the
cluster
API
work
there
kept
is
largely
done,
but
did
we
need
now?
What's
the
motivation?
I
guess,
as
we
have
implications,
come
in
I
think
that
cap
was
gonna,
see
some
active
use,
because
that
work
is
is
really
getting
going
here,
at
least
on
our
side.
So
it's
a
mother,
so
other
groups
are
also
working
pretty
heavily
on.
E
A
A
Right
now
we
had
talked
about
having
Nick
chase
run.
111
I
bet,
I,
have
not
followed
up
with
him
and
I.
Have
some
thoughts
about
I
has
some
thoughts
about
1.11.
If
it's
not
Nick,
it
will
be
myself,
but
that's
a
good.
That's
a
follow
up
conversation.
They
need
to
have
with
Nick
and
would
like
to
have
with
Nick
first
and.
C
E
Yes,
I
just
want
to
make
sure
whoever
is
in
charge
of
the
1.11
Ducks
release
process
really
is
involved
in
in
this
pilot,
so
we
can
kind
of
work
out.
The
you
know,
figure
out
the
issues
and
see
if
it
helps
okay,
because
if
it
doesn't
help
improve
the
process,
then
there's
no
point
but
I
think
we
should.
We
should
be
able
to.
E
F
A
Are
you
proposing
to
use
this
kept
process
to
because
would
notification
of
Doc's
be
any
earlier
I
mean
so
I
hear
that
you're
trying
to
close
the
gap
between
yes,
there
will
be
doc
sent
here
is
an
early
draft
of
those
Doc's,
but
will
will
this
proposal
move
Doc's
any
earlier
in
the
release
timeline?
We.
D
A
A
D
Actually,
we
should
think
about
actually,
as
you
mention
it
yeah,
we
should
bring
this
up
in
contributor
experience,
so
the
owners
files
today,
the
way
we
use
them-
I,
don't
I,
guess
allow
four
categories
of
required
reviews.
So
there's
no
way
of
saying
that
you
know
these
are
the
docs
owners
for
this
SIG.
D
These
are
the
the
engineering
technical
for
this
for
this
part
of
the
tree,
but
it
might
be
nice
to
extend
that
just
have
a
align,
the
other
files,
but
we
can't
do
something
that
the
way
that
tests
in
front
does
is
they
use,
get
up
cut
owners.
So
they
get
notifications
when
pull
requests
are
open
to
various
parts
of
the
tree.
So
we
can
do
that
as
well
and
only
have
Doc's
people
pinged
on
on
that
jar.
So
you
automatically
get
added
to
the
edited
to
request
sure.
A
So
I
also
think
about
Jennifer
and
her
experience
with
release
notes
in
like
one
dad,
1.8
1.9,
specifically
where,
when
automation
was
happening,
oftentimes
like
release
note
features
would
be
filled
out
with
TBD
or
you
know,
things
that
meet
the
gate.
Check
are
checked
in,
but
no
actual
content
is
checked
in
so
I
guess:
I
I,
like
the
idea
that
I'm
hearing
I'm
just
not
sure
how
it
will
immediately
connect
to
getting
to
getting
engineers
to
or
future
owners
to
create,
better
documentation
earlier,
rather
than
just
saying.
A
Yes,
this
is
where
documentation
will
go
and
then
putting
it
to
the
end.
So
there's
there's
I,
guess
the
there's
the
part
of
the
cycle
that
will
make
life
easier
for
us
and
then
there's
the
part
of
the
cycle,
the
other
half
of
it
that
we're
future
owners
have
to
actually
do
that
work
earlier.
I
guess
mm-hmm!
C
I've
been
wondering
and
I'm
happy
to
hold
back
a
bit
further,
but
it
seems
as
though
the
issue
that
I
created
this
morning
and
the
item
that
you
asked
me
about
that
I
has
been
on
the
agenda
about
improving
release.
Note
content
is
in
fact
pretty
relevant
here,
because
if
we
step
back
and
I
mean
I,
don't
know
if
you
want
me
to
pursue
that
it's
as
it's
I
think
that
what
I've
been
chatting
about
with
some
other
folks
and
tried
to
describe
those
conversations.
C
D
C
So
you
know,
I
was
one
of
the
release
notes.
Wranglers
41.8
I
was
the
main
release
note
Wrangler,
with
Nick
chase,
for
one
up,
nine
and
I've
been
you
know,
sort
of
not
shadowing
Nick,
but
following
the
work
that
he
and
Noah
have
been
doing
for
1.10,
so
I've
been
in
the
trenches
with
a
release.
Note,
pain
and
I
think
that
I
mean
I.
Can
my
focus
on
improving
process
over
the
release
cycle
has
been
primarily
on
release.
Notes,
I.
C
Think
that
Doc's
can
you
know,
sort
of
come
along
for
the
ride,
with
some
of
the
stuff
that
I've
been
thinking
about
and
talking
about
with
other
folks,
but
that's
been
less
of
the
focus.
My
experience,
wrangling
Docs
for
110
is
that
the
feature
spreadsheet
and
working
closely
on
tracking
features
with
a
in
for
110
at
least
has
worked
quite
well.
Not
everyone
gets
a
stub
PR
in
early
and
yes,
I
had
to
do
some
pretty
heavy-duty
nagging
of
contributors
on
Docs
PRS
over
the
course
of
the
last
couple
of
weeks.
C
I
also
stepped
into
active
engagement
with
those
PRS
relatively
late
in
the
cycle.
So
I
don't
think
my
experience
of
110
is
solid
data
for
for
that
issue,
1.10
also
wound
up
being
unexpectedly
feature
light,
so
I
just
I
want
to
put
you
know,
sort
of
qualifiers
around
any
stories.
I
might
tell
about
how
well
or
poorly
the
current
process
works
for
docs,
as
opposed
to
release
notes
for
release
notes.
However,
we
can
and
should
do
a
lot
better
and
during
the
1.9
release,
I
was
hearing
a
fair
amount
about
the
caps.
C
The
caps
and
the
proposal
to
institute
them
and
I
was
pretty
excited
about
it
and
I
still
am,
but
it
turned
out.
It
was
not
something
everybody
got
on
board
with
right
away,
and
so
it's
something
that's
going
to
get
rolled
out
more
slowly
and
possibly
get
iterated
on
over
time.
I
think
that
we
also
have
the
the
opportunity
in
cig
Docs
to
improve
release
notes
across
SIG's
without
limiting
ourselves
to
the
cap
process
and
to
that
end,
I
put
some
of
the
ideas
that
some
of
us
have
been
talking
about
in
the
issue.
C
That's
linked
from
the
meeting
notes.
The
the
short
version
is
get
release,
notes,
reviewed
well
reviewed.
Ideally,
by
someone
from
sig
Docs
who's
got
a
good
grasp
of
what
should
be
in
the
release
notes
when
the
PR
is
reviewed
now
and
my
initial
thought
this
came
out
in
conversation
with
Andrew
and
Steve
was
we
could
rotate
sig
Docs
maintained,
errs
through
on
a
weekly
basis.
C
Not
here
because
he's
in
the
release
meeting
released
burndown
today,
you
is
to
develop
a
more
fine-grained
set
of
labels
that
I
it
looks
like
they've
done,
a
pretty
good
job
of
getting
those
labels
applied,
so
that
we're
filtering
only
on
release,
notes
that
users
really
do
need
to
read
and
not
every
last
little
detail.
Those.
C
Think
so,
I'm
not
looking
right
now,
I've
I
have
not
investigated
this
thoroughly
and
Nick
and
I
haven't
had
a
chance
to
meet
as
completely
as
I
would
like.
But
I
did.
You
know
since
I've
been
a
part
of
several
conversations
and
since
I
brought
this
up
last
week,
I
thought
it
would
be
a
good
idea
to
try
to
collate
all
of
this
conversational
information
in
the
issue.
So
everybody
can
take
a
look
because.
A
A
C
So
yes
and
I'm,
not
completely
sure
cuz
I
haven't
a
chance
to
think
it
through,
but
I'm
coming
at
all
of
this
from
an
original
dream
of
getting
the
kept
process
instituted,
you
know
sort
of
see
you
know
across
all
the
SIG's
and
using
that
to
wrangle,
better
release,
notes.
So
I
know
what
you
guys
are
talking
about
I'm,
given
that
we
don't
have
that.
That's
where
Nick
and
I
started
pursuing
other
options
right
and
the
so
I
definitely
see
these
as
at
worst
complimentary
and
at
best
really
kind
of
converging
on
good
solutions.
E
C
E
Look
at
and
act
the
actual
kept
for
a
second,
because
if
you
can
see
there's
already
a
lot
of
things
written
so
I
think
some
of
that
can
be
folded
into
you
know
the
release
note
or
and
or
the
documentation
like,
for
example,
the
you
know
like
the
summary
and
and
then
there's
like
use
cases,
and
things
like
that.
So
maybe
if
one
of
these
sections
were
kind
of
the
short
form
version
that
we
would
use
in
a
release
note
that
would
kind
of
do
both
things.
E
That
would
you
know,
give
a
quick
summary
and
we
can
reuse
that
as
the
release
note
for
the
particular
feature.
So
and
then
you
know
a
lot
of
this,
you
know
right
kind
of
describes
what
this
should
be
doing,
which
I
think
could
easily
be.
You
know
refactored
or
used
in
the
actual
documentation
that
will
that
would
need
to
be
created
for
it.
So
I
mean
it's
just
that
perfect
that
you
know
at
this
moment,
but
I
think
we
can
kind
of
massage
it
to.
C
Yeah
I
agree.
Absolutely
I
guess
you
know.
My
point
was
you
know
we're
at
a
point
now
where
what
the
resources
we
have
available
are
going
to.
Let
us
pilot
the
approach,
not
across
all
features
and
all
SIG's
for
a
given
release.
So
the
kinds
of
bits
and
pieces
that
I've
been
talking
about
woods,
you
know
help
serve
release,
notes
for
other
features
that
have
not
sort
of
gone
through
the
process
yet
and
we'd
have
to
figure
out
how
to
make
these
things
dovetail.
Yeah.
E
C
That
doesn't
seem
like
an
insurmountable
barrier
at
all
and
since
other
things
that
I
talked
about
and
in
the
issue
have
to
do
with,
for
example,
there's
a
release
notes
markdown
file
in
cig
community.
That
does
not
actually
explain
how
to
write
a
good
release.
Note
now
the
chances
of
people
referring
to
that
markdown
file
are
small,
but
they're
not
come
solutely
nonexistent
the
more.
We
can
improve
the
material
that
people
have
available
and
promote
it
to
help
them
write
better
release.
C
Note
copy
to
sync
in
terms
of
user,
facing
content,
whether
it's
Docs
or
release
notes
the
better
off
we're
going
to
be
the
better
the
material
that
we
work
from.
You
know
you
know
in
automated
or
semi-automated
fashion,
it's
going
to
be
whether
it's
in
a
kept
or
in
an
issue
or
in
a
PR
I'm
thinking.
You
know
we
can
also
link
out
to
that
release,
notes
markdown
file
from
the
PR
template.
Now.
C
Yes,
we've
all
seen
what
happens
to
the
PR
template,
especially
for
Docs
people,
don't
even
fill
it
out
and
the
PRS
just
come
in
with
the
template
still
right
there.
But
a
few
people
do
read
it.
You
know
it's
like
you,
try
all
the
things
and
at
a
certain
point,
yes,
you
have
to
say
well,
no
wait
a
minute.
What
about
this
and
more
conversation
needs
to
happen,
but
the
more
resources
that
we
can
provide
to
people
upfront,
you
know,
part
of
being
part
of
Paris's
maintained,
errs
new
new
maintainer
x'
training.
C
E
G
D
E
Mean
it
would
I
think
be
several
releases
before
we
could
do
that,
but
this
is
more
to
see
like
you
know,
assuming
we
did
get
more
of
these
features
in
as
keps
like
you
know,
early
on,
like
how
might
this
help
us
improve
the
release
and
docs
press
release,
notes
and
Doc's
process
yeah?
Okay,
thanks.
A
C
C
You
know
ongoing
discussion
about
what's
doable
at
you
know
what
stage
this
is
got.
This
is
gonna
have
to
be
iterative.
You
know
we
can't
do
everything
you
know
for
1.11,
but
we
can
make
incremental
progress
and
I
feel
like
Nick,
especially
who
couldn't
be
on
this
call
and
and
Noah.
His
shadow
have
done
some
really
good
things
to
put
better
support
for
automation,
of
the
release,
notes
in
place
so
I
want
to
I
want
to
partly
I
want
to
call
out
Nick
and
partly
I
want
to
invite
people
to
weigh
in
on
the
issue.
A
C
Think
so,
when
I
saw
the
item
in
the
agenda,
I
kind
of
expected
these
two
items
to
dovetail
the
cap
item,
I
mean
I,
mean
I,
wasn't
sure
it
was
going
to
be
about
cap,
but
I
had
a
guess
that
it
might
be.
A
Thank
You
Jennifer,
alright,
moving
on.
Let's
talk
about
migrating
the
website
from
jekyll
to
Hugo,
so
to
give
you
an
update,
Jared
and
myself
and
Andrew
and
Jennifer
and
Joe
heck,
met
yesterday
with
yarn
Eric
Peterson,
and
we
have
decided
to
go
forward
with
the
migration
process
and
functionally.
What
that's
going
to
look
like
is
that
Bjorn
is
going
to
do
two
days,
16
hours
worth
of
work
and
that
will
result
that's
going
to
be
work.
A
That's
involved
in,
like
assessment,
making
some
say,
hang
on
my
mom
assessment,
making
some
trial
attempts
at
getting
a
Hugo
build
integrated
with
Matloff
I,
with
a
within
that
laughs
I
instance
up
and
get
a
proof
of
concept
and
also
make
sure
that
he
has
a
true
sense
of
what
the
actual
migration
work
would
require.
And
when
we
have
that
initial
assessment,
we're
going
to
review
that
and
save
document
a
nurse
I'm
going
to.
A
There
are
some
things
that
will
change
in
our
in
our
tooling
the
config
dot
llamo
and
the
the
website
root
directory,
no
more
gems
included.
So
it's
going
to
be
interesting
to
see
how
how
our
website
maintains
its
current
function
in
a
different
stack
and
with
with
a
slightly
different
tooling
chain.
And
it's
going
to
be
important
for
all
of
us
to
put
eyes
on
any
of
those
proposed
changes
and
make
sure
that
we
get
a
full
sense
of
what
in
our
tooling
chain,
is
actually
going
to
going
to
change
and
be
different.
A
A
One
thing
that
Bjorn
pointed
out
about
the
migration
process
is
that
when
we
are
ready,
when
we
are
ready
to
actually
cut
over
the
site
from
Jekyll
to
Hugo
any
open
PRS
that
we
have
become
a
source
of
potentially
large
merge
conflicts.
So
as
the
as
we
get
close
to
an
actual
merge,
we're
going
to
need
to
have
a
like
a
PR
reckoning,
I
guess
where
all
of
our
PRS
are
either
merged
prior
or
or
are
closed,
and
just
to
avoid
the
the
massive
merge
conflicts
that
are
going
to
come
after
that.
A
We
we
talked
with
bjorn,
and
let
him
know
that
our
quarterly
release
cycle
means
that
ideally
well,
we
need
to
see.
We
need
to
be
if
we're
going
to
migrate
to
hugo.
In
the
next
couple
of
months,
we
need
this
by
May
first,
because
that's
realistically,
as
close
as
we
can
get
to
to
1.11
and
still
have
any
chance
of
meaningful,
emerging,
PRS
and
doing
documentation
for
1.11,
and
he
seemed
to
think
that
was
no
problem.
So
I
guess
the
the
summary
is
sig.
G
Yeah
I
I,
don't
think
we're
gonna
get
to
0,
PRS
and
I.
Don't
think
we
want
to
just
close
close
PRS
that
we
can't
get
merged.
I.
Think
we'll
just
have
to
live
with
a
certain
list
of
PRS
that
are
gonna,
hang
on
through
the
process
and
then
they'll
be
there'll.
Be
some
extra
work
to
do.
You
know
if
you
know
when
it
comes
time
to
merge
those
yeah.
G
F
Yeah
I
agree,
I
think
there's
yeah
there
might
be
ways
to
migrate
some
of
those
over,
but
I
think
we
should
do
a
really
good
job
with
due
diligence
closing
the
ones
that
we
can.
One
Center
out
gate
is
reaching
out
to
the
people
who
file
some
may
be
declaring
bankruptcy
on
a
few
that
are
no
longer
relevant
or
very
low
priority
and
restage
that
me,
it's
been
your
site,
yeah
I,
think
with
some
of
these
ones
that
are
sort
of
hanging
out
at
the
very
end.
F
Whoa
Bobby
come
up
with
a
planner
on
that,
but
I
think
yeah
being
being
aggressive
during
the
migration
and
like
trying
to
get
that
down
to
the
smallest
number
possible
is
going
to
save
us
a
lot
of
headaches.
What
we
cut
over
and.
A
A
H
You
know
we
actually
in
contributor
experience
and
our
charter
recently
did
our
communication
plan
and
that
might
be
good
for
you
to
bake
into
your
charter
as
well
on
how
you're
communicating
out
your
changes.
For
instance,
on
contributor
experience
any
time
we
have
a
major
change
for
first,
we
socialize
that
with
our
working
group
mailing
list.
H
Oh
my
gosh,
it's
not
a
working
group,
it'll,
say
I,
don't
know
what
I'm
talking
about
with
our
saved
mailing
list
and
then,
after
that
we
lead
to
consensus
time
box
it
in
and
then
once
that
happens
and
prototyping
is
begun.
Then
we
email,
KK
and
then
also
email.
The
signal
the
sick
leaves
and
then
in
some
cases,
steering
committee
if
needed,
and
that
is
going
to
be
our
go
forward
always
now,
so
that
sig
leaves
and
people
that
are
heavily
involved
in
SIG's
know.
H
They
know
that
contributor
changes
are
are
coming
and
we've
even
included
like
a
special
subject
line
that
says
notice
in
big
capital,
letters.
Okay,
so
now
you
know
some
of
the
some
of
the
folks
that
have
complained
in
the
past
now
know
that
those
are
the
channels
that
were
using,
so
I
would
definitely
turn
try
to
keep
that
in
mind
with
with
Docs,
and
it
could
be
a
good
way
to
to
have
folks
know
where
to
look
in
the
future
and
for
anything
Docs
related
outside
coming
into
this
meeting
or
or
joining
your
mailing
list.
H
A
G
F
A
G
A
A
A
Yeah
Joe
Joe,
chimes
in
and
says
I,
don't
think
we
can
turn
off
PRS
in
a
public
repo,
but
we
can
reapply
and
get
back
or
in
get
more
response
and
saying
closed.
Please
come
back
in
two
weeks
like
whoever's
is
wrangling
PRS
in
those
two
weeks,
and
you
know,
have
the
I
guess:
have
a
copypasta,
splat
handy
and
just
get
used
to
clicking
close
a
lot
okay.
A
So
if
there's
more,
there
will
be
more
questions
and
more
information
as
we
go.
If
you
have
questions
or
concerns
or
suggestions
as
we
move
along
as
we
move
along
this
process,
please
feel
free
to
reach
out
I'm
happy
to
to
make
sure
that
that
any
questions
are
addressed,
that
the
the
next
concrete
step
will
be
an
invite
sent
out
to
sigdoc
to
maintain
errs
to
participate
in
the
two-day
review.
A
G
I
I
merged
and
closed
many,
but
they
come
in
almost
as
fast
as
you
can
work
on
them,
and
then
there
were
several
that
you
know.
I
went
through
and
looked
at
them
and
maybe
added
some
labels
but
they're
in
this
state
of
waiting
for
either
a
tech
review
or
a
doc
review
issue
to
be
to
be
resolved
and
then
I
guess
the
third
category
that's
a
bit
stuck
would
be
ones
that
say
it's.
You
know
something
like
working
progress.
Do
not
merge.
A
So
I
am
the
Wrangler
this
week
and
I
noticed
when
I
was
reviewing
the
PR
q
last
night,
I
saw
I
saw
the
the
PRS
that
you
would
touch
for
that
week,
and
there
were.
There
are
a
lot
of.
There
are
a
lot
of
issues
right
now
that
you
either
need
tech
review
or
in
the
ducts
review.
I,
don't
know
what
to
do
differently
about
those
other
than
in
some
cases
where
it
was
clear
that
people
had
been
assigned
or
that
there
was
a
clear
task
that
went
through
and
I
left
a
comment.
A
Saying:
hey,
please
follow
up
on
this
I
I,
don't
know
what
to
do
other
than
continuing
to
do
what
we're
doing
and
maybe
set
an
expectation
that
if,
if
action
has
been
assigned
or
like
some
kind
of
action
has
been
assigned
and
there's
no
response
in
30
days
or
I
didn't
even
know.
If
we
need
to
do
that,
we
just
can
let
beta
BOTS
tail
it
out.
I.
E
A
A
A
Well,
in
that
case,
I
think
yeah.
Maybe
we
can't
rely
on
the
bot
to
steal
things
out
so
I
guess,
let's
include
in
the
PR
rotation
and
Joe
I,
may
make
a
and
updates
to
your
Wrangler
guidelines
to
be
more
active
in
pursuing
reviews
and
in
closing
things
where,
where
action
has
not
been
clear
or
is
starting
to
stale
out,
so
we've
got
PR
Wranglers
for
the
next
two
weeks
after
this
Jennifer
is
next
week.
C
If
someone
else
is
willing
to
pick
it
up,
it
might
be
prudent,
but
for
what
it's
worth,
I
have
also
been
monitoring.
I
mean,
regardless
of
who's
formally
assigned
I,
have
been
monitoring
the
PR
Q
sort
of
coming
in
behind
you
assiduously,
because
of
a
situation
that
we
inevitably
have,
especially
toward
the
end
of
a
release
where
folks
submit
to
the
wrong
branch
and
I've
been
really
trying
hard
to
keep
well,
first
of
all
to
track
all
of
the
1.10
related
ducks
PRS
because
they've
been
you
know,
various
sort
of
upstream
release
related
issues.
C
C
A
A
G
I've
also
come
around
to
thinking
that
it's
probably
what
we
should
do,
the
you
know
the
the
using
master
for,
as
the
engineering
team
to
do
is
so
ingrained
in
people's
mind.
It's
just
really
hard
for
them
to
adjust
our
opposite
way
of
doing
it.
So
I'd
like
to
open
to
have
that
discussion
again
and
I'll.
C
I'll
be
a
strong
third
to
that
proposal.
The
other
thing
the
thing
that
I
see
happen
is
even
folks
who
know
that
Docs
does
it
differently,
get
confused.
They
know
they're
not
supposed
to
submit
to
master,
but,
oh
my
goodness,
what
do
I
do
and
they'll
ask
questions
in
the
PR
so
well-intentioned
folks,
from
outside
our
little
world,
get
confused
by
what
we
do.
Okay,
yeah.
A
I
So
we
talked
a
few
weeks
ago
about
kind
of
a
desire
to
make
providers
responsible
for
their
documentation
and
removing
that
from
the
upstream
branches
in
the
working
group
cloud
provider
meetings.
We
they
pretty
much.
Everyone
agrees
that
that's
a
good
idea
and
with
with
the
migration
of
all
of
the
external
providers,
moving
in
to
it'll
still
be
hosted
in
Corinna
DS
community
repositories,
but
will
be
managed
by
the
individual
owners
of
those
SIG's
as
part
of
that
process
for
defining
common
common
structure
and
common
requirements
across
all
repositories.
I
I
So
our
expectation
is
that
is
that
the
the
technical
requirements
are
going
to
evolve
during
the
1.11
release,
but
that
we
should
be
nailed
down
by
the
end
of
that
of
the
111
release
and
we'll
probably
be
working
with
the
docs
team
to
to
see
how
we
can
produce
those
documents
and
have
them
published.
So
so
that,
so
that's
something
that
I
know
that
I
came
up
as
a
concern
a
few
weeks
ago
and
and
that
the
cloud
provider
working
group
is
interested
in
helping
find
a
good
solution
to
that.
I
A
I
I
To
kind
of
you
know,
of
a
consistent
set
of
documentation
describing
how
this
works
and-
and
you
know
the
I
mean
the
ideas
is
that
users
are
going
to
are
going
to
be
coming
and
thinking
for
these
things,
and
if,
if
we
provide
consistency
across
that
for
all
of
the
providers,
like
you
know,
each
one
of
them
has
a
getting
started
guide
each
one
of
them.
Has
you
know
a
document
that
describes
the
the
the
settings
that
are
available
to
it?
I
You
know
how
to
how
to
enable
the
provider
you
know
with
you
know
through
you
know,
through
their
preferred,
install
or
mechanisms
that
this
this
will
do
a
few
things.
It
relieves
the
burden
from
the
docs
team
of
maintaining
those
documents,
but
it's
still,
but
it
you
know
which
I
think
was
one
of
the
goals
that
we
were
talking
about
a
few
weeks
ago,
but
it,
but
it
also
still
provides
users
with
that
expected
experience.
I
Since
you
know,
since
the
the
cloud
providers
are,
you
know
common,
you
know
it
they're
they're,
common
things
that
people
are
are
using
in
with
the
end,
with
the
move
to
the
to
the
external
cloud
controller
manager.
I.
Think
it's
going
to
be.
You
know
it's
an
opportunity
for
us
to
improve
that
user
experience,
cool.
A
Right
so
yeah
I'm
really
interested
to
take
a
look
at
this
P
R
and
C,
and
just
take
a
look
at
the
discussion
more
deeply.
Would
you
be
willing
to
follow
up
on
this
again
next
week?
Of
course,
yeah.
Ok,
cool
I'm,
just
gonna,
put
a
note
to
follow
up
on
this
next
week.
I
Then,
and
we
have
the
technical
requirements
there,
but
since
since
we're
all
going
to
be
in
the
process
of
figuring
this
out
over
that
over
the
next
release
cycle,
though
that
requirements
document
for
at
least
for
the
1.11
development
cycles,
is
subject
to
change,
and
so
and
so
there's
so
if
there's
input
from
Doc's
about
you
know
how
you
would
want
to
consume
the
data
in
that
repository
to
publish
it,
you
know
those
repositories
to
publish
it.
You
know,
that's,
you
know
we're
we're
figuring
it
out,
as
we
go
along
sure.
A
G
G
H
B
H
There's
ways
to
tweak
the
bot
to
so
that
it
works
in
your
favor,
like
we
might
be
able
to
do
do
like
if
it
has
the
label
planning
on
it
or
you
know,
auto,
adjust
your
labels
or
something
like
that.
Then
the
Bob
might
pick
up
those
things,
so
I
guess
another
way
to
look
at
that
would
be.
You
know
what
are
the
common
themes
amongst
the
ones
that
are
you
have
open
right
now
that
are
older
than
that,
and
how
can
we
adjust
the
bot
so
that
it
doesn't
pick
those
up.