►
From YouTube: 2021-08-26 Working Group: Merge Request Report Widgets
Description
Kickoff meeting for the WG!
Agenda
https://docs.google.com/document/d/1bcch8UUkwmgEHFolTWDrQFJtUiiXlv_yQFAGwSSDSUE/edit
A
A
It's
very
exciting
to
finally
gather
this
group
of
people
to
attend
to
this
topic
that
we've
had
a
love-hate
relationship
over
the
past
years,
but
everybody's
very
invested
and
and
and
caring
about
doing
a
great
job
here.
So
I
it's
very
exciting
for
us,
encoder
of
you
to
to
have
all
of
you
help
in
in
improving
this
area.
So
the
first
thing
that
I
had
was
I
I
haven't
seen
everyone
on
the
channel,
so
I
wanted
to
raise
that.
A
B
B
A
I
can
take
that
action
because
I
have
to
rename
the
one
I
created
so
that
you
can
use
that
name
so
I'll.
Take
that
action
point
to
rename
the
mr.
Oh
sorry,
I
have
to
rename
that
and
I'll
reach
out
to
the
owner
of
that,
so
I'll
take
care
of
that
action.
So
thank
you.
First
wow
first
action
point
look
at
that
awesome
right!
I'm
moving
on
to
the
discussion
items
please
feel
free
to
add
your
points.
A
Questions
concerns
to
the
points
below
as
a
as
we're
speaking,
so
that
we
can
have
a
worthwhile
discussion
yeah
in
the
first
order
of
business.
I
just
wanted
to
check
everybody's
thoughts
on
how
about
this
meeting.
How
often
should
we
meet?
Should
we
meet
weekly
to
start
off?
Should
we
meet
every
two
weeks?
It
doesn't
doesn't
stop
us
from
having
more
informal
gatherings
throughout
the
week,
but
as
a
regular
catch
up
for
the
whole
group
to
to
meet
what
what
are
people's
thoughts
on
on
frequency.
A
A
Thank
you.
Thank
you
all
right.
So
that's
that
and
as
for
the
length
of
the
meeting
30
minutes,
okay,
should
we
move
to?
Should
we
extend
to
60
minutes
right,
30
minutes
it
is,
I
see
a
lot
of
nodding,
cool,
oh
sorry,
yeah
there's,
one
particular
topic
that
I
would
raise
here
is
that
one
of
the
team
members
daniel
he's
in
an
apac
time
zone
that
he
can't
attend
this
meeting,
and
I
was
wondering
I
know
that
a
lot
of
us
are
in
this
time
zone.
A
D
A
A
A
So
if
nobody
objects
we'll
try
to
find
a
time
slot
I'll
reach
out
to
daniel
and
have
him
try
to
propose
a
time
that
works
for
him
and
the
majority
of
the
team
members
and
I'll
ask
daniel
directly
to
to
take
care
of
that
cool
all
right.
Moving
on
right,
so
the
first,
the
first,
the
most
immediate
action
that
we
should
take
is
materialize.
A
D
D
A
A
A
A
Yeah,
that
sounds.
That
sounds
good.
Definitely
I'm
guessing.
You
made
a
suggestion
about
adding
that.
So
so
my
my
let
me
actually
voice
my
my
thought
on
that
implementation.
Inclusion
is
that
the
state
of
the
code
right
now
it
requires
a
good
deal
of
work
to
first
support
the
ux
framework
and
second,
all
of
the
specificity
of
all
the
group.
Widgets
will
be
specific
to
their
own
groups
and
the
level
of
effort
to
do
that
might
vary.
A
Some
of
them
might
be
simple,
some
of
them
might
be
more
complicated,
and
one
of
the
reasons
why
we
wanted
to
have
a
working
group
about
this
topic
is
that
we
don't.
We
don't
forecast
to
be
feasible
to
rewrite
every
widget,
with
a
high
level
of
quality,
supporting
the
ux
framework
within
three
months.
B
Yeah
absolutely-
and
this
is
this-
is
wonderful
about
our
chaos
right
very
ambitious
right.
I
think
the
biggest
the
biggest
question
we
right
now
have
ahead
of
us
is
really.
How
will
this
go?
Will
we
spend
a
lot
of
upfront
time
on
the
like
on
the
component
right,
creating
that
strong
component?
Will
we
spend
more
time
already
trying
to
implement
these?
To
already
have
some
things
checked
off
for
the
okr,
but
I
would
honestly
say,
especially
with
the
engineering
allocation
and
so
many
things
moving
around.
A
Yep
that
makes
perfect
sense.
I
think
those
the
answers
to
those
questions
we
have
a
technical
discussion
area
on
the
agenda
and
we're
going
to
be
starting
to
drill
down
is
explicitly
about
those
technical
decisions
that
we
have
to
make
that
I'll
postpone
that
discussion
to
the
point
later
but
yeah.
I
think
that's
that
we
can
help
that
to
answer
those
questions.
A
D
Maybe
you
can
cover
my
my
question
with
the
technical
discussions.
I
think
I'm
thinking
if
there
are
any
low
hanging
fruits
for
ux
right
if
we're
focusing
on
the
core,
the
foundation
of
the
component.
What
could
we
be
doing,
for
example,
in
the
meantime,
in
regards
to
the
ui,
to
the
publisher,
for
example,
copy
or
things
that
don't
necessarily
involve
the
redesign
of
of
the
reusable
components
or
yeah
building
that
thing.
A
What's
the
ux
in
some
ways,
so
I
think
you're
you're
going
to
play
a
huge
part
in
assisting
those
decisions
and
assisting
by
reviewing
the
work
that
we're
doing
and
coming
back
a
bit
to
marcel.
I
expect
there
to
be
like
a
an
overlap
of
two
threads.
One
is
updating
the
core
component
and
the
other
is
every
group
leveraging
that
component
to
rewrite
their
widgets.
A
A
So
we'll
go
through
the
so
going
back
to
hyannis
top
point
we'll
go
through
her
feedback
on
the
mr
and
after
those
discussions
are
resolved
from
her,
and
that
would
be
okay
to
merge.
Anyone
else
have
any
other
concerns
or
needs
that
we
need
to
check
before
we
merge.
You
can
always
again
iterate,
of
course,
but
cool
all
right.
That
looks
good,
looking
forward
to
merging
that
one.
F
Yep,
so
this
is
done.
I
did
some
work
on
an
extension
type
thing
a
few
months
ago
now
it's
essentially
the
same
sort
of
base
converter
that
we
can
update.
It
allows
us
to
create
a
very
basic
looking
widget
that
we
can
just
extend
so
for
the
code
wires.
We
just
have
to
register
a
widget,
a
retro
extension,
sorry,
which
just
is
accepts
basically
an
object
of
the
set
structure
that
we
can
change
slightly.
F
A
Yeah,
that's
good.
I
think
one
of
the
things
to
highlight
here
is
this
is
this
is
where
we're
starting
from
and
as
you
can
see,
it
has
a
already
a
separation
between
fetching
data
for
the
collapsed
state
and
for
the
expanded
state,
which
is
beneficial
for
performance,
but
this
is
very
naked,
so
to
speak,
so
the
first
initial
effort
will
be
addressing
it
with
all
the
ux
framework.
Amazing
work
that
the
ux
team
has
done
making
this
and
the
styling
of
this
support
those
rules.
A
So
to
speak,
that's
going
to
be
the
first
effort,
but
then
you
also
need
to
know
specificity
or
specific
things
that
certain
widgets
might
do
that
are
not
supported
by
this
widget
we're
going
to
have
to
not
not
supported
by
this
core
component.
We
know
we
need
to
extend
it,
that's
kind
of
like
the
gist
of
what
we
wanted
to
show
so
questions
thoughts.
How
does
this
make
you
feel.
A
D
I
have
still
formulating
the
question
in
my
head,
so
let
me
try
it
out
when
you
say
that
this
specific
scenario
is
right
test
you
need
to
be
covered
by
the
the
widget.
Do
we
know
the
number
of
scenarios?
Do
you
know
the
complexity
of
the
use
cases
that
are
going
to
be
needed
to
be
they're
going
to
need
to
in
the
in
the
reusable
component?
At
this
point,.
C
I
don't
the
answer.
Sorry,
I
think
just
just
looking
at
it.
It
looked
like
a
good
majority
of
testing
team
owns
like
quite
a
few,
mr
widgets,
a
good
majority
of
our
widgets
would
probably
just
be
able
to
use
that
because
it's
just
straight
up
like
hey.
This
is
the
title
and
here's
a
list
of
stuff,
but
then
we
have
you
know
the
test
report.
I
think
also
with
there's
a
security
report
that
has
nested
collapsible
sections,
they're
ones
that
have
like
different
icons.
C
D
Yeah,
I
I
understand
thanks
thanks
scott.
Indeed,
when
I
think
of
the
testing
we
just
there
are
a
couple
of
of
instances
that
don't
really
show
a
lot
yeah
and
I
think
that
would
be
a
good
place
also
for
us
to
start,
and
I'm
asking
this
because
last
time
I
checked
in
with
james
james
heinrich
the
product
manager
for
testing.
We
wanted
to
look
into
what
are
the
most,
not
just
the
most
used
widgets.
What
are
the?
D
What
are
the
widgets
or
the
merge
request
areas
right
and
for
testing
that
after
we
redesign,
we
have
the
highest
impact
for
customers,
so
not
only
look
at
yeah
the
technical
feasibility,
but
just
delivering
value
based
on
what
we
discover
from
the
the
usability
investigation
for
the
emerging
class
areas.
But
thanks
that
clarifies
my
question.
C
A
B
So
when
we
did
the
framework,
we
asked
every
team
before
make
sure
you
cover
all
all
cases
that
you
currently
have.
We
even
have,
for
example,
status
checks
that
didn't
exist
when
we
started
the
effort
and
we
tried
to
make
sure
every
single
state
is
covered
by
the
framework.
I
have
also
linked
the
figma
file
in
the
agenda
again.
I
can
quickly
also
show
it
here.
B
This
is
probably
the
most
comprehensive
resource
for
seeing
all
of
them
and
seeing
the
different
states
and
seeing
how
they
differ.
I
I
could
expect
that
there
might
be
one
or
two
states
we
just
haven't
seen
we
just
haven't
haven't
yet
had
on
the
agenda.
I
hope
that,
with
a
bit
of
luck,
maybe
we
will
even
have
everything
100
covered
in
the
framework.
A
G
E
G
My
question
is
most:
if
not
all,
of
the
current
widgets
use
the
same
underlying
architecture
or
structural
component,
the
report
section
and
a
few
others
as
well,
and
they
for
allow
for
quite
a
bit
of
variation
via
slots
and
things
like
that,
and
that's
that
affordance
of
variation
is
kind
of.
Why
we're
here
and
that's
what
we're
trying
to
limit.
But
there's
a
balance
of
you
know
what
features
we
actually
want
to
support,
but
we
also
want
to
enforce
consistency.
G
So,
if
just
to
follow
up,
if,
if
if
a
new
merge
quest,
widget
comes
up
or
a
change
is
needed
to
an
existing
one,
that
requires
something
that's
not
supported
in
the
framework.
Would
we
have
to
have
a
quick
discussion
of?
Do
we
want
to
have
it
this
way?
Do
we
want
to
build
support
for
that,
or
do
we
actually
want
to
push
back
and
say?
No,
we
need
it
needs
to
fit
in
this.
Is
that
what
we'd
be
hoping
for.
B
So
I
think,
especially
for
new
ones
that
get
created.
They
follow
the
ux
framework.
If
there's
a
very
complex
one
that
already
exists,
that
wants
to
offer
something
new
that
wants
to
pilot
something
that
doesn't
yet
exist.
We
can
absolutely
negotiate
about
like
how
that's
gonna
go
down.
Will
the
team
have
to
contribute
to
the
framework?
Will
they
maybe
stray
off
from
it?
A
A
What
do
I
do
talk
to
this
person?
Make
sure
that
there's
your
ex
proposals
validated
make
I'm
spitballing
here
but
add
the
add
the
feature
to
the
core
component
and
then
use
it.
So
there
will
be
an
iterative
approach
for
that.
That's
what
I'm
expecting.
How
do
you
feel
about
that
mark
by
the
way?
I
know
that
it's,
it
might
feel
restrictive
at
one
point,
but
how
do
you
feel
that
coming
from
where
we
are
right
now
that
we
have
slots-
and
we
have
some
freedom.
G
G
My
my
only
concern
really
is
that
you
know
it's
fine
to
have
a
process
written
down,
but
I
can
still
see
something
like
maybe
getting
merged
without
having
gone
through
that
process,
and
then
we
end
up
back
here
kind
of
thing.
So
I
guess
we
really
need
to
make
that
foolproof
or
that's
not
the
right
word,
but
it's
really
robust.
So
you
can't
accidentally
skip
it.
Okay
kind
of
thing.
H
H
Doing
are
one
of
the
things
that
will
be
documented,
and
so
the
way
we
think
about
this-
and
we
being
the
code
review
group-
is
that
if
you
are
contributing
things
to
the
merge
request
and
there's
a
framework
defined
you're
welcome
to
stay
within
the
bounds
of
the
framework.
But
if
you
leave
the
bounds
of
the
framework,
we
expect
you
to
come
and
talk
to
us,
and
so
that's
that's
documented.
A
Yeah,
I
just
had
one
more
thing:
yeah
and
my
comment
is
that
maybe
the
the
report
which
is
process
could
be
a
subset
of
this.
We
can
work
it
out.
I
was
going
to
propose
that
we
nominate
two
dris
for
this
particular
topic,
so
that
we
can
create
an
issue
for
devising
a
process
for
anything
that
might
be
outside,
and
this
is
for
the
long
term,
it's
not
urgent
to
make
sure
that
it
doesn't
get
forgotten.
And
does
anybody
want
to
take
this
as
a
something
under
their
wing.
H
It
should
be
the
natural
artifact
if
you
look
at
like
the
handbook
page
it
links
already
to
the
epic,
which
is
the
epic
for
all
of
the
work
that
this
group
is
doing.
So
it
should
be
producing
the
output
of
this,
which
should
be
like
the
figma
file
and
the
guidelines
that
go
into
pajamas
are
the
expectation
of
sort
of
what
that
would
be,
which
a
lot
of
that
exists.
I
think.
A
E
I
would
be
willing
to
look
into
that
a
little
further,
because
one
of
the
things
I
struggle
with
is
conceptually
is
the
framework
going
to
be
as
rigid
or
is
it
going
to
rely
slightly
on
people
to
be
respectful
of
the
framework?
If
that
makes
sense.
So
we
have
these
these
ideas
in
principle
and
we
you
know,
we
want
people
to
abide
by
them,
but
then,
at
the
same
time
is
the
code
gonna
be
as
restrictive
as
as
the
framework
is
so
that's
something
I
would
love
to
look
into.
A
Okay,
so
I
would
suggest
just
creating
an
issue
or
something
to
track
that
effort
and
then
we'll
just
gravitate
towards
it.
It
might
be
that
we
don't
have
to
do
anything
else
just
to
point
to
that
process,
or
it
would
be
great
to
have
some
other
pair
of
eyes,
scrutinizing
that
and
see
if
it
applies,
sounds
good,
cool,
tim
thanks.
A
A
Right
so
we'll
postpone
that
discussion
for
next
week,
we'll
start
off
with
that
one
instead,
just
the
gist
of
it.
Is
that
we're
looking
for
volunteers
to
start
breaking
down
the
work,
but
we
have
some
important
questions
that
we
want
to
nail.
So
what
I
would
recommend
is,
if
you
have
questions
about
technical
technical
aspects,
please
go
into
this
issue
and
leave
the
questions
so
that
we
can
discuss
asynchronously
and
work
from
there
cool
rihanna.
D
A
I'll
do
I'll
move
my
questions
that
I
added
here
to
threads
into
that
issue,
and
then
this
is
going
to
be
probably
a
duplicate
from
the
other
implementation
issue
we
had,
but
I
feel
like
these
are
very
laser
focused
on
implementation
decisions
of
the
code
in
the
context
of
the
working
group.
So
let's
do
it
there
and
start.
Please
add
your
questions
there
as
threads,
so
that
we
can
keep
it
contextualized
right
we're
over
time.
Thank
you.