►
From YouTube: Kubernetes Sig Docs 20171003
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 03 October 2017.
https://github.com/kubernetes/kubernetes.github.io
A
Oh,
hello,
everyone-
this
is
the
weekly
sig
Docs
meeting
for
kubernetes
today
is
October
3rd,
2017
and
I
hope
you're
all
having
a
wonderful
week.
I
know
that
my
wake
is
better
because
1.8
released
last
week,
yay
many
thanks
to
Steve
Perry
and
to
Jay
singer
Dumars,
who
helped
wrangle
Doc's
from
contributors
and
get
them
all
out
the
door,
and
many
thanks
also
to
Jennifer
Rondo
and
Radhika,
who
wrangled
the
release
notes.
A
D
Sure
so
we
basically
learned
from
prior
retros
that
an
hour
is
just
never
long
enough,
so
we're
co-opting
the
community
meeting
for
the
first
hour
and
then
doing
another
hour
on
Friday
to
make
sure
we've
got
enough
space.
We
don't
use
it
then
great,
but
I
have
a
pretty
strong
inclination
that
this
is
gonna,
be
a
very
busy
retro.
Based
on
what
happens.
I
suspect
you
are
correct,
so.
A
E
Well,
I'm
not
planning
on
offering
all
of
that
content
to
the
retrospective.
It's
pretty
substantial
it'll
be
more
like
talking
points.
You
know
the
retrospective
write-up
itself
is
much
more
succinct
and
so
I,
but
I
was
hoping
you
know.
Maybe
folks
can
provide
feedback
in
the
dock
on
the
two
things
that
I
highlight,
and
maybe
what
I
need
to
do
is
simply
flip
the
order,
because
Caleb
seems
to
have
misunderstood
what
I
was
pushing
on
in
his
comments.
Are
automation
and
better
release?
No
guidance.
E
I
see
those
things
as
two
halves
of
the
same
coin,
not
as
prioritized
one
over
the
other
I
do
think
that
Dawn's
proposal,
which
I've
also
linked
to
from
the
doc,
really
outlines
the
larger
approach
to
improving
the
release.
E
Note
process:
it's
not
just
about
a
better
template,
it's
not
just
about
editors
or
you
know
what
have
you
and
so
you
know,
given
that
that's
already
been
proposed
and
partly
implemented,
I
thought
it
only
appropriate
to
call
out
the
work
that
people
had
already
done
to
try
to
improve
the
process
and
then
add
what
I
think
writers
can
provide
with
help.
In
my
experience,
which
is
fairly
substantial
at
the
enterprise
level,
with
this
kind
of
thing,
it's
not
realistic
to
get
final
release.
E
Note
content
in
a
feature
write-up
or
an
issue,
or
a
full
request.
There's
going
to
be
a
human
intervention
at
the
end,
I've
never
seen
it
work.
Otherwise,
if
we
can
get
to
the
point
where
we
don't
need
that
great,
but
the
other
thing
I
try
to
do
in
this
doc,
but
I
just
like
to
call
out,
is
I
tried
to
put
pieces
of
things
in
there
so
that
we
can
implement
in
iterative
fashion
because
we're
not
gonna
get
all
of
this
in
place
for
the
next
release.
Excellent.
Thank.
A
You
for
putting
all
of
this
together
in
a
sort
of
a
neatly
browsable
format.
So
yes,
I
highly
recommend
that
everyone
get
take
some
time
to
look
over
this.
The
content
is
good
and
very
thoughtful
and
also
Jennifer
is
asking
for
feedback
on
it.
So
if
you
are,
if
you
look
at
it
and
you
can
think
of
ways
to
help
improve
our
collective
process
for
releases
going
forward,
this
is
an
excellent
chance
to
provide
feedback
specifically
on
the
release,
notes
and.
E
Especially
anybody
who's
worked
on
this
kind
of
content
for
similar
or
dissimilar
projects.
You
know,
hearing
about
your
experience
would
be
really
appreciated.
Awesome.
We.
F
F
E
G
E
F
D
D
Zack
is
there
any
anything
else
that
you
need
me
around
for
or
do
you
mind
if
I,
if
I
split.
F
D
A
F
Yeah
I
can
do
that.
My
the
docs
print
updates
I
have
it's
more
just
with
a
a
ping
for
ideas
and
people.
If
people
have
great
ideas,
welcome
to
shut
them
out
otherwise
chillness
or
sit
on
them
and
stir
bits,
we're
not
negated
rush.
Basically,
we've
been
approved
to
give
a
docs
prints
to
host
the
docs
prints
at
kook
on
Tuesday
December
5th,
from
1
to
5.
So
we
have
a
half
day.
F
F
F
There
is
a
cost
of
renting
the
room
which
I'm
gonna
see
obscene
yeah,
we'll
pick
that
up
it's,
it's
not
substantial.
It's
like
2,000
bucks,
so
I'm
gonna
work
with
them
on
that.
If
there's
any
ideas
for
themes
for
like
a
like
a
project
that
we
can
put
forth,
that's
people
in
who
are
attending
the
docs
print
can
work
on
I
am
all
years.
So
we
do
have
you
know
two
months
to
brainstorm
this
and
figure
this
out.
F
I
know
a
lot
of
people
here
have
run
doc
sprints
before
so,
Radhika's
run
them
Andrew
and
I
have
done
them
before
in
you
know,
Jennifer
you
participated
in
many.
So
like
there's
a
lot
of
experience
here,
I
think
what
we
need
is
a
good
project
idea
that
we
can
put
out
there
for
folks
to
work
on
so
people
have
ideas.
Great.
A
F
G
F
Yeah
the
write
the
document
was
intentionally
simple
because
the
sort
of
on-ramp
to
kubernetes
is
pretty
steep,
but
the
folks
in
this
audience
will
be
should
be
fairly
technical.
We
could
do
something,
that's
sort
of
a
notch
up
on
the
technical
ladder.
I
think
it's
you
know.
Ideally,
whatever
project
we
have
would
have
say
30
to
40
issues
related
to
it,
but
look
at
that.
F
G
That's
that's
the
best.
If
you
wanted
something
simple
I
was
gonna
say
we
we
have
the
glossary
going
out
soon,
but
we
could
obviously
use
a
lot
more
terms.
We're
just
gonna
go
out
with
like
a
minimal
set.
So
if
you
wanted
something
well
or
we
could
have
different
complexity
levels
for
people,
but
the
lower
one
would
be
like
people
could
work
on.
You
know
the
definitions
for
key
terms,
and
then
you
know
that'd
be
pretty
easy
to
submit
and
they
would
pop
up
on
the
glossary.
F
Why
don't
we
won't?
We
see
we're
at
like
in
like
a
couple
weeks
on
planning
that,
and
that
might
be
a
good
one
and
if
that's
not
big
enough,
we
might
tack
on
another
project.
That's
more
technical
watch
to
work
on
there
gonna
be
a
lot
of
new
people
who
are
just
interested
in
kubernetes
who
are
gonna,
be
there
and
there's
gonna
be
a
lot
of
more
experienced
folks.
So
yep,
look
I,
see
I,
see
a
lot
of
people
chipping
in
with
ideas.
A
F
Be
great,
we
are
gonna,
be
coming
up
on
the
1.9
release
when
that's
when
we
get
closer
to
that
dates,
bukhan
is
like
I
I
think
it's
pretty
close
to
the
1.9
release,
so
just
something
to
keep
in
mind
if
there
is
like
release,
notes
stuff
that
you
want
to
work
on,
or
things
like
that
also
there's
just
folks
in
this
room
that
want
to
hang
out
and
chat
and
brainstorm
ideas.
It's
always
nice
to
be
in
person
as
wonderful
as
your
virtual
appearances
are.
F
It's
always
nice
to
sort
of
have
that,
like
in
3d
interaction.
So
that's
all
I
got
I'll.
Do
a
quick
little
write-up
like
what
we
are
very,
very
general,
what
we
want
to
do
and
and
submit
that,
so
there
can
be
like
a
little
blurb
in
the
in
the
keuken
packet
about
what
we're
done.
I
just
put
the
shell.
Oh
definitely
erotica!
I
would
love
to
do
a
usability
test
there.
Well,
we
have
folks
in
the
room,
are
interested
in
us
ooh.
A
Usability
testing,
yes,
that
would
be
lovely
mm-hmm
I
opened
a
shell
of
an
issue
for
tracking
put
the
link
to
put
the
link
in
zoom
chat
and
put
it
in
the
meeting
notes
for
the
docs.
So
if
you
have
ideas
for
the
cube
conference
or
if
you
just
want
to
register
your
interest,
leave
a
note
or
leave
a
comment
on
the
issue
and
we
can
start
tracking
things
from
there
anything
more
on
cube.
Con
air
ducts
prints,
tread.
F
Nope,
that's
all
I
got
I,
do
have
a
I'll
be
running
a
very
much
smaller
docs
prints
at
the
Reg
denoxin
one-day
event
in
Melbourne
on
November
25th,
so
I
might
do
a
much
smaller
set
of
issues
there.
That's
gonna
be
a
half-day
event,
but
it's
gonna
be
people
who
are
fairly
you
both
to
get
hub
and
to
kubernetes
Andrew
I
might
brainstorm
with
you
about
that
sort
of
offline,
but
I'll.
Let
folks
know
okay
and
there
was
a
I
feel
terrible
saying
this.
F
There
was
a
person
from
Red
Hat
who
was
here
at
the
last
meeting
and
he
voiced
his
interests
in
helping
out
with
that
he's
from
Melbourne
I'm.
Sorry
he's
from
Australia
he's
losing
Brisbane
and
I
totally
forget
his
name.
He
sent
a
chat
to
me
that
he
was
interested
but
I
lost
it
to
folks.
Remember
who
that
was
yes,.
H
F
F
I
On
the
docs
print,
instead
of
using
spreadsheets,
let's,
let's
do
what
we
did
for
for
leftover
projects
from
the
migrant
leftover
work
items
from
the
migration,
which
is
to
create
a
github
project
that
serves
as
a
collection
issues.
We
could
do
one
of
those
for
the
November
another
one
for
the
December
sprint
that.
A
I
There
there
were
several
reasons
for
that.
One
is
that
when
people
copy
and
paste
they
get
the
dollar
sign
along
with
what
they've
copied
and
pasted
in
and
then
that
causes
problems
another
is.
We
were
trying
to
be
consistent
with
the
style
that
we
use
in
the
Google
cloud
Docs.
There
were
probably
other
reasons,
but
you
know
it
was
fairly
well
discussed,
I,
don't
know
within
the
last
year
and
a
half,
and
you
know
that
was
the
consensus
at
the
time.
A
A
J
I
interject
well
I,
guess:
Nick
is
also
speaking,
but
I
think
it's
possible
to
get
the
best
of
both
worlds.
If
you
were
following
this
exact
channel,
misty
I
think
she's
from
talker
she
proposed
using
CSS
and
formatting.
H
J
K
I'm
gonna,
second,
that
I
think
it's
definitely
important
to
make
the
readability
paramount,
because,
while
it's
great
to
be
able
to
copy
and
paste
a
primary
purpose
of
the
docs
at
least
I
would
think
so
is
to
help
people
to
understand
what's
actually
going
on.
And
if
you
can't
tell
what's
going
on
it's
it's
not
as
useful.
In
my
view,
that's
my
personal
opinion
but
I'm
the
new
guy
here.
So
thank.
K
G
Well
also,
is
there
a
way
to
add
the
function
I,
so
you
have
the
copy/paste
button,
so
that
will
only
copy
the
command
itself,
because
right
now
I
mean
that
that
issue.
You
know
the
copy/paste
issues,
because,
like
they're
manually
copying
and
pasting
it,
whereas
if
we
had
the
button
kind
of
like
the
way
the
gamma
was
you
know,
then
they
wouldn't
have
to
worry
about
them.
This
early
copying
the
prompt
and
output,
along
with
the
command.
I
A
J
I
I
could
probably
do
it
if
I
set
aside
a
day,
I
just
haven't,
haven't
done
it
yet
and
I
also
don't
know
if,
like
misty,
wants
to
take
point
on
it,
because
if
she's
excited
about
it
and
like
wants
to
start
contributing
to
sig
Docs,
that
might
be
a
good
way
or
like
a
good
starter
project,
but,
like
I
think,
like
it'll
be
easier
to
make
a
decision
on
this.
If
there
is
a
working
prototype
that
everyone
can
look
at
and
be
like.
Oh
that
makes
sense.
That's
intuitive!
J
A
Would
be
awesome,
I
I'd
love
to
see
a
prototype
of
of
what
that
could
actually
look
like
in
our
documentation.
It's
I
mean
this
is
where
the
discussion
right
now
is
kind
of
abstract.
If
we
have
something
on
create
that
that
we
can
look
at
and
compare
functionality
with,
that
would
be
really
helpful.
Okay,
go
ahead,
I'll.
J
I
Deadline,
one
week
from
today,
so
what
I'd
suggest
is
that
in
the
prototypes
we
we
show
how
we're
going
to
show
both
the
command
and
the
output
of
the
command
and
explain
the
output
of
the
command.
Because,
right
now
the
style
is,
you
say,
you
know,
create
the
pod
and
you
show
the
command.
Then
you
say
something
about
the
output.
The
output
shows
that
you
know
it's.
You
created
a
pod
with
two
containers
and
then
you
show
the
output.
I
Know,
cuz,
that's
quite
different
from
showing
the
command
and
the
output
all
in
one
block
and
saying
something
about
it
up
front
or
or
after
the
whole
thing,
but
not
saying
something
in
between
showing
the
command
and
showing
the
output
right.
Now,
that's
our
style,
as
you
say,
something
in
between
those
two
things
right,
I.
A
A
G
E
Sure
I
left
it
off
the
they're
on
release.
Note
retrospective
content,
because
that
kind
of
had
two
audiences
one
of
them
was
this
group,
and
one
of
them
was
the
larger
release
group,
which
I
think
we
don't
need
to
worry
about
them.
For
this
one
I
mean,
if
I'm
wrong
about
that.
I
can
take
it
up
there
too,
but
yeah
I
think
it
would
be
good
to
talk
about.
E
What
change
log
got
MD,
which
I
think
yeah
I
had
time
to
go
back
and
look
we're
1.8?
We
were
supposed
to
have
implemented
a
single
change
log
for
the
Curtin
release
and
breakout
I
think
the
idea
was
just
to
break
out
everything
else
for
previous
releases
and
then
going
forward
have
single
change
logs
for
each
subsequent
release,
but
from
what
I
see
of
the
PRS
like
I
said,
I
haven't
even
gone
in
and
looked
at
the
implementation
that
hasn't
happened
yet,
but.
G
E
G
I
Let's,
let's
talk
about
the
formatting
for
a
minute
because
the
as
I
understand
it,
the
fear
was
that
we
wouldn't
get
nice
formatting
we'd
get
the
formatting
like
we
saw
a
say
in
the
1.7
release
notes,
but
we
didn't.
We
got
formatting,
that's
more
like
what
we
would
see
in
our
own
box.
It's
just
it
happens
to
be
in
changelog,
got
MD
so
Jennifer.
Do
you
see
it
that
way?
Or
do
you
see
it
that
we
got
formatting,
that's
much
less
interesting
than
what
we
want.
I
E
E
That
I
think
that
include
the
nicer
I
want
to
define
nicer,
looking
there's
no
decent
navigation
in
that
default.
Github
repo
view
and
given
how
complex
a
kubernetes
release
is,
it
seems
to
me
that
that
alone
is
worth
better
presentation,
just
making
it
possible.
Now
this
might
mean
that
going
forward,
we,
we
think
you
know,
sort
of
the
strings
that
we
use
for
headings
and
so
forth
to
provide
a
decent
TOC,
but
I
think
that
breaking
it
up
and
making
it
were
navigable
would
contribute
significantly
would
contribute.
G
Also
like,
if
it
were
in
one
of
our
templates
like
in
our
site,
then
it
would
be
more
part
of
our
site
and
not
just
a
like
a
link
out.
You
know,
but
then
that
would
require
maybe
a
little
bit
automation
where
we
you
know
know
during
the
builds
we
pull
in
the
fat
file
and
then
we
include
it
in
a
you
know:
it's
some
templated
file
that
could
you
then
help
Auto
generate
the
TOC
and
whatnot
right.
E
The
other
thing
that
occurs
to
me
and
I'll
take
one
minute
to
chase
a
shiny
thing
and
then
stop
on,
but
conceivably
being
able
to
review
it
better
in
context
with
the
rest
of
the
docs
would
help
us
port
actual
documentation
for
subsequent
releases
when
things
move
out
of
release
mode.
That's
a
that's
a
kind
of
doc
testing,
Holy
Grail
I,
keep
working
on
on
as
a
side
project
and
haven't
gotten
very
far
on
just
not
admit.
Call
it
out
it's
more
about
thinking
about
the
content,
it's
less
about
where
the
content
actually
lives.
E
M
So
my
idea
was
so
usually
if
you
look
at
any
product,
you
see
like
release,
notes
is
published
along
with
documentation.
Some
time
you
see
the
download
link
button
release
notes.
So
my
idea
was
have
the
release
notes
on
the
documentation
side,
and
you
know
users
can,
you
know
easily
read
through
rather
than
looking
at
the
long
changelog
dot
MD
where,
like
you,
see,
download
links
and
random
tables,
and
then
you,
you
know
you
scroll
down
and
down
and
to
see
where
exactly
the
release
notes
are.
A
M
M
Publish
it
on
the
documentation
site
or
there
any
better
mechanism
to
do
that,
because
two
writers
have
span
day
and
night
and
clicked
right
the
night
right
day
before
the
release
we
have
spent
even
night,
so
you
know
visiting
and
revisiting
editing
lots
of
time
venting
so
I
didn't
know
that
it
is
going
as
a
change
look
empty.
My
eye
I
saw
a
link
with.
F
F
F
F
N
Has
been
my
position
looking
at
the
release,
notes
that
are
generally
attached
to
a
poor,
requester
issue,
they're
generally,
not
written
from
considering
any
persona
they're,
not
generally
written
with
a
user
or
developer
focus
in
mind,
usually
incredibly
technical
and
needs
usually
need
rework
by
a
technical
writer
or
as
some
rounds
of
review
with
the
contributor
of
that
release.
Note,
which
often
will,
just
if
for
lack
of
them,
will
fall
onto
the
sig
lead,
which
is
not
great
because
they
might
not
have
enough
context
on
that
particular
thing.
That's
being
documented!
N
F
F
Yeah
I
didn't
interrupt
dear
Annika
I,
just
like
I
felt,
like
we
were
getting
into
a
tooling
conversation,
but
I
feel
like
the
quality
of
content.
Conversation
I,
don't
know
if
we
were
pulling
that
in
as
well,
because
I
see
that
I
see
attention
in
both
when
it
comes
to
the
release.
Note
it's
like
we're.
Automating
bad
content,
which
didn't
like
leads
to
a
lot
of
work
for
us
and.
E
N
7,
oh
sorry,
I
didn't
find
me
Radek
1
7
was
the
first
time
we
did
not
pull
the
automated
automatically-generated
release
notes
and
we
relied
primarily
on
the
6
to
highlight
their
own
features.
So
this
was
new
for
1/8.
Sorry,
where
we
didn't
actually
use
the
screen.
The
rel
note
script
to
scrape
all
this
information
down.
E
My
understanding
was
also
the
first
release
where
you
had
any
dedicated
writers,
let
alone
two
of
us.
Yes,
so
we've
got
a
bunch
of
different
variables
here
and
I
guess
you
know
trying
to
toss
them
all
in
an
equal
weight
is
well
I'd,
rather
not,
which
is
one
of
the
reasons
why
I
try
to
modularize
my
write
up
and
I
guess
that
until
we
have
some
data
about
how
involving
writers
at
different
stages
of
the
product
can
work,
it
might
be
useful
to
draw
from
experiences
with
other
projects
that
have
involved
writers
actually.
F
I
Think
Jase
has
a
really
firm
idea
in
his
mind
of
what
the
value
is
of
these
release
notes.
So
this
conversation,
let's
get
his
thoughts
because
I
know
he
was.
He
felt
very
strongly
that
these
needed
to
be
correct
for
people
who
were
you
know,
had
a
big
cluster
going
and
needed
to
understand
what
it
would
name
to
upgrade
to
kubernetes
1.8.
Oh
yeah,.
E
F
G
F
F
I
Looks
to
me
like
the
problem
of
where
do
we
get
the
content
is,
has
been
solved.
I
think
the
way
we
did
it
in
1.8,
which
was
to
have
people
actually
write
people.
You
know
people
not
scripts
right
in
that.
What
did
we
call
that
template
anyway?
There
was
one
document
where
everybody
would
write
their
release,
notes,
tenifer
and
Radek,
who
took
took
it
from
there,
and
I
think
it
was
probably
blended
with
a
little
bit
of
automatically
pulling
notes
from
PRS,
but
the
idea
is
that
the
new
way
we're
gonna
do.
I
It
is
not
pull
notes
from
PRS
we're
gonna
have
people
write,
know
it's
in
this
document,
then
we
will
have
editors
work
on
them,
I
think
the
really
the
only
question
that
remains
is:
how
does
it
get
built
and
presented
to
the
public?
Do
we
have
one
document
that
shows
both
a
bunch
of
binary
releases
and
knowing
issues
and
release
notes,
or
do
we
separate
those
out
and
have
them
in
in
the
docs
website?
I
really
I.
Think
that's!
That's
the
question
at
hand
now
I
mean
Caleb
if
I'm
off
base
on
that.
E
E
Bit
to
why
I
wrote
in
favor
of
automation
in
my
write-up,
because
I
did
and
and
we've
we've
abandoned,
that
without
I
think
talking
about
what
it
could
do
with
a
writer
involved
on
Caleb
makes
a
good
point
in
his
comments
in
the
dock.
That
devs
need
to
be
encouraged
to
write
a
decent
release.
Note,
content
and
I
don't
want
to
say
exactly
in
what
form,
but
at
the
start
of
feature
development.
In
other
words,
they
ought
to
be
able
to
describe
what
they're
gonna
go
away
in
code
before
the
code.
E
It
yeah
so-
and
you
know
early
and
often
is
a
good
way
to
manage
content
of
any
sort
and
the
problem
with
the
single
file
that
everybody
contributed
to
up
to
and
including
the
last
possible
minute.
The
last
PR
that
went
into
the
release
was
a
release.
Note
PR
now,
admittedly,
that
one
was
a
known
issue
and
that's
okay,
but
we
had
other
PRS
coming
in
literally
only
hours
before
the
final
build
and
I
would
like
to
see
a
process
in
place
that
doesn't
allow
that
I.
E
Don't
imagine
we'll
get
that
for
1/9,
but
if
we're
serious
about
the
quality
of
release,
notes,
I
mean
I,
think
other
things
are
going
on
with
PRS.
Besides,
just
what's
going
into
the
release
notes
if
they're
coming
in
that
late,
but
sorry
getting
getting
a
little
sidetracked
here,
the
the
larger
issue
has
to
do
with
so
many
hands
so
extensively
in
a
single
file.
It
is
not
a
good
tool
for
serious
editing.
E
It's
it's
really
not,
and
I
deliberately
stayed
for
the
most
part
out
of
the
release
notes
until
a
week
ago
yesterday,
because
I
could
see
stuff
coming
in
hot
Radhika
was
doing
a
good
job
of
providing
some.
You
know
sort
of
copy
editing
in
the
individual
PRS,
but
it
was
also
clear
that
a
lot
more
work
was
going
to
need
to
be
done
to
organize
the
content,
to
sort
it
out
to
actually
explain
what
a
feature
was
doing.
I
know.
E
F
E
Maybe
it
was
in
one
of
these
meetings
about
starting
to
farm
out
writers
to
individual
seeds,
actually
have
an
invitation
from
cig
apps,
because
I
wound
up
in
a
meeting
with
Ken
Owens
last
week,
because
I
was
trying
to
make
sure
I
wasn't
breaking
things
with
the
less
than
completely
intelligible
content
that
the
workloads
API
people
provided
us
with.
They
provided
a
lot,
but
you
know
we
didn't
have
time
to
go
through
rounds
of
PRS
and
in
edits.
It
was
the
quickest
way
to
clean
things
up
and
along
the
way.
E
N
N
Yeah
Jared's
point
is
trying
to
get
as
much
of
this
information
up
front,
so
I've
been
working
with
Brian
and
Jase
and
Joe
to
work
on
a
development
process
where
we
could
try
and
grab
some
of
this
earlier
and
I
would
love
to
get
people
from
cig
docks
involved
in
that
because
I,
do
you
think
that
you
know
once
you
are
at
implementation
time?
You
should
have
probably
already
know
what
the
release
notes
should
be
at
that
point
and
because
I
have
yet
to
see
information
that
would
I
guess
a
reasonable
counterpoint
to
that.
N
To
that
belief,
and
so
I
do
think
it's
starting
earlier
is-
is
important
and
also
to
have
a
way
of
managing
this
in
a
distributed.
Fashion.
I
think,
is
also
important,
because
the
sig
meetings
are
only
once
once
a
week
or
once
every
two
weeks,
and
there
may
not
be
a
time
to
synchronously.
Do
this
kind
of
work.
E
A
A
Seeking
out
and
helping
to
develop
content
worked
really
well,
so,
while
there
we
can
talk,
it
would
recommend
that
we
do
it
in
a
different
meeting
because
we're
running
a
little
short
on
time,
but
well,
there
might
be
different
ways
to
optimize
how
we
get
writers
to
work
with
feature
development
teams.
It
does
sound
like
getting
writers
to
work
on
on
release.
Note
creation
rather
than
trying
to
automate
or
script,
generate
release.
Note
content
is
going
to
be.
The
way
to
go
is
the
does
that
seem
like
an
accurate
and
reasonable
summary
I
I'm.
K
Gonna
actually
kind
of
jump
in
and
say,
I
really
think
you
need
both
because
while
you
do
need
the
the
human
interaction
and
the
scripted
solution
isn't
going
to
solve
everything
the
it
again.
I
was
here
very
late
in
the
process,
but
it
seems
like
there
was
a
lot
of
chasing
people
down
at
the
last
minute
and
so
on
and
I
think.
An
automated
solution
could
solve
a
lot
of
the
problems
of
trying
to
get
that
information
a
lot
earlier.
So.
A
One
second,
thank
you
thanks
Jennifer
and
take
care
we'll
see
you
see
you
around.
N
No
and
I
guess
I,
don't
just
I!
Don't
disagree
that
at
some
point
it
would
be
nice
to
automate
a
lot
of
the
documentation,
production,
workflow
I.
Just
don't
think
we
are
yet
in
a
place
where
we
have
a
process
that
we
think
is
scalable
enough
and
reasonable
that
we
want
to
automate
and
I
am
I
guess
concerned
about
building
automation,
that
automates
are
bad
processes.
Today,
at
least
that's
why
we
in
1a
just
stopped
using
the
automated
scraping
of
PR,
knows
now
that
the
information
wasn't
available
and
that
you
couldn't
use
it.
N
A
Thank
you
yeah.
That's
whether
whether
we
can
eventually
automate
whether
automation
makes
sense
or
not,
I,
don't
think.
That's
the
highest
priority
question
right
now:
I
think
that
getting
to
a
place
where
what
we,
where
we
set
clear
expectations
and
are
achieving
consistence,
where
the
future
developers
are
giving
consistent
information
of
a
consistent
quality
sufficiently
early
in
the
process,
then
we
can
automate
that,
but
until
they
get
there,
automation
seems
like
the
wrong
thing
to
chase
yeah
loose.
N
K
A
Thank
you.
Yes,
thanks
all
right,
yeah
coming
from
Ryan
Ryan
J
+1
for
setting
expectations
early
regarding
content
and
dates,
while
engaging
SIG's,
yes
plus
plus
1000,
all
right,
unless
there
is
anything
else
to
add,
going
once
going
twice
all
right.
That's
the
sig
Bucks
meeting,
all
right
thanks
a
lot
thanks!
Everybody
have
a
good
week.