►
From YouTube: 2022-01-27 Working Group: Merge Request Report Widgets
Description
Sixteenth weekly meeting of the Working Group.
Agenda: https://docs.google.com/document/d/1bcch8UUkwmgEHFolTWDrQFJtUiiXlv_yQFAGwSSDSUE/edit#
A
All
right
we
are
live.
Thank
you.
Welcome
everyone
to
yet
another
weekly
meeting
of
the
working
group
for
the
report.
Widgets,
I'm
going
to
guess
it's
the
16th,
but
I
lost
talent
by
now
and
right,
let's
go
straight
to
the
announcements.
I
posted
a
bit
of
a
quick
update
on
the
status
of
the
ongoing
work,
so
the
the
clickable
row
of
level,
one
merchandise
report
widget,
has
been
merged
today,
so
it's
on
its
way
to
production
thanks
phil
and
jeremy.
A
I
think
you
both
worked
on
that
if
anyone
else
worked
on
it,
I'm
sorry,
but
it's
very
welcome
to
see
so
that
should
hit
production
soon
play
around
with
it.
If
you
have
any
issues
report
them
in
the
usual
way
and
we'll
get
to
it
if
there
if
there
are
any,
but
I'm
looking
forward
to
trying
this
out,
I
haven't,
haven't
played
with
it
yet
and
the
other
update
we've
had
was
that
the
accessibility
widget
was
merged.
So
thanks
everyone
who
worked
on
that.
I
saw
that
gina,
you
reviewed
it.
A
B
A
A
The
other
ones
are
in
the
merge
requests,
slash
one
that
I
think
still
carries
all
the
other
widgets,
so
it'd,
be
nice
it'd
be
nice
to
merge
them
yeah,
like
you
said,
but
as
long
as
we
have
a
link
to
to
it,
it's
not
that
big
of
a
deal.
So
if
somebody
could
merge
them,
that'd
be
nice.
If
not,
I
don't
see
a
big
issue
in
there.
C
A
So
with
that,
then
just
highlighting
the
ongoing
work
in
148,
where
yannick
and
phil
is
working
on
updating
the
documentation,
so
technical
documentation
for
the
working
for
the
widget,
so
that
people
know
how
to
how
to
work
with
it
and
with
the
new
improvements.
Yes,
the
new
rules
that
we
shipped
and
then
the
other
part
is
adding
support
for
content
sections
for
level
three.
That's
also
in
this
milestone,
looking
forward
to
merge
that
there's,
probably
others.
This
is
the
ones
that
had
the
label.
A
So
if
you
don't
see
your
work
here
and
you're
working
there,
if
you
don't
see
your
work,
add
the
label.
Please
add
the
new
shiny
label.
I
forgot
what
it's
called
the
merge
request
report
widgets.
Of
course
that's
obvious
cool
thanks
and
that's
all
for
me.
Let's
move
over
to
discussion
items
for
them.
Do
you
have
the
first.
D
D
D
Will
describe
the
reasons
for
it
and
the
details
of
who's
going
where
but
yeah,
so
I'm
coming
in
a
little
bit
later
into
this,
but
yannick
did
kind
of
give
me
a
overview
right
prior
to
this
meeting
of
where
the
state
is
during
regards
to
the
extensions,
but
I
did
have
a
question,
so
I
see
how
we
defined
ui
structure
for
levels,
one
through
three
and
particular
components
or
ui
elements
that
are
available
at
those
layers.
Are
those
pretty
locked
in
or
are
we
taking
an
approach
where
we
can
dynamically
generate
them?
D
Recursively,
where
we
say
we
have
four
or
five
different
types
of
ui
elements
that
we
can
show,
and
then
we
can
kind
of
configure
these
extensions
to
show
them
in
any
which
way
any
which
configuration
recursively
or
are
they
pretty
locked
in
level?
One
two
and
three
only
have
a
subset
of
these
components
and
certain
components
can
only
be
used
at
a
particular
level
and
we've
only
defined
up
to
level
three.
D
So
so
yeah,
so
in
the
secure
stage
we
have
the
this
notion
of
what
they
call
generic
security
reports.
So
we
have
anywhere,
we
show
vulnerabilities,
we
have
data
associated
to
the
vulnerabilities,
so
with
generic
security
reports,
we
can
actually
generate
these
reports.
Dyna
the
ui
elements
dynamically,
whether
it's
in
the
modal
or
or
not,
or
if
it's
embedded
in
the
page
for
vulnerability
the
data
that's
associated
to
vulnerability
can
be
dynamically
structured.
D
So
if
you
wanted
to
have
a
list
a
table,
sorry,
if
you
wanted
to
have
like
lists
of
data
and
then
have
it
nested,
multiple
layers,
you
could
just
define
it
in
the
in.
I
guess
the
the
view
and
it
will
or
sorry
in
the
configuration
it
will
parse
that
and
then
dynamically
generate
the
data
nested
as
opposed
to
saying
hey.
We
could
only
render
things
at
level
one
or
two
or
three.
D
A
Yeah
yeah,
I
understand
your
question.
I
think
there's
also
part
of
this
answer
is
ux,
but
from
code
perspective
I
don't
think
that
is
possible
what
we
do
worked
in
the
past.
I
I
recommend
you
take
a
look
at
the
ones
that
already
have
is
you
have
some
flexibility
that
we've
added
with
some
we're
using
gas
printf
to
generate
some
strings
and
you
can
change
the?
How
the
you
know
the
warning
strings
show
up.
D
Yeah
good
things
yeah,
I
didn't
have
a
use
case
yet
so
it's
not
a
problem
we
have
to
solve.
I
was
thinking
more
of
the
things
of
like
architecturally,
like
supporting
that
ability,
where
it's
kind
of
self-service
right.
The
idea
is,
we
have
these
specific
set
of
official
compo
or
you
know,
components
that
we
support
within
that
extension
and
that
the
the
developer's
still
limited
to
those
set
components,
but
they
have
a
little
bit
robust
flexibility
to
in
the
future
kind
of
structure
these,
how
they
want
and
nest
them
as
they
want.
D
Because
right
now
we're
locked
into
particular
what's
available
level,
one
two
or
three,
but
I
understand
for
consistency's
sake,
that
is
kind
of
better
in
the
short
term.
So
I'll
I'll
create
an
issue
to
kind
of
weigh
those
but
not
trying
to
derail
the
efforts
or
the
approach
taken
so
far.
So
just
fruitful,
no.
A
This
is
great.
This
is
great
questions
for
them,
because
I
think
that's.
We
have
to
be
open
that
maybe
the
framework
doesn't
cover
everything.
So
I
think
it's
important
to
keep
chatting
about
these
sort
of
things,
and
if
you
do
so
great
issue,
we'll
take
a
look
at
it.
I
do
think
the
the
principle
has
been
towards
being
less
restrictive,
so
we
haven't
been
too
keen
on
having
slots
so
that
you
can
just
throw
anything
in
there.
A
It's
like
a
structured
ui,
but
the
idea
is
that
if
you,
if
you
need
something
that
is
not
covered
by
the
current
code,
we'll
add
it
we'll
discuss
it
with
ux,
see
how
it's
supposedly
to
be
added
consistently
to
other
usages
and
then
we'll
just
add
support
for
it
as
we
go.
Part
of
the
documentation
will
also
potentially
cover
that
how
to
add
support
for
more
things.
A
We
also
already
have
somewhat
of
a
process
to
if
you
need
something
specific
about
this
area,
to
consult
with
the
code
review,
team
and
everything,
but
yeah,
it's
not
a
hard.
No,
but
it's
kind
of
like.
I
think
that,
up
until
now
the
idea
has
been
to
restrict
so
that
we
have
consistency,
but
the
restrictions
are
flexible
to
a
point.
A
So
if
you
have
come
up
with
so
I'm
just
saying
that
in
the
future,
if
that
comes
up,
do
bring
it
up,
so
don't
just
assume
that
we
won't
build
it
just
bring
it
up,
because
it
might
make
sense
for
the
widgets
but
yeah
open
the
issue
we'll
go
from
there
and
thanks
for
bringing
it
up
awesome
I
moved
away.
Where
am
I
any
other
thoughts?
Can
we
move
over
to
technical
discussions?
C
Yeah,
it's
it's
completely
already
solved.
I've
just
been
looking
for
a
merge
request,
which
has
a
level
two
action
item,
and
if
anybody
else
does
all
the
way
up
in
our
agenda,
there
is
actually
an
example,
mr,
which
covers
all
of
the
features
and
the
level
to
action
of
items.
So
that
would
be
a
good
place
to
look
for
it.