►
From YouTube: 2022-05-18 Code Review Weekly
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
B
Let's
do
that,
I
haven't
the
agenda,
is,
am
I
first.
B
Yes,
it's
your
meeting
today,
so
it's
the
andreas
show
feel
free
to
add
some
points
there.
Please
so
that
it's
not
just
me
speaking
so
yeah.
I
just
wanted
to
bring
up
something
here.
It's
not
in
our
priorities,
but
it's
something
that
came
up.
Stannis
left
brought
this
to
my
attention
and
then
I
shared
it
with
donald,
and
it
seems
like
the
plan
team
is
pretty
much
done
with
the
issues
list
view
refactor.
They
have
a
bunch
of
components
and
and
all
that
stuff
so
we're
if
I'm
not
mistaken
code
review.
B
B
Now
we
can
either
just
update
the
filtered
search
or
we
can
include
that
in
the
bigger
effort
of
refactoring
the
whole
page
to
view
which
does
come
with
its
benefits
of
reusing
other
components
and
potentially
even
more
like
real
time
or
more
front-end
interaction
and
stuff
like
that,
but
just
want
to
bring
up
to
the
team
that
they've
gotten
to
a
point
that
now
it's
starting
to
make
sense
to
pick
up
for
the
merch
request
list
as
well.
B
A
For
the
purpose
of
this,
I
know
you-
and
I
discussed
this
a
little
bit-
it's
sort
of,
I
think,
one
of
those
things-
that's
not
entirely
clear
what
the
benefit
is
and
while
there's
a
ton
of
stuff
done
like
how
much
effort
we're
looking
at,
and
so
I
think,
if
we
could
somehow
without
like
having
to
spend
a
milestone
on
a
spike
or
something
like
quantify
the
amount
of
work
that
we're
talking
about
like
how
many
issues
of
a
weight
of
what
is
this
going
to
take
like.
A
Are
we
talking
about
like
three
months
of
someone's
time,
to
sort
of
do
this
and
then
at
the
end
state?
If
we're
not
actually
planning
on
building
any
features,
you're
doing
anything
there
like?
What
did
we
get
or
what
are
where
are
we
at?
I
think
that
would
help
sort
of
understand
what
we're
what
the
ask
is
here.
B
That's
fair:
I
can
work
on
that.
Try
to
come
up
with
some
estimations
of
the
effort
of
that
that
will
take
knowing
that
probably
we
need
some
updates
on
the
back
end
I'll
have
to
check
so
I'll.
Look
into
that
and
I'll
come
back
with
some
forecasts
in
the
next
couple
weeks,
for
it's
not
an
urgent
thing,
because
it's
not
like
we
don't
have
the
merge
request
this
breaking
or
something
like
that,
but
so
to
pedro's
point
one
of
the
pros
and
cons.
B
I
feel
like
not
doing
it
just
keep
that
part
of
the
code
more
stagnant
or
not
benefiting
from
improvements
that
are
done
on
the
issues
list
side,
as
we
know,
moving
to
view
allows
us
to
do
clever
things
about
how
we
load
things
and
make
some
performance
optimizations
there,
and
we
can
have
more
interactive
things
like
if
we
ever
want
to
do
like
expandable
merge,
request
list
items
like
expand
for
a
quick
view,
like
that's
much
more
easier
to
do
in
view
than
it
was
hamill,
that's
some
of
it,
but
I
think
the
driver
here
is
code
debt
because
we're
right
now
using
a
very
old
code
base
that
is
very
hard
to
maintain
for
the
filtered
search.
B
D
Yep
yeah,
I
don't
know
if
kai,
has
any
more
questions
about
the
effort.
D
Okay,
yeah,
would
it
be
not
not
possible,
but
what
would
be
the
work
or
how
feasible
would
it
be
to
if
you
wanted
to
apply
a
slightly
different
design
to
the
list?
You
know
imagine
we
wanted
to
prioritize
redesigning
the
mr
dashboard
lists
and
we
ended
up
with
a
slightly
different
design
from
the
issues
list,
for
example,
turning
it
into
a
table
or
rearranging
some
some
elements.
What
would
be
the
impact
of
doing
that,
and
would
we
have
to
also
do
the
work
for
the
issues
or
you
know.
B
That's
a
good
question,
I
don't
know
so
the
fact
that
we're
working
on
them
allow
us
to
create
new
layouts
for
sure
whether
we
would
have
to
port
them
into
issues.
It's
a
matter
of
basically
design.
I
would
say
if
it
makes
sense,
so
what
you're
talking
about?
Is
it
an
alternative
way
to
render
the
list
or
is
it
just
that's
the
way
we
render
merge
requests
so
that
that
will
be
up
for
debate
in
terms
of
what
the
proposition
is?
So
I
think
everything
is
up
for
being
decided
in
that
regard.
D
But
it
would,
it
would
make
it
easier,
like
imagine
that
we,
you
know
just
changed
some
parts,
knowing
that
the
filtered
the
filter
bar
and
the
tabs
would
stay
the
same
and
other
things,
but
just
the
list
would
be
slightly
different.
That
would
already
help
because
we're
sharing
those
components
right,
the
ones
that
are
not
changed
or,
in
other
words.
C
B
Yeah,
I
don't
know
exactly:
I
would
have
to
dive
into
the
code
to
see
exactly
if
we
have,
if
they
already
have
reusable
components
for
those
issues,
list
items
which
then
would
be
using
for
merge,
request
list
items
which
then
will
have
a
shared
code
base
to
improve
upon.
B
I
think
all
of
that
is
part
of
the
discussion
that
we
can
have
yeah
for
that.
But
remember,
there's
two
two
chunks
here:
one
is
the
filtered
search.
The
other
is
the
merger.
B
Questions
like,
like
you,
said
I'll
I'll
scope
out
the
two
efforts
so
that
we
can
have
an
idea
about
how
would
it
cost
to
just
replace
the
filtered
surge
and
the
plan
were
kind
of
willing
to
do
that
themselves,
but
there's
a
couple
of
filters
that
are
merged,
quite
specifically,
merger
quite
specific,
so
we
might
want
to
be
involved
anyway
and
then
there's
the
merger
business,
so
I'll
focus
on
those
two
things
and
then,
regarding
of
how
we
want
to
design
them,
we
can
have
that
cross-sharing
or
not.
It's
up
to
us.
D
Cool
yeah,
I
think
it's.
It
would
be
good
if
we
moved
over
to
to
view.
But
I
understand
kai
is
concerned
about
the
effort
and
if
it's
worth
doing
now
or
later,.
B
C
Yeah
sorry,
my
computer
basically
crashes,
so
I
can't
we.
B
C
There
isn't
there
is
an
issue
that
I've
heard
about
where
the
goal
this
is,
for,
I
think,
for
plan
issue,
issue
board
type
stuff,
but
it's
sort
of.
I
think
it
sounds
similar
where
the
idea
is
to
basically
take
what
we
would
currently
show
as
a
list
and
view
it
as
a
spreadsheet
that
you
can
edit
or
view
it
as
a
you
know
view
as
all
these
different
types
of
of
ways.
Basically,
I
don't
know
if
you've
ever
used
notion
but
kind
of
like
restructuring
a
little
database
in
different
types
of
views.
D
Yeah,
maybe
maybe
I'm
not
sure,
I
know
that
we
have
like
an
epic
to
look
into
the
merge
request
list
and
make
it
more
powerful
and
and
but
also
simpler
at
the
same
time,
because
we
have
so
much
information
in
there.
We
haven't
prioritized
that
yet,
but
that
could
be
one
of
the
solutions
to
have.
You
know
basically
a
view
toggle
where
you
can
switch
between
lists
cards
board
timeline
table
whatever
it
is,
might
be.
B
F
Yeah,
I
would
suggest
that
we
wait
for
a
title
search
for
issues
to
be
merged
before
actually
rewriting
any
of
the
mr
list
to
view,
because
it
turns
out
that
issues
already
have
such
a
functionality
to
search
for
titles
only
and
it
has
to
be
a
drop
down
where
you
select
in
which
part
of
the
like
issue
you
want
to
search,
you
can
search
everywhere.
You
can
search
in
title,
you
can
search
in
description
and
there
has
to
be
a
drop
down
in
the
filtered
church.
F
So
my
guess
is
that
the
component
itself
has
to
be
updated
first.
So
then
we
can
apply
the
same
logic
in
the
mr
list
because
a
mod
list,
I
think,
also
should
have
this
functionality
yeah
and
also
the
filter
search
itself
is
okay
to
work
with,
but
the
current
approach
in
the
issues
list
how
they
deal
with
searching
is
far
from
perfect
from
my
point
of
view,
and
that
is
the
most
complex
part
of
the
issues
list.
So
I
suppose
we'll
have
to
deal
with
exactly
the
same
problems
in
the
mrlis.
F
B
To
the
the
plan
team
about
this
tennis
left,
like
the
the
problems
you
found.
F
B
B
Okay,
I
can,
I
can
help
bridge
that
because
it
definitely
makes
sense,
but
this
is
also
we're
not
going
to
start
this
in
the
next
milestone.
It's
like
much
more
ahead,
so
we
have
time
to
do
that
thing
definitely
makes
sense
to
make
that
better
before
we
pick
it
up.
B
Okay,
thank
you.
So
much
for
the
thoughts
I'll
keep
this
topic
coming
back.
Next
I
saw
I
saw
this
merge
request
that
edwardo
had
merged
for
metrics,
and
I
wanted
to
have
a
brief
discussion.
How
do
you
all
think
that
we
could
have
avoided
this?
I
saw
kai
from
what
I
understood
this
kind
of
like
pollutes
the
data
a
little
bit
and
then,
when
you
open
the
revert
about
jupiter
notebooks,
that's
the
context,
and
I
was
wondering
how
could
we
have
avoided
it?
B
A
I'm
also
like
sitting
here,
fixing
a
broken
pipeline
on
it,
and
I
was
looking-
and
you
said
that
I
was
like
how
could
I
prevent
it,
and
I
was
like
oh,
I
should
go
add
a
note
to
like
the
top
of
the
aggregated
metrics
file.
That
says
like
this
is
for
user
accounts
only,
and
then
I
looked,
and
there
is
a
note
in
there
that
says
it's
for
user
accounts
only
so
like
it
just
wasn't.
A
I
don't
know
I
don't
have
any
good
answers
for
you
on
like
a
better
way
to
review
that.
I'm
not
sure
if
outside
of
like
myself
and
probably
mark
who
are
the
people
who
have
like
only
worked
in
this
aggregated
file
like
I'm,
not
sure
anyone
would
have
caught
that.
That's
just
like
immediately
or
no
necessarily,
and
so
it's
it
could
just
be
like
a
knowledge
thing.
A
There
might
be
something
we
could
do
with
a
spec
which
is
well
beyond
my.
My
my
skills
to
like
metrics
are
defined,
and
I
think
they
say
if
they
are
a
count
or
like
a
user
metric.
I
think
we
have
a
way
to
distinguish
between
counted
metrics
and
like
user
base
metrics
in
the
the
yaml
file.
So
maybe
we
just
like
write
a
spec.
Maybe
we
update
the
spec
for
the
aggregates
to
like
it
currently
has
like
a
manual
exceptions
list.
A
B
Okay,
maybe
if
you,
if
you
want
to
create
an
issue
or
something
that
we
can
then
pick
up
later,
once
we
have
this
solved.
Okay,
that's
that's
just
wanted
to
bring
it
up.
Thank
you
so
much
and
yeah,
and
then
I
have
it
read
only
just
go
and
watch
listen.
You
can't
watch
it.
Audio
podcast
dummy
yeah
just
go!
Listen
to
thomas
making
a
song
proud.
So
that's
it
any
last
minute
points
from
anyone.
B
E
B
Okay,
thank
you.
So
much
then
great
to
see
everyone.