►
Description
Kubernetes Release Team Meeting (Retrospective part II) for 20220831
A
This
meeting
is
being
recorded,
hey
folks,
welcome
to
the
kubernetes
1.25
release
retrospective.
This
is
part
two
of
the
of
the
release.
Retro
today
is
august
31st,
the
first
release
retro
was
held
on
july
27th,
I'm
your
host.
Today,
my
name
is
ray
lahano.
The
emeritus
advisor
for
on
the
125
release
team
here
jeremy
here
is,
will
be
taking
notes.
I'm
gonna
start
sharing
my
screen
here
and
I'll.
A
Do
some
formal
introductions
here
we
are
a
kubernetes
meetings
so
that
we
do
bye-bye
by
the
cncf
code
of
conduct,
which,
which
means
boils
down
to
just
to
be
kind
to
everyone
here.
Also,
this
meeting
is
recorded
and
uploaded
to
youtube,
so
be
mindful
of
what
you
want
to
say
on
this
meeting.
We
will
continue
on
from
the
this
is
part
two.
A
I
do.
I
do
have
a
marker
for
where
we
left
off,
but
I'm
going
to
briefly
going
through
what
from
the
pre
previous
retro
follow-up,
see.
If
there's
any
changes,
I
did
check
to
see
if
there
were
any
changes,
so
I'm
going
to
skip
through
all
the
the
stuff
that
we
actually
did
finish
and
kind
of
go
and
kind
of
go
through
what
are
still
in
progress.
So,
let's
bear
with
me
folks
here.
A
First
one
is
the
automate
enhancements
tracking
workflow,
so
this
is
the
spreadsheet
replacement
or
the
google
spreadsheet
replacement
with
github
projects
beta.
I
noticed
the
this
is
still
in
progress.
There
is
still
pr
for
the
automation
scripts,
that's
still
in
draft
mode
here.
So
that's.
Please
take
a
look
at
that,
so
there
have
been
some
good
reviews
since
the
last
retro.
A
Next
item
is
I'm
gonna,
I'm
gonna
group
this
into
one
so
there's
usually
after
release
we
like
to
make
some
updates
to
the
handbook,
so
I
do
advise
all
the
role
leads
to
the
handbook
to
add
an
update
to
the
handbook.
So
this
is
one
of
them
for
the
bug
triage,
but
we
also
have
another
one
as
well
on
the
very
in
the
very
bottom
here
to
make
respective
updates
to
the
handbag,
because
we
always
try
to
make
the
release
better
in
every
single
way.
A
A
A
All
right,
moving
on
skipping
over
what's
done
going
to
in
progress,
this
automates
weekly
ci
report
to
know
leo
is
not
available
to
attend.
Today's
call
here,
but
we'll
follow
up
with
with
leo
next
month's,
also
using
the
sippy
monitoring
tool
as
well
to
test
out
as
a
pilot
for
the
what
in
the
126
cycle.
C
A
Good,
thank
you.
Next
one
is
another
handbook
update
as
well,
so
follow
up
to
make
sure
we
have
the
updates.
I
know
there
is
a
draft
pr,
that's
actually
open
from
james,
to
update
the
lead
handbook
from
the
124.,
especially
about
deadlines,
especially
about
what
happens
if
release
is
delayed,
so
we
do
need
to
have
those
steps
added
to
the
lead
handbook.
A
A
A
See
that
has
merge
and
last
one
is
just
more
lead
handbook
or
more
role.
Handbook
updates,
so
I'll
talk
to
the
rolaids
and
what
was
mentioned
last
retro
was
to
possibly
add
some
mermaid
diagrams
as
well.
You
know
leo
merged
one
for
what,
in
the
read
means
to
have
the
to
use
mermaid
diagrams
in
one
of
the
sig
release
readings
that
kind
of
outlined
the
whole.
I
guess
processor
flow
of
a
weak
cycle.
A
All
right
moving
on
what
went
well
125,
these
were
covered
in
the
last
retro,
we're
just
going
over
briefly
pivoting.
The
enhancement
freeze,
dates,
which
was
delayed,
which
was
a
request
from
the
community
enhancement.
Freeze,
went
well
when
we
had
more
exceptions
after
the
first
fourth
show.
So
so
we
those
were
nicely
handled
shadow
orientations.
A
A
All
right,
where
we
left
off
into
that
from
the
first
retro,
was
where
what
could
have
gotten
better
in
125
so
marked
here
and
I'm
retro
one
of
the
first
retro
here
so
the
first
topic.
First
new
topic:
today's
retro
is
from
cc
prr
reviewers,
raise
concern
of
being
asked
to
review
a
bunch
of
caps
for
prr.
They
are
not
on
the
enhancement
sheet
after
the
prr
deadline,.
C
C
Regarding
the
pr
deadline
and
the
pr
reviewers
raised
the
concern,
like
a
kind
of
in
this
early,
this
release
share
some
feedback
they
got
like.
They
were
asked
for
reviewing
some
enhancement
which
not
opting
to
the
enhancement
shade.
Also,
they
were
asked
to
review
after
the
pr
deadline,
and
I
know
some
of
the
pr
I
know
we
like
have
limited
capacity
of
pr
review.
We
only
have
four
pr
reviewers
now,
maybe
three
now,
because
one
like
less
active
and
also
like
they
might
plan
like
a
vacation
around
like
a
pr
deadline.
C
E
Yeah,
so
I
think
this
comes
from
the
the
cap
that
defined
what
the
prr
process
was
like,
and
this
is,
I
think,
partially
something
that
they're
gonna
need
to
push
back
on.
You
know
so
whether
they
should
review
things
that
are
not
in
the
the
tracking
sheet.
I
would
say
no
given
the
finite
bandwidth
that
they
have
and
I
think
they
need
to
feel
comfortable,
pushing
back
on
people
to
after
the
deadline
we're
not
going
to
be
able
to
review
it.
E
We've
we've
got
a
backlog
that
we're
going
to
be
able
to
get
through,
and
if
it's
not
in
that
tracking
sheet-
and
it's
not
something
you've
brought
to
us
by
the
deadline,
then
it's
it's
not
going
to
make
it
if
they
have
bandwidth
and
then
they
can
make
those
those
calls.
But
I
think
that
we
should
all,
as
like
people
on
the
release
team
feel
comfortable
blocking
things
and
making
things
marked
as
release
blocking
when
they're
bugs
later
on
and
then
earlier
in
the
process.
E
C
E
But
we
didn't
like
ask
every
single
person
on
the
api
review
group
if
they
could
do
this
and
jordan
raised
a
concern
that
hey
this
is
super
late.
We
don't
really
have
bandwidth.
Somebody
had
had
said
they
would
do
the
api
review,
so
that
was
okay,
but
I
think
just
there
there's
finite
capabilities
in
some
of
these
areas
and
those
are
going
to
become
sticking
points
or
choke
points
for
the
the
process
and
I'll.
Let
stephen
go
now,
since
I've
been
talking
too
much.
F
I
I
mean,
I
think
you,
you
nailed
it
one
thing
to
note:
we
were
talk,
asking
soft
versus
hard
deadlines,
there's
no
such
thing
as
a
soft
deadline,
and
and
and
to
be
honest,
there's
no
such
thing
as
a
deadline.
We
have
all
of
these
mechanisms
within
the
system
that
allow
people
to
circumvent
our
deadlines
right.
F
So
so
one
of
the
things
that
we
have
to
put
in
place
is,
we
have,
to
like
jeremy,
said,
be
reasonable
about
about
the
amount
of
work
that
can
realistically
go
into
the
cycle
and
be
fine
with
pushing
back
when
that
is
not
happening.
If
a
you
know,
if
a
prr
review
is
required
from
you
know,
you
know
for
for
a
specific
cap.
I
I
see
that,
like.
F
Yes,
we
are
shepherds
of
this
process,
but
the
prr
is
is
happening
within
the
context
of
a
sig
too
right
in
the
context
of
at
least
two
things
right.
So
well,
really,
three
right!
That's
you
know.
The
sig
release
is
consulted
right,
but
it's
the
responsibility
of
the
you
know
of
the
the
owner
of
the
cap.
It's
the
responsibility
of
the
pr
reviewers
and
sig
architecture.
F
It's
also
the
responsibility
of
the
sig
leads
within
that
sig
to
make
sure
that
work
is
happening
right,
so
the
I
I
think
there
is
there
is
a
balance
point
between
planning
your
work
and
not
planning
the
work
and
making
sure
that
you
know
making
sure
that
things
get
opted
in
sooner
rather
than
later.
So
at
least
we
have
some
mechanism
to
to
reason
about
how
much
work
is
going
to
be
in
the
release.
F
Ultimately,
a
lot
of
things
will
fall
out
for
for
sure,
but
that
I
think
a
bit
of
that
falls
to
sig
lee's,
getting
tighter
about
their
planning
process.
Right
during
you
know,
from
code
freeze
to
like
planning
is
continuous
right
so,
but
during
code
freeze
to
next
release
cycle
is
where
I'd
imagine.
People
are
looking
at
what
caps
are
going
to
land
for
the
next
cycle,
so
I
say
all
of
that
to
say
that
there
are
no
deadlines.
We
should
push
back
very
aggressively
on
on
late
stage
reviews.
F
I
don't
think
anyone
should
plan
to
do
a
prr
review
unless
the
thing
is
opted
in,
especially
because
it's
a
requirement,
so
you
know
like
so
the
opt-in
is
a
requirement
and
the
prr
reviews
are
a
requirement
right.
The
opt-in
is
supposed
to
be
happening
before
the
prr
review.
So
if
it's
not
on
the
sheet,
it
doesn't
exist.
That's
how
I
feel.
D
Yeah,
I
think
an
action
item
we
can
take
from
this
is
the
email
that
the
release
lead
sent
out
at
the
beginning
of
the
cycle
can
mention
specifically
that
the
pr
soft
deadline
means
that
if
you're,
you
opt
your
pr
in
after
the
deadline,
you
are
at
risk
that
it
will
not
be
reviewed,
so
just
communicate
that
expectation
ahead
of
time.
It
can
be
an
action
item
going
forward.
F
F
A
F
E
G
Yeah,
I
was
just
wondering
if,
instead
of
saying
soft
deadline,
should
we
do
something
like
what
the
docs
team
does
at
the
end
of
the
release
and
say
like
here's,
a
date
where
we
want
the
pr
section
to
be
up
and
ready
for
review.
If
it's
not
ready
by
then
then
you,
you
may
not
make
it
because
that
will
at
least
force
people
to
look
at
it
early
and
maybe
help
figure
out
how
much
bandwidth
the
reviewers
have.
G
F
C
Oh
yeah,
I
agree
with
all
above,
and
I
think
it's
any
email
or
like
making
the
remove.
The
soft
with
the
software
lines
are
great
and
also
like
add
the
exceptions
for
pr,
and
I
just
want
to
comment
that
it's
not
really
a
big
concern
here.
Even
like
we
have
limited
capacity
in
this
release.
The
pr
review
went
super
well
and
released.
C
Him
do
helped
a
little
bit
on
clarifying
if
the
enhancement
which
being
asked
for
pr
review
late
would
be
opting
or
not
like
the
helping,
with
the
clarification
on
with
all
the
six
but
but
in
general,
the
pr
review
went
super
well
people
playing
around
and
yeah,
and
it
all
like.
The
enhancement,
got
like
the
preview
already
before
the
deadline.
A
A
F
C
But
I
I
just
think
of
this
video
yesterday
and
it
seems
it's
not
quite
ready
yet
because
we
are
still
the
the
board
is
up
and
we
not
use
it
much
for
tracking
and
we
are
lack
of
the
automatic
to
to
like
update
it
periodically
and
that's,
I
guess
the
missing
part
part
and
I
do
feel
if
we
cannot
use
it
from
the
very
beginning,
it's
better
to
like
just
keep
using
spreadsheet.
Maybe
because,
if
like
we
switch
in
the
middle,
it
might
cause
confusion
for
like
the
sig
lease.
C
F
A
A
F
So
so
as
we
as
we
think,
through
like
gap,
analysis
between
you
know
moving
from
old
system
to
new.
The
first
thing
that
we
should
do
is
document
what
the
old
system
does
right.
So
understanding
of
those
scripts
after
that,
because
I
was
going
to
say
if
there
is
no
automation
whatsoever
around
these
things,
I
mean
there
isn't
automation,
there's
scripting,
it's
not
automated
is
if
it's
just
a
spreadsheet,
we
can.
F
E
I
could
I
could
take
a
look
at
it.
Sorry,
with
with
bran,
I
think
ray
would
agree
with
me
is
most
most
of
that
automation
is
for
the
use
of
the
spreadsheet,
but
most
of
that
just
works
around
the
fact
that,
like
spreadsheets
don't
work
like
github
projects,
so
I
think
that
you're
absolutely
right,
but
I
think
it's
pretty
clear
to
see
what
it
is
and
you
see
it
in
the
result
of
like
enhancements,
tracking
and
docs
tracking
and
as
long
as
I
think,
you're
aligned
to
that
those
end
requirements.
G
Yeah
as
part
of
the
enhancement
team
on
this
last
release,
I
think
the
only
automation
we
used
for
scripts
that
we
used
from
those
spreadsheets
was
there
was
one
tab
where
you
put
in
the
number
of
the
enhancement
issue,
and
then
it
went
to
github
and
fetched
information
like
the
tech
like
the
the
tags
for
which
sig
was
owning
it
and
which,
like
release,
it
was
targeting.
Everything
else
was
manual,
and
I
think
that
that
all
just
comes
for
free
with
using
github
actions,
because
it's
an
issue
that
shows
up
on
the
board.
F
G
So
the
other
thing
I
was
going
to
comment
is
around
the
the
automation:
what
I'm
not
exactly
sure,
what's
stopping
automation
around
running
the
scripts
that
we
have
for
the
github
actions
today,
I
think
all
we
really
need
is
somebody
to
generate
a
path
that
has
that
can
authenticate
as
either
an
app
or.
However,
we
want
to
authenticate
to
the
graphql
query
stuff.
I
actually
set
up
some
automation
for
sig
windows
to
keep
a
project
board
up
to
date.
That's
just
running
as
a
get
up
action
and
it's
been
working
fine.
G
F
F
G
G
A
C
Yeah
I
just
bought
added
something
like
marquee.
If
you
want
to
take
follow
the
work,
I
think
priyanka
already
did
like
a
lot
of
work
on
towards
that
direction.
I
guess
the
missing
part
is
documentation
and
the
merge
of
the
scripts
and
the
maybe
the
prawn
job
setup,
the
project
last
time
when
I
synced
it
it's
blocked
by
using
the
github
token
or
using
the
existing,
like
existing
release,
token
to
fetch
the
github
or
create
a
separate
one.
C
A
D
What
cc
said
on
on
the
existing
pr,
but
I
also
want
to
mention
or
clarify
what
we
have
in
mind
for
bringing
in
this
github
board.
So
are
we
gonna,
get
rid
of
the
google
sheet
entirely
and
just
live
on
the
project
board
or
have
both
the
running?
What
does
that
look
like
for
the
sig
lead
and
how
do
we
make
sure
that
we
communicate
that
going
forward?
D
And
then
one
more
thing
is,
I
remember
one
of
the
major
blocker
from
running
the
script
is
that
anyone
can
tag
an
issue
as
being
opt
into
a
release
and
a
lot
of
people
have
access
to.
I
think
that's
the
major
blocker,
because
even
the
patch,
I
don't
think
that's
a
major
blocker
at
the
moment,
because
individual
shadows
can
kind
of
just
run
it
locally.
Right
like
we
may
not
have
the
crowd,
but
I
don't
think
that's
a
blocker.
G
Last
time,
I
remember
being
in
a
discussion
around
this,
I
thought
the
desire
was
to
do
both
have
sig
leads,
opt
into
the
spreadsheet
and
then
have
the
enhancements
team
maintain
the
github
project
board.
At
the
same
time,
I
don't
remember
if
that
had
changed,
and
I
do
remember
also
talking
about
ways
of
having
it,
so
there
were
maybe
specific
tags
that
only
a
certain
subset
of
folks
could
add
to
issues,
and
we
would
use
that
tag
to
gate
which
issues
got
added
to
the
that
project
board.
A
F
If
this,
the
last
I
heard
of
this,
was
maybe
the
last
the
mid-cycle
retro,
so
I
I
would.
I
would
caution
about
running
things
in
parallel,
because
any
conversations
that
we've
had
about
enhancement,
approval
and
improvements-
and
you
know
things
like
receipts
and
stuff
like
like
those
conversations-
have
been
happening
for
multiple
cycles
like
if
we're
gonna
do
it,
we
gotta
we
gotta
just
do
it.
Take
the
hit
be
very
upfront
with
people
about
where
the
gaps
are
and
work
to
close
them
across
the
cycle.
A
F
F
With
regards
to
the
the
the
tags
the
same
way,
we
have
the
the
same
way
we
have
milestone
maintainers,
we
can
do
a
smaller
subset.
That
is
specific
to
the
release
group
that
has
access
to
tag
whatever
this
opt-in
tag
is
going
to
be.
That
way.
That
way,
we
have
the
the
assurances
that
that
tag
won't
get.
You
know
arbitrarily
popped
off
the
issues.
F
The
problem
with
the
milestone
maintainers
group,
is
that
it
is
so
large
and
it
is
required
to
do
some
of
the
things
that
you
need
to
do
so.
The
yeah
yeah
we'll
have
to
think
through
the
system,
because,
even
with
milestone
maintainer,
you
could
circumvent
the
process
even
adding
a
new
tag.
So
it's
it
it's
yeah.
We
do
need
an
extra
layer
of
authorization,
but
but
we
should
do
it.
F
G
F
E
Grace
has
just
said
what
I
was
going
to
say:
people
have
abused
their
milestone,
maintainer
privileges,
either
intentionally
or
unintentionally,
but
I
think
we
just
have
to
assume
good
intentions
and
we
can
go
from
there
and
restrict
things
as
needed.
But,
like
I
I'll
just
echo,
my
plus
one
and
docs
like
I
don't
think
we
should
do
both.
A
D
F
I
I
would
say
it
sounds
like
the
the
folks
who
signed
up
for
some
of
the
stuff
include
you
and
mark.
I
would
work
with
you
mark
and
ryler
compile
what
we've
written
in
the
notes
into
a
github
issue
and
kind
of
break
out
the
work,
but
we,
let's.
Let's
turn
this
from
meeting
notes
into
something
trackable.
A
F
So
I
would
say
that
you
know
part
of
this
is
the
responsibility
of
sig
release
leads.
We
need
to
disappear
all
of
the
existing
boards,
I
think,
and
convert
over
to
projects
beta
or
projects.
Now
ga
figure
out
what
our
structure
is
for
that
and
how
cards
will
flow
in
the
the
stuff
that
has
been
tossed
onto.
I
mean
one
overall
all
leads
across
all
sub
projects
and
and
the
sig.
We
need
to
get
better
about
issue
triage
and
getting
things
into
the
board,
even
though
we're
completing
them.
F
You
know
they're,
not
necessarily
representative
of
the
work
we're
doing
if
we
can't
show
them
off
on
the
board
right.
So
the
you
know
so
part
of
this
is
switching
over
to
projects
beta
whole
wholesale.
Our
projects,
ga
new
projects,
whatever
it's
called
now,
but
also
the
tasks
that
are
on
this
board-
are
representative
of
long-term
tracking
tasks
right
they're,
not
just
necessarily
items
that
should
be
completed
within
the
scope
of
a
of
a
cycle.
F
They
are
items
that
are
supposed
to
be
for
the
long-term.
You
know
ease
of
use,
or
you
know
day-to-day
operations
of
the
teams.
So
when
we
don't
address
them,
we
end
up
talking
about
them
again
in
the
next
retro,
so
so
yeah.
I
I
think
in
an
increased
effort
around
issue
triage
and
around
prioritizing
tasks
that
are
kind
of
priority
long
term,
or
else
they
will
remain
in
the
backlog.
B
But
I'm
I'm
wondering
what's
what
kind
of
issues
land
on
the
release
team
project
world
I
mean
there
are
some
which
are
like
you
know
those
of
burma
open
issues.
But
I
was
wondering
if
you
have
been
using
that
word
over
the
cycle,
which
from
leo's
comment
seems
you're
not,
but
because
I
understand
the
other
boards
and
secretly
tracking
longer
term
issues.
But
the
release
team
is
look
more
of
a
more
rapid
cycle,
so
would
does
it
make
sense
to
still
have
that
board
up
or
maybe
disappearing
it
that
no
one
is
using?
B
F
So
the
way
I
feel
on
the
release,
team
tracking
board
is
most
of
those
issues
that
were
put
on
that
board
were
put
on
by
single
lease
leads
and
with
the
with
the
understanding
that
they
are
long-term
tracking
issues
that
should
be
burned
down
by
the
release
team.
So
this
is,
you
know,
I
think,
if
we
remove
the
board
we're
saying
that
those
issues
are
not
important
and
I
don't
think
that's
the
case
so
trying
to
figure
out
how
to
balance
providing
visibility
to
them
while
actually
getting
them
done.
B
F
C
This
yeah,
so
currently
ci
signal,
said
signaled
him
already
like
poster
like
at
least
the
weekly
report
into
the
channel
and
create
issues
and
tracking.
If
it's
got
fixed
or
not,
but
then
we
got
the
suggestion
of
adding
up
to
the
weekly
report
by
not
only
just
issue
tracking
but
also
calls
for
action
for
maybe
some
long
standing
issues
and
also
kudos
for
anybody
who
fixed
the
fading
test,
which
I
think
is
a
great
idea.
B
I
think
I
would
convert
it
to
an
issue
like
a
feature
request
for
the
signal
reporting
tool.
It's
it's
kind
of
hard
because
it's
supposed
to
be
finally
relieving
the
ca
signal
theme
of
a
what
used
to
be
like
a
manual
task.
So
adding
those
would
be
could
be
a
good
one,
but
we
have
to
think
on
the
flow
and
have
to
incorporate
that
information
into
the
weekly
reports.
A
H
A
Moving
on
to
the
next
topic,
is
there
any
other
last
call
for
any
commenters
or
suggestions
on
this
apologize?
If
you
hear
that,
in
the
background
next
topics
for
me
so
received
some
feedback,
that
release
team
would
be
better
if
all
the
sub
teams
act
like
a
like
a
single
team.
This
some
context
behind
this
is
that
the
shadow
shouldn't
feel
like
a
shadow
like
they
should
feel
like.
They
could
do
the
same
task
as
a
lead,
which
is
what
we
intend,
which
is
stated
in
the
handbooks.
B
A
F
F
I
think
it
is
important
to
recognize
when
someone
is
leading
a
track
period.
The
responsibility
of
those
leaders
is
to
make
their
teams
feel
like
they
can
contribute
in
any
in
any
way
shape
form
possible
right.
There
are.
There
are
instances
where
you
know
I.
I
think
I
think
this
is
more.
You
know
more
specific
to
say.
The
release
team
lead,
for
example,
right
other
instances
where
opportunities
or
requirements
will
pop
up.
F
F
I
do
think
there
there
has
to
be
responsibility
for
the
leads
and
that
responsibility
includes
making
sure
their
shadows
feel
that
they
can
participate.
There
are
some
leads
that
have
you
know,
and
I
mean
this
is
not
specific
to
the
cycle.
This
is
in
the
past.
This
is
years
going
where,
where
shadows
have
come
to
us
and
they've
said
like
well,
you
know
we
didn't
get
an
opportunity
to
do
this
or
leads
have
have
come
to
us
and
said
that.
F
A
B
B
F
I
think
I
think,
as
we
make
those
boundaries
fuzzy,
there
are
always
people
who
will
you
know,
for
you
know
the
the
irrespective
of
pain
and
their
personal
pain
and
suffering
will
always
step
up
to
tasks,
even
if
it
feels
uncomfortable,
even
if
they
don't
have
the
bandwidth
to
do
it
like
that,
is
that
it's
just
like
the
the
sub
sub
sub
sub
subtitle
of
open
source
contribution
the
like,
if
these
teams
don't
make
sense
as
currently
structured.
Let's
talk
about
that.
F
F
The
largest
golang
project,
the
largest
open
source,
going
project
in
the
world.
This
is
one
of
the
hardest
roles
to
get
into
in
all
of
kubernetes.
Save
save
the
committees
right.
There
is
a
deep
amount
of
respect
and
trust
that
is
given
to
this
role.
So
don't
look
at
just
being
a
shadow
as
as
a
nothing
role.
It
was
hard
for
you
to
get
there
and
there
were-
and
there
were
tons
of
conversations
that
happened
in
the
background
between
role
leads
release.
Team
leads,
sig
leads
to
make
the
decision
to
include
you
on
the
team.
F
H
H
I
don't
know
who
com
who
who
has
like
the
specific
feedback
or
complaints,
but
in
my
experience
as
a
shadow
many
cycles
ago-
and
it
was
not
about
the
title,
but
I
did
feel
like
things
were
not
clearly
explained
to
me.
So
I
couldn't
participate
a
lot
and
I
was
expected
to
just
grab
things
and
tasks
that
I
didn't
have
enough
contacts
for
and
like
then
I
was
like
okay,
fine,
I
won't
do
anything
and
then
you
know
it's
like
the
catch-22.
H
So
a
part
of
the
leadership
is
to
to
say
like
okay.
This
is
a
task
that
you
have
to
do
and
I
can
explain
to
you
and
a
lot
of
that.
So
it's
not
only
part
of
being
experienced,
but
also,
if
you
have
the
bandwidth
to
to
explain
things
so
for
every
every
role
will
be
different,
of
course,
but
just
the
the
attitude
to
to
say
like
hey
here
is
how
you
do
it's.
Shadow
literally
is
like
shadowing.
It's
not,
I
don't
know
I'll
I'll
shut
up
now,
but
that
that's
also
important.
A
Yeah
and
I
know
for
a
recent
release-
I
don't
know
when
this
started,
but
we
we
do,
ask
what
leads
to
have
their
own
orientation
sessions
with
their
shadows
and
how
to
do
the
work
or
do
the
tasks.
That's
part
of
that
role,
so
hopefully
that
you
know
that
that
helps
out
and
roll
leads
are
open
for,
for
shadows
to
reach
out
to
them
same
with.
Release
leads
and
lead
shadows
as
well.
A
C
H
A
E
I
think
some
flavor
of
this
happens
all
the
time,
because
the
process
isn't
perfect
and
there
are
lots
of
ways
that
things
can
land
there's
lots
of
ways.
Things
can
get
committed,
there's
lots
of
ways,
things
end
up,
getting
reverted
when
there's
problems
signed
with
them,
there's
lots
of
like
things
can
get
done
and
then,
like
we've
got
a
revert
that
happened
right
after
125
to
move
something
back
to
alpha,
because
there
was
a
big
problem
found
with
it.
E
Then
it's
going
to
happen,
but
there's
no.
Like
hard
and
fast
way
where
we
can,
we
can
lock
everything
down
with
given
how
all
of
the
the
approvals
and
how
the
you
know
the
prowl
restrictions
of
things
and,
like
we
can
say,
oh
only
milestone,
containers
can
do
things
but
milestone.
Containers
is
such
a
big
group
that
things
happen,
and
I
think
we
just
have
to
do
the
the
best
judgment
call
we
can
can
make
on
any
of
those
individual
things,
and
maybe
that's
like
adding
some.