►
Description
Defend engineers working with PM to breakdown upcoming issues into components, clarify requirements, and identify work boundaries.
A
The
goal
of
this
meeting
is
not
to
try
and
groom
every
issue.
We're
about
to
look
at
the
goal
is
to
make
sure
that
the
following
questions
have
been
answered
or
the
requirements
clear
enough.
Do
we
know
the
work
boundaries
as
all
the
solution,
validation
and
research
been
completed
and
start
the
discussion
of
ways
that
we
can
break
this
down
into
smaller
logical
components.
I
don't
want
that
to
be
confused
with
the
idea
of
creating
sort
of
implementation
subtasks.
A
This
would
be
more
discussion
with
the
PM
about
the
entire
scope
and,
if
there's
ways
to
make
that
into
smaller,
MVPs
I
will
go
ahead
and
jump
into
the
first
issue.
Unless
anyone
has
any
questions
or
previous
one
thing
that
we
need
to
make
time
to
do
and
I'm
not
sure
if
I'm
prepared
or
if
Matt
is,
if
there's
any
previous
items
from
last
week,
Matt
do
you
have
anything
or
should
we
just
jump
right
in
I.
B
C
A
C
One
more
thing
from
your
discussion
in
slack
yesterday:
do
we
want
to
do
we
need
to
like
a
new
label
or
differentiator
for
in
process,
so.
A
D
E
A
Good
I
think,
if
to
get
we
were
just
talking
about
the
Dex
portable
CVS
is
a
good
example.
I
couldn't
add
that
grooming
label,
but
it's
one
that
we
discussed
during
the
call.
There
was
a
little
bit
of
question
in
the
about
whether
we've
made
it
through
everything
and
what
Matt's
indicator
was.
We
need
to
bring
this
back
up
again,
so
that
would
have
made
it
clear
to
him.
So
it
solves
that
problem
and.
C
A
B
My
thinking
face,
yeah
I,
don't
know
Lucas
I,
almost
kind
of
thought,
maybe
like
a
workflow
label,
would
be
appropriate
for
this,
because
it
is
a
distinct
step
in
between,
like
the
planning
breakdown
and
then
well,
because
right
now
we're
just
using
the
inference
of
if
there's
not
a
weight
on
it
and
it's
not
done
but
then
I
feel
like
scheduling
should
be
once
the
grooming
has
completed
and
there
is
the
weight
on
it.
So
yeah
I
don't
know
it's
hard
to
tell
just
by
looking.
A
I,
don't
think
we're
gonna
get
this
resolved
right
now.
I
think
we
should
probably
take
this
conversation
back
to
slack
I.
Think
making
a
work
flow
label
is
a
lot
more
effort
or
workflow
change
is
a
lot
more
effort
than
just
adding
a
label,
so
we
could
experiment
around
without
a
new
label
for
now
and
then
you
know
decide
if
it
makes
more
sense
to
add
a
label
or
you
know
Matt.
If
you
want
to
talk
about
this
again
in
the
Select
channel,
we
can
go
through
the
bigger
effort.
Feel
like
we're.
A
Gonna,
add
workflow
labels.
It's
gonna
fall
into
the
bigger
product,
workflow,
so
sorry
to
cut
that
nothing
to
gets
a
really
good
topic
and
we'll
get
it
resolved,
but
so
probably
only
been
able
to
make
it
through
two
of
these
issues
in
any
one
of
these
meetings
and
I
think
that
we
can
do
three
today.
B
E
Consolidating
the
issues
that
have
been
posted
at
towards
the
tail
end
of
this
description,
so
I
think
will
be,
will
be
set
there.
They
don't
all
they
need,
they
don't
need
to
be
defined
by
where,
just
because
it's
a
global
change,
so
we'll
just
expect
way
less
issues
connected
to
this.
That
makes
sense.
A
E
And
they're
just
defined
by
location,
so
what
we
can
do
is
anywhere
where
we're
changing
the
badge
we'll
just
create
we'll
just
have
one
issue
for
it:
instead
of
enlists
and
M
our
reports
and
all
those
things
and
then
anywhere
where
we're
changing
something.
A
sack
of
the
badge
like
we
have
colors
that
we
want
to
change
to
will
have
a
separate
issue
for
that.
So
expect
those
changes
to
happen.
A
F
The
two
things
that
say
on
this
one:
ninety-nine
percent-
if
not
100
percent-
of
these,
when
we
change
that
one
component
they'll
all
change,
so
this
this
should
be
relatively
small
and
to
the
1%
where
it
won't
change,
is
the
vulnerability
list
that
we've
been
doing
as
part
of
first
class
vulnerabilities.
But
the
good
news
is
it's
already
done
there,
so
we
don't
need
to
change
it.
F
F
A
A
I
love
that
term
grooms
and
completions,
and
you
want
to
go
one
step
further,
Sam
all
right
and
that
we
can
keep
track.
You
know,
I,
don't
know
what,
if
there's
an
indicator
there
were
supposed
to
put
on
right
now
to
say
we
put
the
label
on
at
this
point
to
say
it's
ready
for
grooming
I!
Think
it's
what
we
just
I
just
want
to
lose.
The
fact
that
we
just
all
agreed
that
this
isn't:
okay,
I.
C
So
this
link
is
it's
a
relative
link
rather
than
an
absolute
one.
So
if
you
create
an
issue
it
on
a
branch,
vulnerability
from
that
branch
will
point
to
master,
as
was
the
feature
branch
where
the
vulnerability
is
so
the
boner,
so
feature
branch
does
not
get
merged
were
still
point
at
the
wrong
URL.
C
G
A
A
A
B
Yeah,
so
my
reasoning
for
keeping
it
here
is
when
we
released
the
first
class
vulnerabilities
work,
it's
gonna
carry
forward,
so
we're
sort
of
almost
reintroducing
an
existing
bug
into
the
redone
functionality.
It
just
seems
like
a
good
time
to
handle
it.
I
want
to
make
sure
everybody
also
saw
Ross
had
a
lot
of
comments
in
the
issue,
and
then
he
left
him
in
the
planning
document
as
well.
He
was
already
kind
of
looking
into
this
and.
A
A
So
if
any
of
the
questions
that
are
coming
out
of
this
discussion
could
be
added
to
the
comments
of
this
issue,
I'd
be
comfortable
with
asking
Ross
if
he
would
be
able
to
help
clarify
I,
don't
know
if
Ross
is
going
Thomas
isn't
here,
I,
don't
believe
I,
don't
think
Ross
is
going
to
be
committed
to
working
on
first
quest
abilities,
all
the
way
through
12
I'm,
not
sure
about
that.
But
since
he's
already
started
looking
at
this
I
think
it's
fair
to
ask
him
to
help
clarify
the
topic.
A
G
A
A
That
being
said,
for
the
sake
of
time,
we're
getting
very
close
to
wanting
to
begin
execution
on
12:9
I,
don't
think
expecting
us
to
make
it
through.
Every
single
issue
in
this
planning
breakdown
is
realistic
at
this
point
we're
just
making
our
best
bet.
So
we
may
end
up
pulling
this
into
twelve
nine
based
on
individual
grooming
and
a
perfect
world.
We
get
to
come
back
to
the
planning
breakdown
for
this
who
lives
in
a
perfect
world
on
3rd
tickets,
so
notify
a
user
in
the
front
end
when
a
vulnerability
is
resolved.
C
B
B
A
E
D
A
Believe
in
cases
where
we
can
actually
deliver
them
independently,
it
makes
a
lot
of
sense
where
I
get
hesitant
is
when
one
is
dependent
on
the
other,
and
we
have
to.
You
know,
consider
a
to
schedule
a
between
the
two
or
there's
a
lot
of
overlap.
They
kind
of
look
to-
and
we
discussed
this
with
with
Matt
and
Sam
the
PM's,
because
I
don't
expect
the
PM's
to
know
when
it
makes
sense
to
break
that
down
so
I
mean
that
falls
Laura
into
a
team
grooming
decision.
F
A
C
I
think
then
I
don't
think
it
has.
But
again
maybe
we
need
a
Ross
to
confirm
that
the
it's
it's
slightly
out
of
scope
there,
where
the
Krisha
is
one
thing
and
the
I
guess
I,
it
would
be
a
soft
deletion.
Then
don't
we'd
be
talking
about
because
the
the
the
issue
is
on
auto
creation.
I,
don't
know
what
the
handling
is
for
the
actual
removal.
A
Something
it's
helpful
to
have
Ross
here,
like
I
said,
if
he's
not
gonna
be
committed
to
fit
in
or
to
to
working
on
vulnerability
management
going
forward,
it's
good
that
we
start
driving
this
and
consulting
with
him
as
much
as
possible
Lucas.
Will
you
update
this
issue
with
the
results
of
that
discussion?
Yes,.