►
From YouTube: 2022-04-13 Automated Attention Requests
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
Able
thanks
all
right,
so
I
added
some
points
to
the
agenda
based
on
last
yesterday's
meeting
the
ux
sync
for
the
code
review
group
and
today
we're
discussing
the
automated
behavior
of
attention,
requests
and
yeah.
I
added
a
few
things:
caillou
added
others
before
mine.
Do
you
want
to
go
over
those
first?
I
think
I
just
want
to
get
clarity.
B
A
I
think
so
I
think
it's
it's
good.
You
have
good
first
impressions
on
the
feature.
It's
an
interesting
we're
in
an
interesting
position,
because
it's
we're
kind
of
iterating
behind
the
feature
flag
and
the
feature
flag
is
now
off
and
we
got
a
glimpse
into
what
people
were
experiencing.
We
had
a
lot
a
lot
of
good
feedback.
We
also
had
some
very
specific
critical
feedback
and
I
think
you
know,
for
example,
the
icon.
A
I'm
not
I'm
not
super
worried
about
that,
because
there's
the
learnability
effect
there,
and
we
also
noticed
that
when
people
used
it
and
even
when
they
said
like,
I
clicked
it
a
few
times,
but
then
they
realized
what
it
was
actually
doing.
It
doesn't
mean
that
we
should
not
pay
attention
to
that
feedback
and
not
talk
about
it
and
maybe
improve
the
icon
as
we
are
discussing
it
now,
but
I
don't
think
the
icon
is
a
blocker
as
much
as
this,
because
you
know
the
icon.
A
If
we
change
it,
it
will
still
be
there
and
people
will
still
know
what
it
is
for.
An
automated
behavior
is
much
more
obscure,
it's
hidden.
So
if
we
change
it,
it's
not
immediately
clear
for
users,
so
I
think
if
we
have
the
opportunity
to
learn
from
that
quick
feedback
and
iterate
behind
the
feature
flag
and
then
release
it
well
or
improved,
I
think
we
should
take
that
chance.
A
Does
that
answer
your
okay?
I
think
it
does.
A
Yeah
yeah
marcel,
I
don't
know
if
there's
anything
you'd
like
to
add.
C
Nope,
I
think
it
was
super
clear.
I
think
the
separation
of
these
two
concerns
is
definitely
the
right
one.
Yeah.
A
Yeah
and
I
posted
today
something
in
the
icon
discussion
as
well,
just
to
give
some
more
context
that
we
all
we
always
anticipated,
that
the
icon
would
be,
and
even
I
think
the
whole
feature
would
involve
learning
and
that's
why
we
intentionally
put
the
popovers
and
all
of
that,
the
icon
in
solution
validation.
You
know,
16
participants,
gitlab
and
non-git
live
users.
They
didn't
have
any
issues
with
the
icon
that
we
tested,
which
is
not
the
icon
that
was
released
in
the
end,
but
it's
still
the
chevron.
A
But
anyway
you
can
look
at
the
icon
discussion
later
so
yeah,
I'm
not
worried
about
that
right
now.
So,
let's
talk
about
the
automated
behavior
and
I
put
a
proposal
there,
which
is
basically
to
remove
certain
aspects
of
the
attention
requests
and
I
think
it
is
better
for
us
to
you
know,
do
two
things.
So
one
of
them
is
to
learn
more
about
which
and
then
raise
the
confidence
on
which
automated
behaviors,
we
believe
are
the
right
ones
to
have.
A
So
I'm
not
saying
no
to
any
automated
behavior,
but
I
do
think
that
there
is
some
gray
area
for
certain
of
those
automatic
behaviors
that
we
have
today,
which
are
the
ones
that
I
have
there.
Then
we
have
that
one.
I
open
a
merge
request.
I
don't
know
who
added
that
one,
but
I
think.
C
A
Okay,
yeah,
I
think
it's
similar
to
you
know
the
the
one
before
it
right
so
because
today,
when
you
open
a
merge
request,
if
you're
not
assigned
to
your
own
merge
request
or
if
you're,
not
a
reviewer
of
your
own,
merge
request,
you
don't
get
an
attention
request,
so
it's
yeah.
I
think
it's
kind
of
a
a
detail
of
when
you
add
yourself
as
an
assignor
reviewer.
A
You
know
this
is
you
know,
for
example,
when
you
open
a
merge
request,
don't
automatically
add
an
attention
request
for
myself,
basically,
and
and
so
sorry,
just
coming
back
to
what
I
was
saying,
so
I
think
there's
two
things
we
can
do
there.
One
is
learning
and
raising
the
confidence
on
which
behaviors
we
are
able
to
automate,
and
yesterday
kai
we
were
talking
about
it.
The
waxing
and
the
first
thing
that
came
to
mind
was
okay.
We
can,
of
course,
have
feedback
in
the
issues,
but
that
feedback
is
always.
A
A
I
also
mentioned
doing
user
interviews,
which
I
think
is
something
that
this
feature
needs
is
talking
with
users
and
seeing
them
going
through
their
usual
flow,
with
real
merch
requests,
but
other
than
that.
One
other
thing
that
I
thought
about
was
just
tracking
the
events
that
happen
before
and
after
attention
requests
are
made
right.
A
So
if
we
notice
that,
for
example-
and
this
is
just
a
very
rough
example
if
we
notice
that
people
are
requesting
the
attention
of
other
people
and
right
after
that,
the
subsequent
events
or
the
next
two
events-
you
have
them
requesting
their
own
attention
and
we
can
see
a
lot
of
activity
in
that's
in
those
two
events
in
sequence.
A
That
means
that
there's,
maybe
something
for
us
to
investigate
there
and
consider
to
be
an
automated
behavior.
And
this
is
just
an
example.
We
could
see
other
things.
So
I
think
there
are
many
ways
that
we
can
approach
this
to
gain
more
confidence
and
and
yeah.
And
then
the
second
step
which
I
wrote
in
point
seven,
is
to
try
to
make
that
handover
more
visible
and
explicit,
and
that
would
be
to
bake
in
the
handover
piece
and
the
review
feature
and
that
again,
that's
just
a
rough
example.
A
So
that's
yet
another
thing
that
we
can
do
and
in
that
way
it
would
be.
If
we
had
some
automated
behaviors,
it
would
be
more
visible.
So,
for
example,
if,
if
I'm
submitting
a
review,
we
could
automatically
in
this.
So
let
me
share
my
screen,
so
we
can
all
see
what
I'm
talking
about
so
here.
A
If
we
automatically
remove
the
attention
requests
from
the
reviewer
when
they
are
submitting
a
review,
this
would
be
immediately
visible
for
them
that
we're
making
that
decision
for
them
right,
so
we're
making
that
explicit
before
they
submit
the
review
and
today
that
that
is
not
explicit
right.
If
you,
if
you
click,
you
have
to
see
that
your
icon
changes
and
that
you've
lost
the
attention
request.
When
you
request
attention
from
someone
else
or
if
you
add
a
reviewer.
C
I
have
added
two
smaller
points
here.
Why?
I
think
this
is
a
larger
problem
than
it
might
even
need
to
be.
If
we
had
other
points,
the
first
one
is,
we
have
trained
our
users
to
not
trust
the
real-time
information
that
we
show
on
our
merge
request
on
our
issues.
C
The
attention
request
is
the
change
of
the
color
and
that's
in
an
area
that
they
are
not
currently
looking
towards
it's
an
area
where
we
have
trained
users
that
not
all
of
our
actions
actually
perform.
Real-Time
updates-
and
it's
also
not
really
standing
out.
It's
not
a
highlight.
We
don't
like
give
you
an
explosion.
We
don't
give
you
like
some
kind
of
blinking
there's
nothing
that
really
points
the
user
towards.
You
have
performed
action
x.
C
This
is
one
of
the
outcomes
and
I
think
this
is
why
this
automation
behavior
that's
in
general
as
the
behavior
itself,
not
not
100,
clear
us
not
being
clear
enough
about
visualizing
the
feedback
and
visualizing
the
impact
of
that
action
and
users
already
being
not
trusting
of
that
information
that
we
give
in
the
ui.
I
think
these
are
the
two
major
supporting
aspects
why
this
is
a
larger
problem.
A
Yeah,
I
posted
their
possible
mitigation
to
that
of
giving
feedback
other
than
the
visual
feedback,
which
is
something
that
we,
interestingly,
we
already.
A
We
already
predicted
that
when
we
were
designing
the
feature
right,
we
knew
that
just
changing
the
color
of
the
icon.
When
you
click
on
it
or
you
know,
toggling
those
different
icons
filled
or
unfilled.
A
We
knew
that
wasn't
enough,
so
we
added
the
toast
messages,
saying
you've
requested
attention
from
this
person
or
you
removed
the
attention
request
from
that
person,
so
one
possible
mitigation
to
that
is,
if
we
have
certain
automated
behaviors
is
to
let
people
know
like
we
did
this
on
your
behalf.
I
think
that
might
provide
some
reassurance
to
users,
although
I
don't
think
we
should
rely
on
that
as
the
solution.
A
You
know,
I
think
it's
it's
it's
good,
but
it's
not.
I
think
the
best
way
to
communicate
with
users.
C
Yeah,
I
think
it's
the
it's
it's
an
improvement
for
the
automations
that
we
are
confident
about,
but
on
the
ones
where
we
are
not
confident
about
and
where
we
might
even
see
too
many
cases
where
it
leads
to
negative
consequences.
A
Those
specific
ones
that
are
highlighted
above
yes,
we
kind
of
did,
but
I'm
happy
to
go
over
them
one
by
one.
If,
if
you
think
that
might
be
beneficial,
okay,.
B
B
Not
to
question
the
ux
decision
being
made,
I
don't
necessarily
agree
with
it,
but
I
don't
think
my
my
role
is
is
to
question
the
decision
being
made.
So
I
think.
B
So
I
think,
if
that's,
if
that's
the
decision
that
that
ux
wants
to
make,
then
I
think.
B
A
Yeah,
I
think
you
know
part
of
you
is
sad
as
also
I'm
kind
of
sad
that
we,
it
seems
like
we
had
progressed
further
with
the
feature
and
now
we're
reducing
the
what
we
believe
to
be
the
usefulness
of
the
feature,
and
I
think,
above
all,
I
think
we
should
be.
A
What
we
should
be
focused
on
is
how
confident
we
are
in
certain
things
and
continuously
learning
from
yeah
from
what
we
see
users
doing
or
what
we
validate
their
feedback,
and
I
think
we're
learning
from
from
this,
even
though
it
means
that
hey,
maybe
we're
going
to
postpone
this
little
part
and
yeah.
We
might
be
sad
because
of
that,
but
who
knows
if,
in
the
future
we
will
add
those
things
again,
and
I
think
you
should
definitely
share
your
opinion
and
question
everything
that
we
do.
A
I
I
feel
that
I
can
question
what
you
do,
so
I
think
you
should
feel
like
you
can
question
what
I
believe
in
and
and
because
that
will
make
our
work
stronger,
although
in
the
end
there's
there's
only
one
one
dri,
I
guess
so,
but
we
should
be
comfortable
with
it.
B
With
people
being
not
going
on,
leave
and
15,
not
starting
in
four
days,
I
think
we
would
have
different
conversations.
I
think
the
problem
is
is
we're
up
against
a
different
sort
of
timeline
than
anyone
would
like
if
we
want
to
to
make
a
release-
and
I
think
not
making
a
release
to
do
this.
Research
isn't
the
right
decision
right
to
like
go
through
this
and
sort
of
continue
to
iterate
without
turning
things
back
on
is
not
the
right
decision.
B
B
I'll
say
two
things:
it
feels
like
we're.
Gonna
release
with
a
lot
less
than
we
would
have
and
what's
more
interesting
is,
is
the
only
reason
we're
sort
of
in
a
position
to
not
turn
on
the
future
flag
is
because
of
a
production
incident
related
to
the
feature
right,
like
I
think
I
I
would
I
would
it's
a
sign,
I'm
kidding
it
would
be
curious,
like
I
I
mean
I
think
if
it
was
like
hypotheticals
make
plays
out
but
like
if
we
hadn't
turned
the
feature
flag
off.
B
I
think
we
would
not
jump
to
removing
all
of
these
things.
We
might
have
picked
sort
of
the
one
that
got
a
lot
of
pressure,
which
I
think
the
one
that
got
a
lot
of
pressure
or
that
a
lot
of
people
sort
of
were
confused
about
was
like,
when
I
add
myself
as
an
assignee,
when
I
first
create
the
merch
request,
I'm
not
sure
any
of
these
other
ones
were
really
like
questioned
by
people.
B
B
I
don't
know
the
feature
was
on
for
three
and
a
half
days
like
in
three
and
a
half
days.
There
sort
of
wasn't
a
lot
of
question
about
anything.
There
was
only
the
the
biggest
one
was
sort
of
like
I
had
myself
as
a
signing
reviewer,
and
I
think
what
we
would
have
done
had
we
not
had
to
turn
the
feature
off
is
we
would
have
just
been
like.
Well,
let's
get
rid
of
that
one.
There
seems
to
be
like
some
contention.
We
probably
wouldn't
have
gotten
rid
of
the
rest
of
these.
B
That's
actually
going
to
be
significantly,
I
think,
harder
for
us
to
learn
how
people
respond,
because
people
are
not
going
to
like
tell
us
right
like
we.
It's
not
like.
B
We've
had
reviewers
for
a
year
and
a
half,
I
don't
even
know
a
long
time
and
I'm
not
sure,
there's
a
single
issue
about
automating
behavior
behind
that
right,
no
one's
asked
for
it,
and
so
no
one's
going
to
continue
to
ask
for
those
things,
because
that's
not
something
that
people
are
going
to
ask
for
right
and
and
our
ability
to
instrument
and
do
telemetry
on
event-based
things
that
happen
is
pitiful
on
a
good
day.
I
don't
know
like
we
don't
have
a
good
way
to
do
that
either.
Right
so,
like
I
think
that's.
B
I
think
that
is
to
me.
What's
maybe
more
concerning
is
that
feels
like
we're
gutting,
it
sure
we
have
ideas
and
a
plan.
Those
are
much
harder
to
learn
than
like
something
in
the
product
that
rubs
people
the
wrong
way
and
not
that
maybe
rubbing
people.
The
wrong
way
is
the
right
way
to
get
feedback,
but
it
is
at
gitlab.
B
It
is
a
better
sensing
mechanism
than
other
things
we
have
just
because
of
the
way
that
this
works,
and
so
I
think
I
think
we're
not
going
to
get
any
of
the
feedback
around
these
things.
I
think
we're
not
going
to
have
a
good
way
to
instrument
it,
and
so
I
think
we're
like
a
year
from
now
like
it
wouldn't
surprise
me
if
none
of
these
are
back
in
the
product
and
so
that
I
think
that's
like
a
very.
B
I
think
that's
the
challenging
proposition
for
me
to
sit
with.
Is
that
like?
If
that's
what
we
want
to
do,
because
we
think
these
things
are
so
damaging?
That's
fine!
I
don't.
I
don't
necessarily
agree
that
they're
so
damaging,
but
I
think
that's
sort
of
the
spot
that
I'm
in
is
that
I
think
you
and
I
in
a
vacuum.
Let's
just
like
take
everyone.
B
C
B
C
A
Yeah,
okay,
so
let's
just
very
quickly
just
talk
about
two
points,
so
one
is
the
one
you
said.
That
seems
to
be
the
one
that
caused
the
most
frustration
or
confusion
is
when
you're
adding
yourself.
It
would
add
an
attention
request
which
may
or
may
not
be
desirable
and
then
there's
that
other
one
which.
A
In
my
opinion,
yeah,
which
is
the
you
know
when
you
add
someone
as
a
reviewer
or
as
an
assignee
or
when
you
request
someone's
attention
when
so,
basically,
when
you
are
handing
it
over
to
someone
else,
it
would
remove
the
attention
requests
automatically,
and
I
think
that
is
how
it
should
work
right,
because
that's
even
if
you
look
down
at
the
submit
review
like
that
very
rough
mockup
that
has
so
many
controls,
but
there's
the
handover
process
there
and
that's
what
we
want
to
happen.
Is
you
finish
your
review?
A
You're
done
you
hand
over
the
ball
to
someone
else,
and
so
we're
doing
that
automatically
and
in
that
point
of
I
hand
this
over
and
automatically
it
removes
my
attention
requests.
But
I
think
I
think
there
are
two
aspects.
One
is
the
visibility,
which
is.
What
marcel
was
talking
about
is
that
we
don't
have
any
feedback
other
than
the
visual
feedback,
and
also
people
don't
rely
a
lot
and
or
trust.
A
You
know
the
real
timeness
or
lack
of
real-timeness
of
our
product
and
but
then
the
other
perspective
is
that
some
people
are
frustrated
that
it
removes
their
attention
requests
because
they're
not
done
right.
They
could
just
be
adding
someone
as
a
reviewer
but
they're
still
in
the
process
of
doing
their
review.
But-
and
I
think
my
assumption
is-
that
is
a
minority
of
the
cases.
But
I
don't
have
any
way
to
prove
that
now
right.
A
So
yeah,
so
what
what
I
probably
would
do
now
is
remove
the
first
so
the
one
that
is,
when
you
add
yourself
as
an
assignee
or
reviewer.
So
I'm
going
to
bolt
that
one
and
then
for
the
ones
that
I'm
going
to
mark
in
italic.
I
would
probably
right
now.
A
Improve
the
text
of
the
toast
message
so
that
when
you
request
someone's
attention
or
when
you
add
someone
as
an
assignee
or
reviewer,
we
explain
that
immediately
to
you
so
that
you
know
what's
happening
and
that
you
learn
that
behavior.
If
it's
something
that
you
know
usually
conflicts
with,
what
you
do
yeah
I'll,
stop
there,
because
there's
only
one
minute
left.
B
Is
let
me
ask
you,
but
so
I
agree
with
the
real
timeness.
I
also
think,
like
real
time
is
consistently
a
problem,
and
so,
like
that's
sort
of
a,
I
don't
see
a
cop-up.
It
feels
like
a
bit
of
a
cop-out
to
say
like
oh,
because
we
don't
have
real
time.
You
can't
add
other
features
to
gitlab.
Like
I
mean,
there's
a
lot
of
things
that,
because
we
don't
have
them
in
gitlab,
we
do
them
in
different
ways.
So
I
I
think,
like
that's
is:
is
your
stance?
B
Okay?
So
let
me
are
you
saying,
like
the
one
that
you
bolded?
Let's
get
rid
of
that
the
two
that
you
italicized,
let's
add
toast
messages
for
those
and
like,
instead
of
removing
that
behavior,
we
keep
the
behavior,
but
we
add
a
toast
message
which
we
do
for
other
things
like
in
the
merge
requests.
We've
started
like
there's
been
a
few
instances
lately,
where
we've
added
more
toast
messages
to
like
hey.
B
This
thing
happened
is:
are
you
saying
that,
instead
of
removing
it,
we
could
opt
to
add
a
toast
message
and
then
they
approve
the
merge
request
when,
like
I
think
we
leave
right
like
if,
if
we're
going
to
change
this,
it's
like
that
a
viable
path
to
like
changing
it
versus
sort
of
gutting,
the
automation
out
of
it.
A
Putting
it
that
way,
no
I'm
saying
that
this
could
be
a
possible
way
for
us
to
it
could
be
a
good
compromise.
That's
what
I'm
saying!
A
B
Okay,
I
need
to
jump,
would
you
mind
either
updating
the
one
issue
or
creating
a
new
issue
with
what
you
think
is
like
the
proposal
and
then
we
can
back
and
forth
there
if
we
need
to
and
then
yeah
we'll
go
from
there
sure
I'll.
Do
that
awesome
thanks.
Everyone
have
a
good
one
cool.
Thank.