►
From YouTube: Kubernetes SIG Release 20181120
Description
A
A
A
I'm
gonna,
give
it
just
another
minute
or
two
to
see.
If
we
get
some
additional
folks,
I
know
we
aren't.
Gonna
have
Stephan
Augustus
today,
I
think
he's
traveling
I
started
jotting
names
of
folks
in
the
minutes,
just
with
the
first
people
who
had
joined,
but
others.
If
you
could
add
your
name,
there
would
greatly
appreciate
that,
for
the
record
I'll
give
it
just
another
minute
for
folks
to
join.
A
A
A
Welcome
to
the
team
in
both
regards
as
a
VMware
person,
so
I
guess
that
maybe
goes
then,
naturally
to
the
first
thing
on
the
agenda
updates
to
the
cig
leadership.
There
is
a
reference
there
to
a
poll.
Jase
has
moved
on
to
emeritus
status
for
the
sig
and
steven
augustus,
and
I
and
I'm
tim
pepper,
I
work
for
a
VMware.
A
We
are
stepping
up
to
contribute,
as
chairs
also
for
the
sig,
so
just
FYI,
if
folks
hadn't
seen
that
go
by
in
PRS
or
discussion
in
the
slack
channel
or
wherever
additionally
I
else
else
surprised
that
happened
so
yeah.
Hopefully
this
will
just
be
a
continuation
of
things.
I
do
know.
Over
the
last
year,
both
Caleb
and
Jace
have
been
pulled
away
quite
a
bit
two
other
things,
so
Steve
and
I
are
hoping
to
make
sure
that
we
have
meetings
a
little
more
regularly.
The
sig
has
always
struggled
a
bit.
A
Almost
everybody
on
the
call
today
is
either
on
the
current
release
team
or
was
very
recently
or
like
art
looking
to
join.
So
the
release
team
in
any
given
quarter
has
really
dominated
what
the
sig
does,
but
I
really
believe
that
having
a
regular
sig
meeting
documenting
the
things
that
we
would
like
to
do,
that
makes
it
easier
for
folks
to
show
up
listen
a
little
bit.
Lurk
see
like
hey,
could
I
do
that?
A
Team
has
done
a
really
good
job,
better,
defining
orals,
making
it
easier
for
people
to
step
up
and
having
sort
of
that
that
shadow
lead
support
structure
that
makes
it
more
viable,
so
I'm,
hoping
that
we
can
pull
in
some
more
blood
in
cig
release
and
get
some
more
things
going
on
around
release
engineering
as
2019
slams
us
in
the
face
here
in
a
couple
weeks.
So
next
on
the
agenda
is
charter
leagues
there
again
in
the
minutes
that
has
merged-
hopefully
folks
have
read
it.
A
If
not
I
would
encourage
you
to
and
as
much
as
we
just
went
through
the
whole
process
of
getting
it
merged.
I
do
think
these
charters
need
to
be
living
documents.
So
if,
if
you
see
things
weather
today
or
twelve
months
from
now
or
whatever
think
about
peeing
a
change
bring
it
up
in
this
forum
to
discuss
and
let's
make
sure
that
we're
constantly
doing
what
we
say
and
saying
what
we
do,
because
that's
part
of
the
transparency
that
makes
it
the
group
more
sustainable.
So.
C
I
was
one
of
the
steering
committee
members
who
had
to
review
the
Charter
prior
to
it
getting
merged,
and
since
it
has
been
hanging
out
for
so
long,
I
had
a
number
of
comments.
I
would
like
to
see
addressed,
but
I
didn't
suggest
they
were
blocking
comments,
I've
left
them
all
on
the
PR,
that's
linked
there.
My
question
is:
how
best
to
make
sure
that
this
is
followed
up,
should
I,
create
an
issue
and
assign
it
to
you
and
Steven
as
the
chairs
of
this
sig
or
how
would
you
recommend
I
go
got
that
I.
C
A
C
The
main
thing
was
there
was
a
lack
of
clarity.
It's
kind
of
implied,
I
think
that
this
team
has
historically
only
dealt
with
kubernetes
kubernetes,
but
there
are
a
hundred
and
thirty-eight
different
repositories
associated
with
this
project
and
I.
Think
it's
really
important
that
you
clarify,
which
ones
you
are
and
are
not
responsible
for.
This
will
become
especially
important
as
we
look
to
start
building
a
release
made
up
of
things
that
are
potentially
built
from
other
repositories
when
we
do
things
like
break
out
the
cloud,
controller
manager
and
sundry
cloud
provider
implementations.
A
Already
I
mean,
though
the
last
few
releases
I
think
in
1,
9
or
1:10.
We,
we
did
sort
of
a
scavenger
hunt
to
see
what
our
dependencies
worded
to
note
in
the
changelog
and
I
was
like
10
or
12
things
that
hit
the
changelog
and
then
that
doubled
in
the
next
one
and
it
doubled
in
the
next
one
and
it
doubled
the
next
one
and
is
starting
to
look
a
lot
like
a
distribution.
A
And
we
really
got
to
start
thinking
about
what
that
means
and
we're
all
we're
pulling
from
and
how
we
manage
version
skew
integration
testing
and
make
sure
that
we
actually
have
something
coherent,
because
it's
not
just
an
academic
exercise
to
sort
of
declare,
release
that
has
to
actually
be
usable
in
a
meaningful
way.
And
integration
is
really
hard.
A
C
A
Well,
we
will
hopefully
continue
to
integrate
and
integrate
iterate
and
improve
that
as
time
goes
by.
The
next
thing
that
Steven
put
on
the
agenda
was
to
talk
about
sub
projects
and
work
groups.
I
think
there's
basically
nothing
there
specifically
to
talk
about
this
week.
We
do
have
a
separate
item
for
the
release
team
for
the
the
114
team.
A
Just
the
basic
naming
of
what
the
thing
is,
where
it
falls
in
the
governance
hierarchy
and
how
you
how
you
know
that
it
exists
it's
kind
of
buried
right
now
and
for
for
the
listeners,
that's
Brandon
Phillips,
not
one
of
the
other
potential
ones.
Jordan
Liggett
also
is
active
there
and
will
circle
back,
maybe
to
his
name
in
just
a
moment
on
one
of
the
next
things
on
the
agenda
so
kind
of
going
about
what
I
mentioned
talking
about
leadership.
My
hope
is
that
is
the
coming
year.
A
Goes
by
that
these,
these
ideas
of
sub-projects
and
work
groups,
working
groups
that
relate
to
sig
release
that
we
better
define
what
we
want.
Those
to
be
because
there's
been
a
lot
of
talk
about
it,
but
then
that
hasn't
translated
into
specific
actions,
trying
to
get
volunteers
staffed
behind
them
and
and
then
we
just
end
up
talking
month
after
month,
kind
of
ambiguously.
So
my
hope
is
that
we
do
better
definition
on
that
and
and
can
turn
it
into
actual
action.
A
Next
thing
on
the
agenda
is
Steven
again
dropped
in
a
mention
of
this
issue.
Three-To-One
and
sigrid
eise
I
thought
this
was
kind
of
dead
and
done
and
closed,
but
he
felt
like
it
wasn't,
so
he
wanted
to
circle
back
to
it,
so
that
the
general
gist
of
this
is
right.
Now
the
release
process
for
two-thirds
of
the
release
cycle
is
kind
of
ambiguous.
Anything
that
is
merge
ready,
can
merge.
A
When
we
hit
code
slush
and
code
freeze,
we
have
some
established
criteria,
that's
more
rigorous
there,
but
initially
it's
fairly
weak
and
the
idea
of
specifically
annotating
each
issue
and
PR
with
a
milestone.
We'd
done
that
in
the
past,
but
it
it
didn't
really
amount
to
much
of
anything.
Useful
and
I.
Don't
think
anybody
aside,
a
little
bit
from
some
of
the
PM's
was
interested
in
keeping
it.
We
did
away
with
it.
We
haven't
seen
that
I've
heard
any
adverse
consequences,
but
I
should
you
have
any
thoughts
from
the
current
release
cycle
on
that
I?
A
D
I
would
concur
to
say
that
I
don't
see
how
it
can
really
help,
mainly
because
when
we
kind
of
move
something
out
out
of
the
130
might
or
whatever
the
current
milestone,
we
say
if
we
always
say
milestone
future
or
we
put
it
on
some
future
milestone.
It's
it's
even
going
to
be
in
fact
a
little
bit
burdensome
on
the
current
release
team
to
even
figure
out
which
appropriate
milestone.
D
We
should
move
it
to
and
all
of
that,
if
we,
if
we
try,
pr's
and
everything
to
a
specific
milestone
that
they
should
get
into
and
I
yeah
from
the
experience
that
I've
had
this
time,
I
don't
think
I
would
have
benefited
initially.
It
did
seem
like.
Oh,
what
are
all
the
things
that
are
emerging
1:30
that
that
seemed
to
be
like
a
big
question,
but
yeah
you're
right
once
we
neared
code
slush
I,
think
that's
when
code
slashing
codes
freezes
when
things
start
to
slowly
define
much
more
I.
A
Can
see
the
desire
from
a
p.m.
sort
of
perspective
to
have
like
a
more
deterministic
managed
flow,
but
that's
also
different
than
how
this
community
works
and
and
quite
commonly
most
open-source
communities.
So
I
don't
know
that
one
that
we
should
be
declaring
that
that's
what
we're
gonna
do,
especially
when
people
were
I
felt
like
it
kind
of
opted
out
of
it.
It
was
spotty
how
much
things
were
marked
and
going
to
enforcing
without
a
solid
ration.
E
A
C
Even
at
github
URI
you
can
hit
or
there's
a
git
command.
You
can
use
ask
what
which
tag
contains
a
given
commit.
So
we
talked
about
this
at
length.
I,
don't
I'm
revisiting
it
other
than
to
say
it's
undo.
Friction
there
had
been
the
only
way.
I
would
see
this
as
acceptable
as
if
there
was
some
piece
of
automation
turned
on
that
automatically
applied.
C
E
E
A
A
A
Well
all
these
sort
of
back
and
forth,
where
we've
kind
of
been
light,
process,
light
and
affiliative
in
the
process,
and
things
have
mostly
worked
but
they're
starting
to
be
things
that
are
a
little
more
contentious
and
it's
a
burden.
I
think
on
the
release,
lead
to
not
have
a
more
objective
criteria
to
back
to
to
say,
like
here's,
what
I'm
making
my
decision
based
on
there's
always
the
gut
like
okay,
this
this
major
feature,
isn't
ready
and
sick
architecture
agrees
and
Sega
released,
agrees.
We're
gonna!
A
D
A
Say
so
not
to
pick
on
the
specific
issue
of
the
week,
but
let's
say
sig
windows
all
agreed:
this
is
critical
urgent.
They
label
it
as
such,
and
it
merges
mm-hmm.
Was
that
the
right
thing
to
do
so?
The
release
team
does
largely
rely
on
the
SIG's
to
make
the
right
call,
but
when
something's
a
little
broader
and
we're
worried
about
the
overall
health,
because
we
have
to
worry
about
that
broader
picture.
I
can
understand.
Also,
then
we're
sick
Windows
says
like
this
feels
arbitrary
I
keep
getting
kicked
from
meeting
to
meeting
with
new
requirements.
F
A
D
And
also
that
signal
is
kind
of
reactive
for
the
most
part
it
you
get
that
after
things,
kinda
merge.
Most
of
this,
the
decision
has
to
kind
of
comes
to
like
before.
Do
we
even
let
it
in
or
not,
I
think
the
criteria
also
is
very
time
bound
as
an
acquaintance
in
the
cycle
we
are
talking
about?
Is
it
trees
or
like
few
days
before
cool
trees,
yeah
I.
C
C
C
C
Right
yeah,
so
I
don't
want
to
blow
scope
because
there's
like
there's
the
larger
idea
of
trying
to
say
larger,
moving
to
some
shiny
new
world,
where
the
development
of
larger
features
is
done
on
branches
that
don't
even
touch
master
until
they've
met
certain
objective,
measurable
criteria
such
as
testability
and
reliability
in
performance
and
blah
blah
blah.
But
that
is
the
future,
and
that
has
some
engineering
effort
that
needs
to
happen
before
we
can
get
there,
and
so
in
the
meantime,
you
could
still
they
say
like
in.
C
In
a
way
like
you,
you,
the
release
team
have
some
metrics
that
you're
using
to
track
whether
or
not
a
release
is
ready
to
go
out
the
door
and
your
criteria
for
whether
or
not
a
PR
is
allowed
to
go
in
or
not.
Is
whether
or
not
you
suspect
it
is
going
to
affect
those
metrics.
If
you
think
a
PR
is
going
to
cause
a
bunch
more
tests
to
fail,
you
don't
want
that
PR
to
go
in,
but
that
that's
all
kind
of
like
really
difficult,
hand-wavy
stuff
to
measure.
A
So,
maybe
to
back
up
a
step,
I
mean
sure
this
issue
exists,
talking
specifically
about
the
the
320
issue.
What
qualifies
for
a
milestone,
not
just
the
mechanism
portion
or
the
requirement
to
have
a
milestone?
What
qualifies
for
a
milestone
do
folks
feel
like
we
really
have
a
problem.
I
feel
like
certainly
this
last
week,
there's
been
some
frustration,
but
at
any
point,
you're
gonna
sort
of
have
some
some
misses
on
things.
I
feel
like
this
kind
of
this
pragmatic
process
light
drive
a
discussion
with
the
SIG's
and
stakeholders
is
actually
working.
F
E
Haven't
I
haven't
watched
PR
since
111,
so
I
would
like
to
hear
from
the
112
and
current
release
cycle
people,
but
both
for
111
and
one
10
cycles.
My
experience
was,
we
would
basically
have
one
team
each
release,
who
would
abuse
code
freeze
by
trying
to
get
stuff
in
that
was
basically
new
feature
development
during
code
freeze,
but
only
one
is
no.
E
It
was
different
each
time,
okay,
I
and
I.
In
one
case,
it
was
honestly
that
they
had
been
paying
any
attention
to
the
release
cycle
like
it
wasn't.
They
were
trying
to
put
something
in
during
code
freeze,
it
was
a.
They
were
completely
oblivious
about
where
we
were
in
the
release
cycle,
which
now
that
were
branching
at
the
beginning,
the
code
slush
would
be
less
of
an
issue.
A
1:12
I
think
I
had
it
fairly
easy.
There
were
a
couple
that
I'd
been
watching
from
the
beginning
and
sort
of
started
to
I
kind
of
had
like
a
red,
yellow,
green
mental
flash
on
on
each
of
the
the
features
that
were
supposed
to
be
targeted
for
the
milestone
and
of
those
as
time
went
by
and
they
were
continuing
to
look
late,
then
I
ping,
the
cig,
like
hey,
are
you
still
working
on
this
for
the
milestone,
yeah,
yeah?
Ok,
another
week
goes
by
I
still
haven't
seen
code
haven't
seen,
Doc's
haven't
seen
tests.
A
Are
you
still
working
on
it?
Well,
it's
starting
to
become
a
stretch
and
then
finally,
like
hey,
you
got
to
make
a
call
and,
and
they
in
in
each
case
and
1:12
I
think
they
they
all
said
yeah.
This
isn't
going
to
make
it
so
we
there
were
some
that
were
a
challenge,
but
there
wasn't
like.
There
was
a
disappointment.
D
For
the
most
part,
six
and
the
owners
are
pretty
open
to
these
discussions.
From
what
I've
seen
similar
to
what
experience
you're
saying,
like
generally,
we
had
to
go,
but
we
have
to
ping
their
enhancement
multiple
times
and
but
finally,
when
they
had
to
make
a
go/no-go
call,
a
lot
of
them
did
just
because
we're
not
going
to
make
it
in
time
and
during
freeze
at
least
now,
mostly
the
fixes
I'm
saying,
are
for
their
bug
fixes
rather
for
features
that
are
either
doing
to
GA.
D
There
are
few
issues
that
you
are
finding
testing
now
and
those
things
that
we
are
letting
go
by
mainly
because
they
are
about
fixes
may
not
feature
work,
the
most
part
yeah,
even
when
there's
a
pending
PR,
that's
going
in
and
we
asked
them.
If
how
critical
is
it
does
need
to
go
during
freeze
they're,
mostly,
they
are
on
the
side
of
caution
and
saying
it's
not
needed
if
it's
not
super
critical
or
if
it's
not
affecting
the
stable,
oh
yeah,.
E
And
that
was
that
was
only
changed
how
the
milestones
were
handed
handled
to
require
fewer
labels.
That
was
on
the
basis
that
hey
almost
everyone
is
well
behaved
most
of
the
times
and
why
add
extra
process
for
people
to
handle
the
handful
of
exceptions
and
and
I
haven't
seen
any
reason
to
contradict
that
decision.
A
A
The
number
of
times
I
had
to
explain
to
a
cig
lead
where
we
were
in
the
release
process
or
even
what
the
release
process
looks
like
and
last
week
at
cube,
con
I
was
presenting
that
and
was
surprised
at
some
of
the
people
who
were
asking
me
questions
that
I
would
have
thought
like
everybody
knows
this,
so
I
think
communication
and
documentation
can
help
and
I
I
also
am
biased
here
towards
a
process.
Light
I
feel,
like
things,
are
working.
Ok,.
E
C
A
Need
like
some
little
USB,
Wi-Fi
LED,
something
to
send
out
to
all
the
sig
leads
that
like
starts
out
green
and
turns
yellow,
starts
strobing
red
on
their
desktop
or
something
there
was
actually
so
in
all
seriousness,
there
was
talk
of
at
the
point.
We
have
a
better
contributor
website
of
having
some
summary
information,
and
a
little
header
like
CI
is
awesome
in
green
CI
is
not
looking
good.
Where
are
we
in
the
release
phase,
just
some
little
sort
of
minimal
visual
dashboard
of?
What's
what
at
the
moment,
step.
C
C
E
A
A
Yeah
next
up,
then
I've
jotted,
some
notes
on
the
discussion
there.
I
guess
we
can.
It
maybe
can
go
over
into
github,
but
I
yeah
yeah.
So
I'd
mentioned
Jourdan
Liggett
with
respect
to
PST
the
project
security
team
and
then
also
the
working
group
LTS.
So
Jordan
is
engaged
in
the
discussions
around
LTS
and
one
of
the
very
first
things
that
we're
talking
about
it
was
like
s
and
LTS
is
support.
A
What
is
support
and
we
used
to
have
and
I
I
swear
it
used
to
be
there
in
cake,
community
or
somewhere
a
thing
that
said,
like
we
support
three
releases
for
nine
months
with
critical
bug,
fix
back
ports
and
things
have
shifted
around
and
moved,
and
that's
really
not
clear.
Actually,
today
what
our
support
stance
is.
A
So
a
lot
of
people
have
a
sense
of
it,
but
jourdan's
opened
a
PR
there
to
at
least
clarify
the
version
SKUs
and
upgrade
portion
of
what
we
do
today,
trying
to
keep
it
scoped
not
going
into
any
discussion
of
LCS
or
not
LTS.
Just
what
do
we
do
today
and
does
that
include
downgrade?
Is
it
just
upgrade?
What
are
the
version?
C
I
will
check
out
that
PR
I
linked
in
the
chat
that
the
doctor,
probably
thinking
of
that
references,
the
three
things.
It's
some
deep
URI
that
lives
in
a
design
proposals
directory.
How
on
earth
does
that
sound,
authoritative,
but
it's
the
one
that
I
have
been
linked
and
I
provide
as
a
link
anytime.
C
This
thing
comes
up,
so
I
am
happy
that
Jordan
is
surfacing
it
there's
a
there's,
really
a
like
a
Crete,
a
te
line
in
there
that
took
me
a
while
to
parse
in
the
context
of
conformance
tests,
where
there's
like
n
minus-1
compatibility
for
clients
and
then
n,
plus
or
minus
one
compatibility
for
the
API
server,
two
notes
to
allow
you
to
upgrade
forwards
and
backwards,
and
so
it's
that
API
server,
plus
or
minus
one
that
I
think
actually
translates
into
three
versions
or
what
it's
one.
Yeah.
C
That's
like
when
I
initially
read
that
I
thought
that
my
conformance
tests
needed
to
be
backwards
compatible
by
two
versions
it
turns
out.
They
only
need
to
be
backwards
compatible
by
one
because
of
the
client
expectations
so
like
I.
There
is
no
way
I
should
be
allowed
to
use.
Qtl
from
kubernetes
1.10
against
a
1.12
cluster
that
is
not
supported.
According
to
our
version,
skew
policy,
the.
A
And
then
this
I
guess
like
on
the
one
hand,
maybe
some
of
the
folks
on
call
might
be
wondering
why
we're
talking
about
this
here.
It
really
ends
up
impacting
the
release
team
quarter-to-quarter,
because
we
have
to
track
these
components,
cue,
questions
and
test
automation
and
make
sure
that
they're
actually
testing
what's
intended,
and
then
they
very
often
break
and
people
are
like.
Why
are
we
do
we
support
that?
We
don't.
C
D
A
Like
the
answer
to
be
no
just
for
the
reason
that
it's
under
Kay
website
I
would
prefer
the
website
to
pull
it
from
somewhere
else,
like
we've
got
deprecation
policy
in
the
versioning
document
that
Aaron
linked
off
in
it
is
the
both
of
ya
k.
Community,
like
I,
feel
like
that
should
cake
community
should
be
the
canonical
source
of
information
in
that
regard.
But
then,
if
we
do
that,
we
need
to
have
a
machine
convertible
way,
probably
to
have
it
tracked
on
a
website
or
something
it's
the
again.
A
C
A
So
we
have
also
just
we've
changed
up
the
meeting.
I
think
in
the
past,
we've
had
this
meeting
set
for
an
hour,
but
it's
currently
set
for
45
minutes
just
to
make
a
little
more
ability
for
people
to
like
have
a
drink
of
water
or
go
to
the
bathroom
and
things
their
date.
So
we've
got
10
minutes
left,
I,
guess
I
want
to
move
on
Nico.
You
had
something
you
want
to
talk
about
on
decisions.
F
F
F
For
example,
reflecting
on
my
recent
experiences
back
triage,
like
my,
the
handbook
of
they're
all
had
some
inconsistencies
and
we
created
some
miscommunications,
etc.
I
think
generally
putting
down
guidelines
overall
in
the
process
and
trying
to
follow
those
with
some
open
windows
for
discussions
between
not
so
sig
owner,
cetera,
so
yeah.
A
Yeah
I
definitely
want
to
see
again
that
we
think
about
living
documents
so
constantly
upgrading
the
role
handbooks,
but
then
also
bubbling
some
of
that
up.
Maybe
the
the
wording
to
make
sure
that
each
of
them
has
something
sprinkled
in
it
around
these
are
guidelines.
It's
still
pragmatic
talk
to
the
release
lead
and
your
your
peer
leads
to
to
sort
things
out.
I,
also,
really
like
the
idea
of
having
some
sort
of
examples
like
and
such-and-such
release.
We
ran
into
this
problem.
D
Yeah
I
mean
shouldn't
this
in
slack,
you
see
I,
think
this
is
where
the
shadow
training
and
then
the
shadow
having
to
select
it
and
meet
some
relevant
updates.
The
talk
before
they
become
the
lead
will
also
really
help,
because
that
way,
if
they
are
the
ones
who
are
going
to
be
taking
up
the
role
and
running
with
it,
then
they
are
on
both
of
the
rule
books
as
well,
but
yeah
I
agree
with
Miko
that
a
lot
of
those
those
decisions
are
just
made
on
a
case-by-case
basis
and
then
yeah.
D
C
C
D
C
E
Yeah
I
mean
there's
always
a
bunch,
every
code
freeze,
but
there's
no
way
to
do
it,
except
on
a
case-by-case
basis,
because
there's
always
a
whole
bunch
of
different
factors
going
on
right.
Like
oh
yeah,
we
need
to
do
this
because
it's
breaking
this
test,
but
that
requires
implementing
an
API
change.
Then
we
haven't
tested
it
effects
this
other
component
and
you
know
trying
to
decide.
There's
no
way,
there's
no
way
to
come
up
with
a
general
set
of
rules
that
would
allow
you
to
decide
on
all
of
those
cases.
I
will.
C
Say
one
of
the
plus
or
minus
things
here
is
we
initially
had
for
a
little
while
we
had
a
bot
that
was
going
through
an
auto
nagging
issues
that
didn't
have
the
appropriate
labels
applied
and
that
effectively
blew
up
everybody's
inboxes
and
was
ignored.
I
think
one
of
the
things
we
have
learned
for
better
or
for
worse,
largely
thanks
to
the
efforts
of
folks
like
ice
or
Guinevere
or
Josh.
Is
that
an
actual
human
being
going
and
poking
somebody
gets
far
more
reception
than
anything
else
as
manual
as
that
is.
C
It
seems
to
be
the
one
thing
that
people
pay
attention
to
and
get
as
a
signal
that,
like
oh
right,
somebody's
actually
looking
at
this
I
should
probably
do
something
now.
So
that's,
unfortunately,
why
it's
like,
as
clear-cut
as
we
can
try
to
make
the
labels.
There
does
often
need
to
be
some
kind
of
periodic
discussion
or
reminder
I.
D
Think,
at
least
from
my
experience,
just
ones
that
I
really
struggle
me
in
college.
Oh,
but
it's
it's
I
know
it's
freeze,
but
it's
a
very
simple
change
and
it's
the
PR
is
already
like
you
know
interview.
It's
very
close.
Those
are
the
things
you
know.
People
tend
to
use
to
get
things
in
during
freeze.
Well,
then,
I
have
to
revert
and
say
no
it's
only
if
it's
like
super
critical,
an
urgent,
so
it
does
come
across
as
being
like.
D
A
A
D
C
I
would
also
say,
like
I'm,
really
only
gonna
feel
comfortable
being
a
lead
if
I
have
a
shadow
to
go
along
with
me.
History
has
taught
me
that
random
things
can
eat
up
my
attention
from
time
to
time
and
I
need
somebody
that
I
can
rely
on
to
help
with
communication
for
sure.
If
it's
just
me,
I'm
not
sure
that
it
would
be
fair
to
the
community
for
me
and
Neela
to
shoulder
that
burden,
because
I
don't
think
I
would
do
a
great
job.
C
Honestly,
hadn't
even
I'd
forgotten
this
process.
What's
going
on
right
now,
I
had
actually
planned
on
getting
back
to
the
community
until
my
brain
understood,
which
time
zone
it
was
in
so
I,
haven't,
put
a
lot
of
thought
into
it.
You
can
kind
of
consider
this
a
call
if
anybody
here
is
super
interested
in
it.
Otherwise
I
can
start
hooking
it
around
and
see
if
I
can
come
up
with
anybody,
but
just
since
I
hadn't
reply
on
the
issue
or
anything,
that's
where
I'm
coming
from
yeah.
C
A
F
A
Think,
technically,
the
documentation
says
you're
responsible
for
handing
it
over,
but
no
we
are
collaborative
and
we
try
to
figure
out
what
the
right
path
for
it
is
certainly
if
you're
wanting
to-
and
this
is
one
of
the
things
that
hasn't
been
clear-
maybe
at
times
it
there
is
no
mandate
that
you
must
move
on
after
one
quarter
and
the
number
of
us
really
want
to
see
more
continuity,
less
immediate
turn.
Every
three
months,
yeah.
C
D
A
A
C
C
D
D
E
A
E
B
A
I've
had
a
bunch
of
people
ping
me
who
said
if
this
is
a
team
I'd
like
to
get
involved
and
be
mentored
and
figure
out
how
I
can
be
participating
in
that
team?
Pretty
much
everybody
is
like
I
can't
just
do
it,
I
can't
own
it
and
I
think,
especially
when
people
think
about
owning
that
for
nine
months
it's
a
hard
commitment,
so
I'm,
really
enthused
by
the
number
of
people
who've
expressed
interest
in
participating.
If
it's
a
team.
A
A
Yes,
that
is
actually
listed
there
and
we
were
kind
of
out
of
time
to
talk
about,
but
I
actually
think
that's
really
important
that
we
discuss
that
and
clarify
that
in
the
past,
shadows
have
sort
of
been
like
volunteered,
and
especially
in
the
last
couple
cycles.
Steven
was
like
okay,
you're,
the
shadow
but
I
really
believe
Josh
and
I.
We
talked
about
this
last
week.
We
need
to
have
a
solid
conversation
between
leads
and
prospective
shadows,
and
this
isn't
a
job
interview.
A
I
think
some
people
got
hung
up
on
like
the
term
like
we
should
interview
the
prospective
shadows.
This
is
just
about
having
a
conversation,
because
this
is
a
mentor-mentee
relationship.
What
are
the
time
commitments?
What
are
the
role
expectations?
Have
you
read
the
handbook?
What
are
your
thoughts?
Do
you
think
you
can
do
this?
Are
you
willing
to
commit
for
the
time,
duration
and
the
number
of
hours
a
week
and
those
sorts
of
things
so
that
we
can
make
this
successful
and
you
can
successfully
learn
and
I?
E
Yeah
one
and
some
of
it
and
some
of
it
actually
comes
down
to
mechanics
like
I'll,
tell
you
four
CS
signal
I
had
for
shadows,
volunteering
I
know:
I
could
only
reasonably
mentor
two
people
and
out
of
the
shadow
volunteers,
I
had
one
in
Europe
and
one
in
China
and
since
I'm
in
California.
There's
just
no
way.
I
could
make
that
work,
and
so
I
had
to
disqualify
either
the
European
or
the
Chinese
person
and
asked
them
to
Reval
Interior
114.
E
D
I
think
that's
completely
reasonable
and
credits
to
Josh,
especially
for
piloting
this
for
CGI
in
113,
and
is
that
a
really
driving
shadow
team,
and
then
we
are
going
to
graduating
to
become
a
lead,
is
a
sign
of
that.
So
I
agree.
It
shouldn't
be
too
restrictive,
but
basic
question
and
having
the
dialogue
with
the
lead
is
definitely
useful
and
it
must
be
it's
also
critical
before
they
get
signed
on
a
shadow
sphere.
A
C
Well,
my
counterpoint
might
be
that
I
think
the
the
time
expectation
time
commitment
would
be
a
great
thing
to
have
written
down
this
sort
of
yeah.
All
of
that
up
front
you'll
find
I
tend
to
be
that
the
guy
who
always
advocates
for
less
process
and
less
human
interaction,
although
I
continually,
do
espouse
the
need
for
humans
to
interact
I
like
machines
to
do
the
boring
stuff
so,
and
sometimes
I
worry
about
the
sheer
like
glow
in
hand.
I
worry
about
the
sheer
volume
of
humans
and
process
that
this
team
has
grown
on
the
other.
C
This
is
one
of
the
few
groups
of
people
who
are
actually
consistently
focused
on
mentorship
as
a
responsibility
of
your
role,
which
is
generally
the
way
it
works
in
most
companies
that
I've
worked
at
as
you
grow.
You
bring
up
others
with
you,
I
think
it
should
be
no
different
in
the
contributor
ladders
so
kudos
to
y'all.
For
thinking
about
that
when
I
think
few
others
things
do,
or
at
least
I've
documented
process.
These
words
that
I've
seen
yeah
yeah.
E
I
mean
I
will
say
part
of
this,
so
so
there's
a
questionnaire
draft
in
the
issue
and
as
part
of
the
questionnaire
draft,
obviously
whoever's
lead,
would
have
to
be
figuring
out
a
what's
the
approximate
time.
Commitment
for
this
and
I
think
copying
that
information
into
the
release
handbook,
if
it's
not
already
there,
which
it
is
in
a
few
of
the
handbooks
but
probably
not
most
of
them,
would
be
really
good.
C
A
C
C
But
like
this
was
the
reason
I
wrote
down
the
list.
I
started
the
CI
signal
playbook
in
the
first
place,
when
I
served
that
role
I
realized,
like
nobody,
writes
down
what
they
do
or
how
they
do
it
and
the
only
way
I
get
myself
out
of
this
mess
is,
if
I
do
that,
so
that
I
can
then
hand
it
off
to
somebody
else.
Yep.