►
From YouTube: 2021-02-16 Code Review UX Sync
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Actually,
let's
perhaps
start
with
point
two
so
I'll
move
that
up
so
the
results
of
the
code
review
problem
survey,
so
I
reached
out
to
eric
johnson
andrei
and
michelle
and
they
shared
it
a
bit
more
broadly.
But
we
didn't
have
a
lot
of
additional
responses.
A
I
mean
it
doubled
or
almost
doubled
compared
to
last
week,
but
even
so
we're
just
at
around
16
percent
of
all
of
engineers
at
gitlab
and
I'm
not
sure
if
we
should
keep
going
because
because
yeah
we've
already
had
this
open
for
two
weeks
and
we
continuously
shared
it
and,
of
course
it's
optional
for
people
to
reply.
But
what
do
you
think.
B
Yeah,
I
would
say,
depending
on
whether
you've
seen
like
you
feel
like
you've
seen
some
patterns
emerge,
I
feel
like
there
are
some
steps
you
could
take
and
patterns
have
emerged.
Then
closing
it
would
be
fine,
but
if
you
feel
still
feel
like
it's
not
conclusive
yet,
then
I
would
continue
to
push
for
it,
but
maybe
that'll
depend
on
what
you
say
in
the
later
points.
A
And
these
are
the
results,
so
I'm
not
entirely
sure
if
this
is
good
enough,
I
mean
there's
a
clear
difference
between
the
bottom
one
in
the
top
one.
A
In
terms
of
the
mean
and
also
what
I've
noticed
here,
is
that
it's
there's
a
group
here
at
the
top,
with
these
three
around
five
and
a
half
six,
and
then
this
one
is
almost
seven
and
then
we
have
like
from
seven
to
nine
there's
a
huge
number
of
of
choices
here
that
are
similarly
ranked,
and
then
this
one
is
completely
off
the
charts
and
is
is,
I
would
say
that
it's
purely
very
poorly
ranked.
B
Right
yeah,
I've
seen
so
with
these
groups.
I
definitely
I
don't
know,
that's
a
that's
a
good
point
that
you're
raising
here
the
top
three
seem
to
be
pretty
clear
and
then
there's
you
know
some
closeness
with
the
middle
as
we
were
kind
of
talking
about
before,
where
there
are
some
that
it's
you
know
important
for
some,
maybe
not
so
important
for
others
and
then
there's
reviewing
commit
messages
which
seems
to
be
kind
of
for
most
people,
not
as
big
of
a
priority,
so
actually
yeah,
it
seems,
seems
pretty
good.
B
A
A
A
Yeah
yeah,
there
are
other
comments
here,
but
I
don't
see
a
specific
pattern
when
I
review
them.
It's
just
a
lot
of
different
things.
A
Some
of
them
are
things
that
we're
already
working
on,
but
are
not
necessarily
like
specific
problems
compared
to
what
we
have
listed
and
and
yeah,
and
then
we,
when
we
added
this
question
about,
what's
the
larger,
mr
for
you,
basically
the
what
people
have
replied
is
that
it's
a
number
of
files
or
lines
that
is
really
big
and
it
makes
it
harder.
A
Although
there
are
some
comments
that
mention
just
being
slow,
the
mr
experience
and
having
to
do
with
the
performance,
essentially
so
yeah.
B
This
is
really
interesting
to
see
to
see
this
coming
from
internal
response
is
super
interesting.
Have
you
do
you
plan
to
discuss
this
with
engineering
leaders
or
anything
like
that,
just
to
get
their
perspective
on
it.
A
No,
I
mean
I
so
yeah.
I
haven't
discussed
this
with
anyone
else
and,
of
course
the
idea
is
to
then
share
the
results
more
broadly,
at
least
so
that
the
people
that
have
replied
know
what
was
the
outcome
of
the
survey
and
we've
had
nine
engineering
managers
reply,
which
is
great,
I
think,
given
the
amount
of
engineering
managers
and
some
vps
and
executives
and
a
few
others
which
I
don't
know
if
they
reply.
Oh
technical
writers
in
support.
B
A
A
A
Well,
yeah,
I
think
for
in
terms
of
so
so
yeah.
The
the
points
I
added
there
was
was
just
also
the
top
three
problems
and
the
bottom
three
that
I
identified,
but
I
think
I'll
share
this
in
the
the
issue
and
see
what
kai
replies
as
well
and
I'll
keep
it
open
just
until
he
replies,
because
I
imagine
that
he's
not
able
to
join,
of
course
because
of
power
outages.
So,
let's
see
what
he
says.
A
Cool,
so
the
next
point
is
about
the
merge,
widget
design
framework,
and
this
was
something
I
started
working
on
after
I
did
a
competitive
analysis
looking
at
how
our
competitors
do.
A
According
to
these
heuristics
usability
heuristics
and
after
that,
I
started
working
on
this,
so
I
have
there
are
a
lot
of
things
here,
but
I
don't
think
we'll
have
time
to
talk
about
all
of
them.
So
let
me
focus
on
what
I
think
are
the
must-haves
and
it's
basically
the
two
areas
that
I
really
want.
Your
feedback
and
I
think,
having
this
more
reactionary
feedback,
where
you
see
something
and
you
react
to
it
in
real
time-
is
better
because
this
is
what
users
will
see
in
the
end.
A
A
B
A
Yeah
yeah
exactly
so
I'll,
just
start
off
with
the
structure.
A
So
today,
what
I'm
thinking
for
the
merge
widget
is
this
kind
of
structure
where,
if
there's
a
problem,
when
merging
or
doing
any
kind
of
action
regarding
these,
these
merge
widgets,
we
place
the
alerts
at
the
top
of
the
widget
and
they
can
be
dismissible
if
we
want
or
not,
and
then
the
the
pattern
here
is
similar
to
what
we
have
today
with
a
status
icon
like
saying:
is
there
something
you
need
to
look
at
or
is
everything?
Okay,
then
we
can
have
a
title
and
other
styles
of
text.
A
So
one
of
them
is
placing,
in
this
gray
background
section
all
of
the
options
that
relate
to
the
act
of
merging,
so
everything
that
you
can
change
and
that
will
affect
the
merge
or
and
even
things
that
will
be
affected,
or
that
will
happen
when
you
click
the
merge
button.
So
it's
basically
where
you
see
options
and
consequences
before
merging,
and
today
we
don't
have
that
properly
defined.
So
if
you
look,
for
example
here,
this
is
a
screenshot
from
our
product
today.
A
The
first
thing
that
we
have
is
the
merge
button,
regardless
of
the
label.
We
have
this
action
and
after
that
we
have
the
options
and
then
even
below
further
below.
We
have
the
ability
to
modify
the
commit
messages
which
again
is
related
to
this
button,
and
then
it
has
some
of
the
consequences
of
things
that
will
happen
when
you
click
this
button
further
down
and
what
I'm
proposing
is
reversing
this
hierarchy,
so
that
the
last
thing
you
see
is
the
button
and
before
that
you
have
all
of
the
configurations
and
all
of
the
consequences.
A
That
would
be
something
like
this,
where
what
we
say,
what?
What
is
the
state
of
the
what
we
can
call
the
mergibility
if
this
something
that
can
be
merged
or
not,
and
then
you
have
all
of
the
options.
First,
deleting
source
branch
squashing
commits
heading
edit
commit
messages.
It
says
exactly
what
is
going
to
happen
when
you
click
the
merge
button
and
also
that
these
issues
will
be
closed
and
then
you
have
the
button
and
for
this
case,
because
it's
not
the
regular
merge
it
would
be.
A
A
So
that's
my
I'll
stop
there
because
I
think
this
is
the
first
point.
What
I'd
like
you
with
feedback
on
is:
how
do
you
feel
about
changing
from
this?
Where
you
have
the
button
the
options
and
then
the
consequences
and
flipping
that
so
it's
the
other
way
around.
A
B
It
flipped
because
for
me
it
made
it
so
that
I
was
you
know,
reviewing
all
the
information
I
needed
to
know
it's
like
a
almost
like
a
checklist
like
okay.
I
know
what's
going
to
happen
next,
then
I
can
check
off
what
needs
to
happen
and
then
the
final
action
is
to
merge.
So
that
made
sense
to
me
in
my
head.
It
was
like
making
sure
that
I've
considered
everything
and
then
finally
move
on
to
merge.
A
A
A
Yeah,
because
we
so
this
is
already
so
when
I'm
designing
this
in
figma,
I
don't
have
the
ability
to.
I
mean
I
can
do
it
manually,
but
I
don't
have
the
selection
of
the
green
buttons
anymore.
We
only
have
what
we
call
confirm
and
danger
buttons,
so
we
have
this
blue
one
the
danger,
and
then
we
have
the
default.
So
these
will
be
the
only
three
button
styles
that
we
have
or
three
main
button
styles
that
we
have
in
git
lab,
but
I
mean
for
it.
A
It
can,
of
course,
change
and
we
can
use
green
if
we
want
in
the
first
iteration.
A
A
A
Awesome,
cool,
okay,
and
so
the
other
thing
is
how
we
display
the
reasons
why
it's
not
possible
to
merge.
So
this
is
an
example
that
we
have
today
in
the
product
when
it
is
required
that
threads
all
threads
are
resolved
before
you
can
merge.
So
today
we
disable
the
merge
button.
We
have
this
text
saying
before
this
can
be
merged.
One
or
more
threads
must
be
resolved.
We
then
have
the
actions
to
jump
through
the
first
and
resolve
thread
or
resolve
authorizing
a
new
issue.
A
So
this
is
the
reason-
and
these
are
the
things
that
you
can
do
to
address
this,
so
that
you
can
merge
right
and
today
we
only
display
one
reason
at
a
time.
So,
even
if
your
merge
request
has
multiple
reasons
that
it
can't
be
merged,
we
only
display
one,
the
first
one
that
comes
through
our
logic
in
the
code
base.
A
So
if
this
merge
request
is,
for
example,
I
don't
know
in
a
draft
state
or
has
is
missing
approvals,
for
example,
we
would
only
display
like
one
or
more
threads
must
be
resolved,
but
once
you
resolve
this,
the
next
one,
the
next
reason
really
appear
and
so
on.
Until
all
of
the
reasons
have
been
addressed
and
all
of
the
blocking
reasons,
so
you
can
merge,
does
that
make
sense?
A
Okay,
okay,
so
again,
today
we
only
display
one
at
a
time
and
we
have
a
couple
of
options.
So
let
me
go
further
down.
I
think
it'll
be
something
like
this.
Okay,
let
me
show
you
this
one,
although
don't
don't
pay
close
attention
to
these
buttons
here
to
their
style,
but
essentially
what
I'm
proposing
here
is
that
there
are
a
couple
of
possibilities
we
can
stick
to
what
we
have
today
and
only
display
one
reason
at
a
time
which
would
be
something
like
this
saying:
merging
is
blocked.
Threads
must
be
resolved.
A
Right,
so
we
would
display
all
of
this
and
one
by
one
we
would
say
like
this.
This
is
blocking
this
is
blocking.
This
is
blocking
blah
blah
blah
with
all
of
the
reasons,
but
I
do
have
some
concerns
here
that
this
might
become
a
bit
too
tall
right
so,
and
we
already
have
a
lot
of
things
happening
in
the
merge
request
switch
and
it's
already
it
can
already
be
very
tall,
but
so
there's
this
my
feedback.
A
What
I
wanted
to
hear
from
you
is
basically
do
you
feel
that
having
just
one
reason
displayed
is
good
enough?
Is
it
helpful
to
have
this
text
here,
saying
that
there
are
other
merch
checks
failing
or
succeeding,
and
also
the
ability
to
view
them
or
not?.
B
Yeah,
this
is
another
good
question
because,
as
you
were
going
through
it,
my
my
mind
was
thinking.
If
that,
whatever
merging
is
blocked
by
that,
I
would
personally
expect
to
see
all
of
them,
not
necessarily
all
at
once.
It's
just
because
if
it
only
has
one
reason-
and
you
didn't
include
any
other
information,
if
I
resolved
that
reason,
but
then
it
was
still
blocked,
I
would
be
like
why.
Why
is
it.
B
That
would
kind
of
confuse
me
at
least
for
a
second
like,
oh,
I
thought
I
resolved
the
one
reason
that
it
was
blocked
right,
but
I
also
understand
the
concern
about
it
becoming
too
tall.
If
there
were
say
I
don't
know
five
reasons
that
it
was
blocked,
but
I
I
think
I'm
leaning
towards
the
one
that
has
merging
is
blocked,
and
then
it
shows
the
reasons
why
it's
blocked
and
then
you
resolve
them
one
at
a
time.
B
A
A
Right
yeah
yeah
now
that
makes
sense,
and
I
think,
from
the
point
of
view
of
being
as
clear
as
possible.
A
This
is
certainly
clearer
than
this
because
you
can,
as
you
said,
you
have
the
the
title
clearly
saying
merging
is
blocked
and
then
you
have
the
reasons
below
and
you
can
have
multiple
reasons
and
even
the
actions
to
address
them
yeah.
The
my
main
concern
is
that
we
can
have
from
my
research.
We
can
have
like
eight
reasons
at
the
same
time.
So
that's
the
worst
case
scenario,
but
it's
possible
to
have
eight
reasons
at
the
same
time.
A
Of
course,
most
will
have
less
than
that,
but
even
if
you
have
four
and
you
have
all
of
the
other
widgets
on
top,
it's
going
to
be
very
tall
and
that's
my
main
concern,
at
least
from
from
the
perspective
of
the
first
iteration
and
taking
into
account
everything
else
that
we
still
have
with
the
other
widgets
and
we're
not
doing
anything
about
them.
It
might
add
a
lot
of
height
and
a
lot
of
information
that
perhaps
it's
not
it's
not.
B
Yeah
see
see,
that's
a
good
point
too.
This
is
a.
B
This
is
a
tricky
one
because
in
my
head,
there's
like
the
first
scenario
where
there's
one
shown:
okay,
I
resolve
the
threads
issue
and
then
another
one
pops
up.
I
resolve
that,
like
would
that
happen
eight
times
in
the
scenario
where
I
have
eight
problems
like
I
resolved
it:
okay,
fine,
it's
gone,
then
another
one
comes
up.
B
Fine!
Let
me
resolve
this
and
then
another
one
comes
up,
and
then
it
just
happens
eight
times
and
I'm
like.
Why
didn't
you
just
tell
me
this
in
the
first
place,
but
at
the
same
time
showing
them
all
these
problems
all
at
once
could
also
be
overwhelming,
but
it
also
could
be
like
I'm
not
going
to
do
this
right
now
and
then
someone
else
comes
to
the
mr
and
they
see
it
and
they're
like
what
is
all
of
this
and
yeah.
B
A
Yeah
from
my
experience,
I
I
think
the
biggest
number
of
checks
of
things
that
I
needed
to
address
before
being
able
to
merge
were
like
approval.
A
No
sorry
so
rebase
approve
resolve
our
threads
and
and
then
I
could
emerge
so
like
three
or
maybe
four
was
the
maximum
number
of
things
that
I
had
to
do
in
a
sequence,
because
this
is
what
happens
today.
What
you
were
describing
of
I
fix
this,
and
then
I
go
back.
Oh
there's
another
thing,
I
fix
that's
what
happens
today,
because
we
only
show
one
reason
at
a
time:
yeah.
B
C
B
A
Yeah
cool
thanks
thanks
for
that.
Let
me
see
so
that's
what
I
had
in
terms
of
must-haves.
I
have
a
few
nice
to
haves
here,
but
I
don't
think
it's
worth
going
through
them.
A
A
Yeah
this
one
is
quick
so
today,
when
we
there's
no
no
other
blockers
to
merge,
we
just
have
this
button
and
yeah.
Here,
I'm
suggesting
we
have
saying
like
ready
to
ship,
you
can
now
merge,
or
maybe
we
can
have.
I
don't
know
something
else,
but
just
a
bit
more
positive,
you
know
because
usually
merge
requests
are
something
that
take
a
long
time
and
getting
to
the
point
where
you
can
merge,
something
is
should
be,
should
feel
good
and
then
the
same
thing
or
a
similar
thing
for
merging.
A
So
when
it's
in
the
process
of
being
merged,
this
is
what
we
have
today.
It's
like
a
spinner
or
saying
this
merge
request
is
in
the
process
of
being
merged
and
yeah.
I
simplified
this
all
of
this
interface
to
just
this.
With
this
copy
merging
drum
roll,
please
you
know
it's,
it
could
be
interesting.
We
could.
We
could
have
random
things
appearing
here
when
people
are
waiting
for
merging.
You
know
drum
roll,
please
or
wait
for
it.
You
know
or
whatever
it
is
yeah.
B
That's
interesting,
I
I
can't
remember
the
last
time
I
I
thought
about
this.
In
terms
of
I
know
we
had
a
discussion
related
to
this
a
long
time
ago,
when
we
were
first
kind
of
coming
up
with
principles
for
pajamas
and
things
like
that.
But
yeah
is
this
common
throughout
git
lab
to
do
these
sort
of
things,
or
are
we
right
now
more
on
the
robotic
side
of
things.
A
A
Clearly,
on
the
more
robotic
side
of
things,
also,
because
we
don't
have
a
lot
of
these
moments
of
people
like
waiting
for
something
or
successful
moments,
it's
difficult
for
us
to
infuse
that
energy
because
usually
like
it
needs
to
be
productive
and,
for
example,
when
you
were.
Let
me
give
you
this
example
like
there's.
There
was
an
error
to
emerging
right,
so
here
I'm
suggesting
we
say
enable
merge,
and
then
we
have
the
specific
error
message
and
then
try
again
if
we
wanted.
A
A
Try
again,
because
that's
what
people
want
me,
and
so
I
think
it's
a
balance
but
we're,
I
think,
leaning
or
always
talking
with
the
same
tone,
and
I
think
we
can
change
that
tone
more
when
these
moments
happen,
when
something
is,
should
be
celebrated
and
and
it's
ready
to
go
or
they've
merged
something
or
it's
in
the
process
of
being
merged.
So.
B
B
A
Yeah
exactly
yeah
yeah.
It
reminds
me
of
when
you
vest
some
stock
options
in
carter.
B
A
A
B
B
It
helped
with
the
waiting,
but
then
I
became
curious
like
how
many
tips
are
coming.
How
long
will
I
wait
yeah,
but
I
I
like
that
idea
with
the
showing
a
celebration
and
making
it
more
human,
especially
on
this
widget,
because,
as
you
said,
it's
really
tall
and
there's
a
lot
going
on.
I
think,
at
least
from
what
I
was
seeing
with
yours.
It
was
helping
me
kind
of
see.
Okay,
what's
the
main
thing
to
take
away
from
here.
A
Yeah
exactly
I
mean
we're
way
over
time,
so
I
I
apologize
for
that,
but
I
I
think
in
terms
of
the
feedback,
that's
the
main
things
that
I
wanted
are
a
few
other
things
there
and
feel
free
to
explore
the
figma
file
on
your
own,
but
that's
at
least
what
I
want.
I
don't
know
if
there's
anything
else,
you
wanted
to
comment
on.
B
I
think
that
was
it
so
far.
I
like
the
direction-
oh
at
least
the
things
you're
considering
to
me
it's
making
it
more
clear,
because
I
know
that
at
least
for
me,
when
I
go
in
and
look
at
the
all
the
different
widgets,
sometimes
I
I
don't
even
know
where
to
start
or
what
it
all
means.
So
I
like
what
you
I
like
what
I'm
seeing
here.
A
Awesome
all
right
thanks,
catherine,
and
I
hope
everything
continues
to
go
well
with
you
this
week.