►
From YouTube: FCL 5931 Closing Ceremony
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).
A
A
Point
two
christopher
asked
about
communication
comments
and
some
confusion
between
rca
and
fcl
and
specifically
in
this
incident,
how
it
impacts
decomposition
with
the
sharding
group
working
on
reliability
issues
anyway
and
christopher
was
clarifying
his
thoughts
on
how
you
group
the
work
under
the
fcl,
and
you
can
make
it
clear
that,
yes,
we're
going
to
continue
on
the
reliability
work
that
we're
already
doing
anyway,
but
just
make
it
explicit
that
it's
under
an
fcl
and
include
any
new
discoveries.
So
did
I
recap
what
you
were
saying
correctly
christopher
up
to
this
point?
That's
I.
C
So
I
I
actually
recently
was
asked
about
the
fact
that
how
does
that
work,
if
you're
in
the
fcl
and
you're
already
working
on
reliability,
work
and
you
have
to
toggle.
So
maybe
the
original
question
christopher
you
were
asking
is
what
what
can
I
do
to
decouple
this
idea
so
that
people
have
a
better
understanding.
C
So
I
would
go
back
to
the
handbook
and
see
if
there's
to
make
sure
that
it
could
be
in
there.
We
didn't
read
it
right
to
make
sure
it's
clear
that
you
have
a
lot
of
control
in
fcl
and
if
you
want
to
you,
know,
use
your
current
reliability
work
that
you're
doing
as
part
of
scope.
You
can
make
that
because
I
think
that
that
people
are
not
getting
that
from
the
handbook.
B
D
Yes,
I
kind
of
like
it
got
me
interested
christopher
what
you
kind
of
said
about
rca
and
fcl,
because,
like
trunk
rightfully
identified
that
a
lot
of
these
corrective
actions
were
kind
of
in
the
gray
area
that
like
outside
of
maybe
the
the
the
composition,
it's
more
like
general
ability
issues
that
may
be
prevalent
in
general,
like
more
of
broaden
failures
from
occurring,
and
it
seems
that
we
kind
of
probably
got
it
right.
D
According
to
your
description,
that
we
look
a
little
much
broader
than
this
particular
incident
in
trying
to
how
we
can
fix,
like
the
the
scope
like
how
we
can
expand,
to
reduce
like
this
type
of
the
issues
like
implement,
zero
century
exception
policy
for
one
there
were
like
a
few
of
these
like
gray
area
items
that
were
much
broader.
B
Yeah,
I
think
that's
exactly
right
so,
like
you
should
view
an
scl
as
opportunity.
What's
the
opportunity,
like
a
lot
of
people
view
it
as
a
lot
of
people
are
viewing
this
punitive
that
should
be
puna
because
we're
trying
to
be
blameless
here
right
but
like
we
should
do
this
opportunity.
So
what's
the
opportunity?
Well,
the
opportunity
is,
if
you
come
up
with
other
areas,
that
we
should
improve.
B
Here's
the
five-day
window
that
you
can
actually
go,
do
that
as
opposed
to
like,
if
you
were
working
on
existing
feature
work
you
know
product
would
be
prioritizing
that
prop
that
that
work
right.
So
it
does
mean
that
something
does
give
that
situation
which
is
potentially
feature
development,
but
it
does
give
us
that
opportunity
to
potentially
fix
some
issues
that
you
know
if,
if
we're
really
gonna
get
better,
one
of
the
things
we've
got
to
continuously
think
about
is
is
like
how
we
improve
the
product
as
we're
going
along
in
future
development.
B
A
So
clarifying
question
in
this
case
so
under
this
one
here
so.
B
Maybe
let
me
finish
that
thought
just
because
I
know
there's
more
aspects
before
you
ask
your
clarifying
question,
but
so,
like
some
things
that
you
think
about
may
take
longer,
in
which
case
those
go
on
the
backlog,
it's
a
question
of
you
know
like
if
they
go
on
the
backlog
versus
like
we
do
it
right
now
and
that's
that's
what
the
fcl
is
trying
to
do
is
give
you
that
opportunity
to
do
it
right
now,
as
opposed
to
waiting
on
a
backlog
where
it
may
never
get
prioritized
right.
So
I
think
that's.
B
The
other
thing
we
run
into
is
as
we've
seen,
particularly
with
a
lot
of
these
incidents.
Someone
will
bring
up
an
issue.
That's
been
opened
eight
or
two
years,
eight
months
ago
or
two
years
ago,
hopefully
not
eight
years
ago.
For
that
far
back,
then
we're
really
in
trouble,
but
you
know
eight
months
or
two
years
ago
and
that
we
just
never
got
around
to
addressing
so
like
this
is
a
way
to
potentially
bring
that
in
before
that.
D
So
then,
the
question
is
three
because
they're
gonna
be
a
hard
stop
on
some
of
these
items,
how
we
can,
how
or
like
to
whom
we
would
transfer
responsibility
or
or
whether
do
we
close
that
or
we
kind
of
leave
it
like
lingering
around
but
like
who
will
continue
owning
that
visual
ability
items
because
I
think
like
if
we
know
that
something
just
takes
longer,
and
we
are
time
limited
to
five
days
and
we
know
that
it's
gonna
be
lingering
around
and
we
cannot
find
like
the
let's
say,
the
the
sponsor
or
someone
saying
that
it's
gonna
continue
doing.
D
That.
Is
it
really
like
the
best
time
spent
for
us?
Should
we
because,
like
there,
is
a
balance
between
like
long-term
items,
that
we
see
like
a
general
improvement
and
someone
needs
to
like
continue
doing
that
after
these
five
days?
But
there
is
also
maybe
like
a
stream
of
the
smaller
items
that
maybe
we
can
finish
in
this
five-day
window.
So
where
is
the
balance?
Oh
yes,.
B
D
B
So
like
in
the
case
where,
like
we
try
to
get
some
of
them
done,
hopefully
we
can
break
it
apart
enough
that
we
could
get
at
least
some
some
elements
done
within
the
five-day
window,
and
then
they
should
be
added
to
the
backlog
and
that
it's
engineering
manager's
responsibility
to
make
sure
they're
advocating
for
these
as
part
of
normal
prioritization
for
consideration.
B
It's
also
a
good
opportunity
for
us
to
advocate,
for
potentially
is
the
team
appropriately
staffed,
and
do
we
potentially
need
to
add
folks
to
that
team
as
part
of
that
discussion,
so
I
think
I
think
that's
right
now
kind
of
my
thinking
around
it
now
understand
that,
like
the
other
thing
that
happens
in
fcl
is
once
you
start
something,
you
should
finish
it
like
the
other.
You
could
technically
be
outside
of
the
scl
scope,
but
you
should
still
work
to
completion
on
that
activity.
It
doesn't.
B
Could
start
something
that
has
a
year
commitment
potentially
during
the
fcl,
or
at
least
it
would
require
higher
level
approval
if
we're
gonna,
if
we're
gonna
go
to
that
level.
But
you
know
that's
that's
where
we're
trying
to
think
in
terms
of
of
balance
there.
So,
but
you.
D
B
My
short
answer
right
now
is:
it
should
go
into
our
backlog
and
then
it's
it's
engineering,
manager's
responsibility
to
advocate
for
for
basically
that
as
part
of
normal
prioritization,
and
if
they
can't
get
a
prioritized
effort,
then
they
need
to
escalate
on
those
to
so
that
we
can
figure
out
how
we
best
solve.
For
that.
D
D
B
I
think
I
think
I
would
look
towards
approval
from
jerry
yourself-
probably
anybody
principal
plus,
to
give
us
some
validation
that
that
might
be
the
answer
in
the
short
term.
B
I
don't
know
if
I
don't
know
if
I
have
a
better
answer
right
now
than
just
our
senior
iec
saying
this
is
the
right
thing
to
do.
Some
of
that
would
be
infrastructure.
Some
of
that
would
be
also
within
the
development
team.
B
D
Yes,
because
this
is
kind
of
like
gray
area
of
the
current
process,
the
way
how
I
see
that
and
like,
though,
what
we
actually
do,
we,
it
actually
makes
sense.
To
be
honest,
that's
really
like
the
answer
that
I'm
looking
for
because
then,
if
you
are
spending
five
days
on
doing
something
that
has
very
little
benefit,
there
is
no
point
of
doing
that
in
the
first
place,.
B
Yeah,
I
would
hope
I
would
hope
the
team
has
bought
into
the
right
things
to
focus
on,
but
like
like
having
a
strong
advocate.
That's
one
of
the
responsibilities
of
principal
plus
is
basically
advocacy
right
for
like
what
are
the
right
things
to
do
as
a
architecturally
as
well
as
for
for
these
different
aspects.
So
that
would
be
kind
of
my
answer
at
this
point.
B
If
there's
a
staff
member
on
the
team,
I
would
hope
they
would
collaborate
with
either
camille
or
stan,
or
one
of
our
recently
promoted
principles
would
be
my
answer
right
now
is
like,
like
we
have
enough
scope
that,
like
I
feel
like,
we
should
make
it
a
little
tighter.
We
might,
we
might
push
it
to
staff
eventually,
but
what
I
don't
want
to
do
is
I
don't
want
to
see
a
lack
of
collaboration
because
of
that.
B
Yeah,
this
is
not
like
a
like
for
this
type
of
decision.
It's
not
like
a
like.
They
have
to
be.
The
person
has
to
be
knee
deep
in
that
part
of
the
product.
They
just
need
to
be
able
to
look
at
it
and
say:
okay,
is
this
consistent
with
the
rest
of
our
architecture?
It's
because
it's
consistent
with
how
we're
attacking
reliability,
and
I
view
that
that's
much
more
cross-organizational.
So
that's
why
I
would
limit
it
to
that
layer.
Those
layers.
B
But
I'll
be
open
to
people
find
later
on
that
that's
not
pragmatic,
in
which
case
we
could
lower
it,
but
it
feels
like
we
should
start
with
the
tighter
group.