►
From YouTube: 2021-10-21 Working Group: Merge Request Report Widgets
Description
Eighth weekly meeting of the WG.
https://docs.google.com/document/d/1bcch8UUkwmgEHFolTWDrQFJtUiiXlv_yQFAGwSSDSUE/edit#
A
All
right,
we
are
live
for
the
eighth
session.
I
don't
know,
I
don't
know
if
it's
the
eighth
or
ninth
session
for
the
working
group
for
merge,
request
report
widgets.
So
thanks
everyone
for
joining
us
today
we
have
quite
the
agenda.
So
let's
jump
right
in
first.
First
point
we
have
gina.
Gina
is
not
on
the
call.
A
B
So
I
fixed
some
things,
I'm
pretty
sure
I'll
fix
them
all
and
then
the
millions
of
conflicts
that
I've
had
to
solve.
I'm
pretty
sure
I've
solved
some
of
them
incorrectly,
which
is
a
revert
to
some
of
the
changes.
The
books
that
we've
found
like
it's
fine
I've
got
one
of
the
fixed
now
I'll
have
to
fix
soon.
A
C
Yeah,
currently,
all
the
testing
issues
are
scheduled
in
backlog,
because
they've
they've
been
blocked
waiting
for
core
component
features.
I
just
wanted
to.
I
went
through
and
look
through
the
status
statuses
of
those
issues,
but
what
is
the
status
on
the
following
features?
So,
first
ability
to
categories
categorize
items
in
the
list
like
new
removed?
Is
that
still
being
worked
on,
or
is
that
already
done.
A
Okay,
so
we
might
be
missing
an
issue
or
something
so
when
we
did
the
initial
split
up
of
the
issues
we
knew
we
were
bound
to
something
escape
escapists.
So
what
I
would
ask
is
for
someone
someone
comfortable
with
the
problem
or
the
that
area,
to
open
up
an
issue
and
attach
it
to
the
epic
so
that
we
can
then
track
it
and
schedule
it
probably
for
14.6
would
be
something
that
we
could
work
on
or
if
somebody
wants
to
work
on
right
away
and
adding
that
support.
A
A
C
B
So
technically
the
core
component
doesn't
have
any
data
fetch.
It
would
be
up
to
the
actual
extension
itself.
Now,
technically,
it
will
be
possible
to
pull
in
the
way
it's
currently
done,
just
as
no
examples
of
how
it
would
be
done
or
if
it's
the
right
way,
we
should
do
it.
So
I
guess
it's
on
me
to
try
and
put
an
example
together
all
right
and-
and
maybe
I
mean.
C
B
A
I
have
a
question
on
that,
though,
so,
if
you
do
it
outside
of
the
core
component
and
each
widget
handles
the
data
loading
great,
you
have
a
lot
of
flexibility
to
handle
your
apis
to
wrangle
them
in
whatever
way
you
need
it.
My
question
is:
would
it
be
better
and
more
consistent
if
we
let
the
core
component,
do
that
or
would
we
have
to?
You
know,
set
up
a
whole
bunch
of
standard
api
formats
or
something
or
would
that
be
worse?
That's
my
question
because
you
have
consistency
but
it'd
be
more
restrictive.
B
A
A
A
I'm
thinking
here's
what
I'm
thinking,
if
you
want
to
add
logic,
to
pause
when
the
visibility
leaves
the
page
like
we
did
on
the
merge
requests.
It
would
be
much
easier
to
do
consistently
on
the
core
component
to
just
stop
triggering
those
calls.
Instead
of
having
everyone
hey
now,
please
update
your
code
to
check
the
visibility
api
of
the
page,
so
if
they
could
just
have
when
they're
initializing,
the
widget
passes
the
the
step
of
the
not
recursion,
but
the
step
of
the
polling
and
the
core
component
would
trigger
it.
A
So
I
think
that
will
be
covered
by
the
content
sections
level.
Three,
let
me
just
open,
let
me
just
show
the
screen,
so
this
is
the
add
support
for
content
sections
level
three,
and
I
think
this
would
be
it
level
three
that
section
and
then
the
expansion
and
everything
will
be
done
by
the
other
actions
and
actions
for
level
one
and
action
level,
two
which
will
have
the
expansions
and
stuff.
So
I'm
guessing
part
of
it
of
the
sub
levels
that
you're
talking
about
of
the
nested
levels
might
be
handled
by
these
issues.
A
A
A
Cool
which
takes
me
to
the
next
point,
which
is
also
about
telemetry,
and
so
the
code
review
ux
designer
annabelle.
She
did
a
great
job
at
giving
a
bit
of
an
overview
about
what
the
wealth
of
knowledge
wealth
of
events
and
instances
and
calls
to
action.
We
would
like
to
add
telemetry
too,
and
a
lot
of
these
cover
multiple
widgets.
So
maybe
I
can
share
my
screen
as
well
to
get
it
into
the
recording
and
oh,
we
have
a
guest
appearance,
hi.
A
So
we,
as
you,
can
see
the
in
bold,
you
have
the
widget
and
then
in
parenthesis
you
have
the
call
to
action.
So
it's
like
accessibility,
the
approvers
branches,
browser
performance,
merge
post,
merge
with
them
when
it's
after
the
merge
and
everything.
So
some
of
these,
as
you
can
see,
are
for
widgets
that
are
covered
by
this
working
group.
A
We
we
opened
up
basically
issues
for
each
one
of
the
groups,
so
basically
we
gathered,
for
example,
in
the
merge
one.
We
have
all
the
calls
to
act,
all
the
calls
to
action
that
was
identified
on
that
table
and
if
you
look
at
it
some
of
these,
like
the
browser
performance
little
performance,
please
ignore
that
they're
assigned
we're
kind
of
like
reassigning
them
at
the
moment,
but
some
of
these
are
covered
by
the
working
group
widgets
right.
A
So
what
I
wanted
to
give
a
heads
up
to
people
is.
This
is
something
that
we
think
would
be
most
appropriate
for
the
groups
to
handle,
because
they
know
better
how
the
widgets
are
built
and
how
they
were
written
for
this
particular
iteration
of
the
new
one.
So
we
will
be
adding
functionality
to
the
core
component
for
the
telemetry,
but
we
still
need
the
widgets
to
use
that
car
functionality
and
we
expect
to
collaborate
a
little
bit
to
get
to
the
bottom
of
how
we
should
build
that
support.
A
Okay,
now
the
call
to
action
here
or
is
there's
a
bunch
of
issues
in
that
epic,
as
you
can
see,
that
cover
group
widgets
and
not
the
core
widgets,
so
that's
it
just
feel
free
to
jump
in
there
and
and
and
pick
them
up
as
you
go.
The
one
detail
I
would
like
to
call
attention
is
exactly
one
of
the
things
we
have
discussed
is
if
we
so,
for
example,
to
add
telemetry
to
the
browser
performance.
A
Now
we
have
a
question:
if
we
add
it
only
to
the
new
widget,
then
we'll
only
start
gathering
data
when
we
roll
out
the
main
feature
flag.
Because
from
what
I
understood,
we
have
one
feature
flag
to
rule
them
all
right.
So
we
have
to
wait
for
all
widgets
to
be
ready
to
roll
down
be
rolled
up
before
we
even
start
gathering
telemetry
and
that's
unfortunate,
because
telemetry
takes
time
to
roll
out
properly
to
customers
and
everything.
A
So
the
suggested
approach
would
be
when
we
add
telemetry
to
the
browser
performance
which
it
would
add
to
both
the
legacy
and
the
new
which
is
duplicated
work,
but
the
earlier
we
start
gathering
the
better.
So
that's
kind
of
like
a
caveat
for
the
engineers
who
pick
up
this
work
but
we're
we're
willing
to
discuss.
Maybe
we
can
start
discussing
rolling
out
the
widgets
one
by
one
if
we
we'd
like,
I
expect
there
to
be
some
instability.
A
If
we
already
adding
car
functionality
for
adding
functionality
to
the
car
component,
we
might
break
things
so
not
feeling
very
comfortable
about
that.
So
yeah
we
might
have
to
go
bite
the
bullet
and
just
use
those
two
approaches
built
for
the
legacy
and
the
new.
So
I
want
to
hear
your
thoughts
if
anybody
wants
to
take
anything
feel
free
to
ping
us
and
we
can
help
out
filling
in
the
gaps.
C
C
A
Okay,
I'll
so
just
for
clarity,
we
will
not
we're
not
in
the
code
review
group.
We
will
not
look
at
those
issues
that
are
for
specific
widgets,
we'll
let
you
handle
that
and
burn
that
down
we'll
be
supportive
and
then
collaborate
when
we
need.
But
that
sounds
like
a
good
first
approach
to
start
burning
those
down.
In
that
sense,.
A
D
D
A
A
There
so
for
what
I
got
from
the
pm
is
that
once
we
roll
out
the
telemetry,
we
seeing
like
a
slow
uptake
as
it
takes
a
couple
of
miles
of
months
to
actually
start
getting
a
good
coverage
of
those
changes
show
rolled
out
to
customers
today,
phil
this
telemetry
will
go
to
customers
right,
we'll
catch
the
self-hosted
instances
as
well
right.
So
the
the
conscious
we've
we've
learned
is
that
if
you
roll
out
something
on
fourteen
five,
it
might
take
multiple
months
until
customers
start
updating
for
fourteen
five
right.
A
So
the
earlier
we
ship,
the
telemetry
changes
the
better
now
part
of
me
kind
of
wants
to
have
a
like
a.
I
can't
believe
I'm
saying
this
in
the
recording
a
trojan
horse
that
would
just
call
home
and
check
what
code
chatting
to
run,
but
security
would
never
let
us
do
that.
We
would
never
do
that,
so
we
need
to
just
stagger
the
role
out
of
this
or
just
be
aware
of
the
staggered
rollout
that
this
will
have
and
take
time
to
get
to
customers.
So
that's
that's
where
the
rush
comes
from.
A
Is
we
need
to
learn
more
about
this
data
so
that
we
can
make
more
informed
changes
and
updates
and
everything,
because
we're
flying
blind
in
most
of
these
areas
in
terms
of
feasibility,
interaction,
and
this
will
be
useful
for
your
groups
as
well,
so
getting
to
know
how
people
are
using
this
widget.
So,
for
example,
we'll
be
able
to
tell
the
expansions
of
those
areas
and
you'll
be
able
to
see
how
often
the
people
interact
with
these
and
that
will
lead
for
better
ux.
A
Maybe
they
were
didn't
bear
in
mind
that
we
did
no
assessment,
whether
these
already
existed.
So
we
just,
we
did
a
mapping,
we
saw
what
we
wanted
to
track
and
we
created
the
issues.
But
yes,
there
might
be
already
an
overlap
with
the
ones
being
tracked
and
that's
a
matter
of
the
engineer
looking
at.
Is
it
done
already
like?
Do
we
need
to
add
more
or
not?
Okay,
yeah.
A
About
the
new
one
should
definitely
take
the
telemetry
as
early
as
possible
just
to
make
sure
that
once
we
roll
them
out,
we
already
have
it
covered
yeah
for
the
legacy
I'll
defer
to
your
teams
to
figure
that
out.
I
guess
we
in
code
review
we'll
start
looking
at
the
merge
ones,
which
is
the
ones
we
take
control
over
the
merge.
The
post
merger.