►
From YouTube: Closing Ceremony - Threat Insights Feature Change Lock
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
Hey
everybody:
this
is
our
closing
ceremony
for
the
threat,
insights
front,
end
teams
feature
trains
lock
that
occurred
over
the
last
two
weeks
and
it
is
june
16th
cool.
So
today
I
want
to
celebrate
the
fcl
and
review
the
retrospective
con
feedback
from
the
team
and
then
also
review
the
the
changes
that
we
actually
put
into
place
as
well,
so
that,
because
I
know
everybody
is
working
on
somewhat
different
things,
I'd
like
to
bring
all
that
together
so
are
all
well-versed
and
what
all
was
accomplished,
because
it
was
pretty
significant
awesome.
A
Well,
firstly,
I
want
to
thank
everybody.
It
was
an
amazing
experience
for
me.
I
think
I
would
grateful
for
the
company
to
have
a
process
like
this
that
was
already
well
structured,
so
gave
us
good
direction,
but
then
the
immediate
adoption
of
the
team,
the
positivity,
the
attitude
which
is
like
sweet.
I
understand
why
let's
do
it
and
what?
How
can
I
help?
A
And
so
there
are
a
lot
of
creative
ideas
coming
in,
even
even
following
people
were
like
well,
what
if
we
did,
this
is
this
another
opportunity
so
we're
actually
adding
scope
after
we
started
so
just
having
that
behavior
that
culture
of
the
team
was
was
really
amazing
to
to
be
part
of.
So
thank
you.
Everybody
in
terms
of
the
things
I'm
going
to
share
my
screen
and
we'll
walk
through
the
actual
accomplishments
that
we
had,
and
it's
pretty
neat
so
looking
at
our
epic
I
apologize.
A
I
was
attending
to
intending
to
rearrange
these
and
kind
of
what
the
priority
order
was
initially,
but
it's
kind
of
sporadic
now
based
on
the
closing
status,
but
first
off
you
know
we
got
the
the
core
fix
back
in.
That
was
significant
right.
That
was
a
lot
of
collaboration
with
back
ends,
basis
and
samantha
and
dave.
You
know
really
put
thought
into
this.
How
do
we
separate
this
work?
How
do
we
be
methodic?
A
How
do
we
slow
down
as
well
to
make
sure
we're
super
comfortable
with
this,
and
so
ultimately
we
had
two.
Mrs,
I
don't
know
if
they're
represented
in
this
this
fcl
issue
specifically,
I
think
they
might
be
linked
up
in
the
comments,
but
the
the
work
merged
back
in
was
last
week
the
front-end
stuff
went
in
in
the
last
two
days.
I
think
it
was
verified
yesterday.
A
It
looks
amazing,
there's
a
lot
of
you
know
additional
steps,
verification
steps,
checking
out
the
staging
environment.
I
was
also
monitoring.
You
know.
I
think
one
of
our
emphasis
is:
how
can
we
you
utilize,
staging
more
when
possible,
so
I
was
kind
of
monitoring
that,
mr
as
soon
as
I
did
staging,
I
was
going
to
verify
so
there's
neat
little
behaviors
like
that.
A
A
In
terms
of
pro
you
know
extending
our
coverage.
So
this
is
something
harsha
helped
with
was
we
had
a
big
realization
that
our
end
damn
tests
don't
run
when
we
expect
them
to?
I,
for
one
was
thinking
they're,
gonna,
they're
running
all
the
time,
they're
running
through
the
mr
every
time.
There's
a
new
pipeline
run.
A
We're
getting
into
test
coverage
when
in
fact
it's
it's
just
too
expensive,
there's
too
much
compute
time
for
all
these
tests
to
run
all
the
time
now,
so
they're
run
more
on
a
schedule
and
that's
likely
only
going
to
hit
staging
and
prod.
After
you
know,
the
changes
have
been
deployed,
and
so
harsha
and
other
team
members
collaborated
quite
a
bit
on
creating
a
some
guidelines
on
getting.
A
A
A
You
know,
especially
if
anything
is
impacting
the
front
end
or
the
user
workflow
and
then,
along
with
confirming-
and
thank
you
for
the
team
members
that
really
helped
with
what
this
workflow
looks
like
you
know
the
best
way
to
approach
this
and
trigger
these
pipelines
and
also
experimenting
with
this
I
know
samantha.
I
saw
a
comment
from
you
that
you
were.
You
were
following
along
on
an
issue
like
this
or
a
similar
one
saying
I
triggered
this.
You
know
based
on
these
instructions
in
staging
I've,
triggered
the
pipeline
and
it
succeeded.
A
Let's
see
extending
so
one
thing
that
happened
with
the
the
incident
itself.
Is
we
received
both
the
century
error
that
was
captured
by
a
back
end
team
issue?
I
guess
the
sensory
issue
that
really
isn't
in
our
purview
as
front
and
team
members,
including
myself.
We
also
had
an
end
and
test
failure.
That
was
also
escalated
into
an
issue,
but
again
there
wasn't
communication.
A
There
wasn't
visibility
on
that
either
and
so
and
right
now,
what
we're
going
to
do
is
is
harsha
is
going
to
ping
me
and
possibly
the
team
when
there's
any
end
test
failures
that
allow
just
us
to
have
that
immediate
visibility.
If
something
seems
awry
that
we
can
react
to
that
and
again
thiago
and
his
team
will
will
ping
me
I
we're
still
contemplating
if
we
should
do
the
whole
team
or
not.
I
think
it's
going
to
be
based
on
the
amount
of
noise
that
creates,
because
not
every
issue
is
going
to.
A
You
know
pertain
to
us
thiago,
and
I
are
also
working
on
an
automated
process
that
when
these
century
issues
are
created,
that'll
actually
automatically
ping
or
notify
certain
individuals
as
well.
So
we
have
retroactive
automation
in
place
where
it
can
look
for
issues
that
have
a
certain
event
take
place,
so
the
condition
would
be
if
it's
a
threat
inside
sentry
issue
then
go
ahead
and
also
assign
it
to
to
me
would
be
the
use
case.
So
I'm
looking
forward
to
that
because
it'll
take
the
manual,
I
think
anything
we
can
automate
will
be
beneficial.
A
A
It's
that
you
know
what
this
is
the
and
I
added
a
retrospective
topic
for
the
the
15
one
retro
on
this,
but
this
is
actually,
unfortunately,
in
our
protect
page
currently
and
it's
not
even
in
our
protect
page,
it's
in
our
refinement
process,
which
includes
how
we
do
verification.
So
my
apologies
because
that's
the
whole
basis
of
my
retrospective
issue
is
I'm
a
little
confused.
Why
we're
directing
threat
insights
team
members
to
a
handbook
page
over
on
the
protect
space?
A
For
pto
section
that
covers
what
we
should
be
doing
pertaining
to
active,
mrs,
so,
mrs
that
aren't
in
draft
status,
mrs
that
were
recently
merged,
but
haven't
yet
deployed
to
the
different
environments.
How
should
we
handle
that?
That's
really
cool,
so
an
additional
additional
to
these
steps,
which
every
team
membership
should
be
reading
through
and
I'll
go
ahead,
and
summarize
these
all
in,
like
a
synopsis
with
references
out
to
these
links.
That's
what
I
was
going
to
be
doing
on
the
the
epic
down
here
is
I'll.
A
A
That
was
only
looking
at
the
the
author
of
the
mrs
previously
and
then
so
now
it's
actually
going
to
prefer
the
assignees
of
an
mr
and
it'll
default
back
to
the
author,
if
there's
no
assignees
and
so
that
what
that
means
is
when
somebody
goes
on
pto
and
they
want
to
hand
off
nmr,
they
can
reassign
that,
mr,
and
that
means
that
new
assignee
will
actually
get
that
notification,
that
it's
ready
for
verification.
So
we
won't
have
that
that
oversight.
A
This
was
a
more
straightforward
one,
because
we
already
had
a
really
good
verification
policy,
so
I'll
jump
into
that.
But
that's
just
that
we're
expected
to
verify
and
staging,
where
possible,
with
the
understanding
that
window's
very
short,
it's
probably
going
to
be
overnight
in
most
cases,
but
we
should
still
strive
and
attempt
to
verify
in
staging,
but
we
should
also
we
should
most
definitely
be
verifying.
You
know
in
production
and
as
a
team.
One
of
our
our
things
that
we're
doing
is
somebody
else
on
the
team
should
verify.
A
A
A
And
this
one's
awesome
going
back
to
that
contributing
section,
so
a
big
takeaway
from
the
fcl
was
okay.
This
was
front
end
team
members
working
in
ruby
and
back-end
code
that
sucks
that
we
caused
an
issue.
I
don't
want
to
diminish
that
that
excitement
that
I
had
previously.
I
want
to
encourage
it.
So
how
can
we
increase
our
confidence
in
working
on
back
end
work,
and
so
this
was
an
issue
that
david
sabash,
I
know
others
contributed
to
this
as
well,
but
ultimately
we
created
a
this.
A
Also,
this
contributing
section
contains
this
crosstalk
collaboration
section,
which
is
some
really
introduction.
You
know
guidelines
to
we.
We
encourage
this.
These
are
some
things
that
we
should
be
doing
if
we're
looking
at
that
it's
it's
predominantly
working
closely
with
a
domain
expert
within
the
team
and
also
that
initial
review
making
sure
we're
leveraging
somebody
within
the
team.
So
if
we're
working
on
a
back-end
change,
we
should
be
looking
at
a
back-end
engineer
within
thread
insights,
to
do
that
review
for
us
and
then,
lastly,
is
increasing
our
test
coverage.
A
So
savash
and
tsubasha
collaborated
on
this
one
and
it
was
identified
that
we
knew
what
the
additional
coverage
was
necessary
for
the
for
the
fix
that
we
put
up
sebastian
savash
did
a
sync
session
where
savashas
walked
through
to
further
educate
our
team
on
like
what
this,
what
this
is
doing.
So
we
can
kind
of
understand
and
empathize
how
back-end
tests
work
and
why
there's
additional
things
we're
probably
not
even
thinking
about
there
was
this.
You
know
the
flags
we
talked
about
earlier
that
you
can
toggle
manually.
A
We
identified
that
those
could
be
more
clearly
or
maybe
they're,
not
right,
now
documented
in
our
handbook
on
our
docs.
So
we
have
a
follow-up
issue
from
that
to
make
sure
that
we've
represented,
you
know
how
how
exactly
this
this
switch.
You
know
functions,
sweet.
So
that's
that's
what
we
contributed
or
completed
in
this
fcl.
It's
it's
a
lot,
I
more
than
once
celebrated
when
I
was
doing
the
the
stand-up
update.
A
So
I
was
going
to
reliability
in
allocation
meetings
to
provide
a
stand-up,
and
often
I
was
just
expressing
how
much
the
team
is
doing
that.
One
of
the
reasons
we
extended
the
fcl
a
little
bit
is
because
we
we
bit
off
a
little
bit
more
than
we
expected.
I
said
it
would
be
nice
to
cut
through
these.
I
don't
necessarily
think
we
need
to
complete
all
these
to
close
off
the
fcl,
but
I
think
the
team
would
appreciate
just
having
a
little
bit
more
breathing
room.
A
A
Expectation
is
okay,
the
team
broke
something,
let's
fix
it,
let's
be
more
cautious
and
you
know,
and
then
let's
look
for
process
opportunities,
but
in
our
case
we're
like
no,
we
can
do
better
like
these
are
some
things
that
are
hanging
out
there,
there's
opportunities
for
the
team
to
approach,
and
so
we
just
killed
it
sweet.
So
then.
A
A
You
should
be
doing
this,
create
a
slack
channel,
create
an
issue
creating
epic
stuff,
like
that.
Additionally,
there
was
the
retrospective
done.
So
this
is
pretty
neat,
but
we
can
see.
I
think
this
goes
till
march.
You
can
see
that
11
other
feature
change.
Locks
have
taken
place
between
september
and
march.
I'm
not
aware
of
any
that
have
taken
place
since
march,
but
let's
assume
a
couple
did
that's
quite
a
bit,
so
it's
a
lot
of
teams
kind
of
learning
before
us.
A
What's
this
look
like
what's
the
sentiment
of
the
team,
and
so
this
retrospective
was
conducted
around
how
it
went.
You
know
what
could
be
improved
general
retrospective
format,
and
this
you
know
a
lot
of
the
changes
that
our
team
was
able
to
to
take
on
just
the
the
better
direction,
the
more
flexibility
we
didn't
start,
the
fcl
right
away.
You
know
the
day
of
the
incident.
We
didn't
turn
into
fcl
mode.
A
We
actually
took
like
four
days
to
actually
kick
it
off,
so
we
had
time
to
plan
time
to
talk
about
it
time
to
really
understand
and
appreciate
what
what
do
we
want
to
accomplish?
We
weren't
just
in
firefighting
mode.
We
just
take
out
our
hoses
and
start
spraying
them
everywhere.
We,
you
know
we
put
together
a
plan.
That
was
a
big
outcome
that
I
think
helped
us
a
lot.
A
Another
one
is
how
our
team
tackled
a
lot
more
than
just
the
root
fix.
You
know:
lots
of
docs
handbook
updates
and
a
lot
of
different
areas
as
well.
Like
was
discussed
earlier
verification
policy.
You
know
we're
managing
our
pto
test
coverage,
developer
confidence,
widespread
of
topics
paul.
You
had
a
comment
on
on
this
one.
You
wouldn't
mind
verbalizing
that.
C
D
I
think
any
of
these
incidents
always
very
intimidating
and
daunting,
and
I
just
want
to
give
a
kudos
to
the
team
and
to
uni
for
conducting
in
a
way
that
it's
been
a
positive
experience
like
it
used
to
be
like.
Oh,
oh,
no,
there's
a
lot
of
finger,
pointing
there'll
be
a
lot
of
blaming
going
like.
Oh
you
did
this
wrong.
You
didn't
strong.
There
was
none
of
that.
For
me,
this
experience
has
been
so
positive
like
okay.
D
No,
this
is
an
opportunity
for
us
to
be
better
and,
as
you
highlight
it
in
a
bunch
of
the
items
that
we
close,
like
the
document
changes
paul
mentioned
about
the
the
qa
changes,
those
are
really
helpful
and
kind
of
tools
that
we
can
use
for
our
future,
mrs
and
future
issues
to
have
in
our
toolkit
to
tackle
them
to
prevent
something
like
this
from
happening
again.
So
I
don't
know
I
I
I
view
this
experience
as
really
positive.
There
was,
I
use,
I
I
think.
D
Usually
I
might
get
scared
or
whatever,
but
it's
been
very
helpful.
I'm
excited
about
this
obviously
not
excited
that
this
incident
occurred,
but
I'm
excited
about
the
momentum,
the
changes
that
we
are,
that
we
kind
of
gather
and
brainstorm
together
and
I
think
the
product
it's
going
to
be
a
lot
better.
Our
reliability
will
improve
just
with
these
kind
of
new
new
tools
that
we
have
in
our
belt.
So
I
I
thought
this
was
just
been
a
positive
experience,
at
least
for
me,
so
thank
you.
A
Absolutely
it
was
my
pleasure
and
that's
great
to
hear.
I
think
I
definitely
wouldn't
been
successful
without
the
team
support
you
know,
I
I
knew
right
away.
This
would
be
intimidating.
The
reaction
would
be
like
oh
getting
our
hands
slapped
or
even
worse,
but
no,
I
think
we
quickly
got
past
that
and
realized.
No.
This
is
actually
kind
of
cool,
it
doesn't
happen
a
lot.
It's
a
great
way,
great
opportunity
to
step
back
and
think
about
some
stuff
that
maybe
isn't
actively
in
our
heads
and
very
you
know
again
in
a
very
positive
manner.
D
C
Yeah
sure
yeah
yeah,
I
had
to
complain
about
about
something
yeah.
I
think
that
the
dfc
was
scheduled
to
rain
on
a
wednesday,
which
I
guess
would
be
a
thursday
for
dave,
and
I
think,
the
day
before
we
ended
up
extending
extending
it
to
until
the
end
of
the
week
yeah,
which
can
I
came
up
as
a
surprise,
for
me
at
least,
because
I
was
really
scheduling
my
or
planning
my
work
around
the
initial
deadline.
C
I
had
taken
some
commitment
with
frederick
because
I've
been
collaborating
with
him
on
a
migration,
and
at
that
point
I
kind
of
had
to
to
put
everything
on
hold
again,
so
it
was
kind
of
surprising
in
terms
of
scheduling,
not
a
huge
deal
but
yeah.
I
guess
if,
if
there's
something
bad
to
to
take
away
from
this,
I
guess
that's.
B
C
A
B
A
Yeah,
thanks
for
raising
that,
I
I
think
I
transparency
is,
is
really
a
big
part
of
this.
The
process
I
was
providing,
I
mentioned
the
the
daily
stand-ups
I
was
attending,
and
then
we
had
the
slack
channel,
which
was
a
new
temporary
slack
channel
for
everybody
just
additionally
more
noise
right.
It's
not
a
slack
channel
we're
following
it
might
be
down
in
your
sidebar,
so
you
might
not
even
see
the
updates.
A
I
think
if
we
were
all
in
the
same
office,
doing
like
a
daily
stand-up
together,
it'd
be
kind
of
hard
to
avoid
the
transparency,
but
but
no
being
remote
being
async
yeah.
That's
something
that
I
I
can
definitely
understand.
I
had
intentionally.
I
think
it
was
interesting.
We
had
a
public
holiday
the
monday
following
the
incident,
and
I
was
trying
to
be
a
little
bit
conservative
and
starting
this
thing.
So
that's
part
of
the
reason
wednesday
came
and
then
I
also
thought
it
might
be
cool
to
span
the
midweek
to
midweek
as
well.
A
I
think
the
the
five
days
was
also
a
kind
of
a
minimum
recommendation.
I
felt
given
the
scope
of
of
the
fix
that
seemed
very
reasonable.
I
didn't
want
to
set
the
team
up
to
have.
You
know
the
five
of
us
work
on
something
for
more
than
five
days
that
just
seemed
like
a
punishment,
so
I
was
like
okay,
we're
gonna
go
bare.
Minimum
five
looks
good.
What
happened
was
that
stayed
the
stand-up
update?
I
guess
it
was
wayne,
and
I
were
talking
a
bit
earlier
that
day
or
maybe
on
monday
evening.
A
Just
talking
about
it
was.
It
was
monday
kind
of
late
in
the
day
on
monday
he
was
asking.
How
are
you
feeling
do
you
think
we'll
be
complete?
You
know
by
the
planned
day.
I
said
I've
been
thinking
about
this.
I
think
there's
a
number
of
things
that
we're
actively
working
on
it'd
be
nice
to
have
that
breathing
room,
but
I
don't
recall
actually
confirming
with
the
team
either
so
that
may
have
been
an
opportunity
as
well
is
hey,
I'm
I'm
considering
extending
the
session.
A
It
was
more
of
hey,
we
made
a
decision
and
then
the
team
had
to
react
to
that.
So
my
apologies
for
that
one.
But
again
thank
you
for
accommodating
and
I'm
glad
we
were
able
to
put
work
on
hold
without
tremendous
impact
that
that's
a
you
know
that
shows
that
the
work
we're
doing
is
planned
in
a
way
that
that
people
aren't
waiting
on
us.
We
don't
have
like
all
these.
You
know
flocking
work
that
other
people
are
waiting
on,
we're
impeding
the
the
milestone
delivery.
You
know
we.
A
B
A
I
think
we
are
done
again.
Thank
you,
everybody.
We
we'll
close
this
bad
boy
out,
go
back
to
normal,
please
you
know
tell
I'll
summarize
the
things
I'll
send
that
out.
You
know
please
take
a
look.
Do
a
refresher
on
the
handbook
pages,
especially
those
sections
that
were
updated,
remind
others
when,
when
we're
not
behaving
in
a
manner
that
we
had
agreed
upon,
you
know
challenge
each
other.
Just
be
polite
and
say:
hey,
remember,
our
handbook
says
this
and
if
the
handbook
doesn't
make
sense,
let's
continue
to
make
more
updates.