►
From YouTube: 2021-06-18 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).
B
Just
I
don't
know,
if
there's
any
actions
here
so
14-0,
I
think
the
engineering
work
should
be
done.
We
had
to
end
a
little
bit
early
this
month
because
it's
such
a
big
milestone,
so
people
are
wrapping
everything
up
there.
I
think
there
might
be
a
small
chance
to
get
some
engineering
stuff
in,
but
not
guaranteed.
B
But
then
anything
that's
left
in
14-0
we're
going
to
have
to
move
to
14-1
I've
done
most
of
the
at
least
back
end
stuff.
I
don't.
I
haven't
really
looked
at
the
front.
End
work,
but
there's
a
couple
issues
still
in
review
that
I
have
to
follow
up
on
and
then
yeah
just
gonna
start
working
on
14
1..
So
my
question
kind
of
leading
question
for
kai
is
make
sure
the
focus
is
still
on
the
large.
Mr.
B
A
Yeah,
I
think
141
is
sort
of
the
last
full
milestone.
I
believe
that
we
get
in
the
quarter,
so
we
have
not
made
much
progress
on
the
okr
today
so
yeah.
We
we
need
to
figure
out
what
we're
going
to
do
in
14.1
and
then
hopefully
we'll
get
some
new
new
measurements
in
at
some
point.
C
Yeah
and
sorry
for
jumping
on
your
question,
okay
and
saying
yes,
I'm
glad
you
agree
my
biggest
question
right
now.
I
noticed
that
I
think
it
was
patrick
that
created
a
bunch
of
issues
for
the
caching
investigation.
Do
we
have
capacity
for
some
of
those,
at
least
because
those
could
probably
help
the
numbers
get
better,
even.
B
I
think
so
kai
and
I
are
going
to
meet
later
today
to
kind
of
go
through
it
right
now.
The
back
end
capacity
is
basically
double
what
we
actually
have
or
what
is
in
14
1.
The
weights
is
double
what
our
capacity
is,
so
okay,
so
we're
gonna
have
to
start
moving
at
least
half
of
those
out
okay,
but
I'm
hoping,
I
mean
kind
of
why
I
asked
this
too,
is
I
assume
this
is
the
focus,
so
anything
related
to
that,
like
the
caching
stuff,
would
probably
take
top
priority.
C
Yeah,
I
think
they
can
definitely
help
and
given
I
have
an
update
later,
but
we're
going
to
be
focusing
heavily
on
memory
usage
and
if
the
back
end
can
help
on
the
timing
of
the
request,
I
think
we'd
have
two
threads
going
on
to
improve
the
whole
situation
so
yeah.
That
would
be
nice.
C
Thoughts,
so
my
next
point
is
kind
of
preparing
for
fourteen
one
as
well.
In
the
last,
in
the
last
retro,
we
had
a
discussion
about
the
kind
of
a
gap
between
assignments
and
it's,
we
kind
of
like
boiled
it
down
to
the
sorry
assignments
between
back
and
front
end.
We
boiled
it
down
as
a
side
effect
of
kanban,
probably,
and
since
we
have
a
upcoming
milestone
coming
coming
up,
I
wanted
to
check
it
seems
like
you're
planning,
on
having
a
retro
specific
about
kanban.
C
But
do
you
have
any
thoughts
for
14
1?
How
should
we
handle
that
to
make
sure
that
if
we
do
have
some
back-end
and
front-end
issues,
how
can
we
ensure
they're
tackled
timely,
because,
like
kai
was
saying,
I
feel
like
14
1
is
going
to
be
a
very
decisive
milestone
for
the
okr.
So
I
want
to
make
sure
that
we're
ready
and
line
up
in
line.
B
It's
actually
the.
I
think,
the
fourth
one
we've
done
about
the
kanban
process,
so
we
we're
it's
mixed
feelings.
Nobody,
I
don't
know
I'll.
B
Let
it
play
out
a
little
bit
more,
but
yeah
that
was
one
of
one
of
the
big
concerns
is
that
I
think
when
we
planned
14-0
those
issues
that
had
the
front-end
back-end
dependencies
were
placed
pretty
high,
but
nobody
picked
them
up
right
away
like
they
were
prioritized
high,
so
they
should
have
been
the
first
ones
that
were
taken
so
that
I
don't
know
if
the
process
broke
down
a
little
bit.
We
also
yeah.
C
B
Yeah,
exactly
and
one
of
the
themes
from
kanban
retro
number
three
was
that
people
kind
of
liked
having
that,
just
in
general,
having
knowing
what
they're
gonna
be
working
on
for
the
whole
milestone,
because
then
they
can
kind
of
plan
their
month
as
well,
which
and
yeah
like
you
said,
a
lot
of
things
slipped
into
14-0,
so
people
are
already
assigned
to
work
or
they're
already
working
on
things
that
maybe
weren't
those
top
priority
new
things.
B
So
I
think
what
I
would
like
to
do
is
if,
when
we
identify
any
for
14
1
identify
any
that
have
those
dependencies
we'll
make
sure
they're
assigned
right
away
and
then
we'll
I'll.
C
B
D
Recognize
these
mixed
issues
are
the
ones
that
have
like
front
end
and
back
end
labels.
Is
that
correct.
C
C
Cool,
so
next
one,
I
wanted
to
provide
a
bit
of
an
update
on
what
we're
thinking
for
fortune
1
and
the
state
of
virtual
scrolling
and
pedro
has
been
helping
phil
review
the
fixes
and
he's
been
providing
a
very
useful
feedback
on
the
you
know,
the
the
effects
of
the
virtual
scrolling,
some
side
effects,
and
some
of
them
are
pretty
obviously
code
that
is
broken.
Others
are
still
just
an
effect
of
the
library
re-putting
things
on
the
page
and
the
slower
and
more
work.
C
It
has
to
do
the
more
perceived
sorry,
the
more
perceivable
it
is
that
the
element
wasn't
actually
there.
It
just
got
placed
when
I
scrolled
right.
So
there's
a
little
bit
of
a
slight
of
hand.
We
have
to
play
there
in
a
bit
of
a
race
between
the
user
scrolling
and
the
browser,
putting
the
components
back
in
so
we're
having
some
really
low
level
front-end
discussions
about
what
we
can
do
to
the
code
base
so
that
we
can
make
that
faster.
C
They
all
boil
down
to
memory
usage
being
lower
and
less
work
to
do
when
putting
things
back
on
the
page,
a
last
components,
maybe
maybe
having
some
sections
that
are
not
placed
there
at
all,
so
we're
we're
exploring
some
options
and
some
and
they
will
materialize
into
issues
before
the
start
of
the
milestone.
So
that's
what
I'm
hoping
to
have
ready
by
our
conversation
tomorrow.
Okay,
so
that
we
have
a
concrete
plan.
C
There
might
be
one
or
two
issues
that
are
specific
on
the
intent,
broad
on
the
actual
code
being
changed
because
we'll
be
like
we'll
calm,
the
the
code
base
for
components
that
need
this
approach,
but
we're.
C
At
it
with
some
specificity,
rather
than
something
very
vague,
so
yeah
our
biggest
effort
here
for
the
fortune,
one
will
be
exclusively
for
memory
and
component
complexity.
Your
question.
A
Okay,
here's
my
question:
is
this
worth
continuing
to
go
down
the
path
of
like
trying
to
get
the
virtual
scrolling
stuff
to
work
or
would
the
milestone
be
better
spent?
Looking
at
other
performance
opportunities
right,
there's,
there's
a
cost
to
having
phil
in
or
other
people
spend
a
milestone
sort
of
fixing,
something
that
we
don't
don't
even
know
if
it'll
get
there
versus.
Maybe
if
there's
more
concrete
things,
I
think
we
all
thought
this
would
be
like
the
biggest
win,
but
it's
clearly
going
to
be
a
lot
more
work.
So.
C
We
just
had
a
chat
me
and
phil
today
about
this,
and
he
he's
trying
to
avoid
having
to
rewrite
the
whole
library,
because
that
would
be
a
big
of
a
of
an
effort,
but
we
looking
at
the
numbers
we
do
see
some
really
good
benefits
that
justify
the
pain.
C
So
in
the
end,
the
other
threads
we
would
be
exploring
would
be
decreased
memory
usage
and
make
the
page
lighter
to
render,
which
is
what
we're
going
to
be
looking
to
basically
make
the
work
that
the
virtual
scrolling
has
to
do
lighter,
which
is
the
work
that
the
browser
would
have
to
do.
If
there
wasn't
virtuous
calling
at
all.
So
we
will
be
doing
something
not
specifically
for
the
for
virtual
scrolling,
which
kind
of
like
is
already
a
parallel
effort,
but
it
will
end
up
being
supportive
of
that.
C
If
we
do
end
up
enabling
it,
we
do
feel
confident
that
we
will
be
able
to
enable
it,
but
again
as
we
uncover
more
bugs
and
quirks
the
time
of
enabling
that
feature
flag
is
slipping
away
from
under
our
feet
a
little
bit,
and
we
are
cognizant
that
it
might
prove
to
be
later
than
we
expect
so
we're
trying
to
do
our
best
to
get
to
the
point
where
we
can
enable
it.
But
regardless
of
that,
these
improvements
will
be
shipped
in
parallel
and
from
what
I
understand.
C
They
won't
be
behind
the
feature
flag
of
the
virtual
scrolling,
so
they
will
be
benefiting
the
page
immediately,
which
is
part
of
the
problem
of
the
lack
of
progress
on
the
okr
of
that
we're
doing
a
lot
of
work,
but
a
lot
of
it
isn't
being
felt
by
the
users,
and
we
really
are
worried,
but
aware
of
it
too.
So
does
that
make
sense.
A
Yeah,
that's
fine!
I
just
wanted
to
make
sure
we're
thinking
through
it
completely.
So
absolutely
absolutely.
C
Okay,
I'll
keep
you
posted
and
by
tomorrow
I
hope
to
have
a
more
specific
picture
of
this
is:
is
tomorrow,
okay,
for
your
timing
to
do
the
video?
Are
you
doing
the
video
at
all,
or
are
we
just
focusing
on
performance.
A
A
Video,
okay,
I
have
a
head
cold
and
I
don't
really.
B
Reminded
me
of
this
we
had
so
christopher
was
had
some
concerns
that
it
looked
like
we
weren't
making
any
progress
on
this
okr.
Despite
doing
all
these
fixes
and
having
things
behind
feature
flags,
so
what
we
tried
last
week
so
we'll
we,
we
have
to
tune
it
a
little
bit.
I
think
but
tried
adding
a
number
of
like
intermediate
steps
underneath
this
saying
like.
Oh,
we
did
this
work.
This
is
behind
a
feature
flight
whatever,
which
makes
so
they
can
see
that
we're
actually
working
on
this.
B
It's
not
like
we
forgot
about
it,
so
it
makes
it
look
like
we've
made
progress
at
least
on
this
a
little
bit.
It's
a
little
different
than
just
saying.
Oh
we've
met
this
40
goal
or
whatever.
C
A
little
I
appreciate
it
matt.
I
think
there
was
no
other
way
of
revealing
progress
than
the
way
that
you
did
it
yeah.
D
C
I
also
feel
conflicted
that
we
ordered
the
okr
very
results,
oriented
and
now
we're
showing
progress
in
a
way
that
it's
still
not
felt
on
the
results.
I
we
vocalize
it,
but
I
think
it's
useful
to
have
the
upper
management
up
to
speed
that
we
are
actively
pursuing
this,
and
so
I
think
it
fulfills
their
its
job.
Sure
that
sounds
good.
B
One
original
idea
was
like
hey,
just
put
we're
10,
we've
met,
10
of
our
performance
and
then
20
and
like
have
a
kr
for
each
percentage
and
then
mark
those
off
just.
C
Yeah
so,
but
I
think
it's
a
lesson
for
our
future
okrs,
although
I
do
like
okrs
based
on
results,
it
is
important
for
us
to
be
cognizant
about
how
I'm
going
to
score
this
intermediately
in
the
middle
of
things.
Yeah.
B
Yeah,
it's
a
little
different
this
time
too,
because
the
there's
a
lot
more
visibility.
I
think
and
we're
expected
to
update
them
more
frequently
now
before
it
was
like,
maybe
once
a
month
or
at
just
at
the
end
of
the
quarter,
I'll
give
it
a
score
and
we'll
say
where
we
were
and
which
wasn't
very
transparent.
I
I
admit
yeah.
This
is
a
probably
a
shift
in
the
right
direction,
but
it's
going
to
change
how
we
think
about
okay,
ours,
a
little
bit.
C
Right
so,
while
we're
on
the
subject-
and
it's
the
last
point
of
the
agenda-
and
we
have
15
minutes
or
10
minutes,
how
is
our
how's,
our
gut,
feel
for
the
okr?
How
are
we
feeling
are
we
behind?
Are
we
on
track
not
not
technically
not
technically,
but
the
gut
feel
that
we
have
given
the
research
we've
done,
the
investigation
that
we've
seen
how
I'll
voice
my
my
position
after
you
voice
yours?
C
Are
you
asking
me
specifically
you
kai
the.
B
C
C
Do
you
have
an
opinion
spare
the
words
sky?
You
can't
speak
much.
A
A
A
When
you
want
big
efforts-
and
so
like,
I
think,
that's
okay,
like
we
sort
of
we've
tested
the
like
hey,
let's
just
throw
an
okr
something
we
weren't
even
thinking
about
on
the
board
and
like
see
if
it
works
and
it
didn't,
I
don't
think
it
will
and
then
I
think
the
other
thing
that
it
does
is
it
sort
of
shows
like
how
complicated
this
area
of
the
product
is
and
how
challenging
it
is
to
get
these
performance
gains
and
so
like
when
people
you
know
we
have
engineers
who
have
worked
in
code
review
for
years,
who
can't
find
you
know
200
milliseconds
to
save
their
lives
and-
and
I
think
that's
fine-
I
think
what
people
often
think
is
they're
like.
A
Oh,
let's
just
get
more
engineers,
let's
throw
more
people
at
it
and
I
think,
like.
I
think
this
also
sort
of
helps
prove
that
this
is
like
just
a
really
complicated
area
and
it
just
takes
more
time
so
yeah,
I
don't
know,
I
don't
think
we're
gonna
hit
the
goal,
but
I'm
also
I'm
okay
with
that.
I
think
we
will
have
learned
a
lot
and
I
think
we'll
get
some
gains
out
of
it.
So.
C
Yeah
and
I'll
add
just
that,
we
even
went
further
than
our
teams
and
the
ideas
we
got
from
the
rest
of
the
team,
the
front-end
team
wider.
They
were
very
overlapping
with
the
ones
we
already
had
and
one
of
the
ones
we're
already
pursuing.
C
So
it
feels
like
if
we're
missing
something,
it's
definitely
not
obvious,
and
it's
a
lot
of
like
nitty-gritty
low-level
work
that
we
have
to
do,
but
yeah
mats.
B
Yeah,
I
think
I
mean
what
kai
was
saying.
We
basically
needed.
You
know
a
few
milestones
just
to
plan
the
work
before
we
could
really
start
on
it,
and
we
didn't
have
that
time.
So
I
feel
like
at
least
from
the
back
end
side.
Most
of
the
stuff
we
did
in
140
was
okay.
We
have
to
do
this
investigation
first
and
then
we'll
see
what
we
can
get
in
14
1
and,
like
I
was
saying,
that's
it
that's
all
we
get
like.
Hopefully
we're
going
to
be
one.
D
B
Whole
quarter
of
because
of
how
they
don't
align
so
yeah,
that's
a.
B
Little
frustrating
because
I
feel
like
there's,
probably
are
more
performance
improvements
we
can
make
and
if
we
continue
down
this
path,
I'm
sure
we'll
find
more.
But
this
quick,
we
were,
we
kind
of
had
to
do
this
balance
of
or
this
this
trade-off
of.
What
can
we
get
done
quickly
versus
let's
step
back
and
like
really
think
about
this,
and
how
what's
the
long-term,
like
approach
for
how
we
can
make
this
faster
and
we
didn't
really
have
that
luxury?
So
it's
just
okay.
We
don't
have
time
to
really
think
about
this.
B
C
Yeah
thanks,
I
think
my
position
overlaps
a
lot
with
what
both
of
you
said.
I
think
the
learnings
we
get
from
here
we're
probably
and
yeah.
This
is
what
we
were
able
to
do
in
with
tasks
that
fit
a
milestone
or
two
milestones
at
most,
but
it
might
give
us
enough
familiarity
with
the
problem
to
now
start
planning
more
long-term
projects
that
might
last
more
than
a
milestone
more
than
a
quarter,
and
I
think
the
whole
team
is
is
ramping
up
their
knowledge
and
comfort.
C
In
this
topic,
I
think
we
will
again
like,
like
I
was
saying
we
will
get
some
gains
out
of
it
and
I
think
the
gains
will
be
more
more
significant
if
we
didn't
have
the
space
to
focus
this
much
attention
on
this
problem.
C
So
I
think
it
is
very
positive
in
terms
of
a
collective
focus
on
the
whole
thing,
and
even
though
some
efforts
are
like
we've
seen
with
the
virtual
scrolling,
I
I
think
if
we
had
the
normal
cadence
of
other
topics
in
flight,
it
would
be
very
hard
to
to
even
get
where
we
are
today.
So
I
think
it's
it's
still
because,
even
though
the
code
might
not
be
a
lot,
the
exploration
and
the
experimentation
and
the
testing
do
take
a
lot
of
capacity
out
of
things.
C
But
I'm
looking
forward
to
some
ideas
that
we
have
floating
around
for
14
months.
So
I'm
again
it's
going
to
be
the
the
not
do
or
die,
but
a
very
decisive
milestone
for
us
and
I
think
we're
all
stepping
up
to
it
and
it's
going
to
be
a
fantastic
master.
So.
B
Yeah
one
other
thing
I
wanted
to
add
to
was
having
pretty
much
everyone
focused
on
this
one
goal
has
been
nice.
I
mean,
I
think
it's
let
everyone
kind
of
work
together
in
a
new
way,
which
is
great,
so
I
think
that
whether
or
not
we
meet
some
specific
number
goal,
it's
been
nice
to
have
everyone
kind
of
coalesce
around
one
goal
and
focus
in
one
area,
instead
of
kind
of
being
spread
out
a
little
bit
more.
C
Definitely
not
something
to
do
like
at
the
cost
of
all
the
other
topics,
often
because
we
do
miss
pushing
other
things
forward
like
the
reviewers.
We
know
that
there's
some
work
that
left
that
is
left
to
be
done,
so
we
do
feel
like
we
want
to
go
close,
that
gap
too
for
the
future
okay,
ours.
But
I
got
your
point
any
more
thoughts,
ideas.
A
I'll
just
say
I
shared
in
chat
that,
despite
like
an
okr,
this
quarter
performance
will
continue
to
be
a
thing
that
we
work
on
beyond
the
corner
and
beyond
the
okr.
A
C
A
Thanks
everyone
enjoy
your
weeks,
it's
good
to
have
you
back
andre.