►
From YouTube: Testing Group Think Big #5
Description
Today we think big about Custom MR Widgets, who they solve a problem for and how we could differentiate a solution to content on the MR page within GitLab.
A
So
I'm
going
to
kick
it
off
with.
Hopefully,
everyone
had
a
chance
to
click
through
to
the
think
big
issue
and
then
from
there
into
the
other
issues,
open
it
up
to
the
floor
and
I'll
start
taking
notes
on.
What's
the
problem
that
we're
trying
to
solve
kind
of?
What's
the
undercurrent
of
all
of
these
things.
B
A
Can
you
or
can
we
unpack
a
little
bit?
The
customer
information
is
that
data
about
their
app
like
profiling,
data
things
that
might
show
up
in
the
the
custom
reports
today
or
is
it
other
integrations
like
we
have
data
from
sauce
labs
that
we
want
to
integrate,
or
we
run
our
own
load
tests
with
artillery,
and
we
want
that
data
back
into
the
mr
widget
or
back
into
gitlab
somewhere.
B
That
I
couldn't
tell
you
I
mean
so
most
of
it
seems
like
a
lot
of
the
prescriptive
kind
of
issues
are
like.
Oh,
I
want
to
see,
I
think
a
lighthouse
was
the
one
I
can
remember,
but
also
if
maybe
our
information
was
good
enough,
they'd
be
like
oh,
we
don't
need
lighthouse
anymore.
Gitlab.
Does
all
this
amazing
stuff
for
free,
like
you
know,
let's
just
use
that
instead,
how
to
balance
those,
I
couldn't
say.
B
A
A
C
I'm
mentioning
that
is
because,
like
if
they're
doing,
if
they're
asking
for
that
is
because
they
probably
already
use
lighthouse
inside
the
devtools
chrome
devtools,
so
they
already
probably
have
like
a
workflow
that
it's
manual
I
mean
they
go
there.
They
like
go
to
lighthouse
and
then
they,
I
don't
know,
generate
the
reports
there
so
like
they
probably
want
the
exact
same
thing
but
within
the
ci
right.
So
I
didn't.
C
A
So
the
problem
for
that
customer
is
they
use
gitlab
for
their
ci
they're
using
merge
requests.
They
have
data,
that's
being
generated
as
part
of
their
pipeline
or
even
outside
of
their
pipeline.
Once
it's
deployed
to
a
review
app
that
they
want
within
the
context
or
they
need
within
the
context
of
the
mr
to
know
if
they
can
improve
it
and
merge
it.
A
C
A
Yeah,
I
think
we
can
dig
in
with
the
user
who
submitted
that
one
and
try
to
get
at
their
specifics
about
lighthouse,
because
we
have
the
accessibility,
testing
now
web
performance
we
can
make
enhancements
to.
I
think
if
we
pull
up
from
that,
though,
and
say
hey,
there's
other
types
of
data
that
a
customer
is
going
to
want,
or
a
user
rather
is
going
to
want
to
expose
into
their.
Mr
page,
that's
just
that's
just
one
example
of
it.
Why
are
those
users
wanting
that
data
in
the
page?
B
A
D
So
maybe
we
should
be
thinking
about
the
other
side
to
this
as
well
of
like
you
know,
are
we
showing
too
much
and
not
allowing
people
to
hide
them
things,
because
that
that
block
at
the
top
of
a
merger
quest
is
getting
bigger
and
bigger
and
bigger
yeah?
I
just
think
of
something
that
maybe
you
were
thinking
about.
A
So,
let's
talk
a
little
bit
about
who
has
that
problem
of
all
right?
Actually,
so
I
want
to
distill
that
a
little
bit
it
sounds
like
the
problem
that
we
have
is
that,
even
when
there
is
data
that
we
provide,
or
if
there's
data
that
we're
not
providing
in
the
gitlab
ui,
it's
not
the
format,
that's
usable
by
all
users,
and
so
they
want
to
be
able
to
smush
data
around
to
give
them
better
context
of
what's
happened
in
their
pipeline
on
the
merge
request
page.
F
A
Manager,
parker
the
product
manager
delaney,
the
development
lead
presley
the
product
designer
sasha,
the
software
developer,
devon,
the
devops
engineer,
systems,
admin,
security,
analyst,
release
manager,
security
operations,
engineer
and
I
think
that's
everybody.
Oh
no!
Wait,
simone
this
software
engineer
and
test
allison
application
maps
and
then
there's
a
couple:
internal
personas
as
well.
B
A
A
A
B
A
Yeah,
so
the
user
of
the
the
end
result,
user
is
sasha
and
then
kind
of
a
customer.
Maybe
for
the
feature
would
be
that
security
analyst,
okay,
all
right!
So,
let's,
let's
keep
going
down
that
thread
a
little
bit
with
what
an
ideal
outcome
then
would
look
like
and
let's
really
try
to
pull
out
of
the
weeds
and
think
big
about
this.
I
really
like
ricky's
whizzy
wig
with
emojis.
A
B
Yeah
so
like
coming
down
to
it
now
I
see
a
lot
of
the
mr
widgets
are
being
ignored
when
things
come
up,
and
I
think
part
of
that
is
because
it's
information
overload
and
there's
just
a
lot
of
information
in
those
mr
widgets
right
now,
especially
in
the
gitlab
projects,
because
we're
trying
to
dog-proof
them
all
at
the
same
time.
The
other
part
of
it
is,
I
think,
there's
an
outstanding
issue
with
the
diff
of
the
reports
being
compared,
isn't
always
entirely
accurate.
B
B
Well,
I
think,
assuming
that
we
there's
no
bugs
like
assuming
that
all
the
widgets
are
relevant
and
they
have
the
correct
information
in
them.
I
think
it's.
It
should
be
up
to
me
as
delaney
or
sam
or
whoever
to
define
what
stops
an
mr
and
what
doesn't
and
then
to
kind
of
highlight
that
and
everything
else
is
kind
of
tertiary.
A
Like
what
I
understood
from
ricky's
comment
was,
were
we
potentially
show
or
a
good
outcome
would
be
that
you
have
a
minimal
set
of
information
or
even
a
really
collapsed
view
of
things
that
aren't
blocking
your
merge,
request,
widget
and
or
your
merge
request?
Widget
your
merge
request,
if
there's
anything
that
as
a
group
or
maybe
as
an
org
you've
decided
that
these
things
block
the
merge
request
from
going
through.
A
B
And
so
I
think,
and
that,
like
you
know,
if
it's
for
the
whole
organization,
then
tying
it
to
their.
The
group's
like
mergiability
rules
makes
a
lot
of
sense,
but
if
it's
set
for
an
individual,
then
maybe
not
right.
Like
so
my
question:
do
we
have
data
on
like
what
persona
uses
the
mr
page,
the
most
amount
of
time?
C
That's
probably
what
it
is
doing
right
like
some
software
engineers,
are
the
ones
who
like
like
consistently
and
are
using
mars
right,
like
other
people,
are
gonna
check
it,
but
no
one
is
using
it
that,
like
all
the
meaningful
data
that
it's
there,
you
know
like
people
are
babies
hitting
their
pipelines.
People
are
like
looking
if
their
merch
request
is
approved.
A
Yeah,
that's
the
world
we
live
in
today,
though,
so,
let's
think
a
big
about
git
lab
is
just
controlling
information
through
a
pipeline
that
pipeline
can
build
code.
The
pipeline
can
do
other
things
too,
and
so,
if
you're,
if
you're
expanding
into
your
designer
or
your
security,
analyst
or
marketing
or
legal,
like
anything
that
you
want
to
control
some
data
through
a
flow
and
control,
if
it
merges
into
whatever
kind
of
your
final
repository
is,
can
make
use
of
this
and
so
long
term.
I
think
you
would
want
that
combination
of
as
an
org.
A
These
things
are
always
important
to
everyone
that
we
we
have
to
stop
a
merge
of
data
into
other
data.
If
this
is
met-
and
we
understand
that
other
people
may
care
about
other
things.
So
as
we're
thinking
big,
I
think
it's
kind
of
exciting
to
say:
hey,
you
can
customize
what
the
mr
page
looks
like
for
yourself,
so
you
can
always
see
the
things
that
you
care
about.
B
But
then
my
caveat
to
that
would
be,
would
they
all
be
working
on
the
same
project
right
like
with
someone
from
legal
and
someone
from
design
and
security
all
be
working
on
the
same
project
like?
Maybe
this
is
a
project
level
setting
where
hey
this
project.
The
mr
widget
looks
like
that
and
the
way
we
differentiate
between
legal
or
design
or
security
is
they
have
different
projects
that
they
operate
on
with
different
setting.
F
Is
the
ability
to
toggle
it
on
and
off?
It
seems
like
there's
like
the
you
know
what
content
is
being
surfaced
for
whom
right?
That's
that's
one
thing
that
we're
talking
about
and
then
is
there
an
ability
to
toggle
on
and
off
this
to
see
it,
and
then
you
know
what
level
of
granularity
do
you
does
that
information
get
services?
Just
for
me
as
a
delaney
or
you
know
or
me
as
sasha
the
software
developer
or
who
gets
more
value?
Does
my
boss
get
more
value
from
seeing
what
the
teen's
code
coverage
is?
F
B
Yeah-
and
I
think
that's
a
good
point
too-
I
think
in
the
mrs,
I
think,
the
mr
it
being
a
merger
quest
and
not
like
at
the
project
level
or
at
the
group
level.
It's
the
thing
that
differentiates
it
between
seeing
something
for
the
fertiline
something
for
sasha.
In
my
perspective,
because
as
I
would
much
rather
see
the
the
bigger
picture
of
what
my
team's
doing
so,
I
could
make
informed
decisions
about
processes
and
stuff
like
that.
It's
that's
not
that
I
don't
get
value
from
looking
at
merge
requests.
It's
just
that.
D
I
think
it
could
be
like
a
bit
of
both
like
you
can
have
on
a
project
or
organization
level
say
this
is
an
important
widget.
This
will
block
merges.
This
is
a
less
important
one
and
you
know
kind
of
what
ricky
was
saying
before
and
then
on
a
user
level
say:
okay,
what
I
want
to
see
are
the
important
ones
and
they're
not
import,
or
you
know
you
know
like
you
can,
with
with
slack
where
you
can
say.
D
I
want
a
notification
if
I'm
direct,
messaged
or
all
the
way
down
to
any
message,
that's
put
in
any
channel
ever
which
hopefully
no
one
turns
on,
because
that
would
be
terrifying,
but
you
know
you
you,
as
a
user,
you
can
say
I
want
to
subscribe
to
this
level
of
widget
and
then
as
an
organization.
You
say
what
widgets
are
at
what
level.
A
A
Cool,
so
let's
talk
a
little
bit
about
how
we
can
differentiate
this
from,
I
think,
specifically,
the
github
github
checks
api.
I
think
that's
as
I
was
reading
through
all
these
issues.
I
was
like.
Oh,
this
is
the
checks
api
right,
that's
the
first
one
that
came
to
mind,
but
I
don't
know
all
the
other
ci
systems.
What
else
is
out
there?
How
could
we
make
this
way
better
than
anybody
else's?
You
know
kind
of
merge,
request
or
pr
page.
B
I'll
just
verbalize
what
I
said
that
yeah,
like
you,
said
it's
the
checks,
api
and
then
github
also
solves
this
with
like
bots.
That
will
post
comments
into
the
pr,
so
it'll
like
something
like
pajamas
or
coveralls,
will
post
a
comment
with
the
code
coverage
in
there
and
then
it'll
update
the
comment
as
your
pr
changes.
B
So
I
think
that
building
it
directly
into
a
tight
integration
with
an
mr
widget
making
a
customizable
mr
widget
and
then
maybe
as
like
the
really
thinking
bid
big,
allowing
the
user
to
define
what
shows
up
or
not
in
the
mr
widget
and
even
like
compound.
Mr
widgets
is
what
differentiates
us,
because
it's
like
really
really
tightly
integrated
and
you
load
the
mr
page,
and
it's
like.
The
first
thing
you
see
is
like
hey.
This
is
the
state
of
the
mr.
B
What
the
engineers
really
care
about
front
and
center.
I
think
that
really
differentiates
us
from
the
kind
of
patchy
github
checks,
api
solution,
where
it
involves
a
lot
of
integrations
and
there's
comments
and
there's
the
checks
api
and
it's
kind
of
not
immediately
obvious
that
these
are
the
problems
with
the
pr
that
you
have
to
solve
right
now
or
mr
that
you
have
to
solve
right
now.
A
C
I
mean
one
one,
one
from
my
ux
perspective.
One
thing
that
I
always
kind
of
like
I'm
always
thinking
when
I'm
designing
things
is
every
time
that
we
create
something:
it's
not
really
the
final
best
version
of
what
we
could
deliver
in
terms
of
the
information
that
they
need
right.
So
I
think
that
the
the
the
best
class
experience
is
literally
the
the
software
tells
you
your
pipeline
failed,
because
you
I
mean
literally,
it
tells
you
in
very
verbally.
Your
pipeline
fell
because
this
test
is
failing
and
he's
failing
at
this
line.
C
B
Costs
you
know
so
since
we're
thinking
big,
what
if
it
not
only
told
you
what
was
wrong,
but
it
also
told
you
how
to
fix
it.
It's
like
this
test
is
failing,
and
you
need
to
change
this
file
because
the
test
doesn't
pass
and
then
even
bigger.
What,
if
it
just
fixed
it
itself,
is
just
a
a
lot
like
the
the
way.
B
D
We
actually
tried
pulling
this
into
some
of
the
vulnerability
stuff
with
secure
where,
if
there
was
a
known
way
of
fixing
it,
it
would
create
an
mr
that
fixed
it
for
you
and
then
you
could
obviously
approve
or
deny
that
mr,
but
bringing
that
across
to
other
widgets
would
be
would
be
really
cool.
I
don't
know
if
that
still
fits
in
this
thing.
Big,
maybe
we're
going
too
big,
but.
A
A
How
like?
Where
would
you
source
your
suggestions
and
have
a
way
for
somebody
to
build
that
in
like
if
they're
bringing
in
sonar
cube
or
something
like
that,
like
hey?
Where
is
the?
Where
are
the
references
where
you
could
fix
common
problems
and
maybe
even
provide
a
library
for
things
like
in
in
those
different
categories?
You
can
say:
hey
here's
all
the
security
things
that
we
know
how
to
fix.
B
Hey
I've
used
a
product
or
a
yeah.
I've
essentially
used
a
product
before
that.
Does
that
with
upgrading
versions
of
laravel,
which
is
basically
like
rails.
So
it's
this
docker
image
that
you
can
download
and
you
pay
them
a
licensing
fee
for
it
and
it
will
analyze
your
code
base
and
then
submit
a
pull
request
or
a
on
github
or
a
merge
request
on
gitlab
to
upgrade
your
project
to
the
next
version
of
laravel.
So
it
would
be
the
same
with
rails.
B
So
it
would
automatically
upgrade
you
from
one
version
to
the
next
and
like
fixing
all
the
breaking
changes
that
it
found
in
your
code
along
the
way,
and
it
has
that
for
each
like
major
version,
bumper
kind
of
like
automatically
upgrades
you
one
thing
to
another,
so
that's
kind
of
it's
like
stuff
does
this
already
and
like
sam
was
saying
they
were
looking
at
that
for
security.
Things
too.
So
that's
kind
of
an
interesting
parallel
stream.
A
Cool
we
are
under
a
minute
left
on
this
think
big.
I
think
we've
had
some
big
thoughts
and
move
this
forward
a
little
bit.
We
will
continue
with
the
think
small
portion
of
it
next
week.
Hopefully
we
can
come
up
with
an
issue
that
is
an
mvc
type
thing
to
move
forward
on
this
problem,
even
if
it
is
an
nvc
that
we
end
up
deciding
to
throw
away
and
we're
moving
back
from
the
product,
a
topic
that
drew-
and
I
were
talking
about
before
we
started
the
recording.
A
Ricky
and
joanna
and
everyone
else
who
was
taking
notes.
Thank
you
as
always
so
much,
I
started
with
great
intentions
and
then
completely
abandoned
that,
as
I
usually
do
so
as
always.
Thank
you
for
helping
keep
us
on
track
and
recording
the
conversation
all
right
thanks.
Everyone
have
a
great
day
cheers.