►
From YouTube: 2022-01-13 Working Group: Merge Request Report Widgets
Description
Fourteenth weekly meeting of the Working Group.
Agenda: https://docs.google.com/document/d/1bcch8UUkwmgEHFolTWDrQFJtUiiXlv_yQFAGwSSDSUE/edit
A
A
second
and
I
think,
we're
live
yeah.
We
are
hi.
Everyone
welcome
to
yet
another
weekly
meeting
for
the
working
group
of
mergy
quest
report
widgets.
I
believe
this
is
the
14th
edition
of
this
call.
I
could
be
wrong
I'll
check
later
and
we'll
cut
straight
into
the
announcements.
Peyton
is
not
on
the
call.
A
So
I'll.
Just
read
out
his
point.
Welcome
jeremy,
sorry
for
keeping
you
in
the
waiting
room.
I
missed
you
there
so
peyton
head
announcement
polling
is
now
ready.
All
you
have
to
do
is
put
enable
pulling
true
in
your
extension
options
and
you
take
care
of
the
rest.
If
polling
is
not
working
for
you
ensure
that
the
back
end
endpoint
is
properly
set
up
for
you
to
work.
A
A
B
A
Yeah,
I
we
have
discussed
this
in
the
past.
Technically
we
can
do.
However,
we
want
whether
we
want
to
enable
the
mix
and
match
of
like
having
some
widgets
in
the
new
layout
someone
just
in
the
old
layout.
This
is
technically
possible
in
terms
of
of
consistency
on
the
ui.
I
think
we
can
all
agree
that
would
be
best
to
have
the
whole
thing
look
the
same.
C
A
B
Yeah,
it's
a
good!
It's
a
tough
question
about
the
topic
of
early
feedback.
When
we
did
a
lot
of
changes
for
the
left
sidebar
on
the
navigation,
we
had
these
enabled
for
specific
users
in
our
own
team,
so
they
could
see
this
across
the
entire
part
of
the
product
and
also
over
the
entire
like
day,
instead
of
just
going
to
a
specific
part
of
the
product
on
a
specific
time.
So
maybe
that
could
already
be
a
good
idea.
B
Maybe
we
can
just
enable
this,
for
maybe
even
all
of
the
gitlab
employees
that
could
give
us
enough
early
feedback
so
that
we
don't
have
this
weird,
this
weird
visual
of
mix
and
match
for
our
customers.
Maybe
that
could
be
a
good
good
combination
already,
enabling
it
rather
soon
for
the
gitlab
employees,
get
the
early
feedback
and
still
waiting
for
49
1410
to
release
them
to
all
users
to
hopefully
have
them
all
visible
at
once.
A
A
They
would
be
showing
this
mixed
mergercast
widgets,
which
again
whether
we
either
accept
it
or
we
don't
accept
it
from
the
usability
perspective,
because
then
the
rollout
we
always
want
to
have
to
go
through
that
process
of
slow
rolling
it
out
to
certain
projects,
see
the
feedback.
So
that's
always
going
to
happen.
C
D
Start
with
onions
start
basically
with
the
website
project,
and
you
have
99.99
just
gitlab
employees,
some
site
pro
side.
Projects
like
hit,
delete
the
runner
and
so
on
and
so
on,
and
you
have
way
more
engineering
teams
and
finally
do
gitlab
itself
the
project.
Because
then
you
have
employees,
contributors
plus
cutters
in
that
way,
make
sense.
A
So
yeah,
I
feel
like
that's
a
good,
the
good
intermediate
approach,
since
we
are
pursuing
them,
the
the
implementation
of
the
widgets
for
14
9
14
10
at
most,
it
feels
like
he
wouldn't
go.
He
wouldn't
be
in
that
state
for
long.
So
as
we
roll
out
one
per
week,
it
would
give
us
the
time
that
we
need
to
get
to
the
finals
by
the
time
that
we
end
up
the
rollout.
We
might
just
go
and
just
turn
everything
on.
E
A
Thanks
janik,
so
so
far,
we've
been
doing
it
at
ad
hoc
I've
been
thinking
whether
we
should
have
a
particular
label,
because
the
working
group
label
will
will
stop
being
used
from
the
moment
that
the
working
group
ceases
to
exist,
and
the
idea
is
that
the
working
group
will
be
finite
in
time.
So
my
my
proposition
would
be
to
follow
the
example
of,
for
example,
transient
bugs
where
we
have
a
permanent
label
that
will
live
on
after
the
working
group,
and
we
can
mark
those
issues
with
that
label.
A
A
We
do
have
to
find
a
way
to
make
this
visible
to
the
relevant
engineering
managers
and
teams.
So,
but
but
then,
once
we
have
the
label,
we
can
start
preparing
issue
boards
that
can
help
make
that
visible
and
still
the
best
way
is
to
still
have
some
sort
of
responsible
people
looking
at
those
topics.
So,
for
example,
for
the
core
widget,
we
can
start
designating
group
that
groups
that
are
owning
each
part.
So,
for
example,
the
core
the
core
of
the
widget
could
be
owned
by
the
code
review
group.
A
We
could
be
responsible
for
prioritizing
that,
whether
we
do
it
ourselves
or
we
find
other
people
outside
of
the
group
to
do
it,
we
can
take
care
of
the
the
prioritization,
the
other
widgets.
So,
for
example,
you
have
some
things
here.
You
have
one
question
for
the
security
which
you
know
for
this
for
the
license:
compliance
widgets,
so
those
have
obvious
owners.
So
what
I
would
say
is
like
the
person
who's
interested
in
that
issue
should
definitely
tag
the
ems
on
those
groups
that
comes
with
like
a
direct
ownership
of
each
widget.
A
A
Things
that
need
to
be
updated
in
the
core
component
is
where
we
have
to
coordinate
more
with
ux
and
front-end
and
potentially
even
back-end,
but
I'm
happy
to
take
the
code
on
the
the
ownership
from
the
code
review
perspective
of
core
lab
co-op
coordinating,
not
necessarily
executing.
If
that
makes
sense,
we
don't
want
to
be
the
bottlenecks,
but
we
are
able
to
be
the
connectors.
If
that
makes
sense,
does
that
make
sense.
E
Yeah
yeah
yeah
it
does.
It
does
make
a
lot
of
sense.
So
that
sounds
like
a
like:
a
pretty
good
approach
and
a
pretty
structured
approach
to
be
had.
How
are
we
going
to
deal
with
those
specific
issues
like?
Are
we
should
we
do?
We
want
to
set
this
up
now
and
basically
make
these
three
things:
the
very
first
issues
to
be
properly
labeled
and
go
for
this
process,
or
how
do
we
feel
about
that.
A
For
these
particular
issues,
I
already
left
a
comment
at
each
one
of
those
three,
the
I
have
some
questions
for
each
one
of
these
and
I
think
the
existence
of
these
issues
is
exactly
why
this
working
group
was
formed
because
a
lot
of
these
things
that
we
have
done
there's
a
reason
for
them
to
be
restrictive,
so
the
so,
for
example,
the
first
one
where
you
asked
support
extensions
that
don't
require
multiple
requests.
The
fact
that
we
did,
that
is
to
protect
the
performance
of
the
whole
the
whole
page
in
the
beginning.
A
Now
there
might
be
some
cases
where
the
widget
doesn't
do
like
super
heavy
lifting
on
the
requests,
but
the
reason
why
we
did
with
multiple
requests,
if
I'm
not
mistaken
field,
please
correct
me
was
to
exactly
separate
that
thing
load.
First,
the
summary
data
and
then
once
you
have
the
expansion
of
the
widget
by
the
user,
then
you
can
load
the
rest
of
the
data,
but
that's
why
we
need
to
discuss
this
further
to
understand.
E
A
Of
the
core
component
or
on
the
back
end
on
the
back
end,
that's
that's
right
that
I
think
that's
a
fair
thing
to
expect
and
let
me
let
me
explain
so
we
we
shouldn't
cohort
coerce
the
core
component
of
the
merge
request
report
widgets
just
because
the
backend
api
already
exists.
If
that
makes
sense,
so
we
should
definitely
probably
have
to
do
some
further
development
on
the
back
end,
which
could
be
a
blocker
given
that
there's
some
some
some
priorities
running
on
the
back
end,
but
that's
what
we
expect.
Yes,
there
might
be.
A
You
might
have
to
do
some
adaptations
on
the
back
and
to
split
the
requests
into,
but
the
goal.
The
good
thing
is
that
the
end
result
would
be
better
for
performance,
we'll
load
a
far
quicker
summary,
not
use
all
the
memory
and
then
once
the
user
expands
the
widget,
then
we
request
the
big
payload
and
that
was
by
design
if
I'm
not
mistaken,
phil
thanks
for
the
sending
check.
A
The
other
things,
let
me
just
so
switch
switch
the
text
link
order.
I
feel,
like
that's
totally
reasonable
and
doable
it's
just
a
matter
of
getting
the
ux
to
to
give
us
the
go
ahead,
and
we
find
find
a
way
to
implement
that
the
uncollapsed,
the
uncollapsed
state
thing,
if
it's,
if
it's
supported
by
the
ux
framework
great.
But
it's
also
another
thing
that
we
have
to
see
that
we
don't
steer
towards
being
too
permissive,
because
one
of
the
concerns
we
had
was
just
to
not
have
a
huge
height
of
merge
request
widgets.
F
A
A
F
So
the
level
one
is
still
collapsible,
but
that
level
two
is,
that's,
that's
fully
expanded.
So
that's!
That's
just
that's
the
default.
The
only
difference
here
is
that
it
has
those
extra
like
the
title
and
the
descriptor
so
yeah.
If
you
look
at
all
the
examples,
like
all
those
section
twos,
the
level
twos,
I
should
say,
are
they're
expanded,
so
yeah
yeah.
This
is
this
is
correct.
A
F
Yeah
yeah,
when
the
parents
level
one
is
open.
The
level
twos
are
like
fully
visible,
for
whatever
content
is
within
them.
We
looked
at
originally
keeping
those
collapsed
or
scrolling
within
those,
but
we
didn't
want
it
to
be
too
much
of
friction
to
have
to
expand
one
and
then
expand
all
if
you've
already
intentionally
expanded
that
level.
One
you're
wanting
to
see
that
content.
So,
let's
show
it
so.
A
Here,
that's
fine!
You
helped
thanks,
okay,
so
yannick
for
coming
back
to
that.
Let's
follow
up
the
discussions
on
the
issues
and
they
will
be
considered
for
prioritization
for
the
upcoming
milestone,
so
we're
this
is
a
great
moment.
What
I
was
actually
thinking
is
exactly
to
document
something
which
goes
to
my
last
point
document,
something
about
having
labels
but
then
having
potentially
a
group,
not
a
group
called,
but
basically
have
a
group
of
people
be
responsible
for
looking
at
these
labels
every
milestone.
A
So
before
the
start
of
every
milestone,
before
the
planning
of
the
milestone
like
we
do
for
performance
work
like
we
do
for
security
issues
grab
another
pipeline.
That
would
look
at
these
particular
sorts
of
issues
and
this
would
actually
fall
into
my
groups.
So
it's
something
that
we
can
totally
do
in
in
supporting
again,
not
that
we
will
execute
them,
but
we
will
coordinate
them
as
a
kind
of
I
don't
like
the
word
of
gatekeepers,
but
the
gatekeepers
of
merge
requests.
A
Speaking
of
documentation,
I'll
move
on
to
my
next
point,
I
wanted
to
get
a
an
update
on
documentation
or
at
least
to
raise
this
topic
again,
because,
if
you're,
if
you
remember
the
idea
for
this
working
group
was
to
have
it
complete
their
goal
or
exit
criteria
by
the
end
of
quarter
four.
So
by
the
end
of
this
quarter,
we
should
be
able
to
dismantle
the
working
group
and
have
a
process
in
place
to
support
the
evolution
of
the
report.
A
Widgets
in
that
two
of
the
exit
criteria
that
we
have
and
again
congrats
for
everyone,
and
thanks
for
the
work
that
you've
been
doing
on
improving
the
core
components
and
rewriting
the
the
extensions.
It's
been
great
to
see
that
evolution
we're
getting
very
close
to
the
aegis
criteria
to
being
fulfilled.
A
A
I'm
worried
about
the
technical
guidance
from
engineering
perspective
and
also
technical
writing
that
I've
already
reached
out
to
amy
amy
quals,
our
technical
writer
on
create
I
or
reach
out
to
her
and
she's
already
on
top
of
it.
She
will
think
about
something
to
write
down
some
orientations
on
the
copy
to
make
sure
that
the
copy
is
consistent
throughout
the
widgets.
So
that's
already
been
looked
at
by
her,
but
from
our
perspective
engineering
wise.
A
C
A
Yeah,
I
think
what
we
decided
is
that
these
these
involve
network
requests
and
a
bunch,
so
they
would.
This
would
be
too
smart
of
a
component
to
put
in
gigabyte.
I
remember
correctly,
okay,
so
yeah.
The
answer
is
no,
unless
something
changes
or
unless
the
gitlab
ui
starts
supporting
some
of
the
different
kinds
of
components.
But
I
think
the
answer
is.
A
A
So
I
found
it
currently
we
have
this.
Could
we
evolve
this
and
you
said
I
don't
see
why
not
all
right
so
who
would
be
responsible
for
this?
Is
this
something
that
we
can
delegate,
because
I
see,
for
example,
now
there's
we're
getting
to
a
place
where
we
already
have
a
way
to
specify
all
types
of
content
for
the
sections
and
all
that
stuff.
A
It
would
be
a
good
moment
to
capture
those
options
and
examples
of
code
into
the
documentation,
but
we
still
have
our
resources
filled
up
by
actually
doing
the
work,
so
it'd
be
good
to
have
some
external
help.
Writing
that
documentation,
but
it's
also
technical.
This
is
phil.
I'm
I'm
mostly
concerned
about
protecting
you,
because
you
still
have
work
to
complete
for
the
support
of
the
widgets.
C
A
A
A
Can
we
have
an
issue,
yes
I'll,
create
an
issue
outline
what
what's,
what
we
need
to
have
from
that
documentation
so
that
we
have
more
idea
and
having
that
issue
will
then
help.
You
also
include
amy
for
revision
and
that
sort
of
thing
later
and
we'll
look
into
scheduling
it
already,
for
this
discord,
master.
A
I
would
really
be
keen
on
getting
an
outcome,
whether
it's
something
that
the
ux
wants
or
objects
or
something
like
that
would
be
interesting
to
get
feedback.
I'm
not
sure
if
we'll
be
able
to
implement
it
right
away
on
14
8,
but
still
49
would
be
a
good
moment
to
get
on
that
so
I'll.
Let
that
here
just
as
a
reminder.
A
F
F
A
F
A
To
them,
so
basically
you
would
have
the
whole
row
would
be
defaulting
if
you
click
on
the
white
space,
if
you
click
basically
on
a
non-link,
you
just
default
to
this
principal
action
of
expanding
or
something.
But
then,
if
you
click
on
the
text
of
the
link
or
something
else,
you'd
go
to
that
link
specifically,
so
you.