►
From YouTube: 2023-03-01 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
Feet.
Welcome
to
the
code
review
weekly
I
am
gonna,
find
the
agenda
and
change
something
really
quick
before
Matt's,
we'll
leave
Matt's
read
only
and
then
we'll
we'll
bump,
Ben,
sorry
and.
A
Matthew
and
Andy
are
here,
I
think
Andy
came
last
week
and
introduced
himself,
so
we'll
just
make
Matthew
introduce
himself
this
time
around.
So
Matthew
you
want
to
say
hi
I,
don't
know,
tell
us
about
yourself
all.
B
Those
things
yeah,
my
name
is
Matt
Matthew
either
one
works,
I
came
from
fulfillment
utilization
I've
been
at
gitlab
just
over
three
years.
I
live
in
California,
just
North
of
San
Diego
and
I
have
four
kids.
So
life
is
crazy,
but
yeah.
It's
good
to
be
here
nice
to
meet
everyone.
A
Awesome
well
welcome
to
the
team.
Do
you
I
I
feel
like
I'm
obligated
to
ask:
do
you
have
a
strong
preference
for
Matthew
or
Matt,
because
other
Matt
I
think
has
a
preference
for
Matt
and
so
like
I,
just
need
to
know
who
we're
referencing.
D
E
A
A
Able
to
figure
awesome
well
welcome,
Matthew
and
then
Andy
as
well
for
hanging
out
and
then
Ben.
You've
got
the
first
work
related
thing
up
on
the
agenda.
F
Yeah,
so
just
to
fill
you
guys
in
a
little
bit
context,
wise,
Sarah
Waldner
had
tasked
me
with
rewriting
the
jobs
to
be
done
for
the
create
stage
and
that
sort
of
sparked
off
a
chain
of
events
that
has
now
led
to
us
rethinking
and
sort
of
realigning.
How
we
do
this
framework
called
jobs
to
be
done
across
the
whole
company.
F
Andy
and
I
are
part
of
an
okr
that
is
heading
this
up
and
luckily
you
guys
get
to
be
the
guinea
pigs,
since
we
were
already
sort
of
rewriting
create
stage
jobs
to
be
done,
we're
breaking
it
out
into
like
you
know,
team,
sort
of
workshops
and
don't
worry,
it'll
be
fun
like
we've
done
most
of
the
work
for
you,
it's
mostly
like.
F
Are
we
getting
it
right
to
the
best
of
your
knowledge
and
I'm
happy
to
answer
questions
on
it
ahead
of
time?
If
you
like,
I'm,
not
sure
when
the
invite
is
going
to
go
out,
we
have
to
make
sure
our
ducks
are
in
a
row
first,
but
yeah
Andy.
Do
you
want
to
add
anything
there.
F
G
Guess
the
general
thinking
too,
is
that
we
we
get
from
it,
what
we
need
and
we're
showing
other
groups
how
that's
done
as
opposed
to
kind
of
going
through
a
new
process
and
kind
of
seeing
if
that
fits
and
then
iterating.
On
top
of
that,
it's
going
to
be
more
like
kind
of
by
the
book
fit
into
our
git
lab
processes.
So
that's
the
gitlab
way
and
then
we
just
kind
of
share
that
out
to
the
rest
of
the
org.
So.
F
D
Don't
know
you
obviously
answered
it
already.
I
just
didn't
know
what
the
jtd
jtbd
acronym
stood
for
jobs
to
be
done.
It
might
help
me
or
anyone
watch
this
video
just
to
kind
of
briefly
explain
sort
of
the
the
framework
that
you're
referring
to
there.
So
we
can
sort
of
understand
how
you
go
about
it.
F
Sure
and
Andy
you
can
jump
in
here
if
you'd,
like
basically
job
student,
takes
the
philosophy
that
you
should
start.
F
You
know
understanding
your
product
from
your
job
performer
sort
of
point
of
view,
so
not
like
a
Persona,
not
what
you
guess
or
you
think
your
customers,
your
existing
customers,
already
do
with
your
product,
but
like
for
us
right.
What
is
a
code
reviewer?
Who
is
this
person?
What
are
they
need
to
get
done
right?
What
are
their
jobs
and
so
by
sort
of
systematically
breaking
that
out
into
different
aspects?
F
So
what
is
their
you
know,
sort
of
job
map,
what
are
their
aspirational
goals?
What
are
their
social
goals?
What
are
their
emotional
goals?
You
can
come
up
with
this
sort
of
profile
of
a
job
performer
that
then
you
can
highlight
sort
of
like
what
are
the
main
outcomes
that
this
job
performer
needs
to
do,
and
then
you
can
prioritize
those
outcomes
based
on,
so
you
can
actually
like
survey
your
constituents
and
see
like
okay
I.
Can
this
job
is?
F
G
G
So,
like
one
of
the
tasks,
might
be
I
go
and
look
at.
You
know
as
a
code,
reviewer
I
go
and
look
at
the
company's
documentation
on
how
to
code
review
like
that,
could
be
an
opportunity
to
allow
companies
to
like
import
that
documentation
and
a
quick
view
inside
the
Mr
Right
among
many
opportunities
on
in
their
workflow.
So.
D
F
I
mean
I
think
you
have
a
good
amount
of
insight
into
code
review
in
terms
of
what
it
encalculates.
Even
if
you're,
not
a
code.
Reviewer
yourself,
you
review
you
use
Mrs,
all
the
time
so
I
mean
you
are
you're
knowledgeable.
So
it's
up
to
you.
If
you
feel
like
you're
impacted
and
you
don't
want
to
participate,
that's
okay,
I'll!
Let
you
off
the
hook
because
I
know
you're
busy.
Let
me
in
the
end
we'll
invite
you
anyway,
and
you
can
you
can
make
up
your
mind.
A
Yeah
I
know
like
these.
Some
of
the
original
Genesis
of
this
was
like
a
create
stage,
job
to
be
done,
which
feels
ambitious,
given
the
scope
of
the
create
stage
at
some
times,
and
then
you
sort
of
mentioned
like
aligning
it
to
job
performers
or
feature
areas.
Is
that
like
a
shift
in
sort
of
thinking
in
general
about
this
that,
like,
instead
of
instead
of
trying
to
think
about
it
for
merge
request
or
for
create,
or
for
whatever
we're
really
thinking
about
like?
A
F
A
different
thing
right
instead
of
these
little
statements,
where
you're
trying
to
capture
everything
and
we
end
up
with
hundreds
of
them.
What
you
really
end
up
with
is
a
set
of
we
don't
know
yet
but
like
let's
say,
a
dozen
or
so
job
performer
kind
of
maps
or
canvases
right,
and
so
it's
not
going
to
be
these
hundreds
of
statements
that
try
to
cover
every
use
case.
It's
going
to
be
what
are
the
main
job
performers
for
gitlab,
and
then
you
can.
A
F
It's
related,
but
fundamentally,
jobs
to
be
done
and
personas
are
divorced
from
each
other,
because
we
don't
care
what
your
job
title
is
in
a
job
to
be
in
a
job
performer
right.
So
anybody
who
reviews
code
at
any
time,
regardless
of
their
job
title,
is
sometimes
takes
on
the
role
of
code.
Reviewer
right
does
that
make
sense,
and
so
like
a
Sasha
right
Persona
within
the
course
of
their
day,
they
might
be
a
code
reviewer.
They
might
be
a
code
author.
They
might
be
a
CO,
a
repository
maintainer.
A
Yeah
I
think
that
that
helps
they
were
both
coming
at
the
same
time,
so
they
seemed
more
related
in
just
terms
of
like
the
work
that's
happening,
but
that
sounds
like
they're,
not
necessarily
related
and
I,
like
the
idea
of
thinking
about
code
reviewers,
given
our
stage
in
particular
as
like
divorced
from
like
personas
I,
think,
that's
always
been.
A
A
challenge
of
the
merge
request
is
like
we
focus
very
heavily
on
the
that
developer
Persona
and
not
necessarily
like
all
of
the
people
who
might
be
a
code
reviewer
like
the
appsec
people
or
the
whatever
other
people
that
can
interact
with
a
merge
requests,
and
so
that
seems,
yeah,
I
I,
don't
know
it
seems
like
we
could
get
some
interesting
insights
and
really
different
ways
to
think
about
it,
which
can
help
us
and
I
think
other
stages
inside
the
merge
request.
So
cool
thanks
for
all
the
details.
E
So
Ben,
but
they're
still
there's
still
a
space
there
to
as
you're
drafting
the
jobs
to
be
done,
cars
and
everything
to
account
for
different
personas
and
so
the
the
task
so
the
job
to
be
done.
I
as
a
code,
reviewer
I
want
to
be
able
to
see
the
responses
to
my
previous
comments
on
the
on
the
review
or
I
want
to
be
able
to
see
comments
on
front-end
files,
for
example.
So
there's
still
space
to
account
for
different
kind
of
types
of
users
is
just
that.
E
F
Yeah
there's
a
part
of
the
canvas
that
that
we
call
differentiators,
and
so
some
of
that
will
live
there
right
so,
for
instance,
whether
you're
a
new
team
member
versus
an
experienced
team
member
right
that
might
bifurcate
how
that
job
gets
done
or
yeah.
If
you're
a
front-end
reviewer
versus
a
back-end
reviewer
or
write
any
number
of
things
and
those
those
are
accounted
for
and
yeah
they
have
their
place.
A
The
only
other
question
I
have
is
you
said
it's
an
okr
I
assume
for
this
quarter,
which
started
a
month
ago
am
I
right
on
my
Quarters
here.
A
So
like
eight
weeks
to
like
do
this,
how
much
of
a
time
commitment
do
you
need
from
people
on
this
call
and
or
like
Engineers
like
if
we're
planning
on
like
I,
don't
know
what
your
scope
of
like
audiences
but
like
how
much?
How
much
of
a
time
commitment
do
you
need
over
the
next
two
two
months.
F
Yeah,
this
is
actually
a
multi-quarter
okr
because
of
the
scope
of
it
is
actually
gigantic
for
you
guys,
I'm
hoping
it
won't
take
more
than
like
an
hour
of
your
time,
total
does
that
seem
reasonable.
Andy
yeah.
G
It's
basically
the
orders
of
hours
of
under
under
three
max.
F
Yeah,
it's
we're
going
to
take
a
stab
at
you
know
this
code,
reviewer
job
performer
and
ask
some
of
you
to
take
a
look
at
it
and
like
Andre
and
Matt
I'd
love
to
have
you
guys
in
there
and
also
Matthew,
both
Matt
and
Alex
and
Amy
and
Kai.
And
you
know
Thomas
if
you
want
to
jump
in
everyone's
welcome
like
the
more
eyes
on
it,
the
better.
But
you
know
it's
up
to
you
and
yeah.
C
Ben
I
left
a
note
in
there
to
suggest
that
you
get
another
tech
writer
if
at
all
possible,
trivia
point
for
you
top
20
contributors
of
the
past
year,
usually
about
five
of
them
are
Tech
writers.
F
A
All
right
number,
four
sort
of
for
Andrea
and
Phil
and
I'm
I'm,
pushing
more
than
I
normally
would
on
sort
of
getting
an
update
one,
because
it's
dragging
and
two
I've
had
a
I.
Had
a
customer
call
this
morning
where
they
were
asking
about
it,
and
so
I
was
just
top
of
mind
and
thought.
A
It
would
be
good
to
to
figure
out
what
we
need
to
do
to
sort
of
move
forward
on
the
issue
which
is
like
disabling
of
line
wrapping
and
for
those
that
don't
know,
gitlab
automatically
soft
wraps
mines.
Inside
of
the
merge
request.
What
reasons
so
any
updates
Andre.
E
E
But
this
is
where
we're
at
so
that
going
back
to
the
conclusion,
we're
kind
of
like
proposing
to
put
it
back
in
the
backlog
because
it
seems
like
we
need
to
do
a
deep
rework
of
the
layout
of
the
diffs
to
be
able
to
accommodate
what
we're
trying
to
do
again.
This
Behavior,
although
we
do
see
that
sometimes
on
code
tools,
they're,
usually
Ides
or
if
they're
not
actual
Ides
they're,
similar
so
Monaco,
for
example,
does
this
very
easy
because
they
basically
have
the
editor
experience
built
on
the
web.
E
However,
as
we're
displaying
code
and
we're
displaying
code
in
the
way
that
we've
been
doing
it
up
until
now,
that
becomes
a
little
bit
counter
nature
to
the
way
that
the
layout
works.
So
essentially,
we
want
the
layout
to
be
fluid.
E
However,
in
the
comment
there
that
I
link
there,
we
also
have
some
worries
about
the
experience.
Essentially,
our
our
file
content
can
be
interspaced
with
match
lines
with
comments
with
a
bunch
of
things
and
the
files
divs
themselves
can
be
pretty
tall,
which
introduces
some
struggles
to
try
to
scroll
horizontally
within
the
file
diff,
which
is
even
more
complicated
if
we
take
into
account
the
parallel.
So
there
are
still
a
couple
of
ux
questions
in
our
minds.
E
We
try
to
document
them
in
the
comments
recorded
a
video
explaining
what
me
and
Phil
had
been
discussing
so
for
now
it
seems
like
we
need
a
far
deeper
rework
than
we
anticipated
when
we
first
picked
up
this
issue,
and
this
issue
was
was
scoped
as
a
smallish
enough
tweak
and
we
quickly
realized.
We
need
far
better
a
far
deeper
reward.
E
Now,
if
that's
our,
if
that's
a
priority
that
we
find
in
sketching
up
a
plan
to
rework
the
layout,
we
just
don't
know
how
that
integrates
with
you
know:
restructuring
dmrs
or
refactors
in
terms
of
performance,
Round,
Table
conversations,
so
there's
there's
a
lot
of
stuff
in
there
that
we
could
probably
get
some
help
in
understanding.
First,
are
the
ux
struggles
acceptable?
E
Are
we
okay
with
that
and
then,
if
so,
and
if
you
need
to
prioritize
this,
then
we
need
to
actually
come
up
with
a
plan
to
actually
rebuild
the
layout
in
a
way
that
it
accounts
for
this
now,
adding
a
Monaco
per
diff
file
is
out
of
the
question
just
from
the
personal
performance
perspective,
which
is
also
something
we're
trying
to
balance
out
here.
There's
a
couple
of
solutions
that
we
could
do
like
detecting
the
size
of
the
screen
and
calculating
the
layout
using
JavaScript.
E
There's
a
bunch
of
things
we
can
do
we're
just
very
cognizant
of
the
performance
limitations
we
have
on
the
merger
grass
for
very
large
files
and
for
very
large
in
Mars.
We
don't
want
to
screw
up
even
more
than
we
currently
have
so
that's
kind
of
like
binding
our
hands
a
little
bit.
So
that's
kind
of
like
the
tldr,
which
isn't
very,
but
does
that
clarify
our
stance?
E
A
Yeah
I
think
to
me
it
does,
and
I
saw
that
you
tagged
Alex
and
Matthew
in
it,
so
I'm
happy
to
let
them
sort
of
review
and
and
get
feedback
I
think
from
from
a
product
perspective.
I
agree
that,
like
we
pursued
it
thinking,
it
was
trivial.
A
It
turns
out
it's
not
trivial,
then
it's
probably
not
worth
doing
it's,
probably
also
whatever
the
conclusion
ends
up
being.
We
should
just
make
that
clear
in
the
issue,
with
sort
of
like
a
good,
a
good
comment
and
potentially
like
just
close,
that
issue
sort
of
explicitly
as
something
we
won't
do
to
make
the
stance
more
clear,
I
think
it's
not
helpful
to
to
leave
that
sort
of
lingering
around
is
like
we
want
this
without
and
then
always
needing
to.
A
Like
point
back
to
that
answer
of
like
we're
not
going
to
do
this
and
here's
sort
of
all
the
reasons,
and
we
can
always
revisit
it
in
the
future
if
like
allows,
but
I,
don't
think
it's
worth.
You
know
from
that
side,
but
I'm
happy
to
let
let
the
new
ux
folks
double
their
toes
in
what
sounded
easy
and
turns
out
is
not
encoder
you
and
get
some
feedback
on
it.
E
Yeah
and
I
think
Matthew.
Your
feedback
would
be
very
useful
to
draft
that
note,
because
usually
we
have
customers
asking
for
this
and
some
of
the
times
they're,
like
every
other
tool,
does
this
and
like
yeah
vs
code.
But
if
you
look
at
other
diff
tools,
it's
not
that
common
to
have
that
flexibility
from
as
far
as
I
can
I
can
see.
But
your
feedback
on
those
ux
limitations
will
be
interesting
and
important
for
us
to
draft
up
a
note.
What
I
want
to
do
this
with
the
future
in
the
future?
E
E
A
Know
I
know
Garrett
does
it,
it
doesn't
look
like
the
other
one
does
yeah
yeah
they
do
not
so
I
think
that's
pretty
normal
and
I
know
like
Ides,
I,
think
I
think
the
challenge
for
some
users
why
we,
why
we
looked
at
it
anyways
is
the
challenge
for
some
users
is
this.
Some
language
is
naturally
make
very
long
lines,
particularly
like
I.
A
E
Understandable
request,
like
100,
we're
not
saying
that
it's
not
reasonable.
It's
just
that
yeah.
E
A
Awesome
I
appreciate
the
update.
Amy
you've
got
the
last
one
and
then
we'll
get
out
of
here.
C
So
1511
lands
on
a
weekend
and
the
lottery
was
going
to
put
that
very
busy
release
on
a
new
person.
We're
not
going
to
do
that,
so
she
who
took
14015
no
will
take
15-11..
Please
don't
kill
me
in
1511..
That's
all
I
ask
because
it's
going
to
get
busy
right
around
the
time
that
you
all
start
sending
me
stuff.
A
A
Well,
thanks:
everyone
enjoy
the
rest
of
your
week.
It's
good
to
see
you
all
and
we'll
chat
soon.