►
From YouTube: 2022-08-23 Code Review UX 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
Cool
thanks
guy
all
right
so
fyi.
I
we
were
supposed
to
discuss
today.
The
rollout
of
the
in-product
survey
for
merge
requests,
but
stanislav
isn't
able
to
join.
So
I
moved
that
point
to
tomorrow's
weekly
sync,
which
is
in
the
agenda
above
ux
sync
agenda
points
so
we'll
discuss
that
tomorrow,
but
I
wanted
to
discuss
the
validation
efforts
for
the
restructured.
A
Mrs
and
we,
this
is
part
of
the
kr
that
we
have
to
this
quarter,
to
create
five
issues,
which
is
a
very
very
you
know,
round
number
but
yeah
five
issues
to
that
are
in
planning
breakdown,
phase
that
we
can
then
have
engineers
take
a
look
and
implement
in
the
next
quarter,
but
yeah
validate
and
create
five
issues
to
start
implementing
and
I
haven't
recorded
yet.
A
But
I
tomorrow
I
will
record
a
a
walkthrough
of
the
mid
fidelity
mockups
that
I've
been
designing
to
that
explain
what
we've
been
are
working
on.
What
are
the
ideas
that
we've
explored
and
how
do
they
contrast
with
what
we
have
today
and
let
me-
and
I
also
link
there
to
a
comment
in
this
issue
so
which
is
the
research
issue?
A
It's
confidential,
but
I
mean
it's:
it's:
okay,
first
to
post
this
recording
publicly,
there's
nothing
confidential
in
what
I'm
showing
but
yeah
validates
two
design
concepts
for
the
third
hypothesis
through
structure,
mrs
and
I
laid
down
some
thoughts
on
what
what
we
could
validate
or
not
right
now,
and
it's
a
lot
of
things
and
a
lot
of
questions,
and
but
there
are
basically
yeah
five
main
things
so
new
comments,
tab,
a
minimal
activa
log
in
the
overview
tab,
a
new
reports,
tab
for
code,
quality
security
and
other
reports.
Today.
A
A
I
might
have
been
able
to
add
this
to
a
another
kr
that
we
have
in
the
ux
department,
which
is
to
build
a
business
case
to
invest
in
something
like
this.
That
would
have
a
single
place
in
the
code
review
experience
for
people
to
review
the
outputs
of
ci
reports,
artifacts
and
all
of
that-
and
I
talked
with
andy
volp
today,
staff
product
designer
from
secure
and
he's
working
on
that
kr,
and
maybe
they
will
be
able
to
take
this
on
and
design
and
further
validate.
A
This
idea
of
a
reports,
tab
and-
and
so
the
focus
that
I
think
we
should
have-
is
the
new
comments
tab
and
this
minimal
activity
log
in
the
overview
tab,
and
so
that
would
look
something
like
this.
So
in
the
these
are
you
know,
mid
fidelity,
mockups
that
I,
as
I
said,
we'll
share
more
in
depth
tomorrow
in
a
video
walkthrough
that
I
will
record.
But
essentially
we
have
a
new
comments.
Tab
here
at
the
top.
A
A
Nothing
is
threaded,
and
you
just
see
things
coming
in
as
events
from
most
recent
to
the
oldest
and
when
you
click
on
something
here
in
the
activity,
feed,
maybe
like
something
that
tina
smith
approved,
and
she
left
five
comments.
A
You
could
click
here
or
go
to
the
comments,
tab
and
you
would
see
a
dedicated
view
for
the
the
comments,
and
I
think
this
is
the
most
impactful
thing
or
idea
of
all
of
the
ideas
that
we've
explored
the
most
impactful
one
that
we
could
work
on
and
if
we
could
deliver
this
as
a
small,
yet
significant
improvement,
I
think,
will
be
make
everyone's
life
better
when
reviewing
and
but
the
question
I
have
is
about
how
we
should
research
this,
if
we
should
research
all
of
the
concepts
together.
A
So
the
fact
that
we're
removing
the
commits
tab
and
the
pipelines
tab
and
adding
this
reports
tab
and
adding
the
comments
tab
or
if
we
can
focus
solely
on
adding
this
comments.
Tab
and
this
minimal
activity
log,
because
the
two
are
so
related
that
I
feel
like
if
we
just
add
this
new
comments,
tab
and
validate
that
it
could
be
confusing.
A
If
we
still
have
the
threaded
comments
below
and
the
ability
for
you
to
add
comments
here
as
well,
it
will
feel
very
duplicated,
maybe
from
a
iteration
standpoint,
like
the
order
in
which
we
ship
things.
If
the
first
thing
we
ship
is
just
the
comments
tab
with,
like
all
of
the
comments
here
that
might
work
but
long
term,
it
might
be
confusing
if
we
still
keep
the
activity
log
as
it
is.
So
I
would
like
to
see
us
validating
the
comments,
tab
and
the
activity
in
its
more
minimal
form,
first
and
and
yeah.
A
A
I
wonder
if
it
could
be
confusing,
since
both
terms
are
very
similar
looking
and
you
just
go
in
and
might
not
even
notice
that
we
have
a
new
comments,
tab,
which
is
something
that
we
can
also
validate
right.
We
can
also
always
have
a
prototype
that
keeps
the
commits
tab
here
and
see
if
it
raises
confusion
and
if
we
need
to
remove
the
commits
tab
first
before
introducing
the
comments
tab
or
if
we
can
add
the
comments
tab,
while
we'll
still
have
the
commits
tab.
B
I
was
just
gonna
say
I
don't
know.
If
we
have,
I
know
we
don't
have
enough
room
for
five
tabs,
so
I
think
we're
gonna
have
to
always
stick
with
four.
Unless
when
we
start
you
know
the
unresolved
threads
component
and
then
when
you.
C
A
Exactly
yeah,
so
the
the
good
news
is
that
the
all
of
the
unresolved
like
in
this
case.
Well,
I
picked
the
best
murder
request.
It
doesn't
have
any
end
result,
but
the
unresolved
navigation
here
unresolved,
threads,
okay,
yeah!
Thank
you
another
great,
mr,
but
yeah.
A
All
of
this
would
go
into
the
comments
tab
because
you
would
be
able
to
filter
and
jump
between
threads
here.
So
I
think
we
can
solve
that
in
the
comments
tab
and
would
give
us
all
of
this
space
here
at
the
top
to
work
with
whatever
we
wanted,
but
yeah
you're
right
that
I
mean
having
more
tabs.
It's
not
good.
C
A
So
I
mean
if
we,
if
we
can,
if
we,
I
think
we
can.
As
I
said,
you
know
tomorrow,
I'll
be
recording
that
walkthrough
and
I
think
that
can
give
more
context
into
the
ideas
and
nothing
is
set
in
stone.
A
But
I
do
feel
that
from
what
will
be
presented,
the
strongest
one
that
we
could
pursue
in
code
review
in
our
group,
because
there
are,
you
know
this
idea
of
the
reports
tab
and
even
removing
the
pipelines,
tab
and
just
having
you
know,
links
to
previous
pipelines
here
in
this
widget
in
the
status
of
the
overview.
These
are
things
that
I
feel
we
can
hopefully
delegate
to
other
groups
and
have
them
do
that
validation
and
design
work
in
parallel.
A
But
for
us
in
code
review,
I
feel
like
the
strongest
idea
we
can
pursue
right
now
is
having
a
comments
tab
and,
at
the
same
time
trying
to
redesign
the
activity
so
that
it's
more
minimal
easy
to
read
and
doesn't
have
as
much
clutter.
But,
as
I
said,
I'm
unsure.
If
we
need
to
validate
if
we
can
validate
in
a
vacuum,
the
comments
tab
edition
or
if
we
also
need
to
factor
in
the
removal
of
the
commits
tab
or
other
things.
As
part
of
this.
D
D
So
if
people,
if
you're,
not
planning
on
having
the
commits
tab
and
the
comments
tab
exist
at
the
same
time
together,
don't
show
anybody
that
if
they
ask
hey
what
happened
to
the
commits
tab,
we
can
probe
and
say
like
hey.
Well,
what
would
you
expect
to
find
that
information
now
and
things
like
that
and
yeah?
That's
basically
does
that
answer
your
question.
A
In
part,
because
my
the
challenge
here
is,
we
can
certainly
design
and
flesh
out
the
ideal
and
state
where
we
would
like
to
end
up,
but
we
also
have
to
see
if
the
way
we
iterate
and
ship
things
makes
sense.
So
imagine
that
removing
the
commits
tab
and
putting
that
information
elsewhere
is
a
lot
of
work,
and
we
can't
deliver
that
at
the
same
time
of
the
comments
tab.
A
Will
it
be
confusing
that
we
have
two
tabs
commits
and
comments
at
the
same
time
with
very
similar
names
and,
as
I
said,
that's
something
that
we
we
can
try
to
test
as
well.
But
so,
basically
my
question
is:
should
we
validate
the
iterations
or
should
we
validate
the
ideal
end
states,
or
should
we
validate
both.
D
I
guess
it
depends
on
sort
of
the
time
that
each
iteration
is
going
to
have
to
stick
with
people
right
if
it's
going
to
be
six
months
that
they're
gonna
have
to
live
with
two
very
similarly
named
tabs
next
to
each
other,
I
mean
yes,
I
can
tell
you
that
some
people
will
get
confused.
D
A
A
You
know
comments
and
commits
at
the
same
time,
for
I
don't
know
like
nine
months
until
they
upgrade
again
to
a
new
version,
so
I
think
we
always
have
to
balance
that
and
understand
that
whatever
we
ship,
if
it
is
on
by
default,
if
it's
not
like
behind
a
feature
flag
or
anything
if
it's
on
by
default,
some
instances
and
many
users
will
be
stuck
so
to
speak
with
that
for
a
long
time.
B
Is
there
a
reason
we
can't
build
this
behind
a
behind
a
feature
flag
similar
to
the
navigation
redesign
that
we
did
a
few
years
ago.
That
way,
no
one
will
be
stuck
with
these
less
than
ideal
iterations.
A
Yeah
sure
we
I
think
we
can
do
that,
I'm
not
seeing
a
reason
why
we
can't,
since
we
seem
to
we
can
confine
this.
You
know
just
like
at
the
project
level
or
group
level,
and
it's
not
like
it's
adding
new
functionality.
It's
basically
yeah
just
rearranging
things,
and-
and
so
I
think
we
can
do
that.
A
Yeah,
that's
also
a
good
idea
at
this
point.
I
don't
have
a
strong
opinion
on
whether
we
should
have
a
like
a
preference
or
a
beta
program
for
this,
but
definitely
a
future
flag
yeah.
I
think
this
warrants
a
future
fight,
because
it's
it's
a
critical
change
or
couldn't
be
a
critical
change.
A
Yeah,
and
I
think
you
know,
ben
what
you
were
saying
of
like
testing
both
the
ideal.
Like
the
end
state
and
the
in-between.
I
think
what
you
just
said,
I
mean
we
could
have
a
prototype
more
fleshed
out.
Of
course,
this
is
just
mid-fidelity,
there's
a
lot
of
things
missing
here,
but
we
could
test
both
this
view
where
you
just
have
these
tabs
and
we
can
also
test
another
one
where
we
add
the
like.
A
D
Yeah
I
mean
that
that
makes
sense
to
me.
I
I
think,
if
that's
really
something
we're
gonna
have
to
live
with.
As
an
iteration
sure
I
mean
I've
tested
things
like
this
I'll
tell
you
that,
like
some
percentage
of
people,
will
click
on
the
wrong
thing,
it
will
be
that
if
they're
not
semantically
similar,
but
as
long
as
the
content
is,
is
fairly
different,
it's
not
like
a
critical.
D
It's
unlikely
to
be
a
critical
path,
error
right,
so
yeah.
I
guess
I
would
just
say
you
know,
let's
be
thoughtful
about
the
iterations
that
we
put
out,
given
that
people
might
be
stuck
with
them
for
a
long
time
and
try
to
make
them
as
congruent
as
possible
or
whatever
you
want
to
call
it
livable
yeah,
but
yeah.
You
know,
I
think,
testing
the
end
state
is
a
good
way
to
to
make
sure
that
we're
heading
in
the
right
direction.
D
A
Yeah
yeah,
the
other
angle
we
can
test.
A
So
that's.
The
other
possible
angle
is
okay.
Instead
of
first
validating
the
comments
tab,
let's
focus
first
on
the
commits
and
solve
that
and
remove
the
commit
step
and
then
work
on
the
comments
tab.
But,
as
I
said,
I
think
I'm
just
thinking
out
loud
here.
I
I,
I
think,
adding
the
comments.
Tab
has
much
more
value
than
removing
the
commits
tab,
so
I'm
inclined
to
focus
our
validation
efforts
first,
on
the
comments
tab,
even
if
it
means
having
a
variation
of
a
prototype
with
a
duplicate
tab
just
like
for
com.
A
For
commits
just
to
see
how
people
respond
to
it
and
if
they're
confused
and
then
based
on
that
feedback,
we
can
then
say:
oh
actually,
we
need
to.
We
can't
add
the
comments
tab
with
the
commits
tab.
At
the
same
time,
maybe
we
need
to
first
validate
the
removal
of
the
commit
step
and
and
work
on
this
part.
First
yeah,
I'm
just
singing
out
loud.
A
C
A
C
A
D
A
Yeah
yeah,
that's
a
great
question.
Yeah.
We
will
still
have
the
comments
in
the
changes.
Tab
and
maybe
that's
something
I
need
to
add
in
here-
is
some
indication
of
comments
on
online
and
even
findings
like
security,
vulnerabilities
and
code
quality
findings.
That's
something
I'm
still
thinking
we.
We
should
keep
here
because
you
may
approach
your
work
in
a
merge
request
from
a
diff
first
angle
and
not
so
much
from
a
comments
or
reviews
angle.
A
So
that's
why
we
have
these
these
tabs
and
also
for
reports
like
the
reports
is,
if
you
you're
approaching
this
from
a
findings
perspective
like
you,
want
to
make
sure
your
code
is
compliant
with
your
organization's
policies.
So
you
go
to
the
reports
and
you,
you
know,
fix
everything
there,
but
if
you're,
just
looking
at
the
changes,
of
course,
you'll
stumble
upon
the
comments
here
and
you
can
still
make
comments
in
the
changes
yeah.
I
think
that's
fair.
C
I
think
it's,
I
think
it's
something
to
think
about.
I
think
the
other
thing
to
think
about,
and
just
since
I've
now
opened
the
can
of
hormones
and
like
feedback
here
is
like
a
tighter
collaboration,
not
that
it
hasn't
happened,
but
between
you
and
annabelle
on
this
concept
and
the
review
rounds
concept.
A
D
A
Yeah,
you
know
I
I
thought
a
lot
about
that
yeah,
so
so
the
first
parts
yeah
annabelle
and
I
are-
are
in
sync
about
this,
and
even
though
she's
exploring
the
review
rounds
or
and
leading
that
effort,
I'm
kinda
hinting
at
that
here,
but
this
is
all
like
an
exploration
like,
for
example,
like
you
can
see
here.
These
indicators
on
on
the
left,
side
and
they're
kind
of
like
hinted
at
maybe
something
that
is
new
or
unread
or
you
know,
but
it
doesn't
mean
we're
going
to
do
this.
A
It
is
just
to
give
this
a
more
realistic
look
of
how
it
could
work
and
more
sophisticated
look.
It
doesn't
mean
that
we're
actually
going
to
build
all
of
this
functionality
here,
even
the
filters
we
might
not
have
that
in
terms
of
having
the
comments
in
separate
places,
I
think
we
would
have.
We
will
have
to
live
with
that.
We
will
always
need
to
show
unless
we're
we're
very
opinionated,
and
we
say
no,
we
you
see
the
diffs
and
we
don't
show
you
any
of
the
comments
on
the
divs
like
if
you.
A
If
you
want
to
see
comments,
you
have
to
go
to
the
comments
tab
unless
we
say
that
I
think
we
need
to
keep.
You
know
showing
the
comments
here
and
also
in
the
comments
tab.
But
the
way
you
approach
it
is
is
differently.
You
know,
for
example,
as
a
reviewer,
if
I'm
looking
at
the
the
merge
requests
for
the
first
time
and
I
jump
to
see
the
changes,
I
want
to
leave
comments
here.
I
don't
want
to
go
to
a
comments,
tab
to
somehow
create
comments
and
say
which
line
and
file
I'm
commenting
on.
A
I
want
to
interact
with
the
diffs
and
leave
the
comments
here,
but
if
I'm
an
author
or
if
I'm
coming
back
to
re-review
the
merge
request,
maybe
I
go
to
the
comments,
tab
and
respond
to
reviewers
here
or
to
the
authors
and
have
this
conversation
here
before
going
to
the
changes,
tab
and
seeing
what's
new
and
which
new
files?
I
need
to
review
so
it's,
I
think
it's
different
angles
and
yeah
just
different
ways
of
focusing
on
on
what
you're
working
on
at
the
moment.
C
Yeah,
I'm
I'm
nervous
to
end
up
with
comments
on
two
tabs
at
some
point
in
the
future
like
I
would
love
to
get
to
one.
So
maybe
it's
just
something
we
can
keep
in
mind.
I
think
I
think
there's
options
there,
but
I'm
I'm
happy
to
let
this
this
play.
C
I
like
I
like
the
idea
of
a
comments
tab,
but
I'm
curious
like
how
that
meshes
with
the
concept
of
like
a
review
round
right
where
that
was
sort
of
like
a
version
of
the
mr
at
this
state
existed
here
is
the
feedback
on
the
version
of
the
mr
at
this
state.
Now
there's
a
new
round
and
here's
the
the
code
at
this
version
of
the
mr
and
the
feedback
on
this
version
of
the
emr
like
sort
of
like
how
do
the?
How
do
we
get
those
things
align
versus
like?
C
I
think
this
sort
of
still
ends
on
the
very
like
ephemeral,
sort
of
the
merge
request
changes.
Tab
is
always
the
latest
version,
and
comments
may
or
may
not
exist
there
at
all
and
like
it's
hard
to
tie
like
the
review
round
to
the
changes
tab
at
any
point.
In
time
like,
you
have
to
sort
of
only
use
the
comments
tab
to
deal
with
feedback
versus
like
thinking
about
those
things
as
like
states
and
events
and
inversions,
and
unlike
the
version
of
versions
that
we
have
today,
which
is
just
like
every
time
you
push.
C
It
randomly,
creates
a
version
like
the
like
a
more
like
concrete
version.
C
A
Yeah,
I
don't
know
I
I
think
so.
One
of
the
ideas
that
annabelle
had
for
review
rounds
is
making
those
rounds
explicit
in
the
activity
login.
Having
all
of
the
comments
that
you
made
as
part
of
a
review
together
and
able
to
filter
and
just
see
like
everything
that
that
person
you
know,
resolved
and
commented
on
and
which
threads
they
created,
and
I
still
think
that
is
here
right.
We
can
still
do
that.
That's
not
a
problem.
A
What
you're
talking
about
of
creating
versions
of
a
merge
request,
like
the
author
saying
like
this
is
version
one
two,
three
and
four,
and
starting
and
stopping
people's
reviews
according
to
those
versions.
That
is
a,
I
think,
that's
a
different,
related,
but
different
concept
from
what
annabelle
is
exploring.
Unless
I'm
mistaken.
B
Yeah,
yes,
it
is.
B
It
is
separate
it,
it
is,
I
think
that
they
do
work
well
together.
The
current
review
rounds
general
concepts
and
this
as
far
as
versions
from
the
author's
point
of
view
or
something
I
haven't
really
thought
about
too
much,
but
I
think
I
agree
with
you
I'll
need
to
look
into
that
somewhere.
A
A
Stop
reviews
work,
here's
another
version,
re-request
reviews
from
everyone.
You
know.
So
it's
like
a
start,
stop
kind
of
thing
where
you,
where
the
the
author
ships
versions
and
you
see
a
different
version
of
the
mr
every
time
they
they
go
through.
That
which
I
think
is
is
tricky
because
you
might
have
reviewers
reviewing
and
at
different
moments
like
you
might
have
a
back-end
review
and
you
do
back-end
changes
and
you're
waiting
on
front-end.
A
So
I
think
the
re,
the
versions
idea
works
really
well,
if
it's
a
like
a
one
author
and
one
reviewer
or
if
it's
a
very
simple
thing
where
you
just
have
one
like
you're
solving
you're,
not
leaving
things
open
like
you're,
resolving
everything,
and
now
you
have
a
new
version
where
everything
is
in
theory
addressed,
but
I
find
it
hard
to
imagine
how
that
can
work
when
you
have
multiple
streams
of
reviews
that
are
not
yet
are
not
completely
parallel.
A
B
B
You
make
some
changes
and
then
you
re-request
review.
I
was
thinking
their
review
comments
would
then
again
be
batched
together.
So
in
that
one
review
it
could
come
that,
like
that
front
end
person
might
have
three
reviews
with
three
versions
of
that
merge
request,
and
then
you
would
see
them
all
in
different
states.
I
don't
know
if
that's
what
we
want
to
do,
but
that's,
I
think,
that's
kind
of
what
I
was
going
with
I'll
have
to
look
at
that
more
okay.
A
All
right
yeah,
my
my
concerns
about
the
validation
are
answered,
and
I
will
comment
in
that
issue.
I
left
a
long
comment
there
six
days
ago,
for
you,
ben
and
annabelle,
don't
don't
yeah,
don't
don't
feel
like
you
have
to
respond
to
that
comment
now
tomorrow
I
will
add
a
summary
of
what
we've
discussed
here,
which
I
think
will
provide
more
direction
for
what
we
need
to
do
in
terms
of
validation.
A
And
kai
about
the
the
you
know
just
feedback.
I
know
you
can't
help
yourself
giving
feedback
on
these
things,
but
you
know
just
the
general
feedback.
As
I
said
tomorrow,
I
will
record
the
walkthrough
of
those
mid
fidelity
mockups
and
share
it
and
yeah
open
to
feedback
as
well,
and
I
can
try
also
to
have
to
share
the
designs
in
an
issue.
If
you
want
to
have
like
specific
comments
about
certain
things,
but
but
yeah
I
will.
I
will
ping
you
on
that.
C
A
B
Just
the
smidgen
or
I
just
specifically
need
kai,
I
guess
to
answer
a
few
questions
about
code
owners
in
my
review
rounds.
I'm
trying
to
you
know
create
those
placeholders
like
hey.
This
merge
request,
needs
front
and
back
and
blah
blah
based
on
approval
rules
and
code
owners.
Why
are?
Is
our
code
owner
file
just
not
very
well
written
or
is
there
no
way
to
fix
this
like
front
end
shows
up
three
times
on
many
merge
requests.
B
B
B
C
It
wasn't
anything
that,
like
I
think,
if
we
could
do
it
again,
this
would
not
be
the
code
owner's
file
that
people
would
use,
but
it
is,
it
is
how
people
have
written
it
today,
and
so
the
idea
is
that
only
a
path,
a
section
should
only
show
up
once
asking
for
approval
and
it'll,
be
everything
within
that
section
that
matches
a
rule
and
all
the
people
that
can
approve
it
so
like
if
you've
got
one
that
has
something
different
yeah.
A
Yeah,
in
this
case,
I
wonder
if
they
could
have
written
this
with
a
wildcards,
so
it
would
match
both
ee
and
without
the
ee
folder.
But
I
think.
C
A
A
C
A
A
C
A
A
No,
because
that's
the
thing
we
can't
assume
that
they
have
the
same
people
unless
it
was
written
as
annabelle
is
suggesting.
So
this
is
like
they
have
front
end.
This
is
a
front-end
section
and
we
type
out
path
and
who's
the
approver
path,
who's,
the
approver
and
what
annabelle
was
suggesting
is
section.
C
Inside
of
the
section,
but
I
guess
we
rereading
the
docs
that
doesn't
actually
sound
right.
This
sounds
like
we.
We
still
match
paths
first,
which
is
how
code
owners
works.
It
match
matches
paths,
the
sections
are
really
there
to
be
like
it
and
in
fact
the
sections
seem
like
they're
there,
so
that
you
could
give
a
path
and
two
different
groups
to
approve
it's,
not
so
that
you
can
squash
and
control
it's
so
that
you
can
have
two
different
people
approve
the
same
thing.
Yeah.
D
A
Yeah
we
would
have
to
to
change
change
or
extend
the
syntax
to
allow
you
to
do
that,
because
even
in
this
section
of
front-end
you
could
have.
I
don't
know,
or
you
know,
front-end
integration.
For
example,
we
could
have
another
group
or
other
people,
maintaining
the
front-end
integration
and
still
under
the
front-end
section.
Then.
A
B
B
D
B
C
B
A
Yeah,
it's
it's
problematic,
as
I
said,
I
think
the
easiest
way,
because
because
this
this
makes
sense
the
way
it
is
today,
but
because
we
don't
have
smart
deduplication
to
to
basically
merge
this
entry,
this
entry
and
this
entry
because
they
have
the
same
people,
so
we
would
have
to
possibly
extend
the
syntax
to
do
what
you
were
suggesting
annabelle
to
below
front-end
say
who
are
the
eligible
approvers
and
then
below.
A
We
would
list
only
the
paths,
but
the
first
line
below
the
section
would
be
the
legible
approvers
for
all
of
the
paths
below
and
that
would
allow
you
to
merge
everything
and
avoid
this
duplication.
So
you
yeah,
you
just
have
front-end
app
assets
here
then
ee
spec
front-end,
then
spec
front-end,
that's
what
you
would
want.
I
love.
C
That
it's
like
a
a
feature.
Change,
though,
like
that
the
way
you're
thinking
about
an
animal
makes
way
more
sense
and
was
the
way
I
sort
of
thought
sections
worked,
so
it
would
also
like
allow
people,
I
know
the
other
thing
people
want
is
like
multiple
approvals
in
a
section.
So,
like
that's
another
syntax
extension
that
needs
to
happen.
A
Yeah
so
I
messed
this
up,
but
it
would
be.
A
B
As
someone
who
doesn't
know
much
about
code
owners
before
looking
into
it,
this
much
this
layout
in
its
current
look
is
so
very
confusing
and
the
fact
that
it
keeps
appearing
multiple
times
they're,
not
even
all,
there's
like
merge
requests
in
the
middle
of
it.
It's
it's
just
so
very
confusing,
and-
and
I
don't
know,
I
think
it
needs
to
be
fixed
in
some
way-
the
priority.
Well,
whatever.
Hopefully
I'll,
get
rid
of
all
of
this
and
we'll
stick
it
in
a
drop
down
and
it'll
be
great.
A
A
A
D
A
A
Yeah
cool.
C
Yeah
well
thanks
annabelle
and
thanks
pedro,
it
was
great
to
see
everyone
catch
up
annabelle.
I
tagged
you
in
like
a
comment.
I
don't
know
if
you've
seen
something
that
I
sent
you
before,
but
worth
potentially
looking
at,
as
you
think
about
review
rounds.
B
Okay,
did
you
pay
me
on
it
today.
B
B
C
Well,
thanks:
everyone
have
a
good
one
and
we'll
talk
soon.
Yeah
see
you
tomorrow,
bye.