►
From YouTube: 2022-07-07 Working Group: Merge Request Report Widgets
Description
Weekly call for the working group Merge Request Report Widgets
Agenda:
https://docs.google.com/document/d/1bcch8UUkwmgEHFolTWDrQFJtUiiXlv_yQFAGwSSDSUE/edit
A
Hi
everyone
welcome
to
yet
another
weekly
meeting
for
the
merge
requests,
report,
widgets
working
group
and
we'll
get
started
with
the
first
initial
checks.
So
looking
at
the
the
checklists
for
the
launch,
have
the
blockers
been
solved?
I
would
say
yes,
unless
somebody
said
knows
anything
else
that
I
don't
know
about.
A
Okay,
give
it
two
seconds.
I
think
that's
enough
feature
flag
enabling
production.
That's
a
yes
and
feature
flag
defaults,
yes,
has
been
enabled.
So
that's
great.
So
that's
so
that
just
signals
that
customers
will
start
getting
this
with
15
2
and
then
we'll
we'll
we'll
hear
back
from
them.
If
anything
comes
along
like
not
positive
to
to
fix,
but
we're
we're,
we
have
good
hopes
and
regarding
the
working
group
wrap
up,
so
we
can
consider
the
widgets
released,
I
would
say,
and
the
documentation
has
been
reviewed
and
completed.
A
A
So
I
consider
that
a
yes
so
for
now
I
would
I
would
say
I
will
keep
the
calls
going
for
yet
until
after
the
release
of
15-2,
just
so
in
case,
something
comes
up
from
from
testing
and
all
that
stuff
from
customers.
But
we
should
be
looking
to
wrap
up
the
working
group
soon
so
do
prepare
for
that,
and
that
doesn't
mean
that
there
won't
be
technical
efforts
beyond
the
working
group.
But
those
will
happen
outside
of
the
context,
with
the
normal
process
of
reviews
and
involving
the
right
people.
A
A
Well,
good
cool,
so
yes,
the
announcement
that
we
have
here
is
that
the
the
feature
flag
has
been
enabled
by
default,
which
is
great
thanks,
phil,
and
thank
you
for
for
announcing.
We
don't
have
any
discussion
items.
Does
anybody
have
any
before
we
go
on
to
the
technical
one.
A
B
I
would
add
it
is
technical,
but
I
think
it
the
the
the
question
it
brings
up,
comes
into
the
trade-off
between
flexibility
and
consistency,
and
I
think
ux
needs
to
have
a
voice
in
that.
A
C
Yeah,
I
I
was
gonna
say
the
same,
because
the
the
solution
also
involves
the
the
ux
team,
so
so
yeah
I
think
most
of
us
is
like
I
created
an
issue
regarding
the
the
technical
limitations
on
the
extension
api
and
I
documented
it.
I
left
a
link.
C
If
you
haven't
checked
it,
I'm
not
gonna
get
I'm
not
gonna
go
through
the
details
right
now,
but
basically
the
the
the
summary
is
that
the
the
extension
api
in
some
cases
is
very
restrictive
for
the
developer
and
we
have
to
come
up
come
up
with
workarounds,
which
include
some
not
very
happy
solutions,
and
so
basically
it's
it's
very
javascript.
It's
like
using
vanilla
javascript,
whereas
I
think
a
few
years
ago,
gitlab
moved
to
vue.js.
So
the
solution
is
leveraging.
C
Djs
for
this
is,
I
think
everyone
left
the
comments
there,
so
we
were
on
from
my
understanding
I
spoke
with
with
with
yannick
with
fernando
I
notified
phil,
and
everyone
was,
as
far
as
I
know,
is
on
board
to
to
go
with
the
solution
that
uses
new
components.
So
we
keep
the
logic
right
now.
What
we
have
built.
C
The
logic
remains
the
same,
but
instead
of
centralizing
the
whole
presentational
logic
in
a
base
view
component
we're
going
to
come
up
with
a
component
that
accepts
slots
so
like
gitlab
ui
and
then
we're
going
to
use
that
for
for
the
skeleton,
so
the
skeleton
is
going
to
be
the
same.
The
logic
is
going
to
stay
in,
say,
stay
the
same
so
visually
it
shouldn't
change
anything!
It's
just
that
how
we
develop
it's
gonna
change.
C
So
for
the
are
there
any
questions
so
far,
no
okay
cool!
So
for
the
implementation
plan.
What
I
thought
is
the
security
widget
is
pretty
complex,
so,
for
instance,
when
you
click
on
the
model
so
that
we
display
a
list
of
vulnerabilities
and
when
you
click
on
the
vulnerability,
we
display
a
model
and
that
model.
C
If
you
check
the
code,
it's
that
file
is
800
lines,
so
I
have
to
re-uh
do
the
same
work
to
make
it
work
for
the
extension
api.
So
that's
where
actually
I
was
blocked
and
the
implementation
plan
that
I
had
in
mind
is
basically
using
the
security
widget
as
a
pilot
and
then
build
this
presentational
component,
use
it
for
the
security
widget
and
and
then,
if,
if
everything
goes
well,
we
roll
out
one
by
one,
the
other
widgets.
It
shouldn't
be
a
big
word,
because
it's
not
a
complete
refactor.
C
It's
just
the
way
how
we
represent,
how
we
develop
the
presentational
logic.
So
it's
the
the
the
business
logic
is
gonna
stay
the
same
and
the
ux
is
concerned
because,
right
now
we,
the
code,
is
it's
supposed
to
be
flex
strict,
but
with
solutions
like
html
injection,
it's
actually
not
very
strict
and
we
do
actually
html
injection
in
some
cases.
C
So
and
but
we
sacrifice
efficiency
for
for
for
being
strict
for
consistency.
I
think
the
consistency
should
be
re
sold
in
the
code
review
with
code
review
guidelines.
C
So
that's
basically
the
idea
of
the
technical
discussion.
I
think,
if
it's
not,
if
you
have
any
questions,
just
let
me
know
I
can
clarify.
A
No
thank
you.
My
my
worry
was
that
exactly
yeah
in
the
beginning,
we
started
discussing
the
code
allowing
what
the
framework
allows
you
to
do,
but,
like
you
said
very
well
like
by
using
the
methods
we
have
right
now
you
could
inject
something
that
is
not
part
of
the
framework
today.
So
I
don't
think,
there's
a
a
change
in
in
regards
to
that
so
much
so
that
we'll
keep
continuing
checking
for
consistency
on
the
code
review.
A
It's
just
that
it
makes
your
life
easier,
because
it
then
goes
to
to
a
view
component
approach
rather
than
a
method
from
javascript.
So
all
of
that
seems
like
a
very
obvious
and
logical
evolution
of
the
code,
so
from
my
side-
and
I
checked
chatted
with
phil
this
week
and
we
have
no
objections
about
moving
this
forward.
A
C
Okay,
that's
pretty
nice
yep.
D
Jeremy
yeah,
I
was
gonna,
ask
in
regards
to
get
lab
ui.
Would
you
actually
build
this
in
gitlab
ui.
C
Well,
the
same
question
came
from
andre
and
the
answer
to
that
was,
I
didn't
think
it
like
that
but
like
if
so
initially
we
we
would
build
it
in
in
gitlab,
but
then,
if
it's
something
that
can
be
reused
across
different
places,
so
why
not
moving
it
to
gitlab
ui,
because
it's
gonna
be
a
presentational
component.
It's
gonna
accept
some
some
some
methods
like
what
we
do
today
with
the
extension
api
and
that's
gonna
present
the
component.
D
Okay,
yeah,
I
I
my
original
hope
was
to
actually
have
it
in
gate,
lab
ui
and
because,
when
I
designed
this
abstracted
out
a
lot
of
pieces
that
I
felt
could
actually
be
used
elsewhere.
So
if
you
don't
mind,
I'm
just
going
to
share
screen
really
quick
here,
and
this
is
this
is
purely
conceptual
design
here,
so
nothing,
that's
actually
moving
towards
production
or
anything
but
working
on
some
redesign
efforts
for
different
areas
of
the
product.
D
So
if
you
look
at,
for
example,
on-call
schedules-
and
it
has
this
kind
of
a
layout
already-
where
we
have
this
the
chevron
we
have
controls,
we
have
content
being
able
to
leverage
that
the
mr
widget
structure
for
something
like
this,
where
we
have
controls
in
the
in
a
similar
way
and
abstract
out
that
presentation
layer
would
be,
you
know
a
huge
win
to
have
in
gitlab
ui.
D
D
So
I
would,
I
would
love
to
to
have
it
there
and
kind
of
vote
for
that
that
abstraction,
if
possible
and
and
in
that
way
too,
we
could
update
the
actual
pajamas
documentation
right
now,
we're
using
just
like
figma
embeds
for
it
to
to
represent
items,
and
it
would
be
awesome
to
actually
have
live
coded
examples,
and
in
that
way
we
would
have
more
checks
and
balances
for
qa
to
say:
oh,
what's
acceptable
in
a
slot
and
how
do
things
work
in
there
for
the
widget
and
be
able
to
more
quickly
build
that
out
and
adapt
it
and
have
actual
code
that
we
can
check
against?
D
So
I'm
I'm
all
for
that.
C
So
that
that's
a
pretty
good
suggestion
now
that
I
see
the
the
other
designs,
I
think
that
having
one
component
and
then
using
it
for
for
similar
use
cases,
it
definitely
makes
sense.
But
what
I'm
going
to
suggest
is:
let's
iterate
on
this.
First,
maybe
we
start
with
the
with
the
with
the
with
gitlab
and
then
we
adapted
for
dmr
widget,
and
then
we
extend
it
to
gitlab
ui,
because
right
now,
if
we
go
probably,
if
we
try
to
cover
all
use
cases,
it
may
complicate
our
our
life.
C
So
what
I'm
going
to
suggest
is
just
put
it
on
gitlab
right
now
and
then
move
it
to
gitlab
ui.
But
if
we
can
collaborate
on
this,
so
that
I
know
the
use
cases
while
I
develop
the
the
the
component
so
that
for
future
it's
gonna
be
easier
to
migrate
it
to
a
gitlab
ui.
I
think
it's,
it's
even
better.
E
Fantastic
just
a
quick
proposal,
you
kind
of
already
said
it's
a
rush,
but
just
proposing
that
it
might
be
super
beneficial
to
now
pair
up
with
ux
and
in
a
dry
run.
Let's
speak
about
potential
component
because
it
won't
be
one
mr
rigid
gitlab
ui
component.
It
is
going
to
be
probably
a
zoo
of
them
so
teaming
up
with
ux
now
and
speaking
up
with
what
would
potential
gitlab
ui
components,
what
would
be
of
use
would
probably
be
pretty
helpful.
A
But
so
that
just
to
understand
this
right,
it
wouldn't
be
so
what
jeremy
was
showing.
It
feels
like
there's
a
an
abstraction
thing.
We
can
do
and
have
the
basics
like
name
it,
something
generic,
not
something
specific
to
merge
across
widget.
Just
like
a,
I
don't
know,
not
a
not
an
expansion
accordion,
but
like
a
name
for
the
concept
that
will
go
into
the
github
ui,
but
then
it
would
still
allow
you
to
because
I
think
he
wants
to
use
the
ui,
not
particularly
the
mechanics
of
the
magical,
switching
that
right.
A
A
Okay,
absolutely
okay,
we
have
mark
you,
have
a
question:
you're,
muted,.
B
You
stole
my
point,
andre,
that's
exactly
what
I
was
going
to
say,
not
that
you
could
have
known
sorry
yeah
exactly
so.
The
mr
widget,
as
in
the
issue,
is,
is
quite
specifically
about
merge
requests,
whereas
the
designs
are
more
collapsible
container.
B
I
don't
know
what
you
would
want
to
call
that
kind
of
thing
or
sort
of
grouped
container.
I
don't
know
something
generic
exactly
so
I
had
a
further
point
on
that,
so
I
think
the
collapsible
container
can
definitely
go
into
git
lab
ui.
That
makes
a
lot
of
sense.
The
mr
widget
that
is
based
on
top
of
that
probably
belongs
still
in
git
lab,
because
it's
very
gitlab
specific
merge
request,
specific
even
so.
A
My
question
there
is:
can
these
two
things
be
accomplished
in
the
same
effort
like
extracting
that
collapsible
component
collapsible
container
into
gwi
and
also
build
this
thing
or
are
those
two
separate
efforts?
I
think.
C
We
need
a
spike,
so
first
need
to
collaborate
with
the
ux
and
then
see
what
exactly
is
being
done,
because
if
we
just
extract
one,
it's
one
one
component
like
the
container:
it's
like
the
gl
card
component
and
then
we
put
whatever
we
want
inside
it.
So
it
depends
on
what
are
the
use
cases
see
what
we
can
reuse
and
whatnot.
So
if
I
have
an
overview
of,
if
we
have
an
overview
of
what's
being
expected,
I
think
we
can.
A
Okay,
thank
you
yeah.
Definitely,
we
should
create
issues
for
that
then.
So
we
can
track
those
two
so
one
we
already
have
the
proposal
the
v2,
but
we
can
probably
create
an
issue
for
that
spike.
Can
you
take
care
of
that,
create
the
issue
and
then
follow
along
with
that
thanks?
We
have
raised
hands.
Jeremy
mark,
I
don't
know
who
was
first
jeremy
go
ahead
thanks.
D
Yeah,
so
the
dimension
of
the
card-
that's
exactly
what
I
was
gonna
say.
So
it's
very
similar
to
that
and
just
a
little
background,
I'm
working
on
an
effort
for
pajamas
right
now
to
kind
of
restructure
the
the
ia
and
the
way
we
organize
things
in
there,
and
so
I
would
see
that
this
kind
of
a
collapsible,
whatever
we
call
it.
This
yeah
widget
type
thing
would
be
abstracted
as
a
component,
but
then
I'm
working
on
more
of
a
patterns,
kind
of
concept
that,
where
that's?
D
Where
to
your
point
mark
the
mr
widgets,
would
fit
like
here's
a
component,
but
here's
how
we're
using
it
in
a
pattern
and
in
a
repeatable
way
and
so
trying
to
add
more
structure
around
pajamas
in
a
way
that
makes
gitlab
specific
things
have
a
place
to
live
in
a
meaningful
way
that
can
be
built
upon
those
components
so
that
we
can
keep.
You
know
a
single
source
of
truth.
Yet
so
that's
that's
just
some
background
there.
So
I'm
aligned
with
all
that.
D
B
I
was
getting
better
at
that
for
a
while.
Now
I'm
bad
at
it
again,
I
need
to
practice
so
zooming
out
a
little
bit
again.
The
reason
for
this
initiative
was
to
bring
consistency,
because
you
know
every
widget
grew
organically
and
the
widgets
were
doing
whatever
they
wanted
into.
You
know
like
hitting
end
points
and
refreshing,
and
you
know:
building
massive
dom
structures
and
so
on.
B
It
was
getting
very
heavy,
and
so
the
whole
point
of
this
was
to
try
and
tame
that
and
keep
it
and
manage
it
more
explicitly
from
a
top
level.
So
things
don't
get
out
of
hand,
which
is
to
say
that
if
we
had
known
where
we
would
end
up
years
ago,
maybe
the
security
widget
wouldn't
have
been
so
complicated.
B
There's
you
know
this
extension
was
built
to
put
a
some
breaks
on
the
engineering
side
of
let's
make
this
a
bit
harder
for
engineers
so
that
they
don't
get
carried
away
with
trying
to
implement
designs
that
they've
been
given,
and
it's
like
another
barrier
to
sort
of
complexity
there.
So
if
we,
if
we
lift
those
barriers,
how
do
we
prevent
complexity
climbing
up
again?
B
So,
for
instance,
if
we
do
this
rewrite
say
that
we
have
this
sort
of
base
view
component,
there's
nothing
technically
preventing
someone
from
saying
unmounted
hit
these
endpoints,
which
is
not
what
we
want
to
do
anymore,
because
the
extension
managers
requests
and
so
on.
So
how?
How
would
we
prevent
that
kind
of
growth?
Again.
C
I
think
so
right
now.
Actually
we
can
still
on
mount.
We
don't
do
that
on
mount,
but
maybe
we
can
do
it
on
fetch
before
fetching
the
full
data
or
the
collapse
data
we
can.
We
can
hit
any
end
point
anyways.
So
technically
it's
still
possible.
It's
just
that.
The
engineer
needs
to
use
workarounds
to
make
it
work,
and
we
already
do
that
like
even
for
leaving
a
simple,
for
instance,
the
security
widget.
C
It
displays
a
summary
and
then
below
the
summary
on
the
same
visual
component,
like
on
the
same
div,
we
display
like
five
critical,
10,
high
and
20
others
vulnerabilities
detected,
and
to
do
that,
I
need
to
inject
html
to
leave
a
line,
a
breaking
breaking
line,
so
we
we
still
have
the
the
capability
to
to
do
pretty
much
whatever
we
want,
but
in
a
harder
way.
C
So
I
think
this
this
should
be
enforced
again.
This
should
be
enforced
through
code
review
guidelines,
because
if
you
check
the
security
widget,
it's
it's
it's
not
the
same
with
the
other
widgets
either
we
we
redesign
the
security
widget
and
then
we
say:
okay,
we
just
display
a
very
tiny
data
and
then
we
link
it
to
another
page.
C
But
that's
again,
it's
not
an
mr
widget
anymore.
It's
a
different
standalone
page
or
we
we
we
try
to
enforce
the
consistency
through
code
review
guidelines
and
give
the
developer
the
tools
necessary
for
them
to
complete
the
job.
Because,
right
now
we
still
give
the
developer
some
tools
to
complete
the
job,
but
they
have
to
reinvent
their
own
tools
to
match
the
design.
C
To
give
you
another
example,
we
need
to
add
a
popover
on
the
security
widget.
So
when
the
security
training
is
enabled,
the
user
sees
a
blue
dot
and
then
goes
on
it
and
then
it
displays
and
pop
over.
So
it's
not
it's
it's
not
right.
Now,
it's
not
supported.
So
what
we
need
to
do
is
if
we
need
to
extend
the
base
view,
add
some
logic
that
affects
all
all
widgets
and
just
base
you
it's
gonna.
C
It's
gonna,
it's
gonna
right
now,
it's
already
400
lines,
so
it's
probably
going
to
grow
even
more.
A
A
They
want
to
add
something
that
no
other
widget
has
and
the
ux
is
in
there
discussing
things.
So
the
restraints
are
at
the
ux
level.
Are
they
discussing?
How
can
we
add
this
to
the
framework
or
what's
the
kind
of
warning
that
we
display?
Is
it
this
one?
Is
it
that
one
and
again,
like
sahaja
yoga,
was
saying
we
can
already
abuse
the
current
things
today,
but
it
will.
A
It
will
take
a
village
to
keep
this
in
the
in
the
line
within
the
within
its
lane
for
sure,
but
the
the
point
for
me
that
drove
this
home
was,
when
savage
showed
me,
the
existing
part
of
the
code
that
they
just
couldn't
reuse
as
it
is
with
the
current
methods,
and
if
they
had
view
view
components,
they
could
just
like
import
that
so
we
want
to
make,
we
don't
want
to
make
life
harder.
Just
for
the
sake
of
making
life
harder,
we
want
to
still
provide
like
a
a
structured.
A
What's
the
name
like
the
shape
of
the
widget
for
you
to
fill
in,
but
not
completely
cut
your
hands
off
so
to
speak.
So
there
is
a.
There
is
a
margin
there.
B
Yeah,
I
think
so
I
mean
so
as
I
understand
it,
there's
visual
consistency
that
we
want,
and
that
is
sort
of
handled
at
the
ux
level
and
hopefully
will
continue
to
be
with
with
the
framework
which
is
great,
but
there's
also
the
technical
consistency
in
terms
of
like
when
and
how
you
do
requests
or
you
know.
So
you
know.
Maybe
what
we
could
do
is
have
like
where
these,
mr
widgets
live,
is
have
an
eslint
rule
or
something
which
prevents
like
unmounted
hooks
or
something
like
that.
B
I
don't
know
just
so
that
you
know
you
you're,
really
forced
to
use
the
the
framework
so
that
you
can't
go
outside
of
its
bounds
technically
with
like
requests
and
stuff,
but
yeah
that
might
get
tricky.
A
I
I
that
sounds
like
a
good,
a
good
idea
if
you
want
to
go
there,
but
I
think
we'll
follow
pro.
We
follow
the
development
of
the
security
widget
that
suffice
was
saying
and
we'll
keep
evolving
from
there,
but
that
definitely
something
that's
something
for
us
to
consider
putting
in
place.
A
C
Yeah
because
I
was
going
to
say
so,
if
we
impose
limits
on
the
technical
side,
we're
always
going
to
come
up
with
workarounds,
because
if
you
like
that
at
least
that's
what
happened
right
now,
so
technically
it's
some
in
in
a
way,
it's
possible
to
do
something.
So
let's
do
that
exactly
and
engineers
are
tricky
like
that,
and
so
I
I
think
this
should
like
the
whole
consistency.
C
Thingy
should
live
on
the
first
of
all
when,
when
the
ux
is
designing
the
widget
and
second
of
all,
probably
the
if
we
want
to
really
be
rigid,
maybe
gitlab
bought
some
house
somehow
assigns
maintainers
that
are
dris
so
because
that
should
that,
should
that
should
be
in
the
code
review.
That's
why
we
have
code
reviews.
I
think.
C
So,
to
sum
up
the
the
action
points,
I'm
gonna
create
an
issue
on
how
for
a
spike
with
with
the
ux
and
then
I'm
just
gonna,
go
ahead
and
then
start
developing
the
v2
yeah.
A
Okay,
yes,
so
from
my
understanding,
you'll
be
leading
that
charge
in
terms
of
like
executing
will
be
around
to
help
out
with
counseling,
like
reviews
and
all
that
stuff,
so
keep
us
posted
on
the
on
the
on
the
planning
and
things.
But
from
now
on,
I
would
say
that
this
is
an
effort
that
is
going
to
be
starting
within
the
working
group,
but
probably
ending
outside
of
the
working
group.
A
So
I
will
make
you
the
dri
of
that
effort,
argue
with
again
your
manager
and
and
try
to
find
that
schedule
in
terms
of
your
capacity
and
all
that
stuff,
but
we're
here
to
help
if
you
need.
But
yes,
that's
that
we're
going
to
be
finishing
off
after
the
working
group
ends
cool
great
stuff.
A
Well,
thank
you
for
a
fantastic
discussion.
Thank
you
so
much
for
the
proposal.
I
can
tell
you
that
personally,
it
was
exciting
to
see
someone
else
taking
care
of
this
little
living
breeding
piece
of
code
that
we
created
in
code
review
and
it
does
take
a
village.
So
we
really
appreciate
the
help
in
in
making
this
evolve
beyond
where
we
started,
and
it's
that's
how
we
know
this
will
succeed
is
because
other
people
are
caring
about
it
just
like
us.
A
So
thank
you
for
that
all
the
best
and
have
a
wonderful
rest
of
your
day
see
you
next
week.