►
From YouTube: 2021-09-08 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
Sounds
good,
so
yeah
we'll
start
with
the
weekly
engineering
allocation
update,
so
we
have
two
infra
dev
issues
left
still
one
is
much
closer.
One
was
around
adding
caching,
we
kind
of
rolled
that
all
out
slowly
over
the
past
week
and
seemed
like
it
was
working.
A
But
then
there
was
a
production
incident
that
coincidentally
happened
around
the
same
time
as
we
finally
moved
it,
so
they
flipped
it
off
right
away,
but
that
didn't
seem
to
affect
the
production
incident,
so
it
doesn't
look
like
we
had
anything
to
do
with
it.
It
was
just
we
just
had
some
bad
timing
there,
so
we're
pretty
close
on
that
one
and
then
there's
the
there's,
a
n
plus
one
issue
that
we're
still
working
on
but
making
progress.
A
So
that's
good.
The
other
one
is
that
there's
our
error
budgets
are
getting
close,
so
it's
at
99.90
trying
to
get
to
99.95,
which
at
this
rate
we
should
be
there.
I
think
kind
of
mid
next
week,
sometime,
which
will
be
good.
A
A
lot
of
that
has
to
do
with
we're
changing.
We
change
the
threshold
from
one
second
up
to
five
seconds.
So
most
of
our
requests
are
safely
within
that
five
second
threshold,
but
that's
taking
it's
gonna,
take
28
days
total
to
get
all
the
data
like
filled
into
all
the
right
buckets
and
we
have
about
10
days
left
of
that
process.
A
I
think
so
that's
why
it's
kind
of
slowly
increasing
and
then,
but
that
said,
that's
kind
of
that
five
second
threshold
is
kind
of
a
temporary
threshold,
and
the
next
step
eventually
will
be
we're.
Gonna
have
to
classify
our
endpoints
in
like
buckets
of
like
slow,
medium
fast
or
something
generic
like
that,
and
then
they'll
start
tuning
those
down.
A
So
if
we
expect
a
endpoint
should
be
fast,
they
might
change
that
to
be
like
a
one
second
threshold
instead
of
five
and
they'll.
So
they'll,
that's
not
gonna
happen
quite
yet,
but
I
suspect
that'll
happen
relatively
soon.
A
A
I
don't
know-
and
I
did
ask
darva
and
christopher-
are
working
on
kind
of
exit
criteria
for
all
of
the
groups
that
are
have
engineering
allocations
to
me.
It
seems
like
if
we
finish
our
infradeb
issues
and
our
air
budgets
are
green.
That
should
be
the
end
of
it,
but
well
we're
trying
to
actually
define
that.
So
that's
processes
ongoing
right
now,
but
there
should
be
an
update
to
the
handbook,
is
what
I
heard
coming
soon.
That
will
have
like
more
defined
exit
criteria.
A
B
I
don't
say
nitpicking
but
nitpicking
like
some
like
it
reminds
me
of
like
when
we
get
the
performance
issues
out
of
the
quality
team
and
they're
like
oh
congrats,
on
making
it
to
267
milliseconds.
The
threshold
was
250
so
like
keep
going
and
you're
like
I
mean,
there's
not
much,
we
can
do
here
right.
It
feels
a
little
bit
like
that,
and
so
I'm
wondering
like
is
that?
B
Should
we
and
it
doesn't-
I
don't
know
I've
been
watching.
It
doesn't
feel
like.
We
have
really
strong
opinions
or
ideas
on
how
to
fix
this.
So
I'm
wondering
if
this
is
one
of
those
things
where
we
should
be
like
look.
We
made
the
big
improvement
that
we
could
and
like
we'll
open
another
issue,
but
it's
like
even
less
of
a
severity
and
priority,
given
that
this
one
was
sort
of
like
a
p4s4
like
further
optimizations
feel
like
maybe
not
the
best
allocation
of
time
sure,
but
I
don't
know
yeah.
We
could.
A
A
Yeah
right,
we
we
thought
and
gary
thought
that
he
was
he
kind
of
had
a
path
forward.
So
I
was
thinking
oh
we'll
just
yeah
go.
Do
that
and
then
we'll
be
done
with
this
issue.
It
turns
out
that's
taking
a
little
bit
longer
than
expected
so
I'll
check
with
him
later
today
and
see
what
the
status
is
and
see.
A
If
it's,
if
he's
you
know
a
day
or
two
away
from
having
an
mr
that's
different
than
we
don't
know
anything
and
we're
or
it's
gonna,
be
weeks
more
work,
then
that's
a
different
discussion,
so
I'll
check
with
him
and
see
what
the
kind
of
the
next
steps
are
it
like
every
day
it
seems
like
it's
like,
oh
yep,
okay,
we
know
what
to
do
and
then
something
else
comes
up
and
it's
like,
oh,
but
we
can't
quite
do
it
that
way.
So
so
that's
why
it's
kind
of
dragging
on
but
yeah.
A
I
agree
that
if
it
we
made
some
big
improvements
in
two
areas
and
so
there's
just
kind
of
one
left
that
at
least
that
we
know
about
where
it's.
If
you
do
commenting
on
a
bunch
of
different
commits,
then
you
get
this
crazy
exploding,
n,
plus
one
error.
So
it's
I
don't
know
how
common
that
specific
use
case
is
either
but
yeah.
It
does
explode
in
that
case,
so
yeah
we,
but,
like
you
said
we
if
we
want
to
create
a
follow-on
issue,
we
could
do
that
as
well.
B
B
We
intentionally
like
don't
want
to
action
it
because,
like
using
that
engineer
to
work
on
something
like
mergeability
or
these
other
things
that
have
like
a
known
work
path
and
like
bigger
product,
and
you
know,
improvements
and
reliability
or
like
a
more
more
valuable
use
of
that
time.
And
I
think
that's
the
thing
that
I'm
concerned
that
we
might
spend
a
ton
of
time
right
for
for
very
little
gain
or
for
sort
of
an
edge
case
or
for
something
else
and
like
we
need
to
address
those
sure.
But
we
do
have
a
finite
amount
of.
B
A
No
nothing
specific
other
than
it's
in
progress
and
they're
the
infrastructure
teams
kind
of
figuring
out
how
to
do
it.
So
I
think
it's
there's
two
steps.
One
is
being
able
to
actually
do
it
and
then
it's
going
to
be
working
with
every
team
to
actually
classify,
and
so
I
don't
know
we'll
have
to
discuss
how
we,
how
we
do
that
at
that.
C
Moment
the
question
I
have
is:
how
are
we
discussing
potential
ways
to
classify
those
things,
because
some
endpoints,
just
like
we
saw
in
the
large
mr,
is
usually
it's
usually
a
percentile
conversation,
because,
like
most
of
like
98
98,
percentile
of
the
request
should
be
below
a
second
but
we're
always
going
to
have
outliers
right?
I
know
that
this
is
an
average.
I
guess
so.
C
A
Yeah,
the
air
budgets
count
would
count
those
like
one
or
two
percent
outliers
as
affecting
our
air
budget.
So
I
don't
know
if
we
just
say
like.
Oh
the
longest
ones
are
take
this
long,
but
I
don't
think
that
that's
not
really
the
spirit
of
it
right.
The
idea
would
be
so,
but
no,
I
don't
know
that
we've
really
discussed
how
we're
going
to
do
that.
Yet
I.
B
Know
I
know
a
new
has
been
trying
to
talk
with
christopher
and
eric
about
air
budgets
because
they
they
represent
both
legitimate
errors
and
aptx
scores,
which
are
not
actually
errors.
But
you
get
penalized
for
like
being
above
the
appdex
thresholds,
which
is
why
they
move
them
up
to
five
seconds,
and
so
anoop
has
been
trying
to
suggest
that
these
things
be
separated.
B
Because
is
you
should
not
be
penalized
for
things
going
slow,
this
sort
of
like
that
might
be
well
unintentioned
and
like
even
then
we
shouldn't
like,
if
you
had
to
achieve
a
hundred
percent
to
not
go
below
your
threshold,
then
like
we
basically
implemented
100
availability
budget,
which
is
like
sort
of
unreasonable
so
like
we're
we're
trying
to
figure
out
how
to
like
deal
with
those
two
things
as
being
treated
as
one
and
then
what
the
options
are
because
yeah.
I
agree.
B
A
Yeah
definitely,
and
for
our
team
yeah
that
rate
components
of
the
air
budget
we're
we
have
pretty
much
100
success
for
eight,
so
it's
it's
all
that
slow
requests,
and
it's
not
the
it's
that
aptx
slow
request
is
really
the
thing.
That's
impacting
our
error
budget,
the
most
yeah
and
part
of
the
yeah.
Five
second
thing
was
to
say:
okay:
if,
if
it's
just
slow
requests,
then
those
teams
should
be
good
for
a
while
and
then
we'll
focus
on
the
teams
that
are
still
in
that
red
category
after
after
this
full
five.
A
Second
rollout,
there
is
a-
I
put
it
in
the
I
don't
know
somewhere
I'll,
find
it,
but
there's
a
monthly
report
on
each
team's
error
budget.
We're
currently
classified
as
well
we're
still
over
budget,
but
we
suspect
that
we'll
be
within
budget
within
the
next
couple
weeks.
So
they're
not
too
worried
about
it.
There's
a
handful,
maybe
10
groups
that
are
over
budget
and
we
suspect
they
will
continue
to
be
over
budget.
So
that's
the
big
focus
right
now
is
on
those
groups.
Thank
you
for
licking
that.
A
Nope,
okay,
then
I
have
the
next
one
too.
We
had
talked
last
week
a
little
bit
about
the
mid
milestone
check-in
and
if
we
need
it
or
anything,
so
I
just
created
this
periscope
sci-sense
dashboard
that
has
the
calculation
in
it.
So
we
don't
have
to
do
any
manually
weighting
it
or
manual
calculations.
C
A
I
haven't
that
I
haven't
spent
okay
any
time
on
so
yeah
there's
probably
overlap
in
those
issues.
If
they
have
both
the
front
end,
it
only
looks
at
the
front
end
label
or
the
back
end
label
and
then
just
the
weight
total
weight
on
the
issue.
So.
C
C
A
Yeah
I
was
gonna.
I
started
to
update
the
handbook
too,
and
I
will
so
I'll
get
that
link
in
there.
It's
just
it
ran
into
a
little
confusion,
because
that
whole
section
of
our
handbook
looks
like
it
was
shared
with
the
code
or
the
source
code
team
when
probably
when
they
split,
but
now
I
don't
think
the
source
code
team
does
anything
like
this.
I
don't
know
andre.
A
A
B
A
A
That
was
the
thing
there's
a
partial
that
was
shared
between
the
code
review
group
and
the
source
code
group
like
their
main
pages,
so
I
might
have
to
update
that
a
little
bit,
but
it
doesn't
look
like
source
code's
using
it
anymore.
So
I
can
just
that's
the
only
thing
that
slowed
it
down
a
little
bit.
D
How
much
time
yeah
matt
this
is
amazing.
Thank
you
so
much
for
putting
this
together.
How
much
time
do
you
think
this
has
freed
up
from
you
and
andre
to
do
other
things.
A
D
A
It
would
take
us,
you
know
ten
minutes,
maybe
each
to
to
compile
the
numbers
and
add
everything
up.
So
20
minutes
a
milestone
and
then
so.
C
I
think
it's
the,
I
think
it's
the
ability
that
it
unlocks
right,
because
before
we
had
this,
you
had
to
go
and
look
and
do
the
calculations.
So
you
wouldn't
do
that
like
every
day,
if
you
want,
you
can
put
this
in
your
home
home
screen.
If
you
want
just
so,
they
know
where
you're
at
we
would
do
live,
but
we
would
do
that
once
a
milestone,
and
now
you
can
do
that
every
day.
I
think
that's
the
benefit,
not
not
not
necessarily
the
time
frame
that
time
is
freed
up,
but
definitely
the
opportunity.
D
A
A
But
if,
if
you
see
any
discrepancies
or
weirdness
in
there,
let
me
know
I
kind
of
just
copy
and
pasted
a
bunch
of
stuff,
so
there's
chances
that
things
don't
adding
up
quite
right,
but
I
think
it's
close
enough
for
now
all
right,
kai.
B
B
So
a
special
thanks
on
here
and
hopefully
patrick
watches
later,
and
sees
that
it's
also
my
way
of
saying
I
shared
the
insights
and
then
I
was
told
about
other
issues
with
imports
related
to
this
customer
that
we
may
also
need
to
look
into,
and
so
this
is
my
way
of
saying
you
might
also
need
to
pull
back
off
and
look
at
that.
I've
got
a
call
later
today
to
look
at
another
one,
that's
happening
and
then
I'll
probably
grab
you
matt
and-
and
we
might
need
to
take
a
look
at
that
one
too.
B
C
Thank
you
so
far.
Where
can
we
see
those
investigation
details?
I
see
that
the
agenda
of
that
meeting
is
that
in
there.
A
I
created
a
new
issue:
I'll
put
a
link
in
here
or
kai
might
be
able
to
beat
me
to
it,
but
yeah.
We
created
a
new
issue
just
for
the
investigation
and
then
patrick
added
a
bunch
of
details
and
collaborated
with
a
few
other
people
on
there.
So.
C
B
A
and
an
rg-
oh,
no,
awesome!
Thank
you
just
added
it
for
you,
so
you
can
take
a
look
and
I'll
find
the
other
ones
as
as
they
keep
coming
up.
A
And
I'll
say
this
was
a
specific
customer
identified
this
issue,
but
it
wasn't
specific
to
them.
It's
an
issue
with
the
import
process
in
general,
so
it's
good
that
we
kind
of
figured
out
what
was
happening
with
this,
because
this
would
this
is
easy
to
reproduce
with
any
any
import
that
had
these
specific
conditions.
B
D
So
yeah
and
that
issue
talks
about
front-end
allocations
and
given
the
engineering
allocations,
mostly
affecting
back-end
resources
that
we
could
potentially
dedicate
those
to
pajamas
and
migrating
components-
and
I
I
brought
this
issue
up
in
because
what
I
think
a
noop,
if
I'm
not
mistaken,
what
he's
directing
folks
to
do
is
if,
if
we
don't
have
security
performance
or
about
reliability,
issues
that
front
end
can
help
with.
D
If
we
don't
have
critical,
near-term
customer
commitments
that
we
can
address
with
front-end
team
or
if
we
don't
have
extremely
painful
and
high-rise
core
ux
improvements
that
those
would
be
dedicated
to
helping
migrate
components,
pajamas
components,
and
so
before
we
get
to
that
point
I
suggested,
and
we
all
decided
that
it
could
be
helpful
for
us
to
talk
about
those
specific
kinds
of
issues
in
the
next
prioritization
session.
That
will
happen
next
monday
or
this
monday.
I
never
know
if
I
should
say
this
month
or
next
monday,
but
yeah.
D
You
know
so
yeah
this.
That's
a
reminder
for
kai,
matt
and
andre
to
add
those
kinds
of
issues
there.
I
initially
added
this
point
to
the
agenda
first
to
discuss
it,
but
we
reached
an
agreement.
So
I'm
not
sharing
that
here
under
point
a
I
don't
know
who
added
points
for
b.
I
don't
know
if
it
was
me,
but
but
anyway
that's
what
I
wanted
to
share.
C
Yeah,
that
makes
a
lot
of
sense
better.
We
can
take
a
look
on
the
on
that
call
I'll
just
add
that
detail
about
the
team
itself
being
in
their
staff
at
the
moment.
We're
hiring
to
backfill
a
position,
and
one
of
our
engineers
is
mostly
focused
on
gs
code.
So
basically
have
two
engineers
for
for
code
review
and
we
have
the
already
ongoing
topic
of
the
merge
request.
Merge,
widget,
plus
the
merge
request
report
working
group
where
we're
just
working
group
work.
C
E
Sure
I'm
gonna
be
the
noisy
one
who
advocates
for
my
team,
because
we
don't
have
any
engineers
and
our
quasi
engineer
axel
is
about
to
have
his
first
child.
So
we
are
hoping
nothing
breaks
for
the
next
couple
of
months.
So,
if
anybody
wants
to,
you
know,
throw
some
love
our
way,
that'd
be
cool.
That
would
be
a
great
time
so
carry
on.
D
Okay,
thank
you
for
that
yeah.
If
I
think
this
might
be
interesting
to
also
suggest
in
the
I
don't
know
if
you
haven't
done
it
already,
but
it
would
be
interesting
to
suggest
this
in
the
code
review
channel
so
that
if
people
have
some
spare
time
or
don't
know
what
to
do
with
those,
I
think
10
percent
of
their
time
to
work
on
other
things.
They
could
help
with
docs,
for
example,
if
they're
passionate
about
it
and
yeah.
D
Great
minds:
think
alike:
okay,
amy!
You
have
the
next
points.
E
Okay,
so
this
is
a
contractually
obligated
statement.
I
am
running
a
different
process
than
most
of
the
technical
writing
team
and
based
on
the
recent
guidance
that
got
published
for
the
technical
writers,
I
am
required
to
say
these
things
to
you.
C
And
this
is
my
contractually
obligated
officially
way
of
thanking
you
for
doing
that,
exact
thing,
because
that
that
helps
a
lot
in
the
when,
when
we're
crunching
and
it's
getting
trying
to
get
the
technical
writing
the
documentation
updates
in
there
you
pushing
a
commit
might
be
the
difference
between
four
hours
emerging
earlier.
So
just
being
considerate
and
being
in
communication
with
the
engineers
is
all
we
ask
and
you,
like
you
said
you
outlined
the
perfect
way
of
not
the
situation
to
not
do
it
so
yeah
don't
be
specially.
E
D
Yeah,
thank
you
so
much.
I
I.
I
think
that
exemplifies
bias
for
action
and
on
like
what
you're
telling
me
and
on
on
paper,
I
think
that's
great,
but
usually
I'm
not
the
the
possibly
affected
person
so
yeah.
My
question
is:
has
this
you're
making
this
announcements
more
or
less?
Is
it
because
it
has
negatively
affected
someone
in
the
past?
E
D
Okay,
and
and
are
those
guidelines
change
or
have
they
changed
or
are
they
going
to
change
as
a.
D
D
D
You
can
sign
on
the
last
page.
B
All
right,
kai,
we
are
we're
like
at
overtime,
and
I
thought
it'd
be
interesting
to
talk
about
this.
I
didn't
realize
this
had
merged
because
I
haven't
gotten
to
my
email
yet
this
morning,
but
apparently
this
has
already
merged.
So
I
was
just
curious
sort
of
just
to
see
how
people
were
feeling
or
if
people
had
thoughts
or
if
you
had
seen
it
at
all,
because
I
don't
know
I'm
assuming
it
got
sort
of
widely
circulated,
but
not
incredibly
widely
circulated.
B
But
there
is
a
new
proposal
that
I
think
if
teams
are
responsible,
if
you
merge
code-
and
it
is
responsible
for
an
s1
or
s2
incident
on
git
lab,
then
teams
involved
go
into
like
sort
of
an
immediate
five-day
engineering
allocation,
as
maybe
the
best
way
to
phrase
that
it's
called
it's.
B
It's
a
production,
change,
lock
and
you're
not
really
allowed
to
work
on
any
features
or
do
anything
else
until
this
has
been
rectified
at
least
five
days,
I
think
is
the
terminology
actually,
so
I
thought
it'd
be
interesting
to
chat
about
if
we
had
time
normally
we
blow
through
an
agenda,
but
we
did
not
today
so
feel.
Free
to
add
thoughts
or
comments,
async
or
or
share
them
now
in
the
last
minute
or.
C
So
that
we've
got
okay
I'll,
be
brief
on
mine,
I
think
I
think
it's
it's
reasonable
just
because
we
would
do
that
anyway,
maybe
not
the
whole
team,
but
whenever
something
like
this
big
happens
like
a
big
incident
or
something
we
would
act
to
rectify
it
and
to
find
ways
to
mitigate
it
and
probably
not
the
whole
five
days,
but
that
can
probably
allow
us
to
build
more
mechanisms
to
last
longer
or
clean
the
tech
debt
that
caused
it.
So
I
see
this
as
a
positive
thing.
C
It
has
a
also
a
cost
impact
where
you're
starting
to
feel
like.
If
I,
if
I
just
go
very
sloppy
on
my
merge
requests,
I
have
a
cost
to
pay.
After
that
I
do,
I
do
think
they
cleaned
up
the
language
about
the
reviewer.
A
Exactly
that's
the
big
thing
I
agree
and
it'll
be
interesting
to
see
how
it
works
after
the
first
few
of
these
start
coming
up,
which
hopefully
won't
be
our
team.
Let
let
some
other
teams
work
out
the
kinks
of
the
process
and.
B
Good
yeah
awesome
thanks
everyone
we're
we're
out
and
over
so
enjoy
the
rest
of
your
week
and
andre
thanks
for
the
fyi
down
below
sure
justify.