►
From YouTube: 2022-02-22 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
Let's
wait:
okay
now.
A
Sorry
yeah:
this
was
something
that
I
was
starting
to
discuss
with
with
annabelle
and
we
just
thought
hey,
let's
bring
it
over
to
the
ux
sync
also
because
we
ran
out
of
time.
So
we
thought
oh,
let's
make
use
of
this
time,
but
anyway
yeah
we
one
of
the
first
steps
to
in
the
restructure.
Mrs
work
is
prioritizing
the
problems
that
we
identified
so
in
the
issue
description
that
is
linked
from
from
there.
A
There
are
a
bunch
of
problems
that
have
specific
research
insights
attached
to
them
and
we
know
that
there
are
problems
and
so
on,
but
the
more
that
I
was
thinking
about
it.
It
didn't
make
me
it
didn't,
make
a
lot
of
sense
to
me
that
you
know
first,
that
we
had
to
prioritize
them
as
much,
because
if
you
have
to
start
prioritizing,
maybe
you
have
too
many
problems
to
solve
and
at
the
same
time
it's
also
about
how
can
we
elicit
good
solutions
and
ideas
to
solve
those
problems?
A
A
This
is
not
a
major
problem
right.
This
is
you
know
something
that
we
need
to
consider,
but
it's
not
something
that
we
will
go
out
of
our
way
to
to
solve,
and
so
with
these
overlaps
and
so
on.
I
I
tried
to
start
writing
down
like
the
three
large
problems
that
I
was
seeing
and
they
all
seemed
to
revolve
around
the
information
architecture
and
we're
out
in
there
like
it's.
A
You
know,
navigation,
just
very
little
room
for
focused
reviews
in
the
changes
tab
and
in
the
overview
tab
the
just
being
so
overwhelming
that
it
has
so
much
information
that,
even
with
that
amount
of
information,
it's
still
difficult
to
get
an
overview
of
the
mr
and
and
yeah.
A
So
this
is,
you
know
mostly
me
trying
to
think
through
all
of
this
and
wondering
if
any
of
you
have
any
thoughts
or-
or
maybe
you
know,
just
questions
that
might
help
me
think
a
little
bit
better
about
this,
because
you
know
just
to
to
wrap
up
my
parts.
So
I
wrote
down
those
three
large
problems
that
I
see
and
then
I
wrote
after
them
like.
In
what
ways
can
we
give
users
access
to
the
information
they
need
along
their
code
review
journey?
A
You
know
just
trying
to
phrase
the
problems
again
in
a
way
that
elicits
broad
solutions
and
that's
not
just
focused
on
hey
it's
difficult
to
navigate
comments,
because
it's
not
just
about
comments
right
and
below
each
problem.
I
was
thinking
what
do
we
need?
What
information
do
we
need
to
answer
this
question
of?
In
what
ways
can
we
and
to
me,
I
wrote
down,
for
example,
for
navigation.
A
You
know.
One
of
the
things
that
we
need
in
insights
is:
what
are
the
actions
and
information
that
users
need
during
this
code
review
journey.
You
know,
because
if
we
don't
know
what
they
need,
we
cannot
answer
this
question
about.
In
what
ways
can
we
give
users
so
yeah
again,
just
me
trying
to
structure
this
a
little
bit
and
coming
to
the
realization
that
maybe
we
don't
need
to
prioritize
them
so
much
because.
A
As
we
discussed
in
in
in
that
presentation
that
we
did
for
this
work
and
the
documents
these
problems
are
all
connected
to
each
other,
but
I
just
don't
want
us
to
have
a
very
big
list
of
problems
I
prefer,
if
we
just
have
something
focused
like
you
know,
two
three
problems
and
anyway,
I'm
just
talking
a
lot.
I
hope
what
I'm
saying
makes
sense,
but
it's
just
raw
output
from
my
head.
A
C
Yeah,
you
guys
can
take
this
or
leave
it,
but
one
thing
that's
worked
well
and
I've
had
this
in
the
past
is
a
sort
of
affinity
cluster.
So
you
can
group
in
this
case
by
like
the
problems
that
would
be
fixed
by
the
same
solution
right
so
you're
narrowing
down
your
your
like
number
of
targets.
So
if
a
bunch
of
them
are
ia
related,
you
can
group
those
and
then
like
hey.
A
A
Problems,
problems
that
are
more
or
less
unique,
but
not
too
broad
like
the
broadest
problem
is
the
ui
is
doesn't
have
focus
right.
That's
that's
a
very
like
how
can
we
bring
focus
to
the
ui?
That's
that's
too
too
broad,
but
yeah
affinity
constraint
would
definitely
be
part
of
it
and
then
I
added
you
know
maybe
doing
a
five-wise
exercise
for
the
top
problems
we
get
to.
You
know
the
root
causes,
but
I
mean
I
think
we
are.
You
know
what
the
root
causes
are
so.
D
B
Problems
because
you
don't
think
we
can
solve
the
broad
problems,
even
though
that's
sort
of
what
the
purpose
of
the
restructuring
is
to
do
is
to
sort
of
like
broadly
solve
those
problems.
I
guess
I'm
just
not.
I'm
not
clear
on
like
what
you're
what
what
we're
trying
to
accomplish
by
like
refocusing.
B
Sort
of
the
things
that
we
already
knew
were
problems,
and
there-
and
I
say
that
because
the
reason
we
knew
these
were
problems
was
that
they
were
big
problems
that
we
couldn't
solve
in
very
focused
ways
and
that's
why
we
sort
of
chose
to
go
this
different
way
to
think
about
it.
And
so
what
are
we
trying
to
get
at
now?.
A
Yeah,
I
think
it's
so
let
me
share
my
screen
so
that
we're
all
looking
at
the
same
thing.
So
there
are
these.
You
know
big.
These
problems
are
all
connected
more
or
less
to
each
other,
but
some
of
them
were
not
going
to
be
able
to
address
immediately
with
the
restructuring.
A
You
know,
for
example,
developers
need
to
constantly
refresh
the
mr
to
get
an
accurate
depiction
of
the
current
state
of
an
mr
like
if
the
technology
doesn't
provide
this,
it
doesn't
matter
how
good
of
information
architecture
you
have
right
and
another
example
is
merge.
Requests
with
lots
of
comments,
threats
and
activity
are
difficult
to
follow
or
comments
appearing
across
the
overview.
Tab
and
changing
step
can
be
confusing.
A
These
are,
I
think,
yes,
problems,
pain,
points,
but
the
way
that
they
are
phrased
and
that
they're
more
or
less
the
same
thing
they
do
not
do
not
elicit
you
know
broad
ideation.
A
You
know
this
is
one
is
just
focus
on
comments
appearing
across
your
review
tab
in
changes
tab,
but
we
also
have
or
will
have,
in
the
very
short
term
the
same
problem
with
with
those
security
and
code
quality
findings.
A
Like
they're
also
things
that
can
exist
attached
to
changes
or
not
attached
to
changes,
and
they
can
appear
in
multiple
places
at
the
same
time,
so
in
in
a
way
is
what
I'm
trying
to
do
is
clean
up
this
list
to
have
less
things
and
with
the
few
things
that
we
end
up
with,
have
them
phrase
in
a
way
that
provides
clear
focus
to
everyone.
A
So
that's
moral.
I
said
I
don't
know
if
so
we're
still
solving
the
same
things
like
we're.
Of
course
we're
not
going
to
again
to
solve.
You
know
conventional
comments,
we're
not
going
to
work
on
that
right.
For
example,
if
my
description
is
descriptive,
enough
reviewers
will
then
check
the
linked
issue
like
this
is
something
we'll
take
in
consideration,
but
we're
not
going
to
solve
mr
descriptions
being
not
being
descriptive
enough
right.
B
B
You
think
they
don't
solicit
good
ideation
or
does
or
is
it
because
you
think
some
of
those
are
aspirational,
or
maybe
not
within
the
realm
of
solving
that
you
want
to
eliminate
them
and
I'll.
Just
take
two
that
you
point
out,
one
was
merge.
Requests
are
not
updated
in
real
time
like
do
you
think
that
aspirationally,
that's
like
out
of
scope
for
restructuring
to
say
the
ultimate
design
vision
requires
these
elements
on
the
page
to
be
updated
in
real
time
and
so
like.
B
The
other
one
that
you
put
on
there
was,
or
that
you
mentioned,
was
comments
appearing
on
overview
and
changes
tab,
and
that
is
something
that
we've
talked
about
sort
of
a
lot
in
the
sense
that,
like
those
are
duplicative
things
in
many
cases
or
they're,
very
awkward
in
many
cases,
and
they
might
require
us
to
sort
of
like
rethink
entirely,
how
we
approach
those
two
tabs
and
so
making
sure
that,
like
yeah
they're,
very
broad
and
big
problems,
but
like
they're,
also
broad
and
big,
so
that
we
can
think
more
sort
of
like
aspirationally
about.
B
A
Yeah,
it's
it's.
I
think
it's
just
a
balance,
and
it's,
I
think
it's
about
about
semantics,
and
I
mean
we
don't
need
to
get.
You
know
stay
here
in
this
moment
for
too
long.
It's
just
me
trying
to
because
the
other
part
of
this
is
that
can
also
have
some
context.
A
Is
okay,
we're
these
are
you
know
the
problem
statements
and,
and
we
in
that
document
and
the
presentation
we
had
some
bullet
points
about
the
problems,
but
they
were
again
not
phrasing,
a
way
that
is
that
has
a
balance
between
broad
and
narrow
and
and
that
you
know
again
elicits
the
ideation
and
we're
also
one
of
the
things
that
we're
going
to
do
is
bring
in
other
designers
to
provide
input
on
directions
that
we
could
work
on
to
address
these
problems
and
have
that
brainstorming
with
them.
A
So
it's
just
a
way
for
us
not
to
get
too
hung
up
on.
You
know
the
specific
details
because,
for
example,
you
mentioned
comments,
overview
and
changes
tab,
but
once
you
think
about
it,
it's
not
only
like
when,
if
you
try
to
change
that,
it's
yes,
it's
the
comments,
but
then
it's
also
about
how
I
can
navigate
in
the
future
to
findings
that
are
attached
to
lines
of
changes.
A
A
I
was
trying
to
write
it
in
a
way
that
tries
to
capture
all
of
that
right,
because
that's
that's
the
problem,
basically,
that
we're
trying
to
solve,
and
it's
separate
from
the
second
one
which
the
second
one
is
much
more
focused
on
the
changes
tab,
and
we
know
that
you
know,
regardless
of
navigating
comments
and
regardless
of
the
overview,
tab
and
users
being
informed
about
the
state
of
dmr
and
not
being
overwhelmed.
A
We
know
that
it's
a
big
problem
is
okay,
you
get
to
the
changes
you're.
Just
looking
at
the
code-
and
it's
there's
not
a
lot
of
room,
there's
so
many
things
going
around,
that's
that
it
doesn't
leave
a
lot
of
room
for
focused
review
and
then
the
other
problem
with
the
overview
tab,
which
is
separate
from
the
other
ones.
It's
still
related
to
information
architecture,
but
it's
focused
on
how
can
we
inform
the
users
about
the
state
of
the
merge
requests
without
overwhelming
them?
A
And
this
is
just
looking
at
the
primary
pieces
of
data
that
users
need
to
take
a
look
at
when
they
reach
a
merge
request
and
to
actually
give
them
an
overview,
and
these
are
think
are
all
related,
but
at
the
same
time
they
are
distinct
and
to
me
they
feel
like
more
that
they
have
consolidated
everything
that
we
have
listed
in
that
issue,
and
this
was.
C
D
I
I'm
an
interloper
to
the
ux
group
here.
So
forgive
me
if
this
is
something
that
you
are
it's
like
obvious
and
baseline,
but
like
like
what
I
kind
of
hear
you
saying,
is
that
a
lot
of
the
feedback
and
the
notes
and
just
kind
of
what
I'm
seeing
is
it's
specific
to
like
solving
a
specific
problem
that
is
outside
the
context,
larger
context
of
you
know,
looking
at
a
more
holistic
or
top
of
the
process
solution
from
the
task
based
perspective
like
what
is
the
user?
D
What
are
what
are
all
of
our
users
trying
to
accomplish
within
how
they
interact
with
emerge,
requests
right,
it's
like
we
want
to.
You
know
you,
you
want
information
about
the
conversation,
that's
happening
or
you
need
to
do
the
task
of
reviewing
it,
etc,
etc,
and
we
kind
of
micro
optimize
in
a
lot
of
ways,
a
lot
of
our
feature
set
around
specific
features
or
problems
that
people
are
having
in
isolation
from
the
other
pieces
and
goals
that
users
have
when
they're
they're,
interacting
with
it
is
that
kind
of
where
you're
angling,
yeah.
A
A
How
can
users
more
easily
check
out
their
code
right,
but
maybe
in
with
the
context
of
the
merge
request
as
it
is
today,
maybe
the
problem
is
actually.
How
can
users
find
the
most
important
impactions
that
they
need
to
take
in
a
merger
quest
more
easily,
which
includes
checking
out,
might
be
one
of
the
most
important
actions,
but
it's
not
just.
There
are
other
important
actions.
E
So
I
I
think
I
kind
of
had
a
similar
question
in
our
one-on-one
about
prioritizing
these
problems
when
we
couldn't
do
it
months
ago,
which
is
what
led
to
this,
I
suppose,
but
I
think
again-
and
I
don't
know
if
this
is
what
you're
thinking
either
grouping
I
agree.
Definitely
some
of
those
problems
are
so
similar
and
I
tried
to
in
my
in
my
little
rearranging
demo
for
the
lo-fi
mock-up
I
addressed
like
maybe
four
of
them
just
at
once,
because
they
were
the
easier
ones
like.
E
I
can't
find
the
widget,
so
it's
at
the
bottom.
I
don't
want
to
fix
elements.
I
removed
those.
I
don't
know
what
else
I
did
tried
to
deduplicate
some
elements
like
the
source
branch
button
and
that
kind
of
stuff
and
then
just
kind
of
make
the
the
hierarchy
make
more
sense.
E
I
don't
know
what
to
do
about
that
one,
but
I
I
think
if,
if
you're,
if
you're
talking
about
simply
rewriting
them,
I
think
that
makes
sense.
Although
I
did
kind
of
like
the
list
like
when
I
was
designing
it.
I
was
like
okay,
we're
addressing
these
problems
and
I'm
clearly
not
addressing
those
ones,
so
I
could
tell
what
was
going
on
and
which
ones
had
the
check
marks,
but
separating
out
features
like
that,
I
can
definitely
see
value
in
like
forget
the
design.
B
Does
it
make
sense-
and
you
sort
of
did
this
with
like
your
your
c
one,
two
three
like,
instead
of
trying
to
like
rewrite
like
to
make
a
new
problem
statement
that
encompasses
a
bunch
like?
Could
you
just
group
them
in
themes
and
be
like
content
with
that
and
say,
like
one
of
the
themes?
Is
navigation
and
here's
like
a
subset
of
like
very
specific
problems
within
that,
but,
like
we
sort
of,
I
think,
we'll
spend
so
much
time
trying
to
write
like
a
perfect
problem
statement.
B
B
Like
you
really
one
of
the
things
that's
not
clear
about
tabs
to
most
people
is
sort
of
like
the
overview
in
changes
tab
until
you
spend
a
ton
of
time
in
code
review
and
like
going
back
and
forth
between
these
and
having
conversations
with
people
and
so
like
having
that
specific
context
helps
people
think
more
broadly
about
tabs.
It's
the
same
reason
like
when
we
talked
to
secure
about
wanting
a
security
tab.
B
B
That
sounds
like
what
annabelle
was
thinking
about,
that
might
that
might
help
other
people
that
have
even
less
context
than
than
she,
and
I
both
have.
A
So
what
I
understood
that
you
were
saying
is
that
looking
at
the
issue,
you
know
that
list
of
insights,
that
we
have
there
with
problems,
problems
neutral
and
so
on.
That
is
more
tangible
and
you
know
to
annabelle's
example
of
you
know
that
lo-fi
sketch
of
rearranging
things
it
was
easier
to
like
a
checklist.
Okay,
I'm
going
to
look
into
this,
look
into
that
and
so
on,
and
I
think
that
makes
a
lot
of
sense.
A
And
then
you
were
saying
kai:
okay,
let's
try
to
maybe
just
group
them
and
that's
that's,
basically
what
I'm
trying
to
do
and
with
with
these
just
three
large
problems
but
in
addition,
is
keeping
these.
So
these
things
that
we
have
here
as
insights
of
the
problems.
So
an
example.
A
Let
me
see
so
too
much
information,
the
overview
tab,
but
it's
people
to
get
an
overview
of
the
mr.
So,
in
what
ways
can
we
better
inform
users
about
the
mr
without
overwhelming
them,
and
then
we
need?
What
are
the
insights
that
we
need
to
actually
answer
this
question?
We
need
to
know:
what's
the
information
that
users
need
to
get
an
overview
of
the
mr?
So
if
we
look
at
this
list,
we
already
have
two
things
that
are
at
least
two
that
are
spread
out
here.
A
So
one
is
that
developers
tend
to
ignore
the
report
widgets,
and
then
we
have
a
bunch
of
specific
things
here
and
then
we
have
another
one,
which
is
it's
difficult
to
get
a
quick
overview
of
who
has
already
approved
or
still
needs
to
approve
the
mr
right,
and
then
we
have
this
other
one.
There's
an
information
overload
on
the
overview
page.
A
So
these
are
all
the
same
thing
that
we're
trying
to
address,
but
there
are
slightly
they're
slightly
more
inclined
to
one
way
or
the
other,
and
there
are
just
basically
insights
that
we
can
use
and
as
anchors
to
answer
that
big
question,
like
the
big
question,
how
can
we
better
inform
users
about
the
mr
without
overwhelming
them?
So
I
think
at
the
end-
and
this
is
my
my
summary-
it
seems
like
we're
talking
about
the
same
thing,
which
is
you
know,
just
group
them
into
with
headers
that
make
sense
and
elicit
ideation.
A
A
Yeah
we
sometimes
you
need
to
go
down
the
road
to
yeah,
see
where
you're
going,
okay,
yeah
and
but
just
just
to
clarify
in
coming
back
to
the
original
intention
of
that
issue.
Prioritize
problems
and-
and
I
wrote
there-
hey-
maybe
at
the
top
prioritize
and
label
problems,
as
must
solve
or
nice
to
solve,
and
I
think
that's
because
we
had
this
big
list
of
problems,
but
I
don't
think
we
need
to
prioritize
them.
E
E
This
has
nothing
to
do
really
with
what
we're
talking
about,
but
the
last
one
it's
like
how
we,
how
can
we
better
inform
users
about
the
mr
without
overwhelming
them
and
like
getting
that
current
state
of
the
merge
request,
and
I
know
we
have
attention
requests
that
will
show
everyone?
E
A
No,
I
I
I
don't
think,
there's
an
issue
for
it,
but
like
many
things,
I
I
thought
about
it,
but
didn't
yeah
we've
been.
We.
B
Have
talked
about
it
based
on
code
owners
is
how
we've
largely
always
talked
about
that
like
if
you
were
a
code
owner
for
a
specific
set
of
files
that
were
in
the
merge
request,
we
would
tailor
the
merge
request
to
be
like
on
the
review
side,
like
files
that
you
cared
about,
because
you
were
the
code
owner
for,
but
not
anything
else
of
the
merch
request.
B
C
Like,
like,
you
have
three
unanswered
questions
or
comments
on
this
page
or
you
know,
have
three
to
do's
on
this
mri
or
something
that'd
be
cool.
I
like
it.
A
Yeah,
and
even
I
think
things
not
only
the
things
that
you
need
to
do,
but
also,
and
that's
something
that
me
and
amy
have
talked
about
at
length
with
when
we
were
looking
at
the
merge
widget
strings.
Is
that
sometimes
we're
showing
or
highlighting
the
why
merge
is
blocked
a
lot
to
users
that
can't
do
anything
about
it
right
and
like
hey?
There
are
merge,
conflicts,
and-
and
things
like
that,
so
I
think
highlighting
and
emphasizing
these
are
the
things
that.