►
From YouTube: 2022-04-12 Code Review Weekly 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
Let's
get
right
into
it,
thanks
guy,
so
one
I
think.
A
Challenging
part
of
the
feedback
we
receive
of
attention
requests
is
probably
the
most
opaque
unless
you
go
into
the
documentation
to
figure
out
how
attention
requests
are
automatically
added
and
removed,
and
I
think
most
of
you
have
read
that
feedback,
but
anyway
anyway,
I
was
reflecting
on
it
today.
I
was
talking
also
with
marcel
about
it,
and
we
have
a
lot
of
confidence
on
many
things
of
the
future.
A
A
Those
automated
behaviors
might
make
sense
to
us,
but
we
don't
have
concrete
evidence
that
they
that
they
are
the
most
helpful
and-
and
so
I
think
the
feature
itself
can
still
work
and
people
can
still
get
value
out
of
it,
a
lot
of
it
just
without
the
automated
behavior.
For
the
most
part.
That's
let
me
actually
bold,
most
so
postpone
most
of
the
automated
behavior
and
I
believe
that
the
the
ones
that
I
have
high
confidence
is,
you
know
already
auto,
requesting
someone's
attention,
if
you
add
them
as
an
assignee
reviewer.
A
So
someone
else-
and
you
know
that's
the
natural
thing
like
if
we're
adding
them
it's,
we
want
their
attention
and
surely
there
are
edge
cases
where
you're
adding
someone
as
an
assigning
a
reviewer,
but
you
don't
want
their
attention
to
be
requested
and
but
I
wonder,
yeah
just
how
much
of
those
cases
are
are
out
there
and
the
second
one
is
auto,
removing
all
our
attention
requests
when
the
mre
is
merged
or
closed.
B
Yeah
can
yeah
yeah
microphone,
that's
working.
B
I
think
more
than
that
in
there,
and
so
I
think,
like
the
obvious
one
to
me,
is
that
we
remove
your
attention
when
you
comment
or
perform
an
action
right,
because
that,
logically,
if
I
request
attention
from
you
and
then
you
come
and
respond
to
that
feedback
in
theory
like
I
no
longer,
my
attention
is
no
longer
required
and
yours
is
required,
which
is,
I
think,
where
we
get
to
this
piece
of
like
the
confusing,
automated
behavior,
about
not
being
able
to
assign
to
yourself
and
to
other
people.
B
Do
you
want
to
keep
that
one?
I
guess
like
if
we're
gonna
cut
like
what
he's
listed
two,
but
I
think
there's
probably
like
five
or
six
things,
and
so
like
I
I
I
would
like
you
to
be
incredibly
explicit
about
which
behaviors
you
would
want
to
keep.
If
there's
more
than
those.
A
It's
not
that
we
don't
have.
I
mean,
there's
a
reason
why
we
thought
about
them
and
we
included
them,
and
then
we
can
find
cases
for
all
of
them.
A
I'm
just
wondering
if
it
is
not
better
to
scale
back
this
first
iteration
and
learn
from
the
actual
usage
and
see
how
people
use
it
instead
of
immediately
jumping
the
gun
and
having
these
automated
behaviors
and
those
two
that
I
listed
there
are
to
me
the
ones
that
I
feel
are
the
most
obvious
cases
where
you
want
to
add
the
attention
requests
or
that
you
want
to
remove
the
attention
requests,
the
second
one
being
the
fact
that
we
don't
the
list.
A
So
the
counter
at
the
top,
it
only
counts,
open,
merge
requests.
So
it
does
not
count
merged
or
closed.
So
that's
why
it
wouldn't
make
sense
to
remove
the
attention
request.
There.
C
B
B
I
think
learning
is
would
be
a
challenge
right
like,
however,
there's
not
a
good
way
to
track
or
measure
or
no
intent
and
and
anything
in
gitlab,
let
alone
like
review
nuance,
and
so
I
feel
like
we're.
B
Gonna,
be
left
in
a
state,
that's
sort
of
worse
for
a
longer
period
of
time,
without
a
strong
opinion
and
we'll
be
in
the
sort
of
I
think
like
forcing
you
to
remove
your
own
attention
is
very
much
the
same
place
as
forcing
you
to
remove
yourself
as
a
reviewer
that,
like
gitlab,
adopted
as
a
flow
right
like
that
feels
very
similar
in
terms
of
like
pain,.
A
Yeah,
there's
a
yeah
there's
a
it's
not
ideal.
Well,
it's
what
I
would
say
I,
the
hiccups
that
I've
noticed
is
when
you,
when
you
add
yourself
as
a
reviewer
and
assignee,
it
immediately
adds
the
attention
and
I
personally
think
it
makes
a
lot
of
sense
because
you're,
if
you're,
adding
yourself
there's
something
that
you
need
to
do
right,
so
we're
making
that
easy
for
you.
But
at
the
same
time
there
are
valid
cases
where
you
don't
want
to
immediately
adds
the
attention
request.
A
You
know,
for
example,
when
you
create
a
merge
request,
you're
in
the
you're,
creating
the
emerging
quest
you're
in
the
form-
and
you
add
yourself
as
an
assignee,
and
you
also
add
other
people
as
a
as
reviewers
and
then
you
create
the
merge
request.
Would
we
add
your
add
an
attention
request
for
you
or
not,
and
you
could
say:
oh
no.
In
that
case,
we
won't
because
you're
requesting
someone's
attention,
but
how?
A
How
sure
are
we
that
that's
the
right
thing
to
do,
and
that
would
be
another
thing
that
I
mean
we
would
have
to
to
document
as
well
as
an
exception.
A
And
and
yes,
it
wouldn't
be
ideal
and
also
the
removal.
It's
the
other
case
where
I
request
someone
someone's
attention
and
it
immediately
removes
an
attention
from
me.
How
prevalent
is
that?
Do
you
think?
That's
really
the
vast
majority
of
cases?
That's
what
we
want
to
happen
when
you
request
someone's
attention
or
add
someone
as
an
assignee
or
reviewer
you're
done
or
do
you
want
to
keep
doing
things
there
and
I'm
just
not
sure
if
you're
confident
enough
on
that
to
keep
that
behavior
and.
A
We
can
debate
how
many
clicks
that
takes,
but
you
know
in
terms
of
plan,
I
think
you
know
we
have
that
it's
not
easy,
but
we
would
definitely
receive
feedback
from
the
community,
the
issue
tracker
and
we
would
have
to
set
up
some
some
interviews
with
folks
after
we
have
some
time
for
people
to
use
this
for
with
actual
like
real
real
life
cases,
and
we
would
not
only
interview
gitlab
team
members,
but
we
also
interview
customers
that
use
this
frequently
and
I
think
that's
that
would
be
the
most
reasonable
way
for
us
to
approach
this.
A
B
The
like
threshold
is
sort
of
the
phrasing
I
want
to
use,
but
like
how
unconfident
are
you?
I
guess
is
my
question
like
to
me,
and
I
will
say
this:
this
feels
like
a
pretty
tremendous
step
backwards
from
what
was
released
like
two
weeks
ago
to
remove
these
like
little
touches
that
make
the
like
feature
feel
very
complete
and
the
way
you
use
it
and
like
the
experience
that
people
had
was
so
internet.
B
I
also
got
to
know
the
quick
actions
for
attention
requests
which
are
different
from
those
like
attention.
Quest
was
sort
of
like
built
in
to
that
review
flow
process
and
like
taking
all
of
these
things
out
to
me,
feels
like
feels
like
a
step
backwards
and
like
a
very
unopinionated
step
from
us
like
that,
we
don't
know
how
we
want
the
review
flow
to
work
or
how
we
want
it.
How
we
want
you
to
use
it
where
I
think
we've
been
traditionally
making
more.
B
Opinionated
steps
in
code
review
about
how
we
want
features
to
behave
and
what
we
want
review
flows
to
be
and
sort
of
those
things,
and
I
feel
like
this
creates
that
weird
situation
and
I
get
like
we
could
go
interview
teams
who
use
this
we're
likely
to
interview
10
different
teams
have
10
different
opinions
about
whatever
their
workflow
is
and
not
agree
with
any
of
them,
because
our
own
workflow
is
vastly
different
from
those
teams,
and
I
think
that's
where
I'm
trying
to
figure
out
like
how
unconfident
are
you
in
this?
Like
is
this?
B
A
These
things
can
work
well
for
me
and
I
understand
them
and
I'm
biased.
So
you
could
say
I
have
confidence
on
those
things
for
me
and
I
wouldn't
need
evidence,
but
I
think
that
this
may
not
be
necessarily
the
way
that
works
for
most
people.
A
A
Yeah-
and
so
I
think,
yeah,
I'm
I'm
just
basically
going
to
reread
what
I
said
so
I
think
yeah
we
should.
I
understand
that
it
makes
the
feature
less
useful
or
it
looks
like
it
makes
the
feature
less
useful,
but
I
mean
we're
assuming
that
when
people
approve
the
merge
request,
they
immediately
want
their
attention
request
to
be
removed,
which
may
or
may
not
be
the
case
or
even
when
they
add
another
user
which,
which
is
really
the
the
the
one
case
that
we've
or
the
two
cases
that
we've
seen
as
the
most
problematic.
A
Is
you
adding
yourself
as
an
assigning
your
reviewer?
That's
automatically
adding
an
attention
request
and
when
you
add
a
new
user
as
an
assignee
or
reviewer,
that's
also
removing
your
attention
requests
automatically.
Those
are
the
ones
that
we've
seen
and
to
me
as
a
user.
That
would
make
sense.
I
would
not
have
a
problem
with
that,
but
I
guess
we
need
more
information
about
that.
C
What
what
are
the
circumstances
where,
if
you
have
an
attention,
request
to
review
a
merge
request,
you
do
review
it?
Why
would
why
would
you
still
want
your
attention
to
be
requested
on
that?
Is
that
what
you
said.
A
Yes,
that's
the
thing
like
what
is
the
moment
that
we
undoubtedly
can
say:
okay,
I've
done
reviewing
and
to
me
that
is
connected
with
the
second
point
that
I
wrote
there
two
other
pieces
related
to
attention
requests
which
is
baking
the
handover
process
in
the
review
flow
and
right
now
we're
making.
I
think,
we're
making
all
of
these
assumptions
because
we're
not
baking
into
the
review
flow
and
we're.
Assuming
that
I
left
the
comments.
Okay,
I'm
done
reviewing,
you
can
remove
the
attention
request
or
I've
approved.
A
C
I
think
that
this
is
where
I
first
got
a
little
confused
about
attention
requests
like
months
ago.
I
guess
I'm
still
not
sure
why,
like
a
real
review,
experience
like
I
am
requesting
your
review,
so
you
get
that
review
request
and
you
perform
the
review
and
it's
like
an
object
that
you're
it's
got
a
beginning,
a
process
and
then
an
end,
and
then,
when
you're
done,
your
task
is
complete.
C
C
It
feels
a
bit
like
we're
we're
merging
that
review
experience
with
to
do's
in
a
way
and
it's
getting
more
confusing
if
we
remove
some
of
those
automatic
pieces,
because
if,
if
you
do
perform
that
review,
the
attention
request
should
be
gone
theoretically,
because
if
you
are
needed
on
a
different
part
of
it,
then
they
can
ping
you
on
it
and
then
that's
it
to
do.
But
again,
I
feel
like
they
they
kind
of
conflict
with
each
other.
C
B
B
For
sure,
like
this
is
one
of
those
things
that
like,
if
you
set
up
a
merge
request,
you
could
say
these
are
the
people
responsible
for
reviews
and
if
we
get
smarter
about
how
to
like
bring
you
in
and
take
you
out
of
that,
like
as
part
of
this,
then
like
that
is
steps
towards
creating
that
flow.
I
think
those
are
larger
lists
and
even
iteration
on
attention
requests
was
multiple
milestones
worth
of
work
and
sort
of
challenging.
B
So
I
think
I
think
that
gets
there
and
also
sort
of
like,
I
think,
animal's
question
that
maybe
wasn't
addressed
was
sort
of
like
if
you,
if
someone
asks
you
to
do
a
review
and
you
do
the
review
like.
Why
would
we
keep
your
attention?
Like
still
on
the
item
like
I
get
that?
B
Maybe
we
don't
know,
but
I
think
like
we
could
probably
generally
logically
assume
that
like
you're
done
like
you
did
you,
you
responded
or
you
like,
reviewed
the
code
and
went
through
the
submit
review
process
or
you
commented
or
you
did
something,
and
if
that
wasn't
the
case,
I
think,
like
I
think
optimizing,
which
is
what
I
think
you
did
to
begin
with,
and
so
I'm
unusual
for
you
to
backpedal
this
much
pedro.
I
will
say
so
like
like
what
I
like.
B
We
we're
we're
sort
of
like
making
this
huge
leap
backwards
for
a
lot
of
people
in
order
to
let
other
people
like
tell
us
in
the
future
which
might
work
for
them,
but
I
don't
think
we'll
ever
have
a
good
consensus
base
based
on
what
we
know
about
reviews
and
approvals.
Today,
like
we
know
that
no
team
works
the
same
like
we
already
like
sort
of
have
that
as
a
data
point.
So
I'm
not
sure
what
we've
learned
in
the
future.
B
A
I
think
it's
more
reasonable
to
perhaps
attach
a
automated
behavior
to
removing
your
attention
requests.
If
you
submit
a
review,
perhaps
I
would
think
that
would
be
more
reasonable.
As
I
think
that's
what
you
were
saying
and
about
like
I
I
did
the
review.
I
click
submit
review.
I
publish
all
of
those
pending
comments
that
would
automatically
remove
the
attention
requests
from
me.
I
think
that's
more
reasonable,
but
it's
still.
A
It's
still
kind
of
opaque
and
let
me
let
me
you
know,
move
move
some
things
around,
so
I
if
I
could
go
back
in
time,
probably
with
knowing
what
I
know
today.
What
I
would
have
probably
done
is:
okay,
let's
first
do
what
annabelle
was
designing
of
allowing
you
to
approve
when
you
submit
a
review.
A
That
would
be
the
first
thing
then,
after
that
we
would
bake
the
hand
over
process
of
assigning
or
in
this
case,
reassigning
when
you're
submitting
a
review.
So
that
would
help
us,
because
that's
something
that
people
already
do
today,
at
least
in
gitlab
is,
you
know,
add,
remove
reviewers
and
then
the
attention
requests
all
baked
into
that,
and
in
that
way
it
would
all
make
sense,
because
when
you
are
submitting
a
review,
the
handover
process
is
transparent.
A
It's
there
for
you,
you
know,
what's
going
to
happen,
also
the
approval
and
also
the
summary
comment,
and
all
of
that
is
there
in
front
of
you
and
you
know
how
all
of
that
is
going
to
pan
out,
depending
on
what
you're
doing
now,
whereas
just
with
the
attention
requests,
you
know
clicking
the
approve
button
or
adding
someone
else.
That
is
not
immediately
clear
that
that
is
happening
for
you.
Unless
you
pay
a
lot
of
attention
to
what's
happening.
A
And
so
that's
why
that's
why?
I
think
that,
and
again
I
it's
yeah,
that's
that's!
Basically.
I
think
we
should.
You
know,
take
a
step
back
here
and
not
have
as
much
automation.
As
I
said,
it's
not
removing
completely
the
automation.
It's
I
think,
yeah.
The
most
important
piece
is,
you
know
when
you
request
someone
else's
attention,
it
doesn't
remove
your
attention,
but
I
think
that's
at
the
expense
of
figuring
things
out
better
in
the
future.
Instead
of
optimizing
for
something
that
we
don't
know.
B
I
mean
I
said
this
earlier.
I
think
we
have
done
a
better
job
of
having
an
opinion
and-
and
this
feels
like
we're-
we've
decided
at
this
point
at
the
11th
hour
to
not
have
an
opinion,
and
that
feels
out
of
character.
I
think
for
us
as
a
group
and
how
we
thought
about
this,
so
I
think
I've
got
a
like
a
hard
jump.
B
I've
got
to
go
to
a
customer,
prep
call,
but
I
would
like
to
talk
about
this
more
and
you're
short
on
time
so
like
maybe
we
can
find
a
slot
to
do
this
more
this
week.
I
I
did
leave
one
question
like
my
last.
Like
point
d:
are
you
is
your
feedback
here
and
your
thought
here
a
like
blocker
to
turning
the
feature
flag
back
on
and
or
releasing
this,
because
I
think
that
impacts
sort
of
what
today
and
tomorrow
look
like
in
terms
of
doing
that.
B
Given
that
we're
back
in
a
position
to
do
that,
and
so
we
need
to
know,
I
need
to
know
that,
and
I
think
that
gives
me
some
flexibility
and
if
I
schedule
the
removal
work
of
the
automation
too
so
like
we
just
need
to
know.
I
need
to
know
that
piece
and
then
we
can
figure
out
how
to
talk
about
this
more,
and
I
want
to
get
to
your
point
too
as
well.
So
maybe,
let's
find
some
more
time,
but
I
I
need
to
jump
now.
A
B
Let's
do
that
then,
okay,
I
will
end,
but
it's
gonna
stop
the
recording,
but
you
guys
are
welcome
to
keep
discussing
if
you'd,
like
thanks,
everyone.