►
From YouTube: 2021-10-06 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
B
A
Yeah,
I
can
start
because
I
have
the
first
item,
which
is
great
news
that
I
hit
merge
this
morning
on
the
mr
to
remove
the
code
review
team
from
the
engineering
allocation,
so
that's
exciting,
so
yeah.
Thank
you
to
everyone
who
helped
with
that
and
yeah
we're.
Our
air
budgets
are
green.
Our
infra
dev
issues
are
gone
for
now
and
on
both
of
those
things
for
now,
but
but
we
were
able
to
kind
of
get
through
our
backlog
and
get
things
where
they
needed
to
be
so
that
was
great.
C
Proud
yeah
awesome
work,
matt
did
an
outstanding
job,
leading
the
effort
and
keeping
everyone
updated
in
the
loop.
So
it's
much
appreciated
and
thanks
to
the
team
as
well,
I
know
there
was
a
ton
of
issues
and
sort
of
moving
around
and
never
shifting
priority.
So
thanks
to
everyone
for
being
flexible
and
and
getting
through
it,
it
is
merged.
So
it's
not
even
closing.
It
is
closed
so
that
mr
is
merged
and
done
and
we're
off
the
list
just
to
awesome.
B
A
Shooks
it
closed
yeah
exited,
I
guess,
is
the
word
they're
using
there.
We
go
exited
in
it,
which
involved
a
lot
of
uncertainty
of
what
to
do,
and
then
I
just
created
an
mr
and
merged
it,
and
it's
fine
good.
So
then
the
question
then
will
be
kind
of
the
next
steps.
A
There
is
this
proposal
around
security
issues,
which
is
still
a
proposal
as
far
as
I
know,
but
it's
there's
a
lot
of
discussion
and
talk
about
what
we're
gonna
do
there
so
that
that
could
be
on
our
our
near
term
radar.
Here
I
don't
know
kai
if
you
have
any
more
ideas
of
if
there's
next
steps
or
where
that
stands
right
now,
but.
C
Yeah,
I
think,
from
my
side
I'll
say
to
be
clear:
it
is
a
proposal,
so
we
should
not
react
to
it
like
it
is
what's
coming
next
until
we've
heard
otherwise,
and
what
I
know
about
that
is
that
there's
a
conversation
later
this
week
between
david
and
anup
and
scott
and
christopher,
to
I
think,
evaluate
whether
or
not
this
should
move
forward
so
potentially
we'll
know
more
by
the
end
of
the
week
or
early
next
week.
But
for
now
it
is.
C
It
is
purely
a
proposal
which
same
goes
for
like
the
front
end
piece
of
other
efforts
that
are
being
discussed,
they're
being
discussed,
sort
of
like
in
relation
to
if
back
end,
were
to
be
occupied
again
for
a
significant
period
of
time,
like
some
front-end
groups,
which
I
think
even
we
were
part
of
like
I
know
andre.
We
struggled
to
sort
of
not
not
struggle,
but
it
was
certainly
like.
C
There
was
more
capacity
in
the
milestone
than
I
think
we
expected
there
to
be
capacity
in
the
milestone
and
that's
only
going
to
continue
to
get
worse
for
front
end
unless
we
start
looking
well
outside
of
the
group
and
into
things
that
are
like
exclusively
front-end
only
in
in
much
larger
projects.
D
I
think
it's
important
to
acknowledge
that
even
those
contributions
outside
of
the
group
they're
still
valuable
for
us.
For
example,
the
vue
3
pursuit
would
benefit
code
review
directly,
for
example,
that's
just
one
example,
so
it's
it
might
be.
I
don't
see
that,
especially
because
we're
hiring
an
extra
engineer,
so
we
might
even
have
over
capacity
even
even
more,
but
I
see
that
as
a
positive
thing.
D
C
Yeah
no,
I
agree,
I
think,
there's
there's
things
in
there
that
we
should
discuss.
We
just
shouldn't,
discuss
them
in
the
context
of
being
backed
into
the
corner
of
needing
to
find
the
work.
I
think
we
need
to
evaluate
their
their
merit.
Sort
of
against
the
other
work
sure
would
be
the
the
way
to
appropriately
look
at
that
so
yeah,
that's
all
I
know
like
I
said.
I
don't
know
that
I
don't
know
what
the
outcome
will
be
so
for
now
my
my
planning
brain
is
focused
on
what
we
would.
C
C
Which,
I
think
brings
us
to
number
three,
which
is.
That
is
the
next
thing
we
want
to
go
to,
but
we
need
engineers
to
look
at
it,
probably
particularly
on
the
backend.
I
think
andre
has
looked
at
it
before,
but
particularly
we
need
the
back
end
to
go.
Take
a
look
and
start
getting
a
handle
on
what
this
looks
like,
so
that
we
can.
C
D
Yeah
so
last
time
I
looked
into
this
there's
a
mix
of
front
and
back
end
issues
the
back-end
at
work.
I
think
it's
light
though,
but
it
has
been
scored,
so
that
would
be
probably
the
first
stab
we'd
need.
It
would
be
someone
to
go
through
that
plan
and
to
verify
whether
that
makes
sense
or
not,
and
what
would
be
the
effort
for
the
back-end
map
and
then
turning
that
into
issues.
I
guess.
C
Yeah,
it
would
be
good
to
have
engineering
create
sort
of
all
of
the
issues
across
the
board
front
and
back,
and
for
this
once
they're
settled
on
that,
I
think
we
were
also.
I
know
we
talked
about
if
we
go
way
back
in
time
to
the
first
time.
I
think
we
brought
this
up
not
even
a
few
weeks
ago,
but
when
we
this
was
originally
created,
we
talked
about.
C
I
think
engineers
had
been
asking
to
be
more
involved
in
like
sort
of
the
planning
piece
and
sort
of
getting
to
validate
or
see
where
things
were
going
and
making
sure
that
they
understood
the
full
scope
of
things,
because
I
know
that
was
a
concern
with
reviewers
that
we
short
that
what
they
built
was
not
necessarily
what
the
product
vision
aligned
with
and
so
it'd
be
good
to
have
more
than
just
like
one
engineer.
C
C
Probably
not
I
have
a.
It
was
like
a
tangent
to
okrs
okrs
that
are
for
work
that
we
would
do.
Anyways
seem.
E
C
Okr
and
then
that
doesn't
necessarily
like
drive
everyone
to
one
objective
or
anything.
That's
like
meaningful
in
terms
of
understanding
forward.
So,
probably
not
it's.
I.
It
doesn't
feel
as
critically
important
as
like
and
part
of
the
reason
I
think
reliability
for
like
mergeability
work
and
the
merge
widget
were
is
because
they
were
much
more
about
usability
and
sort
of
aligning
with
this,
and
this
is
certainly
makes
reviewers
more
usable.
D
Yeah
yeah,
it
is
something
that's
been
in
the
back
of
our
minds
for
for
long
enough
for
us
to
really
want
to
close
it
off,
regardless
of
that
being
in
okay
or
not
okay,
I
understand
that
so
matt.
Do
you
wanna
get
someone
on
your
team
to
go
through
it
through
that
plan?
I
can
get
someone
on
my
team
to
take
a
look
at
it
and
revalidate
that
and
be
in
contact,
and
I
think
we
should
aim
to
have
that
plan
prepared
for
planning
for
14.5.
D
Then
I
I
think
I
mentioned
that
we
could
have
a
spike,
but
I
feel
like
at
this
point.
I
don't
think
it
needs
that
much
of
a
spike
anymore.
Just
a
couple
of
I
wouldn't
say
hours,
but
a
bit
of
time
to
go
through
it
again
see
if
we
missed
anything
and
then
just
turning
that
into
issues
and
then
we
can
start
planning,
hopefully
we're
circling
a
couple
of
issues
for
five
that'd,
be
nice.
C
Yeah,
I
think,
just
to
be
clear,
like
14
5
planning
mid
like
this
week.
Next
time
probably
has
to
be
locked
up
based
on
yeah
I'm
thinking
next
days.
Yeah
and
next
week
will
be
friends
and
family
day
on
the
friday.
The
15th
so
we'll
lose
that
day,
and
I
think
kickoff
therefore
fell
to
one
day
the
18th,
although
I
don't
see
it
on
the
calendar.
C
So
just
keep
that
in
mind,
like
we're.
Probably
talking,
we've
got
until
about
wednesday
of
next
week
at
the
latest
to
to
really
think
this
through.
B
D
So
next
couple
days
would
be
nice
to
have
some
feedback
on
this
all
right,
I'll,
find
someone.
C
Thanks
next
one's
an
fyi
tag,
annabelle
and
pedro,
I
tagged
you
both
in
slack
about
this
as
well.
E
Great
yeah,
it's
kind
of
related
to
that.
Actually,
I'm
having
trouble
figuring
out
how
to
create
charts
and
read
them
in
that,
but
I
don't
think
it
I
don't
know.
If
it's
the
chart,
I
don't
think
it's
periscope
or
science
or
whatever
it's
called
necessarily.
I
just
think
it's
it's
difficult
to
find
resources
to
figure
out
how
to
read
and
make
these
different
kind
of
things.
So
I
linked
to
the
issue
where
I'm
trying
to
add
tracking
to
all
of
the
different
pieces
of
every
emerge.
E
Request
widget
and
I
just
talked
to
marcel-
and
he
pointed
me
towards
a
chrome
extension
where
I
can
find
out
which
part
of
each
widget
is
being
tracked
just
to
verify.
So
do
we
use
snowplow
on
the
front
end,
and
that
is
what
is
being
tracked
or
what
that's.
B
E
B
Things
yeah:
we
use
we
snip
off
for
like
interaction
tracking
like
button
clicks
and
those
and
feature
using
feature
usage.
We
use
a
couple
of
other
services
for
other
types
of
data
reporting,
but
probably
the
one
here.
Okay,.
E
So
I'm
just
trying
to
see
if
the
expand
buttons
are
being
tracked
or
what
part
of
the
widget
is.
So
I
should
be
able
to
figure
that
out.
So
I
have
some
open
questions
on
the
chart
in
that
issue,
description,
which
I
think
I
can
answer
myself
other
than
that,
though,
as
far
as
I
can
tell,
that
issue
is
ready
for
implementation.
E
C
B
C
Usage
ping
is
off
by
default
and
they
can
choose
to
opt
into
usage
ping.
Snow
plow
does
not
send
to
usage
ping.
Yet
at
one
point
there
was
a
proposal
man
I
just
have
to
make
this
recording
private,
because
I
don't
know
what
this
was
supposed
to
be
or
not
anymore.
At
one
point,
there
was
a
proposal
for
a
usage
ping
collector
to
be
added
that
would
take
snow,
plow
events
and
send
it
into
usage
ping,
and
then
it
would
come
across
in
the
usage
ping
payload.
C
You
can,
though,
track
and
self-manage,
and
you
can
clack
track
click
events
through
the
redis
counter,
so
all
of
the
like
improved
redis
counters
that
have
happened,
work
in
both
self-managed
and
in
dot
com,
and
so
anything
that
we've
done
since
I
joined
the
group
and
implemented
we've
done
in
redis
counters,
not
in
snowplow.
So
any
of
the
instrumentation
work
that
phil
had
done
a
few
miles
ago
was
all
done
in
redis
intentionally.
For
this
reason
he
first
implemented
them
in
snowplow,
and
then
we
were
like
wait.
C
A
minute
we
need
these
themselves
to
manage
and
you've
got
to
go
back
and
do
it.
So
I
think
that's
the
piece
to
be
first
clear
on
so,
even
if
you
see
snowplow
events,
that'll
only
give
you.com
data
it'll
probably
give
you
really
poor.com
data,
because
particularly
widgets
are
in
a
lot
of
that.
Stuff
has
been
paid,
tiers
and
other
things
like
you,
won't
see.
Usage
of
out
of
groups.
E
So
every
every
place
that
I
said
that
we
already
have
tracking
we
might
not,
it
might
be
snowplow,
not
redis.
C
It's
possible
depends
on
what
you
saw,
that
that
led
you
to
believe
we
have
tracking.
So
if
it
was
the
mao
charts
that
are
on
the
mao
dashboard,
that's
all
tracking
that
we
implemented,
I
think,
except
for
the
testing
group,
had
implemented
their
widget
and
we
just
used
theirs
and
theirs
was
done
in
reddit.
E
E
E
E
Don't
know
how
that's
gonna
happen,
but
it's
empty
because
we
don't
have
that
and
then
also
are
we
able
to
filter
out
gitlab
team
members
and
bots.
E
C
You
can
filter.com
sort
of
like
out
exclusively,
but
we
don't
actually
know
much
about.com
at
all.
I
guess
you
could
filter.
C
C
Next
steps
is
the
other
thing
you
asked
about.
I
think
we
just
need
to
probably
build
out
an
issue
for
this.
This
probably
needs
andre.
This
will
be
almost
exclusively
front
end
and
phil's.
Probably
I
think
I
taught
and
thomas
you
can
correct
me.
I
don't
think
you
did
any
other
recent
tracking
work.
I
think
it
was
all
phil,
so
phil
can
look
at
it
and
then
sort
of
come
back.
We've,
never
instrumented
total
total
clicks
or
anything.
That's
like
action
based
is
new
for
instrumentation.
For
us.
E
D
And
you're
talking
about
the
expansion,
so
we
there's
a
small
distinction
between
merge,
request,
widgets
that
are
like
the
merge,
widget,
the
ready
to
merge
widget
and
the
report
widgets
that
we're
calling
that
in
the
working
group
context
about
like
the
tests.
All
of
that
we
call
report
widgets
you're
talking
about
covering.
D
D
It
has
to
signal
that
it's
going
to
be
using
that
report
that
metrics
my
question
is:
are
we
okay
in
waiting
for
all
of
the
report,
wages
to
be
rewritten
to
this
new
code
base
before
we
get
the
data,
or
do
we
want
to
get
the
data
tomorrow?.
E
A
E
It's
got
it,
it
lists
every
single
item
that
we
want
to
track
and
most
of
it
is
the
expand
portion.
So
when
we
do
rewrite
it,
you
know
we'll
always
have
it
on
the
expand
portion.
But
then
some
of
the
report
widgets
have
multiple
buttons
that
we
want
to
add
tracking
to
and
some
of
them
don't
have
expand
buttons.
I
think.
Maybe
they
all
do.
I
don't
know
and
then
other
parts
like
let's
say
the
your
pipeline.
E
I
was
hoping
I
feel
like
the
most
common
thing
you
would
do
with
the
pipeline.
Widget
is
maybe
hover
or
not.
However,
maybe
click
on
one
of
the
stages
to
view
the
job.
So
if
we
could
add
tracking
to
that
somehow
too
anyway,
it's
all
it's
all
broken
out
in
in
that
issue,
I
think
I've
covered
every
state
that
could
possibly
exist.
D
That's
good,
that's
the
hard
part,
I
guess
the
the
following
part,
then
I
think
yeah
we
can.
We
can
totally
start
with
the
other.
Merge
group
merge
request
which
that
are
not
covered
by
the
reports.
Effort
by
the
time
that
we
get
there,
we're
probably
in
good
shape
anyway.
So
I'll
have
phil
have
a
look
at
it
see
if
we
can
break
it
down
into
steps
that
we
can
take
right
now,.
C
C
C
What's
going
on
so
13
8
was
when
we
first
started
any
of
our
male
tracking
we're
many
months
removed
from
13
8
at
this
point
like
january,
so
we're
like
10
months
away
and
of
all
the
instances
that
send
us
usage
ping
data
less
than
50
of
them
are
on
13,
8
or
higher,
which
means
that
we
still
have
less
than
50
of
instances
actually
giving
us
data
about
all
of
the
new
things
we
instrument
it,
and
so
that's
just
like
the
lead
time
on
any
time
you
instrument
is
sort
of
astronomical
in
terms
to
start
getting
like
anything
meaningful
back.
C
We
didn't
actually
switch
over
to
using
the
new
instrumentation
data
for
like
even
reporting
and
product
until
we
had
about
six
months
worth
of
data,
because
it's
it
takes
so
long
for
it
to
stabilize
like
if
you
look
at,
we
didn't
get
the
first
reports
until
march
once
we
implemented
aggregated
and
it
sort
of
took
until
august
to
look
like
this
number
was
close
to
what
we
had
previously
seen
with
other
instrumentation.
And
so
that's
just
why
it's
so
important
that
like.
D
So
sorry
conversation
around
that
that
we
can
have
in
another
forum,
I
guess
but
engineering.
C
Side
yeah,
that's
probably
a
great
conversation
to
have
with
the
product
intelligence
groups,
and
I
think,
that's
also
part
of
the
survey
above
they
want
to
try
and
are
there
other
options
that
sort
of
like
naturally,
instrument
when
you
build
things
versus
needing
to
go
and
manually,
add
instrumentation,
which
are
I
do.
D
I
know
this
is
being
recorded,
but
are
you
familiar
with
kissmetrics
everyone?
More
or
less
a
couple?
Years
ago
they
launched
the
product,
which
was
exactly
that
you
would
track
every
click
on
the
page,
everything
and
then
we
could
retroactively,
go
and
find
a
filter
for
those
actions
which
was
mind-boggling
the
amounts
of
data
being
collected,
but
it
was,
we
were
able
to
backboard
and
not
backward
to
backfill
insights
or
something
that
was
interesting.
C
Take
a
look,
I
think,
that's
probably
the
the
best
next
step
and
then
we'll
need
to
start
yeah
working
on
it,
14,
whatever
we
can
and
annabelle
it
may
help.
If,
if
we
need
to
break
this
up
like
if
you
pick
the
like
thing
that
you
is
sort
of
most
important
first
like
if
it's
the
merge,
the
actual
merge
button,
widget
and
everything
in
there,
because
I
know
we've
been
refactoring
all
of
that
anyways,
maybe
that's
like
one
we're,
starting
with
versus
some
of
the
other
areas.
E
The
the
original
goal
and
the
whole
reason
this
was
created,
was
because
we
were
trying
to
get
a
better
idea
of
what
reviewers
and
authors
of
merge
requests
do
like.
First,
when
they
look
at
a
merge
request
and
which
widgets
they
actually
interact
with,
and
we
got
an
idea,
it's
basically
merge
and
pipelines,
and
sometimes
security,
but
that's
why
I
kind
of
wanted
to
see
at
least
the
expand
on
all
of
them.
If
some
of
them
are
never
ever
being
expanded,
then
maybe
we
need
to
rethink
what
that
widget's
doing.
E
C
It's
probably
a
question
for
phil
and
how
much
he's
comfortable
pushing
in
a
single.
Mr,
I
know
when,
and
I
say
that
only
because
mark
had
the
original
long
list
for
the
back
end
when
we
did
everything
and
it
got
broken
in,
I
didn't
see
more
than
like
six
metrics
get
added
per
mr.
That
seemed
to
be
like
the
upper
limit,
because
every
metric
comes
with,
I
think
three
emo
files
that
have
to
be
added
to
the
metrics
dictionary.
C
So
it's
the
the
total
metric
file
has
to
be
added
the
monthly
one
and
the
weekly
one
and
those
are
all
like
auto
generated
and
filled
in
content.
But,
like
there's
rate
tasks
to
those
and
all
that
has
to
be
validated,
they
ought
to
be
linked
to
issues
and
feature
flags
and
sort
of
they're
they're,
more
labor
intensive,
they're
sort
of
like
security
releases,
where
they're
just
developer.
Labor
intensive,
not
necessarily
like
hard
to
do.
D
I
know
just
so
I
I
know
we're
over
time,
but
just
so
I
understand
the
prompt
correctly.
So
what
I
see
here
on
the
table
are
basically
like
in
bold,
is
the
widget
itself
and
then
in
parenthesis
is
basically
the
action
that
we
want
to
track,
and
some
of
these
might
actually
be
the
same
button
just
different
copy.
But
you
want
to
distinguish
the
two
and
those
are
the
instances
or
the
events
that
you
want
to
track.
E
A
E
D
Got
it
got
it?
Okay?
No,
but
there
might
be
some
bundles.
For
example,
the
merge
train
button
would
be,
for
example,
one
merge
request
like
I
was
saying
to
play
that
in
the
bundle
right
all
right
sounds
good.
We'll
take
a
look
at
that,
looking
to
prayer
to
bundle
this
up
into
chunks
and
see
if
we
can
do
okay,.
E
B
C
Can
help
if
you've
got
specific
questions
I
can
help
you
dig
through
performance
like
the
metric
dictionary
and
try
and
figure
those
out
as
well.
Okay,.
E
I
do
have
some
highlighted
as
well.
Now,
I'm
not
sure
if
it
is
snowplow,
I
know
how
to
check
which
element
it's
actually
being
tracked
on,
but
if
it's
not,
then
I
don't
know
how
to
check
so.
I've
highlighted
like
the
browser
performance.
Is
it
the
expand?
Widget,
that's
being
tracked,
I'm
assuming
it
is
because
that
seems
to
be
the
standard,
but
I
don't
know
for
sure,
because
we
didn't.
A
E
D
C
Thanks
everyone,
and
thanks
for
for
chatting
thanks
again
matt
for
the
engineering
allocation,
awesome
work
to
the
team
there.
So
passing
along.
My
thanks.
If
you
chat
with
me.