►
From YouTube: 2022-04-27 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
Yeah,
so
I
wanted
to
talk
briefly.
I
know
we
have
other
things
to
talk
about
too
about
just
assigning
weights,
I've
kind
of
gotten
in
a
bad
habit
of
just
throwing
weights
on
there
without
a
lot
of
a
lot
without
much
thought.
We
do
have
a
process
documented
of
how
we
we
used
to
do
it.
I
think
that
we
haven't
been
doing
that
the
whole
time
I've
been
around,
but.
B
I
think
it
might
be
time
to
slowly
get
back
to
that
now.
I
say
that,
with
the
caveat
that
I'm
not
going
to
be
around
for
three
months,
so
I
don't
want
to
introduce
a
bunch
of
new
processes
right
before
or
any
new
processes
as
I
leave.
But
I
think
just
in
a
nutshell.
The
the
process
is
basically
in
the
milestone
before
and
assign
engineers
to
look
at
any
issues
that
don't
have
weights
and
try
to
spend
a
little
bit
of
time.
B
You
know
time
box,
so
don't
spend
a
ton
of
time
on
it,
but
spend
some
time
just
reviewing
the
the
issue
and
making
sure
it's
ready
for
development
and
assigning
a
weight
at
that
point
and
then,
when
we
get
to
the
planning
towards
the
end
of
a
milestone,
hopefully
everything
that
we're
we're
planning
on
has
weights
associated
with
it.
So
yeah,
I
don't
know
if
there's
if
we
want
to
think
about
doing
that
again,
it
takes
a
little
more
planning
up
front
than
I've
been
doing
so
yeah.
So
we'll
start
the
discussion
kai.
A
Yeah,
I
mean
yes,
I
think
this
would
be
good.
I
guess
the
question
would
be
like
how
how
do
we
do
this,
because
this
would
require
us
to
be
even
sort
of
further
ahead
in
planning
that
typically
are
and
also
have,
like,
maybe
more
predictable
work,
which
I
think
we
have
some
very
predictable
work.
I
think
it's
the
things
that
show
up
sort
of
towards
milestone,
planning
that
maybe
aren't
necessarily
clearly
weighted
and,
like
I
don't
I
guess
it's.
How
do
we
solve
for
that?
One?
Maybe.
B
Right
yeah,
I
think,
there's
always
going
to
be
those
cases
where
it's
towards
the
end
and
yeah
things
urgently
come
up
that
need
to
be
in
the
next
milestone
or
in
the
current
milestone,
even
as
that
happens
occasionally
too.
So
how
do
we?
B
How
do
we
make
sure
we
get
at
least
somewhat
accurate
weights
on
those,
and
I
don't
have
a
great
answer,
but
I
think
your
second
question
there
is
that
our
comment
is
yes,
I
think
during
the
allocation.
B
We
weren't
really
doing
this
because
we
were
just
kind
of
picking
up
whatever
the
next
security
issue
was
specifically,
so
I
didn't
have
to
really
think
about
what
the
weight
was,
but.
C
Andre
yeah
yeah,
so
last
time
I
chatted,
can
you
hear
me
yeah
so
the
last
time
I
checked,
I
think
the
editor
team
was
doing
something
where
each
week
they
would
attribute
the
nature
of
the
weekly
meeting
to
different
tasks,
and
I
think
they
they
did
something
like
on
the
third
week
or
the
fourth
week
of
every
month.
They
would
have
a
backlog
refinement
session
during
the
weekly.
C
So
I'm
not
suggesting
we
copy
the
same
thing,
but
what
that
ended
up
doing
was
that
regularly
the
team
was
gathering-
and
this
is
like
engineering
manager
in
ics.
We
got
all
up
in
a
call
and
just
to
refine
the
backlog
a
little
bit
about
the
work.
C
That's
left
to
be
scheduled,
which
goes
back
to
kai's
point,
though,
for
this
to
work
would
have
to
be
a
little
bit
ahead
of
the
planning,
which
is
not
a
bad
thing,
but
yeah
so
just
wanted
to
throw
it
out
there,
which
is
something
that
we
actually
want
to.
Consider
I'll
add
my
second
point,
which
is
on
the
front,
and
we
usually
do
this
on
the
milestone
planning
exercise,
and
I
we
double
check
with
engineers.
The
assumptions
made
on
some
of
the
issues,
which
is
bound
to
have
some
imprecision
built
into
it.
C
C
No,
no
so
the
weights,
the
weights,
we
use
them
to
put
them
on
the
milestone.
In
the
conversation
with
you
from
the
moment
that
it's
committed
to
deliverables,
we
don't
care
about
weights
anymore,
okay
right,
so
we
don't
adjust
them
from
then
on.
What
we
do
do
is
when
I'm
looking
at
the
issues
before
I
have
a
conversation
with,
you
is
I'll,
throw
an
assumption
at
it.
Yeah
helping
the
relevant
engineer
to
double
check
on
it,
which
sometimes
yeah
there's
adjustments.
Sometimes
there
is
sometimes
there
isn't
the
other
part.
C
C
We
get
around
that
by
using
a
little
bit
of
a
throttle
thing
and
different
capacities
per
engineer
when
you're
doing
the
capacity
planning
and
all
that
stuff,
but
it's
imprecise,
but
it's
a
nice
effort.
So
far.
C
B
No
at
least
not
in
the
last
six
months,
probably
I
think
we,
I
think,
even
in
talking
to
some
of
the
engineers,
I
think
we
kind
of
fell
off
that
process
even
before
I
started.
So
I
don't
think
I've
yeah
I've
done
a
kind
of
ad
hoc
on
some,
but
not
nothing,
nothing
really
formal.
A
A
While
you're
out
anyways
right
because
that's
more
either
more
work
for
andre
or
like
picking
up
one
more
thing
for
andre
picking
up
one
more
thing
well,.
C
If
anything
like,
while
it's
doubt
we
are
going
to
have
to
try
leaning
more
on
the
ics
anyway,
so
what
that
will
give
us
is
time
to
experiment
and
while
matt
is
out
I'll,
have
to
find
a
way
to
put
weights
on
issues,
and
I
won't
have
the
expertise
to
put
them
myself
so
I'll
have
to
ping
ics
to
help
me
out
on
those
weight
weighting
of
the
issues.
So
I
might
so.
C
A
B
Yeah,
that's
totally
fine
with
me,
but
yeah.
I
think
I
appreciate
you
know
trying
something
new
and
seeing
I
mean
this
is
kind
of
forcing
forcing
the
habit
a
little
bit
or
forcing
the
the
process
a
little
bit
while
I'm
out
anyway
so
appreciate
that.
Thank
you.
A
The
other
one
I'm
just
copying
up
here.
I
I
offered
this
up
in
the
ux
meeting
yesterday
and
I'll
offer
it
up
here.
If
anyone
wants
to
share
sync
feedback
on
attention
requests-
and
we
can
do
that
on
this
call
now,
if
nobody
wants
to
share
anything-
and
they
want
to
go
comment
on
the
issue,
then
this
is
my
reminder
that
that
issue
exists
and
I'm
looking
for
feedback
from
people.
So
we'll
give
it
a
moment
and
then
we
can
either
move
on
or
if
someone.
C
Wants
to
talk
we'll,
let
them
talk.
I
have
some
things
while
people
are
thinking
so
one
of
the
things
that
I've
been
telling
people
when
we've
discussed
this
in
the
past
couple
days
is,
I
personally
haven't
seen
the
feature
itself,
because
I
was
out
so
once
we're
done
with
all
the
adjustments
that
we're
doing
right
now
on
the
automations
and
the
copy
and
make
sure
that,
like
it's
simplified,
I
think
it
would
be
important
to
have
the
team
exposed
to
the
final
state
of
the
feature
before
committing
to
any
decision.
C
So
I
think
the
team
needs
to
see
the
final
product
which
potentially
there's
a
proposition
there,
that
I'm
planning
on
doing
putting
in
an
issue
which
is
to
do
a
rehearsal.
So
these
kinds
of
workflows
work
for
the
whole
team,
so
we
would
have
to
have
the
whole
team
follow
that
process
of
you
leveraging
the
attention
requests,
and
perhaps
we
can
run
a
rehearsal
for
a
whole
milestone,
see
how
that
feels
to
actually
go
through
the
code
review.
C
So
I
don't
know
thomas
if
you
have
any
thoughts
on
that,
because
that
would
that
would
give
us
a
real
world.
Feel
of
it
that's
my
first
part,
second
part
more
for
ben
and
annabelle,
I'm
not
saying
for
like
the
release
of
the
feature.
C
I
don't
think
it
would
be
a
blocker,
but
have
we
thought
of
doing
a
a
tour
of
the
feature
itself
to
users
to
want
to
import
them
onto
the
feature
like
some
of
those
things
like
it
highlights
the
feature.
So
this
is
new.
You
want
to
skip
the
tour
or
take
the
tour
and
then
take
them
through
the
bits
and
pieces
of
the
feature
itself.
D
D
I
wasn't
involved
much
in
the
design,
so
I
don't
know
if
a
tour
type
thing
was
explored.
I
will
say
personally
I
don't
like
tours.
I
think
I
always
does
anyone
really
like
them
like
they're?
They
go
to
the
app
for
the
millionth
time
and
then
they're
like
oh
now.
I
have
to
learn
this
new
workflow.
I
feel
like.
Usually
you
just
like
you
just
say
stop,
but
that
that
might
just
be
me.
D
I
don't
know
what
the
growth
team
has
been
doing
in
terms
of
like
onboarding
wizards
tours
that
kind
of
stuff
they're,
not
my
favorite,
but
that
doesn't
mean
we
shouldn't.
Do
it
just
personal
preference.
C
And
more
about
like
people
who
are
confused
having
a
way
to
hey.
What's
this
again,
which
I
guess
probably
the
popover
that
you
mentioned,
could
address
that
in
a
way,
so
it
doesn't
have
to
be
a
full-fledged
tour
if
we
just
answer
that
question
like
what
is
this
exactly
because
changing
of
habits
is
always
like
painful
thing,
so
so
people
are
going
to
have
to
adjust
to
a
new
workflow.
So
that's
always
going
to
be
a
little
bit
friction.
C
So,
okay
I'll
share
my
thoughts
in
the
issue
and
see
what
to
come
out
of
it.
Thomas.
Do
you
have
any
thoughts
on
the
rehearsal
for
a
full
boston?
Sorry,
I
don't
know
if
you're
there.
D
When
you
say
rehearsal,
I'm
sorry
can
I
just
go
back
to
what
you
were
saying
about
releasing
it
for.
C
Right
not
necessarily
wait.
A
No
we're
making
so
phil
and
I
have
been
working
on
augmenting
the
feature
flag
to
support
selectively
rolling
it
out.
It
is
not
scalable
in
any
manageable
way
because
it
has
to
be
done
on
a
per
user
basis
and
it
introduces
risks.
A
It's
I
we're
in
the
event
that
we
decide
to
proceed
with
turning
this
on
in
some
way,
shape
or
form.
It
gives
us
a
way
to
potentially
pilot
it
with
some
smaller
groups.
I
think
our
own
group
might
be
challenging
I've.
A
I've
considered
maybe
giddily
as
a
isolated
team.
Runner
is
also
a
fairly
isolated
team
groups
that,
like
have
their
own
separate
projects
that
don't
necessarily
work
in
the
main
gitlab
code
base,
are
good
internal
examples
and
then
externally
there
are
customers
who
have
asked
for
the
feature
back
since
it's
been
turned
off.
That
might
also
be
valuable
people
to
pilot
and
continue
to
like,
speak
to
and
talk
to
about
it.
So
there
is
an
option.
It
is
not
the
engineering's
not
done
and
like.
C
Yeah,
that
sounds
if
it's,
if
we
can
get
it
to
work,
I
feel
like
that's.
C
That's
a
good
way
to
run
it
like
a
rehearsal
for
a
specific
team,
because
I
was
thinking
about
even
if
we
do
it
on
our
own
team.
There's
still
a
chance
of
you
sending
your
review
to
someone
outside
of
the
team,
but
if
you
know
that
you're
running
the
rehearsal
then
you'd
know
that's
why
it's
kind
of
like
a
half
and
half
right.
It's
it's,
not
a
real
world
scenario
where
you're
experimenting
the
feature
and
you
didn't
develop
it.
So
most
of
us
have
already
have
some
exposure
to
it.
C
A
What
I
wanted
to
do
was
make
sure
that
the
team
who
has
been
around
for
a
long
time
and
has
worked
on
this
and
hypothesized
and
dealt
with
early
design
and
feedback
and
like
how
we
got
to
this,
was
given
an
opportunity
to
provide
thoughts
and
feedback
there
and
based
on
their
experiences
of
having
it
on
and
sort
of,
the
original
conversations
that
we
had,
like
you
know,
sort
of
that
kind
of
thing
I
think
for
you
and
ben.
A
D
Yeah,
I
wasn't,
I
wasn't
planning
on
adding
anything
else
to
the
issue,
just
because
I
didn't
want
to
derail
and
go
in
the
same
place
that
I
have
already
said,
but
going
forward.
You
know
today's
got
that
due
date.
Sorry,
the
issue's
got
the
due
date
of
today.
So
when
are
we
going
to
make
a
decision
on
what
to
do
is?
Are
we
still
waiting
to
figure
out
if
we
can
pilot
this
as
a
rehearsal
for
giddily,
or
when
are
we
going
to
make
some
decisions.
A
A
Yeah,
so,
on
top
of
the
feature
flag,
work,
that's
being
done,
there's
another
like
blocking
feature
issue
of
work
that
was
like
was
actually
a
hard
ux
requirement
before
we
turned
it
back
on,
which
is
the
the
toast
notifications
piece
that
work
is
not
done,
so
I
need
to
follow
up
with
phil.
He
started
it
and
then
hasn't
revisited
it,
which
is
so.
We
just
need
to
double
check.
A
So
I'm
buying
time
with
engineering
work
at
the
same
time,
for
those
that
don't
know
marcel
has
been
rebuilding
prototypes
of
both
an
original
solution
idea
that
was
never
validated
and
the
current
one.
That
is
what
is
engineered.
A
The
plan
is
to
quickly
run
those
through
some
testing
to
see
if
we
can
glean
any
additional
feedback
between
sort
of
two
proposed
paths
that
exist,
whether
or
not
they're
complete
solutions
or
go
far
enough,
isn't
necessarily
the
point.
The
point
is
more
to
understand.
Are
we
glaringly
missing
something
with
what
we've
implemented
versus
what
other
options
exist?
A
A
So
in
theory
that
will
go
off
tomorrow
friday,
and
we
should
have
data
back
fairly
quickly
by
mid
next
week,
early
next
week,
probably
based
on
how
I've
seen
user
testing
go
before
for
unmoderated
tests,
and
so
my
plan
is
to
look
at
that
in
combination
with
all
of
the
ux
feedback
that's
been
given
and
all
of
the
I
have
read
people's
feedback
in
the
issue.
A
I've
refrained,
I
think,
for
the
most
part
from
saying
anything
on
people's
feedback,
so
far,
so
sort
of
go
through
some
of
that
and
get
back
to
that
and
then
see
where
we're
at
mid
this
time
next
weekend
of
next
week
in
terms
of
what
we
think
is
the
appropriate
next
step.
D
Okay
and
then
this
is
the
small
thing
that
likely
won't
change
anything,
but
if
we
do
end
up
turning
it
on
again
for
a
small
group
of
users,
depending
on
when
that
is
phil,
and
I
have
also
been
working
on
the
sidebar
updates,
which
we're
hoping
to
release
behind
a
feature
flag
of
15.0.
So
we'll
need
to
make
sure
that
attention
requests
in
the
sidebar
still
works
and
looks
the
same.
D
B
A
Anyone
else
on
attention
request
ready
for
number
four
ready
for
number.
Four
all
right.
I
just
wanted
to
highlight
this
one,
which
is
the
forks
relationship
broken.
This
is
primarily
a
back
end
thing,
but
I
think
mark
and
patrick
are
potentially
gonna
look
at
it
matt
and
adding
it
to
your
radar
and
making
sure
we
voice
this
concern
here.
A
I
think
one
of
the
things
that
we're
going
to
need
to
do
if
well,
I
think
we've
confirmed
that
the
security
fix
is
part
of
what
has
changed
this
behavior,
and
so
we
might,
on
top
of
needing
to
figure
out
what
we're
going
to
do.
A
It
might
make
sense
to
start
getting
conversations
with
delivery
going,
because
we
have
now
back
ported
a
bug,
three
milestones
and
we
actually
can't
even
touch
the
third
one
back
in
terms
of
our
normal
back
ports
anymore.
Right
we'd
already
be
well
past
our
ability
to
get
a
fix
into
that,
and
so
we're
going
to
need
to
to
start
some
conversations
with
delivery.
And
so
I
don't
know
if
you
can
do
those
or
if
you
can
make
sure
that
whoever
picks
this
up
does.
But
we're
gonna
need
to
figure
out
what
our
options
are
for.
A
Once
we
get
a
fix,
how
we
deal
with
the
back
port
situation,
because
that
is
gonna,
be,
I
think,
a
little
bit
contentious
there
and
we're
gonna
have
cut.
I
know
we
already
have
a
tam
asking
about
where
the
back
ports
are
going
to
land
so,
like
I
know
we're
going
to
have
people
asking
where
the
back
port's
going
to
land
for
a
fix
here.
B
Okay,
yep
I'll
talk
to,
I
know,
mark
looked
into
it
a
little
bit,
but
then
he
was
traveling
most
of
the
day
yesterday
and
then
patrick
picked
it
up
and
he
started
looking
at
it.
So
yeah
we'll
try
to
figure
out
not
only
how
to
fix
it,
but
then
also
how
to
get
it
back
into
all
of
the
right
versions
that
we've
back
ported.
B
Okay
yep.
I
can
okay
drive
that
a
little
bit.
A
Yeah
thanks
yeah
that
one
that
one's
a
big
concern
and
then
I'm
gonna
stop
recording
just
because
we're
gonna
name
a
customer.
I'm
gonna
talk
about
the
last
one,
which
is
also
just
sort
of
highlighting
here.