►
From YouTube: Threat Insights weekly group discussion 2021-03-02
B
C
D
A
C
E
H
A
To
be
it,
what
makes
your
head
shape?
Look
different,
yeah,
well,
tiago,
to
your
point:
if
folks
haven't
had
a
chance
to
do
the
review
of
issues
or
planning
breakdown,
technically
we're
not
supposed
to
go
through
them,
but
I
I
that's
all
that's
on
the
agenda
today,
so
I
think
it's
worth
at
least
discussing
the
three
issues
that
we
have
on
the
agenda.
Unless
anyone
else
has
things
that
they
want
to
improv.
To
add
to
today's
discussion.
A
Okay,
a
and
b
should
be
quick,
at
least
a
should
be
it's
mostly
just
a
question
of
how
people
want
to
handle
this.
So
since
I
created
a
and
b,
I
can
go
ahead
and
speak
to
them.
We've
been
measuring
our
largest
content
payment
largest
lcp
scores
for
the
site,
speed
measurements
of
our
pages
over
the
course
of
the
last
quarter,
and
we've
identified
our
first
page
that
needs
performance
improvements.
A
There
have
been
some
challenges
in
making
sure
that
the
logged
in
pages
have
the
right
access
for
the
user.
That's
testing
them.
So
as
we
work
through
these,
there
may
be
more
pages,
but
the
first
one
is
not
surprisingly,
the
project
level,
vulnerability
report
and
the
expected
or
the
goal.
Lcp
is
2.5
seconds
and
there's
lots
of
definitions
on
the
internet
around
what
how
to
define
lcp
and
there's
other
measurements
that
we
track
from
site
speed
in
addition
to
this
one
metric.
A
So
this
issue
that
I
created
was
a
spike
around
identifying
opportunities
for
performance
optimization.
I
currently
have
it
labeled
as
front
end
and
back
end.
I
know
that
doesn't
always
work
well.
If
I
should
split
this
into
front,
but
a
separate
front
end
or
back
end
issue,
I
my
assumption
would
be
that
that
would
happen
post
spike
and
it
would
happen
as
we
once
we've
identified,
where
the
optimizations
need
to
happen
and
we
create
issues
off
of
those.
So
any
questions
about
this
issue,
I.
C
Yeah,
well,
actually
you
don't
even
see
that
at
all
you
see
the
loading
spinner
and
then
everything
comes
in
at
once,
so
I've
actually
looked
into
a
little
bit
on
how
to
not
batch,
but
it
looks
like
vue
apollo
doesn't
have
the
ability
to
individually
turn
off
batching
for
for
various
queries,
so
we
may
have
to
like
hack
around
it
by
doing
like
a
small
delay
in
order
to
to
get
out
of
that
batching
time
period.
Yeah
I
mean
so.
C
I
I've
done
a
little
bit
of
looking
into
this,
but
so
there
are
things
that
we
can
do.
But
it's
like,
I
said
like
there
are
other
things
that
it's
it's
like
you
said
they're.
They
may
not
be
meaningful
in
to
see
something
but
not
actually
see
the
thing
you
want,
or
on
the
other
side,
it's
that
we're
limited
by
how
fast
you
can
render
things,
and
so
there
are
certain
things
that
we
can
speed
up,
but
there
are
also
certain
things
that
we,
our
hands,
are
tied.
D
D
H
E
F
A
F
H
D
A
E
A
E
E
So
I
don't
know
if
that
makes
a
difference
in
the
approach
here,
but
it's
certainly
something
worth
considering
like.
I
would
love
to
see
that
17
second
come
down
because
daniel
we're
we're
trying
to
dog
food
right
every
time
you
accidentally
click
on
that
page.
It's
you
gotta
sit
there
and
wait
for
a
third
of
a
minute.
C
C
J
K
K
A
So
between
these
two
issues,
speaking
tiago
and
I
will
figure
out
which
one
sticks
and
assign
it
over
to
daniel
as
the
dri
and
as
long
as
that
plan
flies
with
you,
daniel
that
you
know
you
might
be
creating
issues
for
back-end
work
based
on
the
spike.
You
know,
obviously
pull
in
back
and
engineers
for
their
input
as
needed,
but
that
sounds
like
a
good
plan.
A
The
second
one
I
added
was
a
bug,
and
I
think
this
was
really
just
a
question
of
whether
someone
could
look
at
it
and
tell
me
if
it's
front
end
or
back
end.
You
know,
I
know
we
have
a
bot
in
place
that
should
assign
these
things
off
once
it's
in
refinement,
and
I
could
just
put
it
there
and
let
the
magic
happen
to
decide
who's
gonna.
Do
that.
If
that's
our
process,
I'm
a
little
unclear
on
with
bugs
the
triage
process
that
we
have
in
place
today.
A
K
E
A
H
A
G
C
Okay,
so
we
have
this
one
issue:
that's
to
update
these
messages
so
on
the
security
dashboard
and
the
vulnerability
report,
the
two
messages
both
say:
the
security
dashboard,
blah
blah
blah,
and
so
this
one
also
says
the
security
dashboard,
blah
blah
blah,
and
but
it's
actually
the
vulnerability
report.
And
so
I
worked
on
this
last
night
and
I
noticed
that
the
only
difference
between
the
the
issue
wasn't
completely
clear
on
what
we
should
change
this
message
to.
C
I
C
I
A
A
L
C
A
D
Yes,
please
matt,
and
I
talked
about
it.
A
little
bit
and
andy
has
already
replied
with
some
suggestions,
so
just
for
the
benefit
of
everyone.
This
is
the
issue,
and
this
is
where
it
started
with
a
very
simple
question
from
savage.
He
was
implementing
the
status
update
and
he
found
out
that
the
stage
changed.
D
It
was
only
taking
a
comment
for
dismissal
and,
and
then
we,
how
looked
into
it,
is
that
I
should
be
simple
and
then
he
had
to
go
back
and
say
it's
actually
not
simple,
so
without
getting
into
this
whole
background
of
of
how
this
happened.
The
options
that
we
two
things
right
is
there
a
way
that
we
can
continue
with
this
and
and
change
the
scope.
So
so
savage
can
continue
the
the
work
and
then
the
second
part,
which
is
a
little
bit
harder,
is
how
do
we
want
to
solve
this?
D
A
We
created
these
two
epics
between
the
bulk
dismissal
types,
sorry,
the
bulk
status
updates
and
the
dismissal
types
and
reasons
there
was
a
lot
of
overlap
between
the
two
and
we
created
this
issue
that
I'm
adding
to
the
agenda.
Right
after
me
has
questioned
around
exposing
dismissal
reasons
and
comments,
is,
I
mean,
am
I
missing
a
relationship
between
this
issue
and
the
problem
that
we're
trying
to
solve.
D
D
D
D
D
E
Yes,
my
my
take
on
this
one
is,
I
think,
it's
better
to
take
what
we've
got
while
we
work
on
filling
in
the
gaps.
Having
a
comment
for
a
dismissal
is
probably
most
important
out
of
any
of
the
status
changes.
So
the
fact
that
we've
already
got
the
ability-
I
would
say,
let's
push
forward
with
that.
Instead
of
holding
back
all
commenting
until
we
get
the
ability
across
status
types.
E
D
E
E
By
scans
resolved
manual,
intervention
resolve
whatever,
so
there
may
be
these
other
more
specific
automatic
statuses
that
would
be
applied
like
that.
So
if
you
called
that
you
know
resolved
dismissal
reason
that
would
be
really
confusing.
You
could
call
it
resolved
resolution
reason
or
resolve
reason.
Like
that's
fine,
I
guess
what
I'm
saying
is
if
it
makes
sense
to
have
the
same
field
across
all
the
different
statuses
or
not.
Now
might
be
a
time
to
consider
doing
that.
Your
future
maintenance
coder
will
thank
you
for
not
having
a
resolved
dismissal
reason
field.
L
C
E
Yeah,
I
certainly
and
again
this
is
like
I'm
kind
of
poking
my
nose
into
the
into
the
details
and
how,
on
the
back
end,
I
just
I
agree.
It's
confusing
that
we
have
a
dismissal
reason
which
is
only
attached
to
one
of
the
statuses
and
then
this
comment
and
it's
kind
of
it's
injected
a
lot
of
confusion.
I
don't
want
us
to
sort
of
put
ourselves
into
a
corner
when
we
it
when
and
if
we
decide
to
you
know,
do
something
similar
for
the
other
statuses.
A
E
A
A
A
D
D
L
D
E
I
D
Think
we'll
come
to
that
bridge
when
we
you
know
well,
what
is
it
we
burn
that
bridge
when
we
come
to
it,
because
this
is
already
tied
to
to
to
dismissal
the
reason
there
you,
you
you're,
not
going
to
be
able
to
reuse
this
in
in
this
state,
so
if
it
makes
sense
to
make
it
more
generic
having
an
example
of
what
it
looks
like
it'll
be
worthwhile.
Basically,
we
won't
save
any
time
by
by
renaming
it
now,
that's
what
I'm
saying:
okay.