►
From YouTube: 2022-04-19 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
B
All
right,
first
one
up
on
the
agenda.
I
was
just
curious
for
my
own
knowledge
how
the
mr
restructuring
effort
is
going,
I
feel
disconnected,
but
I
think
that's
fine,
because
that
means
I
don't
have
to
do
anything
which
also
feels
good.
So
I'm
just
curious
how
it's
going
and
if
there's
anything
you
need
help
with.
A
Well,
there's
actually
nothing
to
report
because
the
milestone
just
started
yesterday-
and
I
didn't
do
any
design
for
that
yesterday,
but
so
yesterday
I
spent
most
of
the
time
working
on
the
beautification
just
getting
a
bunch
of
mrs
ready.
But
yes,
alexis
from
plan.
I
don't
know
if
you
know
her.
She
and
I
will
be
working
together
on
these
designs
and
probably
is
going
to
sketch
out
different
features
or
parts
of
the.
A
You
know
the
design
that
came
from
the
workshop
that
we
thought
were
the
most
interesting
or
the
most
viable
and
we're
meeting
weekly
to
go
through
those
and
then,
by
the
end,
it's
hard
to
predict
because
I
don't
know
what
we're
gonna
come
up
with.
Ideally,
it
would
be
like
a
full
merge
request,
page
with
all
of
the
potential
changes
in
there.
A
It
might
just
be
pieces,
it
could
go,
it
could
go
any
number
of
ways
and
then,
at
the
end
of
the
milestone,
we'll
we'll
get
them
into
a
slightly
better
looking
presentation,
but
still
super
low,
fidelity
and
rough,
and
then
we'll
do
some
internal
testing
and
I
reached
out
to
ben
for
help
with
that
and
just
kind
of
make
sure
that
we're
on
the
right
track.
A
So
we
can
just
start
scrapping
things
and
building
on
things
really
quickly
and
then
came
up
with
a
few
ideas
on
how
we
might
test,
because
I
don't
have
much
experience.
Testing
like
these
really
low
fidelity
paper,
prototypes,
basically
and
different
ways
that
we
can
go
about
validating
it
and
I
think
pedro
might
be
back
by
then
so.
We'll
have
more
hands
on
deck.
B
Well,
so
the
just
to
like
make
sure
I'm
clear
so
last
milestone
or
maybe
more
than
last
milestone
was
all
the
like.
Brainstorming
that
I
saw
like
the
canvases
for
was
all
that,
and
so
now
we're
actually
moving
into
lo-fi
designs
to
sort
of
further
flush
out
some
of
those
ideas
or
other
things
that
we've
been
thinking
about
and
validate
those
and
then
so
design.
Only
this
milestone,
validation
next
milestone
and
then
sort
of,
like
repeat
that,
based
on
see
where
that
gets
us
at
the
end
of
feedback,
I
think,
is
probably
okay.
A
Yeah,
I
find
it
really
hard
to
plan
because
I
still
don't
know,
there's
so
many
unknowns.
I
have
no
idea
what
it's
going
to
look
like
at
the
end
of
this,
but
yeah
the
last
milestone
we
were
focusing
on
narrowing
down
to
three.
I
think
we
came
up
with
hypotheses,
so
we're
going
to
design
around
those
hypotheses
and
if,
if
at
the
end
of
the
milestone,
like
nothing
good
comes
out
of
it,
then
which
won't
happen.
A
A
B
Okay,
thanks
thanks
for
the
update,
I
appreciate
it.
I
I
realized
I
hadn't
asked
about
it
until
I
started
pinging,
even
patreon
that
that
issue
last
milestone.
I
guess
I
should
know,
maybe
a
little
bit
more,
what's
going
on.
B
Thank
you
for
the
update
sure
next
one
I'm
I'm
sort
of
pulse
checking
like
how
pedro
and
I
had
talked
about
this
before
he
went
out,
and
so
I'm
sort
of
pulse
checking
you
on
where
you
how
you
feel
or
what
you
think
we
need
to
do
about
the
icon
for
attention
requests
like.
Should
we
should
we
change
it?
Do
we
even
care.
A
A
It
is
it's
it's
hard
to
answer
this
one
too,
so
I
talked
with
marcel
about
this
yesterday
in
our
one-on-one,
and
I
don't
think
he
got
around
to
posting
what
he
was
thinking
or
maybe
he
didn't
want
to
to
influence
it
too
much.
But
yes,
I
think
we
should
change
it
just
because
it
looks
like
a
chevron,
and
I
I
know
it's
not,
and
people
will
learn
that
it's
not,
but
it's
a
little
odd
having
something
that
we
use
all
over
the
app
and
all
over
the
web
to
use
it.
A
A
I
don't
know
just
because
we
can't
come
up
with
something
I
feel
like.
There
is
something
to
come
up
with.
I
just
don't
know
what
that
is
yet
and
then
the
as
for
the
current
proposals.
It
sounded
like
that
the
bell
was
a
somewhat
popular
option
and
there's
a
lightning
bolt
that
that
means
nothing.
That's
just
not
used
yet
and
then,
like
the
the
garrett
style,
I
keep
calling
it
a
chevron,
and
I
don't
I
don't
want
to
but
like
it
is.
A
It's
thicker
though,
and
it
looks
a
little
bit
better,
so
maybe
that's
the
smallest
iteration
just
because
it's
already
used
someone
somewhere
else.
It
might
be
like
a
little
bit
validated
for
us,
because
it's
already
used
the
the
thing
is
users
didn't
seem
to
understand
that
it
was
responsibility
passing
versus
notifying.
A
So
the
bell
might
work
based
on
users
perceived
functionality
of
this
feature
and
in
that
we're
kind
of
generating
a
to-do
for
them
in
a
way
we're
not,
but
it
kind
of
feels
that
way,
so
the
bell
might
make
sense
to
them
if
they,
if
they
perceive
that
future,
to
be
doing
that,
then
the
bell
is
great,
we're
already
using
the
bell
on
the
ui
in
two
different
places.
As
far
as
we
can
see.
So
maybe
that's
maybe
it's
not
good,
but
maybe
it's.
It
is
good,
because
they'll
tie
the
two
together
in
some
way.
A
I
don't
know
yet.
The
the
passing
responsibility
didn't
seem
to
come
across
with
any
of
those
icons
and
I'm
not
sure
that
there
is
an
icon
that
can
display
that
which
I
think
is
fine.
Not
every
icon
needs
to
tell
a
full
story,
but.
A
I'm
still
leaning
towards
the
thicker
chevron.
Just
because
is
there
risk
to
waiting
on
changing
the
icon
in
a
meaningful
way.
You
mean
enabling
the
feature
with
the
existing
icon.
B
The
feedback
we
got
from
people
who
use
the
feature
was
sort
of
like
they
expected
it
to
be
a
drop
down
which,
like
I
too
close
to
the
feature,
can
associate
can't
understand
like
like
that
doesn't
resonate
with
me.
But
I
like
I.
I
could
see
that
if
you
were
sort
of
first
approaching
it
so.
B
It
didn't
really
matter
anymore,
like
sort
of
what
the
icon
was,
and
so
I
wonder
if
we're
like
over
rotating
on
the
icon
and
like
if
we
let
this
ride
for
a
couple
milestones,
we'll
have
a
better
source
of
feedback
or
a
better
understanding
to
like
draw
a
different
icon
conclusion
and
like
if
we
should
just
leave
it
alone
entirely
for
now
or
is
the
like
the
risk
if
we
launch
with
this
icon,
changing
it
in
three
or
four
months
is
like
significantly
harder,
because
we're
gonna
make
people
retrain
on
a
new
icon.
A
A
Yeah,
I
prefer
to
do
it
now
for
a
few
reasons,
so
the
chevron
thing.
That's
why.
I
think
that
the
slightly
thicker
chevron
might
be
a
good
just
fix,
because
it
won't
look
as
chevroni,
it's
already
used
by
feature,
or
it's
already
used
by
a
different
product,
and
it
doesn't
it
sort
of
conveys
what
we're
trying
to
convey
it's
almost
like
an
arrow,
but
not
too
much
and
it
looks
clickable.
I
thought
it
looked
pretty
clickable.
A
It's
hard
because
I
still,
I
still
don't
really
understand
the
feature.
I
understand
what
it
does.
I
still
don't
know
what
problem
it's
solving
that
a
different
type
of
code
review
product
within
our
code
review
stage
would
solve,
and
by
that
I
mean
I'm
broken
record
about
creating
like
a
a
review
experience.
A
C
A
So
in
in
my
mind,
I'm
hoping
that
if
we
ever
do
kind
of
focus
on
the
review
portion,
then
that
will
eventually
kind
of
negate
the
need
for
attention
requests
at
all.
A
So
it's
hard
to
for
me
to
think,
like,
let's
plan
on
a
few
milestones,
updating
the
icon
or
or
something
like
that,
just
because
I
I
feel
still
that
I'm
not.
A
C
I
want
it
back
what
I
do
and
I
can.
I
can
explain
why
why
I
want
it
back
so
badly,
right,
release,
post
items,
one
of
the
things
that
we
have
to
do
as
part
of
getting
one
ready
to
go
for,
say
the
15-0
release.
It's
got
to
be
signed
off
on
by
several
different
people,
usually
pm
em
technical
writer.
Sometimes
even
the
engineer
who
wrote
who
wrote
the
feature,
the
custom
of
taking
out
reviewers
from
after
you've
looked
at
a
a
particular
merge
request
means
any
time
that
I
am
handed
a
release
post
item.
C
C
A
Yeah
and
we
got
that
feedback
too,
from
internal
like
yeah,
the
research
I
was
doing,
people
were
like
okay,
I'm
the
maintainer
who's
reviewed
it.
Let
me
go
through
the
widget,
the
sidebar,
the
comments
and
again
since
I
have
no
designs,
and
I'm
just
blabbering
on
this-
would
solve
that
too,
like
if
you
review
people,
if
you
ask
you
know
three
people
for
a
review,
they
would
remain
in
the
sidebar.
A
There
would
just
be
some
other
kind
of
interaction
that
that
solved
it
without
adding
a
new
feature
called
attention
requests,
it
would
be
yeah,
it
would
be
similar.
We
yeah
the
removing
and
everything
I
don't
think
works
for
anyone
so
yeah.
I
definitely
understand
the
problem.
Okay,
I
suppose
I
just
I
guess
I
don't
it's
not
that
I
don't
understand
the
solution.
I
just
wonder
if
there's
another
way
to
solve
it,
I'm
sure
there
are
I'm
sure
there
are
many
ways
to
solve
it,
and
this
is
one
of
them.
C
B
I
feel
like,
if
we're
going
to
do
this,
we
need
like
if
those
icons
don't
exist,
like
I
don't
know
if
the
big
chevron
exists
in
like
our
svg
library,
if
that's
what
we're
going
to
use-
and
this
is
what
we're
going
to
call
it
the
big
chevron-
I
don't
have
a
better
name
for
it
now,
either
things
you
can't.
B
The
big
arrow
it.
A
Does
not
exist
so
yes,
if
we're
whichever
one
we
choose
for
you
know,
let's
just
pick
one,
whichever
one
we
choose,
I
think
either
pedro
already
has
it
kind
of
it's
in
figma
those
options
that
he
put
they
just
might
need
to
be
kind
of
finessed
a
little
bit
and
that's
where
I
I
get
I'm
useless
at
that.
So
that's
where
jeremy
can
help
and
he's
really
quick
at
it
and
he'll
it's
already
there.
He
can.
He
can
help
that.
I
think.
B
Okay,
then,
can
we,
I
did
see
marcel's
feedback.
He
put
it
in
like
the
design
on
pedro's
design
last
night
or
this
morning,
oh
yeah,
it
was
still
like
he
likes
the
bell.
I
don't
like.
I
don't
like
the
bell.
B
B
In
my
like,
knowing
what
the
feature
is
and
that
it's
like
request
attention,
I
associated
it
with
like.
I
walk
into
a
hotel,
and
I
like
slam
the
bell
at
like
a
concierge
desk
and
like
I
am
asking
someone
to
do
something
for
me,
because
they
are
like
a
servant
of
mine.
In
that
sense,
not
like
a
peer
is
sort
of
like
how
I,
like
I
sort
of
like,
went
through
like
this
mental
piece
in
the
bell,
and
I
think
the
bell.
B
Oversimplifies
and
sort
of
gives
the
wrong
impression
of
the
feature
like
I
think
we
might
give
the
wrong
mental
model
for
people
if
we
associate
it
to
if
we
associate
it
as
a
notification
device
and
not
as
like
a
workflow
like.
I
think
that
the
bell,
like
would
train
you
to
think
that
you're,
giving
a
notification
not
that
you're
doing
anything
else,
and
not
that
the
arrow
is
better
necessarily,
but
the
arrow
doesn't
come
with,
like
loaded,
preconceived
context
about
like
what
you're
doing.
B
If
that
makes
sense,
like
you,
don't
necessarily
like.
If
you
click
a
bell,
you
expect
that
you've
notified
someone
and,
like
your
your,
I
think
your
mental
train
of
thought
stops
there.
If
you
click
the
arrow,
you
will
recognize
based
on
what
the
future
does,
that
you've
notified
someone,
but,
like
you
also
end
up
with
sort
of
this
indicator
and
and
that
might
open
open
minds
and
workflows
a
little
bit
more
than
like
the
limiting
piece
of
the
bill.
A
Yes
and
I
yeah,
I
agree,
and
I
think
that's
exactly
the
point
that
I
I
think
marcel
is
trying
to
make
and
that
yeah
we
prefer
them
to
think
of
it,
the
mental
model
to
be
you
know,
this
is
the
person
who's
responsible
right
now,
the
arrow's
pointing
at
them
like
you
need
to
do
something,
but
the
name
attention
request,
even
like
you
said
that
hotel
thing
we're
calling
it
attention
request
which
says,
give
me
attention.
B
We
originally
called
it
waiting
for
was
the
original
name
when
we
started
like
talking
about
it,
and
it
was
very
hard
to
communicate.
B
That,
like
in
language-
and
I
think,
that's
why
we
like
then
shifted
the
way
we
spoke
about
it
and
started,
calling
it
attention
request.
B
A
B
A
I'm
terrible
at
explaining
this
stuff-
I
guess
one
of
my
worries
about
using
the
bell
too,
is
that
people
will
be
like
okay.
So
this
is
a
notification.
How
does
it
work
with
our
other
notifications
or
to
do?
How
is
this
different,
but
in
my
mind
it
isn't
different
because
you
are
notifying
someone
right
like
I
don't
I
don't
know.
This
is
where
I
I
every
time
I'm
like.
Let's
do
this
and
then
I
step
back
and
think
hang
on
they're,
just
so
many
like.
B
B
Then
it
sort
of
means
like
we
should
probably
that's
why
I'm
curious,
like
the
icon
thing
in
general,
feels
like
a
significant
amount
of
bike
shedding
at
this
point
like,
and
so
I
think
we
should
move
on
from
it
with.
That
being
said,
I
think,
if
we're
going
to
do
the
big,
not
chevron,
pointy
arrow
thing,
maybe
we
just
call
it
the
not
chevron
that
could
be
a
good
icon.
B
Can
we
can?
Can
you
make
that
decision
today?
In
the
issue
and
then
see,
if
jeremy
has
the
capacity
to
get
it
because
we
will
need
to
then
adjust
what's
on,
someone
in
front
ends
plate
to
make
updates
because
there's
a
I'd
love
to
say
it's
just
an
icon
change,
but
it
actually
involves
changing
all
of
the
tooltips
and
all
of
the
docs
once
that
svg
actually
finally
hits
the
svg
library
that
then
gets
updated
in
gitlab.
B
Yeah
and
the
last
one
the
most
complicated
issue
in
the
world,
so
I
just
want
to
make
it
easy,
is
the
the
code
owner
wants
easy.
I
say
I
want
to
make
it
easy,
I'm
going
to
just
explain
where
I
had
been
at
on
this
with
both
of
you,
because
I
think
annabelle
and
I
talked
about
it
and
I
think
we
get
closer
with
these,
and
so
I
think,
maybe
getting
amy
with
these
to
clear
up
the
language
and.
B
I
don't
think
either.
One
of
these
is
correct,
and
so
that's
why
I'm.
C
B
Just
start
it
with
this
gotcha,
I
think
so,
the
intent
of
the
feature
or
the
intent
of
the
way
martin
had
written
it
and
the
way
I
had
understood
it,
especially
in
the
context
of
the
epic,
the
way
approval,
resets
work
now,
and
so
that's
all
that
exists
today
in
the
product
is.
B
Remove
approvals
when
commits
are
added
to
the
source
branch.
So
that's
a
feature
that
exists
today
and
what
that
feature
does.
Is
it
resets
all
approvals
code
owners,
regular
approval
rules,
anything
anytime,
anything
is
changed
on
the
branch
you
rebase,
it
resets
the
approvals.
You
change
a
docs
file,
resets
approvals
for
docs
front,
end
backend,
whatever
your
approval
rules
are,
and
so
the
intent
of
this
issue
and
in
the
context
of
this
is
that
that
setting
makes
it
really
hard
to
actually
use
that
setting,
because
it
creates
these
situations
that
are
very
high.
B
Friction
for
teams
with
large
sets
of
approvals,
it's
even
already
causing
friction
for
gitlab,
because
we've
recently
turned
on
some
new
approvals
and,
like
you,
change
something
and
like
you've
got
to
go,
find
these
specialized
group
of
people
that
can
actually
approve
this
one
section
of
the
code
base,
and
so
we
reworked
some
of
this
I'd
reworked
some
of
this,
because
there
was
another
customer
that
was
interested
in
contributing
specifically
around
like
rebases
and
merging,
which
don't
actually
typically
change
the
content
of
a
merge
request,
but
reset
approvals
for
no
like
good
reason
so
like
if
you're
in
a
fast
forward,
merge
situation,
you
rebase
your
branch
and
you
lose
all
your
approvals.
B
You've
got
to
get
all
your
approvals
again
and
then
you've
got
to
like
rebase
again,
because
you've
now
fallen
behind,
and
then
you
lose
all
like
you're
just
the
circular
thing,
so
they
can't
use
it.
So
that
was
where
we
started.
This
one
was
specific
to
code
owners
and
the
ask
around
code.
Owners
has
been.
B
If
I
have
a
rule
that
says
file
a
is
approved
by
annabelle
and
file
b
is
approved
by
amy
and
both
of
those
are
in
a
merge
request
once
I've
gotten
both
their
approvals.
If
I
then
change
file
b,
only
amy
should
have
to
reapprove,
like
we
shouldn't,
go
back
and
ask
annabelle
to
reapprove
something
that
hasn't
changed
like
that,
doesn't
make
sense,
and
so
I
think
I've
like
had
used
the
wording
down
here
like
selective.
I
don't.
B
We
need
like
a
a
term
for
how
we're
going
to
phrase
these
code
owner
pieces,
but
the
idea
is
that
that
I
had
as
a
sub
option
of
this
feature.
So
when
you're
using
this
feature,
there
were
sort
of
two
options-
one
we
could
have
just
made
this.
B
The
the
native
behavior
of
this
setting
and
like
gone
to
like
a
smarter
code
owner
approval,
reset
annabelle
quickly
pointed
out
that
we
probably
need
a
setting,
and
I
sent
her.
You
know
appropriate
gifts,
and
so
the
idea
of
adding
a
setting
is
so
that
the
default
behavior
would
be.
B
We
would
use
a
smarter
code
owner
approval
reset
so
like
if
you
turn
on
this
first
setting,
which
removes
all
approvals
we
would
use
by
default,
what
this
phrase
in
here-
selective
code,
owner
resets,
and
so
that
would
be
the
way
where
we
only
reset
the
things
that
have
changed.
I
think
selective
needs
a
needs.
Better
word,
smithing
is
probably
the
answer
and
then
a
doc's
link,
and
I
think
that's
what
we
tried
to
do
here
is
like
spell
out
the
difference
between
these
two
behaviors
here.
B
B
C
B
A
The
reason
I
liked
the
checkbox
with
the
two
radio
buttons
and
that's
why
I
uploaded
that
and
that's
one
that
amy
also
changed
the
wording
for
is
just
because
I
didn't
like
that.
It
was
like
reset
all
approvals
and
then
sub.
Oh
wait,
don't
reset
all
of
them.
I
liked
that
it
was
like.
Do
you
want
to
reset
some
okay?
Yes,
now?
What
do
you
want
to
reset
all
or
all,
but
unchanged
kind
of
I
just
felt
like
it
makes
more
sense,
seeing
it
that
way.
B
And
I'll
also
say
this
is
I
told
this
to
annabelle
and
so
amy
for
your
reference?
I
don't
think
we
will
build
this
feature,
which
is
why
we
have
to
be
more
explicit.
There's
a
tam
that
has
asked
as
a
customer
is
interested
in
contributing.
It
was
the
only
reason,
we're
sort
of
trying
to
prep
and
figure
out
what
this
looks
like
so
by
the
wording
needs
to
be
more
accurate
or
the
settings
need
to
be
more
explicit
than
we
would
do
if
we
were
necessarily
picking
this
up.
B
Yeah,
hopefully
that
gives
additional
context.
We
don't
have
to
solve
it
now,
but
that
gives
additional
context
for
that
one.
So
we
can
go
back
and
figure
that
out.