►
From YouTube: UX Showcase: Review rounds concepts
Description
Annabel Dunstone Gray discusses various concepts for the upcoming "Review rounds" feature.
A
Hi
I'm,
Annabelle
gray
and
I'm
going
to
walk
through
a
feature
that
we
are
currently
working
on
for
code
review
just
for
a
little
bit
of
background.
The
the
problem
that
we're
trying
to
solve
is
the
same
problem
that
attention
requests
was
solving
and
I'm
not
going
to
go
too
far
into
what
attention
request
was,
but,
as
most
of
you
know,
we're
going
in
a
slightly
different
direction
now.
So
the
problem
is
that
merge
request
reviewers,
allow
users
to
explicitly
ask
people
for
a
review
and
sorry
and
authors
do
too
I.
A
Don't
know
why
that
says:
reviewers,
but
once
that
user
has
finished
the
review,
there's
no
clear
signal
to
the
author
of
The
merger
request
or
additional
reviewers.
What
the
status
is.
What
do
we
need?
More
reviewers
did
those
those
reviewers
approve
it
if
they
didn't
approve
it?
What
does
that
mean?
Do
they?
Are
they
like
officially
requesting
changes
or
do
they
just
forget?
A
That
original
author
will
get.
You
know
one
one
to
do.
One
notification
saying
this
person
has
reviewed
your
word
request
so
just
to
show
like
an
example,
merge
request,
and
you
know,
here's
the
approval,
widget,
and
it
shows
you
many
things
I'm
an
author,
so
I
can't
approve
this,
but
this
list
I
find
kind
of
confusing,
and
it's
not
necessarily
clear
to
me
what
this
merge
request
needs
from
this
group.
A
It
does
say
it
requires
one
approval,
but
it's
it's
not
exactly
clear,
especially
because
it
says
optional
here,
but
also
you
know
one
of
these
eligible
users,
but
when
you're
actually
creating
the
merger
Quest
and
you
see
approval
rules
right
below
reviewers,
but
they're,
actually
not
connected
approval
approval
rules
or
approvers
can
be
separate
than
reviewers.
In
fact,
they
often
are.
This
doesn't
make
it
clear
and
then
here
it
says,
code
owner
approval
is
required,
but,
as
we
just
saw,
it
isn't
required
anyway,
it's
a
little
bit
confusing
and
I
was
thinking.
A
A
This
would
be
the
merge
request
and
then
there's
the
approve
button
and
all
the
other
stuff,
but
I'm
just
focusing
on
the
proof
button
right
now,
there's
no
way
to
expand
to
see
eligible
approvers,
there's,
no
there's
nothing
really
other
than
hey.
You
need
to
approve
this.
I
was
thinking
we
could
add
those
approvers
as
eligible
approvers
into
the
sidebar.
So,
instead
of
seeing
just
the
reviewers,
it
would
take
those
code
owner
code
owner
approval,
approvers
and
Rule
approvers
and
put
them
kind
of
Auto
populate
them
all
right
here.
A
So
when
you
are
the
author,
you
know
exactly
who
needs
to
approve
because
you've
already
set
it
up
in
your
project
and
then,
when
you
select
one
of
these,
it
shows
you
only
the
people
that
match
that
specific
role
or
code
owner
approval
rule
I've
also
added
this
idea
of
like
the
merger
Quest
status.
It's
it's
not
necessarily
a
badge,
but
it
kind
of
helps
get
an
immediate
overview
of
what
the
merge
request
is
showing.
So
in
this
case
the
author
hasn't
done
anything
yet
they've
created
the
merge
request.
A
The
other
thing
that
we
had
feedback
from
attention
requests
was
that
when
people's
attention
was
requested,
they
weren't
sure
why
and
what
specifically
they
were
supposed
to
be
doing.
So
in
this
case,
once
you
select
your
reviewer,
we
might
show
some
sort
of
view
where
you
can
post
your
comment
with
your
reviewer.
So
we
see
this
a
lot
at
git
lab
people
are
like
hey
user.
Can
you
please?
A
Actually,
that's
a
good,
that's
a
good
segue,
because
I
forgot
to
say
something
anyway,
so
I'm,
sorry
that
this
is
such
a
scattered
presentation,
but
some
feedback
that
I
saw
that
came
up
in
some
past
research
also
was
when
you're
like
a
third
or
fourth
or
some
subsequent
reviewer.
You
see
that's
not
a
good
example.
You
see
that
here
there's
one
person
assigned
as
a
reviewer,
but
you
actually
look
at
the
approvals
and
you
see
three
different
people.
It's
up
to
you
to
figure
out.
A
You
know
which
one
performed
which
role
it's
unclear
from
this,
and
at
least
in
a
git
lab
workflow.
We
we
unassign
ourselves
as
soon
as
we
review
simply
to
get
rid
of
this
badge,
I
assume
because
it
says
two
but
I
don't
actually
have
an
action
to
take
here.
These
are
both
assigned
to
me
because
I'm
the
author
of
both
of
them,
but
it
still
shows
that
too,
like
I'm
supposed
to
be
doing
something
with
those
so
in
this
design,
so
yeah.
A
So
in
this
case,
since
the
author
has
assigned
every
single,
every
single
reviewer
and
then
it
changes
automatically
to
interview,
if
you
are
one
of
these
people-
and
you
receive
your
to
do
or
notification
that
says
hey,
this
person
has
requested
your
review.
When
you
arrive
at
the
merge
request,
there's
there's
going
to
be
an
alert
at
the
top.
That
says
this
person
has
requested
a
whatever
review
from
you.
A
Maybe
there's
more
information.
Maybe
the
comment
that
they
added
could
show
up
here
and
then
there's
this
begin
review
button
that
I'm
not
sure
what
will
do
yet
and
then
the
person
will
do
their
review
and
I
like
the
reviews
right
now
that
when
you
submit
it,
it's
just
a
bad
comment
like
I
said
so
it
just
it
just
submits
like
let's
say
six
different
comments
on
the
overview.
A
Page
I
think
it
might
make
more
sense
and
be
easier
to
navigate
if
we
grouped
everything
to
do
with
that
review
in
one
entry
and
activity
view.
So
in
this
case
the
author
requested
a
back-end
review,
they
posted
a
comment
when
they
made
that
request,
then
the
reviewer
reviews
it.
They
have
several
comments
and
they
all
show
up
here
and
maybe
you
can
expand
it
and
collapse
it.
In
this
example,
the
front
end
review
was
approved.
They
left
a
comment
and
it's
done
so.
The
sidebar
might
look
something
like
this
front.
End
was
approved.
A
The
backend
reviewer
did
not
approve
it,
so
the
only
option
here
is
to
re-request
review
and
then
these
three
haven't
reviewed
it.
Yet
we've
received
feedback
from
many
people,
and
some
competitors
do
this
as
well.
They
have
the
approval,
you
can
approve
it.
You
can
comment
or
you
can
request
changes
right
now,
I'm,
looking
at
only
having
two
options
so
either
you
approve
it
or
you
don't,
and
if
you
review
it
and
you
don't
approve
it,
then
it's
kind
of
understood
that
that
person
has
requests
to
changes.
A
So
perhaps
we
don't
need
to
have
that
explicit?
Hey!
You
need
to
change
this
before
we
can
merge
because
it
kind
of
puts
a
Blocker
on
it.
It's
sort
of
I,
don't
want
to
say
rude.
It's
it's
just
an
awkward
kind
of
interaction
and
I've
seen
a
lot
of
teams,
not
use
that
feature
on
competitors.
Products
they'll
just
do
the
comment
because
it
feels
a
little
harsh
or
weird
or
something
to
say,
request,
changes
so
for
now,
I'm,
just
operating
under
approval
or
non-approval.
A
It's
still
under
review,
because
these
three
people
haven't
reviewed
it.
Yet
once
everyone
has
reviewed
it,
then
it
says
changes
requested,
but
that's
just
because
these
two
did
not
explicitly
approve
it
once
everyone's
approved
it
it
says
approved
and
the
author
will
know
what
to
do
and
I
haven't
added
this
in
the
design,
but
ideally
the
top,
and
this
merge
request
badge.
It
would
only
show
a
badge
if
you
are
doing
something.
So
if
someone
has
assigned
it
to
you
for
review,
it
would
show
that
bad.
A
Once
you
submit
your
review
that
bad
will
go
away.
The
author
would
then
receive
that
badge,
notifications,
and
so
it
would.
It
would
be
more
actionable
and
you
would
only
act
if
that
bad
showed,
that
you
had
the
notification
and
then
I
have
the
states
here
for
different
statuses
and
different
reviewer
options,
but
I
think
I
kind
of
already
went
through
that
and
and
then
one
other
small
changes.
Maybe
we
could
add
filtering
in
the
activity
view
just
because
it's
incredibly
cluttered
right
now.
A
So
in
this
example,
you
can
have
all
activity
or
you
can
just
look
at
your
reviews
and
then
the
history
would
be
all
that
stuff
with
you
know
so
and
so
out
of
the
label
and
that
and
then
this
is
git
lab
specific,
because
we
have
so
many
bots,
so
we
could
kind
of
put
them
all
under
there.
But
this
isn't
finalize.
None
of
this
is
finalized
and
I
would
really
love
any
feedback
now
or
later.
C
It's
a
comment,
slash
question:
Annabelle,
it's
really
nice,
seeing
this
prototype.
So
let's
say
coming
to
life
with
life,
because
we
have
introduced
the
concept
of
deployment
approvals
in
the
release
stage.
Recently
I'll
say
like
two
Milestone
three
Milestones
ago,
and
then
one
of
the
steps
that
we
still
haven't
figured
out
is
you
know
the
how
to
connect
the
notification
flow
and
how
to
communicate
how
to
get
people
to
communicate
that
a
manual
deployment
is
well
for
approval
and
how
that
was
approved
and
rejected.
C
So
it's
really
nice
seeing
how
the
insights
from
potential
requests
can
be
used
also
in
in
the
merge
request
but
I
think
there's
a
lot
of
opportunity
for
us
to
collaborate
and
this
one
and
yeah
Emily
I'm,
not
sure
if
Emily's
here
I
cannot
see
from
my
my
iPhone
but
I.
Think
that's
one
of
the
next
steps
for
her
in
the
release
team.
So
just
wanted
to
to
voice
that.
A
C
C
You
can
approve,
of
course,
and
write
a
comment
and
then
that
deployment
will
run
and
then
you
will
run
a
pipeline
for
production
and
if
you
reject
what
happens,
is
that
the
pipeline
just
won't
run
it's
canceled,
but
that's
specifically
for
protected
environments,
and
then
you
can
set
the
rules
similar
to
what
we
do
today
from
merge
requests.
So
a
lot
of
the
UI
and
the
in
the
interaction
was
based
on
the
current
flow
for
merge,
request
approvals.
D
And
how
do
we
surface
that
in
the
products
without
having
to
get
those
people
to
visit
the
you
know,
vulnerability,
dashboard
or
something
like
that,
so
it
I'm
just
adding
a
bit
of
more
context.
It's
not
a
solution,
but
just
that
I'm.
Seeing
that
this
is
emerging
and
and
yeah
we
need.
We
need
to
work
on
it.
E
B
F
F
If
you
thought
about
like
a
workflow
where,
like
you
know,
ux
approves
before
front
end
or
vice
versa,
or
you
know
the
maintainer
like
a
lot
of
people
today,
be
like
hey
once
you're
done,
you
can
you
assign
this
to
the
maintainer
or
something
like
that
like?
Is
there
a
way
that
that
could
actually,
it
seems
like
this
could
actually
probably
pull
that
in,
but
just
curious?
If
that's
something
you're
thinking
about
as
well.
A
It's
really
tricky.
Sometimes
designing
flows
like
this
when
gitlab
uses
the
product
in
such
a
specific
way
and
I
haven't
actually
seen
other
teams
in
any
external
research.
I've
done.
Do
this
reviewer
maintainer
role,
I've
seen
a
lot
of
teams
be
like
okay,
you
need
to
have
two
back
end
approvals
to
not
even
that.
A
Actually
some
people
just
have
like
you
know
you
need
to
have
three
approvals
and
then
they
might
have
those
required
code
owner
approvals,
which
essentially
function
as
backend
front
end,
and
everything
like
that
I
think
automatically
signing
it
to
someone
else
after
approval
is
an
interesting
feature,
enhancement
and
then,
as
far
as
the
ordering
goes,
I
might
just
be
kind
of
up
to
the
team
to
figure
out,
but
yeah
I
see
what
you
mean.
Maybe
you
only
want
to
assign
ux
at
first
and
then
have
them
look
at
it.
A
So
yeah
there's
still
a
lot
of
things
to
be
ironed
out
here
and
then
there's
always
that
like
hey
what?
If
what
if
the
same
group
is
assigned
to
multiple
required
code
owner
rules,
do
we
show
that
over
and
over
can
we
be
smarter
about
it?
There's
a
lot
of
edge
cases.
What
if
people
don't
use
but
like
the
gate,
lab
project
doesn't
have
required
code
owner
rules
either.
So
in
this
case
we
wouldn't
even
be
able
to
use
the
feature
that
I
just
showed
you.
A
A
Yeah
I
think
kind
of
what
I
showed
like.
Ideally,
this
would
prompt
people
to
maybe
start
using
required
approvals
and
maybe
even
enable
them
in
a
gitlab
project
to
see
what
would
happen.
We're
we're
in
a
I,
don't
want
to
say
we're
torn,
but
we
don't
want
to
block
murder
bus
based
on
specific
people
that
that's
from
what
I
understand,
at
least
in
a
Gate
lab
project.
A
B
E
Yeah
I
just
wanted
to
say:
well
one
I
I,
really
love
the
exploration
that
you're
doing
Annabelle
I
it
like
relates
immediately
to
the
situation.
I
was
in
where
I
was
trying
to
figure
out
if
an
MR
had
been
reviewed
by
ux
and
because
we
remove
ourselves
from
the
reviewers
I
couldn't
tell,
and
I
also
didn't
know
that
we
even
showed
like
who
had
reviewed
the
Mr.
So
I
didn't
look
there
and
there
was
not
a
comment
left
either.
E
A
The
types
were
based
on
the
project
settings.
So
if
the
project
setting
said
that
you
needed
to
have
these
rules
approved,
they
would
show
up
in
the
sidebar
and
then
I
added
like
an
optional
one.
So
if
you
also
said
oh
I
know,
this
person
has
way
more
context
into
these
files.
Maybe
you
could
just
add
them
as
an
optional
approver
and
it
wouldn't
count
necessarily,
but
it
would
be.
It
would
be
a
signal
basically
to
everyone
else.
Reviewing
that
says:
hey
this
person
also
needs
to
review
it.
G
Yeah
just
remember
something:
that's
like
either
I
work
on
it
or
use
it,
or
what
kind
of
partial
approval
concept
I'm
not
for
registered
the
case,
like
I'm
being
ascended
to
as
two
roles
to
review.
One
murder
request
a
type
for
one,
but
I
still
need
to
look
for
another
one.
I'm,
not
sure
this
is
Edge
case
or
it's
a
like
different
feature.
A
If
I
push
a
change
that
affects
only
this
code
owner
approved
file,
should
we
only
reset
that
file
should
we
were
said
everything,
but
the
code
owner
approved
file,
so
I
think
that
issue.
It's
not
separate,
I
hadn't
thought
about
it,
yet
because
it's
so
complicated,
but
it's
something
that
we
have
been
discussing
once
again,
because
it's
come
up
again
and
it
there's
definitely
a
use
case
for
it.
It's
just
really
It's
Tricky,
but
no
I,
don't
I,
don't
have
it
here.
I.
G
Understand
the
way
I'll
talk
about
this,
it
already
sounds
complicated,
yeah,
I
think
I
have
a
next
one
is
like
of
the
not
like
the
email
will
be
considered
because
I
think
that's
like.
Maybe
something
I
can
easily
fix
each
time.
I
see
the
email
notification
that
I
need
to
approve.
Something
like
they
have
like.
A
green
message
is
not
really
clear
and
I
think
what
you
change
is
more
clear
like.
Maybe
you
should
be
like
change
it
together
with
the
email
like
message
or
the
template,
that
video.
A
That's
a
good
point
too,
and
that's
something
I
haven't
considered
yet
and
hopefully,
when
we
batch
everything
together
in
this
one
review
object
it.
The
emails
will
need
to
consider
those
two,
because
it's
going
to
change
everything
but
yeah
I
hope
that
it
will
be
clearer,
what's
happening
in
the
email
notifications,
I
don't
have
those
turned
on
so
I'm,
not
sure,
but
I
definitely
need
to
look
into
that
too.
A
G
B
F
A
We
work
in
such
a
very
specific
way
that
seems
to
work
pretty
well
for
git
lab,
but
I've
seen
ongoing
issues
with
you
know,
kind
of
forcing
all
senior
Engineers
to
become
maintainers.
Sometimes
they
don't
want
to
be
maintainers
and
I
saw
a
comment
about
what.
If
we
do
change
our
workflow
to
be,
you
know
instead
of
reviewer
maintainer,
it's
just
two
approvals,
so
two
approvals
per
roll.
A
This
flow
would
potentially
work
for
that.
I'd
have
to
think
a
bit
more
about
it,
but
I've
seen
many
teams
using
a
workflow
where
they
get
their
approvals
and
then
they
merge
it
themselves
as
well,
and
that
seems
to
be
pretty
common.
The
author
just
merges
their
own
murder
quest
after
they
get
their
required
approvals.
A
D
Yeah,
thank
you
so
much
for
sharing
this
I
yeah
I
mean
I,
already
know
everything
that
you
shared,
but
that
last
part
I,
think
or
in
the
middle
I
guess
that
you
mentioned
about
the
merger.
Quests
counts
in
the
global
header.
That
was
a
challenge
with
the
tension.
Requests
that
we
thought
would
be
trivial
in,
in
a
way
that
you
know
the
the
behavior
that
you
explain,
which
would
be
very
similar
or
equal
to
what
we
were
planning
with
attention
requests.
D
It
ended
up
creating
a
bunch
of
different
challenges
for
us
to
solve
and
I
linked
there
to
a
list
of
that
explains
those
challenges.
Briefly,
and
you
know
two
two
examples
that
we
or
in
this
case
I
didn't
consider
at
the
time,
was
when
you,
when
you
don't
have
anything
on
your
court
right,
so
you
send
out
your
requests
for
reviews
to
other
people
and
you've
reviewed
other
people's
merge
requests
that
counts
appearing
as
zero
or
not
appearing
at
all.
D
A
The
the
difference
between
the
badges
is
it's
already
different
like
the
to-do's.
Is
you
know
that
dynamic?
You
know,
look
at
it
now.
It's
supposed
to
be
at
least
look
at
it
now,
because
these
are
the
things
you
need
to
work
on
as
opposed
to
the
issues
which
is
just
there's
everything
you're
assigned
to,
and
it's
almost
meaningless
at
gitlab,
maybe
at
other
companies
it's
more
meaningful,
maybe
when
they
get
assigned
an
issue
they
know
like.
A
Oh
I
need
to
fix
that
right
now,
the
the
merge
request
count
in
my
head
will
hopefully
mean
exactly
what
you
said.
If
it's
zero,
then
you
don't
have
anything
to
do.
Ideally,
the
assignee
section
won't
even
be
there
and
perhaps
removed
altogether
just
a
fun
idea,
but
the
if
there's
a
badge
there.
That
means
you
have
something
to
do,
and
that
might
mean
that
you
need
to
review
it,
or
that
might
mean
that
someone
has
reviewed
it
and
not
approved
it.
A
The
designs
for
the
top
nav
will
be
the
next
one
and
then
I've
been
creating
these
designs
and
then
recording
the
video
and
posting
them
in
various
channels
and
an
issue
to
hopefully
get
as
much
feedback
as
possible
once
I
get
to
a
decent
space.
So
I'll
do
the
top
now,
but
I
also
need
to
consider
the
things
I
mentioned
like
edge
cases.
A
The
people
who
aren't
using
required
approvals
see
how
we
can
make
this
feature
more
functional
for
more
people
and
once
that's
in
a
good
spot,
more
videos,
more
feedback
until
I
can
get
to
it.
A
well-rounded
area
that
I
can
start
actually
doing
solution
validation
on
some
of
these
ideas,
because
the
problem
is
definitely
a
problem
to
be
solved.
We
definitely
know
that's
been
validated
the
solution.
This
is
a
solution
to
the
same
problem
that
attention
requests
was
solving,
and
so
we're
going
to
need
to
do
the
same
kind
of
validation.