►
From YouTube: 2021-06-09 Create:Code Review Weekly 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
Oh
matt
says
he
will
not
be
able
to
attend,
as
in
read
only
perfect.
I
guess
I
could
have
read
down
the
agenda.
A
Just
an
fyi
I
had
been
taking
like
friday
afternoons
off
that's
going
to
move
to
thursdays.
My
son's
schedule
moved
so
I'll
be
gone
like
noon
central
10,
pacific
to
3,
pacific,
just
as
an
fyi
on
most
thursdays.
A
This
might
be
a
quick
call
if
matt's,
not
here
so
and
no
andre.
I
was
trying
to
figure
out
where
we're
at
with
the
large
mr
okr
stuff,
what's
been
shipped,
what
we
think
we're
gonna
do
for
14.1
and
what
else
might
be
outstanding.
I
the
only
thing
that
I
know
of
that
shipped,
but
it's
not
even
on,
is
virtual
scrolling
and
I
don't
know
that
we've
done
anything
else.
I
don't
know
if
anyone
else
knows
of
anything
else,
either.
B
B
I
think
the
initial
load
is
is
faster,
but
the
when
you
start
using
it
and
scrolling
down
and
even
when
it's
I
was
initially
testing
it
with
a
very
large,
much
request
unreasonably
large.
But
then
I
was
assessing
it
with
a
much
request,
just
20
files
and
it
felt
yeah
kind
of
sluggish
to
me
and-
and
there
were
some
bugs
here
and
there
and
I
and
we've
been
going
around
them.
But
I
don't
know,
doesn't
look
easy
at
this
point,
but
yeah
we're.
B
A
Ashing,
I
think,
there's
a
proof
of
concept
open.
There
is
for
some
merge
request
endpoint.
So
I
think
that
is
gonna
happen,
I'll
link
to
the
epic.
This
will
probably
happen.
I
guess
in
14
1,
depending
on
how
this
proof
of
concept
comes
up,
but
that
feels,
like
all,
were.
A
I
think
it's
probably
unlikely
we'll
hit
our
goal,
but
it's
probably
fun
sorry.
I
was
trying
to
find
it.
A
B
Yeah,
I
think
so
I
think
that's
highly
likely.
Okay,
because
we're
so
the
initial
like
foundation
of
the
feature
fill
shipped
last
milestone
and
now
he's
trying
to
fix
linking
to
the
diff
files.
B
B
B
And-
and
we
still
after
that,
we
still
need
to
figure
out
what
we're
going
to
do
about
the
browser
fine
function,
because
it's
it
doesn't
work
by
default
with
virtual
scrolling.
It's
and
we
will
have
to
find
a
way
to
address
that.
B
So
I
think
yeah
we
will
still
work
work
on
it.
I
I,
as
I
said
today,
I
was
reviewing
it
and
left
a
bunch
of
comments
to
feel
I'll.
I
have
to
see
what
his
feedback
feedback
is
regarding
those
comments
to
see
if
there's
light
at
the
end
of
the
tunnel
or
if
it
feels
like
this
is
going
to
take
a
long
time,
because
from
my
last
review
in
that
mr
to
today,
there
wasn't
much
difference
and
the
experience
was
suboptimal.
B
So,
let's
see
how
that
goes,
and
but
I'll
keep
you
up
to
date
on
that,
but
it
will
probably
continue
in
14.
A
A
Awesome,
let
me
just
get
the
other.
I
guess
the
last
thing
that
I
put
on
here
was
then
based
on
based
on
what
I
think
there
is
for
performance
work,
because
it
doesn't
seeing
how
like
investigations,
have
gone
for
14
and
where
we've
come
out
of
these,
it
doesn't
feel
like
we
have
many
other
ideas
that
are
viable
to
go.
Explore.
A
A
Assuming
that
doesn't
happen.
One
of
the
other
things
that's
probably
next
up
on
our
list
is
the
merge
ability
like
service
rewriting
mergeability
and
like
merge
checks
and
how
all
of
that
works
into
like
a
single
the
single
source
of
truth,
so
the
stuff
that
carrie
and
fabio
had
been.
A
A
A
Assuming
we
don't
have
a
huge
volume
of
performance
work,
we
do
certainly
have
like
other
things
probably,
but
would
it
make
sense
to
also
start
bringing
in
mergeability
work?
And
I
say
that
because
we're
very
likely
going
to
have
to
bring
that
in
in
q3
anyways
so
like
this
would
just
give
us
a
month
sort
of
head
start.
B
On
it
yeah,
I
think
so.
I
think
that
makes
sense
to
start
that
measurability
work
if
there's
space
for
it,
the
so
the
mergeability
is.
B
Is
I
would
see
this
as
solving
edge
cases
and
and
those
pesky
bugs
that
keep
coming
up
while
also
refactoring
things
to
allow
us
to?
You
know,
build
on
top
of
that
and
make
sense
of
the
code
base,
whereas
the
the
work
that
I
did
and
that
fill
broke
down
to
slightly
redesign
the
area
of
the
merge
widget.
B
That
would
serve
everyone
in
terms
of
usability
improvements
yeah.
So
I
think
those
are
two
related
but
separate
things
and
yeah.
I
would
be
very
happy
to
see
us
make
progress
on
either
of
those,
of
course,
my
tendency
and
I'm
more
inclined
for
to
prioritize
what
has
the
largest
impact
to
most
people,
and
that
would
be
the
usability
improvements.
A
Yeah,
I
mean,
I
think
the
other
opportunity
cost
would
be
waiting
for
or
whatever
merge,
requests
that
require
my
attention
stuff,
the
that
or.
B
Yeah
sun
jung
is
still
analyzing
the
findings
from
the
usability
tests
that
she
ran
last
at
the
end
of
last
week
and
the
overall
deposit.
The
feedback
was
positive.
There
were
some
confusion
about
about
the
feature
at
specific
moments
and
one
idea
that
we
had
was
to
provide
some
like
an
introduction
to
the
feature
in
the
same
way
that
we
have.
I
don't
know
the
the
introduction
to
the
suggestions
feature.
We
will
do
something
similar
for
this
feature.
B
Saying
hey
now,
you
don't
need
to
ping
people
in
comments,
so
there's
a
first
class
way
to
do
what
you
are
already
doing
and
and
she's
looking
into
that
and
potentially
just
tweaking
the
user
tests
and
the
prototype
and
run
it
again,
because
she
has
all
eight
participants
in
the
user
tests
go
through
everything
in
three
hours,
so
yeah
from
the
moment
she
released
the
tests.
She
went
to
have
lunch,
she
came
back
and
she
knows.
B
B
Yeah,
so
I
think
it
would
if
we
were
to
put
that
into
14,
1
yeah,
I'm
just
not
sure
about
the
technical
side,
so
we
would
have
to
to
wait
so
the
yeah.
The
surest
thing
is
to
not
count
on
that
for
14
1.
B
B
So
that
means
that
what
we
already
know
today
is
something
that
we
have
higher
confidence
is
the
emergibility
to
check
and
even
that
slight
redesign
of
the
merge
widget.
Even
though
we
didn't
test
it.
I
think
the
changes
are
very
straightforward,
but
so
those
have
higher
confidence
and-
and
I
think,
are
already
as
broken
down
as
as
possible
at
the
moment.
A
Okay,
cool
that
makes
sense
to
me.
We
have
time
so
I'm
just
going
to
add
this
other
topic
that
I
want
to
talk
about
with
you,
since
you
are
here
which
is
diff
limits,
and
I
don't
know
if
you've
thought
about
this
at
all.
A
And
so
I'm
curious
if
you've
thought
about
you
know,
I
think,
on
one
hand
like
the
ideal
experience
is
that
users
never
run
into
diff
limits.
I
think
that's,
maybe
unreasonable.
The
other
question
is
like.
Is
that
a
thing
that
we
think
we
should
tell
people
like
you've
hit
this
limit
in
some
form
of
like
ui
piece,
or
is
this.
A
You
know
I'm
trying
like
how
do
we
make
that
experience
so
there's
not
a
support
ticket.
So
there's
not
a
support
engineer
in
our
chat.
Like
saying
hey,
how
do
I
even
tell
the
customer
what's
going
on
here,
because
there's
really
no
resolution
either
right
like
if
you
hit
a
diff
limit,
we
can't
really
do
anything
about
it.
In
many
cases,.
B
Yeah,
I
have
two
thoughts
I
think
avoiding
hitting
diff
limits.
I
agree
it's
we
need
to
have
limits,
but
what
we
can
do
is
try
to
optimize
for
what
is
reasonable
and
we
initially
like.
We
realized
that
the
diff
limits
were
flawed
when
we
decided
to
load
or
sorry
to
automatically
expand
if
it
was
just
one
big
file,
because
it
was
still
within
the
collection
limit.
So
if
it
didn't
make
sense
to
just
suppress
that
one
file,
but
we
stopped
there,
we
didn't
look
much
further
into
what
is
reasonable.
B
What
is
expected,
I
think
we
should
look
more
into
that
and
understand
how
we
can
optimize
those
limits
to
what
is
reasonable,
like
for
example,
it
would
be
like
it's
not
reasonable,
it's
possible,
but
it's
not
reasonable.
To
expect
someone
to
author
and
review.
I
don't
know
mercury
requests
with
hundreds
of
files
right.
So
someone
reviewing
hundreds
of
files
in
one
go.
It's
yeah!
It's
it's
a
lot
of
work,
so
maybe
we
shouldn't
optimize
for
that.
B
We
hit
the
diff
limits
and
we
get
people
in
the
slack
channel
asking
about
our
diff
limits
every
day,
week
or
month.
There
was
that
message
that
someone
shared
about
that
orange
bar.
B
That
said
too
many
files
to
show
or
something
like
that,
and
I
wasn't
sure
because
someone
said
that
it
was
visible.
But
then
someone
said
that
it
wasn't
visible
that
message
and
that
we
were
not
showing
that
message.
So
I'm
I
was
left
unsure
if
we're
actually
showing
that
message
when
we
hit
the
dif
limits
or
not.
B
B
There
is
another
case
that
we're
not
showing
any
alert
to
the.
That
is
the
case
where
it's
even
not
possible
to
render
some
of
the
files.
So
it's
not
that
you
can
expand
them,
they're,
just
not
renderable,
because
they
we've
gone
past.
The
limits
like,
for
example,
in
a
collection
of
five
five
megabytes
of
diff
files.
At
a
certain
point,
we
only
say
the
names
of
the
files,
but
you'd
have
to
download
them
or
go
and
look
at
them
separately.
B
So
I
think
it's
those
two
things
in
the
end,
it's
making
sure
that
all
of
if,
whenever
someone
hits
the
diff
limits
any
kind
of
diff
limits,
we
make
that
visible
and
make
sure
that
is
happening
because
I
at
this
moment
I'm
not
sure
that
that
is
happening
for
all
cases
and
and
we
can
also
link
to
the
def
limits
documentation
if
people
want
to
to
learn
more.
A
Sense
yeah,
I
think
all
that
makes
sense.
I
was
trying
to
go
and
find
issue
as
well
or
like
the
last
time.
Someone
was
in
our
chat
talking
about
this
there's
one.
Yesterday,
there's
like
a
bug
with.
A
A
A
I
mean
the
optimal
one.
Already
is
not
I
just
I'm.
I
wonder
if
we
should
try
and
think
about
being
granular
enough
to
be
like
a
big
box
at
the
top.
That's
like
this
merge
request,
hit
these
limits
and
like
this
is
the
impact
of
those
limits,
like
you
hit
max
patch
byte
size
on
three
files,
and
you
hit
sort
of
like
total
collection
limits
and
like
or,
if
that's
so
confusing
to
people,
because
there's
so
many
things
involved
that,
like
that's,
not
not
helpful
at
all.
B
Yeah,
I
don't
think
we
need
to
be
explicit
about
exactly
what
limits
we're
getting,
but
just
explain
to
users
in
the
most
human
language
possible:
hey,
we're
not
showing
everything
or
some
files
are
very
large,
so
we're
not
able
to
show
them
so
yeah.
Just
in
a
plain
language.
Try
to
explain
that
we're
not
showing
certain
things,
but
you
can
do
something
about
it
or
we're.
B
Not
it's
not
possible
to
render
them
at
all,
and
you
here
are
the
options
for
you
to
to
solve
that,
and
if
you
really
want
to
know
the
technical
details
and
all
the
limits
here
is
the
the
nerds
documentation
you
know
so
yeah.
B
I
think
at
the
moment
what
I've
seen
in
those
messages
that
you
were
mentioning
in
the
beginning
is
that
people
are
just
unaware
why
the
numbers
are
different
in
the
diff
stats
and
and
why
they
miss
files
or
why
certain
files
are
showing
hidden
or
collapsed,
or
you
have
to
download
them
so
yeah.
I
think
that's!
It's
just
making
things
a
bit
more
accessible
with
plain
language,
perhaps.
A
A
It
feels
like
an
annoyance
more
than
it's
like
something.
We
definitely
need
to
go
fix,
but
it
it's
come
up
enough
recently
that
it,
I
don't
know,
spending
a
little
bit
of
time,
thinking
about
options
and
what
is
possible
and
what
isn't
possible
might
be
worthwhile,
and
maybe
we
can
have
someone.
A
A
B
Have
we've
started
tracking
when
they
hit
how
often
the
diff
limits
are
hits
right.
B
So
I
think
that
that's
what
the
one
of
the
first
steps
that
we
needed
and
then
we
also
have
that
issue
with
the
idea
of
automatically
adjusting
the.
B
B
The
easiest
thing
to
to
understand
is
like
a
merge
request,
has
changes
and
I
want
to
see
those
changes
and
if,
for
some
reason,
the
collection
of
the
changes
is
too
big
too
big,
we
can't
show
them.
I
don't
think
users
can
easily
wrap
their
head
around
the
individual
file,
size
limits,
so
the
weight
of
the
files
and
the
number
of
lines,
and
then
the
number
of
files
that
I
think
all
of
that
is
too
complex.
B
B
A
Cool
well
thanks
for
chatting
pedro
and
thanks
everyone
else
for
hanging
out.
It's
good
to
see
all
of
you
enjoy
the
enjoy
the
rest
of
your
day.