►
From YouTube: Code Review Workflow - FY24 1 Year Plan
Description
Kai Armstrong, Sr. Product Manager, Create talks about the vision for Code Review and plans for the next year (FY24).
Code Review Workflow Direction: https://about.gitlab.com/direction/create/code_review_workflow/
- Real-time merge request updates: https://gitlab.com/groups/gitlab-org/-/epics/1812
- Expressive merge request comments: https://gitlab.com/groups/gitlab-org/-/epics/4349
- Code Review Performance: https://gitlab.com/groups/gitlab-org/-/epics/9086
- Restructuring merge requests: https://gitlab.com/groups/gitlab-org/-/epics/5038
- Review Rounds: https://gitlab.com/groups/gitlab-org/-/epics/9577
A
Hi,
my
name
is
Kai
Armstrong
and
I'm.
The
senior
product
manager
of
the
code
review
group
here
at
kitlab
today
I
want
to
take
a
moment
and
talk
about
the
code
review
Direction
and
what
the
next
one-year
plan
looks
like
for
us
and
some
of
the
things
we'll
be
working
on
and
focusing
on
over
that
year.
So
let
me
share
my
screen:
we'll
walk
through
some
of
this.
A
To
begin
with,
here's
the
code
review,
workflow
Direction
page
as
a
reminder,
everything
at
gitlab
is,
is
public,
and
so
you
can
always
see
this
direction
page
and
what
we're
working
on
and
how
we're
thinking
about
things
here.
I'll
provide
a
link
to
this
below
the
video,
but
we'll
walk
through
a
few
things
to
start,
I
want
to
make
it
clear
on
what
gitlab's
vision
for
code
review
is,
and
so
gitlab
thinks
about
code
review
as
a
way
where
changes
can
be
discussed.
A
Developers
can
be
mentored,
knowledge
is
shared,
defects
identified
and
contributions
delivered,
and
so
what
we're
really
talking
about
is
is
code
review,
isn't
just
the
act
of
reviewing
code
or
leaving
feedback.
It's
it's
making
sure
that
there's
a
whole
process
and
culture
around
that
and
providing
the
right
tools
and
features
to
make
that
happen
and
gitlab
code
review
always
happens
in
the
merge
request.
A
And
so
we
want
to
make
sure
that
these
tasks
that
you
have
to
complete
are
efficient
and
easy,
and
so
that
velocity
of
your
code
delivery,
as
well
as
the
code
quality
and
security
increase,
while
allowing
for
future
iterations
to
continue
improving
those
things
as
you
go
along,
and
so
that's
really
the
foundation
for
how
we
think
about
code
review.
And
so
with
that
in
mind.
A
Let's
talk
about
some
of
the
things
that
we'll
be
looking
at
over
the
next
year,
and
so
our
one
year
plan
for
code
review
can
really
be
thought
about
in
three
different
buckets
of
work,
and
so
those
are
feature
enhancements.
So
these
would
be
net
new
things
to
the
merge
request
that
we
would
bring
to
further
further
the
vision
of
the
merge,
request,
performance
and
reliability
improvements,
and
so
these
would
be
things
that
we
would
do
to
improve
responsiveness
or
improve
user
experience
or
really
impact.
A
Just
those
foundational
things
of
the
merge
request
and
then
the
last
one
is
sort
of
ongoing
research
and
design
efforts
of
things
that
we're
exploring
that
we
want
to
bring
to
the
merge
request,
that'll
sort
of
dramatically
shift
the
way
that
we
interact
and
use
the
merge
request
today.
And
so
these
are
different
from
what
we
might
see
as
smaller
features
that
we
could
Implement
in
you
know
several
iterations.
A
These
would
be
redesigns
to
all
of
the
commenting
experience
or
to
hand
off
in
inside
of
a
merge
request,
and
so
that's
sort
of
what
that
last
bucket
results
in.
So
if
we
go
back
to
the
first
one
and
talk
about
feature
enhancements
over
the
next
year,
there's
sort
of
one
big
area
we're
working
on
and
then
another
that
we
want
to.
A
We
want
to
bridge
into,
and
so
the
first
one
is
real-time
merge,
request,
updates,
and
so
we
know
that
when
you're
on
a
merge
request,
one
of
the
most
important
things
to
make
sure
that
you're
looking
at
is
the
latest
information.
And
that
includes
the
latest
information
from
pipelines
from
other
users
and
from
a
whole
host
of
things.
A
And
so
right
now
we're
reworking
some
of
the
back-end
fundamentals
to
make
sure
that
you
can
get
real-time
updates
for
the
status
of
the
merge
button
approvals
as
they
come
in
and
really
make
it
to
that
merge
request
page
responds
the
way
you
expect
it
to
respond
and
is
always
giving
you
the
latest
source
of
information
there.
So
that's
a
big
one
for
us.
There's
a
lot
of
focus
areas.
A
There
I'll
link
the
Epic
that
encompasses
all
the
places
we're
looking
at
right
now,
but
you
should
see
those
changes
roll
out
over
the
next.
You
know
several
milestones
and
work
here.
The
next
one
we
want
to
look
at
is
a
concept
about
expressive,
merge,
request
comments,
and
so
one
of
the
key
things
about
emerge
request
is
it's
important
to
make
sure
that
the
feedback
that's
being
given
is
easy
to
understand
for
users
and
there's
a
few
ways
that
you
can
do
this?
A
lot
of
people
preface
comments.
A
Gitlab,
you
know
uses
the
concept
of
resolvable
threads.
That's
in
product
today,
and
so
like
a
thread,
needs
to
be
resolved
to
do
that,
but
we
don't
really
wait
comments
or
provide
intent,
and
so
that
can
make
it
unclear
in
a
review.
What
do
you
need
to
address?
What
do
you
not
need
to
address,
and
how
do
you
learn
from
that
experience?
How
do
you
make
sure
that
you
know
the
next
time?
You
know
that
these
are
things
that
people
might
look
for,
so
we'll
be
looking
at
a
way
to
further
classify
comments.
A
Allow
you
to
create
sort
of
different
priorities
of
comments,
some
which
may
need
to
be
resolved,
some
which
might
not
need
to
be
resolved
and
so
I'll
link
to
that
effort
down
below.
We
haven't
started
much
into
the
research
phase,
but
but
that's
where
we're
looking
over
the
next
year
to
sort
of
take
the
commenting
experience
to
that
next
level.
A
So
some
of
the
key
metrics
that
we
we
measure
around
performance,
so
we're
already
seeing
things
here
and
we'll
continue
to
sort
of
always
have
a
theme
around
performance
in
terms
of
what
we're
trying
to
do
here.
But
a
lot
of
these
changes
that
we're
looking
at
will
hopefully
enable
you
know
some
of
the
things
that
we
know:
users,
care
about
which
are
larger,
merge
requests,
merge,
requests
with
more
changes
being
more
responsive,
and
so
that's
a
key
focus
of
of
the
outcomes.
A
We
want
to
see
as
a
part
of
really
looking
at
core
performance
here
and
the
last
one
is
to
to
design
efforts.
I
want
to
touch
on
and
the
first
one
we
call
restructuring,
merge
requests.
The
Genesis
of
this
is
really
that
the
merge
request,
page
is
really
information.
Dense
can
be
overwhelming
to
understand
what
you
need
to
do
and
what
you
need
to
address,
and
so
we're
looking
at
options
of
how
we
can
simplify
that
information
on
page
and
what
we
can
do
to
make
it.
A
So
you
know
what
you
need
to
act
on
what
you
need
to
respond
on.
One
of
the
things
that
we're
likely
going
to
do
out
of
this
is
sort
of
change,
commenting
and
centralize
that
experience
for
comments
in
a
merge
requests
right
now
they
can.
They
can
bounce
between
a
couple
different
areas,
and
we
really
want
to
simplify
and
centralize
that
so
that
you
know
who's
commenting
what
thread,
what
version
and
all
of
those
things
contain
in
one
place
and
then
the
last
one
is
a
concept.
A
That's
called
review
rounds
and
this
really
goes
back
to
things
that
we've
done
when
we
did
reviewer
when
we
introduce
reviewers
and
other
things
where
we
really
want
to
make
sure
that
it
is
clear
inside
of
a
merge
request
what
you
need
to
be
doing,
whether
you're
the
author
or
a
reviewer
or
some
other
participant.
You
know
we
want
to
make
it
clear.
Why
are
you
in
this
merge
request?
What
do
you
still
need
to
do
and
how
do
you
resolve
that?
And
how
do
we
notify
you
of
all
those
things?
A
So
you
know
you
might
leave
a
review,
and
now
the
author
needs
to
act.
Well,
how
do
we
make
sure
the
author
knows
that
it's
their
time
to
act,
and
so
those
types
of
things,
and
so
we
really
want
to
refine
and
build
in
that
back
and
forth
flow
into
the
merge
request,
and
so
we've
got
some
research
on
going
there
on
on
options
that
we
could
take
for
that.
So.
A
So
that's
a
little
bit
about
the
one-year
plan
for
code
review
like
I,
said:
I'll
link
the
direction
page
below
this
video
I'll,
also
link
to
these
high
level
epics
that
we're
working
on.
If
you
have
any
feedback
about
these
ideas
or
other
ideas,
feel
free
to
open
a
merge
request
to
the
direction
page
find
any
of
these
epics
and
comment
on
them.
You
can
always
reach
me
inside
of
gitlab.
So
thanks
and
we're
really
excited
about
the
next
year
in
code
review.