►
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
B
Excellent,
thank
you.
Okay.
I
I
will
give
an
abbreviated
abbreviated
summary
tldr
code
of
conduct.
Please
follow
it.
Retro
part
two
love
y'all
halfway
through
the
dock.
Let's
finish
the
dock.
Great!
Thank
you
tim
button,
so
we
left
off
kind
of
in
the
middle
of
a
couple
of
adolfo's
entries.
So
we
are
in
the
middle
of
the.
What
could
have
gone
better
section
of
119
adolfo?
Could
you
take
it
away
and
tim?
I
believe
you
have
your
hand
raised
for
once.
He
is
done.
C
A
A
The
information
is
sourced
from
github
we're
having
these
public
meetings
we're
discussing
it,
we're
putting
it
into
draft
documents.
We
can
and
should
coordinate
very
closely
together.
We're
not
the
embargo.
Word
doesn't
prevent
us
from
working
together.
This
comms
embargo
is
distinct
in
that
sense
from
say,
a
security
embargo
for
a
critical
vulnerability.
A
The
coms
embargo
is
a
term
that
comes
from
marketing
in
the
marketing
world.
You
have
something
that
you're
going
to
publish
and
it's
put
under
embargo,
sometimes
because
it
is
actually
truly
secret,
but
in
the
sense
here
it's
really
just
about
coordinating
the
date
with
or
the
timestamp
the
time
at
which
people
start
publishing
things.
A
So
the
the
idea
here
is
that
when
we
use
the
word
embargo,
people
in
marketing
or
pr
or
that
type
of
a
field
they
hear.
Oh
I'm
not
allowed
to
publish
my
blog
post.
Yet-
or
I'm
not
allowed
to
put
this
news
article
up
so
they
get
it
all
drafted,
it's
in
their
content,
management
system
and
they're,
ready
to
click,
publish
but
they're,
not
allowed
to
click,
publish
until
the
embargo
lifts,
and
then
everybody
does
it
at
the
same
time
not
everybody
adheres
to
this
embargo,
because
this
stuff
is
public.
A
So
you
will
see
some
media
sources
that
describe
the
kubernetes
release
before
it
is
released.
Those
are
people
who
are
not
participating
in
the
process,
but
it
exists
for
a
reason.
It's
a
coordination
reason
outside
of
the
team.
It's
the
point
that
everybody
knows
that
they
can
go
and
by
using
the
word
embargo,
it's
important
because
it
lets
them
know
that
they're
really
supposed
to
not
do
it
yet.
C
So
maybe
I
don't
know,
who's
dropped
this
to
the
status,
but
we
could,
because
one
of
the
things
that
happened
during
this
release
was
that
the
sig
leads
were
asking
us
to
to
show
them
the
major
themes
document.
Then
at
some
point
I
think
it
was
jordan
and
asked
after
asked
me
to
to
to
set
editing
and
human
rights
to
the
document
to
the
whole.
C
A
I
think
we
could
do
a
couple
things.
I
I'd
be
curious
to
go
back
and
look
at
past
ones.
I
suspect
we
didn't
have
them
shared
with
kubernetes
dev
fully,
but
also
I
don't
think
that
would
be
a
bad
thing
to
do
is
we
would
want
to
have
some
sort
of
header
at
the
top
that
says
this
is
josh
material.
It
is
not
complete,
it
is
embargoed
to
the
press
and
media
until
some
some
time
I
do
think,
probably
in
the
past.
A
If
we
look
at
the
docs,
they
were
probably
shared
with
the
milestone
maintainers,
which
is
a
pretty
broad
list
of
people,
so
that
might
be
something
that's
more
narrow
than
kubernetes
dev,
but
still
gives
the
people
who
are
going
to
want
to
give
input
the
ability
to
to
view
it.
But
we
we
could
look
at
that.
D
So
yeah,
so
just
a
note
there,
the
kubernetes
milestone
maintainer
group
has
been
archived,
so
we'd
have
to
look
at
an
alternate
group
for
that,
specifically
the
the
email
list,
not
the
github
team
but
yeah.
I
agree
that,
like
this
is
all
public
information
we
should
you
know
whoever
wants
to
access
it.
You
know,
even
if
we
gave
permission
to
kubernetes,
to
have
whoever
was
on
kubernetes.
That
would
then
have
access
to
it.
D
The
the
point
that
I
was
making
towards
the
end
of
the
part
one
was
not
so
much
to
get
rid
of
the
embargo
altogether.
It
was
just
we
need
to
put
a
fine
point
on
when
we
consider
the
embargo
to
have
been
lifted
right
now.
The
embargo
is
u.s,
specific
centric.
That's
what
that
that
time
has
been
in
in
the
past
and
we
I
don't
believe
we
need
to
do
that
anymore.
So
I
think
that
we
should
say
at
a
at
the
point
which
the
release
is
released
whatever.
That
means
right.
D
If
it's
for
for
different
teams,
it
means
different
things.
So
I
think
that
if
we
say
the
point
at
which
our
blog
goes
live
is
the
point
at
which
the
embargo
is
lifted,
for
external
consumers
right
and
if
that's
before
the
5
pm
est
5
pm
pst
that
I
think
going
sooner
is
helpful
to
them
because,
like
I
know
at
least
internally,
people
are
waiting
like
kind
of
waiting
on
my
go
like
yes,
it's
happening,
it's
happening
right
now,
it's
okay!
It's
going!
It's
going!
It's
gone!
You
can
do
it
now.
C
Yeah,
I
think
well,
this
was
just
a
well.
My
intention
was
to
raise
the
point
that
we
need
to
if
we're
going
to
improve
on
the
tooling
and
financing
process.
Just
to
maybe
we
can
discuss
the
actual
implementation
of
it
during
the
next
seek
release
meeting
so
to
to
let
know
that
there's
a
the
overlap
and
also
the
the
the
difficulty
of
improving
the
tooling
because
of
the
environment,
but
we
can
discuss
it
further
down
the
road.
A
On
the
specifics
of
the
time,
the
intent
there
is
not
to
have
it
be
specific
to
anywhere,
but
it
is
about
giving
a
an
indication
of
when
the
release
is
expected
to
happen.
It's
hard
for
us
to
know
that
because
we
always
have
surprises.
But
if
you
imagine,
there's
a
hundred
people
out
there
in
the
press
and
media
who
are
waiting
to
press
publish
on
their
content
management
system,
they
need
some
sort
of
alarm
a
calendar
reminder.
A
Somebody
needs
to
be
awake
watching
to
do
that,
so
they
they
look
for
the
guidance
of
when
it's
expected
and
that's
also
part
of
why
we've
tried
to
make
a
call
one
or
two
days
before,
if
we're
clear
that
we're
going
to
be
slipping
so
that
we
can
propagate
the
information
out
to
those
people.
So
they
know
to
be
watching
for
whatever
the
next
target
time
frame
is.
D
C
All
right
so,
regarding
the
next
topic,
so
as
many
of
you
here
know,
we
did
a
lot
of
automation
during
the
118
and
119
cycles
to
to
improve
the
release
notes
process
and
especially
during
the
119
cycle.
Most
of
the
job
was
already
automated
and
I
think
the
release
don't
steam
had
a
well
less
than
a
spectacular
time
shadowing
for
the
for
the
cycle.
Two
of
my
members
are
here
and
if
you
want
to
comment
on
that,
basically,
what
we
were
doing
were
was
just
waiting
for
the
next.
C
Release
to
cut
and
waiting
for
us
to
run
the
command
we
just
was
waiting
three
minutes
for
the
process
to
run,
and
that
was
it
and
attending
just
saying
green,
green
green.
On
the
on
the
meetings
and-
and
so
I
think
well,
we
were
pitching
some
ideas
which
are
further
down
the
documents
on
a
new
process
for
the
release
notes
team
to
implement.
So
I
just
wanted
to
say
the
intro
and
one
went
bad
because
we
had
a
lot
of
manpower
wasted
during
the
cycle
and
but
we
look.
D
All
right
so
the
goal-
my
maybe
not
so
secret
goal
that
we've
we
say
every
now
and
again
and
again,
a
few
cycles
is
that
the
release
team
should
eventually
go
away
one
day
in
the
future.
Enough
of
these
things
are
automated
and
we
have
people
who
are
consistently
looking
over
status.
Maybe
it's
not
a
full
team
right.
We've
we've
done
this
in
the
past.
With
the
the
test,
infra
role,
the
testing
for
role
was
completely
automated
away.
D
The
branch
managers
and
patrick
release
team
have
been
moved
to
a
separate
team,
a
separate,
org
right
they're.
You
know
they're
in
their
own
sub-project
now,
and
they
operate
kind
of
out
outside
of
the
scope
of
any
one
release
cycle
right.
So
so
I
don't
think
that
the
the
the
people
power
was
necessarily
wasted.
I
think
that
it
was
redirected
into
more
automation,
which
is
awesome
right.
D
A
lot
of
the
stuff
that
you've
you've,
written
up,
adolfo
and
and
worked
on
throughout
the
cycle
brings
us
to
taking
more
and
more
of
the
human
effort
out
of
the
process
right.
So
I
think
that
that's
that's
a
huge
one
in
terms
of
like
day-to-day
operations,
what
I
would
say
to
release
team
members
in
general
is
like,
if
you
have
nothing
to
do
like.
A
Cycle
we
did
do
a
survey
at
the
beginning,
but
the
well,
so
it
ended
up
being
the
beginning.
It
was
what
would
have
been
roughly
the
mid.
So
the
cycle
was
unusual
in
timing.
Yeah.
We
had
a
number
of
things
in
sort
of
the
may
time
frame.
If
I
recall
correctly,
as
emeritus
lead,
I
had
a
couple
of
meetings
with
all
the
shadows
and
then
we'd
also
done
a
survey
yeah.
Okay,.
F
F
G
E
H
H
We
try
to
tie
that
to
the
correct
sig
to
you
know,
ask
them
to
help
us
fix
it
or
to
get
them
to
fix
it
and,
and
that
can
have
varying
levels
of
success.
Everything
mentioned
here
is
not
necessarily
specific
to
1.19,
but
it
manifested
1.19
just
like
I've
seen
it
do
in
previous
releases.
So
I
think
it's
an
important
thing
to
bring
up
and
make
sure
we're
addressing.
H
So,
first
of
all,
you
know
just
communicating
with
sigs
the
primary
way
to
do
that
is
create
an
issue
and
tag
folks
on
it
that
actually
got
a
little
bit
better.
This
release,
I
think,
because
of
some
of
the
ways
we
handled
milestones
and
the
the
burn
down
on
the
1.19
milestone
on
those
issues
was
a
little
more
aggressive
than
I've
seen
in
previous
releases,
which
I
think
helped
with
that,
because
it
wasn't
just
the
ci
signal
folks,
pinging
cigs,
it
was
everyone
from
all
angles.
H
So
we'd
see
a
lot
that
you
know
someone
who's
newer
to
the
kubernetes
project
would
have
trouble
finding.
You
know
the
right
person
and
a
sig
to
to
make
sure
action
takes
place
which
you
really
shouldn't
have
to
do
right.
There
should
be
a
a
funnel
where
you
can
put
the
information
in
and
the
sig
pulls
it
off
the
bus
and
does
what
they
need
to
so
we'd
like
to
improve
that
process,
and
part
of
that
is,
is
motivating
cigs
to
keep
their
their
tests
at
a
certain
threshold.
H
I
mean
identifying
what
belongs
to
who
so
part
of
that
effort.
Is
things
we're
already
doing
like
making
sure
that
there's
contact
information
on
all
jobs
and
tests
and
so
that
it's
easier
to
triage
who's
responsible
for
a
test,
failure
or
flick?
But
it's
it's
still.
You
know,
there's
a
lot
of
work
to
be
done
there
and
there's
not
really
established
thresholds
for
saying
like
this
sig
is
doing
what
it
needs
to
do,
or
it's
not
doing
what
it
needs
to,
because
there's,
no
there's
no
measuring
stick.
H
So
I
think
that's
something
that
was
difficult
right,
because
any
sort
of
like
the
sig
is
doing
a
good
job
or
they're
not
is
is
all
anecdotal
from
ci
signal
or
from
other
folks
who
are,
you
know,
hitting
retest
a
bunch
of
times
on
their
pr.
So
I
think
that's
something
that
we
can
work
on
another
thing
that
gets
brought
up
pretty
frequently,
which
I've
seen
it
from
kind
of
different
parties
within
the
community.
H
H
So
I
know
you
know
at
9am
or
10am
whenever
we'd
have
the
meeting
every
day.
I
was
always
praying
that
you
know
it
would
turn
green
like
right
before
it's
like
all
right,
we're,
looking
good
like.
Let's
go,
and
obviously
that's
not
that's
not
helpful
at
all.
So
what
we'd
like
to
do
is
be
able
to
show
trends.
Be
able
to
show
you
know
healthiness
over
time
and
test
grid
gives
us
a
little
bit
of
that,
but
there's
the
the
disparate
thing
of
test
grid
showing
us.
H
Right,
because
a
lot
of
the
pushback
on
adding
new
tooling
is,
are
you
going
to
build
this
thing
and
then
leave
which
you
know
places
a
maintenance
burden
on
someone
who's
not
familiar
with
how
to
manage
something?
So
I
I
think
that
will
go
a
long
way
in
doing
that,
and
the
other
aspect
of
that
is
establishing
actual
kind
of
like
benchmarks
that
that
sigs
need
to
to
meet
for
for
us
to
say
you
know,
like
you're
you're,
managing
your
tests.
Well
right.
H
We
need
a
way
to
measure
that
we
need
a
way
to
present
that,
and
you
know
there
needs
to
be
incentive
for
people
to
respond
and
make
sure
their
tests
are
healthy
and
be
monitoring
them
and
make
sure
they're
testing.
The
right
thing,
which
is
you
know
a
whole
different
thing
outside
of
just
ci
signal.
Saying
this
test
is
failing
or
it's
flaking.
D
Yes,
yeah,
so
we
have
been.
I
think
that
the
the
work
that
has
happened
over
you
know
the
119
cycle,
everyone
who
jumped
in
for
ci
signal
improvements
across
release
and
testing.
It's
it's
been
really
phenomenal
to
to
see
that
pop
up.
I
think
that
I
forgot,
which
cycle?
Maybe
it
was
117
or
so
that
it
was
kind
of
determined
that
maybe
the
ci
signal
reports
were
not
useful
and
I
believe
that's
why
they
stopped
going
out.
D
But
overall
we're
hearing
that
communication
is
a
big
thing
and
given
the
given
the
change
in
frequency
to
the
community
meeting-
and
you
know
there
were
a
few-
misses
that
we
planned
to
to
shore
up
for
for
120.,
I'm
excited
about
seeing
the
ci
signal
project.
Subproject
kick
off
we're
going
to
be
working
on
that
first
thing
for
120,
and
we
already
have
the
the
sub
project
owners
lined
up.
D
I
think
part
of
one
of
their
long-term
goals
is
to
establish
established,
essentially
gating
for
the
for
tests
that
are
related
to
certain
things
right,
so
I'm
not
sure
exactly
how
that
would
work,
but
essentially
being
able
to
block
changes
to
certain
areas.
If
the
signal
looks
a
certain
way,
so
that's
in
discussion,
I
can
dig
up
their
proposal
unless
someone
beats
me
to
it
overall,
I
think
we're
moving
in
the
right
direction.
We
just
have
to
keep
the
foot
on
the
pedal.
I
B
G
H
G
H
H
G
Informing
the
community,
you
know
obviously
being
a
distributed
team,
that's
working,
asynchronously,
that's
that's
very
difficult
and
then
what
kind
of
modes
of
communication
can
we
identify?
That
will
be
helpful
for
the
community
and
allow
for
people
to
really
engage
and
feel
influenced
on
that?
I
think
that's
the
gist
of
what
josh
is
saying
there.
I'm
not
mistaken.
B
B
This
would
have
the
added
benefit
of
giving
that
team
activity
during
the
early
phases
of
the
release
taylor
you
mentioned:
what
would
the
thoughts
be
around
surfacing
the
release
schedule
on
the
kubernetes
website
to
increase
visibility,
and
maybe
even
utilizing
rss
for
updates
max,
don't
see
max
on
max
is
on?
Oh,
then,
I'm
blind,
I'm
sorry
go
ahead
max.
J
D
So
yeah,
so
given
some
of
the
feedback,
both
in
this
cycle
and
last,
I
think
we
have
some
opportunities
here
between
the
the
enhancements
team,
release,
notes
and
communications
to
get
together
and
talk
about
talk
about
major
themes.
Talk
about
enhancements,
incoming
talk
about
what
communication
looks
like
overall
for
the
community
from
the
quote
unquote
top
level.
I
would
plan
to
have
at
least
bi-weekly
comms
coming
out
from
sig
release.
D
That
would
include
include
updates
from
all
of
the
sub
projects
right.
So
so
things
you
want
to
know
like
how
the
next
dev
release
is
coming,
how
the
upcoming
upcoming
cherry
pick
deadlines.
The
plans
for
next
patch
release
cycles,
cool
tools
that
we've
written
recently.
I
think
there
has
been
a
lot
of
good
work
from
the
sig
that
we
have
not.
D
We
have
not
shown
off
as
much
as
we
could
and
I'd
like
to
I'd
like
to
make
sure
that
we're
doing
that
not
just
for
the
release
team,
but
from
a
little
bit
of
everybody.
So
I
think
that
if
you
look
at,
if
you
look
at
some
orgs,
where
the
where
leaders
may
send
a
you
know
a
monday
morning,
email
or
something
like
that,
what
usually
happens
is
friday.
You
know
friday
or
thursday.
D
They
have
all
of
the
their
sub
project.
Owners
essentially
essentially
send
in
updates
right.
So
maybe
we
can
do
something
like
that,
where
some
project
owners
can
kind
of
take
a
tally
of
what's
going
on,
and
we
can
send
out
updates
that
kind
of
encompass
the
entire
scope
of
the
sig.
That
sounds
good
to
people.
D
Yeah-
and
I
think
this
goes
beyond
a
maybe
internal
comms
calendar-
this
is
if
there
are
important
dates
that
we
need
to
publicize.
They
should
be
on
our
our
main
calendar,
the
one
that
we
show
for
the
release
right.
So
if
it's
a
you
know,
if
it's
a
date
that
is
highlighted
in
bold
or
something
like
that
right
and
the
activity
is
like
hey,
it's
the
you
know
it's
code
freeze
or
hey
it's
whatever,
whatever
milestone
right,
it's
you
know.
D
That
also
includes
some
communication
from
the
team
right
and
the
communication
can
probably
be
centered
or
handled
by.
Whoever
is
on
point
for
that
specific
area
right,
so
enhancements.
Freeze
enhancement
should
be
working
on
it,
release
notes.
They
need
major
themes,
they'll
be
working
on
that
and
I
think
that
the
communications
lead
can
probably
work
to
make
sure
that
that
is.
C
C
C
To
with
every
note,
every
new
note
that
comes
along
once
when
our
new
contributor
files,
a
new
pr
and
the
cradle
detects
the
new,
the
new
release,
note,
it
will
present
the
release
team
with
the
with
the
new
release
notes
for
them
to
review.
And
if,
if
they
accept
the
note
as
it
is,
it
gets
locked
and
if
they
don't,
they
have
the
chance
to
to
edit
the
content
right
from
the
start,
and
this
is
all
stored
in
the
in
the
release
directory
inside
of
sig
release.
C
And
so
you,
this.
This
gives
a
chance
to
the
release
team
to
bring
any
doubts
or
questions
during
the
release.
Meetings
to
the
whole
to
the
whole
release
team
for
them
to
review
I've
written
a
more
clear.
I
think,
documented
detailing
the
process
which
I've
linked
in
the
document
for
everyone
to
review
and
just
wanted
to
hear
everyone's
thoughts
on
that.
Whenever
you
have
get
a
chance
to
read.
B
D
So
in
in
working
on
these
tools,
I
think
what's
kind
of
cool.
Is
that
we're
seeing
some
of
the
same
patterns
emerge
right?
If
you
think
of
the
kept
ctl
that
a
few
of
you
on
the
call
are
thinking
about
and
working
on
for
for
enhance
for
the
enhancement
side,
we
started
to
talk
about
what
the
personas
look
like
for
these
various
tools
right.
We
have
kind
of
like
this.
D
This
intra
team
persona,
where
I
might
want
to
make
sure
certain
metadata,
looks
good
right
or
you
know,
or
you
take
the
reviewer
approver
persona.
You've
got
also
the
passerby
persona,
who
may
just
want
to
see
what
these
things
look
like
right.
So
you
know
for
the
passerby
you've
got
the
release,
notes
website
right
and
for
the
for
a
day-to-day
editor
who
may
be
on
the
release.
D
Team
you've
got
one
view
right,
so
just
starting
to
think
about
the
functionality
that
could
hold
for
someone
who
is
actively
doing
the
work,
but
also
someone
who
is
in
a
sig,
maybe
a
milestone,
maintainer
reviewer
approver
that
may
want
to
edit
notes
on
site,
because
it
would
be
great
to
shard
that
work.
More
towards
the
sigs,
the
the
the
goal
is
hopefully
to
have
less
work,
be
be
done
on
the
release.
D
Right
so
so
what
do
we
have
to
discuss
with
kep
ctl
is
being
able
to
filter
down
to
sig.
Right
so
say
I
want
to
review
release
notes
that
live.
I
want
to
review.
Release
notes
are
kept
or
something
that
that
are
for
my
sig
specifically
right.
Maybe
I
want
to
edit
the
content
of
the
release
notes.
How
does
that
flow
potentially
work?
Can
I
edit
the
release,
notes
in
such
a
way
that
it
will
that
it
will
generate
a
pr
that
I
can
that
I
can
post
somewhere?
D
Will
the
content
potentially
given
I
provide
a
github
access
token.
Can
I
then,
assuming
I
have
the
appropriate
rights
on
the
repo
edit,
the
release,
notes
that
are
actually
on
the
pr's
right,
so
future
generation
is
always
correct
right
so
that,
like
making
sure
that
all
the
the
various
content
streams
that
we're
getting
from
from
like
start
to
eliminate
the
human
requirement
around
it
right,
if
we
have
constant
editors
that
are
pushing
accurate
data
to
the
right
places,
then
there's
less
cleanup
for
you
to
do
at
the
end
of
the
cycle.
C
E
E
E
So
I'm
talking
to
some
folks
here
about
how
we
might
reformat
some
of
the
meetings
to
gain
more
space
and
time
for
that
boardwalking
effort
and
then
also
we
can
always
try
out
the
asynchronous
approach
as
well
one
tool.
We
would
like
to
try
out
that
to
supplement
the
project
boards
is
triage
party.
I've
included
the
link
here.
Many
of
you
have
probably
seen
it
already.
It's
it's
a
multi-player
triage
board
set
up
by
thomas
stromberg
and
it's
in
use
in
mini
cube
and
scaffold
and
a
couple
other
projects.
E
E
Let
issues
sit
without
a
response,
or
how
long
would
we
be
comfortable,
letting
a
pull
request
sit
in
our
in
our
backlog
without
a
merge,
I've
prototyped
what
the
sig
release
triage
party
can
look
like,
and
I've
included
the
link
here
for
your
review,
but
basically
it
spells
out
some
of
those
roles
I
haven't.
I
haven't
put
those
slas
in
my
suggestions,
so
that's
up
for
debate,
but
essentially
once
we
figure
out
the
consensus
on
how
long
our
delays
our
slas
would
be,
then
we
can.
E
D
No
only
because
it's
the
retro,
but
this
is
the
right
meeting
for
it,
I
think
that's.
I
think
that
we
have
multiple
problems
that
we've
already
kind
of
discussed
in.
In
various
conversations
there's
I
would
like
to
see
triage
us.
Have
the
capability
to
do
triage
asynchronously
and
have
the
meetings
as
one
we
need
to
do
triage
in
meetings
as
well
right
only
because
we
have
such
an
enormous
backlog
of
things
to
do
and
a
lot
of
them
are.
D
The
trickier
part
is
a
lot
of
the
long-standing
issues.
Are
big
they're,
very
big
they're
they're
multi-cycle
projects,
some
of
them
and
some
of
them
have
you
know
some
of
them
have
made
a
decent
amount
of
progress.
I
think
that
one
we
need
to.
We
need
to
establish
triage
so,
like
tim
said,
plus
100
to
to
moving
that
forward.
We
also
need
to
get
out
of
the
game
as
the
sig
of
triaging
other
people's
issues.
D
That's
that's
a
big
portion
of
it.
We
need
to
make
it
easy
so
acting
as
guinea
pigs
for
triage
party,
I
think
we
should
be
working
towards
also
establishing
potential
triage
patterns
right
just
in
general
and
things
that
can
be
mimicked
by
other
cigs
lori.
I
know
you're
already
doing
work
on
that
on
how
to
chat
with
like
node
and
network,
about.
D
Yeah,
so
so
I
think
we're,
I
think
I
think
we're
on
the
right
path.
I
think,
from
the
perspective
of
the
chairs
and
technical
leads
and
and
lori,
of
course,
it's
going
to
be
our
job
to
break
down
a
lot
of
the
chunkier
issues
into
things
that
are
more
digestible.
I
think
that
a
lot
of
the
things
that
have
not
had
movement
is
because
they're
just
really
large,
and
we
run
out
of
time
to
to
think
through
all
of
that
stuff,
so
we
definitely
want
to
get
more
hands
on
deck.
D
So
there
are
things
that
I
kind
of
drive
towards
and
tim
drives
towards,
and
now
that
we
have
more
people
on
the
crew,
we
can
have
more
people
driving
towards
that,
but
we
should
be
able
to
put
up
kind
of
what
the
road
map
looks
like
for
the
sig
and
what
you
know
what
our
major
themes
are.
Personally,
as
we
move
into
the
next
few
cycles,.
E
E
A
lot
faster,
we'll
gain
a
better
understanding
and
more
control
over
it,
and
it
will
help
spread
knowledge
incrementally
because
it
leads.
When
we
talk
about
these
issues,
it
leads
to
discussions
about
them,
which
means
that
we
end
up
communicating
more
regularly
about
what
we're
trying
to
do
and
that's
helpful
as
a
team.
F
F
K
D
Yeah
yeah,
primarily
time
really
is,
is
what
it
comes
down
to
so
going
over.
I
think
it
was
deemed
to
not
be
useful
to
go
over
the
same
things
over
and
over
and
over
expect
progress
updates
right.
So
the
I
think
part
of
it
is
also
the
the
team
is
very
focused
on
executing
on
on.
You
know,
what's
detailed
in
their
handbooks
as
opposed
to
stuff
that
is
listed
as
maybe
assigned
to
the
team
for
for
the
cycle.
E
E
D
Go
ahead
so
yeah,
I
think
one
of
the
biggest
drop-offs
that
we
have
is
the
transition
from
cycle
to
cycle.
As
we
rotate
in
an
entirely
new
team.
We
have
a
bunch
of
assignees
on
topics
that
may
not
be
working
in
our
area
anymore,
so
it's
important
to
figure
out
how
we
handle
that
handoff
and
how
we
do
that
quickly,
so
that
we
can
get
the
the
next
team
focused
on
it.
E
E
Cool
all
right,
so
the
next
item
is
setting
up
a
leads
monthly
sync
to
drive
more
collaboration,
teaminess
and
knowledge
exchange
around
strategy
and
also
workload.
This
is
done.
I
sent
out
the
invites
today
this
kind
of
aligns
with
the
point
about
the
emergency
advisor
and
that
it's
a
way
for
us
to
build
more
culture
into
the
release
team
and
for
that
person
lockheed
to
hear
what
all
the
leads
are
saying
and
what
they're
struggling
with,
etc,
to
be
able
to
help
them.
E
E
So
I'm
looking
for
ways
to
do
that,
and
one
of
the
things
I
did
last
week
was
to
reach
out
to
all
cigs
to
see
if
they're
doing
the
future
health
check
a
la
signode,
which
I
have
linked
their
feature.
Health
check
check
doc
here.
If
you
can't
access
it,
let
me
know
I
have
a
screenshot
of
it,
but
basically
this
is
you
know
what
what
is
coming
down
the
pipeline
for
120.
E
This
is,
with
the
intents
of
understanding
like
having
a
plan,
not
not
planning
waterfall
like
all
the
way
through,
but
what
do
we
know
today
would
be
really
high
impact
so
that
we
can
unblock
ourselves
or
get
long-standing
items
done
and
be
able
to
move
to
the
next
item.
So
I
gave
an
example
here.
Some
of
you
have
already
seen
this
stock.
It's
six
user
stories
based
on
old
retro
items
and
things
in
the
backlog
for
the
release
team
that
you
all
helped
prioritize
over
the
summer.
B
B
G
No
I'm
back
back
back
at
home,
not
on
the
road,
so
not
touching
traffic.
So
this
is.
This
is
kind
of
in
line
with
what
stephen
had
said
about
you
know.
Just
let's
get
things
automated.
Let's
try
to
make
this
each
release
the
best
one.
We
could
possibly
do
with
the
tools
that
we
have.
This
is
around
creating
more
tooling,
and
you
know
there
were
a
couple
opportunities
identified
during
this
release
cycle
like
hey,
we
might
be
able
to
automate
calendar,
invites
and
kind
of
getting
you
know
just
overall
administration.
G
Basically,
let's
get
the
rid
of
the
things
that
don't
make
sense
to
have
the
release
team
focus
on
you
know
just
because
it's
either
toil
or
just
there's
a
better
way
to
do
it,
and
so
in
120.
I
think
it'd
be
helpful
for
us
to
identify
those
efforts
and
to
kind
of
start
creating
more
tooling
around
that.
I
know.
We'd
already
said
that,
but
this
is
just
another
nod
in
that
direction.
Until
we
all
join
the
singularity
and
become
cyborgs
yeah,
we
still
need
to
make
some
help
on
that
phone.
B
All
right
that
went
zero
to
a
hundred
real,
fast
stephen,
if
you're
trying
to
automate
out
my
life.
I
am
gonna
have
some
problems
with
that,
but
you
know
I
have
faith
that
I
don't
know
I
will
become
borg.
Okay,
we
are
at
the
bottom.
Does
anyone
have
anything
else
they
would
like
to
add
or
talk
about?
We
do
have
five
minutes
left.
Thank
you,
lori
for
absolutely
blitzing.
Your
three
entries.