►
From YouTube: Reviewers Dogfooding Discussion
Description
The Code Review group discusses proposals and next steps for trying to use Reviewers as part of the GitLab code review process. Largely this discussion is based off of the proposal and feedback from https://gitlab.com/gitlab-org/gitlab/-/merge_requests/54400
A
A
What
would
be
preferred
and
all
of
that,
so
here's
the
summary
of
kind
of
what
we
decided
based
on
that
feedback,
we're
thinking
and
andre.
You
can
jump
in
at
any
time
to
interrupt
me,
but
this
is
the
scenario
that
we're
thinking
people
will
adopt
as
an
nbc,
so
number
one
people
who
are
responsible
for
the
mr,
like
the
authors,
which
could
be
multiple
people,
that's
what
the
assignee
field
will
be
used
for
people
who
are
reviewing
or
have
already
given
reviews
that
includes
maintainers.
Those
are
going
to
be
in
the
reviewers
list.
A
Basically,
that
list
will
give
you
context
clues
as
to
what
the
status
of
your
review
is.
The
one
piece
of
feedback
that
kept
coming
up
was
like:
when
do
we
merge?
We
don't
know
that
today,
and
we
still
don't
know
that
so
andre
and
I
have
like
an
faq
on
how
you
can
determine
that
you
need
to
merge,
but
the
big
thing,
one
of
the
main
reasons
for
this
call
is
that
we'll
have
to
distinguish
between
the
mrs
that
have
been
reviewed
or
unreviewed.
A
B
B
The
one
thing
that
we
heard
as
well
is
that,
right
now
for
you
to
be
able
to
mark
your
review
as
complete
you're
we're
leveraging
the
merge
request,
feature
sorry,
the
merge
request
review
feature,
but
if
you
don't
have
any
comments
to
add
as
a
comm
as
on
the
code
you're
just
going
to
leave
a
regular
comment,
looks
good
to
me
improving
or
something
you
won't
use.
The
merge
request
review
feature,
so
you
won't
be
able
to
mark
it
as
done
unless
you
approve
that's
another
potential
way
of
marking,
reviews
complete,
which
is
approving.
B
B
The
approve
does
not
toggle
the
review
statuses
as
completed
it's
just
the
much
request
review.
That's
doing
that
at
this
point,
but
yes,
they
should.
However,
you
can
still
pay
rebase
or
something
I
can
still
ask
something
or
the
tests
are
not
passing,
and
it's
not
actually
something
on
the
code
right
now,
you
have
to
leave
a
comment
on
the
code
to
mark
the
feature
the
review
has
completed,
which
seems
a
bit
incomplete.
B
A
C
C
C
Tie
ourselves
to
that
flow,
I
think
one
of
the
things
that
we
were
concerned
about
or
that
I
was
concerned
about
when
we
introduced
the
re-request
review
feature
in
general,
was
that
it
was
tied
to
batch
comments
tying
the
whether
or
not
I
have
done
anything
on
the
mr
to
batch
comments
is
like
furthering
us
down
this
like
goal
that
I
don't
know
that
that
is
the
path
we
want.
That's,
I
don't
know
that
that's
the
workflow.
We
want
to
force
everything
into
all
the
time
like.
C
D
D
Yeah,
I
agree
with
sky.
We
need
something
that
is
a
first
class
thing
on
its
own
and
that
doesn't
rely
on
the
batch
comments
and
maybe
in
the
future
they
come
together
somehow
and
we
make
the
relationship
much
more
automatic,
but
we,
this
is
such
an
important
part
of
the
flow
and
clearly
people
want
to
have
control
in
their
own
different
ways
that
making
things
just
automatic
and
invisible
yeah.
I
don't
think
it's.
It
works
very
well
and
yeah.
That's
what
I
want
to
say.
B
Yeah,
just
that,
noting
that
that,
mr,
what
it
really
introduced
is
the
the
state
of
review,
I
think
that's
the
crucial
part
of
it.
The
fact
that
it's
tied
to
batch
comments-
it
doesn't
have
to
be
just
the
batch
comments,
the
I
think
the
novelty
there
was.
We
now
have
a
state
on
the
review
and,
moreover,
one
of
the
feedback
that
we
got
from
people
is
that
they
want
to
still
be
able
to
go
quickly
to
the
merge
request.
B
They
are
currently
reviewing
in
the
process
of
reviewing
or
attached
as
a
reviewer,
so
the
removing
of
the
reviewers
as
they
did.
The
assignees
doesn't
cover
that
need
from
some
people
to
be
able
to
cover
that,
so
the
the
the
direction
of
using
the
reviewers
the
review
state
definitely
makes
sense
to
them
as
well.
B
So
I
I
feel
like
it's
an
additional
thing.
We
we
can
support
the
review
state
in
more
places,
the
filter,
which
is
the
proposal,
but
I
know
that
there's
some
things
that
be
ironed
out
there.
I
don't
think
we're
there.
Yet
we
can
use
a
filter
to
work
on
the
review
state,
but
also
we
can
add
more
ways
to
interact
with
that
state,
whether
it's
a
manual
toggle
for
the
user,
like
if
I'm
a
reviewer
I
must
set.
B
C
C
It's
like
hey,
as
you
add,
and
remove
people
to
assignees,
to
tell
them
that
they
need
to
go
review
it
instead
of
adding
them
to
that
field
and
remove
them
to
the
reviewers
field,
and
that
was
sort
of
like
the
extent
of
the
proposal
which
got
people
using
reviewers
in
a
way
that,
like
maybe
some
people
would
see
re-request,
maybe
some
people
would
see
approved
as
we
added
those
right
like.
Maybe
people
would
like
understand
these
other
pieces.
We'd
get
more
testing
on
the
filters.
We'd
know
like
what
are
the
other
combinations.
C
Instead,
it
feels
like
we
want
to
have
like
the
fully
baked
hundred
percent
done
solution,
which
is
like
not
the
like
sort
of
iterative
step
to
get
there,
and
I
guess
that's
sort
of
what
concerns
me
right
now.
Is
that
like
it
feels
like
we're
like?
Well,
we
need
one
more
feature.
One
more
feature,
one
more
feature
which
was
the
same
thing
that
happened
to
even
get
reviewers
shipped
out.
The
door
was,
it
was
always
like
one
more
feature,
one
more
feature,
one
more
feature,
and
now
we're
still
saying
we
need
one
more
feature.
C
One
more
feature,
one
more
feature
to
get
people
to
even
use
it,
and
so
that
that's
probably
where
I'm
I'm
most
concerned
right
now,
because
I
think
we're
trying
to
be
be
more
than
the
feature
is
today
and-
and
we
should
just
be
really
honest
with
what
it
is
today
it's
today.
It
is
a
very
simple
replacement
for
assignees
that
sort
of
gives
you
an
explicit
role,
but
it's
very
much
an
assignee
field.
D
So
yeah,
so
I
think
I
have
maybe
it's
a
dumb
question,
but
why
I
mean
the
vision
is,
of
course,
for
people
to
stay
as
reviewers
and
up
until
reviewers
they
were
added
and
removed.
When
the
ball
was
on
someone's
court,
why
don't
we
until
we
figure
out
a
better
way
to
handle
exactly
who,
where
the
ball
is,
why
don't
people
just
add
and
remove
themselves
from
the
reviewers
field?.
A
C
B
And
also
it
loses
the
ability
to
see
who's
currently
reviewing
it,
because
now
you
have
a
blend
of
assignees.
Sorry,
no,
you
don't
have
the
plan.
Do
you
have
a
blend?
If
you
use
the
same
field,
never
mind,
you
lose
the
ability
to
see
the
status
of
the
other
reviews,
because
now
you've
reviewed
the
the
ux
has
reviewed
but
has
removed
themselves
from
reviewers.
B
B
D
I
mean
you
have
the
now
the
split
and
you
can
see
like
if
you
have,
if
you're
a
reviewer
of
some
merge,
requests
and
you're
an
author,
an
assignee
of
another,
you
have
that
distinction
and
you
can
filter
down.
For
example,
one
of
the
things
that
we
do
today
in
our
code
review
practice
is
prioritize.
Merge,
request,
reviews
over
your
own
merge
requests.
D
So
that's
an
easy
way
for
you
to
see
hey.
These
are
the
merge
requests
I
need
to
review,
whereas
before
you
were
a
nice
assignee
of
everything,
your
own
and
your
other
as
much
request-
and
you
didn't
know
what
you
should
prioritize.
So
if
anything
that
helps
with
that
triage,
it
doesn't
help
with
much
more
because,
as
kai
said,
we
haven't
had
time
to
flush
everything
out,
but
I
think
the
re-request
review
button
is
an
interesting
feature.
D
D
A
I
understand
the
mr
handoff
kind
of
conversation,
pretty
much
everything
that
you
just
said
kai,
but
I'm
not
sure
that
that's
really
like
nbc.
I
think
if
we
just
show
a
way
for
them
to
even
if
it's
got
the
gaps
andre,
if
we
just
show
a
way
for
them
to
kind
of
say
like
this
is
what
I
still
need
to
review
versus.
This
is
what
I
have
reviewed
in
whatever
form
that
takes,
and
it
can
be
a
very
simple
form.
I
think
that
that
will
just
satisfy
it.
A
I
don't
think
we
have
to
go
into
like
you
know.
Only
only
batch
comments
work,
because
I
think
those
are
all
things
that
we
can
still
work
with,
but
the
pushback
on
the
original
proposal
replacing
assignees
was
like
you
can
see
the
number
one
feedback
theme
was.
We
should
keep
the
current
process
like
that's.
What
kept
coming
up
was,
they
would
say
we
should
keep
the
current
process
or
they
should
say.
If
we're
going
to
update
it,
then
we
should
update
it
to
say
not
to
use.
A
C
I
don't
know
I
mean
I,
I
don't
want
to
be
in
the
one
more
one
more
feature
game
to
to
turn
to
like
get
people
using
this
like
I'm,
not
I'm
not
interested
in
that,
and
I
I'd
honestly
say
that,
like
this
isn't
like
this
feels
like
take
my
ball
and
go
home
kind
of
but
like
if
our
team
doesn't
want
it
like.
If
gitlab
has
an
org
doesn't
want
to
use
it.
C
C
I
guess
like
our
customers
and
the
problems
there,
and
I
say
that
because,
like
our
engineers
have
have
a
lot
of
power
here
and
like,
I
think,
that's
fine,
but
that
makes
it
very
hard
for
us
to
like
live
this,
this
dog,
fooding
and
iteration
value,
and
so
like
I'm,
I
don't
want
to.
I
don't
want
to
take
another
fight
on
this,
like
cody's,
had
to
take
a
lot
of
fights
on
this
and
I'm
I
I
sort
of
don't
want
to
take
this
one.
C
Like
saying
that,
like
this
doesn't
solve,
anything
is
is
sort
of
apparent
because,
because
of
our
incredible
investment
in
reviewer
roulette-
and
I
would
say
that,
like
is
also
immensely
frustrating-
I
imagine
if
we
took
reviewer
roulette
away
as
part
of
this,
which
would
be
like
the
ultimate
way.
I'd
love
to
do
this
and
make
make
our
engineers
feel
what
our
customers
feel
on
a
daily
basis.
C
B
My
question
was:
don't
you
think
that
this
spells
feedback
or
just
anticipates
feedback
that
we're
going
to
get
from
customers
because
they're
probably
struggling
with
the
same
things,
except
they
don't
have
the
review
roulette
yeah,
but
they're
still
being
fed
these
feature
of
reviewers
that
they're,
probably
struggling
with
as
well.
Just
like
us.
C
I
agree,
and
I
think
what
I
have
seen
in
the
handful
of
customers
that
have
are
on
versions
that
support
reviewers
is
they
are
using
reviewers
sort
of
very
similar
to
how
we
use
assignees
I've.
Seen
mrs
of
several
customers
over
the
last
week
and
a
half
that
that
have
people
in
the
reviewer's
field
and
have
someone
in
the
assignees
field.
C
And
that
is
their
process
for
signaling,
because
they
they
very
logically
adapt
it,
and
I
think
this
is
sort
of
what's
frustrating.
They
very
logically
said
this
person
is
a
reviewer.
I
will
make
them
their
reviewer
and
then
they
all
like,
I
think
that
word
is,
is
very
easy.
To
understand,
tells
you
what
that
person
is
doing.
B
C
C
Person's
role
was
in
the
merge
request,
so
we
have
a
value
increase
right
and
it
is
the
smallest
possible
change.
We
could
get
you
to
make
that
value
change.
That
value
increase
was
change
your
process
instead
of
putting
a
reviewer
in
as
an
assignee
put
them
as
a
reviewer.
You
want
to
add
and
remove
all
day,
long
and
remove
all
day
long.
I
don't
care
but
like
that,
should
be
very,
very
simple
to
do,
and
so
much
pushback
on.
That
is
just
not
to
me.
It
is
not
worth.
B
B
B
Right
as
the
assignees-
and
it
won't
give
me
right
the
measurements
I
reviewed,
the
one
thing
that
we
also
saw
is
that
the
commented
column
that
we
have
on
the
approval
rules
widget,
it's
really
invisible.
Nobody
knows
about
it,
and
so
the
thing
about
those
of
us
like
hey,
if
you
want
to
know
who
already
commented
on,
go
and
check
the
commented
column
on
the
approval
rules,
nobody
knows
about
it,
so
it's
really
not
a
solution
for
this
missing
information,
but
I
I
get
your
point
I
I
I
see
what
you're
standing.
D
Yeah,
I
think
the
I'm
with
kaya
that
I
agree
that
it's
shipping,
minimal
value
and
the
value
is
there,
even
if
it's
very
slim-
and
I
mean,
if
there's
a
so
much
push
back
and
most
don't
want
to
use
it-
I
mean
it's
okay,
if
we
don't
use
it
for
a
couple
of
milestones,
because
to
be
honest,
I
think
at
least
to
me
we
already
learned
exactly
what
we
need
to
focus
on
or
not
so
dog
fooding.
It
more
could
just
be
perpetuating
some
people's
frustration.
D
So
I'm
also
okay
with
dropping
that
and-
and
I
think
the
focus
here
is-
should
definitely
be
on
making
this
a
distinction
between
what
I've
reviewed
and
what
is
waiting
on
me
to
review,
and
that's
why.
I
think
that
we
need
a
first
last
way
to
do
it.
But
I
just
haven't
had
the
time
to
to
focus
on
it,
and
I
haven't
reviewed
phil's,
mr
yet,
but
it
yeah
I'm.
D
A
So
these
are
really
good
points
and
putting
phrasing
them
in
that
way
reminds
me
of
like
how
many
very
large
customers,
source
code
and
code
review
have
who
refuse
to
adopt
our
features
until
they
meet
a
certain
criteria
and
they're
not
saying
our
features
are
not
good
code
owners
is
a
great
example.
Sectional
code
owners
is
a
great
example.
Approval
rules
are
a
great
example.
Some
of
the
compliance
stuff
was
a
great
example.
I
have
a
lot
of
examples.
A
They're
not
saying
those
features,
aren't
good
they're,
simply
saying
you
know
I
like
where
you're
headed,
but
that
doesn't
mean
what
we
have
to
do
today,
and
so,
if
you
just
do
these
two
features,
and
so
I
think
what
I'm
hearing
and
andre
sanity
check
me
is:
let's
try
to
go
with
this
scenario.
Maybe
we
explain
it
better
and
we
have
more
information
with
it.
This
scenario
that
really
david
started
out
already
and
if
it's
rejected
it's
rejected,
and
we
understand-
and
maybe
the
only
question
that
we'll
need
to
answer
then,
is
like
well.
A
B
B
We
will
continue
to
pursue
improvements
over
the
next
couple
of
like
I
want,
without
promises,
of
course,
we'll
we'll
continue
to
pursue
the
maturity,
making
the
future
more
mature,
but
right
now
at
the
current
state.
This
is
the
the
process
that
we
propose
for
for
efficiency.
Basically,
because
that's
what
we're
talking
about
here
is
making
sure
that
everybody's
followed
follows
the
same
process,
has
the
required
information
to
make
them
efficient,
reviewers,
and
if
that
is
removing
yourself
from
reviewer,
when
you're
done,
then
that's
it.
B
We
propose
that
we
should
also
have
a
clear
direction,
whether
whether
they
should
leverage
the
request
to
review
or
not,
because
if
you're
left
as
a
reviewer,
that's
not
the
expectation
of
everyone.
Now
if
we
propose
this
process,
so
we
need
to
word
it
in
a
way
that
req
this
is
the
process
recommend
right
now
with
the
current
state
of
the
future,
we'll
let
you
know
soon.
If
this
changes.
C
C
I
think
that's
a
perfectly
acceptable
answer.
I
don't
and
I
think,
like
you're
gonna
run
into
the
same
thing
over
and
over
again,
and
I
I
appreciate
that
everyone's.
Like
oh
look
at
this
other
thing,
I
needed
to
do.
Look
at
this
other
thing
I
needed
to
do
like
into
pedro's
point.
We
got
the
like
sort
of
some
of
the
feedback
we
wanted
about,
like
what
we
need
to
go
do
and
we
sort
of
knew
we
needed
to
go.
Do
those
things
we
thought
we
could
get
an
interim
step
in
there.
A
I
think
we
probably
still
should
just
because
we
do
want
to
give
some
sort
of
like
closure
and
update
to
this
reviewer's
feature
like
one
of
the
questions
david
asked
me
was
since
this.
Mr
has
closed.
Should
I
open
up
a
new
one
that
recommends
not
using
it,
and
I
said
no
we're
not
doing
anything.
We
need
to
just
close
the
loop
on
this
and
just
kind
of
say
like
even
if
it's
not
even
a
required
process,
just
kind
of
say
this
is
what
we
recommend.
A
If
you
don't
want
to
use
it,
that's
okay,
we're
still
continuing.
We
know
the
downsides
here
they
are.
You
know
we
have
a
vision
here.
It
is
and-
and
that's
that
so
I
do
think
it's
still
worth
doing-
that
to
kind
of
close
the
loop,
but
whether
it's,
whether
we
push
forward
for
the
next
two
to
three
weeks
to
get
it
adopted,
that
that's
the
difference.
B
Yeah,
I
I
can't
stop
to
feel
that
there's
a
bit
of
a
wasted
potential
here
that
we're
very
close
to
delivering
a
far
better
workflow
and
we're
stopping
like
three
steps
from
it.
Whether
and
I'm
not
I'm
not
saying
that
this
is
the
shape
that
we're
the
handoff
is
a
crucial
part
of
code
review
and
we
are
that's
why
we're
exploring
it
carefully
and
and
deeply,
but
it
feels
like
the
harder
part
is
done.
The
the
split
of
the
entity
of
reviewer
and
assignees
is
the
hardest
part.
B
B
B
It
feels
like
we're
we're
stopping
short
at
the
very
final
solution,
but
I
agree
with
your
part
about
not
wanting
to
marry
to
one
solution
that
we're
not
sure
it's
the
right
solution.
I
totally
understand
that
too.
So
I
I
fully.
I
just
wanted
to
clear
that
out,
but
I
also
support
the
decision
of
making
the
process
the
one
that
is
supported
by
the
feature
today
so
I'll.
I
think
I
think
we're
all
aligned
there
presenting
that
to
the
team.
C
A
Steps
andre
and
I
can
regroup
and
kind
of
re-uh
solidify
what
what
the
next
steps
are.
The
next
steps
is
andre
and
I
will
figure
out
next
steps
and
we
so
appreciate
both
of
your
feedbacks
on
that
totally
different
way
and
then
we'll
probably
just
give
an
update
and
see
if
you
totally
hate
it
and
if
you
don't,
then
we'll
just
continue
on
whatever
our
next
steps
are
yeah.