►
From YouTube: 2021-06-29 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).
A
Here
we
go.
The
first
one
I
put
in
was
just
sort
of
you
had
asked
a
lot
of
questions
about
the
metrics
related
to
diffs
and
what
was
generated
and
what
was
viewed,
and
I
was
trying
to
figure
out.
If
there's
anything
else
you
need
or
what,
if
you
like,
have
an
expectation
of
me
trying
to
figure
this
out
or
what
you
want
to
do
on
that
one
and
just
to
limit.
A
Forth
because
I
know
I'll
be
just
make
it
a
little
bit
easier
to
get
through
this
if
we're
trying
to
get
to
something
yeah,
no.
B
At
the
moment,
no,
so
it's
it's
low.
B
I
actually
yesterday,
I
found
out
a
number
that
I
that
I
placed
in
one
of
the
like
a
slide
deck
that
was
talking
about
merge,
request
sizes
that
I
put
there
some
months
ago,
and
it
was
probably
like
march,
maybe
or
april,
and
and
it
said
that
on
dot
com,
it
was
four
percent
of
all
diffs
viewed
we're
using
the
single
file
mode,
but
now
here
this
number
is
showing
as
two
but
yeah
regardless
it's
it's
a
low,
very
low
number
still
and
that's
what
I
wanted.
B
I
just
wanted
to
know
if
we
were
tracking
this
and
so
that
we
can
see
how
it
goes
over
time.
So
right
now,
no
further
action
here.
The
only
thing
that
could
affect
this
is
prioritizing
this
research
that
we
would
look
closer
at
single
file
mode.
So
we
already
have
the
quantitative
data
we
don't
have.
We
don't
have
qualitative
data
to
understand
if
users
like
it,
why
they
like
it
if
they
think
it's
preferable
to
multi-file
mode,
always
or
only
sometimes
so,
asking
those
questions
that
the
data
can't
answer
for
us
to
understand.
B
Announcing
this
feature
and
making
it
known
because
we
haven't
made
any-
I
mean
other
than
the
release
posts,
we
haven't
made
any
announcements,
announcements
to
it
in
the
ui,
so
so
yeah,
it's
just
a
matter
of
deciding.
If
this
is
something
we
want
to
prioritize
or
not,.
A
B
Think
I
think
it's
valuable
to
to
answer
these
questions,
if
anything
for
us
to
understand
yeah,
if
it's
something
that
we
should
be
paying
attention
to,
or
not
so
much
or
if
it's
just
something
that
we
can
tell
people
that
are
migrating
from
tools
like
garrett
or
others
or
crucible,
where
they
use
this
kind
of
mode
to
say:
hey,
don't
worry,
we
have
this,
you
can
enable
it
and
it's
there.
B
A
B
That
are
using
it
since
the
beginning
already
have
some
time
using
it.
The
question
is
in
comparison
to
other
things.
If
we
would
prioritize
it.
B
B
So
what
what's
interesting
about
this
mode
is
that
it
makes
the
merge
request
ui
a
little
bit
similar
to
an
ide
where
you
have
to
click
to
jump
from
file
to
file
and
one
of
the
things
that
we've
heard
repeatedly
is
that
often
developers
check
out
the
branches
to
review
them
locally.
B
And
when
they
are
reviewing
the
branches
locally,
I
imagine
they
do
it
in
their
ide
and
they
go
from
file
to
file
so
they're
effectively
in
a
single
file
mode.
So
I
wonder
if
there's
a
connection
here.
B
And
if
single
file
mode
is
as
valuable
as
multi-file
mode
and
and
what
we've
seen
already
is
that
at
least
for
us
as
a
company
developing
gitlab,
is
that
it
helps
with
performance
and
the
loading
is
much
faster.
And
so
we
could
have
much
better
experience
if
we
pushed
more
for
single
file
mode.
But
again,
I'm
not
sure
if
it's
the
right
thing
to
do.
A
A
A
It
just
feels
like
a
if
to
me.
It
feels
like
the
way
people
use
it
right
now
is
sort
of
like
a
similar
to
how
they
might
switch
between
like
side-by-side
or
stacked
diffs
like
it
feels
like
one
of
those
things
that,
like
sometimes
you're
looking
at
something
and
like
you
want
that
focused
context,
and
sometimes
you
want
the
context
of
all
of
those
things
and
you
might
bounce
between
sort
of.
Like
all
of
those
experiences
and
same
with
this,
I
think.
B
Yeah,
that's
also
interesting
yeah.
I
think
I
think
that's
a
fair
assumption
and
it
would
be
interesting,
like
let's
imagine
that
we
validate
that
actually,
the
people
that
change
those
preferences
they
change
it
very
often.
Maybe
it
would
make
sense
to
have
those
preferences
in
an
easier
location
that
you
can
just
click
back
and
forth
between
things.
B
So
I
don't
know
regardless.
I
don't
think
this
is
the
most
important
problem
yeah,
but
but
it's
something
that
we,
it
would
be
interesting
to
figure
out.
Maybe
when,
once
we
have
annabelle
on
board,
we
would
have
more
capacity
for
this.
We
also
there's.
Also
a
problem
is
that
we
don't
have.
We
have
very
low,
ux
research
capacity.
At
the
moment
we
only
have
two
researchers
and
one
of
them
is
onboarding
still
and
we're
hiring.
B
I
think
four
four
or
five
more
researchers
so,
but
the
team
right
now
is
very
small,
and
I
know
that
anne
the
only
researcher
that
at
the
moment
we
can,
we
can
count
on.
She
is
prioritizing
just
a
few
initiatives.
One
of
them
is
the
perceived
performance
of
merge,
requests
that
I'm
working
on
with
her
and-
and
I
think,
there's
another
research
that
she's
prioritizing
not
exactly.
A
Ramp
and
then
yeah
yeah,
exactly
okay.
Okay,
you
want
to
talk
about
your
point
before
we
out
of
time
again.
B
Yeah,
I
I
mean
we
can.
This
is
an
unstructured
chat
about
this.
I
don't
we
don't
need
to
get
to
a
specific
conclusion.
I
put
some
down
some
thoughts
on
this
file,
so
let
me
share
my
screen
for
the
purposes
of
the
recording,
so
yeah
add
in
some
column.
I
don't
know
if
this
structure
makes
sense
or
not,
it
was
go
with
the
flow
at
that
point.
B
So
problem
possible
things
for
us
to
do
then
some
issues
or
related
issues
and
then
some
notes
of
things
that
I
was
thinking
about
and
they're
not
in
this
particular
order,
but
I
it
was
just
that
I
wanted
us
to
think
about
the
problems
and
not
only
the
the
solutions
and
the
possible
paths.
B
It
was
interesting
when
I
was
putting
this
together
that
this
one
that
talks
about
best
practices
and
people
avoiding
having
people
do
things
over
and
over
again
to
conform
to
their
organization's
practices.
I
wasn't
aware
that
we
had
so
many
issues
and
popular
issues
related
to
this
topic
and
yeah.
It's
basically
templating
enforcing
settings
and
validating
them
on
merge
options
in
general,
like
merge
methods
commit
messages.
If
people
can
squash
or
not
or
delete
or
not
source
branches,.
B
And
it's
something
that
we
to
my
knowledge,
we
haven't
been
paying
much
attention
to,
except
for
an
enhancement
that
we
did
some
months
ago
to
allow
people
to
choose
the
default
value
of
the
squash
commit
setting.
If
you
want
to
allow
and
force
encourage,
and
so
on
other
than
that,
we
haven't
made
any
particular
changes
here.
B
B
Is
this
one
number
four
so
row
four,
because
I
think
it's
just
trying
to
do
deeper
research
on
the
merge
request,
ui,
because
I
think
we
have.
B
We
have
research
on
merge
requests,
but
we
don't
have-
or
maybe
we
have
this
research,
but
it's
it's
scattered.
I
know
that
you
created
an
issue,
I
think
when
you
joined
or
before
you
were
joining
our
group,
that
to
have
developers
share
their
workflows
when
reviewing
merge,
requests
and
that's
something.
I
would
like
to
synthesize
more
and
have
some
insights
about
the
mental
models
and
if
it
changes
when
you're
an
author
versus
a
reviewer,
because,
for
example,
for
me
I
this.
These
are
my
assumptions
that,
like
the
merge
request,
ui
is
cluttered.
B
Tab
other
times
are
in
the
changes,
tab
things
that
are
resolved
things
that
are
not
resolved
things
that
matter
to
you
things
that
don't
matter
to
you,
but
also
that
my
assumption
is
that
the
mental
models
change,
whether
you're
an
author
or
viewer
and,
for
example,
as
an
author
you're,
more
interested
in
the
comments
and
reviewers,
are
more
interested
in
the
changes
like
what
happened
since
I
last
viewed
this
like
what
were
the
commits
that
were
made,
what
were
the
files
that
were
changed?
B
B
This
would
be
an
interesting
one
that
I
saw
as
mentioned
a
couple
of
times
that
this
is
what
people
do
when
they
why
they
go
to
ides
is
that
they
want
to
navigate
the
code
base
and
understand
why
changes
to
this,
I
don't
know
function
where
are
they
being
called?
So
you
know
just
to
understand
the
extent
of
the
changes,
and
today
it's
not
possible
to
do
that
with
merge
requests.
B
You
have
to
have
some
kind
of
code
intelligence
or
you
have
to
manually,
go
through
the
the
repo
to
find
things
so
extending
the
code
intelligence
feature
to
support,
merge
requests
or
allowing
you
to
navigate
branch.
All
of
the
code
base
inside
of
the
merge
request,
which
is
another
feature
request
that
we
have
is
commenting
on
unchanged
lines
in
an
unchanged
file.
So
I
think
these
two,
like
one
really
big
thing,
and
and
and
none
that
I
don't
see
a
specific
end
to
and
something
that
it
could
be
a
bit
smaller.
A
Okay,
I
will
take
a
look
and
then
I
think
I
also
owe
adding
some
things
in
here
sort
of
some
problem
areas
as
well,
so
I
will
I'll
try
and
work
on
the
spreadsheets
on
this
week.
It's
another
short.
B
Okay,
yeah
yeah,
you
feel
free
to
restructure
it
if
this
doesn't
make
sense
for
what
you're
thinking
is
it
from
what
I
added
here
is
there
anything
that
that
that
pops
up
for
you.
A
A
On
the
one
hand
like,
I
think
we
should
be
building
an
opinionated
tool
and
then,
on
the
other
hand,
like
some
people
will
always
disagree
with
the
opinion
and
that
will
inevitably
lead
to
these
situations.
Where,
like
they,
don't
want
to
use
the
tool
or
something
else,
and
so
it's,
I
think,
a
balancing
act
and
balancing
against
introducing
settings
and
settings
and
settings
and
configuration
that
like.
If
you
sort
of
think
about
all
of
those
issues.
Really
the
ask
is
like
we
want
more
settings
in
configuration
which.
A
I
don't
know,
that's
a
it's
just
so
tough
for
me
because
I
feel
like
if
we
could
do
that
we
could
introduce
settings
in
configuration
all
day
long,
but
I
sort
of
wonder
if
we
should
just
more
strongly
say
no
to
a
lot
of
things
and
like
I
don't
think
we
do
that,
and
I
don't
know
if
that's
the
right
answer
or
not,
but
I
don't
know,
I
think
that's
an
it's
just
interesting
sort
of
like
the
theme
of
all
of
those
is
like
configuration,
that's
a
very
touchy
subject.
I
think.
A
Otherwise,
I
don't
know
that,
there's
anything
that
necessarily
jumps
out.
I
think
your
line
four
is
spot-on
in
terms
of
what
you
talked
about
there
I
think
line.
Two
is
interesting
that
you
you've
added
native
code,
intelligence
and
sort
of
associated
it
with
like
understanding
the
broader
impact
of
changes,
and
I
only
say
that,
because
I
think
there's
like
sort
of
no
adoption
very
limited
adoption
of
native
code
intelligence.
A
I
think
it's
hard
and
it's
limited
support
like
I
think
we
only
support
like
two
or
three
languages,
and
it
requires
you
to
add
a
ci
job.
So
right,
like
anything
all
those
things
that
have
required
ci
have
typically
been
a
little
more
challenging
because
we
we
just
don't
have
a
good
way
to
get
people
to
do
that.
Right,
like
we
have
to
get
them
to
go
in
and
add
that
they
need
to
add
those
six
lines
to
their
seven
lines
to
their
ci
jobs
yeah,
and
we
only
support.
B
Yeah
yeah
there
are
more
here
that
you
can
support
yeah.
I
think
I
think
this
is
this
is
something
that
that
could
change
and
keep
people
inside
of
merge
requests
instead
of
having
to
go
to
their
ide,
I
mean.
Without
this
I
can
see
people
using
much
more
the
vs
code
extension
because
they
have
access
to
the
merge
requests,
but
they
also
have
access
to
all
of
these
things
that
are
valuable
to
them
and
navigating
everything.
So
I
think
we
need
to
replicate
that
more
inside
of
merge
requests,
but
yeah
this.
B
A
A
I
think
I
want
to
go
through
some
of
the
epics
that
exist
and
sort
of
also
come
up
with
some
problem
areas
that
like
or
maybe
inside
of
these
or
other
ones
that
I've
been
thinking
about,
and
then
I
think
the
ultimate
goal
right
was
find
these
spaces
and
then
we're
the
goal
is:
how
do
we
take
these
problem
spaces
and
then
figure
out
what
we
want
to
work
on,
and
so
I
think,
we'll
have
to
figure
that
out
once
we
build
out
that
spreadsheet
more
so,
I
think
definitely
building
out
the
spreadsheet
more
first
priority,
and
then
we
can
figure
out
how
we
decide
what
we
go
and
work
on
and
sort
of
stay
focused
on
for
a
period
of
time.
B
Yeah
exactly
cool!
Well,
thanks
guy!
Let
me
know
when
there's
anything
else
for
me
to
to
review
there,
and
we
can.
You
can
talk
more
about
this
later
awesome.
A
It
was
good
to
see
you
and
good
to
catch
up
and
I'll,
see
you
again
tomorrow.
I'm
sure.