►
From YouTube: Code Review Group - MR Widget Architecture Sync
Description
This is a discussion related to https://gitlab.com/gitlab-org/gitlab/-/issues/300042 and trying to determine the best path forward.
A
A
That
was
my
main
priority,
because
what
will
happen
it
and
I
think
that
we
all
have
different
goals
with
this
architecture
widget
except
for
maybe
yukai,
but
I
think
we're
all
hoping
it
will
solve
a
different
thing.
But
for
me,
what
really
kind
of
sealed
the
deal
is
our
biggest
problem
with
s1s,
s2s
and
continuous
integration
is
the
issue
will
come
in
and
it
will
take
say
it
comes
into
code
review,
it'll,
take
like
three
or
four
months
on
a
on
a
good
issue
for
code
review
to
investigate
it
and
see
what's
happening
here.
A
It's
not
always
clear,
and
also
we
have
other
priorities.
Then,
when
we
do
investigate
it,
we're
like
oh,
this
isn't
even
our
issue.
I
actually
think
it's
continuous
integration
and
then
we
kick
it
over
to
them
and
then
the
same
thing
happens
to
them.
They
don't
have
time
to
triage
it
when
they
finally
do
it's
like
they
have
to
dig
into
it.
Just
like
we
did,
and
so
it's
not
really
clear,
and
so
I
wanted
to
work
on
that
really
before
the
widget.
A
There's
also
the
concern
that
pedro
has
done
by
the
way
beautiful
work
like
exactly
what
I
had
asked
for
from
the
continuous
integration
team
is
what
pedro
spent
all
that
time
on
so
time
well
spent,
but
there's
the
concern
that
his
work
is
going
to
change
what
our
re-architecture
is,
and
we
want
to
be
super.
Mindful
of
that,
I
don't
think
that
it
will
change
anything
really.
What
we're
trying
to
do
with
the
re-architecture
is
not
necessarily
change.
A
How
we
fail,
or
even
what
the
message
is
when
we
do
fail,
but
we
just
want
to
make
it
more
clear:
where
did
it
fail
and
if
we
can
just
get
where
did
it
fail,
then
we
should
be
able
to
determine.
Is
this
our
issue?
Is
this
a
ci
issue
and
who
needs
to
work
this
issue,
so
that's
kind
of
what
changed
my
perspective
on
this.
C
C
But
for
the
time
being,
I
didn't
put
it
in
another
location,
and
I
think
that
it
should
be
in
another
location
that
is
more
easy
to
consume
and
easier
to
update
anytime.
We
make
changes
without
having
to
go
into
the
code
and
check
what
those
are,
because
I
think
it
helps
everyone
helps
not
only
the
engineering
folks,
but
also
the
design
team
and
our
users
in
figuring
out
why
the
merge
request
is
in
that
state.
A
Yeah,
that
makes
sense
we
want
to
abstract
that
work
so
that
it's
easy
to
change
and
I
think
from
the
ci
perspective,
andre,
I'm
not
sure
if
our
front
end
team
does
this
the
same
way
but
any
time.
So
if
the
end
goal
is
like
to
make
that
super
flexible
right
now
with
ci
anytime,
that
needs
to
change
it's
a
back-end
engineer
and
a
friend,
an
engineer
that
has
to
make
that
change,
which
is
like
crazy.
A
So
I
know
that's
one
of
their
main
goals,
but
that
kind
of
future
direction
will
certainly
help
there.
We
just
want
to
get
to
a
place
where
engineers
themselves
understand
where
these
things
are
happening,
and
then
in
the
future
we
can
get
to
a
point
where
it's
like.
Okay,
now
everybody
can
understand
where
these
things
are
happening,
including
our.
D
D
So
what
I
guess,
what's
not
clear
to
me,
is
like
what
are
you
proposing,
because
what
I'm-
and
I
was
my
concern-
is
that
what
ci
is
proposing
and
what
I
have
seen
is
sort
of
like
a
future
world
that
would
be
influenced
or
would
benefit
from
us
saying.
This
is
what
we
want
the
end
state
to
look
like.
A
I
agree
and
disagree
with
that.
I
think
that
probably
is
the
end
goal,
but
I
think
that
pedro
has
a
lot
of
say
in
that.
What
I
am
proposing
is
that
our
team
starts
in
cahoots
with
their
team
starts
breaking
down
these
issues
in
terms
of
what
are
the
next
steps
to
abstract,
where
these
errors
are
coming
from,
and
so,
for
example,
an
easy
example
is
the
draft
you
can't
merge
until
it's
out
of
the
draft
state,
so
an
easy
example
would
be
if
we
can
just
separate
that
failure
into
a
different
area.
A
It's
still
going
to
fail
the
same,
and
it's
still
going
to
happen
the
same.
But
as
an
engineer
now
at
least
we
understand
where
it
is
failing
at
and
then
we
can
correlate
that
back
to
code
review
and
they
they
get
really
specific
and
technical
into
that,
and
I
think
that
is
something
that
we
need
to
discuss
and
iterate
on
and
work
through.
A
D
We
want
to
build
this
json
data
structure,
that
everything
on
the
front
end
consumes
this,
and
this
is
how,
like
all
the
data
will
be
presented,
is
sort
of
their
proposal,
that
is,
that
is
re-architecting,
and
that
is
like
in
theory,
net
new
functionality
that
is
introdu
opens
up
the
opportunity
for
things
to
get
significantly
worse
before
they
get
better
right,
because
we're
now,
we
at
least
know
how
things
work
sort
of
today
more
than
we
would.
If
we.
D
We
it
at
least
works
right,
like
the
we
may
not
know
like
it
at
least
functions
at
a
level
that
we
all
sort
of
go
yeah.
This
is
not
ideal,
but,
like
push
comes
to
shove,
we
could
figure
out
how
it
how
it
happened
and
what
it's
doing,
whereas
like
if
we're
deciding
like
we
want
to
change
that
the
way
all
of
that
works
at
the
same
time
like
that,
never
not
never!
So,
there's
a
lot
of
risk
associated
with
that
versus
like
if
we're
like.
A
I
think
it's
probably
both
and
andre
can
talk
to
that.
So
I
think
the
answer
to
your
question
was
more
clear
in
the
beginning,
until
you
brought
up
maybe
the
json
structure,
which
I
really
do
support
and
again,
I
think
andre's-
probably
more
involved
in
that
than
anything.
But
from
my
perspective,
from
a
back
in
perspective,
if
we
can
taking
draft
as
an
example,
we
can
move
that
to
a
separate
location
and
then
have
just
that
respond
with
the
json
as
like.
That's
an
iterate,
an
iteration.
A
D
It
does,
I
think
I
also
I'm
not
opposed
to
going
like
sort
of
the
back
and
handling
all
the
error
and
dealing
with
this
json
structure
and,
like
the
front
end
sort
of
being
more
consumery
versus
controlling
logic.
But
if
we
are
going
to
do
that,
I
would
rather
do
that
knowing
what
we
need
to
be
at
the
end.
So
that
way
we
don't
model
an
entire
like
api
and
thing,
and
then
pedro
comes
back
and
he's
like,
oh
well.
I
want
you
to
show
eight
error
messages
and
they're
like
oh
well.
A
C
A
Basically,
what
we're
saying
is
like
true
or
false,
basically
and
pedro:
do
you
want
to
show
that
with
these
other
errors,
or
do
you
want
to
show
it
on
its
own
or
do
you
want
to
show
it
in
the
nav
bar
or
where
do
you
want
to
show
it
and
like
here's,
the
data
we've
already
got
it?
I
don't
care
where
you
put
it.
A
It
is
technically
new
if
you
want
to
look
at
it
that
way,
it's
a
new
data
response
yeah,
but
it's
still
the
same
failure.
Pedro's
work
hasn't
finished,
so
it's
still
the
same
failure.
It's
just
now
we're
sending
it
in
a
different
way
and
we
have
to
do
it
in
a
in
a
one-at-a-time
kind
of
way
and
we
have
to
really
focus
on.
What's
the
most
important.
B
A
Yeah,
I
don't
want
to
go
too
deep
at
all
anyway,
I'm
really
prioritizing
this
from
the
perspective
of
like.
Why
do
these
s2s
keep
happening?
What
are
those
problems?
Let's
do
those
things
like
you
know
we
keep
getting
s2s,
because
we
don't
understand
that
it
failed
because
of
draft.
I
don't
know
why
that's
my
easiest
example:
I'm
just
gonna
stick
to
it.
So,
let's
start
with
that
one!
Let's
do
that
one!
These
other
errors
are
super
clear.
We
always
know
how
to
handle
them
like.
A
C
C
C
I
think
that
will
stay
and
live
on,
so
I'm
comfortable
with
with
that
structure
and
later
in
the
future,
we
can
iterate
on
it.
If
we
find
that
it's,
we
need
to
do
a
very
different
way
of
presenting
and
building
those
checks.
But
looking
at
what
has
been
proposing
the
issue-
and
I
mean
I'm
still
discussing
this
with
fabio
and
waiting
for
his
response,
but
I
think
we're
fairly
open
to
what
the
structure
can
be
to
accommodate
what
we
have
today.
B
What's
what's
the
current
state
right
and
right
now,
it's
an
amalgam,
just
a
merge
merging
all
of
these
properties
together.
What
you're
describing
is
evolving
that
one
place
into
having
a
different
vocabulary,
a
different
representation,
but
we'll
be
on
that
place,
and
that
will
be
already
an
advantage
that
we'll
have
having
that
one
place
specified
rather
than
this
cloud
of
properties
that
is
like
read
by
the
front
and
interpreted
by
the
front
and
with
a
lot
of
gaps.
B
C
Yeah
that
makes
sense
to
me,
yeah
and,
and
one
thing
that
I
still
think
we
can
do
like
one
of
the
ideas
that
I
had
proposed
when
thinking
about
the
merch
checks
is
maybe
like
what,
if
in
the
future,
instead
of
just
showing
one
of
the
merch
checks,
we
show
a
list
of
all
of
them
and
say
hey.
These
are
the
ones
that
are
failing,
and
these
are
the
ones
that
have
passed
so
that
you
can
plan
ahead.
C
A
C
D
It
it
still
feels
like
there
are
two
things
happening
here
to
me,
and
this
is
my
concern
like
michelle's.
First
pitch
of
like
move
things
move
controllers
to
different
places,
so
we
know
which
file
is
called,
and
then
we
can
tell
what
the
error
is.
I
don't
necessarily
have
a
problem
with
that,
because
that's
straight
refactor
right
that
is
sort
of
the
by-definition
version
of
refactor.
D
D
D
Is
it
because
we
moved
that
thing
or
is
it
because
the
front
end
is
now
looking
in
a
different
place
to
understand
how
that
merge
check
works
because
we've
changed
the
way
we
like
try
and
deal
with
some
of
these,
but
not
all
of
them
on
the
fly,
and
I
think
that
is
to
me
like
what
I'm
concerned.
I
I
I
like
the
end
state
where
the
back
end
controls
it
all
on
the
front
end.
Does
it?
What
I
don't
like
so
far?
D
But
all
the
proposals
want
to
do
all
of
the
things
and
they
all
want
them
to
happen
all
at
the
same
time,
and
this
is
far
too
fragile
and
brittle
of
an
area
in
the
application
to
have
multiple
teams
making
significant
structural
changes
in
flight.
All
at
the
same
time
like
we
will
inevitably
increase,
like
our
s1
volume,
will
go
from
whatever
unfortunate
and
unhappy
thing
it
is
now
to
to
more.
D
Is
the
proposals
want
to
do
all
of
it
and
until
I
see
a
proposal
that
like
looks
correct
in
terms
of
doing
one
or
the
other,
and
I
don't
have
a
preference
of
one
or
the
other,
but
I
don't
want
to
do
both
at
the
same
time,
then
like
it's
going
to
be
hard
for
me
to
like
support
this
and
want
to
actually
put
this
work
in
because
it
to
me
this
is
well.
The
the
pitch
is
risk
mitigation.
D
A
Yeah,
I
don't
think
it's
that
bad.
I
understand
where
you're
coming
from,
though
so
I
think,
there's
two
different
perspective
and
that's
that's
front
end
and
back
end,
so
front
end
is
expecting
like.
Can
you
just
tell
me
the
one
thing
that
or
the
two
thing
or
whatever
it
is?
Can
you
just
tell
me
those
and
from
a
back
end
perspective,
a
lot
of
the
times
we
can
be
like
yeah?
A
A
But
the
fact
is
that
we
don't
have
a
good
grasp
yet
on
what
that
looks
like,
because
we
haven't
devoted
time
to
investigate
like
technically
how
we
would
implement
it
outside
of
that
issue,
which
is
based
on
really
the
response.
There's
work
that
has
to
be
done
to
even
get
that
response.
We
need
to
find
out
what
that
work
is,
but
I
think
we're
just
on.
I
love
pedro,
I
think
we're
just
including
pedro
to
be
collaborative
and
supportive
of
each
other.
C
I
did
all
of
that
mapping
exercise
and
because
I'm
probably
one
of
the
few
people
that
has
done
that
and
has
looked
through
all
of
the
merch
checks.
They
just
want
to
make
sure
that
hey
what
we're
thinking
is
it
align
with
what
we
have
today,
because
that's
what
we
want.
We
want
what
we
have
today.
So
it's
just
double
checking.
A
C
D
D
That
is
not
the
focus
of
where
people
every
time
this
comes
up.
That's
not
where
people
start
is
the
work
that
needs
to
happen.
First,
we
keep
talking
about
this.
Like
future
json
structure,
we
want
to
use
to
send
data
right
and
again
that's
that's
sort
of
when
you
started
and
you're
like.
Oh,
we
want
to
move
things
to
different
controllers
and
do
that
I
was
okay
with
that,
like
I
actually
think.
D
That's
a
good
if
that
helps
us
like
sort
of
more
quickly,
diagnose
things,
I'd
love
to
see
that
proposal
and
like
be
supportive
of
that,
the
the
current
one
that
exists
is
the
thing
that
I'm
not
going
to
be
supportive.
The
current
thing
that
is
being
described
is
I'm
happy
if
that
is
like
step
four
or
five,
but
I
need
to
see
steps
one
through
three.
First,
if
that's
the
case.
A
D
A
Then,
to
my
intent
with
this
call,
the
question
is
kai:
can
we
dedicate
resources
to
this
issue
to
understand
what
the
iterations
are
and
what
we
need
to
do
like?
This
is
a
spike
at
this
point
and
it
sounds
like
that's
something
you're
willing
to
do
versus
actually
work
on
it.
I'm
also
unwilling
to
work
on
it
blind,
and
so
we
need
time
this
isn't
this
isn't
the
same
kind
of
issue
as
like
what
we
investigate
for
1311..
This
is
like
we.
D
I
think
we
know
that
it's
a
lot
and
not
worthwhile
unless
we
do
the
investigation.
My
impression,
based
on
the
way
people
keep
having
this
conversation,
is
that
people
are
ready
to
like
start
building
things.
If
you
look
at
that
issue
like
that
is
in
sort
of
like
the
I'm
ready
to
start
building,
things
is
the
way
I
interpret
that
conversation
and
I'm
not
ready
to
start
building
things.
I
don't
think
our
team
is-
and
this
is
again
where,
like.
D
Yeah
ci
is
like
wants
to
go.
Do
this
thing
and
I
don't
very
nervous
that,
like
a
team
that
doesn't
own
the
merge
button
wants
to
start
going
and
doing
something
on
the
merge
button.
That
would
be
this
significant.
I
think
that's
the
difference.
I'm
100!
You
want
an
entire
engineer
for
all
of
1311
to
like
come
back
and
then
like
have
an
actual
thought
out
plan
that,
like
we
could
go
and
have
a
legit
conversation
about
sure.
I
will
give
you
an
entire
engineer
for
all
of
13
11..
B
A
Because
coming
from
my
perspective,
like
the
question
that
I
just
asked
kai,
I
immediately
said
no
two
weeks
ago
to
this:
it's
not
worthwhile.
We
should
not
even
look
into
it
because
we
have
these
other
problems
and
now
I'm
at
a
point
where,
like
we
should
look
into
it
but
yeah.
I
do
agree,
there's
a
difference
there
as
well
within
the
teams-
and
I
don't
know-
maybe
this
is
something
they
can
start
working
on
when
we
oversee
it.
But
I
don't
even
know
that
I
don't
even
know
that
yet.
B
B
Can
I
I'm
good
okay,
so
one
of
the
things
that
I
was
thinking
about
is
we
would,
we
would
be
very
it'd,
be
very
beneficial
for
us
to
have
some
sort
of
representation.
So
that's
what
I'm
expanding
here
on
this
on
this
deep
point
we
could.
We
could
get
the
benefits
of
having
some
machine,
readable
representation
of
the
current
state
of
the
merger
quest,
widget
state.
A
B
It
will
allow
us
to
do
better
debugging
and
we
will
already
be
reaping
the
benefits
of
decreasing
the
time
it
takes
to
investigate
the
s1
and
s2
bugs
without
affecting
the
current
status
of
the
application.
Until
we
have
the
final
guidance
on
from
pedro
just
a
thought.
We
don't
have
to
have
the
answer
right
now,
but
I
thought
I'd
advise
it.
B
B
A
B
A
B
C
Yeah
my
my
points,
I
think
it's
one
of
the
most
important
ones
is:
if
we
want
to
talk
about
capacity
who
will
be
leading
this,
because
I
don't
like
that.
Another
group
is
leading
this
not
that
they
are
not
going
to
do
a
good
job,
but
we
should
be
on
top
of
that
110
and
having
them.
Work
with
us
is
amazing,
and
it's
really
good
that
they
are
able
to
do
that,
because
we
can
share
the
knowledge,
but
we
should
be
driving
this
because
we
don't
know
like
one
year
from
now.
C
If
the
ci
team
will
be
as
interested
in
it.
We
will
always
be
interested
in
this,
so
I
would
really
like
for
our
engineering
team
to
be
leading
this
if
possible.
Carrie.
I
think
she's
been
involved
a
lot
and
I
don't
know
if
at
this
point
we
need
front-end
representation.
But
if
we
do
someone
yeah,
oh
okay,
but.
B
B
D
D
D
D
B
I
think
we
can
make
that
clearer.
I
I
want
to
make
sure
I
think
it's
important
to
to
acknowledge
that
for
us
to
take
ownership
of
this,
we
have
to
show
movement
and
that's
what
we're
showing
in
investigating
in
1311,
because
if
we,
if
we
call
for
ownership
and
then
we
don't
move
anything,
it
just
seems
like
we're
blocking
them.
B
B
D
I
think
we
just
need
to
set
expectations.
I
mean
we
should
all
be
very
clear
that
we
could
come
out
of
1311
and
still
decide.
We
don't
want
to
do
this
right
and
I
think
like
that,
needs
to
be
made
clear
to
them
that
if
we
come
out
and
decide,
we
don't
want
to
do
this
like
that,
doesn't
mean
we
want
you
to
do
it
either
we
sort
of
like
this
is
a
bigger
fish
than
we
like
anyone
needs
to
take
on
right
now.