►
From YouTube: Kuberentes SIG Release Meeting for 20230829
Description
Kuberentes SIG Release Meeting for 20230829
A
Everyone
welcome
to
the
Tuesday
August
29th
Sig,
release
weekly
meeting.
This
meeting
is
being
recorded
and
we'll
be
available
available
on
YouTube.
This
meeting
is
covered
by
the
cncf
code
of
conduct.
So
please
be
mindful
of
the
things
you
say
and
by
participating,
you're
agreeing
to
abide
by
the
cncf
code
of
conduct,
I
think
on
the
agenda
today
we're
going
to
go
through
the
rest
of
the
Retro
from
sorry
from
the
release
team.
B
Back
we've
got
two
items
and
I
think
they're
they're
fast
enough
that
we
should
just
clear
them
and
then
and
then
head
into
the
Retro
items.
So
the
first
one
I
don't
know
if
Veronica
is
on
the
call.
I
don't
see
Veronica
so
really
quick
for
release
managers.
You
will
have
received
a
check-in
survey.
This
is
just
to
see
how
you're
doing
the
items
that
you're
working
on.
B
C
So,
very
quickly,
from
my
side
as
well,
I
am
planning
to
follow
the
meeting
next
week
about
the
open,
build
service
and
our
new
packages
infrastructure.
There's
a
total
for
the
time
that
we
should
meet
a
place
for
sigalese
leads
and
release
managers.
Please
feel
it
so
that
I
can
know
by
the
end
of
the
night
by
the
end
of
this
week.
What
time
works
for
you
all
that
I
can
schedule
the
meeting
cool.
A
I
added
one
more
related
to
the
package
of
stuff.
We
are
going
to
accelerate
our
deprecation
of
the
Google,
managed
repository
register,
sorry
repositories
for
devs
and
RPMs
to
be
on
the
lookout
for
some
Communications
around
that
we're
trying
to
finalize
when
we're
going
to
do
this.
But
it's
going
to
be
September
or
October
when
we
stop
doing
the
packages
to
the
Google
owned
infrastructure.
So
we're
going
to
send
a
lot
of
comms
out
you'll
see
a
wave
of
those
things
rolling
out
pretty
quickly.
Once
we
get
some
confirmation.
A
D
D
So
that's
good
and
then
priyaka
capture
the
feedback
from
the
Retro
into
her
release,
leak
checklist
there.
So
there's
a
few
PR
that
is
in
progress
from
enhancements
and
other
documentation,
mostly
enhancement
and
also
the
stuff
on
merging
yeah.
So
the
next
up
we
got
Stefan
merging
CI
signal
and
Bug
triage.
D
D
D
A
Yeah
so
I
think
we
have
done
this
in
the
past.
I,
don't
think
we
have
a
documented
process
for
it,
but
we
have
dropped
people
from
the
releasing
when
they
were
not
responsive,
and
then
we
had
other
folks
kind
of
fill
in
come
in
pick
up
the
burden
if
needed.
So
it's
definitely
something
we
should.
We
have
done
and
I
think
it's
something
we
should
do.
A
I
think
participating
in
the
early
seam
requires
you
to
be
involved,
and
it
it's
not
a
it's
not
a
thing
for
you
to
just
sign
up
and
do
a
thing
and
expect
that
you're
going
to
get
access
to
all
the
to
things
later
on
and
and
it's
like
a
pathway
for
it.
It's
doing
work
right
like
you,
are
participating
and
helping
their
at
least
be
successful
and
if
you're
not
participating,
we
should
remove
you
from
the
the
team.
That's
my
impression
and
that's
what
we
did
in
the
past.
B
B
You
know
you
know
Josh
I'm,
looking
at
you,
I
think
you
you've
done
some
some
initial
work
on
the
on
the
the
you
know:
release
team
applications
and
and
the
and
the
announcements
of
them
the
there
are
a
lot
of
people
on
The
Scholar
that
have
had
to
deal
with
like
recruiting,
interviewing
and
and
getting
people
the
appropriate
privileges
for
this
team.
It
is
work
to
onboard
and
off
board.
It
is
work
to
be
on
the
team.
B
It
is,
you
know
it
is
work
to
stay
on
the
team
and
and
continue
moving
up
the
roles,
and
it
is
not
fair
to
people
who
are
actually
doing
the
work
to
be
recognized
in
the
same
venue
that
as
people
who
are
not
doing
the
work,
I
want
to
call
out
for
this.
This
item
that
I
don't
think
that
should
just
be
a
documentation
and
discussion
around
Shadow
on
responsiveness
leads,
should
be
looked
at
the
same
way.
D
E
E
Obviously
super
frustrating
and
hard
to
hard
to
do,
and
so
I
guess
what
I
want
to
kind
of
I
want
to
kind
of
bias
towards
what
could
be
a
solution
for
this
I
would
love
as
an
idea
if
we
could
discuss
it.
If
it
doesn't
exist
already,
is
there
a
stank
stack
rank
of
Shadows,
who
can
step
in
for
a
lead
that
isn't
responsive
so
that
we
can
still
work
on?
You
know
working
on
the
the
release,
things
that
need
to
happen.
E
I
want
to
pull
out
cat
big
thanks
to
you
for
this
recent
release.
That
I
believe
that
that
kind
of
happened
this
this
time
until
that
that
League
was
was
available
for
docs,
but
that
was
and
a
suggestion
I
have
as
something
that
maybe
could
happen
where
a
lead
shadow
gets
ideas
around
or
training
around
needing
to
step
in,
if,
for
example,
in
lead,
does
need
to
be
away
from
the
release.
D
F
Yes,
thank
you
and
thank
you
Natalie
yeah.
That
is,
that
is
in
fact,
what
happened
unfortunately,
but
so
there
is
a
GitHub
issue
open
for
this,
which
I
will
grab
and
Link,
because
I've
been
growing
about
this
for
the
last
like
three
releases
or
so.
But
it
is
true
that,
like
unofficially,
there
is
a
way
to
remove
an
an
active,
Shadow
or
potentially
an
inactive
lead.
It's
just
that
it
isn't
documented
anywhere
and
because
there's
no
Handover
from
sub
team
lead
to
sub
team
lead.
F
The
incoming
sub
team
lead
if
they've,
never
let
a
sub
team
before
don't
know
that
there
is
this
undocumented
process
for
removing
an
inactive
Shadow,
and
it
I
think
this
is
contributing
to
some
release
team
member
burnout,
because
the
result
is
always
that
the
sub
team
leads
takes
up
the
slack
for
the
missing
shadows
and
it
kind
of
just
or
you
have
the
situation
I
ended
up
in,
which
is
where
I
picked
up
a
slack
for
a
missing
lead
and
it
kind
of
gets
messier
than
it.
It
should
be.
F
But
like
the
the
larger,
this
project
gets
the
more
important
I
think
it
is
that
we
address
this
in
writing
and
also
make
it
clear
to
shadows
and
leads
that
if
they
get
overwhelmed,
they
can
step
down
without
penalty
right
like
that.
That
part
should
be
documented
really
thoroughly
as
well,
I
think,
but
if
we
can
figure
out
like
what
the
actual
parameters
are
for
deciding
that
somebody
is
unresponsive
enough
to
be
removed
against
their
will.
I'm
I'm
happy
to
open
a
PR,
but
we
got
to
decide
what
the
actual
rules
are.
D
G
So
when
we
started
the
shadow
program,
it
was
pretty
normal
for
Shadows
to
drop
out
one
of
the
reasons
why
somebody
would
try
things
out
as
a
shadow
was
they
thought
they
could
manage
the
time
commitment,
but
they
weren't
sure,
and
that
was
actually
why.
Originally
there
was
only
one
Shadow
per
leap
and
we
moved
to
two
Shadows
per
lead
specifically
because
we
were
getting
about
50
dropouts
and
we
were
expecting
50
dropouts,
like
that
was
a
conversation
we
had
when
Shadows
were
recruited
right
to
actually
specifically
tell
the
Shadows
hey.
G
G
That
was
pretty
much
just
up
to
the
discretion
of
the
individual
section
lead,
although
they
usually
consulted.
Whoever
was
the
release
team
lead
at
the
time
after
that
we
introduced
the
Emeritus
advisor
and
the
Emeritus
advisor
got
involved
in
helping
dismiss
Shadows
that
were
basically
not
showing
up,
because
they
were
basically
there
to
support.
The
section
leads
mainly
around
the
shadow
of
the
program,
so
I
think
we
could
actually
reintroduce
some
of
that.
G
D
Okay,
thank
you.
Josh
I,
think
I.
Think
the
50
rates
is
harder
for
us
now
because
of
the
size
of
number
of
enhancements
that
we
get.
For
example,
if
the
enhancement
team
that
is
like
four
to
five
Shadows
became
half
of
what
it
is,
it
just
becomes
a
lot
of
work,
so
I
don't
have
a
good
answer
to
like
how
do
we
replace
Shadows?
Is
that
an
option,
but
just
keep
that
in
mind?
Besides,
we
are
now
and
Steven,
you
have
your
hand
up.
B
Yeah,
so
I
knew
she
was
going
to
do
the
but
I
I
know
it's
not
in
the
history.
Is
that
we've
discussed
how
many
Shadows
is
this
addition
amount
of
Shadows
for
Ailee
to
have
and
I
mean
in
the
position
that
you
you
should
have
as
many
as
you
think
you
can
manage
reasonably
and
be
effective
to
do
the
work
there
have
been
limits
proposed
in
the
past.
B
I
I
think
you
know,
the
the
hard
limit
is
is
maybe
four
to
five
right
and
even
that's
not
a
hard
limit,
but
you
know
I
think
it's
discuss
how
many,
how
many
is
the
right
number
and-
and
that
is
not
necessarily
in
question
I-
just
want
to
call
up
Josh.
You
left
a
note
about
the
not
at
all
accurate,
I,
think
the
what
people
are
specifically
talking
about
is
is
the
documentation
for
how
to
do.
The
thing
has
not
been
has
has
not
existed.
That
is
true.
B
B
I
do
feel
that
it's
kind
of
you
know
I,
think
we've
been
talking
about
like
backups
and
how
do
we?
How
do
we
find
a
backup
and
like?
What's
the?
What's
the
you
know,
what's
the
graceful
degradation
mode
for
the
release
team?
Should
we
have
multiple
losses
of
Shadows
right
and
and
that's
a
little
hard
to
answer
only
because
I
think
people
have
been
proposing
a
and
there's
even
a
cap
for
it?
That
was
both
stable
roster
for
the
release,
team,
right
and
and
so
much
of
what
goes
into
stable.
H
Yeah
that
segues
into
what
I
wanted
to
talk
about
as
well,
which
is
the
back
below
process
I,
think
having
like
a
warm
pool
of
folks
who
have
been
existing
shadows
in
the
past,
even
if
they're
not
necessarily
like.
If
we
just
have
a
group
of
people
we
can
reach
out
to
and
ask
about
their
time
availability.
That
might
be
something
we
can
start
with,
because
what
I
worry
about
is
if
we
were
to
do
something
like
stack
rank
that
other
folks
that
weren't
selected
for
the
release
team
in
the
first
place.
H
That
means
we
might
have
to
spend
a
lot
of
time,
onboarding
folks,
very
late
into
the
process,
which
means
we're
kind
of
redoing.
Everything
that
we
already
did
earlier
in
the
release
for
the
first
batch
of
Shadows,
so
I
know
that
stable
roster
is
a
bit
of
a
challenge,
but
I
would
still
advocate
for
trying
to
figure
out
having
some
sort
of
warm
pool
of
backups
to
step
up
just
because
slotting
folks
in
towards
the
end
of
a
release.
H
H
A
A
We
don't
have
a
hot
like
a
hot
list
of
folks,
but
we
technically
do
because
we
have
the
list
of
everybody.
That's
done
the
job
in
the
past
and
we
can
go
back
through
them
and
ping
them
to
say.
Do
you
have
availability
to
come
back
and
help
us
and
that's
what
we've
done
so
Karen
Chu
came
back
to
do
comms
in
One
release.
She
hadn't
been
around
for
several
several
releases,
but
she
was
capable
capable
of
coming
back
and
doing
that.
A
We
didn't
have
a
Emeritus
advisor
person
that
was
around,
so
we
were
able
to
go
back
through
release,
League
shadows
and
help
have
one
of
them
step
up
in
the
previous
instances
where
we
did
have
to
drop
Shadows,
at
least
in
my
experience.
When
we've
done
this,
we
we
did
just
pick
people
from
the
list
of
people
that
had
applied
because
it
happened
fairly
early
on
in
those
scenarios.
A
Generally,
we
you
know
like
we
would
pick
just
backfill
from
there.
We
also
did
have
to
replace
release,
leads
or
sorry
section
leads.
During
the
release,
Cycles
like
when
payush
passed
away,
we
replaced
him
with
a
shadow
from
that
team
that
had
been
doing
some
of
the
the
work
so
I
definitely
think
we
have.
We
have
a
set
of
people
that
we
can
go
to
I.
Think
what
we
need
to
focus
on
is
knowing
that
context,
so
we
know
where
to
go.
Look
for
folks.
A
I
definitely
also
wanted
to
add
I
think
that
we
need
to
make
sure
that
the
Marist
advisor
is
checking
in
more
on
some
of
these
things
to
make
sure
that
Shadows
are
engaged
and
they're
around
taking
a
pulse
and
making
sure
that
like
did,
they
come
to
the
orientation
meetings.
If
you
didn't
do
that,
then
that's
probably
a
qualifying
thing
something
we
can
enumerate
a
lot
of
these
things,
I'm
happy
to
share
more
about
what
we
did
in
previous
Cycles.
D
Okay,
yes,
I
do
want
to
ship
gear
into
looking
at
exactly
the
criteria
of
removing
folks,
because
I
think
that
is
very
blurry
right
now.
So,
for
example,
the
dog
sleep
was
not
responsive
to
me,
but
they
would
be
responsive.
You
know
a
couple
days
later
and
saying
they're
on
the
work
you
know
in
that
case
when,
when,
among
that
line,
do
we
remove
them
I'm,
not
sure
if
it
has
their
hand
up
first
but
I'm
gonna
call
it
a
cat.
Oh
cat,
just
remove
her
hands
to
Stephen.
B
But
I
was
going
to
segue
from
cat's
thing,
but
I
I
think
you
know
so
so
one
I
think
having
the
prescribing
the
methodology
right,
I.
Think
for
if
you
have
been
a
if
you
are
currently
a
safe,
lead
in
some
capacity
or
you're
a
project
owner
or
have
have
been
on
the
release
team
before
you
kind
of
have
a
a
rough
methodology
about
how
to
to
dig
for
potential
Replacements
right.
That
again,
that's
a
thing.
That's
not
documented,
and
we
should
do
that.
B
The
I
think
I
I
agree
on
on
poking
at
the
the
EA
points,
because
the
you
know
to
catch
Point
earlier.
We
we
have
and-
and
this
is
kind
of
a
point
that
I
bring
up
in
every
retro
like
this
is
a
thing
you
know
like
this
thing,
or
you
know
thing
why
thing
X
has
been.
You
know
adjudicated
before
it,
you
know
and
and
it
hasn't
and
it's
fallen
through
the
cracks
across
the
release.
B
E
Yeah
to
answer
your
question
of
you
know
what
what
was?
What
are
the
kind
of
criteria
for
removal
do
we
have?
This?
Is
me
asking
questions
knowing
that
I
haven't
read
all
of
the
every
single
release
handbook,
but
do
we
have
kind
of
how
available
you
are
requirements
in
terms
of
responsiveness,
like?
Is
that
something
we
can
sit?
F
Some
Shadows
do
genuinely
apply
with
I
can't
attend
any
those
people
do
not
get
selected
for
the
release
theme,
usually
because
you
have
to
you-
have
to
be
there,
but
I
I
would
suggest
that,
because
some
sub
teams
are
doing
very
very
little
in
the
early
half
of
the
release
or
in
the
latter
half
of
the
release
it
there.
There
should
be
some
kind
of
expectation
that
you
don't
miss
like
two
weekly
meetings
in
a
row
without
talking
to
your
lead
about
it
right
because,
obviously,
like
happens,
we
all
have.
F
We
all
have
lives
you're,
going
to
miss
a
meeting
every
once
in
a
while
I
don't
make
the
make
it
to
all
of
them
either.
But
if
you're
not
talking
to
your
lead
about
it,
if
you're
not
actively
communicating,
why
you're
not
making
it
into
the
meetings,
then
we
have
no
way
to
say
whether
or
not
you're
going
to
actually
do
the
work.
D
Okay,
yeah
I
really
appreciate
that
first
idea
there
so
I'm
gonna
ask
that
we
should
gears
into
the
criterias
of
removing
unresponsive
Shadows.
So
what
does
it
mean
to
be
unresponsive,
not
doing
their
roles
and
keep
in
mind?
This
looks
like
differently
for
different
teams,
so
for
enhancement
there
early
on,
so
it's
easier
to
tell
versus
docs
and
com.
You
know
they
might
go
AFK
for
the
first
half
of
the
release
on
Stephen.
B
B
If
you're
a
lead
who
is
not
getting
support
from
your
shadows,
you
should
be
same
same
path
right.
The
Emeritus
advisor
releasing
lead,
releasing
lead,
Shadows,
I,
think
part
of
the
responsiveness
there's
a
component
of
responsiveness
that
is
is
also
around.
This
is
a
bi-directional
relationship
right
and
in
every
sense
of
the
word
right.
So
like
you
are,
you
should
be
polling
for
feedback
from
your
team.
You
should
be
polling
for
feedback
from
your
lead
right,
so
that
means
leads
working
with
leads
leads
working
with
the
lead.
B
D
E
So
yeah
I
think
so
too
and
I
think
so
yeah,
firstly
to
also
kind
of
say
that
loud
I
feel
like
it's
implied,
but
just
in
case
response.
This
is
all
async
right,
so
this
idea
of,
if
you
check
in
check-ins,
are
happening
in
that
async
manner,
but
yeah
I
think
it's
I
think
that's
it's
a
great
point
to
call
out
where
we
in
docs
actively
called
on
you
as
you
and
Leo,
to
be
like
hey,
helps
out.
E
We've
got
someone
responsiveness
going
on
so
like
that
was
our
escalation
path
right,
but
I
think
we
I
will
say
I
think
as
as
a
Sig
chair
I
think
we
often
don't
look
at.
We
often
just
assume
things
are
going.
Okay,
because
we
get.
We
look
at
the
updates
in
the
release
team
meetings
to
get
our
updates
for
our
for
our
community
meetings
and
because
we
saw
green,
green
Green
all
there.
That
I
think
that
specific
scenario
is
how
that
happened,
and
so
okay
just
wanted
to
call
out.
D
Yeah
and
I'm
just
reading
the
comments,
Jeremy
said
that,
in
the
event
that
the
deadline
is
not
approaching,
it's
just
green
all
the
time.
I
part
agree
with
that.
I
think
the
the
failure
that
happens
at
1.28
is
like
the
maintenance
task
is
not
getting
done,
like
updating
the
branches
going
to
sick
talks
meetings
and
that
to
me
should
have
been
a
yellow,
even
if
that
one
is
not
approaching,
but
because
the
lead
is
responsible
for
updating
the
status
and
doing
all
these
things.
D
E
Really
agree
by
the
way,
yeah
totally
agree.
I
think
also
is
just
maybe
lack
of
understanding
that
the
branch
syncs
are
is
also
a
signal
for,
if
they're
not
being
completed,
it's
yellow,
like
just
little
things
like
that,
that
you
know,
may
not
have
been
an
obvious
status
updated
for
docs,
because
yeah
I
don't
know,
but
you're
right.
D
Okay,
so
since
we're
already
on
the
removing
lead
train
of
thought,
what
would
that
process
look
like
like?
Do
we
want
to
have
like
a
strike
system?
How
responsive
do
they
have
to
be?
Because
we
do
have
a
week,
that's
released
here
in
Australia,
and
so
they
would
take.
You
know,
12
to
24
hours,
to
get
back
to
me
and
by
the
time
I
ping
them
again.
It
would
take
another.
You
know
12
to
24
hour
stream,
to
get
back
to
me,
yeah,
so
I
think
removing
leaders
is
quite
difficult.
G
D
G
I
mean
the
role
leads,
need
to
attend
the
meetings
or
send
a
proxy
and-
and
we
have
had
ones
in
the
past
where
it
was
all
proxies
because
of
their
time
zone
the
and
and
they
need
to
make
their
deadlines.
Basically,
if,
if
you
know
every
rule
has
deadlines
and
if
they
start
missing
those
deadlines,
that's
the
lead
not
doing
their
stuff.
D
Okay,
thank
you,
Jeremy
said:
do
we
need
to
discuss
it
in
this
retro
about
removing
the
I
do
want
to
have
like
kind
of
a
general
understanding
of
that?
What
that
looks
like
because
me
even
also
relief
lead,
I,
don't
know
that
was
an
option
like
if,
if
that's
a
conversation,
I
should
have
about
removing
them
and.
A
I
think
everybody
agrees
that
that's
the
thing
that
should
be
done
if
they're,
not
responsive,
I,
think
arguing
about
the
specifics
like
what
are
the
the
five
things
that
have
to
happen
to
remove
them
in
this
is
not
a
not
a
super
good
use
of
time.
That
was
just
my
suggestion,
like
I
think
we
should
totally
hash
that
out.
I
think
we
definitely
largely
agree
that
there
is.
There
should
be
a
process
for
removing
leads
that
are
unresponsive.
Anybody
that's
unresponsive
on
the
team.
There
should
be
a
way
to
remove
them.
B
Yeah
so
I
I
I,
you
know
again
to
kind
of
KF.
Bear
me
I,
don't
think
we're
going
to
solve
that
in
this
meeting
and
we've
got
a
bunch
of
items
to
go
through
I.
Think
if
an
issue
does
not
exist,
we
should
create
one
and
talk
through
what
the
criteria
needs
to
be.
It's
definitely
some.
We
need
to
figure
out
what
the
escalation
paths
are:
timeout,
Etc
et
cetera.
What's
the
process
for
for
removal
and
replacement,
but
I
don't
think
we're
going
to
solve
it
in
the
next
10
minutes.
D
Okay,
all
right
that
sounds
good
to
me.
I've
appear
open
for
these
two
things,
but
I
think
I'm
going
to
open
an
issue,
so
we
can
have
a
conversation
about
it.
Is
there
anything
anyone
would
like
to
bring
up
about
the
process
or
escalation
every
moving,
Shadows
or
lead
before
we
move
on
to
the
next
item.
D
D
A
A
A
sink
like
between
cigarettes,
leads
and
early
seem
leads
just
to
make
sure
that
we
convey
the
same
things.
Even
if
they're
like
it's
okay,
to
remove
people,
it's
okay
to
reach
out
it's
okay
to
do
XYZ!
We
used
to
actually
go
to
all
of
like
enhancements
at
least
used
to
go
to
all
of
those
things,
and
it
is
definitely
hard
to
like
to
make
sure
you
hit
all
those
meetings,
because
there
are
so
many
of
them.
D
D
That
I
will
copy
and
paste
the
link
to
regarding
creating
a
different
templates
for
sick
docs
and
release
T
release
team
meetings
for
Content
docs
team,
and
then
one
item
that
Leo
and
I
talked
about
is
instead
of
going
to
at
the
end
of
every
really
team
meeting,
we
would
go
to
the
project
board
on
GitHub
and
see
what
we
could
do.
We
don't
really
do
that
anymore
and
it's
kind
of
out
of
date
instead
I
propose.
D
We
look
at
the
upcoming
deadlines
to
make
sure
that
we're
all
sync
on
the
next
deadline
and
yep
Leo's
next
point
is
to
have
a
release.
Team
sync
between
leads
and
I.
Think
Jeremy
does
what
you
mentioned
there
yeah.
We
also
have
two
other
points.
First,
is
release
team
lead
Handover,
make
it
more
thing.
Currently
it's.
It's
informal
and
then
I'm.
B
Think
that's
that's
also
bi-directional
like
if
you're
not
seeing
these
people
show
up
like
we
announced
to
you
who
these
people
will
be
if
you're
not
seeing
them
show
up
at
your
meetings
like
please
let
us
know
as
well
and
for
the
release
review,
release
timeline
at
the
end
of
the
meeting,
I
I
believe
in
meetings
that
have
agendas,
I
believe
in
meetings.
That
kind
of
like
are
moving
towards
some
deliverable
or
some
set
of
deliverables.
B
If,
like
the
meeting,
should
be
structured
around
the
deliverables
that
are
coming
up
right,
the
deliverable
at
the
end
of
the
gate
is
we
have
a
release.
The
publish
to
announce
to
discuss
every
meeting
should
be
in
service
of
that
right.
So
so
the
meetings
should
be
structured
around.
What
are
the
upcoming
deliverables
right?
Not
just
the
status
checks,
but
also
what
those
status
checks
mean
in
it
with
respect
to
how
all
of
those
those
roles
work
together
right,
so
I,
I'm,
agreeing
I'm
agreeing
that,
like
the
release
timeline,
should
be
reviewed.
B
H
I
think
that
there's
that's
a
great
idea,
I
would
say
from
past
releases.
There
hasn't
been
enough
continuity
between
the
previous
lead
and
the
current
lead
I
think
it's
also
a
challenge
when
the
current
lead
maybe
doesn't
know
to
ask
for
help
or
doesn't
know
what
they
don't
know
and
I
think
it'd
be
nice
to
have
an
opportunity
to
coordinate
with
them
more
directly
rather
than
just
async
over
over
slack,
because
that's
I
know
what
I've
done
in
the
past.
E
Am
I
one
addition
to
that
would
be
to
add
a
couple
of
the
returning
Shadows
to
that
Handover
as
well.
So
it's
not
just
lead
and
Lead
get
a
couple
of
the
Shadows
in
there
too.
So
that
again,
if
we
are
possibly
coming
to
that
point,
where
a
replacement
needs
to
happen,
there
has
been
that
Handover
as
well.
There's
been
as
much
handovers
possible.
Of
course,
that
may
not
always
be
possible,
so
the
minimum
should
be
lead
and
Lead,
but
I
think
a
couple
of
the
returning
Shadows
being
there
too
could
be
helpful.
F
D
B
Yeah,
so
just
calling
out
the
whole
bi-directional
thing
again
when
you
start
on
the
release
team,
you
should
have
an
eye
if
you're
shadowing,
you're,
you're,
shadowing
you're,
learning,
you're
picking,
ups
and
you're
picking
up
some
stuff,
you
should
kind
of
take
stock
and
and
think
about
like
what
your
intent
is
with
the
role
right.
If
that
intent
is
to
lead,
you
need
to
be
making
steps
towards
that.
If
you
were,
if
you
are
currently
a
lead,
you
should
have
an
eye
towards
succession
who's
going
to
replace
you.
B
How
they're
going
to
do
that
and
and
I
think
part
of
succession
is
building
up
enough
context
in
your
in
your
shadows,
so
that
they
can
execute
the
role
without
you
right.
If
you
are
not
doing
that,
that
is
I'll
say
explicitly.
That
is
part
of
the
role
Shadows
you
should.
You
should
be
extending
yourself
up
and
and
around
the
responsibilities
of
the
lead.
As
far
as
you
can
I,
you
know,
I
I
think
you
know
when
I
was
the
reason
I.
B
B
D
E
D
Okay,
all
right
achara,
if
you're
still
around
I,
know
it's
probably
late
to
wrong
where
a
Target
is
I.
Just
saying
earlier,
okay
Trevor
mentioned
that
in
health,
my
team
is
working
on
adding
what
statuses
mean
in
their
handbook
and
he
links
the
issue
there.
So
thank
you,
atarba,
okay,
and
that
reached
the
end
of
our
meeting
on
the
dot
and
also
the
end
of
our
agenda.
A
E
A
A
All
right,
I'll
reiterate
what
Stephen
said
earlier.
Everybody
should
feel
totally
open
to
come.
Talk
to
us
talk
to
anybody
kind
of
in
the
hierarchy
of
things
within
the
release
team
and
say
if
you
run
into
any
problems
or
you
have
any
concerns
or
questions
we're
all
around
to
to
answer
and
and
to
talk
about
things
so
just
wanted
to
Echo
that
point
one
more
time.
G
A
G
Yeah
well,
and
some
of
the
stuff,
like
I,
didn't
actually
think
about
it
because
of
the
language
that
was
used
for
proposing
this,
but
basically
treating
previous
release.
Teams
as
a
pool
of
backfilling
recruits
is
something
we
always
did,
because
that's
how
I
ended
up
being
CI
lead
for
113,
because
the
CI
lead
had
to
quit
due
to
massive
personal
problems,
and
it
happened
early
enough
that
they
hadn't
trained
any
of
their
Shadows.
So
they
needed
to
slot
in
somebody
who
already
had
experience.
F
I
mean
like
it's
that
or
like
you
just
reach
out
to
anybody.
Who's
been
a
shadow
for
that
team
in
the
last
year
in
the
last
like
four
or
six
releases
whatever,
or
what
the
sub
team
leads
select
like
their
actual
Shadows
at
the
beginning
of
the
cycle
and
they
select
a
B
team
and
then
maybe
we
have
to
onboard
a
B
Team
like
that
is
a
huge
yeah
pain
in
the
ass
and
that's
not
I.
Don't
think
that
that's
reasonable,
especially
since
I
don't
know
about
y'all,
but
sometimes
I
have
a
hard
time.
F
It's
very
persistent
to
to
a
point
where
it's
like
it's
pretty.
It's
pretty
inappropriate
and
I
have
told
them
both
that
it's
not
appropriate
and
that,
if
you're,
not
if,
if
you
are
sending
other
sub
team,
leads
messages
like
this.
This
is
why
you've
been
rejected
for
the
release
team
five
times
like
I'm,
not
really
sure
what,
if
there's
something
in
the
water
or,
if
like
Mercury's
in
retrograde
or
whatever,
but
I've
never
had
that
before
and
I've
got
two
of
them
right
now.
So.