►
From YouTube: 2021-09-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
The
first
one
is
just
a
read-only.
We
were
talking
about
it
if
you
have
not
seen.
B
A
Craig
sent
out
a
message
in
the
company
fyi
channel
to
go
sign
up
for
some
swag,
give
away
your
shoe
size
and
we'll
see
what
comes
with
it.
The
next
one
up
is
free
format.
I
just
made
it
a
standing
item.
Yeah.
B
B
Issues
left
an
n
plus
one
error
that
we
made
some
fixes
for
and
looking
for,
there's
another
edge
case
that
we
have
to
look
for
and
then
I'm
a
caching
one
that
is
all
deployed
now
we're
just
working
on
rolling
out
the
feature
flags
that
was
deployed
to
dev
and
staging
yesterday,
we're
checking
on
the
test
results
and
then
we'll
slowly
roll
it
out
to
specific
gitlab
projects
this
week,
probably
so
that's
in
for
dev,
and
then
our
air
budget
keeps
going
up
which
is
great,
improving,
so
we're
currently
at
899.84
available
or
shooting
for
99.95,
I
think,
is
the
target
yeah.
B
So
we've
been
making
a
couple
small
changes.
The
caching
sometimes
helps,
but
we
found
the
caching
really
helps
with,
like
average
timings
and
response
rates
as
but
as
if
people
hit
a
cache
that
is
cold
and
it
hasn't
been
hit.
Yet
before
then,
we
could
still
potentially
get
higher
times
which
count
against
our
air
budget,
so
we're
looking
at
a
few
other
things,
but
then
also
there
was
a
change
last
week
for
or
maybe
it
was
two
weeks
ago
now
to
change
the
threshold
a
little
bit.
B
B
C
On
that
matt,
I
guess
the
plan
is
to
soon
bring
that
back
again
to
one
second
right.
B
My
suspicion
is
we'll
get
up
to
so
everyone
can
have
that
99.5
or
be
closer
to
that,
and
then
we'll
start
ratcheting
it
down
a
little
bit,
and
so
then
we
can
see
where
the
impact
of
that
is
makes
sense.
Thanks.
A
You
have
a
question
yeah
as
part
of
the
air
budget
stuff.
Have
we
made
sure
that
everything
that's
being
attributed
to
our
group
is
actually
our
group?
I
know
they
sort
of
like
broadly
categorize,
based
on
controllers
and
sort
of
best
guesses,
but
have
we
like
done
the
detail,
work
to
make
sure
all
of
that
is
ours.
B
The
that
is
an
excellent
question.
We
haven't
done
that
the
ones
I've
looked
at.
At
least
the
top
offenders
are
related
to
us.
So
that's
the
ones
we've
been
focused
on.
I
can
pull
up
the
list
of
all
of
them.
It
takes
a
while
to
load,
maybe,
but
but
I
can
look
and
just
verify,
but
most
of
them
are
ones
that
are
pretty
clear.
At
least
the
the
worst
ones
are
pretty
clearly.
A
Yeah,
I
think
I
thought
it
might
be
good.
I
know
I've
lately
seen,
and
I
think
this
is
because
of
the
way
like
italy
and
the
rails
stuff
talk.
We
there's
been
a
few
issues
lately
that
are
open
via
sentry
that
are
initially
tagged
us,
but
are
actually
like
giddily
problems,
because
giddaly's
too
slow
to
do
anything
which
I
think
then
results
in
like
a
cascade.
A
Where,
like
we
error
on
our
controller,
because
we
didn't
get
something
back
from
italy,
yep
fast
enough,
and
so
it
may
be
good
to
make
sure
that
we're
like
clear
that
the
failures
that
we
are
have
like
downstream
on
all
of
them
just
like.
Let's
make
sure
that
one
all
those
everything
that's
being
attributed
to
us
is
us
and
two
that
we
could
actually
impact
it.
And
it's
not
like
we're
beholden
to
giddily
as
a
service
responding
in.
A
Because
that's
that's
sort
of
like
out
of
our
control
and
so
it'd
be
good
just
to
make
sure
that
we-
and
we
don't
need
to
do
that
immediately.
I
know
like
part
of
engineering
allocation
is
addressing
sort
of
immediate
concerns,
but
over
the
course
of
the
quarter.
I
think
error
budgets
were
concerned
anyway,
so
it
might
be
good
to
make
sure
that
we're.
B
B
That
makes
sense
I
can
pretty
easily
at
least
get
the
list
of
all
the
things
that
are
contributing
to
our
error
budget,
and
then
we
can
review
that
and
make
sure
that
they're
all
really
ours
so
I'll
I'll
pull
that
list
together.
That
should
be
pretty
easy
to
do.
C
Back
yeah,
I
just
wanted
to
say
in
that
example.
I
was
thinking
that,
while
while
we
can
shift
the
focus
for
the
giddily
operation
that
might
be
taking
longer
in
the
end
of
the
day
from
our
side
on
the
rails,
we
could
totally
leverage
caching
so
that
not
as
many
requests
go
over
the
budget.
So
in
the
sense
it's
a
shared
responsibility,
it
might
be
definitely
worth
to
draw
a
flame
graph
of
the
operations
to
see
where
exactly
lies.
The
delay
there
on
certain
cases
but
great
point,
kai.
B
And
we
have
been
some
of
the
caching
we've
been
doing.
I
think
we've
done
some
specific
for
italy,
but
yeah.
It
helps
to
have
fewer
requests,
but
we
still
the
requests
that
aren't
hitting
the
cache
is
an
area
we
need
to
focus
on,
because
that
first
initial
one,
if
that's
really
taking
long,
that's
still
going
to
affect
our
error
budget,
it
might
only
get
called
one
time
and
then
it'll
be
cash.
So
we'll
be
okay,
but
if
we
can
reduce
that
initial
one
as
well,
that
that
will
help.
A
A
B
A
B
Yeah,
if
we're
done
with
our
error,
our
infradeb
issues,
which
possibly
could
be
you
know
this
week
or
next
week-
and
our
air
budgets
are
keep
going
up,
then
maybe
we
don't
need
to
be
100
allocated
or
yeah.
That
would
be
the
goal
and
we're
so
we'll
I'll
keep
trying
to
dig
on
that.
B
I
know
I
said
that
last
week,
but
I'm
I'm
working
on
it,
but
I'll
keep
on
it
and
yeah
in
the
meantime,
we're
slowly
starting
to
work
on
some
of
the
kind
of
the
mergability
stuff
as
well
kind
of
because
that's
it's
not
technically
related
to
engineering
allocation,
but
it
was
something
that
we
knew
we
had
planned
to
do
anyway,
so
get
it
get
the
first
parts
of
that,
like
the
we
had
to
do
a
database
table,
so
that
is
underway
so
kind
of
get
a
little
bit
of
that
work
done
to
prepare
for
when
we
come
out
of
this.
A
Next,
one
up
on
the
agenda
there's
a
I
had
a
conversation
with
pedro
and
annabelle
yesterday
about
the
strategy
and
vision,
work
that
pms
and
creator
taking
undertaking
during
q3.
I
think
matt
and
andre
you've
both
been
tagged
on
the
issues
probably,
but
you
can
check
the
questions
there
that
pedro
asked
and
watch
the
the
review
from
yesterday.
A
So
if
you
want
to
contribute
to
that,
just
do
it
before
next
week.
I
think
we're
going
to
discuss
it
synchronously
next
week
in
the
ux
meeting.
So
if
you're
interested
in
that,
then
you
can
also
try
and
join
that
meeting
as
well.
B
Yeah,
I
can.
We
can
mostly
skip
over
this
next
topic
for
the
mid
milestone
checking.
I
just
put
it
in
here
with
the
rec
for
for
the
reference
for
everyone
to
see
kind
of
where
we
are
for
the
from
the
back
end
team
on
the
the
deliverables.
Now
this
was
kind
of
a
a
weird
milestone,
because
it
was
mostly
focused
on
engineering
allocation,
which
we
did
mark
those
issues
as
deliverable
things.
So
that's
where
most
of
those
are
coming
from,
but
just
to
be
consistent.
I
wanted
to
make
sure
to
put
that
in
there.
C
While
we're
on
that
topic,
I
haven't
done
the
front
end,
yet
I
can
do
that
asynchronously
just
to
provide
that
kai
more
for
you.
Have
you
been
getting
useful
feedback
from
these
status
updates,
like
the
weekly
status
updates
from
the
ics
on
the
issue?
C
Is
that
working
well
is
the
mid
milestone,
still
worth
continuing
doing?
What's
the
thoughts
there,
I'm
happy
to
continue
doing.
I
just
forgot
that
today
was
the
half
of
the
milestone.
Honestly
speaking,.
A
The
front
end
does
a
a
really
good
job
of
doing
the
status
updates.
I
think
the
back
end
does
not
so
yes
to
me
and
one
of
the
reasons
we
brought
the
status
update
here
was.
It
is
valuable,
because
it's
a
good
way
for
me
to
see
it
makes
it
easy
for
me
to
just
know.
What's
going
on
when
which
is
nice,
I
think
it's
a
way
for,
like
other
people,
to
know
what's
going
on
as
well,
because
that
happens
in
the
planning
issue.
A
That
sort
of
everyone
is
at
some
point
involved
in
there
are
times
when,
like
someone,
mint
is
an
issue
and
you'll
see
me
comment
on
it
or
go
find
that
issue
and
go
look
at
it,
and
so
for
me,
it's
helpful
from
that
regard.
A
The
mid
milestone
check-in,
I
think,
is
sort
of
less
helpful
in
the
sense
that
it's
redundant,
it
is.
It
is
a
good
like
indicator
of
where
we
are
but,
but
I
think
we
normally
sort
of
recognize
those
problems
in
advance
and
so
and
then
we
always
come
down
to
the
wire
and
it's
like
what
ship,
what
didn't
ship
like?
Where
did
we
actually
end
up?
Like
you
know,
we
I
think
that
park
gets
weird.
A
So
I'm
okay,
if
we
stop
doing
the
milestone
check-ins,
I
would
like
to
see
more
participation
in
the
status
of
the
weekly
status
stuff.
But
that's
you
know,
that's
the
thing
that
we
just
have
to
figure
out
if
that,
if
that's
working
for
other
people,.
C
B
Yeah,
I
could
try
to
drive
up
a
little
more
engagement
from
the
back
inside
I'll
I'll,
bring
it
up
to
everyone,
because
I
think
that's
fine
but
mid
milestone
check
in
is
not
hard
to
do
so.
I'm
fine
doing
it,
but
if
it's
not
valuable,
then
I
won't
spend
the
couple
minutes.
It
takes.
C
I
won't
put
it
that
way.
Just
it
is
valuable,
but
it's
also
redundant
yeah.
C
B
C
We
drop
it
completely,
yeah.
Okay,
you
have
editor
access,
man,
yeah
scissors,
okay,
we
can
collaborate
on
it
and
try
to
see
if
we
can
make
it
still
available,
but
without
having
a
strict
ceremony
thing
that
every
time
in
the
middle
of
the
month,
we
show
it
just
make
it
everywhere
available
all
the
time
with
some
filters
and
stuff.
So.
A
D
C
I
can
vocalize
why
my
my
perspective
on
it
is
that
I
don't
think
it's
worth
considering
or
doing
it
for
the
back
end,
because
they're
already
exhausted
on
the
capacity
from
our
side.
We
also
have
work
to
pick
up,
but
I
feel
like
we'll.
We
have
a
little
bit
more
gaps
to
fill,
and
if
we
have
some,
you
know
low-hanging
fruit
that
we
could
just
hammer
it
out
and
just
push
it
out
in
the
middle
of
the
epic
work
that
we're
doing
for
the
merger
quest
merger
widget.
C
D
I
think
so,
and
it
might
also
be
like
if
we
find
an
issue
that,
for
some
reason
we
believe
also
needs
backend.
D
It
could
also,
if
it's
really
important,
and
if
it's
really
impactful,
we
might
be
able
to
come
up
with
a
way
to
you,
know,
split
it
and
change
how
we
approached
it
so
that
it's
more.
B
A
Sounds
like
you
agree,
yeah,
I'm
on
board
trying
it
with
run-in
only
I
think,
given
what
we
saw
in
14..
A
D
B
No
I'll,
I
can
still
attend,
but
yeah
you're
right
that
it's,
I
think
the
back
end
is
probably
full
for
at
least
the
next
milestone,
regardless
of
the
engineering
allocation.
If
we're
out
of
that
by
then
I
think
we
have
you
know
all
the
stuff
that's
been
building
up
since
then
to
to
get
back
to
and
then
all
the
mergability
work
so
but
yeah.
I
think
that
makes
sense.
D
Yeah
cool
thanks.
Thank
you
for
that,
and
also
I
wanted
to
to
thank
you
for
all
of
the
work
that
you've
been
doing
and
organizing
everything
for
us
and
how
we
work
through
this
engineering
allocation.
So
thank
you
for
that.
B
B
Hopefully
everyone
can
attend
at
least
one
session.
If
you
have
ideas
for
things
you
want
to
do
during
that
time,
there's
the
the
link
to
the
issue
and
then
that's
just
to
kind
of
brainstorm
ideas
and
then
we'll
kind
of
narrow
it
down
a
little
bit
closer
to
the
date
and
andre
wants
to
play.
Pokemon.
C
It's
very
typical
of
me
because
I've
never,
I
was
never
big
into
pokemon,
but
they
now
have
a
game
to
spin
within
league
of
legends
and
I'm
like
all
right
I'll
bite,
so
yeah
propose
your
activity
is
gonna,
be
fun
thanks,
matt.
A
All
right:
well,
let
everyone
enjoy
the
rest
of
your
week
and
have
a
good.