►
From YouTube: Gitlab 12.5 Kickoff - Plan
Description
Plan Vision : https://about.gitlab.com/direction/plan/
Plan 12.5 Issues: https://bit.ly/2OWrqrR
Questions? Comments?
Ping us on GitLab!
For Portfolio Management : @kokeefe
For Project Management : @gweaver
For Certify : @mjwood
A
A
So
that's
kind
of
order,
we're
going
in
there.
The
other
thing
we
want
to
provide
is
the
ability
to
manage
print
and
release
Cadence's.
So
right
now
you
can't
track
an
issue
against
both
release
and
a
sprint,
because
there's
only
one
milestone.
So
that's
been
a
bit
of
a
kind
of
big
issue
and
there's
some
short-term
solutions
and
some
long-term
goals
there,
and
then
we
also
want
to
be
able
to
have
within
an
issue
the
ability
to
break
down
estimations
by
function.
A
So
it's
easier
for
the
respective
function
leads
to
determine
capacity
and
then
we're
looking
at
also
introducing
the
concept
of
team
velocity
and
volatility
to
understand
over
each
given
release
or
sprint.
What's
the
work?
That's
getting
done
so
that
when
it
comes
time
to
plan
the
next
one,
it
is
easier
to
make
commitments
that
can
be
trusted
and
set
realistic
expectations
both
with
the
team
and
with
the
external
stakeholders.
It
also
helps
force
trade-off
discussions
which
are
a
healthy
thing.
So
those
are
all
epics.
A
If
you
want
to
look
at
them,
you
can
for
this
particular
release,
which
is
12/5.
We
I
didn't
link
to
a
specific
issue
because
there's
a
couple
of
them,
but
we
more
or
less
her
continue
to
work
on
refactoring
the
sidebar
to
support
rescue
part
of
that
is
also
I,
think
creating
some
pyjamas
components
to
who's
that
correct
Donald
Scot.
A
A
A
Get
lab
to
associate
an
issue
to
more
than
one
concurrent
time
box
to
milestone,
which
is
very
common.
It's
it's.
How
scrum
works,
how
extreme
programming
works,
which
are
very
wildly
adopted?
Methodologies
for
project
management
among
the
capital,
a
agile
community
and
the
most
common
use
case?
Is
you
know
you
might
have
two
sprints
within
a
release?
You
need
the
way
to
kind
of
track
progress
against
both.
So,
if
you're
interested,
we
can
go
through
some
of
the
use
cases
here,
but
it's
pretty
straight,
for
these
are
all
directly
from
our
customers.
A
These
are
their
words
and
I
did
not
make
them
up.
So
you
know
one
basically
sets.
We
require
more
aslam
for
an
upcoming
version
of
a
given
project.
It's
a
big
pain
that
we
can't
attach
another
milestone,
forgiving
release
window,
we're
closing
multiple
projects,
an
additional
operation,
tasks
or
usual
today,
even
for
small
teams,
so
it
would
be
nice.
A
We
have
the
tools
to
properly
plan
and
observe
them,
and
so
yeah,
if
it
feels
like
I,
spend
a
lot
of
time
trying
to
organize
issues
spanning
multiple
projects
and
multiple
seekers
trying
to
avoid
the
single
milestone
and
limitation.
We
end
up
using
labels
as
a
poor
placement.
So
once
we
kind
of
get
this
in
place,
there's
some
bigger
picture
context
too.
We
we
can
we're
also
going
to
be
showing
more
historically
accurate
data
on
milestones
and
that's
one
it's
in
12.5
as
well.
A
We
can
also
introduce
the
concept
of
milestone
types
which
would
then
let
you
better
track
velocity
against
the
specific
type.
So
if
you
want
to
know
what
your
releases
are,
if
they're
the
same
type,
then
we
know
that
they're
related
and
we
can
track
them
sequentially
to
measure
the
velocity
of
volatility.
A
C
A
Whatever
the
cadence
is
and
having
those
Auto
create
milestones,
force
and
manage
that
process,
so
we
want
to
do
the
main
goal
thing
every
time.
So,
within
this
issue
we
want
to
allow
the
easier
to
associate
five
milestones.
Originally
I
proposed
three.
Some
folks
in
the
water
community
push
back
and
said
that
you
know
they're
gonna
quickly
hit
that
limit,
so
I
think
we
do
need
to
have
a
maximum,
and
we
do
need
to
have
a
limit
for
UX
purposes,
mainly
because
it's
already
gonna
be
tricky.
A
To
show
like
little
milestones
like
in
an
issue
card
or
an
issue
lists
your
search
issues
but
I
think
like
this
is
it
we
want
to
be
able
to
satiate
five
milestones
and
we
want
to
properly
handle
the
UX
first
playing
the
multiple
milestones
and
issues.
If
you
search
less
items
epics
any
other
locations
where
a
reference
to
an
issue
also
displays
the
Associated
milestones.
A
A
Understand
all
of
that,
but
let's
see
it
was
a
trick,
maybe
okay,
so
he
said
I
think
you'll
hit
the
limit
three
pretty
soon.
Just
add
security
related
issue
to
a
milestone
of
a
hypothetical
old
one.
You
know
one
X
branch,
current
2,
X
branch,
the
next
branch,
and
then
you
reach
your
limit
I'm
sure
that
you
come
up
with
with
more
milestones
or
way
to
use
that.
Why
not
5?
Why
not
7
I?
You
know
the
point
at
least
brought
like.
Is
it
an
artificial
limit?
A
A
When
you
look
at
the
full
safe
you
kind
of
have
your
top
level,
and
then
you
have
that
you
might
want
to
track
an
issue
at
the
Business
Solutions
and
lean
systems
level
and
then
at
the
release
level
and
then
like
get
the
actual
team
level.
So
that's
where
you
kind
of
would
get
to
3,
but
I.
Also,
you
know
if
we
can
handle
five
and
that
works
great.
A
If
we
just
like
think
it's
a
better
idea
from
a
user
experience,
standpoint
so
limited
to
three
right
now
and
they'll,
let
the
community
push
back
if
they're
not
happy
with
that,
like
I'm,
also
fine
with
that
I
could
go
either
way.
But
from
a
technical
standpoint,
the
engineers
said
that
it
was
not
gonna
cause
any
performance
issues
going
from
three
to
five.
It
really
didn't
matter
that
answer:
question
yeah.
A
Any
other
conversation
about
this
or
push
back
or
just
exploration,
good
thing
to
do:
I'm
totally
open
to
feedback.
Oh
yeah,
the
last
thing
that
I'm
trying
to
start
doing
on
my
shoes
as
well
at
least
the
direction
level
ones,
is
having
some
success
metrics,
and
so,
if
we
can
get
the
plum
tree
and
to
start
tracking,
this
that'd
be
great.
If
not
I,
think
you
know,
this
can
be
something
for
the
database.
A
This
also
I
would
like
this
to
be
graph
keel
first,
as
with
any
new
feature
or
things
that
were
refactoring
and
make
sure
we
update
the
public
api's
and
use
pajamas,
we're
applicable
and
then
I
did
also
have
the
acceptance
criteria
of
the
adding
the
telemetry
make
sure
this
soon.
As
we
launch
this,
we
can
measure
any
questions
or
discussion
that
we
won't
have
about
this.
A
You,
okay,
cool,
moving
on
next
item.
This
is
the
historically
accurate
burn
down
charts.
So
the
problem
is
right
now,
when
a
milestone
ends,
issues
are
typically
moved
to
the
next
milestone
and
burn
down
charts
on
the
previous
milestone.
Then,
don't
accurately
reflect
what
was
completed
on
that
given
milestone.
Well,
it
guess
it
does
what
was
completed
but
not
what
wasn't
completed
and
what
got
bumped
to
another
sprint
or
another
milestone,
and
so
there's
no
way
to
say,
like
we
started
with
X,
we
added
a
Y
amount
of
scope.
A
A
So
the
basic
proposal
is
to
add
a
series
of
events
that
we
track
along
with
milestones,
so,
instead
of
it
being
kind
of
stateless,
we
move
towards
more
like
when
the
day
is
over,
like
we
take
a
snapshot
of
what
are
the
state
of
all
the
issues
that
are
attached
to
this
milestone,
like
which
ones
or
drops
so
it
was
removed
from
the
current
milestone
it
wasn't
assigned.
So
it's
more
like
we're.
Abandoning
this
we're
not
going
to
reprioritize
it
we're
just
going
to
drop
it
moved
so
just
gets
moved
to
another
milestone.
A
How
did
the
current
one
that
the
contexts
were
in
the
issue
is
closed,
which
means
it's
probably
completed,
I
guess
there
are
use
cases
where
it
could
be
closed
and
not
completed,
but
I
don't
want
to
get
into
that
with
this
iteration.
If
there
is
an
issue
added,
so
the
basic
idea
is
if
it
was
added
a
day
or
more
after
the
start
date.
So
a
lot
of
teams
will
start
a
milestone
and
do
your
planning
on
that
same
day.
A
The
the
big
issue
that
I
saw
with
milestones
is
also
performance
related
when
I
went
and
looked
at
get
labs
group
level
milestone
412,
for
it
took
11
seconds
to
load
the
page
in
another
10
seconds
to
render
the
burndown
chart
for
a
total
like
time
of
21
seconds
before
I
could
see
the
burndown
chart.
I
know
like
we
have
a
lot
of
issues
that
are
going
on,
but
it's
also,
if
we're
doing
reference
architectures
for
25,000
users
and
50,000
users
and
we're
starting
to
scale
things
out,
like
that's
unacceptable
performance.
A
A
There's
lots
of
things
that
aren't
in
the
API
that
they
want
any
API,
but
we
don't
take
the
time
to
do
that
when
we're
building
new
features
in
and
a
lot
of
it
was
specifically
razón-
was
around
visibility
into
metrics
and
feedback
on
how
teams
are
doing-
and
this
is
one
of
those
things
where,
like
they're
gonna,
want
to
see
the
data
to
externally
use
graphic
you'll,
first
test
added
the
behavior
and
the
proposals
working.
That's
like
the
basic,
primitive
stuff
in
terms
of
designs,
I
think
we're
still
working
through
it.
A
I
don't
see
them
on
this.
One
Holly
will
attach
them
when
she's
ready
to,
but
the
basic
idea
is
at
a
vertical
C
bar
chart
on
the
graph
along
that
kind
of
aligns
to
the
x-axis.
It
represents
these
events
and
then
have
total
aggregate
counts
under
it
and
that
way
like
you
can
see
over
the
time
period,
when
these
events
happened
and
then
you
can
see
the
total
amount
over
the
course
of
the
milestone
and
I
recount
you
any
questions
about
this
Oh.
A
Also
consideration
for
this
is
one
of
the
other
issues
in
12/5
is
making
parity
with
the
project
milestones
in
the
group
milestones
so
right
now
the
project
milestones
lists
a
bunch
of
things
that
aren't
on
the
group
milestones
and
we
want
to
at
least
make
sure
that
those
two
look
the
same
so
we're
gonna
put
them
on
there
and
then
we're
going
to
slowly
refactor
the
milestone
view
to
be
more
meaningful
to
you
know
everyone,
but
given
that
constraint,
like
you
might
go,
look
at
the
group.
Mouse
didn't
forget.
A
D
A
Is
big
and
that's
where,
if
like
this
is
where
Donald
and
Sean?
If
you
watch
this,
if
you
push
back
on
this-
and
we
want
to
like
maybe
just
tackle
one
event
per
issue
and
like
chunk
it
down
that
way,
that's
totally
fine!
Then
we
can
convert
this
into
an
epic
I.
Think
I
left
the
question
down
here
to
bring
that
up,
see
here-
camera,
oh
yeah,
so
how
we
should
split
it
up.
A
I
think
one
of
the
questions
that
this
brings
up
from
a
technical
standpoint
is
why
it's
really
low
slow
right
now
is
that
where
we're
computing
like
the
values
of
the
brandade
chart,
every
time
we
request,
the
I
guess
think
the
milestone.
So
we
look
through
like
all
the
issues,
then
we
like
calculate
the
plots
on
the
chart
instead
of
just
having
like
all
that
stuff
pre
calculated
and
then
we
just
render
the
chart
was
like
JSON,
which
is
more
times
your
eazy-e.
A
B
A
A
A
Think
if
we
look
at
this
like
a
lot
of
this
stuff
and
like
the
whole
tabs
down
here
with
the
issues
that
are
part
of
that
milestone,
the
Merchants
request
that
participants
the
labels,
the
projects,
I
think
this
is
I,
don't
know
if
we'll
have
this
for
Knox
I
think
this
was
for
that
weird
type
of
milestone,
there's
like
whatever
dynamically
created
ones
at
the
very
very
top.
It
would
be
gratefully.
This
could
make
it
into
the
group
milestones.
If
not
that's
fine,
does
it
make
sense
in
the
project
level.
A
But
the
idea
is
like
this:
stuff
doesn't
exist
right
now
anywhere,
and
a
lot
of
the
community
was
frustrated
by
the
fact
that
we
were
removing
it
from
the
project
level
milestones
and
that
we
haven't
added
it
to
the
group
level
milestones
and
we
haven't
provided
a
suitable
replacement
for
the
amount
of
like
the
information
that
they
were
finding.
Very
valuable
on
this
view,
so
for
the
time
being,
we're
gonna
put
this
back
on
the
group
view
and
then
we're
gonna
go
back
and
talk
to
the
wider
community
about
like.
A
E
E
E
So
as
we're
trying
to
drive
adoption
of
epics
and
helping
people
plan
work
out
over
time,
making
sure
that
that
list
is
easily
used,
easily
visible
usable
mutable
and
super
important,
improving
the
ability
to
create
and
Link
epics
and
issues
so
they're,
not
necessarily
always
the
easiest
things
to
create
or
merge
to
each
other
or
link
them.
So
we're
trying
to
find
out
find
the
best
ways
to
just
help.
People
create
things
quickly
without
having
context
switch
or
switch
to
multiple
tabs
to
do
it.
E
We've
all
been
how
epics
are
displayed
on
the
roadmap
right
now.
Epics
are
just
a
bar
that
exists
on
the
roadmap,
with
not
a
lot
of
data
and
a
lot
of
functionality.
So
we
were
looking
at
the
bunch
of
functionality
to
kind
of
display
them
better
and
give
them
opportunities
to
interact
with
each
other,
and
you
can
interact
with
roadmap.
E
You
know
we
we
need
to
start
surfacing
a
lot
of
this
information
up
on
the
roadmap,
so
you
can
actually
see
okay,
my
epic
is
in
flight,
but
how
does
that
relate
to
my
milestone
that
it
and
it's
children
items
are
associated
to
so
I
can
actually
track
progress
towards
that
milestone,
so
to
make
progress
towards
those
looking
at
12.5,
we're
really
focusing
on
improving
our
epics
functionality
and
just
visualizations.
A
lot
of
the
roadmap
stuff
is
in
solution,
validation,
working
with
the
UX
team
to
get
great
designs
and
NPCs
to
step
into
that.
E
Slowly,
so
you
should
start
seeing
those
come
into
the
q4
12
six,
but
four
twelve
five
remain
Lee,
focusing
on
improvements
epics,
so
I'll
just
go
through
these
one
at
a
time.
So
the
big
one
I
think
which
we've
gotten
a
lot
of
customer
feedback
as
well
as
internal
frustration
around
this
is
epics,
are
often
very
difficult
to
find
inside
the
you
act
when
you're
trying
to
hunt
them
down
either
epics
down
as
a
list
or
actually
cut
down
a
specific
one.
E
E
If
I'm
at
the
group
I'll
see
the
group
level
epics
and
everything
that
bubbles
up
from
those
subgroups
under
it
as
well,
I'm
Sophie,
I,
don't
know
if
we
actually
have
a
design
in
here
or
not
Alexis,
but
I
mean
that
one's
pretty
straightforward,
we're
gonna
have
an
epic
nav
item
on
the
left
hand
on
that
expands
out
and
let
you
navigate
to
it
pretty
quick
are
any
questions
on
that,
one
again
that
one's
fairly
straightforward,
but
if
we
want
to
have
a
discussion,
let's,
let's
go
for
it.
I.
A
E
So
that
yeah
I
think
that's
that's.
Definitely
one
of
the
one
of
the
open
questions
that
we're
sorting
through
with
our
validation
work
right
now
is
how
do
you
continue
that
contextualization,
when
we
do
expand
it
down
to
epics
right
now,
you
know
I,
think
we're
focusing
on
the
group
and
subgroup
item
is
right.
Now
is
the
MVC,
but
yeah
no
I
think
that's
a
great
question.
Alexis
sir
Holly,
if
you're
on,
if
you've
had
specific
thoughts
on
that
or
not
if
we
wanted
to
talk
through
it
now
are.
F
A
So,
like
you
know,
just
like
a
group
doesn't
have
a
repository,
a
project
doesn't
have
epics
and
so
to
me,
it
seems
like
people
might
be
having
a
hard
time
discovering
them,
because
they're
not
realizing
the
context
that
they're
in
because
the
sidebars
look
the
same
as
like
groups
like
everything
between
a
project
in
a
group,
look
exactly
the
same,
which
is
why
I
find
myself
getting
confused.
It's
not
that
I,
don't
they're,
not
discoverable.
A
It's
like
I
I
can't
ever
remember
what
contexts
I'm
in
like
what
what
main
entity
so
of
like
it
takes
me
a
second
to
then
look
at
the
breadcrumbs
be
like
oh
crap,
like
I'm
in
a
project.
I
have
to
go
back
up
the
tree
to
like
get
to
the
group,
the
subgroup
or
whatever
group
it
is.
It
has
the
epics
in
it.
So
that
makes
sense
and.
F
A
A
It's
fine,
it's
just
like.
Are
we
gonna
and
then,
whenever
we
have
project
level
up,
because
this
is
gonna
be
confusing
when
you're
like
on
the
project
level?
And
then
you
also
like
want
to
go
look
for
things
and
you're
gonna
like
bring
in
the
group
level
at
that
same
place,
I
guess
it's
just
food
for
thought.
Yeah.
E
So
if
I'm
at
the
project
level,
then
I'll
see
the
project
level
epics,
but
if
I
come
back,
like
you
know,
forget
in
this
level,
I
think
what
we're
really
talking
about
is
excuse
me,
elevating
that
out
a
little
more
from
the
sub
group
and
further
down
the
line,
but
yeah
I
mean
I,
get
that
what
we'll
do
is
well
actually
start
pinging
everybody
as
we
get
some
more
solid
design
ideas
around
and
elicit
some
feedback,
but
again
I
think
there
there
is
an
opportunity
to
solve
it.
I
mean
again.
E
You
know
we
saw
this
when
we
were
at
that
off-site
the
a
couple
weeks
ago.
You
know
where
this
was
one
of
the
conversations
we
kept
having
and
then
the
you
know
the
video
sessions
we
had
trying
to
get
them
set
up
with
her
POC
org,
like
this
came
up
multiple
times
so
I
think
what
we're
really
just
trying
to
do
is
find
that
iterative
step
in
between
what
can
we
do
now
to
help
service
it
and
arm?
What
can
we
do
once
we
do
that?
The
project
level
ethics
book
that.
E
So,
as
you
can
actually
watch
in
this
gif,
if
it's
showing
up
during
the
screen
share
my
epics
and
issues,
we've
got
those
fun
little
icons
up
on
top
I
tell
you
how
many
are
there?
They
actually
do
not
include
all
of
the
items
under
them
like
the
the
integer
actually
increases
as
you
expand
the
items
d
collapse
them.
E
So
what
we
want
to
do
is
update
that
so
that
those
are
actually
reading
all
of
the
individual
issues
and
epics
under
there
and
displaying
a
correct
number
up
at
the
top
verses
like
you
can
see
here
as
soon
as
I
expand
the
sub
epic.
Suddenly
my
issue
number
expands
and
increases,
so
it
was
really
just
driving
to
drive
accurate
information
up
at
that
level
and
drive
some
consistency
in
how
and
how
we're
showing
people
how
much
work
is
attached
to
this
individual
item.
B
E
No
not
allow
users
to
search
for
epics
when
adding
related
epics.
So
right
now
you
know
when
we're
adding
a
adding
an
sub
epic
or
adding
an
epic
to
a
parent
epic
to
make
it
a
child.
Epic
on
you
actually
have
to
copy
and
paste
the
link
directly
in
there,
instead
of
actually
having
a
populated
list
or
a
search
function.
So
really
just
quality
of
life
improvement
to
allow
people
to
attach
items
to
the
epic
itself
without
having
to
navigate
to
another
page
or
open
a
new
tab
copy
link
and
then
switch
back.
E
Alright
and
similar
related
allow
users
to
search
for
epics
and
issues,
or
at
least
fuel
list
when
adding
them
to
the
widget.
When
you
just
want
to
add
an
epic
er
issue
to
an
issue,
they
miss
first
copy
link
same
story.
There
actually
are
these
the
duplicate
ones.
We
talked
about
Donal
or
he
just
left,
I.
Think.
E
All
right,
so
next
one
is
adding
an
epic
option
while
creating
a
new
issue
in
the
UI,
so
this
is
expanding
on
some
functionality
that
we
have
currently,
which
is
we're
also
trying
to
roll
out
the
ability
to
create
an
issue
directly
from
an
epic
versus
just
linking
one
that
you
already
have
copied
in
your
clipboard.
But
this
is
also
going
to
let
you
do
that
from
adding
adding
in
epic
as
well,
so
we're
trying
to
just
drive
that
functionality
across
both
epics
and
issues.
So
it's
consistent.
E
So
we're
looking
at
your
your
epics
list,
what
we're
trying
to
do
is
just
bubble
up
those
start
and
due
dates
inside
of
this
view,
so
that
you
can
actually
have
more
information.
Looking
a
list,
you
don't
actually
have
to
open
each
individual
epic
up
to
get
that
data
on
this
should
help
allowing
just
encouraging
proper
prioritization
through
stack,
ranking
those
items
and
lists
so
that
we
know
hey
this
one's
to
earlier.
Let's
make
sure
we
start
working
on
it
sooner.
E
Allow
changing
in
items
parent,
epic,
using
drag-and-drop
interactions.
So
as
we
as
you
know,
we
are
working
to
roll
out
a
more
advanced
epic
tree
that
allows
you
to
drag
and
drop
items
across
epics
and
issues.
This
one
will
allow
you
to
actually
drag
and
hide
or
drag
an
issue
from
an
epic
into
a
new
epic,
epic,
reassigning
the
parent.
B
E
Yep
everyo
thanks
s
cool,
so
what
we're
looking
now
is.
So
this
is
an
older
issue.
You've
seen
it's
been
open
for
about
two
years,
but
we
did
some
some
clean-up
on
it
to
get
it
up
to
current
standards.
So
you
can
see
this
a
lot
of
the
designs
that
got
leaked
in
here
or
older,
but
what
we
are
looking
is
showing
the
actual
issue
count
and
a
close
count.
So
when
you're
looking
at
the
epic,
you
can
see
the
proper,
proper
information
on
it.
E
So
what
we
had
before
you
know:
we've
updated
our
icon
since
that,
so
that's
what
I
was
trying
to
scroll
down
to.
So
we
have
the
green
and
blue
icons
now
on
lated
issues.
But
if
you
look
in
here,
what
we're
gonna
do
is
actually
have
the
close
items
get
sorted
down
to
the
bottom
of
the
list
so
that
the
open
ones
maintain
up
at
the
top
and
then
change
just
the
change.
E
Yep,
so
just
quick,
oh
yeah,
so
we
actually
have
a
couple
couple
bugs
we're
gonna
work
towards
an
security
issue
and
some
tech
debt
around
the
epic
graph,
QL
API
response.
But
what
we're
really
again,
it's
a
lot
of
quality
of
life
and
small
functional
improvements
just
to
get
epics
closer
to
on
par
with
how
issues
are
just
how
you're
able
to
work
with
issues
and
specifically
being
able
to
link
them
between
each
other,
make
it
easier
to
create
them
and
easily
be
able
to
identify
state
of
work.
C
There
we
go.
Nobody
see
that
yeah
you're
good
to
go
okay,
I'm,
trying
to
shrink
that.
So
it's
a
little
easier
here.
We
go
so
I'm,
Mark,
Wood
I'm
in
charge
of
the
certified
stuff
here
at
the
PM
side,
and
currently
we're
working
on
two
major
topics.
Here,
one
is
requirement
management.
You
know
with
a
service
desk,
our
requirements.
Management
is
yet
to
be
released,
feature
but
we're
hoping
to
actually
have
an
MB
seen
for
the
novice
release,
12
five,
but
twelve.
Six.
C
In
the
meantime,
we
do
have
a
epic
here
as
well
as
some
issues
that
we're
working
through
trying
to
get
them
through
UX
work
so
that
we
are
ready
to
go
to
release
an
MBA
MBC
in
twelve
six.
That
would
allow
users
to
create
requirements
and
link
them
together.
So
you
have
a
level
of
requirements,
high
level
requirements
trace
tool.
It
will
require
this
type
of
thing.
So
that's
our
current
status.
We
do
have
that
issue
open,
as
well
as
an
epoch
tracking
tracking
network.
C
C
What
we're
looking
to
do
is
just
allow
the
concept
of
blocks
or
is
blocked
by
and
being
able
to
do,
that
will
allow
people
to
visualize
what
is
holding
up
their
issues
or,
if
there's
a
blocking
effect,
be
able
to
actually
tag
a
blocking
issue
and
it
helps
with
prioritization
planning
we,
a
future
issues
would
like
to
implement
on
top
of
that.
Well,
it
will
add
more
visual
information
surrounding
that
add
warnings.
C
If
you
go
to
close
an
issue
that
is
currently
blocked,
it
would
give
the
user
a
warning,
they
would
say
hey
this
issue
is
blocked
by
another
issue.
Are
you
sure
you
want
to
close,
and
ideally,
in
the
long
run,
when
we
look
at
a
board
you'll
be
able
to
see
issues
that
are
blocked
in
a
slightly
different
background,
color
or
some
other
visual
indicator?
That
would
allow
you
to
recognize
the
blocking
issues
and
glance
as
opposed
to
having
to
click
through
and
and
actually
look
to
see.
C
Great,
so
that's
sort
of
side
of
things
the
service
does
side
of
things.
We're
really
trying
to
push
to
get
service
desk
from
viable
to
lovable,
and
the
service
desk
right
now
is
very
viable.
There's
a
lot
of
people
using
it
I've
actually
been
talking
to
people.
Of
course,
the
last
couple
of
weeks,
but
two
of
the
things
that
really
popped
up
for
me
and
comments
that
I've
gotten
was
the
incoming
issues.
It
would
be
nice
to
be
able
to
template
eyes
those
and
the
outgoing
service.
That's
what
I'm
you
know
responses.
C
C
So
there
should
be
ready
to
go
and
as
I
was
saying
before,
this
will
enable
you
to
have
a
template
surrounding
all
incoming
issues
to
ship
stuff,
so
that
should
help
to
make
it
a
little
bit
more
usable
for
people
and
then
the
final
issue.
We're
going
to
be
putting
in
is
there's
a
bug
fix
going
in
for
Co
five,
the
service
desk,
where
duplicate
issues
are
created
when
users
reply
to
an
email.
This
is
a
pretty
heavily
uploaded
feature
or
service
desk
users
and
it's
causing
them
a
lot
of
grief.
C
It
doesn't
really
recognize
it
here,
because
it's
on
another
epic
that
would
people
doing
the
voting
but
effectively
what's
happening,
is
if
an
email
is
a
service
desk
issues
created
via
email.
The
user
receives
an
email
back
saying
that
issue
is
created
if
they
reply
to
that
currently
or
comment
from
that
email
chain.
The
service
desk
is
not
catching
that
that's
a
reply
or
forward
and
what
it's
doing
is
creating
a
second
issue
with
the
reply
or
forward
well,
which
is
causing
duplicate
issues
and
just
some
issues
for
some
of
our
customers.
C
C
The
current
concept
is
is
going
to
show
up
in
a
very
similar
manner,
probably
within
that
same
list,
but
it
may
have
a
different
icon
next
door,
something
we're
still
working
through
all
the
details
and
how
we'll
visually
display
that
but
effectively
blocking
issues
are
definitely
related
issues.
So
there's
sort
of
a
subclass
of
that
or
subset
of
that.
So
the
blocking
issue
is
just
a
type
of
relation
or
a
is
blocked
by
as
another
type
of
relation
there.
C
So
will
be
the
option
to
relate
issues
to
one
another
and
say
this
one
is
related
to
this
because
they're
similar
or
they
have
similar
use
cases
or
similar
solutions.
But
in
the
issue
or
in
the
situation
where
one
issue
is
actually
blocking
another
issue
from
being
implemented,
we
want
to
be
stronger
definition
of
that.