►
Description
Pedro Moreira da Silva, Product Designer on Create:Code Review, shares a design concept to restructure merge requests.
Issue: https://gitlab.com/gitlab-org/gitlab/-/issues/355574
A
Thank
you
so
much
for
providing
your
feedback.
It
has
given
me
a
lot
of
food
for
thought
and
I
hope
that
this
concept
solves
some
of
the
issues
that
we've
talked
about
in
in
the
designs.
So,
first
off,
let
me
just
say
that
this
concept,
even
though
here
I'm
showing
the
global
navigation
sidebar
collapsed.
I
think
it
can
still
work
with
that
sidebar
expanded,
so
yeah.
A
Just
that
caveat
that,
even
though
here
it's
displayed
as
collapsed
for
simplicity,
I
think
it
can
still
be
displayed
expanded
even
by
default
and
you'll,
see
here
that
there
are
oops.
There
are
a
few
designs
that
have
this
pink
background,
and
these
are
more
exploratory
designs
that
may
or
may
not
work.
I'm
not
entirely
sure
we
may
need
to
do.
A
So,
let's
start
with
the
overview,
it
would
be
the
first
tab
and
it
was
this
design
is
actually
very
similar
to
what
we
have
today.
It
just
changes
the
purpose
of
the
tabs,
and
it
has
this
different
way
of
displaying
the
details,
sidebar
and
so
as
you'll
notice.
Here,
the
big
changes
are
the
fact
that
we
have
the
comments
and
reports
tabs
and
the
commits
and
pipelines
tabs
are
not
visible
anymore.
A
What
has
changed
in
a
very
summarized
view,
so
that
you
can
then
jump
into
the
comments
reports
or
changes
tabs
to
work
according
to
these
different
anchors,
the
description,
the
activity
that
is
filterable
and
it
will
be
a
very
compact
list
of
the
activity
sorted
by
the
most
recent
activity
appearing
at
the
top
and
the
details
sidebar
would
show.
A
A
To
have
the
breadcrumb
crumb
showing
at
the
top,
and
so
that
is
still
up
for
exploration,
so
this
is
an
idea
to
have
the
author,
maybe
even
the
creation
date
showing
in
the
details
sidebar,
including
the
branches
and
this
info
icon.
We
can
use
also
with
text.
You
know,
saying
details
or
show
open
sidebar,
but
we
would
have
a
control
here
that
would
allow
you
to
toggle
this
details
drawer
on
and
off,
in
any
view
of
the
merge
request.
A
Alternatively,
we
can
show
the
details
sidebar
only
on
this
tab,
the
overview
tab,
but
for
now
and
throughout
all
of
the
other
views
shown
in
this
concept,
I'm
keeping
this
toggle
here
but,
as
I
said,
we
can
remove
it
and
have
the
detailed
sidebar
only
shown
in
the
overview
and
the
big
difference
here
is
that
we're
not
expanding
the
activity
stream.
It's
all
compact
and
the
threads
comments
and
reviews
are
shown
separately.
So
two
possible
ideas.
Let
me
show
you
the
the
one
that
I'm
most
confident
on,
which
is
when
you
click
here.
A
It
will
navigate
you
to
the
comments,
tab
and
show
you
that
common
thread
in
full
here.
So,
even
though
the
you
know,
in
this
case,
pedro
approved
and
left
five
comments,
you're
seeing
the
thread
that
they've
commented
on,
and
even
maybe
we
can
allow
you
to
select
a
whole
review.
So
in
this
case,
pedro
left
five
comments.
A
A
Instead
of
jumping
from
the
activity
to
the
comments
tab,
we
can
show
when
clicking
on
a
comment
or
review,
we
can
show
the
selected
common
thread
in
a
drawer
that
appears
on
the
right
side
and
allows
you
to
have.
You
know,
take
a
glimpse
at
the
the
thread
and
reply
to
it
or
if
it's
something
that
is
more
involved
and
you
need
to
type
out
a
larger
response,
or
the
thread
is
quite
long.
You
can
click.
This
expand
button
to
show
this
same
thread
in
the
comments
tab.
A
A
Some
filters
that
we
can
add
here
at
the
top
or
searching
and
the
list
of
reports
would
continue
and
then
for
each
of
the
reports.
We
would
have
a
detailed
view
with
also
searching
and
filtering
capabilities
if
we
want
the
now
common
table
view
that
we
have,
for
example,
for
security
vulnerabilities
with
the
number
of
attributes
detected
status,
severity
and
description
and
would
allow
you
to
see
exactly
what
has
happened
to
each
of
these
reports
and
allow
you
to
act
on
them.
A
Now
the
idea
with
the
reports
tab
is
to
try
to
avoid
having
a
another
tab
just
for
the
inline
findings.
So
inline
findings
would
be
the
the
same
as
inline
comments
that
you
make
on
the
lines
of
changed
files,
but
they
would
be
automatically
made
by
ci.
You
know,
for
example,
to
highlight
code
quality
issues
on
specific
lines
of
code
or
security
vulnerabilities
on
specific
lines
of
code
and
to
avoid
having
another
tab
just
for
those
inline
findings
that
come
out
of
these
reports.
A
A
That
shows
you
only
the
findings
from
code
quality
that
you
were
seeing
seeing
on
this
list,
but
now,
in
a
sorry,
the
the
findings
that
you're
looking
at
on
this
table,
but
now
looking
at
those
quality
findings
in
the
list
view
still
being
able
to
filter
them,
but
now
you're,
triaging
them
and
acting
on
them
one
by
one,
with
a
more
with
more
room
for
the
actual
finding
so
similar
to
comments,
you
could
go
next
to
the
previous
finding
on
this
list.
A
The
finding
details,
the
diff
you
know
shown
next
to
the
findings,
details
so
that
you
can
compare
and
understand
what
you
need
to
do
and
maybe
having
some
actions
at
the
bottom
or
at
the
top
of
the
finding,
and
this
is
an
exploratory
view
design.
We
would
have
to
discuss
this
more
closely
with
our
counterparts
from
verify
and
secure,
but
it's
something
that
can
work
if
we
want
to
leverage
the
design
that
I
was
showing
here
for
comments
to
use
that
for
reports,
details.
A
A
The
difference
with
this
concept,
as
I've
shown
just
now,
is
that
users
can
now
focus
solely
on
one
of
these
contacts.
So
you
can
just
look
at
the
comments
or
just
look
at
the
reports
and
their
findings,
and
these
are
first-class
ways
of
triaging
and
action.
Actioning
on
those
comments
on
those
findings,
so
you
don't
have
to
scroll
up
and
down
in
the
overview,
tab
or
scroll
up
and
down
in
the
changes.
A
But
of
course,
you
can
still
use
the
changes
tab
as
normal
if
you're
reviewing
the
changes
for
the
first
time
or
if
you're
re-reviewing
the
changes
and
you're
wanting
to
understand
what
changed.
Since
the
last
time
you
reviewed
an
exploratory
design
for
the
changes,
tab
is
instead
of
showing
the
inline
comments
or
findings
with
the
changes
would
be
showing
them
in
a
drawer
that
appears
next
to
the
diffs.
A
So
you
can
keep
looking
at
the
diffs
in
a
linear
view,
without
having
the
comments
appearing
in
between
the
lines
of
code
and
having
just
the
comments
on
the
side
to
provide
a
more
a
deeper
separation
of
concerns,
while
maintaining
the
simplicity
of
the
view-
and
this
idea
can
be
expanded
on.
If
we
want
to
you,
know,
show
the
sidebar
on
the
right
on
large
screens,
for
example,
so
this
smaller
screen
would
show
it
the
drawer
like
this.
A
If
we
have
more
space,
we
can
still
show
the
file
tree
and
commit
picker
the
changed
files
and
then
the
thread
or
inline
finding
details
here
on
the
right
side-
and
this
is
it
this
is,
I
think,
one
of
the
concepts
that
I'm
most
happy
with
so
far.
There
are
a
few
open
questions.
Of
course
you
know:
does
this
button
with
an
icon
or
even
with
a
label
or
both?
Would
it
work
to
show
and
hide
the
details?
Sidebar,
do
we
need
the
details
sidebar
always
accessible,
or
can
we
just
keep
it
in
the
overview?
A
The
comments
tab
is:
is
it
more
useful
and
efficient
to
have
this
design
with
lists
and
thread
or
having
all
of
the
threads
stacked
on
top
of
each
other,
and
then
this
idea
of
for
the
reports
of
drilling
down
on
specific
findings
of
one
report,
you
know,
as
I
said,
you
know,
code
quality,
you
have
the
findings
of
code
quality
and
then
looking
just
at
those
findings
in
detail.
So
there
are
a
few
open
questions
here,
but
overall
I'm
I'm
happy
with
where
this
going.