►
Description
Pedro (Senior Product Designer) and James (Senior Product Manager) discuss the future of merge requests.
Share your feedback with us here: https://gitlab.com/gitlab-org/gitlab/issues/36119
A
We've
shipped
over
the
past
year,
including
multiple
assignees,
multiple
approval
rules,
code
owners
suggesting
changes
all
these
are
based
on
UX
feedback,
but
I,
guess
they're
kind
of
iterating
on
what
we
already
have
improving
it
listening
to
feedback,
but
not
substantially
changing
the
workflow
and
we've
been
hearing
feedback
from
customers.
You
know
interviews
and
discussions
and
comments
being
left
on
issue
boards
about
how
we
might
really
take
image
requests
further
and
solve
some
harder,
more
complex
problems
and
the
moon
request
is
a
really
significant
place
where
people
do
a
lot
of
work.
A
It's
where
everyone
collaborates
on
major
quests,
where
code
quality
is
ensured
and,
as
a
result,
significant
time
is
spent
in
this
interface
and
so
I.
Guess
we've
been
asking
ourselves
how
we
can
significantly
decrease
the
cycle.
Time
increase
the
efficiency
of
code,
review
and
I
guess
create.
Maybe
new
ways
of
collaborating
I
think
the
merge
request.
Interface
we've
got
today
is
pretty
similar
in
a
lot
of
ways
than
it
was
five
years
ago.
A
I
mean
we've
improved
it
a
lot,
but
it's
fundamentally
the
same
workflow,
so
I
think
there's
three
key
questions
that
we've
kind
of
asked
ourselves
and
have
surfaced
through
research
which
catching
up
an
understanding
where
the
merger
quest
is
so
since
I
last
looked
at
it.
What
needs
my
attention?
What's
changed,
helping
me
more
efficiently
review
that
difference
after
that
first
review,
the
other
one
is
considering
real
time
collaboration.
A
A
lot
of
teams
are
based
in
the
same
location
or
same
time
zone
and
have
significant
overlap,
even
a
gitlab,
most
people
who
work
together
have
a
couple
of
hours
of
overlap
today
in
a
day
and
look
at
things
that
similar
sorts
of
times.
So
if
people
are
coming
to
the
same,
merge
request
working
on
it
at
the
same
time,
how
can
we
make
that
more
efficient
and
then
remote
is
a
really
big
value?
We
have
a
git
lab.
A
A
synchronous
communication
is
something
that
we
we
do
really
well,
but
there's
a
it's
a
tool,
and
sometimes
it's
a
better
tool
to
work
synchronously
to
get
on
a
call
and
like
solve
confusions,
communicate,
sketch
things
out
and
then
document
those
decisions.
But
the
murder
request
doesn't
provide
a
natural
way
to
do
that.
We
use
oome,
we
use
Google
Docs
and
then
we
try
and
summarize
it
in
the
merged
requests
or
issues.
Wouldn't
it
be
great
if
we
could
find
a
way
to
integrate
all
that
into
the
merge
request.
A
So
those
are
some
of
the
things
we've
been
thinking
about.
As
we've
been
solving
the
more
obvious,
simpler
problems,
how
can
we
solve
these
harder,
more
complicated,
large
problems
that
maybe
require
rethinking
the
things
that
we've
come
to
sort
of
accept
as
the
default
of
merge
requests
so
Petra
I'll
hand
over
to
you
to
maybe
share
some
of
the
mock-ups
and
wireframes
of
where
we've
landed
so
far
and
add
some
color
with
a
concrete
example
sure
yeah.
B
See:
okay,
are
you
seeing
my
screen?
Cool
I
can
awesome.
So
let's
get
started.
So
this
is
very
low,
fidelity
mock-ups,
so
that
we
can
focus
on
the
essential
details
and
I'll
walk
you
through
some
steps
of
this
short
visual
story.
So
in
this
first
step
as
a
reviewer
I
can
see
what
has
happened
since
I
last
reviewed
this
merging
process-
and
you
can
see
at
the
top
here
that
there
are
two
files
that
didn't
need
my
attention
that
I
need
to
review.
B
Maybe
they
were
changed
since
the
last
time
that
I
was
here
and
there's
also
one
comments
that
needs
my
attention.
Someone
replied
to
my
initial
comments,
or
maybe
someone
resolved
the
comment
and
I
need
to
see
why
it
was
resolved.
So
I
can
immediately
have
this
personal
area
where
I
see
what
it's
most
important
to
me.
B
So
I
click
through
to
see
this
comment
that
I
need
to
reply
to
and
I
can
see
that
in
this
discussion,
James
and
Catherine
are
having
an
argument
about
what
this
change
is
for,
and
it's
a
bit
of
convoluted
discussion.
There's
a
lot
of
different
topics
going
on,
but
because
they're
in
different
time
zones
I'm
just
going
to
leave
a
comment
here
and
so
that
they
can
then
read
it
in
their
own
time.
B
B
It
says
here
that
he's
not
only
the
code
owner
of
this
file
that
we're
changing,
but
he's
also
the
person
who
has
changed
this
line
of
code,
and
this
is
incredibly
important
because
I
think
that
it's
a
good
indication
that
Andre
might
have
some
background
information
and
could
help
us
move
this
discussion
forward.
So.
A
Yeah
Inc,
we
already
do
something
like
this
right
in
that
we
suggest
people
who
are
already
involved
in
the
conversation
like
people
who
created
the
issue.
But
this
is
this:
mock-up
is
trying
to
bring
in
new
forms
of
data
and
also
I
think
more
clearly
highlight
the
people
and
why
they're
relevant,
whereas
maybe
today
we
just
show
like
a
sorted
list,
it's
got
some
funny
sorting
that
isn't
maybe
amazing,
yes
to
the
user,
yeah.
B
B
So
maybe
if
we
made
that
visible
and
explained
why
we're
starting
in
this
way
and
make
it
a
bit
more
clever,
it
can
be
more
useful,
and
this
is
one
of
the
cases
where
you
can
immediately
see
that
the
first
person
is
the
person
that
is
most
most
attached
to
this
file
or
int
or
to
this
specific
line
of
code.
Then
you
have
the
author
and
then
you
also
you
have
reviewers.
B
Maybe
we
can
then
list
the
reviewers,
so
you
can
quickly
ping
them
so
yeah,
I
I'll
leave
the
comment
and
meanwhile,
while
I'm
doing
my
review,
I
noticed
that
both
James
and
Catherine
are
now
online.
So
you
see
this
indicator
with
their
avatars,
which
means
that
they're
online
very
much
similar
to
how
you
would
see
someone
in
Google
Docs.
B
Looking
at
the
same
document
that
you're
looking,
it
means
that
they're
now
actively
focused
on
this
merge,
request
and
I
receive
at
the
same
time,
a
notification
and
the
browser
saying
that
catherine
mentioned
me
in
a
comment
and
I
can
also
see
that
James
is
typing
a
reply
to
a
comment
that
I
just
left
so
I
can
see.
People
interacting
with
the
merge
requests
in
real-time
I
can
notice
their
presence
but
I'm,
not
necessarily
seeing
what
they're
typing
and
I'm
not
collaborating
directly
with
them.
We're
just
going
about
doing
our
own
tasks
separately.
A
I
think
is
really
really
cool
and
exciting
because
it
sort
of
helps
people
know
that
each
other
are
there
right
and
we
might
change
the
way
we
work
together.
If
we
can
expect
an
immediate
response
like
if,
if
you're
I
see
you
typing
somewhere
and
then
I'm
responding
you
to
it
on
a
different
thread,
I
might
I
might
ask
you
a
question
which
is
sort
of
more
open-ended,
because
I
know
that
you're
probably
able
to
respond
quite
quickly
versus
maybe
writing
a
longer
response.
B
B
Exactly
and-
and
this
is
very
helpful
not
only
for
people
that
work
distribute
lis
and
asynchronously
like
we
do
at
git
lab
as
a
remote
only
company
but
I
think
also
for
people
that
work
in
the
same
time
zone,
maybe
even
in
the
same
location
in
the
same
office
in
the
same
room.
It's
quite
important
to
have
this
visibility
that
people
are
also
looking
at
it
creates
it
gives
you
more
expectations
and
a
sense
of
progress
to
the
merge
requests
as
well.
Yeah.
A
One
thing
I
remember:
working
in
previous
teams
and
I've
seen
to
eliminate
expedited
gitlab
as
well
is
often
when
you're
waiting
on
a
code
review.
You
don't
really
know
if
someone's
looked
at
it
and
if
you
can,
if
you're
working
on
a
code
on
a
merge
request
and
you're
the
author
of
it,
and
you
can
just
see
people
coming
in
and
out
looking
at
it,
you
know
that
something's
happening,
even
if
they
maybe
haven't
finished,
done
doing
the
review.
A
It
saves
me
walking
over
to
their
desk,
which
or
someone
walking
over
to
my
desk,
which
used
to
interrupt
me
all
the
time
when
I
worked
in
an
office
with
people
or
even
even
if
people
don't
tap
you
on
the
shoulder
physically,
they
might
send
you
a
slack
message
and
be
like
hey.
Did
you
look
at
this
thing
and
that
might
be
interrupting
or
unnecessary
this?
This
gives
a
sense
of
progress
without
necessarily
needing
to
sort
of
have
someone
take
an
active
measure
to
find
out
if
progress
is
being
made.
A
B
And
this
is
just
one
of
the
many
ideas
that
we
have
around:
providing
this
sense
of
progress
to
authors
of
merge
requests
and
also
reviewers.
There's
these
two
roles
that
are
in
play
and
numbered
requests
and
in
the
code
review-
and
this
is
just
one
of
those
ideas
so
now
that
I
see
that
they're
online
and
actively
commenting
and
working
on
this
merge
request.
I'm
thinking,
wouldn't
it
be
great
if
we
could
just
work
together,
collaborate
on
the
open,
threads
and
open
discussions
and
then
close
them
out
and
have
clear
next
steps.
B
B
If
I
want
to
focus
all
of
the
participants
attention
to
a
specific
comment
or
file,
maybe
I
can
even
copy
a
link
to
this
shared
session
and
paste
it
on
slack
so
and
or
another
chat
tool
or
an
email
so
that
others
can
join
without
having
to
go
through
finding
the
merge
request
and
etc.
And
the
most
important
thing
I
think,
is
the
ability
to
co-author
and
collaborate
in
real
time
in
comments
in
the
merge
request.
B
So
you
have
the
ability
to
collaborate
on
these
different
types
of
comments,
while
you're,
if
you
have
a
zoom
meeting
open
or
another
video
call
or
maybe
you're
offline
in
the
office
just
next
to
each
other
with
a
shared
session,
you
can
quickly
reach
consensus
and
know
that
these
comments
and
these
decisions
and
these
thoughts
and
opinions
were
authored
together
and
people
can
edit
them,
and
you
know,
just
publish
your
joint
accumbens.
This.
A
Is
really
cool,
it
feels
a
looks,
a
lot
like
a
Google
Doc
working
together,
but
on
a
merge
request.
I
think.
If
we
work
out
how
to
do
this
right
on
merge
requests,
we
can
apply
it
to
issues
as
well,
which
is
the
other
area,
I
think
and
Epix
as
well,
which
I
think
would
be
super
relevant.
But
I
know
that
some
teams
that
work
in
the
same
office
really
close
to
each
other
do
code
reviews
in
a
meeting
room
where
they
put
the
code
on
a
projector
and
they're
all
reviewing
it
together.
A
Everyone's
got
their
laptops,
but
they're
sort
of
looking
at
the
same
thing
right
this
all
of
a
sudden
would
allow
everyone
to
sort
of
be
taking
those
notes
collaboratively
putting
them
down,
sharing
them,
because
it's
often
hard
to
see
what's
on
a
projector
or
if
you're
doing
it
over
zoom,
like
some
people
do
code.
Reviews
like
screen
sharing
can
be
really
hard
to
follow,
and
this
kind
of
creates
an
interesting
way
of
documenting
and
sort
of
bridging
that
gap
and
I.
A
B
A
A
B
So
it
it
automatically
notes
that
me
who
started
the
comments
and
who's
also
collaborating
on
this
comments.
So
people
don't
have
to
write,
and
we
know
that
these
comments
were
made
together
and
then
their
joint
decisions
and
opinions
and
yeah,
and
also
the
use
case
that
you
highlighted
having
a
projector
in
an
office
and
people
going
through
a
code
review.
It's
something
that
we've
heard
a
couple
of
times
in
user
interviews,
so
other
companies
are
also
doing
that.
So
there
are
many
use
cases
that
we
can
solve
here
and
I.
B
Think
from
a
user
experience
standpoint,
it's
really
important
that
we
try
to
use
metaphors
and
patterns
that
people
have
seen
in
other
tools
and
common
tools.
So
you
were
mentioning
like
this
looks
like
Google,
Docs
and
I.
Think
that's
a
good
thing
right,
because
people
can
immediately
relate
and
understand
what
these
cursors
mean
and
also
this
top
part
with
the
avatars
like
people
are
looking
at.
This
merge
request.
So
using
these
same
paradigms
with
not
at
at
face
value,
but
also
studying
and
understanding
if
they
fit
into
the
specific
context,
is
something
that
we're
very.
B
So
yeah
this
is
this
is
great
and
it
allows
us
to
look
like
ninjas
I'm,
just
trying
to
move
this
to
the
side
but
yeah.
So
we
can
quickly
reach
a
consensus
using
this
way
of
collaboration,
and
we
can
even
leave
comments
in
the
regular
thread
so
that
others
can
see
what
we
were
discussing.
What
were
the
decisions
in
water?
B
What
are
the
next
steps
after
we
meet
Kathryn
and
James
Matz
and
inside
of
this
merge
request-
and
this
was
way
quick
week
quicker
way
of
collaborating
and
getting
to
the
resolution
all
of
all
of
those
discussions
instead
of
having
to
quickly
where
you
said
of
just
leaving
comments
and
expecting
others
to
reply,
because
we're
all
looking
at
the
same
Mudd
request.
This
was
way
faster
and
one
of
the
best
part
is
that
we
don't
have
to
jump
from
tool
to
tool.
So
we
are
working
in
a
merge
request.
B
We're
writing
the
comments,
we're
writing
the
notes
of
our
call
and
what
we're
discussing
this
short
collaborative
meeting
and
we're
in
the
same
tool.
Looking
at
everything
and
recording
the
decisions,
we
no
need
to
write
things
in
a
in
paper
or
in
a
Google
Doc
or
in
a
chat
tool
and
then
copy
them
over
to
a
git
lab.
Everything
is
recorded
in
git
lab
and
you
can
use
other
tools
like
zoom
slack
or
others
like
a
video
projector
right
to
collaborate
better
depending
on
your
work
setting
and
what
works
best
for
your
in
your
company.
B
A
B
It's
all
one
last
idea
that
we
wanted
to
show
to
complete
this
short
visual
story
is
the
ability
of
communicating
decisions
and
rationale
for
the
future.
So
one
thing
that
we
see
happening
a
lot
inside
of
gitlab
and
in
other
companies
that
people
when
they're
explaining
something
in
writing
in
the
comments
in
an
email
in
chat
tool
when
they're
explaining
a
decision
or
why?
Don't
we
don't?
B
We
shouldn't
touch
in
this
specific
part
of
the
code
because
it
could
break
this
or
that
that
usually
should
be
a
code
common
that
usually
should
be
left
for
posterity,
so
that
other
people
that
eventually
change
future
authors
and
in
future
merge
requests.
They
can
see
why
this
decision
was
made,
why
this
function
or
why
this
class
shouldn't
be
changed
or
remained,
or
something
like
that.
B
So
after
our
call
in
our
shared
session,
in
the
merge
request
with
James
and
Catherine
I
decide
to
go
back
to
one
of
our
comments
and
I
feel
like
it's
so
important
for
people
in
the
future.
To
know
why
we
discussed
this
in
the
merge
request
that
now
I
have
the
ability
to
commit
this
comments.
That
I
wrote
here
as
a
file
comments,
so
this
is,
if
you've
used
our
suggestions,
feature
inside
of
merchants
quest.
B
If
you
haven't
you
should
it's
a
great
feature
and
it
basically
allows
you
to
write
comments
as
normally,
but
also
apply
part
of
what
you're
writing
in
your
comments
directly
into
the
file
and
with
this
idea
we're
moving
the
comments
that
you
usually
make
in
in
a
multiplayer
a
discussion
and
applying
them
to
the
file
itself,
and
so
once
this
merchants
quest
is
merged.
This
file
will
have
this
file
comments
and
other
authors
and
in
future
image
requests.
They
can
understand
what
was
discussed
here
and
the.
B
A
A
A
B
Yeah,
so
this
is
again
a
short
visual
story
to
show
a
couple
of
ideas:
we're
not
entirely
sure
how
these
will
be
executed
if
all
of
them
are
viable
or
not,
if
they're
good
ideas
and
that's
why
we'd
love
people
to
comment
on
the
issue
that
we
have
open
for
feedback
and
leave
your?
What
do
you
liked?
What
you
didn't
like?
What
other
ideas
you
have,
that
could
improve
code
review
and
again
this
short
story
doesn't
mean
that
we're
going
through
with
these
ideas.
B
A
Yeah
I
think
one
of
the
maybe
we
talked
about
some
of
those
questions
that
have
come
up
briefly,
one
of
them
that
sort
of
serviced
is
around
privacy.
People
feeling
concerned
about
revealing,
when
they're,
looking
at
a
merge
request,
who
that's
going
to
be
revealed
to
whether
that
would
then
create
a
situation
where
people
start
interrupting
them
and
I
think
that's.
Another
concern
is
like
interrupting
flow
like
if
I'm
coming
in,
to
do
a
code
review
I
might
want
to
just
go
deep
and
understand
it.
A
B
B
B
We
want
to
enable
collaboration
in
the
right
moments,
and
so,
as
said,
James
I
think
privacy
is
a
big
concern
and
also
privacy,
in
the
sense
of
pressure
that
you
have
on
your
shoulders,
knowing
that
other
people
are
seeing
what
you're
writing
or
that
other
people
are
watching
it
at
watching
the
same,
merge
request,
I,
don't
know,
and
that's
why
we
are
sharing
this
and
we
need
people's
feedback.
This
is
one
of
the
concerns
that
we've
realized.
This
is
maybe
one
of
our
blind
spots.
There
could
be
other
blind
spots,
so
we'd
love
the
community.
A
That's
I
think
one
of
the
reasons
why
we
discussed
having
this
sort
of
you
could
type
your
comment
privately
working
on
a
review
that
people
can't
see
their
comment
until
you
either
start
sharing
it
in
one
of
these
collaborative
sessions
where
you
submit
it.
So
that,
because
writing
constructive
thoughtful
code,
review
feedback
is
hard
and
so
exact.
We
don't.
A
We
don't
want
to
interrupt
that
or
make
that
even
harder
by
knowing
that
literally
every
keystroke,
you
type
could
be
observed
by
someone
else,
because
that
makes
it
hard
to
leave,
notes
and
quickly
sort
of
skim,
the
merge
request
and
then
come
back
to
them.
They
might
be
misinterpreted
while
they're
still
in
draft
form.
A
We
want
to
make
sure
that
we
absolutely
don't
compromise
those
kinds
of
workflows
that
we
know
are
very
common
and
also
there
might
be
other
even
more
amazing
out
there
crazy
ideas
that
we
haven't,
thought
of
which
would
take
the
merge
request
to
an
exciting
new
place.
So
don't
just
give
us
feedback
on
the
ideas
that
we've
come
up
with,
feel
free
to
give
us
even
more
crazy
new
ideas
that
you
think
would
make
the
merge
request
an
even
better
place
to
work
and
get
your
job
done.