►
From YouTube: 2021-11-18 Working Group: Merge Request Report Widgets
Description
Eleventh weekly meeting of the Working Group.
Agenda: https://docs.google.com/document/d/1bcch8UUkwmgEHFolTWDrQFJtUiiXlv_yQFAGwSSDSUE/edit#
A
A
Just
a
one
discussion
item:
I'll
move
this
discussion
to
an
issue
just
to
have
an
asynchronous
discussion
with
engineers,
but
for
the
people
in
the
call.
One
of
the
things
I
noticed
is
that
the
widgets
that
have
already
been
rewritten
the
parts
where
they
have
subtext-
and
I
think
the
one
that
we
had
was
browser
performance
where
they
have
that
little
text
with
green
numbers
and
all
that
stuff.
A
The
way
that
the
content
is
being
controlled
is
that
the
widget,
the
consuming
widget,
in
this
case
the
browser
performance,
index.js
who's
consuming
or
using
the
core
component
they're
the
ones
specifying
the
markup
for
that
using
their
utility
classes,
which
leads
to
the
problem
that
I
think
gina
reported.
That
text
wasn't
exactly
right.
According
to
the
ux
framework,
this
was
more
of
a
topic
to
bring
up
because
we're
very
early
in
the
game.
Yet
we
only
have
like
two
widgets
rewritten.
A
A
I
see
a
method
that
outputs
the
summary,
for
example,
and
then
the
summary
has
like
a
gl
text
spread
and
then
a
gltex
gray
and
then
a
geotext
screen
depending
on
what's
being
outputted,
but
I
wonder
how
how
deep
does
the
ux
framework
goes?
Is
it
that
there's
a
title
there's
like
some
things
that
are
written
in
stone
like
the
type
like
the
text,
size
and
the
font
and
all
that?
A
B
B
C
And
one
additional
point
I
want
to
make
is:
if
we
restrict
it
from
the
beginning
on,
we
will
have
people
reaching
out
to
us
if
they
need
it.
If
we
make
it
very
open
from
the
beginning
on,
then
people
will
just
implement
it
and
we
will
not
hear
about
it
and
then
we
have
chaos
again.
So
I
rather
want
to
be
restrictive
and
then
have
them
reach
out
to
us.
C
D
I
think
this
case
was
a
little,
I
can't
think
of
words
right
now,
but
unique
because
we,
this
was
one
of
the
first
merger
request,
widgets
that
we
implemented,
and
then
we
created
an
issue
after
this
to
update
the
core
component
so
that
it
actually
took
this
into
account.
So
then,
we'll
have
to
like
retroactively,
go
back
and
update
this
basically,
but
I
agree
I
for
someone
who's
like
reviewing
that
didn't
have
a
ton
of
representation
when
the
actual
merge
request
widgets
were
being
created
for
ux.
D
A
This
is
one
of
those
cases
like
we
have
the
ux
framework
specif,
specifying
the
areas
for
the
text
right,
the
subtext
and
the
title
and
the
subject
or
something
but
there's
not.
I
don't
know
if
there's
a
strict
typographic
rule
set
that
people
have
to
follow
like
what
happens
with
the
weights.
Can
I
put
some
blood
some
bold
text
in
there?
Is
that
specified
in
the
ux
framework
and
colors,
and
all
that.
B
Except
for
that
section,
there's
just
examples
of
some
different
formatting
and-
and
you
know
it
just
mentions
that
we
can
use-
you
know
the
utility.
Well,
I
think
it
mentions
utility
classes,
but
you
know
we
obviously
want
to
be
consistent
where
red
means
danger.
You
know
in
all
the
contexts
and
we
use
bold
for
emphasis
of
variables
and
whatnot
and
we're
using
links
correctly.
So
I
think,
there's
some
reason
to
be
pretty
buttoned
up
with
that,
because
we
have,
you
know
specific
use
cases
for
those
styles,
but
how
those
styles
are
are
used
for.
B
E
I
think
we'd
want
to
be
quite
aggressive
in
refactoring
existing
usages
and
keeping
the
api
clean
and
not
let
it
bloat
up.
As
we
add
more
and
more
use
cases,
I
don't
know
how
process-wise
we
can
do
that,
but
it's
something
to
think
about.
You
know
if
and
when
we
find
we
need
to
extend
this
a
bit.
We
need
to
be
quite
strict
in
terms
of
cleaning
up
after
ourselves.
A
That
touches
on
the
point
that
we
discussed
previously
on
the
process.
If
you
want
to
extend
the
widget-
and
I
think
part
of
it
is
just
including
including
the
product
designers
that
worked
on
the
rex
framework
and
including
the
code
review
folks,
to
kind
of
like
make
sure
that
we're
not
creating
support
for
something
that
I
don't
know
adds
52
pixels
size
text
to
the
widgets,
something
out
of
right
of
what
common
sense.
So
kai
you
want
to
voice
your
comments.
F
Approval
rules
are
the
answer
to
solve
that
and
be
be
strict
about
it.
If
we
used
code
owners
in
the
gitlab
project,
then
they
would
have
to
therefore
be
approved
by
people
who
could
who
could
see
and
make
that
distinction.
I'm
I'm
obviously
supportive
of
using
approval
rules
in
the
gitlab
project,
but
it
is
that's
a
larger
and
different
conversation.
A
Yeah
it's
one
of
those
things
if
you
had,
if
you
were
working
on
gitlab
ui
project
or
something
we
could
probably
be
stricter
and
turn
that
on
because
right
now,
if
you
turn
on
the
approval
rules
for
code
owners,
you
turn
on
all
of
them.
I
think
you
can't
just
like
enable
a
certain
section,
but
yeah
that
would
probably
help.
So
this
is
good.
I
think
I
think
I'll
still
have
to
move
a
discussion
more
towards.
A
But
it
provides
sort
of
a
set
of
things
that
people
could
use
out
of
the
box
to
to
do
what
they
need
to
do,
rather
than
just
allowing
for
like
any
markup
to
fall
into
place,
and
then
the
strictness
of
it
is.
Should
we
strip
any
tags
that
come
from
those
texts,
because
then,
if
you
want
to
be
super
strict,
we'll
avoid
them
for
adding
an
iframe
to
that
right.
A
So,
which
is
probably
I'm
going
a
bit
extreme
here,
but
right
so
I'll,
move
that
to
an
issue,
probably
some
that
already
exists
and
oh,
if
not
I'll,
just
create
a
new
one
and
ping,
some
of
you
and
some
of
them
and
try
to
get
something
out
of
that
discussion.
But
this
is
very
useful
to
understand
your
perspective
as
well,
and
thanks
mark
for
pitching
in
there
any
more
thoughts.
A
Not
right
now
so-
and
this
was
exactly
why
this
came
up.
I
was
talking
to
thomas
about
his
his
work
on
that
issue
and
was
when
I
saw
this,
that
it
was
like
a
free-for-all
kind
of
formatting
that
you
can
just
do
whatever
markup
you
want,
because
what
I,
what
I
was
sort
of
expecting
was
that
his
fix
for
this
issue
would
be
in
the
core
component
and
then
I
noticed
no
he's
fixing
it
on
the
consuming
widgets
and
that's
what
we
want
to
avoid.
You
want
to
avoid
that.
A
If
you
have
an
in
like
a
wrong
text
size,
we
have
to
update
all
the
widgets.
We
should
have
a
core
component
where
we
update
that
and
then
everybody
who's
using
the
core
component
should
benefit
from
that
fix.
So
that's
what
that
came
from.
So
my
my
perspective
is
just
let's
see,
let's
fix
it
right
now
and
I'll
block
that
and
whatever
we
decide,
because
there's
not
just
this
particular
instance.
A
There's
other
places
in
the
summary,
even
though
they
might
be
correct
in
terms
of
ux
framework
they're
using
directly
the
utility
classes
on
the
consuming
widgets.
So
I'd
rather
us
just
yeah
fix
it
as
it
is
right
now
for
this
particular
update
level.
One
subject
text,
I'm
gonna
put
the
link
here.
Oh
you
found
it
there
already
good
so
leave
there
leave
that
fixed
as
it
is.
But
then,
whenever
we
review
this,
we'll
review
everything
at
once.
A
A
If
nobody
has
any
other
points.
I'll
just
give
you
50
minutes
back
all
right.
I
see
a
thumbs
up
good
to
see
everyone.
I
won't
be
here
next
week,
so
I'll
have
someone
else
moderate.
The
team
well
I'll
write
the
meeting.
Somebody
wants
to
volunteer
just
hit
me
up
on
slack
and
set
it
and
set
it
up,
but
I'll
see
you
when
I
see
you
have
a
great
weekend.