►
Description
Plan Product Manager (Gabe Weaver) walking through ideas for how issue types, relationships, and views could evolve in GitLab
A
Hey
so
on
this
issue
for
adding
test
sessions
with
the
link
test
cases,
there's
kind
of
this
discussion
going
on
about
should
we
have
separate
list
view
like
place
in
the
application
sidebar
for
the
different
types
of
issues
like
test
cases
have
their
own
down
here.
Requirements
have
their
own
lists,
issues
have
their
own
list.
Should
we
keep
going
that
direction
where
basically
each
type
of
issue
gets
its
own
list
somewhere
in
the
ui,
or
should
we
consolidate
things
down
into
a
single
list?
A
I
want
to
talk
a
little
bit
about
where
I
see
us,
hopefully,
eventually
going
and
kind
of
just
share
my
two
cents
so
that
we
can
all
kind
of
collaborate
on
some
of
these
ideas
together.
So
right
now
today,
you
know
we
have
different
lists,
features
different
types
of
issues.
Eventually,
requirements
are
being
converted
to
type
of
issue.
We
eventually
want
to
get
epics
there
too.
Within
each
of
these
types
of
issues.
We
have
certain
features
that
are
available
that
aren't
in
the
other
ones.
A
For
example,
issues
have
iterations
epics
have
like
you
know.
Your
epic
tree
component
requirements
have
test
reports,
sort
of
how
I
was
thinking
about.
This
is
decoupling.
Some
of
these
features
into
sort
of
standalone
experiences
that
can
be
more
or
less
effectively
included
in
any
type
of
issue.
So
if
we
were
to
take,
for
example,
the
test
report
that
is
on
a
requirement,
the
this
behavior
more
or
less
marks
a
requirement
is
satisfied
or
not
satisfied
according
to
pipeline
results,
it
can
be
done
manually.
A
So
if
you
look
at
all
of
the
fields
and
apps
and
little
kind
of
experiences,
we
have
across
our
different
plan
objects
and
kind
of
extracting
those
out
in
the
kind
of
standalone
things
that
can
be
included
in
any
type
of
issue.
And
then
we
have
this
idea
of
issue
types.
There's
going
to
be
some
system
defaults,
like
incidents
and
test
cases
and
test
sessions
and
requirements,
but
eventually
we
want
the
user
to
be
able
to
create
whatever
types
of
issues
they
want,
and
then
we
also
have
this
idea
of
views
right
now.
A
We
have
like
different,
I
guess
list
views,
but
the
way
that
I
sort
of
think
about
it
is
a
list
is
just
one
way
to
view
the
data.
So
if
we
sort
of
have
a
view
app
or
some
sort
of
standalone
experience
for
for
listing
type
issue
types
for
a
board
for
visualizing
types
of
issues,
we
could
also
have
a
grid
view.
We
have
a
timeline
view
which
is
like
a
road
map.
We
eventually
want
to
have
a
calendar
view.
These
are
all
just
different
ways
to
kind
of
segment
and
and
visualize.
A
A
But
once
we
have
like
the
ability
to
kind
of
compose
some
of
these
different
fields
and
apps
into
these
different
types
of
issues,
and
it
will
be
sort
of
like
then
building
out
this
idea
of
a
work
item
hierarchy
where
I
just
call
these
human
bar.
But
we
sort
of
have
a
kind
of
a
parent-child
relationship.
A
We
also
sort
of
have
this
idea
that
I've
kind
of
ripped
off
from
a
github
repo
called
multi-tree
relationships,
and
so
one
thing
can
have
multiple
parents
and
not
just
with
issues
themselves,
but
also
some
of
these
objects
right,
so
maybe,
like
an
issue,
can
belong
to
more
than
one
milestone
in
the
future.
Maybe
you
know
we
have
multiple
assignees
now,
but
it's
the
idea
of
not
limiting
ourselves
to
just
one
hierarchical
relationship
but
spanning
that.
So
in
this
case
we
could
have
issue
relationships
that
span
work
item
harkies.
A
We
could
have
issues
that
span
and
belong
to
multiple
groups
and
multiple
projects,
and
we've
been
talking
about
that,
but
instead
of
having
a
single
like
hard-coded
list
view
the
way
that
I've
been
thinking
about.
This
is
almost
like
exposing
saved
views
where,
within
that
you
can
go
and
kind
of
go
in
and
customize
what
you
want,
the
view
to
be
whether
it's
a
list
or
timeline
or
calendar
board
or
grid
or
whatever
other
view
types.
We
add
and
basically,
like
a
save
view,
consists
of
like
a
work
item
marquee.
A
So
you
don't
have
to
do
a
bunch
of
navigation
to
get
there.
So
in
terms
of
like
test
cases
having
their
own
lists
and
requirements
having
their
own
lists.
I'd
almost
like
us
to
see
a
move
towards
this.
Like
save
view
concept
and
that
way,
end
users
can
can
almost
customize
how
they
interact
with
issues
and
types
of
issues
based
on
the
work
that
they're
doing,
and
so
somebody
that's
using
requirements,
for
example,
could
create
a
save
view.
That
is
all
their
requirements
right.
Somebody
who's
using
test
cases
test
sessions.
A
They
could
have
a
safe
view.
That
is
just
test
cases
and
test
sessions.
You
could
create
one
that
basically
is,
for
instance,
or
you,
maybe
you
figure
out
how
to
kind
of
mix
and
match
some
of
these
things.
We
can
iterate
on
the
ux
for
this
and
like
how
we
accomplish
this,
but
I
don't
necessarily
see
it
as
a.
We
have
to
duplicate
the
list
view
lots
of
places
because
the
list
experience
should
be
consistent
everywhere.
We
have
a
list
experience
that
has
types
of
issues
on
it.