►
From YouTube: Create:Code Review Weekly Sync - 2021-02-24
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
All
right,
I
have
the
first
points
I
mean
the
first
two,
the
first
one
is
read
only
thanks
kai
for
for
looking
into
it.
It's
a
meant
as
a
food
for
thought,
and
if
anyone
wants
to
discuss
it
async
or
in
the
next
call,
I'm
I'm
open
to
that.
B
A
B
Question
like
what
do
you
think,
how
do
you
think
we're
doing
without
like
calling
us
all
out
like
how
do
you
think
we're
doing.
A
No,
I
think
I
think
we're
doing
very
well.
I
think
I
mean
I
think,
we're
doing
very
well,
given
all
of
the
constraints
that
we
have
basically
right.
So
it's
not
like.
We
have
like
a
blank
check
to
do
everything
and
we
have
all
the
time
in
the
world
and
all
of
the
resources
and
everything,
and
so
we
don't
have
to
worry
about
anything.
A
A
I
mean
if,
if
we,
let's
imagine
that
we
like
hit
the
reset
button
and
all
of
the
people
that
are
now
in
code
review,
just
came
in
and
together
for
the
first
time
and
we
could
like
start
off
with
a
blank
slate
and
no
legacy,
no
existing
issues
from
customers
and
users.
You
know
if
we
could
do
that,
it
would
be
different,
but
we
have
to
live
with
what
we
have
so
given
all
of
that,
I
think
we're
doing
very
well.
A
I
mean
I'm
really
happy
and
proud
about
what
the
team
is
doing
and
how
the
especially
how
the
team
is
behaving.
I
think
more
than
that,
because
the
the
behavior
and
the
attitude
are
really
important
to
make
sure
that
everyone
is
aligned
and
knows
what
is
most
important,
yeah
and,
as
I
said
in
in
in
the
first
points
like
if
there's
something
specific
I'll,
be
direct
about
it
and
call
it
out,
as
I
have
done
it
in
the
past,.
C
Yeah,
a
bit
of
a
plus
one,
I
like
what
I
like
the
most
like
the
pragmatical
cohesion
and
expanding
on
that
is,
like
I,
don't
think
we're
ideology,
ideo,
ideological
and
pure
purely
ideological.
C
I've
seen
you
back
up
for
kai
I've,
seen
michelle
back
up
for
me
and
I've
seen
all
of
that
in
all
directions
and
that
because,
for
example,
we
have
so
much
feature
work
that
if
kai
could
not
allow
any
technical
debt
to
to
be
done,
and
we
have
space
for
that
and
vice
versa.
We
could
do
100
technical
that
work
on
each
milestone,
there's
a
much
more
mutual
respect
going
there
in
both
directions.
C
That
speaks
about
the
results
that
we're
shipping
and
even
though
we're
getting,
we
always
get
negative
pushback,
that's
part
of
being
in
a
lovable
product
category,
but
we're
we're.
We've
been
dealing
with
this
for
a
while,
and
I
michelle
said
it
best
one
a
couple
days
ago.
This
is
not
our
first
rodeo
like
we've,
we've
been
through
some
things,
and
it's
not
that
we're
not
listening.
We
are.
We
know
how
to
deal
with
that
with
that
feedback
and
push
for
the
sake
of
the
users,
always
with
them
in
mind.
B
B
A
All
right,
yeah
on
to
my
next
point
about
ownership
model
yeah,
it's
it's
a
really
long
thing
that
I
wrote
there,
but
basically
it's
about
having
in
the
ownership
of
the
merge
requests,
feature
and
experience
documented
somewhere,
because
the
way
I
see
it-
and
I
gave
some
examples-
there
is
that
there
are
so
many
groups
that
touch
on
merge
requests,
and
I
don't
know
it
seems
to
me
that
it's,
if
not
the
the
best
example,
one
of
the
best
examples
in
the
product
of
stages,
overlapping
and-
and
we
already
talked
about
this-
we
we
suffer
from
the
homepage
syndrome,
right
where
every
department
in
the
company
wants
one
image
in
the
carousel,
and
we
suffer
from
that.
A
A
This
is
how
we
work,
and
this
is
what
we
like
the
kinds
of
changes
that
we
gate
and
that
we
oversee-
and
these
are
the
other
kinds
of
changes
that,
although
they're
inside
of
merge,
requests
they're
we're
just
here
to
support
you
and
you
can
do
whatever
you
want
more
or
less.
You
know.
I
don't
know
if
my
point
came
across.
Let
me
know
if
this
is
too
confusing.
D
I
think
I
understand
what
you're
saying,
because
we
just
recently
talked
about
this
same
thing,
the
page,
so
I
got.
I
think
I
understand
what
you're
saying,
however,
that
doesn't
align
with
the
page
that
you
link,
if
I'm
understanding
you
correctly,
the
page
that
you
linked
is
for
like
our
satellite
services
that
are
super
confusing,
but
we
did
talk
about
this
before
wanting
to
define
ownership.
I
linked
to
our
backend
key
result
here,
where
I've
assigned
cary
as
kind
of
the
dri
and
the
kind
of
outcome
that
I'm
expecting
to
happen.
D
For
example,
two
issues
came
in
yesterday
that
have
been
open
for
a
little
while,
and
I
have
to
have
a
talk
with
the
ci
team
just
to
understand
who's
working
on
this
issue.
Does
it
belong
with
you?
Does
it
belong
with
us
and
that's
just
kind
of
silly
that
we
don't
know
our
own
ownership
versus
their
ownership,
and
so
collaboration
is
definitely
welcome
on
that.
I
think
it's
a
great
place
to
start
to
just
kind
of
say,
like
here's,
what
code
review
is
responsible
for
here's?
D
What
we
can
help
you
with
here's,
what
we
expect
other
groups
to
do
my
example
is
with
ci.
But,
like
you
said,
it's
a
it's
a
lot
of
groups.
It's
it's
a
lot
of
groups
so
definitely
free
to
engage,
but
I
don't
have
that
anywhere.
I
don't
know
if
we
even
have
our
ownership
or
what
we're,
what
our
expectations
are
defined
anyway,.
C
I
feel
like
we
should
open
an
issue
and
start
discussing
that
asynchronously,
because
we're
going
to
have
to
do
some
research
where
we'll
be
the
right
place.
We
do
have
domain
experts
on
the
code
on
the
code
side
that
encourages
reviews
by
the
main
experts.
Every
time
you
touch
certain
parts,
I
don't
think
that's
being
super
respected,
so
we
definitely
need
a
stronger
ownership
message
there.
So
I
agree
we
should
document
that
somewhere,
but
I
know
exactly
where.
B
Is
where
we
should
document
it,
because
it's,
I
think
to
pedro's
point.
This
is
more
philosophical
than
tactically
engineering.
I
think
right,
like
one
of
the
things
that
we've
discussed
is
how
do
we?
B
Half
the
op
side
of
the
company
about
the
merge
request
page,
because
this
is
where
they
all
integrate
and
like
how
do
we
make
sure
that
we
establish
some
kind
of
process
that,
like
we're
informed
when
we
need
to
be
and
consulted
when
we
need
to
be,
or
things
happen
when
we
don't
need
to
know
about
them
without
creating
like
roadblocks,
for
these
other
groups,
like
you
know,
how
do
we
make
sure
that
the
experience
of
the
ones
that
you
know,
pedro
added,
like
testing
group,
wants
to
add
code
quality?
B
You
know
how
do
we?
How
do
we
be
involved
in
that
in
an
early
enough
place
that,
like
they
don't
start
down
that
path?
And
then
we
sort
of
roadblock
it
later
or
it
causes
some
other
problem,
because
we
were
six
milestones
into
refactoring
the
way
diffs
work,
and
then
we
break
their
code
quality
two
days
before
release
those
kinds
of
things
I
think,
are
the
things
that
we
want
to
make
sure
that
we
do.
B
But
I
don't
know
where
direction
pages
don't
feel
like
the
right
place
to
do
that
and
product
doesn't
have.
I
mean
product
has
some
handbook
pages,
but
I
don't
know
if
they
speak
to
this.
I
guess
we
could
always
add
some,
but
there
is
an
engineering
aspect.
This
is
a
very
like
cross-functional
thing,
so
yeah
I
mean
my
question
is
sort
of
where,
where
would
we
do
this
in
a
way
that
it
would
be
part
of
the
flow
that
people
think
about
or
look
at.
D
D
Do
do
pms
or
pd's
or
tech
writers,
or
anybody
if
we
may
be
in
the
developer.
Docs.
For
example,
we
have
developer
docs
a
whole
section
on
feature
flex.
Could
we
add
a
new
merge
request,
page
there
with
process
for
working
on
this
page
things
we
expect
if
you're
on
this
page,
it
is.
Are
the
counterparts
going
to
be
checking
that
page.
B
Don't
read
dev
docs,
so
I
would
say
no,
probably
not,
but
also
I
mean
we
have
that
same
problem
with
like
product
doesn't
read
the
engineering
handbook
either
and
like
it
says
things
that
are
sometimes
contrary
to
what
the
product
handbook
says
when
when
people
do
actually
go
and
like
read
both
of
them
because
they're
all
the
handbooks
are
sort
of
done
in
isolation,
the
closest
thing
we
have
really
have
to
like
a
shared
page
is
the
product
development
flow.
B
C
Not
only
mentioned
that
kai
we
have
the
the
two
phases
approach
of
product
development,
the
discovery
and
the
build.
If
we
contribute
with
a
an
addition
to
that
first
step.
Oh,
should
I
wait.
We
could
add
a
section
to
if
you're
developing,
if
you're
starting
to
do
the.
C
What
is
the
solution,
validation
or
scoping
out
a
solution
or
a
problem
on
the
first
phase,
make
sure
you
get
in
touch
with
the
owner
of
the
area
you're
working
on.
If
it's
not
your
own
like
and
then
we
could
create
an
index
page
for
the
owners
of
those
areas,
so
to
kind
of
like
hijack
the
product
development
workflow
to
point
to
where
we
document
this,
whatever
wherever
it
is,.
D
A
I
lost
your
comments
in
the
way.
I
don't
really
understand
what
you
suggest.
C
So
product
development
workflow,
you
know
we
have
two
phases
right.
You
know
what
we
do
have
two
phases:
the.
C
A
One
yeah
well
andre,
writes
this,
so
one
thing
I
wanted
to
share
is
that
I
scheduled
some
one-on-ones
with
product
managers
and
product
designers
of
ci
release,
testing
and
secure
to
just
know
a
little
bit.
A
What
they're
thinking
about
and
kind
of
do
a
gorilla
research
with
them
to
understand
how
how
they
go
about
like
adding
things
to
the
merge
request,
experience
and
other
places
where
there's
overlap,
how
do
they
are
aware
of
things
that
other
groups
are
doing
that
might
affect
them
or
that
they
might
affect,
and
I
just
want
to
you
know-
take
the
temperature
of
this
issue
to
really
understand
what
could
be
a
good
thing
to
do
here.
A
In
terms
of
in
terms
of
having
a
process,
because
one
thing
is
communicating
and
having
it
beautifully
written
in
the
handbook
that
hey
code
review
owns
this
and
other
groups
do
that,
but
if
there's
not
a
process
of
continuous
involvement
that
fosters
collaboration
in
a
good
way,
I
mean
it's
it's
I
don't
know.
If
it's
going
to
work
because
it
hasn't,
I
don't
think
it
has
in
the
meantime
and
and
yeah.
I
had
a
question
about
what
we
had
discussed
recently
when
we
made
the
displays
of
source
code
and
code
review.
A
The
approval
rules
feature
was
in
this
limbo
and
we
thought
a
good
way
to
describe
the
relationship
that
different
groups
have
with
approval
rules
is
that
source
code
is
the
primary
owner
and
it
owns
the
structure
and
how
approval
rules
are
built
more
or
less
like
an
api,
and
then
the
other
groups
consume
that
api
and
transform
it
into
ways
that
it's
helpful
for
their
needs.
Did
we
end
up
documenting
that
somewhere.
B
We
did
we
have
a
page,
I
thought
where
we
did
some
of
the
split
or
did
we
just
have
the
issue
in
the
word
doc,
where
we
split
stuff,
I
don't
think
we
documented,
like
that
specific,
like
sort
of
anecdotal
way
of
explaining
it
to
people,
but
we
did
like,
maybe
maybe
that's
the
piece
we
didn't
document
was
like
that.
That
way,
we've
described
it.
C
A
Okay,
in
case
there
are
no
other
comments.
I
think
yeah
amazing
comments
so
far
I'll
create
an
issue
to
discuss
this
a
little
bit
more
and
to
give
some
time
for
people
to
digest
this,
and
also
to
as
a
place
for
us
to
gather
feedback
that
we
get
we
get
from
other
sources
like
kai,
was
suggesting
reaching
out
to
farnoosh
to
see
what
she
thinks
and
what
we
can
start
doing
so
getting
that
industry
might
be
a
good
place
yeah.
I
can
do
that.
I
don't
know
if
I'll
do
that
today.
D
B
B
Yeah
I
have,
I
have
looked
at
it.
I
don't
quite
understand
it
because
it
seems
like
they're
still
like
giving
us
themes
that
we
need
to
hit,
which
is
like
the
same
thing
that
happens
normally
as
they
sort
of
just
get
passed
down
from
the
themes
anyway.
So
there's
there's
an
ama
today
in
ama
tomorrow
I
will
try
and
get
to
one
of
them
just
to
sort
of
see
what
they're
thinking
about
this
process.
B
Alternatively,
I
will
just
go
open
an
issue
in
the
create
stage
project
for
us
to
discuss
this.
I
don't
want
to
do
it
in
this
massive
issue.
I
think
that
would
yeah.
So
that's.
B
C
B
C
A
B
I
think
that's
the
intent,
yes,
is
that
we
decide
as
a
group,
because
in
this
stems
from
product
product
doesn't
really
like
the
okr
process,
and
I
think
I'd
probably
say
this
to
all
of
you,
because
product
does
not
set
them
at
the
same
level
as
everyone
else.
So,
like
engineering,
you
guys
go
all
the
way
down
to
new
people.
All
of
you
go
all
the
way
down
to
like
groups.
B
It's
like
front
end
has
okrs
and
back
end
has
okrs,
but
like
I,
as
an
individual
product
manager
do
not
have
okrs
and
we
don't
set
okrs
for
the
group,
and
so
what
inevitably
happens
is
like
and
then
ux
does
the
same
thing.
They
come
sort
of
further
down
the
train.
Sometimes,
and
then
you
throw
in
staff
engineers
in
there
and
like
all
of
these
okrs
get
set
and
product
is
like
wait
a
minute.
There's
this
like
whole
long
list
on
the
product
page.
B
I
created
an
okr,
therefore
like
it
has
to
be
prioritized
because,
like
it's
an
okr
and
we
committed
to
do
things
as
part
of
the
okr
process,
so
product
has
been
vocal
about
how,
like
this
process,
doesn't
make
sense,
and
so
the
idea
is
that
I
think
if
we
come
back
and
like
do
it
as
a
group-
and
we
all
say
these
are
the
things
that
as
a
group,
we
want
to
work
on
and
have
our
key
results
then,
like
those
are
things
that
product
can
plan
for
and
understand
and
like
has
an
impact
to
influence
versus
right
now
we
are
sort
of
just
like
informed
about
everyone
else's
okrs
and
then
expected
to
like
accommodate
them
in
the
grand
scheme
of
everything
going
on.
B
So
that
is
where
this
comes
from.
I
don't
know
how
it's
going
to
play
like
going
up
the
chain,
all
the
way
back
up
to
like
sid.
I
think
sid
has
his
theme
set,
and
so
that's
why
we
have
themes,
sort
of
loosely
defined,
and
so
I
think
that's
the
intent
is
that
we
fill
in
the
bottom
and
then
it
works
sort
of
back
up
to
like
directors
and
engineering
vps
and
product
vps.
But
but
I
don't
know,
I
that's
that
that
piece
of
it
is
still
unclear
to
me.
A
Yeah
yeah,
I
don't
want
to
hijack
the
meeting
with
many
points,
but
I
was
I'm
really
happy
to
see.
Contributions
like
fills
to
address
pain
points
that
everyone
is
feeling
today
and
just
being
proactive
and
like
this
is
something
that
we
know
is
a
problem.
A
We
I
mean,
we
have
confidence
on
the
problem
and
we
have
a
certain
confidence
on
the
solution.
So
why
don't
we
go
ahead
and
just
do
this
or
fix
that?
And
I'd
like
to
see
that
more?
Basically,
because
I
think
so.
First
of
all
I
mean
everyone
is
a
ux
designer,
and
everyone
affects
the
I'm.
A
deep
believer
of
that,
especially
the
last
people
who
affect
the
user.
A
Experience
are
the
ones
that
write
the
code
and
ship
the
code,
so
engineers
have
a
deep
effect
on
what
the
experience
will
be
and,
second
of
all,
I
think
this.
A
A
Some
experiments
should
have
some
consultation.
You
know.
Sometimes
I
see
people
pushing
out
some
ideas
that
were
like.
Oh
well,
wait
we're
not
ready
for
this,
or
maybe
this
is
not
like
we're
not
sure
about
the
problem,
but
I
feel
like
when
there's
a
good
overlap
of
problem,
confidence
and
solution
confidence.
This
is
something
that
we
can
do
today.
C
Said
it
does
to
me,
I
plus
one
everything
you
just
said,
and
I
there
is
that
risk
of
us
getting
ahead
of
ourselves
but
having
a
merging
quest
to
play
around
with
it's
always
better.
Even
if
we
discard
it,
we
will
learn
something
from
it
and
from
the
recent
lessons
that
of
the
fields
work
is
that
they
all
end
up
being
in
the
product
so
because
we
have
our
we're
the
ones
working
with
these
on
daily
basis.
C
D
A
Okay-
okay,
no,
I
saw
you
were
muted,
that's,
okay,
no
one
that
I
would.
I
yeah
my
my
my
ask
here
is
how
can
we
incentivize
that
more
so
that
people
feel
comfortable
doing
it?
Because
I
think
I
mean
we
have
thomas
on
the
call
we
have
thomas
so
thomas's.
How?
How
I
think
you
too,
and
the
rest
of
the
engineering
folks
have
a
lot
of
ux
sensitivity
and
know
like
what
works
and
what
doesn't
work,
especially
because
we
use
what
we
build.
A
I
don't
want
our
road
map
and
at
least
that's
how
I
see
it
feel
free
to
disagree,
but
I
don't
want
our
roadmap
to
be
discouraging
of
people
pushing
out
some
things
that
they
think
are
a
good
overlap
of
what
I
said
like
validated
problem,
and
maybe
this
could
be
a
validated
solution.
So
how
can
we
incentivize
that
more.
C
I
think
it's
just
shipping
them
and
taking
them
and
participating
in
them
and
engaging
with
them.
There
is
one
important
aspect
to
highlight
here,
though,
is
that
phil
does
all
this,
but
it
that
this
doesn't
come
at
a
cost
of
deliverables.
C
So
it's
making
sure
that
we
have
well
planned
from
my
part
is
making
sure
that
we
have
well
planned
milestones
that
don't
end
up
with
unexpected
complexity.
That's
still
unexpected
time
from
engineers
so
that
they
have
time
to
think
and
explore
and
play
around
with
these
things.
C
D
I
agree
with
andre
there.
It's
it's
very
important
to
me
that
the
weight
budgets
that
I
give
kai
are
not
a
100
of
an
engineer's
time,
especially
because
sometimes
reviews
or
people
who
have
just
recently
become
maintainers
those
take
a
long
time.
D
So
it's
really
important
that
there
is
space
for
people
to
play
around
and
historically
it's
really
like
the
performance
issues
that
we
get
or
the
infrastructure
issues
that
we
get,
that
totally
spin
out
of
hand,
and
that's
where
you'll
see
an
engineer,
maybe
reach
out
to
kai
and
say:
can
we
schedule
this
issue
that
I
would
like
to
play
around
with
and
then,
of
course
we're
always
like?
No,
we
can't
schedule
it.
We
have
stuff
to
other
stuff,
that's
important.
We
have
so
not
you
kai,
I'm
just
saying
like
we
have
a
lot
of
stuff.
D
So
it's
just
important
for,
like
the
release
that
we
are
working
on
to
be
so
well
defined
that
there
is
time
for
thought.