►
From YouTube: 2021-11-11 Working Group: Merge Request Report Widgets
Description
Tenth weekly meeting of the WG.
Agenda:
https://docs.google.com/document/d/1bcch8UUkwmgEHFolTWDrQFJtUiiXlv_yQFAGwSSDSUE/edit#
A
B
Thank
you
very
much
and
I'd
love
to
present,
I'm
not
quite
sure,
if
we're
already
there,
but
we
have
some
so
we've
been
looking
at
this
issue
in
our
last
refinement
session,
which
is
about
enhancing
dmr
richard
of
the
license
compliance-
and
I
am
not
100
familiar
with
the
the
current
state
of
the
shared
components
in
there,
but
what
we
definitely
could
see
that
this
is
just
an
example
merge
request.
The
security
scanning
is
already
using
all
of
the
latest
framework
and
the
license
compliance.
Absolutely
not.
B
We
just
did
like
a
pretty
short
another
analysis
of
this,
but
just
going
from
this
thing
and
yeah
the
security
security
scanning
mr
widget,
and
to
the
license
compliance,
we
couldn't
find
any
features
that
would
not
cover
it
so
far,
so
it
basically
boils
down
what
is
the
current
state
of
this,
and
where
can
we
find
some
documentations
of
the
currently
used
components
and
probably
most
important?
Do
you
still
see
any
blockers
for
this,
which
we
should
consider
now
early,
since
we
are
just
hitting
the
refinement
stage
on
this.
A
Thanks
so
to
your
first
question:
where
are
we
in
the
support?
I
added
a
link
to
the
agenda
where
we
can
see
the
development
of
the
support,
so
basically
we're
breaking
it
into
steps
and
we're
adding
it
in
bits.
We've
added
quite
the
central
part,
I
think
it
while,
while
the
ux
all
of
it
might
not
still
be
there
in
terms
of
like
alignment
and
all
that
stuff
we
are
already.
We
were
already
able
to
pour
two
widgets
peyton
worked
on
on
those
two
widgets.
A
A
Yes,
so
we
already
merged
browser
performance
and
load
performance.
Those
two
are
merged
as
to
the
what's
missing,
yeah,
there's
a
bit
some
bits
missing
from
from
adding
actions
level,
no
support
for
actions
level,
one
it's
being
worked
on
by
phil,
the
other
level,
two
and
level
three.
Unless
you
have
actions
for
level
two
or
level,
three
or
sorry,
not
action,
sections,
content,
sections
for
level
two
level,
three:
how
blocking
is
this
fill?
Can
they
still
add
it
and
then,
when
once
we
add
support
for
all
these
spaces
and
all
that
stuff?
C
A
I
would
add,
I
would
add
one
thing
that
might
be
useful
for
you,
yannick
and
fernando
the
the
idea
here
was
that
the
earliest
that
you
start
rewriting
your
widgets,
the
earlier
you'll,
find
the
limits
of
the
core
component.
Now
we
do
have
already
documented
work
to
add
what's
in
the
ux
framework,
but
if
you
have
anything
specific
to
your
widgets,
these
widgets
are
not
being
turned
on
right
away.
They
are
behind
a
feature
flag,
global
for
the
whole
rewrite.
A
But
if
you
find
say
a
limitation
or
something
that
you
would
like
us
to
rework
on
the
core,
widgets
you'll
only
find
that
once
you
start
diving
deep
into
the
implementation
of
it,
and
we
don't
set
an
expectation
on
product
managers
that
once
you
pick
it
up,
you'll
ship
it
in
a
milestone
or
something
these
will
be
rewritten
and
then
once
we're
ready
and
the
code
base
is
stabilized.
We'll
turn
them
on
all
at
once,
so
to
speak.
A
B
Sorry,
it
definitely
doesn't
make
sense,
and
what
I'm
taking
away
from
this
is
be
cautious
when
it
comes
to
level
two
and
level
three,
I'm
not
100
sure,
yet
with
license
compliance,
if
we're
really
going
to
need
them,
but
we'll
figure-
and
this
has
to
be
flagged
behind
a
this-
has
to
be
behind
the
flag.
That's
definitely
a
hard
requirement.
B
D
D
Yeah
I'll
try
to
keep
it
short,
because
I
know
the
other
meeting
a
lot
of
folks
probably
want
to
attend.
My
general
question
was
in
terms
of
rollout
strategy
right
like
to
work
in
terms
of
working
with
product.
They
kind
of
want
this
in,
but
it's
going
to
be
a
while
till
we
get
to
the
point
where
we
enable
this
feature
flag.
D
I
can
imagine
that's
doing
it
in
parallel,
we're
doing
it
without
this
feature,
flag,
enabled
and
then
we're
gonna
have
to
re-implement
it
anyway.
You
know
with
this
new,
I
guess
mr
widget
extension
code
so
like
I'm
trying
to
do
any
recommendations
for
approach.
If
product
really
wants
to
get
this
in
soon,
but
or
should
we
push
back
and
say,
hey,
no,
let's
focus
our
efforts,
I'm
contributing
to
these
efforts,
so
we
get
a
win
across
gitlab
in
terms
of
you
know
getting
closer
to
enabling
future
flag.
A
Yeah,
that's
a
great
question,
so
what
we
have
been
discussing
about
the
rollout
is
that
it's
just
easier
to
have
one
merge
one
feature
flag
for
everything
at
this
point,
but
we
will
come
a
point.
So
if
you
follow
that
epic,
that's
6647,
once
we
have
those
issues
closed,
which
I
expect
one
more
milestone,
we
should
have
it
again.
The
effort
of
this
working
group
is
not
per
quarter,
but
we
do
have
a
goal
to
wrap
it
up
by
the
quarter,
one
which
puts
us
at
the
end
of
january
right.
A
A
Is
that
as
phil
mostly
has
been
working
on
the
core
component,
that
throws
some
instability
on
the
code
base.
You
want
to
be
cautious
about,
you
know,
throwing
something
into
production,
visible
and
then
all
of
a
sudden
it
breaks.
So
once
we
finish
touching,
the
in-ears
of
the
car
component
frequently
we'll
be
comfortable
to
turn
that
on
then
from
that
moment
on,
say
that
you're
rewriting
another
widget
later
you'll
have
your
own
individual
feature
flag
if
the
other
is
already
on
so
in
terms
of
expectations
for
the
product
manager,
I
would
expect
within
two
milestones.
A
And
thanks
for
for
for
stepping
up
and
looking
into
it
and
please
yes,
as
you
pick
up
the
issue,
as
you
start
rewriting
the
the
widget
there's
gonna
be
questions
and
docs
are
not
where
we
want
them
to
be.
That's
one
of
our
tasks
until
january.
So
there's
going
to
be
some
things.
You're
going
to
need
to
talk
to
to
the
developers,
phil
and
peyton
would
be
the
best
people
to
help
you.