►
From YouTube: Create:Code Review Weekly Product + UX Sync
Description
2020-12-15 Code Review Product + UX Sync
A
I
don't
really
have
any
other
questions.
Adam
came
to
to
the
product
meeting
this
morning
and
talked
about
user
testing
again,
so
I
don't
really
have
any
other
questions
yet
I'll
get
signed
up
and
whatever
we
can
figure
out
where
it
fits
in
and
if
we're
going
to
use
it
but
we'll
cross
that
bridge.
I
think
when
we
get
there
for
number
two
and
I'm
gonna
start
with.
A
A
It
is
for
the
most
part
locked
in
so
like
I
went
through
and
we
trimmed
everything
down
with
andre
michelle
yesterday.
So
the
issue
list
is
much
smaller
than
it
was
last
week
in
terms
of
what'll,
make
the
cut
given
capacities
and
other
things,
and
so
one
of
the
things
that
that
did
is
it
reduced
sort
of
what
was
happening
in
this
last
column
outside
of
there's
some
other
things.
A
A
That
was
like
the
issues
that
are
sort
of.
Maybe
more
thought
out
are
like
about
approval
rules
and
finding
that
right,
reviewer.
I
think
what
I
haven't
seen
in
feedback,
and
I'm
assuming
this-
is
because
danger
solves
this
for
us,
and
other
companies
probably
have
as
a
way
to
solve.
This
is
that
people
still
know
how
to
find
a
reviewer
like
we.
We
probably
need
to
go
back
to
that,
but
I
think
immediately
where
the
concern
is.
A
Let's
start
to
think
about
like
how
do
we
show
more
status
in
that
area,
and
I
would
say,
sort
of
the
first
actionable
thing
to
come
out
of.
There
would
be
like
either
showing
that
someone
has
approved
it
and
they're
sort
of
done
and
then
like
the
ability
to
to
request
that
review
or
like
re-review.
A
And
wildly
phil
has
an
open,
mr
for
like
requesting
a
review
already
that
has
like
a
he
hasn't
remarked
for
that
yeah.
He
sent
it
to
me
this
morning
because
we
were
talking
in
slack
and
he's
like.
Oh,
I
put
this,
mr
together
that
like
prototypes
it
and
he
pinged
you
on
it
like
an
hour
ago,
maybe
it
was
like
hey,
you
should
reuse
it.
So.
A
A
B
Yeah,
I
think
the
the
work
with
approvals
was
that
angle,
I
think,
was
mostly
fueled
by
trying
well,
first
of
all,
trying
to
make
the
creative
experience
of
approvals
better
like
it's
something
that
we
already
have
in.
We
didn't
have
reviewers
at
the
time
we
already
had
approval.
So
let's
try
to
make
these
two
things
work
well
together
before
we
invest
more
in
reviewers
and
also
at
the
same
time
since
multiple
approval
rules
is,
and
for
that
matter
I
think
yeah,
any
kind
of
required
approval
rule
is
on
a
paid
tier.
B
And
I
think
both
are
valid.
I
agree
that
I
mean
if
we
look
at
it
the
other
way
approvals
was
there
already
people
have
had
more
than
opportunity
to
raise
problems
with
the
provers
and
then
some
of
them
have
been
raised.
But,
to
be
honest,
I
was
like.
If
we
look
at
the
issue
tracker
and
catherine,
you
can
also
speak
to
that
from
user
research.
B
I
was
expecting
people
to
be
much
more
frustrated
with
the
current
approval
rules
experience
than
they
are
there.
There
are,
of
course,
bugs
and
requests
for
improvements
and
things
like
that,
but
it's
not
like
this
is
broken,
or
I
don't
know
how
to
use
this,
whereas
compared
to
the
angle
that
you
were
describing
of,
how
can
we
ensure
that
people
know
how
to
use
the
new
reviewers
feature
that
could
be
more
pressing
so
yeah?
I
don't.
B
I
don't
have
a
particularly
strong
opinion,
although
also
because
we're
not
heavy
users
of
approval
rules
at
gitlab,
but
we're
re,
I
think,
reviewers,
which
also
talks
to
the
lack
of
polish
or
usefulness
of
approval
rules.
So
that's
interesting
because
we
we
could
be
the
most
powerful
user
approval
rules
that
we're
not,
but
reviewers
will
likely
be
something
that
all
users
of
mrs
will
use
and
we'll
see
even
in
core.
They
have
reviewers
feature,
although
it's
only
one
reviewer
at
the
time,
so
they're
bound
to
use
it
basically
so
yeah.
B
B
B
But
if
you
look
at
the
merge
requests
lists,
it
would
be
also
be
interesting
to
to
flag
which
merge
requests
need
your
attention
right
from
all
of
the
merge
requests
that
I'm
assigned
to.
Maybe
some
of
them
are
stale
or
I'm
just
waiting
for
someone
to
review
them,
but
maybe
one
of
them
has
already
had
replies
and
it'll
be
interesting
to
flag
them.
B
I'm
just
thinking
out
loud
not
concerning
myself
too
much
in
terms
of
what
we're
going
to
do
for
the
first
iteration,
but
I
think
it'll
be
interesting
in
the
epic
just
to
lay
down
some
of
the
questions
and
assumptions
that
we
have
to
so
again.
We
can
have
some
constraints
about
the
problem
that
we're
trying
or
the
problem
space
in
this
case,
yeah
I'll,
stop
there
for
your
your
comments.
A
Yeah,
I
don't
I
I
in
the
epic
I
put
like
we
should
on
the
re-review
like
to
be
able
to
do
an
email.
You
bring
up
like
a
totally
interesting
point
about
like
the
counter,
because
I
sort
of
hadn't
thought
about
how
that
would
work
in
this
case
anymore
and
like
the
list,
because
now
everything
would
sort
of
always
be
in
the
list
and
that
might
not
be
helpful
either.
A
A
A
A
B
B
B
Yeah-
maybe
maybe
yes,
maybe
maybe
not
I'm
not
sure,
and
we're
also
still
collecting
usage
data
from
approval
rules.
That's
also
something
I'm
very
in
hindsight,
I'm
very
sad
that
we
didn't
instrument
that
early
on,
because
it's
a
key
I
mean
there
are
many
things
that
we
can
instrument,
but
I
think
approval
rules.
B
We've
poured
so
much
time
and
effort,
so
money
into
approval
rules,
and
we
don't
know
exactly
how
people
are
using
them
and
how
much,
how
little,
how
customized
or
not
and
and
and
so
we've
we've
been
making
decisions
without
that
data,
so
yeah.
Let's
also
see
and
hope
for
that.
I
would
assume
that
in
the
case
of
reviewers,
we
at
least
what
we've
been
releasing
now,
which
is
very
minimal.
A
A
Be
challenging
and
what
we
won't
have
good
instrumentation
for
is
how
people
use
it
in
the
context
of
like
adding
and
removing
people,
we
won't
be
able
to
understand
flow
based
on
data,
which
is
we
don't
have
good
tools
for
that
and
data
anyways.
To
do
that,
right,
like
we
wouldn't
be
able
to
know
that
like
or
let
me
think
about
it,
it
would
be
probably
very
challenging
to
instrument
in
a
way
that
we
could
say,
like
you
assigned
someone
as
a
reviewer,
they
got
unassigned
as
a
reviewer.
A
B
B
B
B
B
A
B
A
Counter
that
does
like
create,
update,
merge
and
close,
or
something
for
merge
request,
and
those
are
the
only
actions
we
count
as
users,
so
this
will
start
tracking
the
goal
of
like
that
epic
was
to
track.
You
know
the
variety
of
actions
you
can
take,
but
yeah
it
might
be
good
to
yeah.
I
think
it's
sort
of
wait
and
see
where
that
data
gets
us
and
then
what
additional
questions
we
have.
B
B
A
Yeah,
that's
fine,
I
think
I'm
open
to
sort
of
whatever
we
want
to
do.
I
just
wanted
to
get
some
thoughts
down
and
out
that
we
could
start
to
build
on
for
for
sort
of
figuring
out
what
that
looks
like.
So,
if
you
want
to,
if
we
want
to
like
segment
that
into
individual
issues,
for
like
specific
problems
or
whatever
that's
fine
or
if
we
just
want
to
have
one
longer
issue
that
we
chat
and
I
think
that'd
be
fine
too.
B
A
B
A
Yeah
I
just
wanted
to
put
it,
it
was
like
sort
of
an
fyi
and
then,
if
you
had
any
thoughts,
eric
brinkman
looked
at
and
I
can
uncle
find
an
issue,
he
looked
at
github's
roadmap.
These
were
the
became.
It
was
sort
of
like
a
few
things.
These
were
the
two
that
related
to
us,
which
was
auto,
merge
and
version
pr's,
and
those
are
his
comments,
not
mine
like
next
to
those.
A
B
Yeah
the
auto
merge.
I
think
I
think
just
the
terminology
that
you
use
auto
merge
just
that
simplifies
everything
that
we
now
have
for
mwps
and
had
to
merge
stream
when
pipeline
succeeds
and
all
those
things.
I
think
we
go
to
great
lengths
to
explain
how
things
will
be
merged
when
actually
people
just
want
it
to
be
automatically
merged
right
and
they
we
keep
telling
them
it's
when
the
pipeline
succeeds,
is
when
the
pipeline
succeeds,
and
but
in
a
way
they
already
know
that
from
the
first
time
they
used
it.
B
I
wonder
if
for
an
individual
developer,
if
there
are
really
that
concerns
about
this
project
using
merged
strings,
but
that
one
is
not
using
much
strings
and
if
it's
something
that
we
need
to
explicitly
tell
them
every
time
instead
of
just
auto
merge
is
the
feature,
and
there
are
many
ways
that
you
can
do
out
of
merge
in
the
same
way
that
you
have
multiple
merge
methods
right.
You
have
fast
forward,
merge
you
have
the
the
merge
commit.
B
But
coming
back
to
your
point
about
making
that
more
effortful,
sorry
effortless
from
the
y
or
command
line
from
the
command
line
as
you've
seen
it's
it's
already
available
and
from
the
ui,
I
think
it
it's.
It
makes
sense
in
the
same
way
that
you're,
when
you're,
creating
merge
requests.
You
want
to
say
I
want
the
source
branch
to
be
deleted,
or
I
want
this
to
be
squashed
on
merge.
B
Why
can't
you
do
all
of
that
and
just
say
I
also
want
this
to
be
set
to
automatically
merge
once
I
create
it.
So
I
don't
need
to
wait
for
everything
to
be
computed
to
then
click
the
button
or
for
the
pipeline
to
be
created
in
the
first
place.
So
I
think
that's
it's
precious
seconds
that
are
shaved
from
many
many
merge
requests,
probably.
B
B
I'm
I'm
a
bit
torn
between
pursuing
something
like
this.
The
version
prs
where
you
say:
okay,
I've
paused
the
review.
I
have
resumed
and
then
the
reviewers
see
everything
that
has
happened
since
the
pause
and
resume
or
solving
the
catching
up
problem.
With
the
experience
that
we
have
today,
because
I
think
versioning,
merge,
requests
and
setting
specific
milestones
inside
of
the
merge
requests
of
things
that
happen.
B
A
A
A
I
think
the
problem
is
catching
up
like
how
do
you
understand?
What's
going
on
every
time
right
like
that?
I
think
that
is
the
problem
and
one
of
the
ways
that
you
could
solve,
that
is
by
versioning,
mrs,
in
a
way
that,
like
here's,
a
here's,
a
conversation
and
a
change
set,
and
then
here's
the
next
set
of
conversation
and
changes
that,
like
are
the
diff
between
sort
of
those
two
things
versus
collectively
sort
of.
What's
going
on,
I
one
of
my.
A
A
A
It
is
like
a
subset
of
what
you
would
consider
a
version
right.
The
aversion
in
if
you
were
to
expand
that
scope
out,
is
actually
all
of
the
comments
that
happened
on
diffs
during
the
period
that
I
asked
you
to
review
it,
and
all
of
these
things
like
that
is
a
version,
whereas
we've
like
created
micro
versions,
which
is
each
time
you've
pushed
we've
now
like
or
each
commit,
or
whatever
we've
decided.
That
is
we
you.
We
create
this
other
weird,
like
version
on
the
code
that
is
sort
of
a
more
complicated
way.