►
From YouTube: Kubernetes Release Team Meeting for 20230823
Description
Kubernetes Release Team Meeting for 20230823
A
Hello,
everyone
welcome
to
the
release
team
128
retro
meeting.
This
is
part
two
and
we
had
a
part
one
which
was
mid-cycle
of
the
room
release
cycle.
Now
we
are
past
release
date,
so
the
releases
has
been
finalized
and
this
is
the
second
part
we
have
a
couple
of
action
items
Please.
Be
aware
that
this
is
a
community
sick
release,
release
team
meeting,
so
it
falls
under
the
cncf
code
of
conduct,
which
can
be
summarized
to
be
just
excellent
to
each
other.
A
I
shared
the
Retro
agenda
in
slack,
no,
not
in
slack
in
Zoom.
So
if
you
would
like
to
take
a
look,
take
a
look
and
follow
for
a
long,
please
open
up
the
document,
I
believe
the
Retro
follow-up
from
last
time.
We
already
did
this,
so
let
me
go
down
the
document.
There
are
a
couple
of
highlights
here.
A
B
A
A
D
D
So
I
missed
that
and
I
think
that
could
have
been
a
lot
better
in
one
point
to
it
and
I
guess,
like
the
other
two
and
and
the
other
two
things
that
could
have
been
better
than
1.2,
it
would
be
I
also
faced
an
issue
with
GitHub
permissions
on
the
release
day.
So
it
didn't
allow
me
to
merge
a
PR
I
had
made
because
the
pre-order
didn't
I
guess
the
period
didn't
have
any
reviews
and
it
was
also
failing
tests.
D
So
so
I
also
needed
to
so
I
also
needed
to
merge
that
and
there
I
didn't
have
enough
GitHub
work
machines
to
do
that,
even
after
being
ordered
to
the
website.
Maintainers
and
I
also
think
that
we
should
probably
be
documenting.
We
should
probably
also
be
documenting
what
some
of
the
labels
on
the
board
board
means.
D
A
Right
thanks
thanks
Rashid
I
know
we
have
a
couple
of
discussion
items
about
dogs,
so
maybe
we
can
for
now
just
like
focus
on
the
reporting,
so
I
think
this
was
like
the
first
one
like
the
status
update
in
the
release
release
the
meetings
is
there
anything
like
obviously
like
these
reportings
are
kind
of
opaque?
So,
but
what
is
like
really
yellow
what
is
really
red?
A
What
is
green,
so
there's
like
not
like
a
very
specific,
usually
not
a
very
specific
guidelines
for
some
teams,
for
example,
if
there's
like
a
blocking
issue
and
for
CS
signal,
for
example,
which
blocks
the
release
cards,
this
is
like
a
red
red
flag.
So
are
there
any
ideas
how
we
can
improve
that
in
general,.
F
F
F
Both
the
comms
and
the
docs
team
should
be
doing
this
in
our
opinion,
because
they
would
be
able
to
flag
this
on
a
much
more
frequent
basis
and
we
could
have
avoided
the
last
minute
rush.
So
two
things
tldr
has
stopped
rambling
after
this
first
thing
is
for
each
of
the
role
vertical
leads
to
go
through
there.
F
Accountability
checklist
first
have
a
checklist
on
what
the
roles
and
responsibilities
are
for
that
particular
lead
and
a
certain
what
you
know
based
on
that,
whether
it's
yellow
green
red,
the
second
thing
would
be
to
actually
bring
up
these
issues.
Bubble
Up
these
issues
on
both
the
calls.
This
would
sort
of
help
with
any
you
know,
communication
that
we
have
to
have
around
these
particular
issues.
That's
just
me,
though,.
G
A
H
I
Updates
and
weekly
updates
being
somewhat
opaque
and
I
think
on
the
dock.
Send
that
could
be
something
that
we
could
possibly
work
with,
so
that
that
so
that
that's
not
the
case,
because
that
that
line
of
updates
being
opaque
is
to
be
super
honest,
a
little
concerning
for
me
in
terms
of
then,
what
are
you
supposed
to
be
updating
on
my?
I
So,
if
they're
looking
to
try
and
get
things
merged
and
the
authors
are
just
not
responsive,
that
is
an
automatic
yellow
in
my
mind,
because
there
is
clearly
a
blockage
happening
and
we
need
to
kind
of
kind
of
step
in
there,
and
they
can
then
also
take
on
responsibility
of
making
a
decision
around.
There's
no
response.
This
doesn't
make
the
docs
deadline,
and
thus
this
is
cut
from
attract
enhancement,
release
or
whatever.
E
Yeah
similar
similar
lines,
one
thing
that
came
up
during
the
release
when
I
was
talking
to
Ray
was
just
the
importance
of
joining
the
the
calls
of
their
respective
sigs.
That
leads
are
working
with
I.
Don't
think,
that's
something
we
actually
have
documented
in
many
of
the
role
handbooks,
but
where
it
applies
in
particular,
like
comms
meeting
with
contrabacks
or
docs
meeting
with
Sig
docs
I.
E
I
know
that
when
I
was
Doc's,
lead,
I
I
work
with
Ray
I
mean
it
felt
like
weekly.
So
we
were
very
much
aligned
with
what
we
were
working
on
and
I
know
that
I
also
work
with
Natalie
Nvidia
on
the
release
date
itself.
So
I
think
it's
important
to
make
sure
that
we
actually
remind
everybody
to
be
very
aligned
with
the
respective
Sig
that
they're
working
with.
A
B
Yeah
I
do
want
to
make
a
note
that
that
I
would
like
to
hear
if
status
is,
yellow
or
or
red.
So
that
gives
me
action
or
gives
me
a
call
to
action.
Lets
me
know
that
something
has
something
there's
an
issue
that
that
needs
attention
to
so
I,
so
I
just
want
to
make
sure
that
that
shadows
and
roll
leads
feel
safe
to
to
Mark
something
as
non,
not
green
as
well,
so
I
just
want.
B
So
we
should
be
clear
with
that
and
either
in
handbooks
or
or
in
the
or
in
the
shadow
orientation,
where
that
it's
okay
and
it's
actually
for
me
personally,
it's
better
I
would
rather
see
it.
If,
if
it's
truly
not
green
I
would
rather
see
it
be
exact
to
reflect
to
to
their
current
status
also,
but
for
for
the
docs
handbook
as
well.
B
We
actually
do
note
that,
for
the
time
requirements
for
docs
leading
Shadows
is
210
docs
meetings
for
status
reports,
it's
actually
States
one
hour
weekly,
but
we've
gone
to
bi-weekly
so
but
yeah,
it's
already
stated
in
the
hand
in
the
handbook
yeah,
so
there's
other
changes
additions.
We
need
to
to
to
reinstate
or
to
state
that
in
other
places.
Well,
maybe
add
it.
You
know
to
all
to
the
entire
release
timeline
for
the
docs
handbook.
We
could.
I
Sorry
to
jump
in
I
just
want
to
say
big,
plus
one
and
right
what
Ray
said.
I
think
it's,
because
we
end
up
I'm,
just
speaking
for
docs.
We
don't
expect
that
every
status
update
needs
to
be
green
and
that
we
do
nothing
like
if
it's
yellow.
We
want
to
help
be
in
there
and
help
out
like
we're
working
on
this
all
together
right.
So
that's
the
that's.
I
The
purpose
on
making
sure
that
we're
kind
of
teaming
up
and
knowing
what
a
like
a
legit
status
is
so
that
we
know
when
we
can
help
out
and
step
in
if
need
to,
or
support
and
Wrangle
folks,
because
of
maybe
someone
will
listen
to
a
docs
person
for
docs
versus
release
team
for
some
reason
as
an
example.
So
I
just
want
to
kind
of
further
clarify
that
we
want
that,
because
we
want
to
help
for
sure.
J
The
Wally
is
coming
back
I
one
thing
that
Natalie
said
that
piqued
my
attention
is
that
we
typically
have
never
kicked
an
enhancement
out
because
they
don't
have
dogs
so
we're
we
don't
enforce
that
deadline
well
and
so
I
think.
As
a
result,
it
has
create
this
kind
of
expectation
that
PRS
will
be
docs.
Prs
will
be
overdue,
but
I
think
it
can
certainly
be
done
like
we
can
strictly
enforce
that
deadline.
F
So,
jumping
on
to
what
you
just
said:
Grace
I've
worked
with
dogs
and
comms,
and
the
issues
not
per
se
with
the
PRS
not
not
being
approved
like
I,
do
get
that
every
cycle
has
those
like
stray
three
four
PR's
here
and
there
that
you
know
need
approval
at
the
last
minute.
They
tend
to
happen
because
as
much
as
we'd
like
to
believe
all
of
us
here
are
doing
this
voluntarily,
and
it
does
happen
that
we
end
up
getting
it
shortened
there.
F
Some
of
the
PRS
I'm,
not
gonna,
say
all
of
them,
but
this
cycle
it
was
slightly
difficult
and
given
the
feedback
that
we've
given
over
the
last
couple
of
Cycles,
this
was
a
little
difficult
for
us
to
digest
that
you
know
there
were
a
lot.
There
was
a
lot
to
handle
because
the
comms
or
comms
team
was
also.
F
You
know,
burdened
with
the
fact
that
they
did
not
have
a
publishing
date
and,
and
then
we
had
to
set
all
of
that
into
motion,
get
the
release
blog
out,
get
it
reviewed
from
a
technical
perspective,
so
it
all
sort
of
snowballed
at
the
end.
So
we
get
that.
You
know
there
will
be
dates:
I'm
not
asking
for
a
strong
enforcement,
but
bubbling
up.
Those
issues
earlier
on
would
have
helped
in
reducing
and
sort
of.
F
You
know,
smoothing
the
workload
across
the
cycle,
or
at
least
across
the
last
few
weeks
of
the
cycle,
as
opposed
to
you
know
just
being
done
all
of
it
happening
on
the
same
day,
and
you
know
Ray
me
Natalie
and
Tim
like
struggling
to
get
Tech
approvals,
and
you
know
folks
to
actually
concentrate
on
specific
PRS.
So
this
is
majorly
an
ask
for
people
to
come
up
and
feel
safe
to
come
up
and
say
that
you
know
hey,
we
have
an
issue.
We
want
your
help.
F
Please
help
us,
that's
all
we're
asking
and
report
it
to
us.
That
is
all
like.
We
don't
expect
that
you
know
people
will
be
able
to
give
everything
in
on
the
exact
deadline.
It's
it's
not
possible,
but
they're
working
on
enhancements
and
I
get
it.
Docs
are
not
much
of
a
priority,
and
unfortunately
that's
something
that
we're
gonna
have
to
deal
with,
but
bubbling
it
up
in
time
is
something
that
we
expect
so
that
we
can
ensure
our
workload
and
your
workloads
are
smoothened
over
time
rather
than
you
know.
A
A
But
one
point
for
me
is:
we
have
talked
about
docs
quite
a
bit
now,
but
I
think
the
entire
discussion
about
giving
sales
updates
obviously
applies
to
every
everybody
else
too.
So
all
the
other
teams.
So
maybe
this
is
like
a
good
point,
like
a
tracking
issue
for
the
other
teams
as
well
to
scan
the
handbook,
if
they're
like
clear,
actionable
like
thresholds
or
whatever,
when
to
give
like
a
red
flag
when
to
give
like
a
yellow
flag
and
so
on.
C
Yeah,
just
one
thing
I
like
to
add
in
this:
what
happened
with
our
sincers
England,
this
release
is
that
we
had
to
freaky
test
from
1.27
and
we
have
become
so
used
to
those
solicitors
that
we
actually
don't
change
the
signal
to
Yellow.
They
are
still
flaking,
but
we
give
out
the
singular
screen
because
we
have
become
used
to
those
failures.
C
A
I
E
A
G
K
A
F
Yeah
I
think
there's
just
one
thing
and
I
think
gray
has
bubbled
up
that
thing
as
well
in
his
item
so
I.
Let
him
add
on
I,
basically
believe
that,
from
the
comms
perspective,
blog
publishing
schedule
was
missing,
till
I
think
the
week
before
the
release
as
far
as
I
remember,
but
that's
when
I
wrote
this
so
I,
don't
exactly
remember,
but
it
was
missing
and
we
were
not
sure
when
that
actually
ended
up.
F
You
know
being
designed
or
when
that
actually
happened
to
you
know
be
published.
So
a
lot
of
authors
were
reaching
out
to
us
on
the
issues
specifically
so
I
I
don't
know
if
if
it's
still
a
thing
to
publish
to
have
a
publishing,
Cadence
or
a
publishing
schedule
for
the
release,
it
was
during
my
time
as
a
comms
lead,
but
if
not
I
would
sort
of
recommend
it,
because
at
the
end
of
the
day
it
makes
life
easier
for
everyone.
F
Not
just
us,
not
just
you,
but
in
general
people
know
when
to
you
know,
push
their
changes
by
and
finish
off
whatever
they
are
supposed
to.
You
know
push
into
the
respective
PR,
so
I
would
recommend
that
the
schedule
will
be
actually
drawn
out
once
you
have
an
idea
of
the
you
know,
major
themes
and
stuff
like
that,
and
with
that
I'll
hand
it
over
to
her
because
I
realize
I've
been
talking
for
quite
a
bit
so
yeah.
B
Yeah
just
to
add
that
I
I
know
on
the
enhancements
tracking
board,
there's
a
view
for
the
for
for
comms,
and
there
is
a
column
for
the
publication
date
once
that
publication
date
has
been
already
been
determined.
That
should
be
communicated
back
to
the
to
the
blog
authors,
and
that
should
be
that
should
be
added
to
the
handbook,
because
there
was
a
confusion.
I
think
we
had
about
four
blogs
set
to
publish
on
release
day
and
typically
only
the
release
blog
is
a
published
on
release
date.
B
B
L
Well
now,
I'm
talking
I
put
an
issue
about
the
block
release
and
it
will
be
nice
if
we
have
a
branch
that
we
can
everyone
can
we
started
to
to
create
this
block
release
to
everyone's
review
it
and
merge
it
easily
and
it's
not
be
targeted
to
the
elite
to
the
private,
a
repository
of
the
consulate
that
it
that
was
happening
in
the
last
vlog
I.
Don't
know
if
you
got
the
idea,
but
it's
not
taking
anything
I.
B
B
A
route
I
would
go
with
because
he
also
because
blog
posts
typically
come
after
the
release.
So
right
now
we
target
the
main
branch
since
it,
since
it
goes
after
the
release.
If
we,
if
we
have
a
separate
Branch
for
the
blogs,
we
would
have
to
maintain
that
Branch
you
and
so
there's
and
more,
and
there
will
be
issues.
B
It
went
to
merge
that
Branch
into
Maine
as
well,
and
that's
going
to
be
a
lot
of
efforts,
as
so
I
I
won't
I'm
not
going
to
to
suggest
going
that
route
to
maintaining
a
separate
blog
release.
Branch
I
mean
right
now.
It's
we
work
for
for
blogs.
It
just
goes
to
Maine.
It
could
be
set
in
draft
at
first
as
well
and
or
or
blogs
could
also
be
reviewed
before
a
pull
request.
B
It
could
be
reviewed
in
in
hack
MD
for
our
blog
process
today
that
are
not
part
of
releases,
and
this.
This
might
be
something
that's
good
to
be
to
be
included
with
the
release
that
we
would
actually
like
to
prefer
to
review
the
blog
posts
in
in
hack
MD
or
it's
a
place
or
something
before
making
making
the
pr
and
then
the
then
the
pr
could
be
made
and
and
it'll
be
less
iteration
on
that
PR.
F
Flashback
to
what
Mickey-
and
we
have
said
as
a
previous
conversate
myself,
we've
done
the
hack,
MD
weight
and
we've
had
success
because
we've
asked
people
to
collaborate
over
there,
but
again,
not
limiting
you
to
hacking.
Please
try
whatever
works,
for
you
not
saying
that
you
have
to
try
that
out,
but
I
think
having
a
branch
is
going
to
make
it
more
complicated
than
not
for
everyone
involved.
So.
L
Okay,
I
just
put
in
the
comments,
because
my
idea
it's
only
to
have
a
branch
for
the
pull
request
about
this
block,
not
all
the
blocks
only
only
about
the
blog
of
the
release,
because,
where
you
have
like,
if
you
can
see
it,
we
have
a
lot
of
of
comments
and
reviews
and
it's
more
easily
for
all
the
community
and
also
the
owners
of
the
enhancements
or
review
it.
But
yeah.
If
you
think
about
that,
have
packet,
MD
will
be
a
good
idea
too,
to
review
it.
Okay,.
G
Hey,
thank
you.
Everyone
for
giving
feedback
on
the
dog
side
I
just
have
a
request
from
the
docs
lead,
Tim,
actually
added
a
few
feedback
on
the
129
timeline.
Pr
and
I
have
added
few
Milestones
to
just
make
some
noise
for
getting
dogs
ready
or
other
feature
blogs
ready
in
time
like
way
before,
so
that
we
can.
We
have
time
for
review.
I
would
request
more
feedback.
If
we
go,
I
could
include
anything
in
the
timeline
itself.
So
I
know
what
would
be
the
right
time.
G
G
A
C
E
K
A
G
G
So
I
can
add
an
example
had
added
feedback,
basically
asking
me
to
encourage,
let's
say,
dogs,
lead
and
dogs
Shadows
to
start
reaching
out
to
the
authors,
maybe
let's
say
right
after
enhancements
freeze
within
one
week
of
enhancements.
Freeze,
maybe
one
example
was
to
just
open
PR's
if
dogs,
pee
or
even
their
mtpr,
so
I
have
added
like
a
milestone
there,
something
like
initiate
Outreach
for
so,
and
so
so.
G
G
So
yeah
like
we
discussed
if
Communications
around
feature
blocks
Can
Happen
by
this
week
in
the
release
cycle
that
would
make
dogs
the
sick
dogs
and
other
people
in
the
docs
reviewer
team
will
make
their
work
will
make
it
more
comfortable
for
them
to
review.
So,
if
they're,
if
like
I,
could
get
some
some
pointers
like
by
this
week,
it
would
be
manageable.
Then
I
can
add
like
a
line
there,
just
for
a
just
as
a
pointer
for
me
to
start
letting
people
know
this
is
let's
do
this
yeah.
F
M
J
F
F
I
can
only
speak
to
the
number
of
PRS
I've
reviewed
last
week.
We
have
had
a
lot
of
fix-ups
on
the
release
blog
in
terms
of
not
only
from
the
technical
perspective,
but
like
minor
typo
edits,
which
are
okay,
I
guess,
but
we've
not
seen
them
as
a
trend
in
previous
releases,
so
I
guess
having
that
schedule
in
place.
What
really
helped,
because
you
know
again
everything's
snowballing
at
the
wrong
time
sort
of
makes
us
want
to
push
everything
out
of
the
door
before
you
know.
I
Yeah
big
just
want
to
say
big
plus
one
like
like
one
example
is:
you
know,
a
release
was
featured
in
the
release,
blog
that
actually
didn't
make
it,
and
so
like
being
able
to
make
sure
that
we
are
syncing
the
updates,
let's
say
that
we're
getting
from
docs
and
comms
together,
so
that
their
work
also
overlaps
right.
So
I
think
that
was
also
that's
also
something
that,
in
the
dark
side
of
things,
we're
able
to
then
bring
some
of
that
together.
I
If
comms
knows
what
is
happening
on
the
Dockside
too,
and
we
can
in
the
docs
either
meeting
or
in
any
other
really
says,
update,
we
can
combine
some
of
so
some
of
those
things
so
that
those
kind
of
release-
doxic
subs,
don't
happen
in
future.
Again,
that's
something
we're
willing
to
do
on
the
dock
side
in
our
meetings
for
status,
updates.
M
You
know
your
your
editing
environments,
if
that's
stuff
that
we
need
to
put
into
put
into
the
the
docs
handbook
as
a
as
a
guard
for
this
moving
forward,
but
we
should
try
to
classify
what's
coming
in
post
Post
Release
because,
like
this
is
again,
this
is
a
huge
huge
burden
on
Sig
dots.
I
have
to
try
to
reason
about
all
of
these
things
as
multiple
you
know.
Multiple
trains
are
leaving
the
station.
E
I
Sorry,
the
combination
part
just
to
clarify
my
sense
on
my
part-
is
that
docs
and
comms
updates
come
together
in
the
Sig
docs
meeting,
so
that,
like
those
kinds
of
updates,
are
being
heard
together,
so
that
if
there
is
things
that,
for
example,
for
some
reason,
the
comms
team
aren't
aware
of
on
the
dock
side
they're
getting
some
of
that
information
together.
Somehow
that
was
a
clarification
on
that
point.
Sorry
Steven.
M
Yeah,
no,
that's
that's
that's
cool
it
just
it
sounds
like
some
of
these
timelines
are
tightly
woven
together
or
some
of
these
masks
are
tightly.
Where
would
you
go
like
if
I
expect
the
you
know,
docs
and
comps
to
be
visiting
Sig
docs
and
in
tandem
that
they
have?
They
have
had
a
chance
to
to
sync
up
together
so
that
they're,
going
in
with
the
same
information
right
again,
suggesting
that
maybe
that's
the
same
team.
E
B
M
I'm
just
going
to
call
out
because
I
I
saw
this
conversation
pop
up
and
I've,
been
in
the
background,
listening
to
some
feedback
from
various
release,
team
members
and
and
folks
that
are
just
generally
involved
in
the
process,
including
Sig
docs.
The
I
want
to
call
out
that
the-
and
this
is
moving
into
I-
think
we
kind
of
run
into
this.
Every
every
retrospective
and
and
I
had
a
whole
I
read
about
it.
M
You
know
in
the
in
the
the
live
one,
but
one
of
the
responsibilities
of
this
group,
especially
in
handoff
moving
into
the
next
release
cycle,
is
to
make
sure
that
things
are
actually
handed
off.
Like
the
we
make
sure
things
don't
drop
right,
so
things
should
come
out
of
the
stock
land
in
as
issues
and
discussions
for
the
Sig.
M
For
you
know
for
our
stakeholder
cigs,
the
Emeritus
advisor
is
responsible
for
driving
that
across
the
team
to
completion
it's
the
next
Meritus
advisor
like
the
the
two
emeritance
advisors,
should
be
having
a
conversation
between
the
two
releases
and
handovers
should
happen,
and
the
new
Emeritus
advisor
should
be
coming
in
and
burning
down
the
backlog
of
retrospective
items.
In
fact,
that
is
the
first
responsibility
that
is
listed
in
the
Emeritus
advisor
handbook.
J
K
Yeah,
hello,
everyone
so
actually
I
I
talked
about
this
dashboard
long
time
ago,
maybe
10
releases
but
but
I
feel
like
it's
just
you
know
like
with
with
having
the
GitHub
projects.
It
might
be
easier
now
to
to
address
this.
So
why
don't?
We
have
a
a
project
dashboard
for
each
sub
team,
similar
to
the
bacteria,
the
enhancement
and
then
we
can
have.
K
We
can
have
another
dashboard
just
for
the
the
leads
and
Shadow
leads
to
have.
You
know
like
all
the
status
on
front
of
them,
so
they
can.
They
can
start
to
notice
some.
You
know,
like
maybe
an
issue
that
oh,
we
have
like
10
enhancements
here,
but
then
in
the
docs
they
said
they
have
11
enhancements.
So,
what's
going
on,
we
need
to
check
this,
and
you
know
like
all
this
stuff
can
be
handled.
If
we
have
all
the
numbers
and
there's
a
status
as
well
in
front
of
us.
K
I
know
it
might
take
a
little
bit
of
work,
especially
for
the
you
know,
like
the
the
lead
dashboard
but
happy
happy
to
help
for
the
sub
release.
Sub
teams
I
think
it's
doable
right
now.
We
can
just
do
the
same
thing
that
Pottery
agent
enhancements,
though,
and
just
make
sure
that
all
of
sub
teams
already
implementing
this
I
would
like
to
hear
from
you
all.
What
do
you
think
about
this
idea?
Is
it
feasible
or
not.
The
pros
and
cons.
J
Before
I
head
over
to
Stephen
I
think
each
sub
team
do
have
a
dashboard
right
now.
The
problem
we
face
is
that
the
tasks
that
are
not
on
the
dashboard
is
not
getting
done.
Things
like
syncing
up,
Brands
attending
sick
talks
meetings
and
so
I
I.
Don't
I
can't
visualize
what
that
would
look
like
I
think
it's
just
the
roll
up,
a
rolly
to
complete
those
things,
and
we
trust
in
them
that
they
will
do
it
we'll
hand
it
over
to
Stephen,
and
we
do
have
about
seven
minutes
left.
M
M
M
M
K
Sure
yeah
I
agree,
it's
I
I
think
it
might
be
like
a
combination
of
programmatically
and
just
reviewing
by
the
lead
for
this
sub
team.
For
example,
I
expect
I
would
expect
if
there
is
new
enhancement
and
list
of
the
GitHub
tasks
have
been
added
to
this
enhancement.
One
of
them
is
the
doc,
so
we
will
just
add
a
new,
a
new
column
or
a
neural
to
the
docs
and
communication
and
communication
dashboard
and
waiting
for
the
lead
to
confirm
that
it
will
be
included
in
this
release
or
not.
M
Yeah
I
think
you
know
people
process
tools,
so
you're
never
fully
going
to
automate
it
automate
something
away,
right
and
I.
Think
outside
of
just
how
you
know
for
for
Shadows,
on
the
call
for
Shadows
continuing
consider
how
you
can
be
empowered
with
additional
responsibilities.
For
your
section,
you
know
anecdotally,
when
I
was
shadowing,
this
group
I
effectively
took
over
the
role
from
or
because
there
were
things
that
I
wanted
to
do
and
he
was
like
go
for
it.
M
So
I
I
want
you
to
strongly
consider
how
you
can
more
deeply
get
involved
in
the
process.
If
you've
got
a,
you
know
if
you've
got
a
suggestion
for
improvement,
know
that
you
were
on
the
team,
because
your
voice
matters
in
the
discussion
to
make
sure
it
is
actually
heard
if
you're
ever
not
feeling
that
way.
We
have
both
the
the
the
shadow
feedback.
You
know
surveys
for
for
that
feedback,
as
well
as
reaching
out
to
any
of
the
leads
to
discuss.
G
I
I
just
had
another
item
very
much
similar
to
what
we
are
discussing
right
now
to
have
checklist,
GitHub
issues
checklist
for
every
role
lead
like
we.
Currently,
we
have
for
the
release
team
lead
itself
which
actually
lists
down
all
the
tasks
that
the
release
lead
is
supposed
to
do.
If
we
could
and
I
have
item
there,
but
I
can
park
it.
If
we
want
to
talk
about
it
later
or
I
can
talk
about
it
now,
if
you
have
time.
G
Yeah
yeah
I'll
just
quickly
walk
through
what
I
was
thinking
so
having
a
checklist
like
that,
would
help
in
many
ways
number
one
is
just
to
not
over
have
oversight
on
all
these
tasks
that
we
are
talking
about,
that
really
can't
be
programmatically,
maybe
monitored.
We
really
just
need
to
have
them
listed
there,
and
somebody
need
to
do
it
and
check
it
there.
So
I
think
for
me
that
checklist
is
helping
me
a
lot
because
I
everything
is
listed
down
for
me.
G
J
J
So
it
would
be
great
if
we
can.
You
know
own
that
and
start
that
in
1.29,
especially
for
docs
and
comms,
because
we
have
less
work
in
the
beginning
of
the
release.
We
do
really
have
to
move
on,
though
so
merging
bhaktriage
and
CI
signal
sub
team,
I'm,
not
sure
if
folks
have
anything
to
say
about
it,
except
that
we
need
a
tracking
issue
for
it.
M
Real
quick
and
this
question
had
come
up
in
the
background
too,
like
what
do
we
do
about
unresponsive?
I
think
just
also
with
the
Shadows
have
a
discussion
and
remove
them
right
like
if
you
were
not
doing
the
work
you're,
not
on
the
team
and
have
that
discussion
with
the
the
groups.
This
is
again
we
have
an
entire
Community
counting
on
us
to
execute
on
this
release
and
the
having
people
named.
Who
who
are
not
doing
the
work
is
not
fair
to
people
who
are.
J
J
Don't
think
I've
seen
an
instance
of
us
doing
that
before,
but
100
agree,
I
think
the
work
on
comms
is
really
difficult
on
Brad
and
Carol,
because
they
were
mostly
the
main
two
people
doing
it
at
the
peak
of
its
work,
but
also
a
reminder
to
the
role
leads
at
the
beginning
that
you
know
they
need
to
surface
this
as
soon
as
possible.
I,
don't
think
I
think
that
was
one
of
the
oversight
that
I
didn't
actually
find
out
that
the
Shadows
was
unresponsive
until
it
was
kind
of
too
late.