►
From YouTube: 2023-01-04 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
Welcome
everyone
back
to
the
new
year
2023..
This
is
the
first
coder
you
think
of
the
year,
so
there's
a
couple
read-onlys
for
planning
things
that
are
upcoming
tag
for
most
people
on
those
issues
as
well,
but
take
a
look
and
then
Annabelle
you've
got
sort
of
the
first
one
that
you
want
to
chat
about
for
the
new
year.
B
Yeah
I
just
got
a
ping
yesterday
on
this
issue
to
oh
optional,
merge
request
notifications
for
approvers,
so
I
haven't
really
gotten
a
chance
to
read
it's
really
long.
It's
also
three
years
old,
so
I
don't
have
thoughts
on
it.
Other
than
a
bunch
of
questions
which
I
see
you've
already
answered.
B
It
looks
like
jihu
is
going
to
be
contributing
this,
so
we
need
to
make
sure
that
we're
okay
with
the
design
and
the
implementation
plan
and
all
of
the
potential
drawbacks
and
then
just
from
like
a
surface
level.
Reading
I
was
wondering.
Wait.
You
probably
already
answered
this.
B
A
Yeah
we
can
talk
about
that.
I
I
left
you
sort
of
like
notes
on
all
the
other
things
in
risks,
and
you
can.
We
can
go
back
and
forth
on
those
if
you
want
to
chat
again,
as
far
as
where
we
add
it,
I
think
that
depends
on
how
we
approach
it.
A
The
way
I
think
it's
proposed
in
the
issue
and
I,
don't
necessarily
have
strong
feelings,
one
way
or
the
other
other
than
that,
like
it's,
not
a
default
on
Behavior,
but
the
way
it's
proposing
the
issue
is
that
it's
a
project
setting
not
a
user
setting
and
so
the
project
would
then
opt
users
into
to
getting
this
notification
right
like
if
the
project
thinks
that
all
approvers
want
to
be
notified,
then
the
project
could
turn
that
on.
A
We
could
go
the
other
way
and
make
it
a
user
setting,
but
then
I
guess
you'd
have
to
have
like
a
user
setting
and
then
in
that
giant
notifications,
settings
area
for
users
you'd
have
to
like
be
able
to
select
which
projects
you
want
it
on
for
and
don't
want
it
on
for
right,
like
if
you
didn't
want
it
for
everything.
But
you
wanted
it
for
some,
so
I
don't
know,
I,
don't
know
which
is
the
better.
A
Neither
of
those
sounds
ideal,
but
but
yeah
I
think
those
are
so
yeah,
depending
on
what
you
think
there
I
guess
that
would
change
how
you
would.
B
Okay
and
I
don't
know
that
somewhere
I
saw,
if
you
know,
if
we
enabled
it
for
gitlab.
We'd
have
we'd
be
notified
more
than
150
people
on
every
single
merge
request.
Would
you
say
that
our
usage
of
approvers
and
code
owners
is
a
good
example
of
it
being
used
correctly.
A
That's
a
tough
question.
One
of
the
things
I
had
been
thinking
about
like
if
you
step
away
from
code
owners,
I,
don't
think
we
have
good
data
on
this.
I'd
have
to
go.
A
Every
time,
it'd
be
way
worse
than
like
our
scaled
down
code
owners
version,
which
is
still
pretty
bad
and
so
I
think
I
think
that's
fairly
typical
that
people
use
the
any
eligible
user
rule.
A
So
maybe
it's
it's
not
going
to
be
as
big
of
a
deal.
I
put
a
note.
I
don't
know
E4,
which
is
like
similar
someone's
proposing
like
changing,
get
labs
and
turn
and
review
things.
But
you
know
there's
feedback
in
there,
like
that's
small,
at
a
small
enough
scale
like
in
a
team
of
five
to
ten
or
something
right
like
or
whatever
the
arbitrary
number
is.
A
B
In
the
issue,
a
lot
of
the
comments
were
from
internal.
What
is
that
team
called
like
sales
or
account
managers?
They
were
saying,
like
you
know
so,
and
so
with
400
seats.
Once
this
feature
is
there,
do
we
know
more
about
those
companies
or
those
users?
B
Can
we
learn
more
about
them
and
then
on
the
flip
side,
I
guess
what
you're
saying
is
you
know?
Do
we
want
to
spam
1500
people
with
a
notification
that
they're
an
eligible
approver
every
single
time?
It
probably
well.
Actually,
let's
go
back
to
the
first
thing.
Do
we
know
more
about
the
users
that
are
asking
for
this.
A
I,
haven't
no
I
haven't
looked
into
what
companies-
those
are
that's
actually
harder
now,
but
it's
possible.
We
could
do
some
of
that.
The
the
other
is
like
the
issue
where
we
stopped
doing.
This
also
has
like
a
bunch
of
customer
links
in
it
that
we're
like
customers
didn't
want
this
Behavior
anymore
too.
A
So
it's
not
like
it
was
like
both
were
done
in
like
vacuums
sort
of
right
like
they're,
the
other,
the
other
one
was
like
an
intentional
decision.
You
asked
about
it
being
a
regression
and
it
was
a
regression
in
the
way
we
added
people
to
merge
requests
or
a
change
in
Behavior
I,
wouldn't
call
it
regression.
It
was
a
change
in
Behavior.
A
A
Yeah,
so
we
could
do
the
same
like
we
could
look
into
the
customers
if
you
think
that
would
help
if
you
think
it
would
help
to
talk
to
some
of
them,
I
think
I
think
by
making
it
optional
right,
like
we
reduce
the.
A
A
B
Yeah,
that
seems
that
seems
logical.
The
the
possibility
of
sending
way
too
many
emails
is
not
necessarily
our
problem
and
I
don't
mean
that
in
a
like
a
mean
way,
but
it
is
a
possibility
you're
going
to
need
to
fine-tune
the
rest
of
your
project
settings
membership
settings
to
get
the
result
that
you
want
and
I'm
assuming
the
people
that
do
want.
This
are
working
that
way
anyway,
and
the
poll
based
approach.
This
would
be
super
useful
for
that.
A
There's
another
issue:
I
added
it
in
the
related
section
too.
That's
some
of
this
sort
of
exists.
A
So
if
you
like
edit
approval
rules
on
an
openmr,
we
do
actually
send
you
an
email
that
says
you've
been
added
as
an
approver
like
that
notification
exists,
but
only
if
you
edit,
the
fruitful
rules,
which
is
a
very
weird
trigger
there.
So,
like
some
of
that
already
exists,
and
then
the
other
one
is
related,
not
related,
is
that
I
guess
we
send
you
a
to
do
in
certain
situations
as
well,
if
you've
been
at
it
as
an
approver.
A
But
not
an
email
just
a
to
do,
and
so
that
is
also
related
unrelated,
like
we
probably
need,
like
all
of
these
things
to
like
get
into
one
setting
place,
which
may
be
why
this
is
more
work
than
like
that
one
issue
is,
and
so
it
would
be
good.
It'd
be
good
to
take
a
look
at,
but
I
will
say
the
one
for
the
set
you
as
an
approver
like
to
do
is
both
the
original
and
the
the
duplicated
one.
B
Great
and
then
I
just
added
one
more
at
the
bottom
I've
seen
this
brought
up
a
few
times
and
I
don't
think
there
was.
You
know
a
conclusion
yet,
which
is
fine,
but
when
should
the
notification
be
sent
when
them
are
first
opened?
What
if
it's
in
draft
status
and
then
what
if
additional
approver
rules
are
added
after
the
fact
so
I
guess
on
open?
B
A
Okay,
yeah
I,
don't
I,
don't
know
either
I.
Think
that's.
What's
confusing
about
the
notification
right
is
it's
because
it's
not
clear
like
what
the
value
and
like
do
you
want
to
know
that
NMR
exists
or
do
you
want
to
know
that
an
MR
is
ready
for
review
and
I
think
that's
sort
of
like
the
difference
of
when
you
would
send
that
notification?
A
If
you
send
it
when
it
goes
into
draft,
then
you
as
a
person
who
could
approve
now
know
it's
something
you
could
approve
and
if
you
want
to
keep
an
eye
on
it,
you
could,
if
you
send
it,
when
we
Mark
is
ready,
are
we
telling
you
you
need
to
go
like
what
it
like?
What
is
the
purpose
of
it?
At
that
point?
A
The
other
risk
is
that,
if
you're
using
Code
owners
in
theory,
this
notification
could
fire
off
every
time
you
push,
because
you
might
have
added
a
new
file
that
touches
a
new
codon
or
trigger
right
like
so
like
yeah
I,
don't
I,
don't
have
good
answers
for
like
how
do
you
deal
with
this
on
an
ongoing
basis,
because
there's
there's
a
possibility
that
the
approver
set
grows
as
the
life
of
the
Mr
grows,
and
so
did
you
send
it
once?
Do
you
send
it
to
someone
if
they
show
up
in
a
second
rule?
A
So
I
think
those
would
be
things
to
think
about.
I,
don't
know
what.
B
A
I,
don't
know
because
to
me
this
doesn't
fit
with
like
how
we've
talked
about
review
flow
right.
When
we
talk
about
review
flow,
we
talk
about
being
really
intentional,
and
so
this
is
like
sort
of
the
opposite
of
very
intentional
and
I.
You
asked
about
it
like
in
relation
to
review
rounds
earlier
and
I
sort
of
similar,
like
I.
Don't
I,
don't
know,
because
I
think
I
think
that
they're
different
workflows
almost.
B
D
D
So
it's
kind
of
like
there's
different
levels
to
the
importance
of
these
things,
but
they
still,
if
I'm
done
with
my
pipeline
I,
might
go
into
this.
Take
a
peek
at
stuff
that
is
waiting
for
review
and
the
waiting
for
review
depends
on
the
teams,
conventions
and
settings.
So
all
this
starts
to
be
very
complicated
and
earlier
above
I
was
musing
about
adding
stuff
into
the
Mr
drop
down,
which
is
a
no-go
from
the
start,
but
it
just
starts
to
become
this
thing
where
your
talk
was
talked
about.
D
Emergency
Quest
boards
in
the
past
being
able
to
visualize
the
evolution
of
the
merge
requests
with
the
review
rounds
that
is
going
to
come
into
play
again
is
every.
Has
that
ever
been
discussed
or
it's
about
like
a
dash
dashboard
like
a
home
page,
some
code,
reviewers.
B
B
B
Okay,
I'm
not
gonna,
say
I've
heard
the
word.
Dashboard
been
thrown
around
a
lot.
I,
don't
know
if
it's
been
merge,
request
specific
but
more
like
a
dashboard
for
every
user
to
see
what
they
need
to
work
on
in
a
given
day,
so
it
would
kind
of
house
their
issues.
Merge
requests
to
do
I,
don't
know
how
it
would
work,
but
that's
I,
don't
think
I've
seen
a
number
of
request,
dashboard.
B
C
Yeah
I
mean
I.
C
My
audio
setup's
all
crazy,
but
yeah,
there's
a
I
know
that
the
foundations
team
is
like
would
like
to
work
on
dashboards
since
that's
something
that's
like
kind
of
for
every
for
every
person
across
the
whole
company.
You
kind
of
want
some
place
to
to
start
rather
than
having
to,
rather
than
having
to
to
know
where
you
go
so
a
code
reviewer
could
have
a
dashboard
and
but
I
don't
know
that
there's
been
any
real
progress
on
that.
It's
just
sort
of
a
dream,
I
think.
A
We
call
the
merge
request,
page
a
dashboard
actually
like
if
you
click
on
it
and
say
the
ones
that
are
assigned
to
me
and
in
theory
you
could
filter
that
to
like
capture
all
of
the
different
views
that
you
wanted,
but
you
can't
have
like
four
of
them
up.
At
the
same
time,
really
you
could
set
like
that
list
to
be
ones
where
you
are
an
approver
or
could
be
an
approver
or
whatever
right,
like
you
can
do
all
of
those
things.
A
I
think
the
the
next
step
and
sort
of
what
you're
talking
about
is
like
can
I
create
a
view
that
has
five
of
those
and
they're
saved
like
queries
and
then
I
like
see
all
of
that
at
once
in
some
sort
of
better
layout
and
I.
Think
yeah,
that's
the
that's
a
piece
that
I
don't
think
anyone
is
taking
on,
but
I
know
is
talked
about.
A
There's
a
working
group
for
dashboards
and
Foundations,
but
I'm
not
sure
if
they
mean
those
kinds
of
dashboards
or
if
they
mean
metrics
style,
dashboards,
I
think
they
intend
to
mean
metric
style
dashboards,
but
we're
there's
some
conflict
over
the
word
dashboard
in
the
product
in
general.
So.
D
Yeah,
probably
the
wrong
content
terms,
but
yeah
I'll
move
it
over
and
see
if
there's
anything
that
we
can
and
I'll
search
around.
If
you
have
any
issues
link
it
up,
so
I
can
jump
in
thanks
foreign.
A
They
would
like
to
pick
it
up
in
1509.
They
run
their
development
Cycles
the
same
time
as
we
do
so
that
would
be
starting
in
two
weeks,
but
I.
Think
if
you
I
think
I
think
there's
two
options:
one.
A
We
can
sort
of
work
on
it
in
real
time
as
they
put
like
an
MR
forward.
As
long
as
we've
got
some
base
foundational
things
that
we
think
we
want
done.
The
alternative
is
like
if
you
want
to
go
back
and
say,
like
here's,
all
of
the
things
that
we
have
there's
too
much
in
scope
to
like
reliably
achieve
this
within
this
time
frame,
and
we
don't
have
the
capacity
to
like
do
that.
A
That's
also
sort
of
like
an
acceptable
answer
to
go
back
and
they
might
push
in
like
want
to
find
an
MVC
and
that's
fine
like
if
there
is
something
small
that
we
could
do
then,
like.
Maybe
we
work
to
that,
but
yeah
I
think
it's
really
on
us
to
to
decide
whether
or
not
we
have
the
capacity
to
help
support
them
or
whether
or
not
we
like
the
proposal
enough
anyways.
B
My
preference
would
be
to
just
have
them
start
working
on
it
and
kind
of
collaborate
in
merge
requests,
but
I
am
going
to
be
out
for
pretty
much
that
whole
Milestone
in
February,
so
maybe
I
don't
know.
Okay
I'll
have
to
figure
that
out.
A
Yeah
I
would
say,
take
a
look,
take
a
look
at
the
proposal.
That's
in
there
without
sort
of,
like
all
of
the
other
complications
that
we
have
and
if
that's
a
place
to
start
then,
like
that's
a
place
to
start
and
then
we
can
patch
the
rest
out
into
Mars.
If
there's
something
that's
like
a
glaring
concern,
then
I
think
that's
where
it
would
make
sense
to
say
we
need
to
to
stop
on
this
and
not
not
move
forward.
A
Thanks
for
bringing
that
up
beautiful,
it's
a
complicated
one,
so
yeah
makes
sense.
That's
all
that
we
have
on
the
side
of
the
agenda,
so
I'm
gonna
hit,
stop
and
then
see
where
we
go.