►
From YouTube: Kubernetes Sig Docs 20180116
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 16 January 2018.
https://github.com/kubernetes/kubernetes.github.io
A
A
Let's
do
some
follow-ups
from
the
last
meeting
so
for
the
sick,
docks
summit,
Jennifer's
suggestion
I
think,
is
a
really
good.
One
and
I
know
it's
pushing
us
out
a
little
later
into
the
year.
But
if
we,
if
we
go
any
earlier,
we
run
the
risk
of
people
not
being
able
to
attend
in
the
in
fairly
significant
number.
So
for
the
sigdoc
summit,
we're
looking
at
Portland,
Oregon,
May,
9th
and
10th,
that's
a
Wednesday
and
a
Thursday,
and
that
is
immediately
following
right.
A
A
Maybe
urban,
the
airship
someplace
that,
if
you've
been
to
a
break
the
docks
before
will
be
familiar
so
yeah.
Let's
put
a
reminder
in
your
calendars
now
for
May,
9th
and
10th
for
the
sigdoc
summit,
which
is
exciting.
This
would
be
our
first
Oh
Lord
he's
still
not
talking
about
Lex
I
mean
maybe
I'm
in
the
wrong
shake.
My.
A
G
G
Yeah
actually
I
have
it
right
here.
It's
not
like
anything
super
fancy
visually,
but
it's
the
content
is
there
for
anyone
who
needs
it.
Oh,
awesome
and
I.
Guess
the
nation
that
so
the
reason
this
works
is
all
the
content
is
in
the
community
repo.
So
we
don't
necessarily
have
to
be
the
ones
approving
those
peers
they
merge
and
then
the
content
should
update
I.
A
F
Don't
want
to
lead
it
and
I'd
like
to
have
Aaron
here
to
talk
about
it,
but
I
think
that
there
are
some
related
things
that
I
just
like
to
call
out
so
that
the
folks
who
are
on
this
call
can
maybe
also
help,
and
you
know,
take
a
look.
It's
not
just
you
know,
sort
of
LG
TM
and
approve
it's
making
sure
that
we've
got
the
right
lists
of
contributors
who
can
actually
effectively.
F
You
know
there
was
an
interesting
discussion
about
all
of
this
in
last
week's
community
meeting
about
sort
of
normalizing
across
project.
Actually,
in
that
case,
it
wasn't
so
much
of
cross
repos,
although
partly
across
repos
and
I,
think
that
this
is
a
place
where
sig
Dux
could
perhaps
usefully
borrow
a
little
more
of
the
rigor
that
ladies
kubernetes
brings
to
the
table.
We
big
guard
to
how
things
get
reviewed
and
by
whom
and
sort
of
how
things
get
merged.
F
Y'all
know
I've
brought
this
up
from
time
to
time.
I
felt
woefully
confused
about
it
at
the
start
and
at
this
point,
I
just
go
in
and
do
stuff
to
try
to
help
reduce
the
back
of
open
jars.
That
doesn't
always
feel
like
the
right
way
to
do
things
so,
and
sometimes
I'll
get
stuff
leave
something
in
a
stuck
State
and
nobody
else
knows
what
to
do
with
it,
and
so
it
stays
in
the
stuck
State
and
then
our
PR
backlog
gets
big
again.
F
A
A
C
So
I
want
to
go
on
record
as
saying
that
I'm
in
favor
of
what
Aaron
is
proposing
the
more
I
look
at
it
and
think
about
it.
The
more
I
think
it's
the
right
thing
to
do.
The
the
the
main
decision
for
us
I
think
is
to
decide
if
what
we
want
is
to
is
to
sort
of
copy.
What
they're
doing
in
kubernetes
kubernetes
we're
just
having
two
two
kinds
of
approvals:
one
is
the
/l
GTM
and
the
one
is
the
slash
approve,
and
I
think
we
should
I
think
/l.
C
Gtm
should
mean
technical
approval
and
slash
approve
should
mean
doc
approval
and
if
there
is
a
/l
GTM
as
soon
as
one
of
the
one
of
the
people
with
approvers,
you
know
when
people
who
can
serve
as
this
kind
of
a
prove
err
so
slash
approve.
We
get
automatic
merge
that
would
be
really
similar
to
the
way
the
way
they're
doing
it
and
I
come
down
on
the
side
of
you
know
consistently
getting
more
advantage
from
consistency
than
we
do
disadvantage.
C
There
was
some
discussion
in
the
community
meeting
about
how
enforcing
consistency
might
sort
of
harsh
the
you
know.
The
put
a
harsh
tone
on
the
process
of
some
other
things,
but
I
don't
feel
that
way
about
ours.
I
think
we
would.
We
would
get
much
more
positive
out
of
this
and
I
don't
see
any
any
down
side
to
it.
Yeah
Andrews
Andrew
is
already
working
on
making
these
owners
files,
and
you
know
coming
to
some
understanding
of
what
it
means
to
be
listed
as
a
certain
kind
of
person
in
one
of
these
owner
files.
C
A
Love
everything
that
you
just
said:
Steve
giant
plus
one
to
it
I,
you
know,
I
I,
don't
know
that
we
need
to
get
any
more
complicated
than
that.
I.
Think
that
addresses
all
of
our
all
of
our
real
process.
Concerns
is
just
making
sure
that
we
are
able
to
differentiate
between
tech
reviews,
tech
reviews.
H
A
A
I
I
think
that
what
happened
was
we're
talking
about
the
1.9
release
or
something
that
looked
good
in
the
release
branch
when
it
was
merged
into
master
broke,
because
there
was
sort
of
an
unclean
commit
history
complicated
commit
history
in
the
in
one
particular
PR
Steve.
It
was
that
thing
that
we
spent
like
three
or
four
hours
on
a
Friday
night,
trying
to
fix
on
one
Batman,
really
stay
yeah.
A
H
A
Fair
Jared
and
I
had
a
similar
discussion
at
the
time
and
Jared
as
usual.
You
know
came
up
with
a
zinger
of.
Are
you?
Are
you
trying
to
implement
a
process
for
one-off
behavior
and
in
this
case
I
think
we
can
solve
it?
I,
don't
I,
don't
know
that
we
need
to
solve
it
with
automation.
So
much
as
we
just
need
to
be
consistent
when
reviewing
PRS
and
say
if
we
see
a
PR
that
has
like
a
whole
bunch
of
Roberts
in
it
has
a
whole
bunch
of
free
bases.
H
A
A
A
A
B
It's
I,
guess
kind
of
just
wanted
to
to
to
hear
what
people
think
about
it.
Also
overall
tell
me
to
kind
of
try
and
read
it
out,
but
I
wrote
an
email.
I
mean
generally
it's
about
the
getting
started
guides
right.
So
there
are
great
many
getting
started,
guys
I
think
some
got
removed
over
time,
but
I
haven't
tracked
it
down.
Just
yet
I
mean
I
just
wanted
to
get
your
feedback
on
the
overall
approach.
B
Well,
we
would
like
to
we'd
like
users
to
not
find
outdated,
getting
started
guides
or
getting
started
guides
that
do
not
leave
to
the
class
the
configuration
that
that
is
supported
upstream
right,
and
you
know
over
time,
we've
merged
all
sorts
of
things
that
people
contributed
are
as
great
and
if
actually,
what
has
happened
is
that
that
bill
learned
different
pressures
of
setting
up
your
clusters
and
since
you
know,
I
mean
I,
could
give
you
an
example.
B
I
wrote,
I,
wrote
down
our
guide
back
and
he
could
deleted
quite
a
while
ago,
but
in
that
process
learned
a
whole
number
of
things
about
covering
this
and
Casa
bootstrap
and
provisioning
for
resources
that
runs
on
like
PM's
and
stuff
and
private
networks,
and
such
things,
and
you
know
since
then,
I've
worked
on
qbm
and
some
some
other
bits
and
pieces.
So
you
know
effects.
We
all
learned.
B
It's
like
yeah,
the
Viking
seems
like
now's
a
good
time
to
actually
go
and
delete
some,
some
of
the
guides
that
are
no
longer
maintained,
or
you
know,
maintained
very,
very
infrequently
or
whatever
on
so
the
the
kind
of
fair
approach
that
we
figured
out.
Well
thanks
to
Robert
and
look
as
mostly
is
that
we
could
enforce
et
compliance
or
performance
right
on
the
documentation
that
that
is
related
to
cluster
set
up
like
begin
Authority
guides,
and
they
would
help
us
to
see
through
them.
B
I
mean
well
I
guess
one
of
one
of
the
questions
is
like
whether
we
really
should
try
to
to
dump
them
into
some
repository
and
have
redirect
saying
like
this
guys
have
been
deleted.
But
if
you
really
have
to
find
out
what
used
to
be
on
this
page,
go
to
this
git
repository
write,
something
like
that
or
or
we
don't
care.
We
just
want
to
redirect
them
to
a
page
where,
where
they
can
find
it
and
the
Maurice
is
a
guy
didn't
wanted
to
start
discussion
and
sick
Docs
is
like
building
legacy
class
lifecycle.
A
Ya
kidding
getting
rid
of
the
gate
getting
started.
Guides
has
been
like
one
of
those
one
of
those
lamps
that
I
rub
saying.
I
wish
I
wish
so
yeah
anything
that
we
can
do
to
make
sure
to
reduce
stale
documentation
to
to
remove
it
and
to
make
sure
the
documentation
that
all
discoverable
documentation
on
the
kubernetes
website
is
current
and
relevant
is
anything
that
we
can
do
to
move
towards.
A
C
B
I
mean
I,
guess
one
easy
way
to
do,
that
is
to
run
to
a
sauna
by
your
cluster
and
that
they
would
give
you
indication
of
where
that
passes
the
pair's
or
you
know
if
it
doesn't
pass
them.
You
figure
figure
out
what
is
going
on.
You
know
it
is
it
isn't
something
that
is
particularly
easy,
but
you
know
kind
of
how
do
you
tell
that
whatever
they
end
up
with
after
following
a
certain
page
in
the
docs
he's
going
to
he's
good
mm,
you
know
he
would
cluster
that
that
it's
just
like
someone
else's.
C
B
It
needs
to
you
know:
you
have
the
e
to
e
tests
and
cubes
test
utility
and
and
that's
like
something
that
we
run
on
CR
NCI,
for
you
know
a
few.
Therefore,
if,
if
you
kind
of
configuration-
and
we
pretty
much
every
change
where
Romney
GE
tests
and
the
ete
tests
is
what
cnc
of
conformance
with
is
based
on
it's
just
it's
kind
of
a
subset
of
into
e
test
from
it's
like
okay,
it
is,
it
consists
of
a
key
tests
that
are
tagged
with
conformance
tag
right,
so
yeah.
B
So
so
you
have
to
build
this
sort
of
user-friendly.
Let's
do
that
you
don't
because
like
if
you
were
to
look
at
cube
test,
then
you
know
there
isn't
an
obvious
way
of
how
to
you
bomb
cube
test
which,
which
is
something
that
which
is
a
eight
month
and
that
lis
program
that
leaves
in
testing
for
a
reaper.
B
C
I'm,
just
I'm
just
wondering
what
are
some
of
the
typical
things
if
you
look
at
one
of
these
guides
now
that
that
fails
conformance,
what
are
some
of
the
typical
things
that
the
cluster
fails
to
do
or
are
these
things
like
you
know,
the
API
server
refuses
to
answer
the
network
is,
is
determined
to
be
insecure.
What
are
the
things
that
that
the
cluster
is
failing
to
do?
Yeah.
B
Some
some
particular
features
don't
work
exactly
as
as
they
should
get
out
of
some
like
I,
don't
know,
yeah
something
to
do
with
networking
or
or
like
and
gain
some
toleration.
Zand
sort
of
such
things
right
on
the
there
is
very
different
kind
of
features
that
that
we
have
on
current.
Is
that
better
under
conformance
subset,
and
is
anyone
else
familiar
with
this
stuff
here
on?
The
call
I
could
try
to
describe
it
somewhat
differently,
because
you
know
we'd
like
to
be
totally
honest
with
you.
It's
can
be
pretty
obscure.
E
So
when
things
break
it's
usually
due
to
some
implementation
detail,
that's
outside
of
the
normal
realm
of
cloud
deployments,
so
usually
I
would
look
at
things
and
the
cupola
config
or
the
networking
config,
that's
in
the
underlay
or,
if
there's
some
sort
of
weird
proxy
or
stuff
like
that,
so
things.
Basically,
it's
the
it's.
The
more
deviation
you
have
in
terms
of
implementation
details,
the
the
less
likely
you
are
to
pass.
That's
good
form
its
test.
A
So
maybe
a
more
targeted
question
is
when
a
getting
started
guide
produces
a
non
non
conformance
State
who
opens
the
PR
and
how
does
the?
How,
where
where's
the
the
chain
of
notification
between
oh,
this
guide
is
no
longer
no
longer
produces
a
conformant
result.
A
PR
opens,
someone
opens
it.
Who
opens
that
PR
to
remove
that
documentation
and
we're
I?
Guess
where
is
the?
Where
are
the
results
of
conformance
testing
posting
that
that
a
a
PR
can
be
opened?
E
It's
like
it's
an
azure
thing,
obviously
sig
a
sure
or
say
GCP
or
whatever,
and
if
it's
not
somebody
specific,
maybe
there's
a
working
group
area
cloud
provider,
brother
and
just
throw
it
up
there
and
then
put
something
in
the
actual
getting
standard
guide
itself.
You
know
a
notation
that
this.
This
does
not
currently
pass
that
conforms
judgment.
So
it's.
A
Physically
have
two
pieces
of
work
to
do
here.
One
is
to
handle
legacy
material
and
another
piece
is
to
handle
how
how
we
gauge
that
conformity
or
conformance
going
forward
so
for
I
mean
Steven.
That's
a
perfectly
reasonable
requirement
to
Institute
I
think
for
a
getting
started
guide
for
for
new
material
introduced
into
a
release,
but
we've
still
got
to
work
the
way
our
way
through
legacy
material.
So.
B
Yeah
I've
not
looked
at
the
things
that
I
think's
as
this
thing
right
now,
but
for
memory
there
were
guards
which
say:
well,
here's
how
you
run
kubernetes
on
Ubuntu,
on
VirtualBox
and
from
the
title
you
know
you
just
get
like
seems
like
running
into
an
Ubuntu
is
the
end
goal.
So
in
that
case
we
could
just
say:
here's
how
you
install
converting
is
on
Ubuntu,
independent,
full
sort
of
virtualization,
saying
you
use
and
here's
here's
your
open
to
package,
and
here
the
ADM
commands
and
read
more
about
humidity
and
over
here.
B
A
C
B
That's
okay,
so
on
yeah
sure
I
mean
I
was
I
was
going
to
go
and
look
at
them
and
sort
of
I
mean
I
was
going
to
drag
down
the
the
obvious
things
right.
So
whether
people
refer
to
like
one
one,
five
or
whatever
already
and
where,
where
they're
afraid
to
and
something
that
that
is
obviously
I
have
to
take.
And
you
know
just
look
at
the
commute
log
on
such
things
and
Trust
around
the
most
active
contributors
in
that
subdirectory
answer.
B
Do
that's
sort
of
stuff
first
and
then,
and
then
see
also
how
the
winds
would
react
to
this
and
then
listing
out
I
guess
it
would
be
you'll,
be
quite
challenging
to
run
through
all
the
guides,
but
it'd
probably
be
you
know
easy
I
can
reach
out
to
to
owners
and
see
where
whether
they
still
care
to
maintain
those
and
and
ask
them
to
consider
going
through
conformance
and
if
they
face
any
difficulties.
Doing
that
I
mean
this
kind
of
thing.
I
was
thinking
on,
but.
C
B
B
A
All
right,
let's
move
on
to
better
review
habits,
so
I,
open,
I,
put
this
I
put
this
on
the
agenda,
because
I'm
noticing
I'm
starting
to
notice
some
bad
review
habits
across
cig
docks
and
it's
it's
not
evenly
distributed.
There
are
folks
who
do
wonderful,
PR
reviews
all
the
time,
and
if
your
concerns
that
that
that
isn't
you-
it's
probably
you
so.
A
Everyone,
I
think,
is
doing
a
really
good
work
with
reviews,
but
I
do
think
that
we
need
some
more
consistent
good
habits
in
the
repo
I
am
noticing
a
tendency
to
for
folks
to
merge
their
own
PRS
and
without
a
clear
chain
of
review.
I
am
guilty
of
this
too.
It's
it's
gross,
it's
it's
kind
of
unclean
and
we
need
to
get
out
of
this
habit.
A
A
Static
branches
or
anything
branches
that
are
earlier
than
the
current
release,
those
are
considered
snapshots
in
time.
We
don't
accept
PRS,
open
against
content
for
anything
earlier
than
1.9.
So
if
something
needs
to
change,
make
sure
that
it's
changed
in
the
current
version.
Otherwise
branches
are
considered
historic
snapshots
they're,
not
we're
not
accepting
content.
Few
hours
against
older
branches.
A
You
know,
I
know
that
we
have
a
large
a
large
backlog,
and
then
we
have
a
large
throughput
of
documentation,
PRS
but
I'm.
Seeing
a
lot
of
things
like
go
through
with
mechanical
errors,
things
that
are
going
through
that
aren't
consistent
with,
like
with
good
quality
things
that
could
be
better
and
not
even
like
a
real
stress
to
be
better.
So
I
want
to
ask
that
we
take
more
effort
to
make
sure
that
the
pros
that
we're
passing
is
as
clear
and
as
helpful
as
it
can
be,
and
we
are.
A
A
A
C
Exact
when
you're,
when
you're,
ready,
I'm
gonna
chime
in
here
yeah,
that's
all
I
have
cocoa
Boise,
okay,
so
part
of
what's
happened
here
is
that
we've
been
in
this.
You
know
one
to
two
years
of
just
having
this
process
evolve
and
trying
to
dig
me
out
of
a
big
hole
and
so
I
think
it
made
sense
for
a
while
to
just
move
as
quickly
as
possible.
Even
if
that
meant
skimping
on
some
process
and
on
some
you
know,
quality
with
things
matching
the
style
guide.
C
C
You
know,
new
proposals
are
having
the
the
bot
merge,
based
on
LG,
TM
and
approved,
and
having
clear
definitions
of
what
LG,
TM
and
approved
means,
but
here's
the
place
where
I
think
we
have
to
be
careful
if
there's
a
concept
piece.
That's
about
you
know,
six
pages
long
and,
and
an
engineer
makes
a
small
technical
addition
to
that
page
to
make
it
a
to
date
with
the
new
release.
C
I
don't
feel
like
that's
always
that
that's
not
the
time
to
go
through
and
make
that
sure
that
entire
document
conforms
to
our
style
guide,
that
that
would
take
the
thing
way
off
the
track
of
what
that
that
engineer
was
trying
to
just
you
know,
just
get
that
thing
done,
and
it
would
add
more
time
than
we
often
have
to
the
process.
So,
as
we
write
up
our
guidelines,
what
does
it
mean?
C
If
you
say
slash,
approve
I,
think
we
need
a
document
that
clarifies
that
for
us
and
that
sometimes
what
it
means
is
that
you're
gonna
bring
the
whole
document
into
alignment
with
the
style
guide
other
times
it
doesn't
for
the
for
these
reasons
that
sometimes
we
just
have
to
be
pragmatic.
When
there's
a
small
change
in
an
older
large
document.
F
A
D
C
Makes
sense
to
me-
and
we
do
have
some
some
kind
of
overarching
issues
that
that
I
wrote
a
while
back
and
they
say
things
like
this,
this
body
of
conceptual
content
about
you
know
a
certain
thing
needs
to
be
looked
at
and
we
need
to
decide
what
goes
in
concept
pieces.
What
goes
in
tasks
pieces
and
we
need
to
do
an
edit
pass
for
style
on
on
all
the
topics,
and
some
of
those
issues
are
already
there.
F
Partly
I
think
to
address
Stephen
augustus,
his
comment
and
partly
just
say,
and
then
to
what
Steve
said.
I've
been
struggling
with
this
true
and
what
I've
done
recently
is
not
always
to
file
issues.
I
actually
have
a
sticky
note
on
my
laptop
with
that
I
titled
new
list
of
communities,
topics
in
need
of
Health
and
when
I
merged,
something
that
clearly
has
a
bit
of
a
conceptual
a
bit
of
technical
update,
exactly
the
scenario
that
Steve
just
provided
but
we're.
F
So
that's
clearly
not
an
extensible
model,
but
in
some
cases
it's
clearly
not
particularly
helpful
to
provide
edits
to
write.
There's
I
mean
there's
two
ways
to
deal
with
this.
Fundamentally,
you
can
provide
a
whole
lot
of
copy
editing
in
comments
which
is
cumbersome
but
is
useful
because
you're
helping
and
you
know
a
contributor
to
the
docs,
more
style
and.
F
Sometimes
it
feels
like
there's
enough
of
a
backlog
of
PRS
and
there's
enough
work
to
be
done
on
the
topic
and
the
PR
author
is
clearly
just
struggling
to
get
a
bit
in
that
I'm,
not
convinced
that's
the
most
useful
approach,
all
right,
I
mean
I,
think
that's
always
gonna,
be
a
judgment.
Call
on
the
part
of
those
of
us
who
obsess
about
words
but
I
thought
I.
Put
it
out
there
as
a
thing
that
is
worth
reminding
ourselves.
Yeah.
A
Yeah
I
agree
with
both
of
you,
Steve
and
Jennifer
that
when
doing
it,
when
reviewing
a
change
to
a
PR,
it's
good
to
confine
a
review
to
the
scope
of
the
changes
in
the
PR.
It's
it
would
be
very
easy
and
I
think
it
would
be
a
deterrent
to
contribution
if
we
turned
every
PR
into
an
occasion
to
under
to
like
to
address
editorial
debt,
let's
call
it
in
in
every
file.
A
That's
changed
so
I
think
to
to
both
of
your
point
that
yes,
confine
the
scope
of
a
review
to
the
PR
in
question
or
to
the
change
in
question,
but
then
opening
us
opening
a
separate
issue
for
editorial
need
and
I
like
Elia
you're,
suggesting
of
tracking
editorial
debt
in
a
separate
github
project.
I
think
that
works
really
well
just
the
ability
to
like
look
in
a
single
project
and
say:
okay,
here's
a
list
of.
C
I
think
the
place
to
do
that
is
in
this
project.
We
already
have.
We
might
repurpose
this
project
it.
We
have
this
project
that
kind
of
collects
the
things
that
are
left
over
from
the
doc
migration,
but
I
think
the
doc
migration
is
so
far
in
the
past.
Now
that
we're
not
even
thinking
along
those
lines,
but
maybe
we'll
we'll
take
the
things
that
are
already
in
that
project
rename
the
project
to
indicate
this
is
about
editorial
debt,
and
we
can
add
to
that
project
as
we
come
across
things.
C
F
C
A
Right,
thank
you.
Okay,
yeah.
It's
just
to
affirm
what
everyone
has
said
it
has.
It
has
been
a
giant
crush
of
content
for
the
past
for
the
past
year
or
two
and
I
think
that
it's
been
tremendously
valuable.
The
work
that
everyone
has
done
to
get
content
current
and
to
get
our
backlog
reduced
to
the
point
that
it's
at
has
been
a
giant,
labor
and
and
greatly
appreciated.
But
I
do
think
that
it's
that
we're
at
the
time
where
we
need
to
start
focusing
more
on
the
quality
of
content.
A
C
F
A
I
am
internalizing
them
internalizing
that
what
is
new
the
changes?
Yes,
the
the
new
changes
will
be
glorious,
excellent,
okay,
any
any
other
discussion
about
better
review
habits,
all
right,
I'm.
Looking
at
we
have
a
couple
of
items
left
Jennifer
I
had
asked
if
you
wanted
to
do
a
user
journey
update
but
Andrews
out
today
and
then
I,
don't
know
that
we
can
really
do
justice
to
user
journeys
in
like
ten
minutes.
So
do
you
want
to
skip
user
journeys
today?
If
we're
there
for
a
week
and
talk
about
the
the
writing
mentorship
proposal.
Sure.
F
Probably
better,
if
Andrew
can
speak
to
that
anyway,
but
for
anybody
who's
interested.
This
is
not
that
late,
I'm
sticking
a
URL
in
in
chat.
That's
not
the
absolute
latest
state
of
it,
but
for
those
of
you
not
familiar
that'll,
give
you
an
idea
of
what
we're
trying
to
do
without
context.
That
might
not
be
very
much
so
if
it
confuses
you
and
you
want
to
know
more
come
back
next
week,.
F
F
It's
a
more
elegant
way,
referring
to
getting
sig
Docs
representation
on
the
more
code
for
e
nted
SIG's,
specifically
with
an
eye
to
helping
folks
write,
better
release.
Note
copy
in
support
of
the
release
process.
Although
I
know
Nick
has
some
more
ideas
for
making
that
better,
but
better
copy
out
of
the
gate
would
help
a
lot
and,
where
appropriate,
helping
folks
with
dot
content
as
well,
most
likely
on
a
per
release
basis.
F
Although
there's
kind
of
some
nice
timing
here
with
Ilias
proposal
for
the
sig
cluster
lifecycle,
this
is
another
place
where
you
know
we're
working
cooperatively
but
I'm
thinking,
primarily
in
terms
of
how
we
can
help
folks
through
the
release
cycle
and
so
I
guess
what
we
need-
and
we
probably
don't
again
have
enough
time
to
get
through
this.
But
we
need
a
couple
of
things.
We
need
to
identify
key
cigs
and
we
need
volunteers.
F
F
Sig
apps
is
another
one
where
I
think
we
could
really
use.
You
know
we.
We
tend
to
get
big
chunks
of
PRS
coming
in
per
release
there
and
I'm
doing
this
off
the
top
of
my
head.
So
I
don't
have
a
formal
list.
Anybody
else
wants
to
contribute
to
the
list
of
things
that
we
think
are
high
priority
to
farm
ourselves.
Out
to
please
do
so.
A
I
Sounds
good
I
actually
have
a
separate
mentoring.
Update
andrew
is
going
to
do
a
small,
very
small
workshop,
like
15
to
20
minutes
with
the
mentoring
test,
cohort
that
we're
running
right
now
again
for
the
people
that
are
going
from
member
to
reviewers
in
cube,
ADM
cops
and
workload
API,
and
that's
going
to
be
just
a
what
you
guys
and
gals
would
be
looking
for
as
far
as
in
a
qualities
of
a
tech
reviewer
and
how
to
be
one
more
of
a
sign
of
why
etc.
So
listen.
Thank
you.