►
From YouTube: 2022-06-23 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
And
we're
live
hi.
Everyone
welcome
to
yet
another
weekly
meeting
for
the
merger
quest
report,
widgets
working
group.
I
think
I
got
that
right
so
I'll
cut
straight
to
to
the
agenda
and
basically
starting
with
the
checklists
as
before.
A
B
I
think
there
was
one
for
test
reports.
There
was
a
bug
with
the
widget,
not
loading,
and
I
paired
yesterday
to
kind
of
get
through
that.
So
the
thing
is
mr
up,
let
me
see.
A
B
A
One
that
miranda
mentioned
on
the
thread
on
the
slack
channel.
B
Yeah
and
I
just
posted
an
update-
she
has
an
mr
up
for
it,
but
that
would
yeah.
We
need
that.
I
think,
but
basically
the
the
problem
is
on
the
initial
page
load
because
of
caching,
it's
related
to
the
204,
no
content,
the
same
thing
we
were
facing.
It
was
basically
there's
an
exception
in
the
callback
handler.
That's
been
fixed
in
the
mr.
I
think
she
has
up,
but
that
I
don't
know
if
we
want
to
push
forward
without
that
it
would
manifest,
as
test
reports
failing
to
load
on
the
initial
load.
B
No,
so
what
it
was
is
an
edge
case,
so
it
was
project
specific.
There
was
some
nested
data
that
was
an
empty
array
in
some
cases,
so
this
was
like.
We
didn't
see
it
before,
because
it
wasn't
in
the
we
didn't
have
a
project
with
that
particular
scenario,
so
it
was
literally
just
handling
that,
when
is
that
value
is
undefined
be
default
to
to
zero
or
something
discounts.
B
A
Let
me
find
the
mr,
while
others
speak:
okay,
yeah,
please
post
it
in
the
agenda,
so
the
question
because
I
feel
like
that's
the
value
of
getting
the
rollout
for
the
future
flags
and
the
more
edge
cases
revealed
by
more
projects,
the
better
I
would
say
for
the
rollout-
that's
already
identified,
there's
already
a
fix
for
it.
The
problem
is
how
much
of
a
blocker
is
that,
because
the
test
summary,
if
I'm
not
mistaken,
is
summarizing
the
information
available
on
the
pipeline
right.
There
is
a
workaround.
A
The
workaround
is
refresh
the
page,
okay
yeah.
That
would
put
us
in
severity
three
territory,
if
I'm
not
mistaken,
like
an
easy,
workaround
kind
of
thing,
so
I'm
tempted
to
not
blocking
the
roll-up,
I
mean
continuing
to
broadening
the
roll
out
to
other
projects.
Anybody
disagrees.
A
So
issues
mr
open
edge
case
identified
mr
open
to
fix
rollout,
not
blocked
okay,
so
blocker
solved,
okay,
so
moving
on
to
the
next
check
for
launch
a
feature
flag
enabled
in
production
that
is
correct
for
specific
projects.
A
If
I'm
not
mistaken
and
that's
the
thing
I
was
trying
to
confirm
is
what
projects
are
enabled
at
the
moment.
I
have
the
ids
so
I'll
just
do
that
now
for
not
having
an
easy
way
to
translate
that
to
projects,
but
I
think
that's
the
gitlab.org
gitlab
project
and
then
the
other
test
project
we
had
before.
A
A
Okay,
that's
what
we'll
do
so
feature
flag
enabled
by
default?
No,
not
yet!
I
put
here
next
steps.
Why
is
this
not?
A
Okay,
I'm
battling
with
bullet
points
on
the
agenda
right
next
step
enabled
globally
on.com
that
should
just
come
on
the
next
monday.
I
would
say,
because
tomorrow's
family
and
friends
day
so
I
expect
by
next
monday,
we
should
start
rolling
out
to
all
projects
on.com
that
will
give
us
more
exposure.
That
would
give
us
more
probably
edge
cases
that
we
need
to
fix
so
and
with
that
support
will
definitely
be
notified
so
that
they
can
route
the
requests
to
us
working
group
wrap
up.
We
just
released
that's
kind
of
a
half
bang.
A
Well,
no,
not
yet
documentation
review
and
complete.
Not
yet
I'm
I'm
lagging
behind
on
my
task
to
find
a
technical
writer
to
review.
I
haven't
been
able
to
catch
up
with
amy
kai
I've
been
I've
been
thinking
of
asking
amy
calls
to
kind
of
help
us
there.
I
think
she's,
a
perfect
candidate
for
that.
Try
to
reach
her
to
see
if
we
can
get
her
before
she
goes
on
holiday.
So
that's
the
plan.
Do
we
have
an
issue
for
what
we
need
for
documentation?
A
A
Now
we
just
need
a
review
to
see
what
are
the:
what
are
the
pl?
What
are
the
gaps?
What's
missing,
what
should
we
document
even
for
even
more-
and
I
feel
like
that-
would
just
show
the
exit
criteria
and
show
what's
linked
to
all
the
documents,
documentation
pages
that
are
relevant
and
then
have
her,
give
her
give
us
the
feedback.
What
should
we
write
more?
Is
it
clear
I'm
thinking
and
here's
a
something
that
came
to
me
yesterday.
A
I
think
samantha
is
working
on
an
early
stage
of
a
widget,
I'm
probably
samantha
ming,
so
I'm
probably
going
to
ask
her
to
hey.
Can
you
also
take
a
look
at
these
pages
and
see
from
the
perspective
of
an
author
of
a
new
widget?
Is
the
documentation
insane
because
we
were
all
part
of
the
development
of
the
documentation
might
be
blind,
so
I
want
to
put
here
I'll
open
an
issue,
so
andre
will
open
an
issue
and
tag
amy,
technical
writer
and
samantha
ming
from
the
engineer
to
review
the
pages.
C
Yeah,
I
think
the
big
one
for
tech
writing
is
going
to
be
less
about
like
in
like
development
docs.
Fine,
I
think
amy
can
review
those.
I
think
the
the
big
one
will
be
are
these
like?
Are
there
functional
changes
which
I
don't
think
there
are
for
any
of
the
widgets
that
need
to
be
like
updated
in
feature
docs?
C
A
That's
a
good
point,
so
we
should
do
that
by
the
time
that
we
enable
the
feature
flag
by
default
or
shortly
after.
C
A
I
want
to
put
here
potentially
crowd
source
from
the
teams
who
own
the
widgets
yeah
I'll
document,
that
too
okay
and
then
we'll
we'll.
We
have
the
dris
for
the
widgets
and
potentially,
what
we'll
leverage
is
through
that
channel.
We
can
find
a
way
to
have
those
dris
take
care
of
ensuring
that
that
gets,
updated,
cool
right,
launch
checks
done
announcements,
roll
out
ongoing
enabling
product
for
certain
projects.
A
As
I
said
before,
and
that
was
kind
of
my
announcements,
discussion
items
I
wanted
to
just
bring
up
the
opportunity
for
us
to
kind
of
like
get
a
pulse
of
how
things
are
going
and
the
feelings
about
proceeding
with
the
wider
robot,
which
already
briefly
discussed
so
for
now.
Do
you
want
to
want
to
add
something.
B
Yeah,
so
I'm
glad
that
for
the
widgets
that
are
not
ready,
there's
the
security
widget
license
compliance
and
I
think
one
code
quality,
maybe
that
yannick
was
working
on
those
are
featured
flagged
out
independently,
and
that
was
to
enable
the
rollout
to
go
out
with
new
stuff
and
some
of
the
old
stuff
until
so
we're
not
blocked
entirely.
So
with
that
said,
there's
this
I'll
share
my
screen
really
quickly,
and
this
is
the
right
one.
I
did
create
an
mr
last
week.
Just
we
didn't
have
one.
B
This
is
in
the
in
the
gitlab,
mr
widgets
demo,
and
the
purpose
of
this,
mr.
The
changes
actually
just
adds
to
the
ammo
file,
the
secure
related
jobs,
and
this
is
using
static
data,
but
this
is
how
we
have
the
secure
demo
project,
so
I
just
kind
of
copied
over
the
ammo
file,
but
what
that
gave
us
was
more
of
the
widgets
mixed
in
with
secure
widgets,
and
you
see
that
these
are
intentionally
the
old
ones
for
licensing
appliance
and
security,
and
these
are
the
new
ones.
B
And
the
point
of
this,
mr,
was
just
kind
of
a
visual,
a
working
visual
of
of
this
in
action.
You
know
the
ones
that
are
flagged
out,
the
ones
that
are
flagged
in
and
making
sure
they
render
together
and
work.
So
you
know
this
stuff
all
works,
as
is
so.
I
think
that
this
is
the
sanity
check
feel
free
to
play
around
with
that.
The
only
thing
is
this,
because
this,
mr,
is
the
one
that
introduces
the
yaml
for
the
additional
security
stuff.
B
You
won't
see
this
right
now
in
any
of
the
other
merge
requests.
So
you
need
to
go
to
this
specific
one.
We
merged
this
merge
request
into
the
demo
project
and
we
see
it
for
all
other
feature
marks,
but
I
figured-
and
this
is
enough
to
kind
of
see
what
we
want
any
questions
on
that.
A
Under
yet
some
other
points,
no,
I
already
added
that
link
to
that
demo.
Mr
thank
you
for
creating
that
that's
very
useful.
I
added
that
to
the
top
of
this
agenda.
The
list
of
mr
examples
we
have
so
we
can
always
refer
to
those,
that's
extremely
useful.
So
thanks
for
that,
for
that
now,
okay,
any
other
thoughts
I
feel
like
the
pulse,
has
been
overwhelmingly
positive.
It's
moving
forward.
A
Of
course,
there's
some
pains,
but
I
feel
like
the
exposure
to
wider
projects,
will
give
us
even
more
confidence
in
brought
releasing
this
to
the
wider
crowd,
which
makes
me
think.
A
Okay,
we
should
probably
prepare
a
release
posts
block
for
this.
No,
what
do
you
think.
A
A
All
right
maybe
give
it
some
time
to
think
about
that.
C
It's
really
like
a
ui
improvement
like
we
could
like
put
a
single
item
in
the
ux
improvements
is
sort
of
how
I
would
like
generally
think
about
it.
I
don't
know
that
this
rises
to
the
level
of
like
a
feature,
a
feature
because
functionally
it
doesn't
doesn't
change
much
right.
I
don't
think
so
so,
like
I
think
it's
it's
worth
mentioning
in
the
ux
improvements,
but
and
that's
not
to
like
discount
the
work
like
the
work
is
important.
It's
just
that,
like
I
think
in
what
we
communicate
it.
A
I
agree
with
that
assessment.
I
think
it
doesn't
devalue
at
all
the
work
that
we've
been
putting
forward
and
but
okay,
that
works
for
me,
we'll
just
follow
that
through
the
rollout
issue
and
once
the
robot
issue,
when
the
rollout
issue
is
updated
with
the
defaulting
tool.
On
we'll
add
the
link
potentially
to
the
rollout
issue
from
the
ux
improvements
sounds
good.
This
is
something
that
I
should
have
put
on
the
announcements.
This
is
the
next
point.
A
The
telemetry
work
has
been
merged,
so
thomas
finished
that
off
in
15-1,
that's
already
in.
If
you
do
have,
questions,
do
reach
out.
I'm
moving
to
the
announcements
now,
but
I
think
he's
planning
on
doing
some
demo
or
something
so
that'll
probably
come
on
youtube
and
everything
we'll
share
it
on
select
channel
once
it's
up
ferland.
Do
you
have
the
next
point.
B
Yeah,
sorry,
I'm
adding
this
as
they
kind
of
come
up.
You
know
in
these
meetings
we've
had
a
lot
of
representation
from
designers,
product
managers
and
engineers,
but
I
think
noticeably
absent
was
you
know
our
qa
counterparts.
So
I
was
wondering
for
the
dris
for
each
widget.
B
If
every
friendly
reminder,
if
they've
been
keeping
their
qa
counterpart
in
the
loop,
we
do
have
automation
tests
at
least
license
compliance
that
I
had
to
comment
out
because
I
haven't
you
know,
have
to
rewrite
those
and
or
sorry
browser
automation,
tests
or
interactions
with
the
widget
that
are
currently
commented
out
for
licensed
clients
as
one
example.
So
I
think
it's
great
that
everyone's
kind
of
writing
unit
tests
and
manually
testing,
but
maybe
we
should
just
be
a
little
more
transparent.
A
Yeah
for
the
recording
I'll
just
voice,
would
you
mind
dropping
a
comment
in
the
rollout
issue
and
confirm
directly,
because
now
you
have
the
list
of
dris
from
the
engineering
perspective
on
that
issue
already
involved
and
just
tag
them
and
then
hey
just
a
quick
check.
Are
you
all
checking
with
all
your
qa
counterparts,
because
it's
definitely
something
that
we
don't
want
to
be
surprised
at
the
end
so
yeah,
it
sounds
like
a
relevant
question
to
put
in
their
radar.
Should.
B
We
extend
that
to
technical
writing
as
well,
because
I
know
earlier
mentioned
in
the
agenda
about
updating
feature
docs,
screenshots
and
stuff.
So
I
you
know
a
lot
of
times.
I
think
as
engineers
who
forget
to
ping
like
the
docs
team.
So
then
they
only
know
because
they're
browsing
issues
and
a
milestone
like
hey.
This
is
some
dots
and
sometimes
that
slopes
through.
So
I
will
add
that
qa
and
technical
writing.
B
If
that's,
okay
with
you,
I'm
I'll
kind
of
call,
it
question.
Okay,.
A
A
I
would
keep
them
like
this
2dris,
but
use
the
use,
one
of
them
to
to
reach
the
other
counterparts
so
ping,
the
ux
ping,
the
engineering
dris
and
ask
them
to
make
sure
that
they
are
in
touch
with
their
own
tw's
and
sets
awesome
thanks.
Vernon,
that's
a
good
point.
Sure.
B
I
guess
the
last
item
we
don't
have
to
go,
do
a
deep
dive,
because
I
don't
yeah,
we
don't
have
any
engineers
on
the
call,
but
the
we're
just
really
quickly
high
level
just
for
transparency.
We
needed
this
for
license.
Compliance
because
license
compliance
is,
I
believe,
the
only
widget
that
actually
has
two
optimized
endpoints
one
for
class
and
one
for
expanded.
B
All
the
other
ones
will
derive
their
data
from
the
that
one
endpoint
or
either
by
just
using
the
data
that's
available
from
the
collapse
fetch
or
fetching
the
two
different
endpoint
same
endpoint
twice.
I
think
a
lot
of
them
now
will
just
fetch
it
once
and
then
just
use
the
derived
data
and
that
initial
fetch
license
compliance
is
the
exception.
B
But
anyway,
what
this
does
at
a
high
level
is
add
the
ability
to
pull
now
the
expanded
content
and
all
we
did
is
add
and
enable
a
full
data
flag
and
that
when
it's
off
or
not
included
at
all
it,
it
should
have
the
existing
behavior
had
before.
So
it
should
be
low
risk
in
theory
to
whatever
widgets
we
have
already,
because
it's
a
feature
enhancement
if
you
enable
it
if
it's
disabled,
it
should
behave
exactly
the
same.
I
just
wanted
to
call
that
out,
but
not
a
blocker
for
the
rollout.
A
Got
it
thanks
fernando?
I
only
have
one
question
this
polling
for
the
expanded
content.
Does
this
only
start
when
the
user
expands
or.
B
Yeah
yeah
so
the
way
it
piggybacks
off
the
existing
functionality.
So
what
are
the
differences
in
the
when
you
do
the
expansion
there's
a
call
to
like
load
all
data
and
that
initiates
the
initial
ajax
request?
That's
where
we're,
including
this
logic,
it's
just.
If
else,
if
polling,
we
kind
of
go
the
pulling
route,
so
this
will
only
yeah.
A
Sounds
good,
thank
you
so
much
for
calling
that
out.
I
know
that
phil
is
already
there
his
thoughts
so
yeah.
Thank
you
for
that.
No
further
comments
from
my
side
and
then
I
think
we're
done
here.