►
From YouTube: 2021-01-06 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
So
so
yeah,
I
have
the
first
points.
Actually
this
transition
from
last
year-
and
I
want
to
preface
this
by
saying
that
I
don't
think
like
this-
is
complaining
or
do
or
pointing
fingers
at
a
specific
person.
A
But
I
just
want
to
talk
more
with
everyone
on
the
call
how
we
can
plan
better,
how
we
can
have
more
predictability,
more
ownership
by
everyone
on
the
team
and
yeah
trying
to
reduce
the
risk
and
the
amount
of
rework
that
happens
during
milestones,
and
we
started
talking
a
little
bit
about
that
in
the
last
weekly
sync
in
december,
and
I
added
some
examples
there
of
issues
that
I
could
remember
where
they
either
slipped
or
we
realized
that
we
needed
to
significantly
change
the
the
design
that
we
were
thinking
or
maybe
the
rework
that
we
had
to
do
during
the
milestone
actually
caused
us
to
make
decisions
on
top
of
our
knees
and
it
didn't
work
out
as
well
as
it
could
have
worked.
A
If
we
had
done
some
exploration
yeah,
I
wrote
a
lot
in
the
this
point
and
so
yeah.
I
think
overall,
one
thing
that
could
potentially
help
with
this
is.
A
Making
technical
research
and
evaluations
parts
of
engineers
work
and
because
my
feeling
and
again
I
I
don't
want
to
sound
unfair
and
then,
of
course,
this
is
a
generalization
and,
and
michelle
below
I'll
hand
it
off
to
you
michelle.
But
I
you
already
mentioned
that
this
is
something
that
we're
already
doing,
and
it's
difficult
for
us
to
do
that
if
we
don't
have
good
planning
or.
A
A
You
need
to
work
through
all
of
these
issues
that
are
assigned
to
you
and
when
that
milestone
finishes,
the
same
thing
happens
and
the
same
thing
happens
while
sewn
over
a
milestone,
and
I
think
this
very
big
focus
on
output,
engineering
output
and
the
number
of
merge
requests,
and
all
of
that
has
been
putting
a
lot
of
pressure
on
making
sure
that
planning
is
perfect
and
that
designs
are
perfect
and
then
the
scope
is
perfect
and
that
requirements
are
perfect
or
else
like.
A
We
only
look
at
issues
inside
of
the
milestone
and
they
can
blow
up,
which
is
what
happens
yeah.
I
think
I
more
or
less
covered
the
main
points
of
what
I
had
I'll
I'll
stop
here,
so
that
others
can
comment.
A
I
see
michelle
you,
you
commented
on
my
part,
the
part
that
I
suggested
making
more
time
and
like
making
the
the
research
and
evaluations
actually
part
of
engineers
work
and
dedicating.
I
don't
know
like
10
20
of
their
time,
just
to
do
that,
for
example,
yeah
so
go
ahead.
Michelle.
B
B
So
we
we
already
have
been
doing
this
for
a
while,
but
it's
not
as
successful
as
you
would
think,
and
that
is
probably
because
we're
our
us
as
counterparts
are
not
really
aligned.
It's
more
like
a
back
end
effort.
So
when
we
investigate
issues
in
advance,
we
don't
always
know
if
those
issues
are
actually
going
to
get
scheduled
or
you
know
a
lot
of
the
times.
B
B
C
Yeah
I'll
I'll
add
my
perspective
because
we're
the
ones
lagging
behind
a
little
bit
on
this,
so
historically
the
scoring
you're,
absolutely
right
peter
and
I'm
with
michelle.
Please
don't
apologize.
We
all
want
to
make
things
better
and
historically
we
we
have
pinged
ics
on
some
cases
that
we
feel
like
it's
useful
to
have
that
feedback,
but
it's
very
informal
and
ad
hoc.
C
So
we
have
also
been
feeling
the
lack
of
deeper
planning
before
assignment
from
our
perspective
as
well,
because
we
also
feel
it
like.
We
don't
also
don't
like
having
things
slip,
and
I
think
I
think
the
bigger
one
of
the
things
we
have
identified
is
exactly
that
lack
of
involvement
of
ics
thomas
is
on
the
call.
We've
talked
about
this
as
well.
C
One
of
the
things
that
we
also
identified
is
that
we
have
at
times
uncovered
deep
unknowns
on
how
the
app
is
working
so
from
our
site
on
the
front,
and
we
have
nominated
what
we
call
it
domain
experts
for
the
front
end
of
merge
requests,
but
I
don't
think
we
have
the
main
experts
on
the
back
end
doing
michelle
for
for
merge
requests
themselves.
C
I
took
a
look
and
it
doesn't
look
like
we
do,
because
one
of
the
one
of
the
problems
that
came
up
recently
was
we
need
to
have
a
reliable
id
for
blob
and
we
spent
we
went
through
several
back-end
until
we
got
the
proper
answer,
so
not
knowing
exactly
who
to
go
to
for
these
questions
kind
of
delays
a
little
bit,
but
that's
just
part
of
the
the
topic,
the
the
the
other
part
that
we
can
totally
start
doing
right
from
the
next
milestone
is
involving
ics
on
weighing
and
planning,
and
they
might
be
separate
or
they
might
be
together.
C
C
I
think
that
will
be
easy
enough.
What
I
worry
is
if
it's
something
that
we
don't
really
have
a
clear
direction
on
how
to
build
we're,
gonna
need
ux
feedback
and
I'm
a
big
fan
of
collaboration.
C
C
So
I
don't
know
I
don't
know
how
we
can
solve
that
without
becoming
super
staggered
like
one
milestone
for
design,
one
milestone
for
engineering,
but
as
long
as
everybody
is
always
on
the
same
boat
like
if
you
have
a
spike
on
one
milestone
to
prepare
the
concept
for
the
next
milestone,
then
everybody's
aligned.
So
that
could
be
a
way
to
do
for
the
deeper,
more
complex
tasks,
but
I'm
up
for
trying
it
right
away
from
39
honors
involving
ics.
A
Yeah,
it's
under
one,
a
four
one
yeah
that
that
I,
I
think
the
these
technical
research.
I
think
it's
what
you
said
and
that
we
don't.
We
don't
need
to
have
a
design
for
that
at
all,
because
for
me,
it's
more
about.
A
B
A
Possible
yeah
well,
that's
possible
because,
like
a
great
example
of
that
is
the
the
assignee
or
reviewer
filter
that
we
had
planned
the
reviewer
feature
as
if
this
thing
this
last
bit,
that
was
actually
really
important
to
get
right.
We
just
thought
hey.
This
is
probably
going
to
work,
because
the
only
thing
we
had
done
was
ask
david
or
someone
else
from
the
back
end:
hey.
Do
you
think
this
can
work
like
yeah?
A
I
think
so
like
there
was
nothing
that
would
say
that
it
wouldn't
work
and
david
actually
progressed
through
that
path,
and
we
only
learned
about
it
when
it
was
in
production,
but
I
don't
know,
maybe
if
we
had
known
the
boundaries
and
the
playing
fields,
when
we
started
breaking
down
the
work
for
reviewers,
it
would
be
much
easier
to
know
where
we
need
to
go
first,
what
we
needed
to
explore
more
or
less
so
I
think
it's
just
at
the
perhaps
at
the
epic
level,
define
the
boundaries
of
what
we
can
do
in
the
short
term.
A
What
needs
more
work
in
the
mid
and
long
term
so
that
the
designs
themselves
and
again
this
is
a
very
collaborative
activity
where
anyone
can
suggest
things
that
we
can
do
to
improve
the
user
experience,
but
the
designs
would
then
kind
of
flow
and
and
inside
of
that
playing
field
and
working
with
all
of
those
constraints
that
that
are
real
constraints.
I
mean
the
technical
constraints
are
the
things
that
we
can't
really
avoid.
So
I
just
wanted
to
clarify
that
if
it
wasn't
clear.
D
Curiosity
for,
like
the
processes
that
exist
today,
where
engineers,
at
least
on
the
back
end,
do
weight
things
is
that
is
that
a
solo
effort
or
do
other
engineers
ever
talk
with
other
engineers.
B
Andre
may
have
a
different
answer,
but
probably
probably
not
the
engineers
investigate
the
issue
and
collaborate
with
others
during
that,
so
like
even
earlier,
if,
if
when
we
were
talking
about
the
design
mockups
and
things
like
that,
if
an
engineer
is
looking
at
the
issue
and
they're
like,
I
really
am
not
clear
what
the
proposal
on
this
is
part
of
their
investigation
includes
pulling
in
pedro
or
even
tech
writing
or
you
or
staff
engineers,
and
things
like
that.
So
it's
like
a
group
effort
but
you're.
The
dri
is
one
person.
D
Yeah
I
get
I
asked
thinking
that
was
the
answer,
but
in
in
the
editor
group
and
again
I'm
not
saying
this
was
perfect
one
of
the
things
that
they
did
at
least
on
the
back
end.
The
front
end
did
not
for
whatever
reason
or
hadn't
gotten
there
yet,
but
the
back
end.
D
The
issues
that
were
like
on
the
table
to
be
weighted
for
the
week
were
weighted
by
every
engineer
in
the
group.
It
was
obviously
a
much
smaller
set
of
back-end
engineers,
but
each
engineer
had
to
give
like
their
proposal
on
sort
of
like
the
number
of
mrs
that
were
required,
and
what
those
mrs
would
do
and
like
the
weight
of
the
issue
with
sort
of
all
of
those
opinions-
and
I
don't
I
don't
know
if
it
helped
or
hurt
or
if
it's
like
a
waste
of
time.
But
it's
something
that
you
know.
D
I
know
we're
doing
right
now
in
a
few
issues
that
are
going
on
where
we
have
sort
of
multiple
backend
heads
looking
at
things,
because
they
are
so
complicated
that
I
wonder
if
we
accelerate
that
to
like
put
that
in
the
planning
stage.
Instead,
where
multiple
backend
engineers
can
sort
of
be
like.
Here's,
how
I
would
approach
this
and
someone
else
can
be
like
here's,
how
I
would
approach
this
and
then
they
sort
of
find
that
middle
ground
solution
in
advance
versus
hey.
D
C
One
question
before
I
answer:
how
frequent
did
they
do?
Did
they
do
that
on
the
editor?
Do
you
know
it
was
a
weekly
thing,
bi-weekly
or
monthly,
weekly.
D
C
Refinement
backlog
refinement.
Okay,
so
my
my
feedback
is
is
going
in
that
direction,
which
is
this
one
thing
we
have
to
be
in
always
aware
is
like
for
us
to
have
better
planned
issues.
We
have
to
invest
more
time
in
the
planning
that
that
just
goes
without
saying,
and
it
will
decrease,
for
example,
the
capacity
for
each
engineer.
C
I've
had
experiences
in
teams
that
work
that
way
like
have
weekly
backlog,
refinement
exercises,
I
think,
being
weekly
makes
it
easier
because
the
load
on
each
week
is
less
than
if
you
were
doing
for
monthly,
for
example,
then
it
would
be
like
a
full
day,
because
I
personally,
I
always
take
multiple
days
of
refinement
through
issues
on
every
month,
every
time
we're
playing
a
milestone
and
we
will
refine
dozens
of
issues
that
never
get
scheduled
right,
because
we
don't
have
capacity,
they
turned
out
to
be
much
bigger
than
we
expected
or
they're,
not
ready.
C
So
there's
a
lot
of
wasteful.
Oh
no.
I
don't
like
the
word
wasteful,
but
I'll
use.
It
now
not
focus
on
this
milestone,
effort
kind
of
thing,
but
there
is
value
in
having
more
people.
Take
a
look
at
it
for
sure,
but
then
it
eats
more
time
of
the
whole
team.
So
maybe
we
can
start
by
by
imitating
what
backhand
has
been
doing,
which
is
giving
the
task
of
doing
the
planning
and
scoring
individually
promoting,
and
I
think
one
of
the
things
that
has
happened.
That's
why
michelle
doesn't
have
a
straight
answer.
C
B
If
you
are
asking
me
what
I
think
about
that,
I
have
linked
there,
my
handbook
page
and
if
you
want
to
take
a
look
at
the
handbook
page
on
what
the
process
is
and
kind
of,
if
it
needs
to
be
modified
or
anything
like
that,
and
we
can
just
discuss
it
in
the
planning
issue.
When
we.
C
A
Yeah,
I
just
wanted
to
say
one
thing,
really
quick
thomas
and
then
I'll
hand
it
over
to
you.
I
just
wanted
to
to
say
that
I
think
today
we
put
in
when
we're
talking
about
iteration
and
learning
and
improving
in
the
next
iteration
and
learning,
and
doing
all
of
that
I
think
we're
putting
too
much
focus
on
the
outputs
and
the
doing,
and
not
so
much
on
the
planning
and
preparation,
and
I
think
that,
even
if,
even
if
waiting
something
and
researching
something
that
maybe
we
then
realize.
A
Oh,
it's
not
going
to
work
or
we
have
to
break
this
differently
or
we
have
to
approach
this.
Maybe
six
months
from
now.
I
think
that's
better
than
what
we
have
today,
because
I
think
just
focusing
on
the
output
and
doing
things
without
better
planning
reduces
the
team's
morale
because
they
see
things
slipping.
There's
rework
there's
a
lot
of
other
things,
so
I
think
that
lost
effort
that
you
were
saying
there,
which
is
real
like
it.
A
E
F
F
I
wrote
something
that
I
wrote
to
darva
in
in
our
skip
level,
just
a
an
outline
of
how
I
how
I
feel
this
should
go,
and
it's
actually
a
three
milestone
in
advance
process,
where
three
three
in
advance
of
what
we're
planning
for
that's
where
we
start
talking
about,
like
maybe
ems
talk
about,
where
what
is
can
be
done
and
then
two
milestones
in
advance,
engineering
and
design
are
working
together
to
decide
if
we
can
even
do
what
they
want
to
do
with
something
because
a
lot
of
times.
F
What
I
find
is
we
get
into
something
and
turns
out
that
it's
not
even
possible.
We
need
to
like
do
a
bunch
of
like
work
to
get
to
where
we
want
to
be,
and
then
one
milestone.
Advance
is
kind
of
what
like
michelle's
talking
about,
where
we
like
weight
issues
and
we
go
and
find
out
like
who
knows
what
something
needs
that
kind
of
stuff
engineers
would
do
that
kind
of
stuff.
We
don't
have
to
go
over
the
whole
thing,
but
that's
the
process
that
I
was
imagining
when
I
was
talking
with
dharma.
C
Yeah,
it
definitely
does,
I
think,
the
when
I'm
looking
at
new
process.
I
always
try
to
look
for
the
negative
impact
of
it.
So
don't
take
it
as
a
criticism.
It's
more
like,
I
think,
for
certain
kind
of
work.
This
completely
applies,
but
it
comes
with
a
with
with
less
agility
like
it
would
take
us
longer
to
react
to
things
so
definitely
work
will
fit
this
kind
of
like
three
milestone
rhythm.
Others
will
be
just
reacting
like
a
bug
fix
or
just
improving
or
iterating
on
a
feature.
C
D
B
B
Page
in
the
call,
but
the
three
milestones
in
advance
with
the
em
working
with
product
and
design
is
very
interesting
promise,
and
I
would
just
let
you
know
that
the
back
end
engineer
process
where
we
wait
things
two
weeks
in
advance,
started
with
an
issue
in
the
create
stage
issue
tracker
where
they
listed
the
proposal,
barriers,
risks
pros
and
cons,
and
I
will
leave
it
at
that.
But
that
is
quite
interesting
because
at
any
time
I
should
in
theory
know
what's
happening,
three
milestones
in
advance:
that's
pretty
cool.
B
C
A
Yeah
yeah,
it's
really
quick
and-
and
I
think
michelle
already
answered
it,
but
in
case
anyone
also
wants
to
contribute
yeah.
I
was
just
wondering
if
there
are
any
iteration
retrospectives
that
we
should
do
michelle
shared
three
that
we
have
open
at
the
moment.
Multi-Line
comments,
reviewers
and
highlighting
collapse.
Diffs
yeah,
any
other
iteration
respects
that
we
should.
I
mean,
having
three
open
is
already
a
lot.
A
But
yeah
just
wondering
if
anyone
wants
to
contribute
to
this
one,
if
not,
we
can
move
to
the
next
point.
B
I
think
we
have
our
hands
full
and
we're
not
getting
as
much
engagement
as
I
think
we
need
to
take
action,
but
if
we
want
to
know
what
iteration
retrospectives,
we
should
do.
Probably
all
five
that
you
listed
above
about
you
know
outdated
div.
B
C
So
a
question
to
you:
michelle
do
you
think,
and
I
agree
with
the
lack
of
engagement
and
I've
been
pushing,
but
the
lack
of
a
deadline.
Kind
of
you
were
all
engineers,
so
we
work
with
headlines.
Do
you
think
having
a
like
open
the
issue
set
a
deadline
for
a
week
after
that
and
then
have
a
sink
call?
I
know
that
we
were
avoiding
sink
calls,
but
I
don't
know
having
something
that
would
push
people
to
participate.
C
B
C
B
I
was
also
kind
of
thinking
when
we
assign
these
issues.
Maybe
we
create
a
placeholder
iteration
retrospective
for
it
already.
I
don't
know
so
that
as
they're
as
they're
going
through
the
issue,
for
example,
reviewers
was
going
super
smoothly
until
like
week,
three
and
at
week
three,
it
might
have
been
easy
for
somebody
to
just
pop
into
another
issue
and
say
this
happened
today
and
then
pop
right
back
out.
D
I
would
I
would-
and
I
I
say
this
in
the
nicest
of
ways
the
fact
that
there
are
five
open
leads
me
to
believe
that
we
haven't
learned
from
any
previous
ones,
which
is
again
not
not
a
blame
thing,
but
I'm
wondering
if,
like
these
are
just
not
an
effective
tool
like
in
terms
of
trying
to
extract
learnings
like
if
maybe
they're,
not
useful,
to
people,
because
people
don't
provide
the
thing
or
we've
already
sort
of
gotten
through
it
and
so
we're
beyond
it
or
if
or
if
generally,
the
problem
is
sort
of
what
we
talked
about
above,
which
is
things
aren't
playing
well
enough
in
advance.
D
We
would
have
caught
these
things,
anyways
and
sort
of
like
there's
a
there's,
a
bigger
sort
of
like
first
thing
we
need
to
solve
before
we
get
into
some
of
these.
Like
I,
I
guess
I'm
one.
Are
these
effective
and
two
like?
What
are
you
actually
trying
to
get
out
of
them
like?
What
are
we
trying
to
learn.
B
I
can
answer
that
because
I've
been
thinking
about
it
a
lot
all
week.
I
don't
know
if
they're
effective
or
not,
because
I
don't
think
we've
ever.
I
think
we've
had
one,
maybe
two
and
I
think
andre
has
had
one
and
I
had
one
separate
or
something
like
that
and,
like
I
said
when
too
much
time
passes
or
we
wait
until
the
issue
is
resolved.
B
Look
at
merge,
refs,
it's
been
several
months,
you
don't
remember
any
of
that
stuff,
and
so
it
turns
into
kind
of
what
we
have
today
with
our
regular
retrospective,
where
it's
like
yeah.
This
wasn't
a
very
productive
month.
I
don't
know
what
it
was,
I'm
just
not
feeling
into
things
you
know,
but
that's
not
actionable,
and
we
don't
know
what
that
means,
and
so
I
I
don't
think
we've
given
them
a
chance
to
see
if
they
work
or
not,
and
what
what
I'm
trying
to
learn
is
say
you
know
with
reviewers.
B
C
And
I
know
we're
at
time,
but
we
I
did
capture
the
one
that
we
had
before
I
I
can
remember
from
the
top
of
my
head.
Some
learnings
we
took
from
using
multiple
interdependent
feature
flags
that
have
been
affecting
our
decisions,
which
we
have
so
we
have
corrected
some
of
those
problems.
We
haven't
solved
them
all,
but
we
we,
some
of
them,
are
in
our
minds,
but
I
think
the
more
we
have
them,
the
more
it's
just
an
iteration
just
always
going
to
have
them.
C
C
And
we're
at
time
I
wanted
to
call
her
attention
for
point
number
four,
because
we're
gonna
have
a
call
tomorrow.
If
you
have
any
questions
about
that
topic,
please
reach
out
to
me.
I
can
clarify
on
a
one-on-one
basis
but
yeah.
That's
it!