►
From YouTube: 2021-06-30 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
A
My
question
is:
do
we
want
to
do
it
again?
Did
everyone
enjoy
the
experience
enough
that
we
want
to
do
this
again
product
is?
It
is
technically
a
pilot,
and
so
we're
not
required
to
do
it.
B
B
So
we
can
keep
that
in
mind
when
you're,
when
we're
defining
the
next
one
we're
thinking
about
a
shadow
kr,
but
not
let
that
be
the
100
of
our
quarter
and
be
more
product
focused,
because
this
one
was
very
much
more
engineering
focused
having
one
more
where
everybody
is
pointing
in
the
same
direction,
but
it's
more
feature
oriented
product
oriented
might
be
worthwhile
considering,
but
I
wouldn't
yeah.
I
think
it
would
be
great.
I
actually
think
the
pros
outweigh
the
cons
from
my
perspective,
but
what
do
you
all
think.
C
Yeah
I'll
second,
that
it
it
was
nice
to
have
everyone
on
the
same
page
and
all
driving
towards
the
same
goal
that
I
really
liked,
but
yeah,
maybe
yeah.
I
don't
know
how
to
say
it
other
than
what
andre
said
just
the
yeah.
It
was
a
lot
to
to
focus
on.
I
feel
like
this
specific
one,
we're
we
kind
of
came
into
it
late
and
didn't
didn't,
have
time
to
fully
plan
and
get
get
ready
for
it.
But
I
think
that
was
just
this
specific
case.
C
D
Yeah,
I
think
I
think
it's
it's
worth
doing
doing
it
again.
D
My
what
I
was
writing
is
that
we
had
a
bunch
of
key
results
proposing
that
issue
for
q2,
so
reduce
mean
time
to
close
s1
and
s1
s2
bugs
we
had
another
car
to
deliver
on
the
monetization,
the
shared
understanding,
some
proposed
courses
for
the
team,
and
then
we
ended
up
with
just
the
performance
of
large
mmr
and
I'm
a
bit
confused
because
yeah
we
committed
ourselves
to
that
larger,
mr,
but
I
don't
know-
and-
and
this
is
something
that
I
had
maybe
I
should
have
followed
up
sooner,
but
I
don't
know
if
we
were
also
supposed
to
go
forward
with
the
other
queue
results
or
if
we're
just
focusing
on
one
thing,
I
don't
know,
what's
what
were
you?
D
What
was
your
perception
at
the
time
if
it
was
many
things
or
just
one.
B
My
perception
was
just
the
bulk
of
it
being
so
large.
It
didn't
allow
for
anything
else
to
fit
the
quarter.
We
do
have
other
okrs
from
our
team
side
like
throughput
and
training
and
all
that
stuff,
but
in
terms
of
like
engineering
deliverables,
we're
heavily
pretty
much
exclusively
focused
on
the
performance
work
and
I
think
kai
has
helped
in
giving
us
that
ability
to
focus
by
not
putting
a
lot
of
like
big
efforts
from
the
product
side,
but
we
do,
we
still
have
a
product
to
tend
to.
B
So
that's
why
I
think
it's
important
to
consider
that
for
the
future,
but
for
this
one
was
just
the
bulk
of
the
work
were
so
large
and
that
it
didn't
allow
for
anything
else.
So
that
was
my
understanding
that
that's
why
we
kind
of
like
excluded
every
other
effort
from
being
a
priority
could
be
wrong,
though,.
A
Am
I
wrong,
though?
No
I
would
agree.
I
think
I
f
and
I
felt
like
we
had
discussed
this,
but
maybe
I
guess
we
hadn't
was
that
because
the
large
mr1
was
going
to
be
so
overwhelming,
we
didn't
want
to
take
on
other
engineering
ones.
At
the
same
time,
the
shared
understanding
ones
like
the
shared
learning
ones
we
probably
could
have
fit
in.
A
A
It
sounds
like
everyone
wants
to
do
this
again,
which
is
fine.
I
I
did
not
expect
that.
So
I'm
excited.
I
guess
that
everyone
wants
to
do
it
again.
My
my
only
other
question
would
be.
A
A
B
A
Baby
yeah,
that's
an
interesting
take.
I
maybe
I
felt
like
what
we
had
to
do
when
the
quarter
started
was
like.
I
had
to
work
with
up
above
me
to
get
like
david
and
anup
to
like
rewrite
their
okrs
to
match
ours.
I
know
for
ux,
like
they
had
like
three
okrs,
that
all
seemed
to
relate
to
the
merge
requests
and
we
had
to
be
like
no
we're
not
doing
this.
You
need
to
pick
like
other
groups
to
do
these
other
things
and
we're
only
doing
this
one
and
I
think
for
engineering.
A
It
became
this
like
managing
up
thing
and
then
we
all
had
the
same
okr,
but
we
all
sort
of
were
reporting
on
it,
maybe
slightly
differently
like
upwards,
and
I
think
that
was
maybe
why
I'm
a
little
bit
worried
about
doing
something
again,
but
maybe
that
maybe
you're
right,
maybe
it's
because
it
was
top
down
and
bottoms
up
that
it
was
just
like
in
the
middle.
It
got
messy.
B
Having
said
that,
guy,
given
our
visibility
and
maturity,
I
think
all
okrs
of
ours
will
have
a
high
visibility,
but
yeah
we
can
learn.
We
can
totally
learn
from
what
we
just
had
and
try
to
avoid
the
mistakes
and
use
that
learning.
So
that's
why
I
was
proposing.
Maybe
we
can
have
an
issue
to
capture
the
pros
and
cons
like
have
a
sort
of
an
early
retro
of
the
okr.
B
I
think
maybe
the
okra
itself.
When
we
have
openly
connected
we
can
it
can
act
as
a
retro,
but
maybe
to
keep
it
not
less
noisy.
We
can
have
a
separate
issue
for
a
retro
and
we
can
dump
our
pros
and
cons
that
we
can
let
that
educate
the
following
one,
but
yeah
I'll
be
up
to
try
it
again.
C
And
I
think
part
of
the
management
issue
was
that
we
were
also
switching
to
a
new
tool
to
manage
okrs
which
changed
the
visibility
made
it
made.
Things
seem
more
visible
because
now,
like
from
my
stance
like
christopher,
had
an
okr
and
tim
and
darva
and
like
the
stuff
that
I
was
doing,
was
all
feeding
into
there.
So
if
I
wasn't
updating
it
regularly,
they
were
noticing
which
didn't
happen
when
we
were
using
gitlab
issues,
because
they
just
weren't
checking
not
just.
C
Right,
yeah
yeah
exactly,
I
think,
but
I
think
that
was
a
thing
that
compounded
the
problem
a
little
bit,
that
we
were
trying
to
switch
to
this
new
tool
ally
in
the
middle
of
this
new
process
around
shared
okrs
and
this
high
visibility
okr.
I
think
they
all
kind
of
fed
into
the
same
series
of
problems
or
perceived
problems
where
it
was
a
lot
of
people
were,
were
paying
attention
or
more
attention.
Maybe.
D
So
we're
going
to
suffer
from
that,
and
I
agree
that
that
was
an
impact
for
the
previous
for
the
current
okrs
that
we're
still
the
okr
that
we're
working
on.
I
I'm
not
sure
like
if,
if
we're
supposed
to
focus
on
those
three
guiding
themes,
application
security,
testing,
adoption
through
usability
and
sas
first,
the
only
one
that
clearly,
I
think
aligns
with
this
group-
is
adoption
through
usability
and
yeah.
I'm.
D
As
I
already
wrote
in
a
couple
of
other
issues,
I'm
inclined
to
believe
that
the
performance
work
will
need
to
continue.
So
that's
the
biggest
thing
we
can
do
for
usability
right
now,
but
yeah
happy
to
to
talk
in
the
issue.
But
my
initial
reaction
is
that
I
would
be
okay
if
we
just
continue
doing
what
we're
doing,
maybe
with
even
more
ambitious
goals.
But
I
don't
know.
B
But
I
think
that's
an
important
topic
and
we
can
discuss
more
in
depth
in
the
issue
or
epic.
What
we've
been
feeling
is
like
there's,
a
lot
of
conversation
we've
been
having,
including
in
our
front-end
team,
with
thomas
and
phil,
and
everyone
like
some
efforts
will
require
more
than
a
quarter
and
they'll
better
attract
in
something
else
like
working
group
or
something
rather
than
a
quarter,
focused
effort.
So
they
can
still
go
on
parallel
to
the
okrs,
but
we
can
chat
more
in
the
so
that
we
don't
derail
the
conversation
here.
A
A
You
can
say
I
think
I
think
everyone
wants
to
do
this.
I
will
open
another
issue
in
the
create
project,
so
we
can
hash
it
out
again
and
try
and
come
up
with
some
ideas
and
and
get
it
going
now.
Thanks
for
checking,
though
that
was
that
was
nice
yeah.
B
Cool
you've
got
the
next
one
andre
I
do.
I
do
indeed
so
just
wanted
to
raise
it
up
here
as
well.
Some
of
you
already
saw
this
because
I
shared,
I
think
it's
a
bit
of
an
update
on
the
performance
of
kr,
the
one
we're
just
talking
about
the
quarter.
Two
me
and
matt
posted
a
lengthy
update,
stating
the
current
state
of
things
on
the
front
and
back
ends,
and
then
tommy
also
shared
a
bit
there.
B
I
hope
to
have
git
lab
or
git
lab
sorry,
gitlab
or
git
lab
project,
with
virtual
scrolling
enabled
and
we'll
be
able
to
gather
some
feedback
and
hopefully
we'll
get
to
enable
it
for
all
projects
very
soon,
but
we're
waiting
for
that
feedback
also
memory
work
ongoing,
but
no
findings
yet,
but
yeah
we're
we're
anxious
to
turn
it
on
to
see
how
people
react
to
it
because
more
than
just
the
metrics,
the
people
have
been
working
with
it.
I
don't
know
peter
you've
been
trying
it
as
well.
B
Please
correct
me
if
I'm
wrong,
the
page
feels
lighter
like
the
overall
feeling
when
you're
interacting
with
the
page
is
that
the
page
itself
feels
lighter.
Moreover,
it's
faster,
it
does
have
some
rendering
issues
that
we're
still
addressing
with
memory
improvements,
but
yeah
we're
very
excited
to
turn
this
on
yeah
matt.
You
have
something
to
add.
C
Yep
just
add
not
quite
as
exciting,
but
we're
adding
from
the
back
end
we're
adding
caching
things
for
14.1,
that's
kind
of
our
focus
right
now.
I
think
we
have
four
issues
that
three
different
people
are
working
on
in
fourteen
one,
one's
already
in
review,
the
other
ones
are
started
so
we're
making
progress
from
that
front
too.
It's
on
what
andre
and
I
talked
about
is
it's
it's
hard
to
to
really
understand
or
know
what
the
impact
is
of
those
caching
improvements.
C
C
B
And
it
kind
of
yeah
go
ahead.
There
are
three
two
aspects:
one
is
before
running
the
test.
They
always
visit
one
page,
the
explorer
to
catch
up
the
assets
and
images
and
all
that
stuff,
and
then
they
have
like
at
least
two
runs.
I
I'm
not
sure
if
the
caching
from
one
one
will
affect
the
other
tommy.
If
you
know
let
us
know,
but
yeah.
B
There
is
some
overlapping
between
the
caching,
but
more
than
anything,
users
will
feel
it,
even
if
the
metrics
don't
and
then
we'll
play
catch
up
there.
I'd
rather
have
that
than
the
other
way
around.
A
E
A
So
something
to
think
about
if
the
test
don't
come
back
that
way.
B
Yep,
that's
that's
kind
of
it.
Can
I
move
on
to
the
next
point
or
somebody
has
any
questions
on
that.
D
Yeah,
I
was
just
gonna
say
that
yeah.
I
agree
that
with
virtual
scrolling,
it
feels
like
the
page
load
feels
faster
and
when
you're
scrolling
the
first
few
files,
it's
it's
faster,
so
that
that's
that's
already
amazing
by
itself
and
it's
a
great
improvement
and,
as
you
said
like
to
me
when
I
was
testing
it,
it
was
mostly
hitting
on
what
I
believe
are
still
our
existing
problems.
With
memory
and
yeah,
I
mean.
D
That
to
to
other
things
that
we
haven't
addressed
yet,
but
the
virtual
scrolling
is
it's
pretty
good.
One
question
that
I
have
that
I
haven't
looked
into
yet
is
the
the
browser
find
function
and
it
seems
like
we
are
looking
to,
as
you
said,
enable
it
on
select
projects
on
gitlab.com
and
see
what
people
think
about
it
but
I'll?
D
B
So
my
current
thoughts
is
yes
we're
going
to
be
using
the
feedback
to
see
if
it's
something
that
it's
noticeable
and
it's
by
users
and
we'll
go
from
there.
The
second
is
there's
a
couple
of
ways
forward
on
that
front.
One
is
we
can
try
to
detect
that
they've
done
that
and
we
disable
virtus
calling.
Then
that's
one
way.
The
other
is
to
offer
our
own
implementation
of
that
feature,
which
is
a
bit
more
involved,
but
can
be
done.
B
So
that's
one
of
the
things
we
we
have,
because
once
we
have
the
information
on
the
state,
we
can
have
the
front
and
do
that
search.
Of
course,
this
will
be
disruptive.
It
won't
be
the
same
functionality
that
people
are
used
in
other
websites.
Just
like
the
experience
on
google
reader
or
google
reader,
google
docs
yeah,
I
miss
google
reader.
So
that's
the
way
that
we
can
go
forward
is
with
our
own
implementation
or
just
disabling
virtual
scrolling.
B
When
we
detect
that
the
user
is
trying
to
search
something,
not
all
cases
will
be
detectable
mobile
phones,
mobile
devices
won't
be
allowed.
We
won't
be
able
to
detect
that
it
was
done
or
using
the
ui,
but
if
they
use
control,
f
or
command
f,
we
can
try
to
kind
of
hijack
that
a
little
bit
and
detect
it,
and
then
we
disable
the
virtual
scrolling.
It
will
cause
some
sluggishness,
then
that's
one
workaround
that
we
have
theorized.
B
We've
never
implemented
it,
but
it
all
boils
down
to
whether
this
is
even
a
pain
or
not
and
again,
like
kai
mentioned
before
we
already
have
such
as
you
type
on
the
file
names.
We
just
don't
have
it
on
the
code
or
notes.
So
that's
probably
one
of
the
gaps
we
might
have
to
plug
later
yeah.
It's
still
on
our
minds.
That's
the
bottom
line.
D
Yeah
yeah,
I
yeah,
I
wonder,
and
I
I
think
that's
fair-
that
we
experiment
this
initially
on
some
projects
on
gitlab.com
to
see
what
people
feel
and
maybe
some
people
complain.
Some
maybe
others
won't
complain
I
yeah
without
trying
to
get
too
much
into
the
what-if
territory.
I
wonder
if
users
will.
D
Understand
that
it's
missing
or
that
it's
not
working
correctly,
because
you
can
use
the
find
function,
but
it
might
not
return
any
results,
and
so
you're
left
thinking.
Okay,
so
either
it's
not
working
or
it
didn't
find
anything,
and
so
because
this
is
a
very
under
the
surface
improvement
like
people
don't
know
that
we
are
now
using
virtual
scrolling
they're
not
going
to
look
into
the
files
one
by
one
to
see.
Oh
actually,
the
browser
find
function
is
not
working
correctly
right,
so
it
might.
B
You
have
a
point,
it's
kind
of
like
the
problem
is
that
it's
a
silent
failure
right
it
it's
unnoticeable,
yeah
yeah.
I
have
to
give
you
something.
B
B
D
Tests
would
it
be
reasonable
or
small
efforts
to
track
how
often
people
use
the
browser
find
function.
B
D
B
Cool
so
I'll
move
on
for
the
sake
of
time.
Next
one
I
have
six
minutes
I'll,
be
brief.
They
were
starting
the
conversation
about
the
merger,
crest,
widget
implementation,
alignment
and
kind
of
my
biggest
question.
I'm
starting
to
highlight
this
to
my
peers
and
my
front
end
engineering
managers
and
I
wanted
to
check
if
we
do
need
ux
support.
Are
we
able
to
provide
that
support
before
the
end
of
the
quarter,
peter
or
not,
or
is
that
going
to
marcel
or
someone.
D
Yes,
york
support
is
more
than
possible.
I'm
here
talking
more
of
the
product
design
front.
I
don't
want
to
speak
on
amy's
behalf,
because
I
know
she
she
has
a
lot
of
work,
but
in
terms
of
ux
product
design,
support
which
I
think
will
be
the
the
major
part
in
terms
of
support
for
this
implementation.
There's
a
lot
of
support.
D
We
have
jeremy
elder
staff
product
designer
from
the
ux
foundations
team,
he's
leading
the
visual
design,
so
he
will
be
able
to
support
with
that
and
we
have
tim
noah
a
product
designer
who
is
leading
and
facilitating
and
structuring
this
whole
initiative
so
and
I'm
there
to
give
more
feedback.
But
these
two
folks
are
the
main
points
of
content.
B
Perfect
that
works.
I
can
answer
that
question.
If
they
have
it,
the
other
part
is
yeah.
We
think
about
a
way
that
we
won't
be
able
to
do.
We
won't
do
won't,
be
doing
the
coding,
but
we'll
be
involved
in
the
approval
part
of
the
engineering
side
and
I'm
I'm.
I
wanted
to
get
like
a
quick
sense.
Do
you
think
this
effort
would
justify
a
working
group
or
is
not
not
even
what
do
you.
B
B
To
be
honest,
I'm
thinking
about
it,
but
I'm
not
sure
if
you'll
be
overkill
or
not,
but
it
has
been
successful
in
the
past
we're
trying
to
sink
multiple
siloed
groups.
It
has
been
useful
and
successful,
but
it
does
come
with
a
bit
of
an
overhead.
We
have
to
have
a
sponsor
up
ahead
up
above
so
I'll.
Give
it
some
thoughts
next
week
I'll
be
putting
some
proposals
together
and
sharing
it
on
the
epic
on
the
issue
we
created
our
epic,
so
the
the
just.
D
B
Yes
in
both,
so
basically
it's
not
it's
extending
the
current
component
of
the
extension
to
one
align
better
with
the
ui
and
second
fill
in
missing
features
that
their
extensions
might
require.
So,
for
example,
the
secure
widget
or
the
license
widget
might
require
some
features
that
the
component
doesn't
still
support.
B
They
will.
They
will
have
to
rewrite
their
extensions
from
their
own
code
to
leverage
the
extension
component
that
we
created,
so
it's
it's
not
just
using
as
importing
or
something
there
would
have
to
be
a
summary
right
there.
That's
why
I'm
starting
the
conversations
early
so
that
they
might
factor
that
into
priorities
in
the
quarter?
Three
so
yeah.
E
One
caution:
I
would
give
you
andre,
based
on
past
burns,
I
have
on
my
arms
from
the
last
couple
of
milestones.
Changing
text
breaks
tests,
yes,
plan
on
that;
okay,.
B
F
Yeah,
so
I'm
not
sure
if
everyone
is
aware,
while
you
are
mostly
doing
performance
improvements,
we
are
kind
of
split.
We
do
try
to
test
the
performance
increases,
but
also
we
are
trying
to
edit
our
tests
in
a
way
where
we
can
also
have
a
new
pipeline
which
tests
most
or
like
specific
tests
that
we
normally
do.
F
End-To-End
tests
for
merge
requests,
but
instead
of
normal
or
merge
requests
that
we
like
create
with
one
single
file
or
two.
We
try
to
do
it
with
a
large,
mr,
so
that
we
can
catch
major
things
which
just
break
when
we
use
memoirs
that
are
around
the
size
that
you
are
currently
using
to
test
against.
So
what
we
did
is-
or
at
least
I
currently
am
added
to
add
a
new
mr
that
is
manually
created
mostly
because
the
project
that
you
are
currently
using
would
be
like
a
gigabyte
or
something
as
an
export.
F
F
I
think
someone
would
complain
yeah,
so
I
had
to
like
trim
it
down
to
just
a
187
files
that
they
were
changed
that
were
changed
in
amr
and
I
kind
of
tried
to
manually
add
the
discussions
with
was,
which
was
a
pain
trying
to
copy
paste
the
text
every
single
time
about
after
the
seventh
file
it
just
was
like
slow,
slow,
slow,
slow,
but
yeah.
I
I
guess
that's
the
thing.
That's
currently
being
worked
on
so
yeah.
F
Currently
what
we
hope
to
have
in
like
a
week
or
two
is
we
have
a
new
pipeline
which
just
is
called
like
large
setup,
and
it
would
run
a
few
tests.
Currently
it's
one
test,
which
is
reverting
a
merge
request
that
the
clue
is
like
merging
it
and
then
trying
to
revert
the
whole
merge
request
back
and
yeah.
So
it's
more
on
the
side
of
like
merging,
commenting
and
stuff
like
that,
so
yeah.
That
would
be
it
from
my
side.
B
Cool
thanks.
I
I
did
pingu
matt
and
kai
on
that,
mr
that
tommy
prepared
all
good
from
our
side
from
the
back
end.
I'm
not
sure
if
that
affects
or
not
having
a
smaller
project,
but
it
does
look
like.
We
even
have
some
improvements
there,
where
it's
an
unmerged,
mr
and
we
haven't
resolved
discussions
that
we
didn't
have
in
the
previous
one.
So
that's
good
to
test
as
well
good
job
tommy.
Thanks
for
the
update
thanks,
tommy.
A
I
think
we're
at
time
so
good
to
see
everyone
enjoy
the
rest
of
your
day.
Your
week
enjoy
the
time
off
for
everyone,
who's
got
something
coming
up:
bye,
bye,
bye,
everyone
see
ya,
bye,.