►
From YouTube: 2021-09-02 Working Group: Merge Request Report Widgets
Description
Second weekly meeting.
Agenda:
https://docs.google.com/document/d/1bcch8UUkwmgEHFolTWDrQFJtUiiXlv_yQFAGwSSDSUE/edit#
A
Hi
everyone
welcome
to
the
second
meeting
of
the
working
group
for
the
merge
request
report
widgets
and
today
we
have
a
couple
of
things
to
talk
about,
so
we
have
the
the
one
announcement
I
wanted
to
make
was
the
merger
is
finally
merged
thanks
rianna
for
hitting
the
button.
It's
already
live
on
the
handbook.
A
One
of
the
things
that
I
still
have
to
check,
though,
is
I
haven't.
I
haven't
talked
to
tim
zalman,
yet
he's
the
sponsor,
so
I
will
try
to
once.
He
comes
back
from
pto
he's
on
pc
this
week
once
he
gets
back
we'll
validate
whether
this
time
works
for
him,
because
he
hasn't
attended
one
yet,
and
I
would
like
to
have
him
over
so
we'll
see
what
that
means.
A
I've
also
talked
to
daniel
tian
and
he's
still
looking
for
a
time
slot
that
works
for
the
majority
of
tech
leads
and
apec,
but
he's
still
watching
the
recordings
and
following
along
so
he's
still
aware
of,
what's
happening,
we're
just
trying
to
make
it
a
bit
more
inclusive
so
that
we
can
have
that
secondary,
alternate
slots,
but
we
still
don't
have
any
proposals
so
we'll
just
continue
on
with
weekly
on
this
time.
For
the
time
being
and
then
we
we
adjust
when
we
need.
A
Right
cool
discussion
items
the
one
thing
that
was
left
over
from
the
merge
request,
and
there
was
some
some
good
discussion
over
there
pedro
raised
it
and
raised
it
as
well
about
the
the
end
date
for
the
working
group
and
right
now
we
merged
it
merged
it
at
the
end
of
quarter
three
now
I
think
we'll
be
worth
having
a
little
bit
of
a
discussion.
A
What
that
means,
why
is
it
better?
Is
there
anything
that
we
can
choose
that's
more
meaningful
for
the
whole
group,
so
yeah
anyone
has
thoughts
on
on
the
date.
Please
speak
up.
B
A
D
B
I'm
biased
I'm
in
favor
keeping
it
right
to
the
end
of
quarter,
but
I
think
it
would
be
interesting
if
we
could
access
assess
what
we
will
be
able
to
deliver
by
the
end
of
the
quarter
if
it's
actually
the
start
of
implementation,
changes
right
or
the
plan
for
what
those
changes
would
look
like
and
and
how
they
will
be
executed.
So
that's
that's.
My
initial
thought
myself.
E
E
I'm
still
not
sure
if
the
work
on
mr
widgets
will
be
finished
by
then,
and
if
we
should
keep
it
more
flexible,
because
our
chaos
are
intentionally
ambitious
and
okay,
us
also
don't
expect
100
completion.
So
maybe
we
separated
from
this
I'm
open
to
either
option
they
both
have
advantages
and
disadvantages,
but
yeah.
I
I
think
this
is
something
where,
where
we
can
decide
which
option
we
go
with
and
either
one
will
will
be
fine.
A
Okay,
I
can
voice
my
opinion
just
one.
I
I
understand
the
the
alignment
with
the
with
the
okr
one
of
the
things
that
I
was
looking
at.
Looking
at
the
exit
exit
criteria.
Looking
at
the
exit
criteria,
somebody
can
write
as
I
speak.
That'll
be
awesome
thanks.
A
So
we
have
to
shepherd
implementation
and
redesign
of
10
extensions.
The
shared
component
folds
the
report
to
basically
supports
the
framework.
The
documentation,
reflects
the
capabilities
of
the
shared
component
and
ensure
that
there's
a
clear
documentation
written
for
extending
the
component.
So
while,
while
we
have
four
exit
criterias,
one
of
them
relates
directly
with
the
okr.
I
agree
with
that
and
the
reason.
A
The
original
reason
why
we
considered
doing
a
working
group
and
not
a
shared
okr
between
different
groups,
was
exactly
because
we
already
anticipated
that
the
effort
would
go
beyond
a
quarter,
so
that
would
be
my
argument
for
pushing
it
at
least
at
the
end
of
the
next
quarter.
That
would
be
the
end
of
the
quarter
four
because
it
would
allow
us
to,
or
maybe
we
can
even
do
not
bound
to
quarters.
A
I
mean
that's
totally
fine
too,
because
I
do
think
after
we
finish
the
implementation
of
the
of
the
widgets
and
I
think
we're
going
to
be
operating
on
fixing
the
support
of
the
framework
fixing
the
implementation
of
the
widgets
and
then
updating
the
documentations
as
we
go.
But
we
all
know
how
documentation
takes
a
long
time
to
get
right.
So
I
think,
there's
probably
going
to
be
some
cleaning
up
after
we.
A
We
clear
all
that
from
the
lessons
learned
and
all
that,
so
that
will
drive
the
the
last
bit
of
the
exit
criteria
so
by
my
proposal
will
be
to
be
at
the
end
of
the
quarter.
Four
just
to
have
time
to
you
know
complete
the
non-100
achievement
of
the
okr
and
plus
make
sure
that
we
have
time
to
really
hammer
out
the
documentation
in
the
process.
A
That
is
a
good
question.
I
don't
have
an
answer.
C
I
mean
because
in
this
case
the
okrs
already
apply
pressure
on
the
assigned
groups
to
deliver
what
they
can,
because
it's
ambitious,
but
we're
all
aware
of
what
are
the
commitments
and
the
responsibilities
of
each
group
and
what
they
have
signed
up
for
the
working
group
itself,
kind
of
inherits,
the
due
dates
and
milestones
and
whatever
we
set
for
the
deliverables.
F
B
I'll
share
my
feeling
better,
and
it's
really
just
my
gut
feeling.
I
would,
I
think,
yeah
it's
the
teams.
They
know
that
they
have
to
to
deliver
right,
but
I
think
us,
having
a
set
due
date
to
facilitate
the
implementation
or
facilitate
the
progress
within
the
stage
groups,
would
also
help
them
stay
accountable
for
that,
even
if
we
say
as
a
wax
department
right
that
yeah
q4
we're
not
going
to
have
a
kr
for
merger
quest
widgets,
because
each
group
knows
what
they
have
to
work
on
yeah.
B
Are
they
going
to
work
on
it?
Sorry,
folks,
if
you're
watching
this
later,
but
I
think
I
would
also
expect
us
to
enter.
Do
the
groundwork,
you
know,
documentation,
here's
what
needs
to
be
delivered
delivered
to
them
and
in
a
way,
leave
this
effort
like
exit
right
the
room
so
that
the
teams
can
also
implement
and
not
yeah,
keep
waiting
for
us
to
give
them
an
indication
of
what
happens
next
and
and
how
anyways
rambling.
B
Let
me
know
if
it
makes
sense,
but
yes,
I
would
say
I
would
appreciate
particularly
knowing
how
the
teams
operate
to
have
a
due
date
and
being
able
to
extend
that.
If
that's
the
case.
A
Nobody
here
thinks
that
so
yeah,
I
think
hayana,
you
said
it
well
like
it
provides
accountability,
and
if
we're
not
done
by
the
end
of
quarter,
four
we're
probably
slacking-
I
mean
unless
there
was
some
slippage
or
something
that
came
up
and
we
didn't
dissipate
or
something
so
I
think
having
that
is
generous
enough
to
provide
ample
capacity
for
even
given
all
the
things
that's
happening,
but
I
think
it
would
still
give
us
accountability
to
get
it
done.
C
Yeah
yeah,
it
does
yeah.
I
think
it's
okay,
it's
a
communication
issue,
I'm
with
marcel
at
this
moment
I'm
okay
with
having
it
and
not
having
it.
I
see
both
points
so.
F
A
Okay,
so
I
guess
we
can,
I
can
go
ahead
and
create
the
update
to
move
it
to
quarter
four
date.
Thanks
everyone,
I'm
I'm
I'm
hogging
the
agenda.
So
please,
if
you
have
any
thoughts
or
questions,
add
to
the
agenda.
It's
not
just
me,
the
biggest.
A
The
quick
question
that
I
just
came
up
with
my
my
mind
is:
should
we
have
a
working
group
label,
I've
seen
them
around
in
other
group
working
groups,
it's
good
to
capture
like
efforts
of
epics
and
issues
that
we
end
up
creating
and
then
we
can
contextualize
them
into
that
which
will
be
tasks
contextualized
to
this
working
group.
Anybody
has
thoughts.
Is
it
worthwhile?
Is
there?
Is
it
harmful
to
have
a
label.
A
What
would
we
use
it
for
so
the
anytime
we
have
like
epics
for
so
we
already
have
a
couple
of
at
least
I
anticipate
two
major
epics
one
is
to
add
support
to
the
framework
on
the
component.
A
The
other
is
to
implement
the
the
widgets
themselves,
which
we
already
have,
and
I
think
it
will
be
giving
us
a
tool
to
quickly
get
an
overview
of
things
that
are
happening,
and
this
always
provides
a
way
for
people
looking
from
the
outside
to
see
what's
the
activity
of
the
working
group,
they
find
the
label
and
they
click
on
it,
and
they
say:
oh
look
at
that.
They're
also
doing
this
yeah
and
that
worked
well
really
really
well
on
the
transient
bugs
and
in
there
we
had
two
labels.
A
One
was
the
the
working
group
for
the
the
label
for
the
working
group
tasks.
It
was
update,
documentation,
update
this
update
that,
and
there
was
the
label
that
was
the
product
of
the
outcome
of
that
working
group,
which
was
every
bug,
was
a
trained
enterprise.
The
label.
In
this
case,
I
think
we
just
need
one
for
the
working
group.
I
think
we
can
start
there
hyena.
B
No,
I'm
sure
we
probably
have
other
ways
to
practice,
but
I
think
in
general
yeah
having
a
label
having
a
way
to
see
and
track
the
progress
of
especially
the
stage
moves
over
the
guild
reek
before
would
be
useful
right,
especially
like
what
marcel
just
said
at
the
end.
Yeah
they're
gonna
use
the
framework,
but
are
we
gonna
still
be
helping
out
and
facilitating,
and
how
do
we
track
that?
Well,
I'm
pro
labels
in
any
case.
C
Yeah,
I'm
wondering
if
we,
if
we
could
have
an
epic
and,
if
necessary,
sub
epics
that
align
with
the
exit
criteria
so
that
we
can
close
out
initiatives
related
to
documentation.
And
all
of
that,
and
you
can
see
the
tree
of
exactly
what
the
working
group
is
doing
and
then
close
out.
The
epic
once
the
working
group
is,
is
complete.
C
C
I
can
I
can
create
the
the
main
epic
if
you
want
and
then
I'll
leave
it
to
you
to
to
create
the
sub
epics,
and
all
of
that
I
know
that
tim
was
already
creating
some
issues
for
the
implementation.
I
believe
so
we
can
move
those
over
there
if
necessary.
A
Okay,
thanks
peter
we'll
go
from
there
any
quick
anybody
has
thoughts
on
I'm
trying
to
avoid
the
mr
widget
legacy
thing.
I'm
trying
to
I'm
trying
to
go
for
the
expansion
of
it.
Should
we
go
for
the
for
the
full-on
merge
request
report
widgets
one:
are
we
going
to
keep
the
mr
report
widgets.
A
All
right
first,
it
is
thank
you,
okay,
so
I
just
want
to
take
the
opportunity.
Following
going
on,
we
had
a
technical
issue.
We
had
already
started
some
discussions
thanks
for
everyone
who
contributed
to
the
discussions
it
feels
like
we
have
some
consensus
around
some
topics.
One
is
about
where
you
will
live,
so
it
feels
like
we're
going
to
add
it
to
just
keep
developing
the
component
and
the
widgets
within
gitlab
or
gitlab
project.
A
We
are
going
to
do
emphasis
on
kpm
dumb,
so
that
they're
easily
reusable
and
sort
of
thing
we're
not
going
to
allow
slots
initially
so
that
we
have
a
strong
adherence
to
the
ux
framework
and
we
don't
initially
allow
veering
off
of
that
and
then,
if
somebody
has
needs
or
something
to
that,
don't
that
is
not
supported
by
the
ux
framework.
A
We
can
assess
whether
we
extend
the
framework
or
we
add
slots
at
that
time,
but
initially
it
doesn't
make
sense,
because
we
want
everybody
to
adhere
to
the
framework
itself
and
the
framework
is
very
widely
encompassing
to
the
needs
that
we
have
identified.
A
So
that's
the
two
outcomes:
there's
still
not
a
lot
of
activity
on
the
last
discussion,
which
is
to
break
down
into
sub
epics
and
issues.
This
is
going
to
have
to
happen,
so
I
am
asking
for
volunteers
if
you
want
to
help
with
this
breaking
down
of
of
the
the
tasks
of
those
two
efforts
like
adding
support
and
implementing
the
widgets.
Please
re
reach
out,
and
especially
there's
simple
widgets
that
we
can
start
with.
A
But
but
anyway,
I
just
wanted
to
say
that
that's
on
our
plan
to
drive
forward
within
the
next
week
or
so
cool
any
updates.
Since
last
meeting
on
this
topic
that
you
might
have.
A
Okay,
tim
did
say
that
he
was
going
to
take
the
lead
on
the
process
and,
of
course,
we're
still
very
young
and
very
early
and
he's
out
of
office.
I
don't
expect
any
updates
there.
Anybody
else
has
any
updates
or
questions
or
thoughts
or
concerns
that
or
haven't
been
addressed.
I.
C
Don't
know
I
don't
know
if
it's
a
question
about
the
process,
but
I'm
wondering
because
you
you
were
asking
for
volunteers
to
help
break
down
the
the
work.
C
Do
you
know
if
it's
possible
to
have
multiple
engineers
working
on
the
main
components
which
I
believe
we're
going
to
add
to
gitlab,
ui
or
but
nonetheless,
it
doesn't
matter
the
main
extension
that
exists
today
that
phil
created?
I
believe
the
idea
is
to
work
on
that,
so
that
it
matches
to
the
the
guidelines.
D
A
Yeah
I've.
One
thing
that
I
know
for
sure
is
that
it
would
be
important
to
have
one
common
maintainer
reviewing
it
and
I,
since
phil
started,
writing
it.
I
would.
I
would
advise
to
be
every
work
that
goes
into
that
component.
Go
through
him
as
a
review,
at
least
as
to
the
author,
as
long
as
it's
made
together
in
in
clear
communication.
A
So
that's
one
of
the
things
that
will
be
comparing
those
will
start
to
break
down
because
one
of
the
things
I
want
to
take
a
look
at
what
are
the
parts
of
the
ux
framework
that
we
can
start
driving
into
the
component
and
then
some
of
them
might
be
parallelizable.
A
Some
of
them
are
not
like
accessibility
parts.
You
can't
do
that
just
alone.
You
can't
just
put
accessibility
on
one
person
and
the
rest
that
doesn't
care,
but
certain
parts
like,
let's
make
sure
that
we
revise
the
icons.
We
can
put
a
person
on
that.
Let's
make
sure
that
we
revise
spacing
and
put
another
person
on
that
as
long
as
they're
in
communication.
A
I
think
I
really
feel
on
having
one
orchestrator
having
a
dri
for
that
car
component
and-
and
I
would
suggest
phil
just
because
he
wrote
it
and
he
being
the
maintainer
would
act
as
the
reviewer
part,
but
I
don't
think
it's
necessarily
a
done
deal
that
only
one
person
works
on
that
component.
A
I
think
it's
some
parts
will
be
parallelizable,
but
I
think
that
will
become
clear.
Every
start
to
break
down
is
that
fair,
phil.
A
C
I
think
that
that
answers
it
and
and
yeah
I
think,
that's
a
good
way
to
look
at
it
and
I
hope
that
we
can
paralyze
some
of
the
things.
C
I
wonder,
then,
if
without
trying
to
to
push
phil
under
the
bus,
but
I
then
wonder
if
I
mean
it's,
as
you
said,
it's
not
required
that
phil
does
the
implementation
himself,
but
I
agree
that
it's
helpful
for
him
to
be
the
maintainer,
but
with
all
of
the
knowledge
that
he
has
of
the
current
implementation
and
given
that
he
also
provided
some
feedback
on
the
framework
that
exists
today
in
terms
of
designs,
the
design
guidelines.
I
wonder
if
he
wouldn't
be
the
most
appropriate
person
to
do
that.
A
Group
up
we'll
we'll
group
up,
and
I
think
it's
useful
to
have
another
at
least
another
element
of
somebody
who'll
be
consuming
it
and
another
person
is
like
a
designer
with
us
on
that
exercise,
so
probably
I'll,
probably
think
about
having
a
sync
session
where
phil
will
be
driving
the
that
part
and
yeah
for
sure
cool
thanks.
A
I'm
thinking
mostly
about
those
I
can't
remember,
which
ones
are
simpler,
simpler,
widgets.
What
would
you
say
are
the
simple
widgets
marcel
you
get?
You
told
me
about
some.
E
Yeah,
looking
back,
I
think
at
least
two
or
three
of
the
testing
widgets
were
very
similar
and
had
very
simple
data,
at
least
from
the
what
is
being
displayed
perspective.
I
don't
know
if
the
data
loading
in
is
exactly
working
in
the
same
kind
of
way,
but.
A
E
C
Yeah,
I
was
just
going
to
say
the
top
of
mind
quickly.
Remember,
could
be
code,
quality,
browser
performance
and
accessibility
and
there's
also
another
one
load,
load
testing
or
something.
F
So
code
quality
will
be
more
complex,
but
there
is
browser
and
low
performance
and
metrics
are
and
accessibility.
So
we
have
like
four
that
are
basically
just
straight
up
lists
of
what
is
returned
from
the
api.
The
only
one
that's
really
complex
from
testing
is
the
test
summary
code.
Quality
has
been
passed
off
to
the
sas
team,
but
we
can
we're
happy
to
help
there,
since
we
just
barely
pass
it
off
to
him
yep.
E
The
one
difference
also
about
the
metrics
one
is
that
we
now
have
groups
and
new
changed
and
unchanged
no
yeah
new,
changed
and
unchanged.
I
think,
whereas
the
accessibility,
browser
performance
and
load
performance,
I
think,
are
just
items
below
each
other,
so
they
are
not
going
into
the
third
level
got
it.
Okay,
if
I
remember
correctly,
I'm
not
gonna
have.
F
Change
and
unchanged,
that's
the
yeah,
so
the
the
shared
component
we
have
now
currently
doesn't
have
that
change
in
unchanged
sections,
okay,
yeah,
so
we
can
just
do
the
other
ones.
So,
three
of
them
and
to
be
to
just
confirm
we're
good
to
just
start
whenever
we
can
on
those.
A
I
was
going
to
invite
you
scott
to
lead
that
threat
and
as
soon
as
pedro
created
that
major
epic,
we
could
create
a
sub
epic
to
or
okay.
Is
there
an
epic
already
to
implement.
F
There
is
an
epic
I
put
it
on
the
technical
issue,
I'll
link
it
in
the
agenda.
Thanks.
A
But
yes,
my
my
answer
is
start
right
away.
Implementing
and
re-implementing
this.
I
I
think
it's
fair
to
establish
expectations
that
we
might
hit
a
snag
and
we
might
hit
a
place
where
oh,
the
widget
doesn't
do
this
still
look.
The
component
doesn't
do
this
still,
let's
add
support
to
it,
but
still
it's
important
to
start
pushing
the
boundaries
of
what
it
can
do
without
really
paying
too
much
attention
to.
A
You
know
which
icons
are
being
used
or
the
spacing,
because
those
will
be
the
other
effort
on
going
on
the
other
side,
but
as
early
as
you
can
start
the
better,
I
think
and
rally
rally
around
any
help
that
you
might
need
from
ics
and
and
other
teams
as
well.
That
might
be
able
to
help
if
you
need,
but
I
would
invite
you
to
drive
that
forward.
Scott.
F
Yeah
I
can
drive
that
forward
and
we
we've
had
some
volunteers
from
like
jose
and
and
payton
to
help
us
out.
A
D
F
Oh
yeah
I'll
check
to
see
which
of
these
widgets
pull.
I'm
not
sure
I
I'm
not
sure
if
they
actually
do
pull,
because
I
think
what
they
basically
do
is
get
two
reports
and
compare
them
and
then
just
list
the
comparison.
F
A
All
right,
my
I
was
gonna
ask
scott
when
we
start
to
break
that
down.
Do
you
want
to
have
someone
on
your
team
join
us
or
you
yourself
to
break
down
the
the
work.
A
So
we're
going
to
start
working
we're
going
to
looking
at
the
two
efforts.
One
is
the
adding
the
support
to
the
component,
we're
going
to
break
down
the
parts
of
the
framework,
so
icons
spacing
all
that
stuff.
Do
you
feel
it's
valuable
to
have
someone
on
your
team
join
us
or
we
just
you'll,
be
focused
on
consuming
that
and
we'll
be
focusing
on
adding
support
to
the
widget.
F
I
think
there'd
be
value
in
having
someone
join,
whether
that's
me
I'll.
F
F
C
If
anyone
is
in
a
hurry
to
for
the
that
main
epic
feel
free
to
create
it,
because
my
computer
might
need
to
be
reinstalled,
the
mac.
F
A
We'll
figure
it
out
I'll,
probably
create
it
thanks
peter
all
right.
That's
it
we're
out
time
thanks
everyone
for
your
time
and
see
you
next
week.