►
From YouTube: Kubernetes Sig Docs 20180213
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 13 February 2018.
A
So
we
have
two
items
on
the
agenda
today
and
the
first,
let's
start
with
finding
consensus
and
guidance
for
how
to
represent
API
changes
with
different
versions.
I'm
really
glad
to
see
this
come
up.
This
has
been
simmering
on
the
back
burner
for
a
while
and
I
think
this
discussion
is
timely,
so
Jo
I
see
her
I,
see
your
name
attached
to
it
and
I
know
you've
been
doing
some
work
around
versioning,
both
you
and
Steve.
A
B
Because
if
well,
that's
a
great
thing
to
update
I
totally
agree,
we
should,
but
we
need
to
make
sure
that
all
the
examples
are
then
in
sync,
with
version
1.9.
If
that's
the
document
documented
version
that
we're
saying
all
these
tasks
and
tutorials
are
related
to
and
I
do
not
know
that
they
are
right
now
and
in
fact,
there's
a
whole
bevy
of
changes
that
I
put
holds
on
just
so
that
we,
you
know
not
because
they
weren't
accurate
or
appropriate,
but
I.
What
just
wasn't
sure
what
the
right
way
to
do.
B
C
So
I've
got
a
couple
of
remarks
on
this,
so
one
is
the
concern
that
Joe
just
raised
and
another
concern
is
the
reverse
of
that
and
which
has
been
happening,
and
that
is
it.
Somebody
goes
through
and
changes
the
version
in
our
yellow
configuration
files,
game.
C
C
It
is
in
the
prerequisites-
and
this
is
done
per
topic
in
the
front
matter
of
the
topic.
You
have
the
option
of
putting
this
this
value
of
min
kubernetes
server
version.
If
you
set
that
to
some
value,
then
it
automatically
appears
in
the
prerequisites
that
you
must
have
it.
At
least
this,
this
version
of
kubernetes
server.
A
C
C
C
But
that's
a
that's,
not
a
true
statement,
because,
if
you're
all
the
way
back
at
1.6,
you
cannot
use
apps
if
V
1
beta
right.
So
it's
an
inaccurate
comment.
I
think
we
should
stop
trying
to
make
comments
like
this
in
the
animal
science.
I
think
it's
just
it's
too
hard
to
get
it
right
and
we're
never
gonna
keep
up
with
it.
A
F
F
F
D
F
A
A
A
A
A
C
B
Think
one
of
the
things
we
can
do
I
totally
agree
with
you
know
Steve
everywhere.
You've
gone
with
this
is
send
out
a
note
to
all
the
reviewers
on
our
team
today
and
say:
hey
as
these
are
coming
in,
because
these
changes
are
becoming
more
frequent.
Please
be
aware,
you
know
this
is
what
we
want
to
do.
We
want
to
make
sure
that
the
appropriate
include
tag
is
in
the
mat
in
the
document
that
has
the
version
two
content,
that
it
represents
the
right
version
and
that
the
example
matches
that
version
number.
C
Yeah
I
agree,
and
here's
part
of
what
makes
it
tricky
is
that
people
are
going
through
and
just
sitting
all
right.
I'm
gonna
go
through
and
change
all
the
ammo
configuration
files
to
v1,
but
they
don't
check
to
see
where
what
topics
are
using
those
llamo
files,
so
they'd
have
to
go
to
that
effort.
They'd
have
to
do
a
grep
or
something
to
see.
Okay.
Now
that
I've
changed
the
Z
Amal
file,
which
topics
refer
to
it
and
now
I
go
to
those
topics
and
make
sure
that
the
frontmatter
says
men.
B
B
Already
planned
nine:
that's
why
I
brought
it
up
at
this
meeting
so
that
I
could
draft
that
email
and
kick
it
out
to
everybody.
Cuz
I,
don't
know
I'm,
not
the
only
one
who's
reviewing
these
PRS
but
I
just
seem
to
be
my
time
zone
when
I,
usually
you
know
start
reviewing
them.
I'm
up
at
the
coffee
shop
at
4:00
a.m.
I've
got
some
hideous
meeting
with
Tel
Aviv,
so
I'm
like
well
I'll
just
review
a
couple
PR
so
I'm
getting
it.
You
know
just
as
they're
slapping
them
in
there
Thanks.
C
So
it's
you
I,
think
that's
probably
unusual,
but
I
do
think
you
shouldn't
be
updating
the
animal
configuration
files
without
looking
at
the
topic
where
they're
used
and
that's
what's
happening
now,
and
it
might
be
more
than
just
getting
the
before
you
begin
updated.
It
might
be
there's
some
other
reason
in
the
text
that
you
know
would
would
indicate
that
we
really
do
want
this
to
still
say:
V
1,
beta
2.
A
A
A
Well
like
you're,
making
the
surprised
face
so
I
will
make
an
update,
and
then
you
can
correct
me
so
after
talking
with
with
Eric
Veda
and
the
the
test
in
for
a
team
about
the
the
the
purpose
of
tied
and
prowl
and
matching
matching
the
expectations
of
what
we
are
trying
to
do
with
it
as
sig
docs
for
tech,
LG,
TM
and
Doc
sale,
GT
diem
and
the
intentions
of
the
bot
creators,
it
it
looks
like
we
were
trying
to
make
the
bots
do
things.
They
were
not
designed
to
do
that.
A
A
The
solution
to
that
is
to
override
permissions
at
the
at
the
local
level
for
the
repo
and
make
them
specify
that
these
specify
that
folks
or
reviewers,
rather
than
approvers,
to
override
upstream
permissions
and
what
that
looked
like
functionally
was
that
Jo
bless
his
heart,
went
and
added
directory
level
owners
files
for
reviewers
and
that's
fantastic.
It's
a
lot
of
work,
but
I
appreciate
it.
So
that
is
I.
A
B
The
only
difference
was
those
files
already
did
exist,
I
didn't
go,
add
them
I,
just
updated
it.
Everybody
that
was
in
those
files
was
listed
as
an
approver,
which
is
what
caused
the
unexpected
behavior.
That
Jennifer
noted
early
on
somebody
gave
an
LG
TM
there.
It
was
taken
as
an
approver,
zel
GTM.
No
further
review
was
needed
and
WHAM
it
went
straight
in
and
that's
what
was
confusing
us.
It
wasn't
until
Eric
said:
hey
you
missed
configured.
This
whole
thing
was
like
okay,
okay,.
D
You
so
is
this
conversation:
what
sort
of
looking
for
over
I
saved
that,
because
I
did
invite
Andrew
Jared
and
some
testing
folks
to
contributor
experience
on
Wednesday
to
talk
this
out
further,
especially
the
mechanics
behind
l,
GMT
and
and
to
prove?
Do
you
want
to
table
that
conversation,
or
should
we
still
go
ahead
with
it.
A
C
There's
an
an
issue,
or
maybe
a
PR
that
Aaron
Creek
and
Berger
opened
to
to
add
this
option
to
LG
TM,
add
an
option
where
LG
TM
does
not
act
as
approve
and
all
it
all
it
is.
Is
you
know,
giving
repositories
the
option
into
to
sit
LG
TM
access
approved
to
false,
but
turns
out
in
that
PR?
There's
a
lot
of
resistance
to
the
idea,
so
I
think
that
discussion
probably
needs
to
keep
keep
going.
A
F
F
My
conversation
that
led
Aaron
to
file
that
issue
I
think
that
for
purposes
of
cig
Docs,
we
are
in
better
shape
now,
but
the
issue
got
framed
in
a
somewhat
larger
context,
so
yeah
I
think
it
is
useful
to
take
it
up
there
and
that's
just
giving
a
little
more
context
to
Steve's
comment.
D
C
And
one
more
thing
along
these
lines,
these
these
owner
files
that
are
in
directories-
we
don't
have
them
in
all
of
our
directories.
In
fact
the
ones
we
have
tends
to
be
in
our
old
directories
that
were
working
on
getting
rid
of.
So
the
question
would
be.
Do
we
want
to
continue
this
pattern
and
have
this
in
our
new
directories?
C
B
Noting
that
it's
specific
to
a
directory
structure,
so
kind
of
think
of
them
as
leaf
nodes
and
as
we've
reorganized
into
concept
tasks,
things
like
that,
the
set
of
possible
reviewers
has
expanded
broadly
because
of
our
organization
set.
They
may
not
be
as
beneficial
as
they
once
were
when
things
were
more
organized
by
topic
set
within
a
directory.
B
C
That's
right,
it
is
to
be
that
every
every
little
thing
would
have
its
own
directory
and
inside
index
dot,
MD
and
then
some
configuration
files
and
now,
as
small
as
we
get,
we
might
have
under
tasks.
We
might
have
something
called
configuring,
pods
and
containers,
and
that
covers
a
lot
of
ground.
So
it's
trickier
to
narrow
down
the
list
of
reviewers
that
should
be
automatically
assigned
to
things
in
that
directory.
I,
wonder.
A
If
we
could
take
advantage
of
the
aliases
in
the
owner,
Sebelius's
file
and
just
tag
tagging
and
alias
for
things
that
are
six
that
are
relevant
to
a
topic
except
that
code,
that
requires
us
to
go
topic
level.
Wouldn't
it
may
be
good
I,
don't
know
you
immediately.
Think
of
like
use
cases
where
tagging
by
sig
would
be
less
helpful.
C
C
A
I
think
that's
a
better
revision
is
I
would
be
really
curious
to
try
both
to
try
adding
individual
reviewers
and
then
try
adding
by
sig.
You
know
the
the
only
reason
that
adding
by
sig
a
leus
even
comes
to
mind
is
because,
if
we
add
individual
owners
at
the
directory
level,
that's
two
places
to
maintain
that's
a
dual
source
material.
We
have
to
maintain
that
list
in
owners
Sebelius's
and
in
individual
owners
files,
sometimes
multiple
owners
files.
C
Think
I
would
love
to
do
that.
Can
so
I,
don't
maybe
Joe.
Maybe
you
know
the
answer
to
this
I.
Can
the
bots
go
through
and
assign
a
group
like
you
know,
sig
storage,
PR
reviews,
I,
don't.
B
A
B
I've
got
comments
on
it
from
Jennifer
and
Steve
now,
if
anybody
else
wishes
to
comment
before
I
take
a
pass
at
updating
it.
Based
on
those
comments,
please
do
so,
can
we
say
by
Thursday
and
I:
will
you
know,
go
on
and
just
run
through
the
whole
damn
thing
and
update
it,
based
on
all
the
feedback
and
try
to
improve
my
language,
because
all
the
comments
are
super
relevant
I
was
having
a
hard
time
disambiguating
and
describing
what
it
is
and
I
think
the
feedback
there
is
perfect.
B
A
A
We
have
a
little
bit
of
a
like
a
hard
mechanical
conversation
and
then
some
some
I
guess
the
softer
conversation
about
method
I
just
want
to
point
out
before
we
get
before
we
get
rolling
the
the
link
that
Joe
added
from
Paris
Thank
You
Paris
for
contributor
stats
over
time.
So
last
week
we
had
talked
about
having
a
service
level
objective,
not
an
agreement,
an
objective
of
one
week
or
less,
and
if
we
look
at
the
kitchen
stats
for
the
repo
or
responsiveness
test
for
the
repo
we
meet
that
handily,
it's
our
will
host.
D
No
one's
that
can
first
nan
author
activity.
Alright,
sorry
now
I'm,
just
getting
it
up
on
my
browser
right
now
time
before
any
commitments
or
activities:
okay,
okay,
yep.
So
what
you're
seeing
right
now
is
just
for
docs.
If
you
want
any
other
repositories,
you
can
filter
for
those
at
the
top.
D
But
in
this
it
looks
like
the
the
dashed
lines
that
are
going
vertically
are
your
releases
and
then,
if
you
point
your
mouse
over
any
of
other
lines
like,
for
instance,
80th
percentile,
which
essentially
means
your
longest
time
that
you've
had
for
first
non
author
activity,
so
meaning
if
Zack,
is
the
author
of
a
issue
and
then
say
Jennifer
comments
on
it.
What
you're
measuring
here
is
Jennifer's
comment,
so
how
long
does
it
actually
take
for
someone
to
get
something
from
us,
which
is
a
great
metric?
D
I
know
that
go
team
and
several
other
open
source
projects
use
this
as
a
way
of
measuring
the
health
and
the
velocity
of
their
projects,
but
I
mean
currently
just
from
you
know.
Like
a
most
recent
date,
it
looks
like
your
very
good
days.
It's
like
1.8
hours
and
then
you're,
not
so
good
days
is
a
little
more
than
five
days
to
get
a
comment
or
any
like
I
said
or
any
activity
that
could
be
closing
the
issue
completely
assigning
and
a
label
pretty
much
anything
I.
D
A
D
D
D
And
the
other
thing
is
to,
if
you
want
to
reverse
engineer
this
a
little
bit
and
think
about
questions
before
you
think
about
that
data,
and
you
don't
know
where
what
graphs
to
use
to
answer
your
questions
come
to
me,
because
sometimes
we
might
be
able
to
create
a
graphed,
a
graph
for
you
that
works
better
and
that's
exactly
what
we're
trying
with
dev
stats
in
general.
It's
like
like
I,
said
now.
We
have
all
these
graphs
now,
what
so
I'm
trying
to
like
reverse
engineer
this
and
think
of
okay?
D
What's
something
I
really
want
to
know
from
kubernetes
data
and
try
to
mold
it
that
way
so,
like
I,
said,
if
anybody
on
the
call
ever
has
like
hey
how
I
think
it
would
be
so
cool
to
know,
X
from
you
know,
X
time
period,
let
me
know,
because
we
would
love
to
get
this
to
a
point
where
you
know
we
can.
You
know
really
start
blogging
about
the
data
and
things
like
that.
Okay,.
C
F
D
A
A
Okay,
that
was
really
cool.
So,
let's,
let's
talk
a
little
bit
more
about
soft
expectations
for
handling
reviews.
So,
like
the
two
of
the
questions
that
I
wrote
down
are
when
we
see
somebody
else
is
assigned
to
a
PR
like
how
long
do
we
wait
before
we
touch
it
dude?
Do
we
touch
it?
Do
we
do
we
care
that
it's
assigned
to
someone
else?
Do
we
need
to
set
a
sign,
or
do
we
need
to
set
expectations?
For
you
know
now
that
we've
got
a
bot
automatically
assigning
things?
A
C
B
Do
not
believe
that
it
applies
assignees
I,
think
it
recommends
one
but
leaves
that
to
human
interaction,
where
it
pulls
that
list
from
I'm
not
entirely
sure,
but
it
recommends
it
based
on
some
history
and
it
doesn't
necessarily
pull
just
from
the
approvers
list.
From
what
I've
seen
I
think
it
looks.
C
Okay,
so
I
kind
of
thought.
The
pattern
was
that
that
the
advice
you
get
in
the
PR
says
something
like
this.
This
PR
must
be
approved
by
someone
in
each
of
these
owners
files
or
someone
in
this
owners
file,
and
if
you
want
to
make
that
request,
you
say
slash
assign
that
person
and
I
guess
when
they
used
the
word
this
must
be
approved.
I
was
thinking
that
meant
that
it
was
when
it
suggested.
You
know.
C
F
Pretty
exactly
what
it
says
to
fully
approve
this
pull
request.
Please
assign
additional
approvers.
We
suggest
the
following
additional
approver.
It's
sound
like
an
approver
to
me,
but
then
I'm,
but
that
doesn't
necessarily
mean
that
that
gets
a
say
I'm.
Looking
at
an
example
right
now
that
I
think
it's
pretty
typical
the
ones
I've
seen
since
we
started
using
the
bot
and
the
assignee
is
the
reviewer
who
provided
lgt,
em
and
it
I
don't
see
and
a
sign
command
anywhere
in
the
PR.
If.
B
F
A
G
F
F
A
C
Well,
well,
we're
on
on
this.
What
one
other
questions
does
it
seem
weird
to
anybody
else
to
get
given
that
I'm,
an
approver
saying
every
time,
I
open
a
PR?
It
says
this
PR
is
approved
and
it
slaps
the
approved
label
on
it,
because
the
person
who
opened
it
is
an
approver
that
that
seems
ridiculous
to
me
seems
dangerous.
Well,.
C
Was
so
good
good
question
suppose
either
someone
else
or
I
does
a
/lg
TM?
Is
that
enough
for
it
to
be
automatically
merged?
I've
never
tried
that
experiment.
It
is
oh,
okay,
so
I
think
it's
kind
of
weird
that
if
you're
an
approver
and
you
open
a
PR,
it
slaps
an
approved
label
on
it
and
and
makes
a
note
of
saying,
hey.
This
PR
is
approved
by
this
person,
so.
E
B
No
you're
absolutely
right,
but
just
be
aware,
it
doesn't
allow
you
to
LG
TM
your
own
stuff,
so
it
forces
somebody
else
to
do
it.
So
if
the
danger
is
somebody
other
than
you
looks
at
it,
that's
that's
not
necessarily
what's
happening
here,
but
there
is
sort
of
a
two
people
are
required
to
review
it.
This
is
an
exception
if
one
of
those
people
is
already
an
approver
okay,
so.
E
C
Well,
it
bypasses
the
writing
review
so
if
I
open
a
PR
and
what
I
would
like
to
have
is
both
a
technical
review
and
a
writing
review
and
as
soon
as
a
tech
reviewer
puts
an
LG
TM
on
it,
it
gets
automatically
merged.
Dangerous
I
haven't
gotten
the
writing
review.
Then
they
don't
always
want
to
writing
review.
Sometimes
it's
a
trivial
change
and
I.
A
Can
you
hear
me
now
yep,
okay,
good
deal
so
in
cases
where
we
want
to
have
a
more
intentional
process.
We
can
do
you
know
two
different
lines:
/l
g,
TM
and
slash
hold
and
so
impose
a
hold
for
a
writing
review,
but
it
does
require.
It
does
require
active
choice
for
that
rather
than
the
the
passive
default
behavior,
which
I
don't
know,
is
necessarily
a
bad
thing.
I
think
I'm
fine
with
how
things
are
set
up
right
now,
because
we
do
we
do
have.
A
We
do
put
a
great
deal
of
trust
in
people
who
have
approval
power
or
the
repo
and
using
that
power
mindfully
seems
like
a
reasonable
thing
to
ask.
So
you
know
if
you,
if
you
want
to
you're
working
on
something
that
needs
specifically
to
get
a
distinct
tech
review
and
writing
review
and
you're
an
approver,
then
imposing
a
hold.
You
can
there's
no
reason
why
you
can't
hold
your
own
PR.
You
know
you
can.
A
E
That
kind
of
feel
like
a
band-aid
though,
and
it
feels
like
we're
just
kind
of
patching,
something
that's
a
little
dangerous
and
so
there's
now
you're
gonna
see
holds
all
over
the
place.
And
why
did
why
why'd,
you
have
to
put
the
hold
well
because
I'm,
an
approver
and
if
I
don't
put
the
hold
or
if
I
forget,
to
put
the
hold.
Oh
boy,
this
thing
might
merge
a
little
faster
than
I
think.
Does
that
make
sense?
Anybody
well.
A
D
A
E
Guess
I
would
just
need
a
little
cheat
sheet
that
says:
okay,
if
I
need
a
tech
review
and
and
and
a
writing
review.
Well,
here's
what
I
had
to
do
it.
You
know
you
know
just
something
so
I
can
just
ingrained
I,
don't
know
everybody
else.
I'd
be
scared.
I
just
mess
up
a
little
bit
right.
So
if
maybe
had
a
little
cheat
sheet
that
says:
okay!
Well,
if
I
do
this,
this
is
what
I
really
meant.
A
B
A
E
A
So
I'm
sorry
I'm,
gonna
I'm
gonna,
look
back
around
to
one
of
the
original
questions,
which
is
if
a
PR
is
assigned
to
someone
else,
I
mean.
Do
we
want
to
take
a
cookie
licking
policy
at
all
like
this
cookie
has
been
licked
by
someone
else.
In
this
case,
bye-bye
prowl
prowl
has
automatically
licked
this
cookie
on
someone's
behalf.
E
So
it's
kind
of
a
circle
of
trust
thing
that
says
the
following.
You
trust
your
folks
to
know
what
they
feel
comfortable,
reviewing
and
approving
as
part
of
the
approvers,
and
in
that
case
it's
it's
no
big
deal
that
somebody
helped
me
out.
Let's
say
I
see
that
Jo
was
assigned
and
I
pulled
from
him,
because
he's
busy
took
one
of
his
30
fake
Asians
to
some
coffee
place
and
so
I'm
like
yeah.
So
that's
the
nice
thing
right.
E
E
A
I
guess
that's
what
I'm
asking
is.
Does
anyone
feel
really
strongly
that
we
should
have
like
a
really
strong
boundaries
on
PRS
until
a
certain
date
and
I'm
not
hearing
that
at
all
I'm
hearing
that
we
don't
really
need
to
worry
about
this
PR
as
a
PR
review,
away,
reviews
free
and
just
just
get
to
get
the
PRS
review?
You
know
we're
all
going
to
have
different
availability
around
that
and
that
sound
that
to
me
sounds
wonderful.
They're.
C
Doing
it
works
it's
it's
one
thing
to
say:
everybody's
welcome,
to
participate
in
the
PR
and
I.
Think
that
we're
all
fine
with
that,
but
the
the
other
question
is,
is
somebody
who's
not
listed
as
an
assignee
er,
who
has
not
been
requested
as
the
approver?
Should
that
person
do
a
slash
approve,
which
could
then
lead
to
an
automatic
merge.
E
Oh
those
slight
tweak
to
that
is,
let's
say
the
one
person's
done.
The
reviews
and
they've
feel
very
strongly
about
the
comments
they've
made
and
they
want
those
comments
to
be
addressed,
and
then
you
come
over
top
of
that
and
go
no
I
approve
right.
So
that's
what
you
want
to
be
careful
of.
Sometimes
you
have
people
that
are
trying
to
get
really
good
feedback
and
you
you
want
that
feedback
to
be
taken
into
account
before
an
approval
is
given
and
if
somebody
else
comes
behind
you
and
just
says.
E
A
F
F
Do
you
want
a
hand
with
these
I
mean
we
have
communication
mechanisms
and
I
think
we
have
enough
trust
built
up
that
we
know
how
to
handle
this
I
agree
with
Steve,
but
on
the
other
hand
like
I,
have
provided
you
know,
changes
required
reviews
to
PRS
I've.
Never
had
anybody
come
in
behind
me
and
approve
or
merge,
but
that
just
doesn't
I
haven't
seen
it
happen.
F
I
think
that
we
we
know
how
to
behave
ourselves
and
if
I
want
to
go
I
know
speaking
only
for
myself,
I
mean
if
anybody
wants
to
go
into
something.
That's
a
saying
to
me:
I'm,
assuming
first
of
all
that
there's
one
of
two
reasons,
because
it's
something
you
care
about,
and
you
want
to
see
what
I
might
be
doing
with
the
thing
you
might
disagree
with
how
I'm
handling
it
and
typically
our
piers
are
smaller
than
this
right.
F
Sometimes
they're
not
or
I've,
been
sitting
on
it
for
too
long,
in
which
case
I'm
eternally
grateful.
If
you
take
care
of
it
and
I
feel
a
little
shamefaced
and
maybe
I'll
do
better
to
contribute.
You
know
sort
of
pull
my
weight
with
the
SLO
going
forward.
So
I
think
there's
a
bunch
of
variables
here
that
we
as
his
group,
all
kind
of
operate
with
responsible
assignments.
There
sure
so
I.
A
Mean
we're
we
talk
a
lot
about
trust
and
Trust
is
really
important
in
any
group,
but
I
think
what
trust
can
mean
can
vary
depending
on
the
group,
size
and
composition.
So
let
me
ask
it
not
so
hypothetical
question:
if
we
scale
up
this
group
and
add
five
more
maintain
errs
over
the
course
of
this
is:
is
that
still
a
sufficient
basis
of
trust
from
which
to
operate?.
B
A
F
A
E
Assigned
to
automatic
automatically,
it
would
seem
like,
let's
say,
Joe
assigned
20
of
them
automatically.
Well,
they
weren't
really
like
his.
It
was
just
somebody
shoved
them
on
him,
and
wouldn't
he
want
me
just
to
go
and
pick
one.
It
wasn't
like.
It
was
one
that
was
near
and
dear
to
his
heart
as
opposed
to
well.
The
tool
was
mean
to
him
that
week
and
gave
him
an
extra
20
to
make
any
sense,
and
then
so
I'd
want
to
be
able
to
just
be
aggressive
and
say.
E
A
Once
I
could
say,
hey
you're
PRQ
looks
long,
can
I
help
or,
if
he's
being
unresponsive
to
say,
hey
Joe.
Unless
I
hear
back
from
you
I'm
grabbing
these
10
PRS,
you
know
just
practice
like
good,
proactive
communication.
I
I,
don't
see
the
need,
I,
guess,
hearing
this
conversation
I,
don't
see
the
need
to
to
try
and
create
specific
policy.
I.
Don't
think
this
is
a
policy
problem.
I,
don't
even
think
it's
a
problem.
I
think
it's
right.
A
It's
not
like
a
relational
check-in
and
I
think
that
we're
all
cool
with
how
things
are
working-
and
you
know
it's
working
so
I-
think
we
can
I
think
we
can
continue
sort
of
consciously
doing
the
way
things
consciously
continue
doing
things.
The
way
that
we've
done
them
to
this
point,
because
it's
a
working
relationship,
I.
E
A
It
increases
our
PR,
it
decreases
our
PR
queue
and
increases
our
throughput.
So
all
right,
we've
got
about
three
minutes
left
anything
else
for
last-minute
discussion,
I'm
good,
we'll
put
in
one
more
plug
for
IBM
index
next
week.
If
you
are
in
the
Bay
Area
and
you'd
like
to
attend
IBM
index,
we're
doing
a
dock
sprint
on
Tuesday
Brad
and
myself
will
be
there.