►
From YouTube: 2020-08-04 GitLab's “Issuables” UX
Description
Participants: Pedro Moreira da Silva, Amelia Bauerly, Alexis Ginsberg, and Nick Brandt
We having been working on things that can be considered “issuables” — that follow the issue model of interaction: epics, merge requests, requirements, incidents… maybe others. We sat down to chat about what everyone is doing/thinking that might impact other issuables.
A
A
Basically,
I've
been
meeting
on
and
off
with
holly,
since
we
started
the
category
maturity,
scorecards
process,
and
that
was
a
very
good
moment
for
us
to
talk
about
differences
and
between
issues
and
merge
requests
and
what
we're
doing
with
issues,
what
we're
doing
with
merge,
requests
and
there's
a
lot
of
overlaps,
and
I
feel
that
we
have
neglected
those
overlaps
for
too
long
and
before
which
was
not
too
long
ago.
The
same
people
that
were
working
on
issues
and
merge
requests
yeah.
It
was
the
same
team.
A
There
was
not
different
teams
than
different
designers,
and
so
it
seems
like
today
we're
kind
of
living
in
these
of
the
stage
groups
which
are
very
comfy
and
cozy.
And
it's
nice
that
we
know
everyone.
But
then
we
have
these
overlaps
and
when
we
make
changes
in
one
place,
it
affects
all
of
the
other
places,
because
the
greatest
strength
of
gitlab
is
that
and
that's
why
customers
buy
licenses
and
users
register
on
gitlab.com
is
because
we
have
this
whole
devops
life
cycle,
where
the
features
and
the
stage
groups
are
seamless.
A
They
don't
see
anything
like
that.
We're
the
only
ones
that
are
aware
of
the
divisions
in
the
product,
but
users
don't
are
not
aware
of
that
and
that's
great.
So
we
have
to
keep
it
that
way
so
yeah
I
started
talking
with
her
about
it
these
things
and
then
I
wonder,
like
we
need
to
expand
this
a
little
bit,
because
what
we
considered
initial
today
or
for
a
long
time
was
just
again
issues
and
merge
requests.
A
My
screen
is
the
extensible
issues,
which
was
started
by
gabe
the
product
manager
for
project
management,
if
I'm
not
mistaken
and
from
from
plan
and
so
yeah,
he
he
thought
about
a
lot
of
about
a
lot
of
these
different
objects
and
how
they
relate
to
each
other
and
what
we
could
do
to
finally
address
the
needs
that
a
lot
of
users
have
and
that
customers
request.
Oh,
we
need
issues
to
be
more
extensible.
A
But
in
the
back
of
my
mind,
what
I'm
thinking
is
that
we
need
a
design
framework
to
navigate
these
waters
and
have
a
solid
foundation
that
every
designer
can
work
on
and
that's
something
that
I'm
working
on
now
and
so
the
the
product.
What
I'm
doing
right
now
is
a
very
dumb
documentation
of
and
and
not
smart
at
all,
documentation
of.
A
Where
are
we
listing
or
do
we
have
a
summary
of
the
changes
to
objects?
Attributes?
What
are
the
actions?
Where
are
the
non-embedded
actions
and
also
the
non-transactional
actions?
And
all
of
these
have
a
description.
I
won't
explain
them
in
detail,
but
you
can
see
more
or
less
what
I'm
aiming
for
with
kind
of
categorizing
all
of
these
blocks
of
information
and
actions,
and
you
can
quickly
see
the
nice
groups
and
the
not
so
nice
groups
and
the
inconsistencies
in
this
case.
A
This
is
the
merge
request
page
and
you
can
see
that
the
actions
are
all
over
the
place
and
some
of
them
have
a
good
reason
for
it
and
others
just
don't
have
any
good
reason
and
just
confuse
users
and
that's.
This
is
a
source
of
frustration
by
many
of
them,
and
just
this
exercise
just
makes
that
visible,
and
then
we
also
did
a
smaller
exercise,
which
was
to
highlight
still
on
the
same
page.
The
merge
request
page.
Where
are
the
goal?
A
Related
information
and
actions
and
again
you
can
see
like
the
actions,
are
all
over
the
place
and
the
information
that
drives
and
that
helps
propel
the
user
forward
to
completing
the
main
goal,
which
is
to
get
the
merge
request
merged
where
that
information
is
and
it's
all
over
the
place.
Yeah
and
I've
started
to
do
the
same
with
issues
and
epics.
A
I
haven't
gone
to
incidents
and
and
requirements
yet
because,
I'm
to
be
honest,
I'm
not
very
familiar
with
how
it
is
today.
But
what
I'm
thinking
right
now
is
then
for,
of
course,
for
issues
and
epics
to
ping
holly
and
alexis
to
help
me
out
with
this
and
see,
if
I'm
thinking
correctly
and
then
in
a
very
iterative
and
boring
way,
just
link
to
this
figma
file
from
pajamas
and
from
then
on.
A
A
Epics-
and
this
is
just
a
quick
example
of
again
I'm
here-
I'm
just
looking
at
the
object
in
a
dumb
way.
So
it's
it's!
It's
not
looking
at
how
it's
visualized
or
anything
like
that,
it's
as
if
we
were
starting
from
scratch,
gitlab
and
we're
describing
and
listing
out
what
are
the
attributes
of
whoops.
I
don't
know
what
I
did
here.
A
A
A
That
can
then
have
also
reply
comments
and
then
can
have
threads,
and
this
highlights,
for
example,
one
of
the
inconsistencies
that
we
have
today
in
the
product,
with
the
way
that
people
write
comments,
and
so
you
can
see
that
a
top-level
comment
only
is
only
turned
into
a
thread
when
they
have
replies
right.
That's
how
we,
in
terms
of
the
concept,
that's
how
we
treat
it.
A
top-level
comment
is
not
a
thread
on
its
own
unless
it
has
replies
and
the
difference
in
in
the
these
things
here.
A
It's
basically
this
very
bad
design
that
we
have
today
of
making
people
choose
between
commenting
or
starting
a
thread
right,
and
these
two
actions
creating
two
separate
kinds
of
objects,
is
exactly
what
we're
visualizing
here.
So
I
think
in
a
way
this
can
help
us
make
things
better.
Just
by
looking
at
it
from
a
purely
conceptual
standpoint,
yeah
I'll
share
all
of
these
materials
with
you
in
case
you're
interested.
But
this
was
just
a
very
long
intro
and
I'd
like
to
hear
your
thoughts
as
well
and
then
also
what
you've
been
struggling
with.
B
B
Many
other
things
users
were
looking
for
are
things
that
are
currently
available
within
issuable.
So
obviously
it
makes
sense
for
us
to
transfer
those
into
an
issue
bowl,
but
we
were
looking
to
kind
of
piggyback
on
a
lot
of
the
work
that's
being
done
by
incidents
and
these
extensible
issues,
and
so
I
I
would
love
to
be
a
part
of
you
know,
building
this
out
and
kind
of
better
understanding
which
ways
we
can
improve
on
the
issues
model
as
we
do
that.
D
Yeah
I
also
appreciate
it.
I
hadn't
had
a
chance
to
look
through
the
the
figma
file
that
you
had
created
pedro
and
I
think,
as
we
were
kind
of
trying
to
put
together
the
design
for
incidents.
There
were
a
lot
of
small
questions
like
should
we
combine
all
these
buttons
into
a
single
button
and
at
that
point,
because
we
had
to
move
forward,
we're
like
we
don't
have
any
research
and
we
don't
actually
have
enough
information
to
make
this
change
yet.
But
we
would
like
to
make
this
change
in
the
future.
D
So
I
feel
like
there
were
a
lot
of
these
like
these
things
that
we
needed
to
do
for
the
first
iteration
that
we
know
that
are
not
right,
but
we
didn't
have
enough
information
to
change
the
existing
design,
but
if
we
had
more
of
a
vision
that
these
are,
this
is
where
all
the
buttons
are
going
to
be.
For
all
of
these,
you
know
extensible
issues
or
issues.
Whatever
we
decide
to
call
them,
then
it
just
makes
that
easier.
And
if
that's,
you
know
researched
and
it's
going
to
be
consistent
across
everything.
D
That's
going
to
make
it
just
a
thousand
times
easier
and
we're
not
going
to
end
up.
I
just
have
like
a
horror
vision
of
like
all
the
different
issues,
we'll
all
have
buttons
in
different
places,
because
we
didn't
it's
hard
to
we're
all
going
to
have
different
buttons
that
we
need
and
we're
all
going
to
be
making
different
decisions.
If
it's
not
documented,
you
know
it
will
lead
to
inconsistency.
So
I'm
glad
this
is
happening
and
I'm
happy
to
help
work
on
the
incidents
piece
of
it
and
contribute
what
you
know.
D
The
things
that
I've
run
into
as
I've
been
working
on
that
and
yeah.
I'm
glad
this
is
happening.
I
think
we'll
make
it
a
thousand
times
easier
for
everybody
who
comes
after
us
like
it
sounds
like
they're
gonna
make
a
an
issuable
or
extensible
issue
type
for
future
flags
and
for
run
books
shortly.
So
more
are
coming
so
the
more
I
guess
we
can
get
ahead
of
this.
The
better.
B
C
Yep
it's!
This
is
great
pedro.
Thank
you.
I
know
I
saw
the
async
feedback
you
did
and
I
was
like.
Oh,
I
really
want
to
do
this
for
issues,
so
I'm
glad
you've
already
started
that
and
epics
as
well,
so
that'll
be
helpful
and
even
thinking
about
like
some
of
the
research
we've
been
doing
on
metadata
right,
like
the
really
nitty
gritty
things
and
all
the
feedback
we're
getting
around
things
being
kind
of
like
too
cluttered.
I
think
this
will
help
focus
in
on
cool.
What
are
the
main
jobs
of
each
of
these?
C
A
Yeah
this
is
this
is
great
to
hear
yeah.
This
is
again
like
more
validation
that
I'm
not
the
only
one
me
and
holly
like
struggling
with
all
of
these
questions
and
yeah
and
then
like
very
two,
very
direct
things
that
we've
all
noticed
or
probably
noticed
with
issues
and
merge
requests
which
are
probably
the
most
used.
Issuables
is
like
issues
now
have
a
sticky
title
bar
right,
merge
requests,
don't
and
merge
requests
have
the
sticky
tabs
and
issues
you
had
the
tabs
before
with
design.
C
C
A
Yeah,
I
think,
in
a
way,
I
think
it's
it's
fine
if
we
implement
things
at
different
rates
and
like
first
do
it
in
issues
and
then
doing
emergency.
I
think
that's
fine,
if
there's
a
rationale
behind
it
and
there's
a
plan,
but
for
these
things
they're,
I
don't
know,
but
I
don't
know
if
there
was
a
plan,
so
I
at
least
the
one
I
can
speak
for,
which
was
the
merge
requests
apps,
which
I
was
involved.
A
I
really
didn't
think
about
issues
and
epics,
and
that
was
probably
one
of
my
fault,
but
if
we
had
some
kind
of
documentation
to
reinforce
what
was
already
there,
if
we
had
these
kinds
of
conversations
more
often,
I
think
that
would
probably
come
up
immediately
right
and
that's
what
I'm
trying
to
prevent
yeah.
I
I'm
really
good
to
glad
to
hear
all
of
the
positive
feedback
from
you.
A
So
in
terms
of
the
what
I
showed
you,
the
interaction
design
framework,
I
will,
I
don't
have
a
specific
to
do
for
you
right
now.
I
will
probably
ping
you
on
things
that
I'm
have
questions
or
that
I
would
like
to
you
to
take
a
look
at
so
I
don't
want
to
take
your
time
and
your
capacity
to
go
through
all
of
that,
because
it's
a
lot
so
helping
you
in
due
time.
I'm
just
now
I'll,
I'm
wondering
what
you
all
are
working
on.
A
D
I'm
actually
working
on
something
a
sorting
of
the
comments
thing
and
I
didn't
realize
that
you
had
worked
on
that
originally
nick,
so
I'll
ping,
you
on
the
issue
yeah,
I
I
feel
like
there
are
like
a
thousand
little
decisions
that
we're
making
every
day
and
I'm
never
really
sure
who
to
reach
out
to
so.
This
meeting
has
already
been
super
helpful
because
I
know
who
I
actually
reach
out
to
to
ask
my
question
now
now.
C
That's
like
a
perfect
example
like
nick
did
a
great
job
with
that,
but
because
we're
not
probably
like
you
know,
it
goes
higher
than
design
at
some
points
right
and
to
your
point
pedro
we
get
to
we're
getting
siloed.
That
was
something
I
was
a
little
bit
worried
about
like
even
at
a
group
level
right
and
you
saw
it
get
solid
from
a
stage.
C
In
we
just
started
with
stages,
so
yeah,
that's
another
thing.
That's
really
great
about
this.
Thanks
for
thinking
about
that
pedro.
For
me,
I'm
kind
of
shifted
focused
to
boards,
so
I
I
don't
know
if
we
can
include
boards
and
issuables.
Somehow
I
don't
know
if
we
get
the
game
in
at
that
level,
because
I've
been
thinking
really
when
I
work
on
like
road
maps,
so
I've
been
looking
at
road
maps,
epic
boards
kind
of
shifting
between
the
three
and
really
they're
all
different
views
of
the
same
information.
C
A
Than
that,
I
think,
I
think,
that's
very,
very
important
right
because
the
lists,
and
even
like
what
we
were
just
talking
about
something
as
small
as
the
sorting
how
does
that
persist
across
projects
across
groups
across
instances
of
an
object.
All
of
those
things
are
not
properly
documented
and
we
should
document
it
somehow.
Yeah.
C
But
starting
with
issuables,
I
think,
is
great,
like
we
could
start
somewhere
but
yeah
anywhere.
I
could
help,
I
would
say
the
most
relevant
is
epic,
so
anything
you
need
support
with
there
or
if
you
want
me
to
take
it.
However,
you
want
to
work
on
that
happy
to
help
there
because
yeah
it's
it's
an
issue,
that's
not
quite
as
mature
as
an
issue
and
at
some
point
we
want
to
add
in
things
like
initiatives
or
themes
which
is
like
a
another
higher
level
than
than
epic.
C
A
I
think,
to
be
honest,
I
think
I
disagree,
I
think
epics
are
can
actually
be
more
powerful
than
issues.
Maybe
the
most
powerful
of
all
is
merge,
requests
which,
right
now
that
power
translates
to
very
complex
and
confusing,
but
epics
is
very
powerful.
You
can
do
all
of
that
different
nesting
and
the
ability
you
have
to
view
the
road
map
in
the
tree.
That's
that's
unparalleled
and
you
don't
have
that
in
issues.
Issues
are
kind
of.
B
C
So
I'm
checking
with
anjay
tomorrow
about
that,
so
we
just
did
all
the
interviews.
I
need
to
go
through
dovetail
and
synthesize
everything,
but
this
the
first
initial
phase
was
portfolio
management,
so
that
would
be
the
epic
list
epics
and
a
bit
of
the
roadmap
as
well.
So
next
phase
is
going
to
be
more
of
the
issue
tracking
and
milestone
work,
and
then
the
next
phase
we'll
be
getting
into,
like
mrs,
which
of
course
pedro.
I
think
any
help
you
want
to
give
there
I'll.
Just
involve
you
as
much
as
I
can
so.
C
A
A
C
C
A
Yeah,
because
one
of
the
things
that
I
was
yeah,
I
mean
just
coming
back
to
what
you
were
saying.
You
published
the
findings
and
pingas
there,
and
maybe
from
there
like
nick
emilia
myself,
you
and
hollywood
can
then
understand
and
see
how
the
findings
impact
our
own
work
and
what
we've
done
with
requirements,
incidents
and
so
on.
I'm
I'm
curious,
if
just
very
quickly,
because
I
created
this
issue
more
or
less
at
the
same
time
that
you
created
that
research,
which
is,
I
didn't,
fill
it
out
with
anything.
A
But
the
idea
is
to
research.
What
is
the
user's
perception
of
the
conceptual
model,
and
that
is
basically
like
the
all
the
attributes
and
the
actions
that
we
have
in
the
issuables
and
I
feel
like
that
is
very
related
to
what
you
were
doing
in
so
much
that
mike
linked
to
your
research,
which
which
talks,
I
think
more
about
the
metadata
on
lists
and
not
so
much
in
in
when
you're
in
the
object
itself.
How
do
you
think
do
you
think
that
this
issue
that
I
created
is
is
worthwhile?
A
C
So
I
think
I
think
it
could
still
be
helpful.
I
think
we're
kind
of
just
scratching
the
surface
of
that
with
the
metadata
research
right.
It's
more
pointed,
like
cool.
Look
at
this
list
like
rank,
what's
important
to
you.
Why
so
like
a
higher
level
understanding
but
the
model
of
literally?
What
is
a
list?
C
I
don't
know
if
we're
getting
to
that
level,
which
I
think
is
what
you
are
trying
to
investigate
if
I'm
correct,
so
maybe
maybe
the
metadata
research
is
a
good
starting
point,
but
I
think
that
the
overall
conceptual
model
research
you're
doing.
I
think
that
could
be
useful
as
well.
Ours
is
a
little
more
tactical
and
it
started
very
tactically
like
what.
How
do
I
organize
this
information?
What
is
the
hierarchy
stuff
like
that?
A
Yeah
yeah
it
does,
it
does
cool
yeah,
that's
very
helpful
yeah.
I
don't
have
any
timeline
to
work
on
this.
I
have.
I
already
have
a
lot
of
my
plates,
so
I
kind
of
I'm
kind
of
doing
this
on
the
side.
You
know,
as
with
everything
that
is
proactive
at
gitlab,
you
kind
of
do
it
on
the
side
of
the
milestone
work,
so
so
yeah
cool
any
any
last
thoughts,
we're
already
over
time.
A
A
A
I'll
I'll
leave
you
some
things
to
to
provide
feedback
async.
Well,
I'm
off,
so
that
when
I
come
back,
I
already
have
some
info
from
you
yeah,
but
I'm
just
wondering
like
this.
This
meeting
or
this
sharing
knowledge
about
what
we're
doing
I'm
just
wondering
what
would
be
the
best
medium
we
don't
have
to
decide.
Now,
however,
we
can
go
about
our
day
and
think
about
it
and
then
talk
later.