►
From YouTube: 2022-04-21 Working Group: Merge Request Report Widgets
Description
Weekly call for the Working Group about MR Report Widgets.
Agenda: https://docs.google.com/document/d/1bcch8UUkwmgEHFolTWDrQFJtUiiXlv_yQFAGwSSDSUE/edit#
A
Okay,
welcome
to
the
weekly
call
for
the
working
group
of
merge,
request
report
widgets.
That
was
an
amazing
first
words
for
the
live
stream.
Welcome
everyone.
Let's
get
on
with
the
agenda.
We
have
a
little
bit
of
an
announcement.
It's
it's
read
only,
but
I
have
a
question.
So
do
you
want
to
read
it.
B
A
My
question
is
whether
I
feel
like
this
is
going
to
be
something
that
future
authors
will
want
and
we'll
need
to
have
some
guidance.
So
when
looking
through
the
design,
I
think
it's
important
for
designers
to
be
aware
that
that's
a
possibility
right
that
can
affect
the
design
of
the
widget
themselves.
So
I
feel
like
it
would
be
a
nice
addition
to
the
documentation.
C
If
that
makes
sense,
because,
like
right
now,
the
widget
extensions
are
bound
by
the
rules
that
we
design
and
the
design
spec
and
all
the
extensions
have
to
conform
to
that
right.
Now,
the
modal,
at
least
for
the
security
widget.
It
shows
vulnerability,
specific
data,
so
I
didn't
know
what
your
thoughts
on
were
that
were
we
trying
to
even
standardize
to
the
modal
content,
or
can
we
just
show
what
we
want
in
there.
B
B
A
Yeah,
I
think
that's
a
deeper
discussion.
Isn't
it
because
it's
more
of
a
physical
philosophical,
where,
until
when
do
we
want
consistency,
because
from
the
moment
that
they
click
a
button
on
the
widget,
they
now
go
to
the
context
of
security
and
now
should
it
be
consistent
with
the
widget?
Should
it
be
consistent
with
the
part
of
security
application?
C
C
B
B
A
C
To
the
the
work
so
yeah,
I
have
okay
so
before
we
had
discussed
at
this
point,
it
might
make
sense,
because
the
security
widgets
are
a
little
bit
more
interactive
to
introduce
a
feature
flag
specific
to
them,
so
that
we
cannot.
So
we
can
allow
ourselves
to
roll
out
that
we
did
extensions
without,
I
guess,
licensed
compliance
in
the
security
widget,
so
quick
status
update
license
compliance
and
security.
C
C
I
have
a
mr
up
to
to
feature
flag
out
license
compliance,
and
this
is
not
a
double
stacked
feature
flag,
meaning
it's
not
like
the
widget
extension
feature
flag,
plus
the
license
compliance
flag,
because
I
was
running
into
some
weird
edge
cases
where,
if
one
or
the
other
isn't
turned
on
like,
I
think
we
try
to
stay
away
from
double
nested
feature
flags.
So
what
I
did
is
I
refactored
it
and
extracted
the
the
show
hide
logic
to
be
a
dedicated
feature
flag.
C
Just
for
license
compliance,
so
there's
just
one
flag
for
it,
which
made
it
a
little
bit
easier.
The
problem
I'm
having
is-
and
I
might
have
to
follow
up
with
the
qa
team,
but
if
anyone
knows
we
have
a
two
jobs,
you,
the
package
and
qa
ff
name
feature
flag,
enabled
and
then
disabled,
the
disabled
job
runs.
Fine
it'll
run
the
automation
test
with
the
feature
flag
disabled,
but
I
think
because
we
have
some
front-end
automations
for
license
compliance
when
it's
turned
on.
C
You
know
it's
not
showing
it's
showing
the
the
widget
extension
the
unit.
The
automation
is
failing,
so
I
don't
know
how
to
like
flag
that
out
or
go
around
it.
I'm
looking
at.
If
I
could
share
my
screen.
Miranda
looks
like
she
had
a
mr
merch
recently
that
allows
for
a
specific
feature
flag,
but
I
pretty
much
took
the
approach
he
did
and
just
stubbed
out
the
there's
this
the
spec
file.
Okay,
that's
not
jumping
to
it!
C
A
C
A
C
A
Okay,
I
think
you
can
stop
shooting
the
screen
cool.
So
the
next
point
was
something
that
you
pinged
us
on
on
slack,
and
I
wanted
to
bring
it
up
here
to
see
what
everybody
thought
having
an
alias
for
the
working
group.
I
feel
like
there
are
two
kinds
of
alliances:
one
is
slack
user
groups
and
the
other
is
git
lab
glasses.
I
don't
know
what
to
call
it.
A
Do
you
feel
the
need
for
it?
I
can
totally
see
the
way
that
it's
easier
for
just
quick
broadcasted
messages
to
all
the
owners
of
widgets,
because
we
need
we
need.
Sometimes
we
need
to
like
do
a
quick
check,
whether
we're
rolling
out
feature
flags
or
we're
rolling
out
a
change
or
something
they
might
want
to
like
quickly
notify
the
all
the
right
people.
A
C
I
I
thought
about
the
samore
after
I
pinged
you
and
it's
tricky
because
like
if
we
ping
everyone,
the
slack
channel,
there
are
a
lot
of
people
in
there
that
are
like
between
engineering
managers,
front
end
designers,
engineers.
Sometimes
you
only
need
to
ping
a
design.
You
know
you
want
the
designers
to
know
all
right,
get
feedback.
Remember
sometimes
you
just
want
the
front
end
engineers
are
working
on
this.
C
So
then
I
don't
even
know
it.
I
don't
want
to.
I
mean
it's
almost
like
we
kind
of
need
two
like
two
aliases
at
least
one
for
like
or
three
maybe
everyone
designers
engineers.
Sometimes
I
just
want
to
talk
about
implementation,
not
design,
and
sometimes
I
want
to
talk
about
design,
and
sometimes
you
want
to
ping
everyone,
but
right
and
then
so
I
don't
know
that's
overkill,
to
have
like
a
bunch
of
different
nail
views.
I.
B
A
That's
why
I
first
I
initially
I
was
thinking
the
most
urgent
ones
that
we
might
be
in
a
hurry
to
ping.
Everyone
are
the
people
looking
after
the
ones
that
are
live,
so
the
owners
of
the
widgets
engineering-wise
make
sense
in
case
there's
something
in
production
happening
an
incident
or
something
we
need
to
have
a
quick
way
of
pinging
everyone,
and
we
might
you
don't
want
to
forget
someone
so
having
that
user
group
might
be
a
good
thing
now,
so
my
vote
would
be
to
start
with
engineering
and
go
from
there.
A
Maybe
I
can
update
the
documentation
of
the
working
group
in
the
handbook
to
say
here's
a
table
table
of
widgets
that
are
online
and
here's
the
owners
and
then
once
the
working
group
dissolves,
we'll
actually
I'll.
Just
put
that
in
the
handbook
that
it's
not
inside
of
a
working
group
somewhere
I'll
figure
it
out.
And
then
we
can
use
that
list
as
a
quick
ping
people.
I
don't
know,
but
I'm
all
for
it-
set
up
setting
up.
Always
your
group
user
user
group
on
slack
and
go
from
there.
B
I
was
this
just
reminded
me
of
the
table
that
we
have
in
the
handbook,
and
we
andre
basically
just
said
that,
so
I
was
just
wondering
if
we
could
rely
instead
of
breaking
up
further.
We
could
rely
on
the
roles
there
and
then
you
know
just
notify
those
that
you
need,
and
maybe
we
need
to
update
that
table.
Like
you're
saying.
A
Yeah,
I've
done
something
in
the
past
for
for
the
misused
terms,
which
I
I
can
add
a
section
to
that
page
of
like
a
quick
slack.
But
I
is
it
okay
to
still
leak
the
slack
handles
on
the
handbook,
because
it
would
basically
be
a
copy
based
thing:
it'll
be
something
you
expand.
You
have
all
the
ads
there,
but
it
feels
like
we're.
A
I
don't
know
it
feels
uneasy.
I
think
the
slack
user
group
just
the
easiest
way
for
the
quick
thing
for
engineering
wise.
For
the
rest,
I
would
defer
to
the
table
like
you're
suggesting
yeah
because
well,
I'm
concerned
more
about
incident
management,
and
we
can
add
a
section
to
this
page
saying
that
for
incident
purposes
you
can
feel
free
to
tag
the
slack
user
group
x.
That
will
decide
for
any
incident
manager
coming
to
this
page.
A
A
A
C
Sure
I
just
wanted
to
do
a
quick
review.
I
I
saw
the
ping
in
the
working
group
slack
channel
that
we
added
the
column
for
feature
flags
thanks
for
doing
that,
whoever
added
it
so
we
have
contents
of
what's
rolling
out.
I
saw
that
the
security
widget
is
marked
as
individual,
which
is
true,
that's
the
plan,
but
it's
not
actually
merged
in
yet.
So
that's
why
I
called
out
the
mrs
and
draft
state.
I
don't
know
what
the
plan
is
of
the
mr.
C
C
I
could
ask
him
if
it's
okay,
to
have
him
redo
the
mr
or
refactor
it
to
only
have
the
feature
flag,
part
of
it.
So
at
least
the
code
is
guarded
and
whatever
incremental
improvements,
you
could
add
behind
the
flag,
but
basically
that's
where
we're
at.
I
think
these
two
widgets
are
waiting
on
things
and
once
the
plan
is
this
milestone
to
have
those
guard
feature
flag,
widget-specific
feature
flags
in
master.
So
my
follow-up
question
is:
if
those
two
flags
are
in
this
milestone,
do
we
still
plan?
C
Do
we
want
to
push
forward
and
roll
out
the
other
widgets
globally?
Are
we
going
to
do
it
where
we
roll
them
out
incrementally
in
production
where
it's
percent
based
or
we're
just
going
to
flip
the
global
flag?
And
we
have
a
strategy
for
for
that
in
terms
of
testing
or
getting
user
feedback
or
because
it
seems
like
a
pretty
drastic
change,
because
we're
swapping
out
how
many
are
there?
I
think
it's.
A
C
The
security
one
right
now
is
unmerged
and
right
now
that
chain
this,
mr,
I
think
it's
planning
to
be
merged
soon,
so
yeah.
So
what
it
is.
The
mr
contains
the
version
one
of
the
security
widgets
plus
the
flag.
So
I
think
that's
what
they're
going
for
it's
like
you
know
whatever
implementation
they
have
now,
that
is
kind
of
somewhat
complete
with
the
flag
in
the
mr,
but
I'll
encourage
if
there
is
more
churn
in
that.
C
A
Yeah,
which
brings
to
another
point,
which
is
the
rollout
of
this,
going
to
be
a
little
bit
complicated,
and
I
know
that
we're
all
like
every
owner
is
trying
to
put
their
widget
in
there
in
the
best
shape.
But
I
feel
like
we.
We
need
to
elect
responsible
for
the
rollout,
like
specifically
the
process
of
rollout,
so
I'll
ping
on
slide,
because
we
don't
have
a
lot
of
engineers
here.
So
I'll.
A
A
So
I'm
going
to
check
in
and
see
if
we
can
have
a
an
engineer
selected
for
the
next
week,
or
at
least
so
we
can
have
that
starting
to
move
on
more
decisively,
because
I
feel
like
we're
constantly
checking.
Are
we
ready?
Are
we
ready,
but
somebody
needs
to
be
paying
exclusive
attention
to
the
rollout
and
I've
been
trying
to
do
that.
But
failing
at
it
miserably
trying
to
break
some
clarity
to
it,
but
does
that
sound
like
a
good
idea,
have
a
diy
for
the
robot.
A
A
So
I'll
add
it
to
my
to
do
too
thanks
for
the
reminder,
okay,
reminder
for
the
staging,
because
we
need
to
make
sure
that
the
the
qa
test
and
everything
and
it's
all
ready
and
not
breaking
to
staging
reminder
for
the
staging
project
cool.
Then
I
guess
that's
it.
Anybody
has
any
other
points
that
are
not
in
the
agenda
that
you
want
a
device.