►
From YouTube: 2021-06-14 Create: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).
B
Oh
yeah,
so
the
second
item
is
coming
from
the
the
first
item,
the
read-only
item.
So
pedro
and
I
were
discussing
a
lot
in
the
pikma
file
and
pedro
realized.
It
was
a
really
great
point
that
we
need
to
rethink
about
this
re-request
review
feature
if
we
are
introducing
to
the
user
of
request
attention
in
the
near
future.
B
B
C
C
C
C
No
sorry,
we
requested
a
re-review
from
you
and
and
yeah.
So
so
it's
the
explicit
implicit
and
what
I
thought
was
that
it
could
be
confusing
to
have
two
buttons
where
one
of
them
is
basically
a
subset
of
the
other
right.
This
clicking
here
is
calling
someone's
attention.
This
one
does
the
same,
but
it's
saying
hey
it.
What
I
would
like
for
you
to
do
is
really
just
review
and
I
think
that
calling
for
reviewers
attention.
A
C
Yeah,
I
I
think
just
keeping
one
of
them
and
instead
of
having
both
the
thing
with
this
button
and
icon,
which
could
also
be
on
this
side
right,
we
could
move
it
around,
but
the
thing
with
this
icon
is
that
it
doesn't
give
you
the
it's
not
clear.
C
If
someone
has
the
ball
or
not
compared
to
this
one
visually,
this
one
is
clearer
of
who
needs
to
take
action
next,
because
you
have
that
filled,
you
have
the
color.
In
addition,
this
one
we
could
do
something
similar.
But
to
me
personally-
and
this
is
just
my
personal
opinion-
it
doesn't
seem
as
strong
as
this
one
with
the
arrow
and
so
yeah.
It
would
be
of
try
to
avoid
the
duplication
and
have
just
one
button
and
one
indicator
to
to
do
it,
but
yeah.
B
No,
I
I
agree
with
pedro's
point
because
I
didn't
think
that
was
like
part
of
this
design
scope,
so
I
didn't
like
remove
the
current
feature.
That's
just
my
only
intention,
and
all
I
heard
from
some
of
the
casual
interview
that
I
heard
from
like
internally
is
I
I
don't
think
they
understand
this
current
feature
of
having
this
circle
look
like
button
on
the
right
side.
A
I
I
would
agree
that
having
two
buttons
is
problematic,
so
I
think
I'm
on
board
that
that
is
problematic.
I
guess
the
I'm
wondering
if
maybe
the
the
arrows,
though,
should
just
not
b
buttons.
If
they
are
just
a
visual
indicator,
then-
and
it's
just
the
circle-
is
the
button
and
sort
of
that
is
the
like
requesting
of
attention
or
requesting
you
to
come
back
and
look
at
it
action
and
then
based
on
it
being
click
right,
you
would
toggle
the
the
filled
or
the
unfilled
sort
of
piece.
A
I
don't
I
and
I'm
like
I'm
not
married
to
like
the
request,
a
re-review
thing
like
I
don't
necessarily
have
an
issue
if
we
get
rid
of
that
terminology
and
change
that
terminology
to
be
requesting
attention,
because
I
think
you
could
easily
update
like
to
do's
and
things
to
just
say,
like
requesting
your
attention
on
this
merge
request.
It's
maybe
a
little
less
clear
that
it's
a
review
and
I
I
wonder
if
we're
getting
away
from
sort
of
that
intent
there,
but
I
think
so.
I
think
the
visual.
A
The
visual
indicator
is
helpful
to
know
that,
like
we're
waiting
on
these
people-
and
I
assume
like
if
I
play
this
out
logically
like
if
my
name
is
up
there
and
it
has
the
gold-
I
guess
it's
gold-
the
filled
in
arrow-
it
looks
gold
on
my
screen.
Maybe
it's
like
a
yellow,
mustardy
color.
A
But
yeah,
if
it's
filled
in
then
like
the
drop
down
like
the
merge
request
icon
at
the
top,
would
show
me
like
all
of
the
merge
requests
where
my
chevron
is
filled
in.
I
guess
it's
sort
of
like
the
intent,
and
I
think
that
to
me
is
like
the
key
and
I'm
sort
of
indifferent
to
the
interaction
of
how
we
get
there.
I
like
the
extra
visual
indicator,
but
I
to
me
it
doesn't
jump
out
as
like
a
button.
C
C
C
And
yeah,
I
think
we
could
explore
making
the
indicator
look
more
like
a
button
in
the
same
way
like
one
example
that
immediately
came
to
mind
is:
is
this
these
buttons
here
that
are
indicators
but
are
also
buttons,
they're,
interactive
right
and
you
can,
if
I
click
on
them,
you'll
notice.
You
have
like
the
blue
halo
effect,
and
it
tells
me
that
I
clicked
on
it
and
if
others
have
clicked
on
it,
we
have
this
indicator
as
well
with
the
few
numbers.
C
And
what
I
what
I
like
about,
what
I
like
about
yeah,
I
I
I'm
just
going
to
repeat
myself:
it's
just
that
I
think,
having
just
one
way
of
doing
it.
I
think
it's
the
right
thing
and
I'm
also
not
married
to
the
wording
of
a
re-request
review
or
even
the
button
itself.
I
think.
C
A
So
yeah
yeah,
I
think
internally,
no
one
uses
it
because
we
sort
of
said
the
policy
was
to
unassign
yourself
after
you've
done
your
review,
so
no
one
internally
has
probably
even
seen
it
or
very
rarely
has
seen
it
so
yeah.
I
think
I
like
the
idea
of
also
incorporating
some
kind
of
attention
set
type
piece
with
this.
I
think
that
makes
sense
the
interaction
piece
I
wouldn't
have
a
problem
if
every
single
person
had
the
circle
next
to
them,
and
you
could
just
do
it
that
way
and
the
icons
were
just
sort
of
visual.
A
At
that
point
like
to
me
that
wouldn't
be
a
huge
issue,
I
think
ultimately,
the
language
piece
of
what
happens
is
going
to
be
the
more
important
thing
because-
and
maybe
that's
where
we
have
to
be
careful-
is
because
I
think,
like
clicking
that
button
and
saying
like
requesting
your
attention.
A
I
think
people
are
going
to
be
like
attention
for
what
like
they're
going
to
need
to
know,
whereas
like
asking
someone
to
review,
is
sort
of
very
explicit
like
it
gives
them
like
a
very
actionable
thing
to
do.
I
guess
so.
I
feel
like
we've
got
to
think
about
that
is
almost
maybe
more
important
to
solve
as
like.
If
we
go
to
sort
of
where
there's
only
one
model
to
click
in,
how
do
we
sort
of
make
sure
that
the
language
used
for
those
is.
A
Clear
to
tell
people
what
your
expectation
of
them
is,
I
think,
if
we
say
request
attention,
I
think
that's
probably
not
the
right
that
feels
like
the
wrong
language
and
and
maybe
amy's
got
some
ideas
and
requesting
a
review
feels
like
okay.
I
know
what
I'm
supposed
to
do
with
this
and
like.
A
If
I
was
the
author
and
I
got
pinged,
you
know,
I
would
expect
that,
like
that
message
comes
back
and
says
something
along
the
lines
of
like
feedback
for
you
to
review
or
something
you
know
some
way
to
like
tell
people
why
they've
gotten
that
notification
versus
just
like
you
need
to
go.
Look
at
this
sort
of
it
needs
that
action.
It's.
C
Ideally,
we
would
have
the
same
yeah.
We
would
have
to
work
on
it,
but
ideally
we
would
have
the
same
terminology
for
reviewers
and
for
assignees,
because
that's
how
we
would
base
like,
for
example,
let's
imagine
that
for
reviewers
we
kept
the
request
review,
but
for
assignees
we
changed
and
the
hover
of
the
button
would
say.
C
Request
follow-up
or
request
attention,
or
I
don't
know
something
different.
I
think
then
the
problem
is
that
we
would
also
probably
have
to
support
different
quick
actions
and
also
the.
C
The
filter
would
be
difficult
to
name
or
we
would
have
two
filters,
and
I
don't
know,
but
I
think
the
the
goal
is
is
interesting.
I'm
just
not
sure
if
it's
feasible.
A
A
Yeah
like,
if
you
think
about
the
way,
mentions
work
in
comments
right
now,
right
like
you,
if
I
put
your
name
in
the
middle
of
like
a
sentence,
it
just
sort
of
says,
like
you
were
mentioned,
on
a
comment,
but
if
I
put
your
name
at
the
start
of
the
sentence,
the
to
do
says,
you
were
directly
addressed
right,
like
the
we
manipulate
the
to
do
a
little
bit
based
on
like
where
your
name
shows
up
and
so
like
if
you're
a
reviewer,
maybe
we
just
like
the
first
language
pass,
is
sort
of
we
default
to
like
request
it
or
re-review
right
and
then
like
it's
waiting
like
that
to
do
says,
like
blah
blah
blah
requested
a
re-review
of
so
and
so
like
whatever
at
merge,
requests
right
and
then
like
that's.
A
What
the
to
do
an
email
says
the
filter
is
still
like,
requires
your
attention
or
waiting
for
you
or
whatever,
like
the
general
concept,
is
called,
and
I
think
the
same
with
like
the
author.
We
could
do
something
along
those
lines
where
it's
like
you
know.
You've
received
feedback
on
this
merge
request
and
like
it
requires
your
attention
or
something
like
you
know,
whatever
we
could
figure
out
how
to
wordsmith
that,
but
it's
the
email
that
to
do
that.
Need
that
language.
A
C
Well,
I
yeah,
I
think
that
makes
sense.
What
I
was
interpreting
in
the
beginning
was
that
what
made
this
not
as
clear
as
you
would
like
it
to
be,
was
the
this
tooltip.
When
you
hover
the
button
saying
request
attention,
I
thought
you
meant
that
you
wouldn't
know
what
this
means,
because
it
didn't
say,
request
attention
to
review
this
or
something
you
know
what
I'm
saying.
I
thought
that
was
the
problem,
not
so
much
the
receiving
end.
It
was
the
the
person
who
is
triggering
the
action.
A
A
Let's
just
call
the
like,
if
we
call
the
feature
man,
that's
such
a
good
name
attention
set
but
like
if
we
call
the
feature
something
like
that,
you
would
talk
about
that
and
you
would
say,
like
you
would
describe
the
icons
as
saying
like
this
means
that
your
attention
has
been
requested
or
that
this
one's
waiting
on
you
to
like
action
it,
but
like
in
the
language
of
the
button
you
would
probably
say
like
down
by
the
reviewers.
It
would
probably
say,
like
I
think
the
first
pass
of
this
is
like
re-request
review.
A
Is
what
that
says,
because
it's
super
clear
and
then,
if
users
think
they
need
like
more
ways
to
signal
that,
like
we
try
and
approach
like
how
do
we
change
the
way
people
describe
or
signal
that?
But
I
think
like
we
want
to
be
very
explicit
that,
like
the
goal
of
this
is
to
re-request
a
review,
I
don't
know
if
that
makes
it
more
muddy
or
more
clear,
but
I
I
think,
like
just
saying
request
attention
to
me,
is
like
if
I
was
an
author
and
I
clicked
somebody
and
said
request
attention
like.
A
Why
did
I
request
their
attention?
Like
then?
I'm
probably
gonna
have
to
go,
leave
a
comment
that
says:
hey.
I
requested
your
attention,
so
you
would
review
this
versus
if
it's
very
clear
to
me
that,
like
I'm
requesting
their
attention
because
I
want
them
to
review
it
sort
of-
and
there
might
be
other
cases
where
you're
requesting
attention
to
like
merge
it,
and
I
think
to
your
comments
earlier,
like
sure
so
I
re-requested
your
review,
but
I
go
leave
a
comment
that
says:
hey
pedro.
A
C
A
Yeah,
I
think
that
works
too,
like
I
think,
that's
a
like
a
very
logical,
like
sort
of
extension,
or
way
to
phrase
that
I
think
it
just
needs
to
like
both
piece
where
all
the
wording
is.
I
think
we
just
want
to
be
like
try
and
be
more
clear
of
like
what's
going
to
happen
like
to
the
user.
We
should
be
very
clear
about
like
if
you
click
this,
this
is
sort
of
like
what
you're
asking
them
to
do
and
then
I
think
the
person
who
receives
it.
A
So
I,
like
the
button
version
that
you
put
up
above
that
sort
of
makes
things
a
little
more
clear
that
that
would
be
a
button
if
you,
if.
C
Yeah,
I
think
it's
very
interesting
how
people.
C
Absorb
certain
icons
and
interpret
them
as
being
actions,
and
they
don't
need
like
the
border
and
the
look
of
a
button.
But
if
it's
something
slightly
uncommon,
perhaps
that
you
people
don't
associate
with
an
action,
they
don't
think
it's
a
button.
I
think
that's
that's
interesting
like,
for
example,
even
this,
this
clipboard
icon.
C
It's
it's
an
object.
It's
not
an
action
right,
it
doesn't,
but
we
we
by
learning
we
already
know.
Oh
maybe
this
is
copied
clipboard,
because
we've
seen
it
over
and
over
again,
but
it's
it's
an
object,
not
communicating
action
motion
or
whatever
yeah.
That
was
an
aside
cool
sanjong,
any
other
thoughts
or
questions.
B
No,
I
think
the
figure
was
really
valuable
and
clear
to
me,
so
I
just
made
a
note
in
our
dock.
Okay,
I
think
we
can
come
up
with
another
example
and
then
run
another
test.
C
Cool
is
how
is
the
the
turnaround
in
the
in
the
validation
in
the
usertesting.com.
C
C
Focusing
on
doing
our
job
yeah,
that's
that's
great
good
news.
Okay,
so,
let's
quickly
jump
to
the
next
point,
so
we're
we're
coming
up
to
the
end
of
the
the
milestone
sanjiang's
last
milestone
with
us
and
and
yeah.
She
she's
been
doing
an
amazing
work,
and
now
we
have
to
follow
through
with
it.
C
I
read
through
all
the
comments
that
our
colleagues
left
in
the
design
feedback
issue
for
consolidating
the
main
information
and
actions
in
merge
requests,
and
I
think
there
are
two
things
that
stood
out
to
me
that
I
personally
already
believed-
and
I
saw
validation
of
that-
that
it's
a
good
idea
for
us
to
move
forward
with
that
and
could
be
two
quick
wins
that
don't
have
a
lot
of
how
should
I
say,
like
ripple
effects
that
could
cause
us
to
doubt
their
validity
and
one
of
them.
C
So
let
me
move
this
to
the
top,
so
the
first
one
is,
I
think
the
consolidation
of
the
actions
at
the
top
is
really
is
great,
and
I
I
kind
of
think
that
we
don't
need
necessarily
to
do
it
sticky
to
have
value
right.
We
can
still
so
I'm
trying
to
find
something
to
share
with
you.
C
C
I
think
there's
value
in
that
in
in
pursuing
that.
Maybe
the
edges
of
the
design
here
and
there
if
necessary,
but
I
think
it's
something
that
everyone
agrees
is
good,
I'm
still
very
much
concerned
about
the
sticky.
So
that's
why
I'm
not
mentioning
it
right
now
and
the
other
thing
is.
C
But
we
all
know
that
I
mean
not
no,
but
we
can
all
easily
assume
that
quick
actions
are
not
very
discoverable
and
yeah
and
then-
and
then
I
have
a
very
long
paragraph
below
about
my
main
concern
with
the
added
height
and
the
sticky
behavior,
and
that
it
would
add
a
lot
of
problems
in
terms
of
the
the
space
available
for
reviewing
and
yeah,
and
I
also
see
that
this
is
very
much
connected
to
other
things
like,
for
example,
we
haven't
solved
this
part
here
with
the
unresolved
threads.
C
We
just
kept
it
here,
but
it
we
all.
We
kind
of
know
that.
Maybe
this
is
not
the
right
location.
We
actually
had
feedback
from
internal
folks
that
have
been
with
gitlab
for
some
time
now
that
they
find
the
connection
between
this
controls
and
the
overview
and
the
changes
that
they
kind
of
don't
understand
because
to
them.
This
should
be
close
to
the
comments
and
close
to
the
list
of
comments
somehow
yeah
and
there
are
other
things
regarding
the
navigation,
and
I
think
all
of
this
is
connected
at
some
point.
C
As
I
mentioned
there,
kai
said
hey:
why
don't
we
remove
all
of
the
tabs
and
yeah?
Maybe
it's
not
a
crazy
idea?
Maybe
it's
something
worth
exploring
and
I
think
we
need
to
look
and
get
some
insights
on
all
of
this
not
necessarily
solve
all
of
them,
but
answer
these
tricky
questions
about
all
of
these
parts
before
we
can
introduce
something
that
we
can
already
anticipate.
We'll
have
some
negative
reactions
because
it's
sticky,
it's
always
there
and
people
already
complain
a
lot
with
the
available
space
for
reviewing.
C
And,
and
also
the
cognitive
is
also,
the
other
thing
is
just
the
cognitive
overload
that
we
already
have
today
with
the
tabs,
these
controls
and
these
controls,
and
these
controls
and
the
the
file
header
and,
in
addition,
we're
adding
all
of
this
at
the
top,
which
is
useful,
but
it's
just
a
lot
to
always
have
visible
yeah.
So
these
these
are
my
thoughts
on
what
I
think
is
in
a
good
place,
and
I
think
we
should
explore
further,
but
in
in
the
last
minute
that
we
have
available.
A
Proposal
would
be
that,
like
in
the
designs
there's
like
basically
the
edit.
What
we
have
currently
is
edit
and
market
draft.
Marcus
draft
is
sort
of
the
buttons
at
the
top
we'd
be
changing
that
out
for
potentially
open
with
approve
and
merge
buttons,
and
the
merge
button
would
always
just
say,
merge
or
are
we
going
to
get
into
like
the
super
complicated
world
of
like
that
button
can
say
500
things
and
then
it's
gonna
take
up
the
whole
width
and
then
everything
will
die
up
at
the
top
right
like
we'll.
A
Just
we'll
need
all
of
the
width
to
deal
with
that.
I
guess
that's
sort
of
like.
I
don't.
I
think,
that's
a
good
iteration,
although
I
was
looking
and
like
I
feel
like
clicking
on
marcus
draft
and
now
that's
going
to
be
buried
in
a
menu
like.
I
almost
feel
like
there's
just
so
many
actions
that
changing
these
out.
Maybe
that
isn't
the
right
call
either,
but
I
don't
I
don't.
A
A
I
think
it's
worth
testing,
I
guess
maybe
that's
the
answer.
It
is
worth
testing
those
as
top
level
buttons
inside
of
the
merge
request
to
see
like
what
people
say
and
like,
depending
on
the
level
of
effort,
maybe
we
can
throw
together.
A
Someone
could
put
a
new
mark
together
relatively
easily.
You
should
ask
be
worth
asking
and
like
feature
flag
it
and
turn
it
on
for,
like
the
get
lab
group
and
just
see
sort
of
what
people
say
as
like
a
way
to
do
that
user
test
versus
maybe
trying
to
send
it
through,
like
user
testing
or
something
it
might
just
be
better
to
do
it
and
toggle
it
on,
and
if
we
get
a
ton
of
feedback
that
it's
not
great
then
like.
We
know
we
sort
of
need
to
spend
more
time
there.
C
Yeah
yeah,
I
think,
yeah
we
would.
I
should
have
prefaced
this
that
it
regardless.
I
think
we
need
some
some
validation,
especially
the
this
part
of
consolidating
the
action,
because
it's
a
very
visible
change
and
we
would
be
changing
the
location
of
buttons
so
yeah.
I
agree
with
that.
B
Yeah,
I
think
that
could
start
to
be
destroying
like
a
moderated
test
and
also,
if
we
implement
it
and
also
just
put
it
behind
the
feature
flag,
just
hold
the
gila
fox,
and
then
we
will
receive
tons
of
feedback,
I
think,
or
if
we
have
more
time.
I
think
we
can
also
have
moderated
tests
within
gitlab
before
we
start
implementing
this,
because
it's
really
big
change,
it
changed
their
ux
flow.
Quite
a
lot.
So
I
think
it's
okay
to
be
more
conservative
at
this.
B
A
Yeah,
I
think,
we'll
need,
if
we're
going
to
go
the
testing
route
then,
like
maybe
we
see,
if
we
can,
I
don't
know.
I
don't
know
what
your
capacity
now
looks
like
for
a
fourteen
1
pedro
that
we'll
lose.
C
Back
to
busy
yeah
I'll
have
to
toggle
the
busy
indicator
for
the
rest
of
my
life,
no
yeah.
I
I
just
wanted
to
run
this
by
you
too,
and
we
can
yeah
I'll
have
to
think
about
how
we're
going
to
accommodate
all
of
this
yeah.
I
just
wanted
to
know
I'm
not
going
to
talk
again
about
the
proven
comment
or
just
comment
in
the
submit
review.
C
A
A
I
say
that
with
my
like
you
know,
big
monitors
and
one
that
turned
vertical
like
it
doesn't
matter
if
I
lose
that,
but
I
say
that
in
that
way,
because
I
think
I
think,
if
we
think
about
like
the
problem
to
solve
the
the
chief
complaint
is
like
those
things
are
lost
in
the
middle
of
the
page,
and
I
have
no
idea
where
they
are
how
to
get
to
them,
and
I
have
to
go
to
this
other
tab
and
I
think,
like
the
sticky
thing,
addresses
that
more
than
just
like
changing
things
at
the
top,
changing
it
at
the
top
helps
a
little
like
at
least
I
could
always
know
I
have
to
scroll
to
the
top
like
it
gives
it
a
fixed
position
on
the
page.
C
A
Yeah,
which
is
which
is
a
step
in
the
right
direction,
and
so
like.
Maybe
we
try
that,
but,
like
I'm
less
concerned
about,
I
think
the
sticky
piece,
because
I
think
that
just
makes
it
there
when
you
want
it
like.
If
you
scroll
to
the
bottom
of
a
very
long,
merge
request
and
then
you've
got
to,
like
you
know,
scroll
all
the
way
back
up,
like
that's
still
more
more
effort
that
you've
got
to
put
in.
B
I
I
agree
with
kylie,
because
when
I
was
working
at
my
previous
job,
I
used
gitlab
as
a
designer
and
my
first
trial.
I
couldn't
find
the
merge
button
at
the
time,
so
I
just
found
I
I
felt
close
a
little
bit,
but
of
course,
after
like
couple
of
times,
I
I
found
it,
but
I
think
it's
important
to
have
a
certain
like
common
center
and
we
got
a
couple
of
feedback
also
in
the
async
design
already
from
the
ux
department.
B
So
I'm
not
against
to
having
the
sticky
header,
but
I
also
agree
with
like
having
a
lot
of
like
height,
would
also
decrease
some
part
of
the
ux
that
especially
the
large
mr,
I
think
because
they
need
to
scroll
a
lot
so
maybe
for
the
next
iteration
would
be.
We
need
to
think
about
the
compare
tab
in
the
change
tabs,
so
it's
just
below
the
changes
like
there's,
comparing
master
and
blah
blah
blah.
I
think
we
can
accommodate
those
things
into
the
sticky
header
if
we
imagine
how
github
handle
does
that.
B
C
Yeah
yeah,
I
think
that's
that's
worth
explaining
if
you
have
a
bit
of
time,
just
to
create
a
visual
if
it's
just
a
napkin
sketch
out
of
that,
but.
C
Yeah
yeah,
I
think
that
could
alleviate
some
of
the
things
at
the
same
time.
Yeah
and
that's
related
again
to
what
I
was
saying
about.
The
threads
controls
is
that
things
start
to
be
to
look
disconnected.
C
So
if
we,
I
think,
that's
not,
I
think,
that's
a
good
idea,
but
at
the
same
time
it
moves
the
controls
that
today
are
just
above
the
diff.
The
compare
and
the
preferences
for
side
by
side
and
so
on.
Those
are
immediately
above
the
diff
and
if
we
would
move
those
above
the
tabs,
when
you
scroll,
they
are
no
longer
close
to
what
they
would
change
right.
They
would
have
the
navigation
so
yeah
pros
and
cons,
but
yeah,
let's,
let's
let's
experiment
and
and
see
I
guess
he
is.
C
Cool,
I
think
I'm
done
from
my
side.
I
don't
know
if
anyone
else
wants
to
talk
about
anything.
No,
I
think
I'm
good.