►
From YouTube: Project Quality Dash MVC Kickoff prep
Description
Walk through the high level problem to solve/goals of the Project Quality Dash MVC epic and our initial thinking on how to implement.
Epic: https://gitlab.com/groups/gitlab-org/-/epics/5430
Design issue: https://gitlab.com/gitlab-org/gitlab/-/issues/322203
A
Hey
vindica
and
hayanna:
I'm
recording
this
just
to
kick
off
talk
through
the
project,
quality
dash,
mvc
and
probably
scott
two
who's
watching
this.
So
I
just
want
to
walk
through
the
epic
kind
of
kick
off
the
problem.
What
we're
looking
to
do
over
the
course
of
this
epic
through
a
couple
of
milestones
and
really
what
I'm
targeting
getting
done
as
part
of
the
design
that
vtec
is
helping
with
both
doing
the
design
and
the
solution,
validation
and
I'll.
A
I
can
definitely
help
run
that
as
well,
so
we
have
just
a
couple
items
in
here.
I
expect
that
this
is
going
to
grow
as
we
get
into
the
technical
bits,
but
what
we're
going
to
focus
on
today
is
really
the
ui
components
here.
So
our
overall
problem
statement
is
as
an
application
dev
director.
I
want
to
see
simple
to
understand
signals
about
a
project,
so
I
can
understand
how
quality
is
trending
over
the
last
30
days.
A
There's
a
couple
of
loaded
terms
in
there
signals
is
one
we
don't
know
exactly
what
those
things
are.
Quality
is
one
that
means
different
things
to
different
people.
So
what
we're
going
to
do
is
really
scope
this
down
into
data
we
already
get.
We
know
that
we
have
test
coverage.
We
already
have
a
great
presentation
for
that.
So
that's
kind
of
our
anchor
on
this
is
that
we're
going
to
give
them
test
coverage
to
start.
The
other
thing
that
we
can
easily
get
is
test
execution.
A
Stats
like
what
percentage
of
tests
are
passing
are
being
skipped,
are
failing
as
part
of
their
default
branch,
so
we're
just
dealing
with
the
default
branch
here,
we're
just
dealing
with
those
two
data
points
to
start,
and
then
the
design
can
expand
from
there.
This
is
really
we're
gonna,
really
embrace
that
minimum
viable
change
and
embrace
that
we
might
throw
this
design
away
even
after
we
build
it
and
start
with
something
else.
We
want
to
go
really
really
simple
here,
so
we
have
a
project
quality
dash,
ui
that'll
happen
actually
in
14.3.
A
If
I
refresh
here,
I
laid
out
the
the
milestones
here.
We
have
three
of
them:
the
first
one
we're
going
to
be
designing
and
validating,
doing
the
design
validating
with
the
endpoints
to
get
our
current
test
coverage
and
latest
test
execution
of
the
stats
that
I
talked
about
in
milestone,
two
v2k,
you
and
I
will
be
doing
so.
The
solution,
validation
and
the
team
will
be
implementing
any
additional
data
endpoints
that
we
need
and
then
implementing
the
ui
with
those
two
data
points
really
is
going
to
be
a
pretty
simple
presentation.
A
We
think
to
validate
that
we're
going
in
the
right
direction
and
I
want
to
jump
into
that's
not
it.
That's
the
design
issue
for
you.
This
is
it.
So
this
is
the
ui
one.
We
have
a
proposal
here
display
the
two
metrics
this
could
grow
later,
but
we're
not
focused
on
what
it
could
be
today.
We
really
want
to
just
focus
in
on
those
two
that
we
know
we
can
get
at,
because
we
don't
want
to
build
for
things
we're
not
going
to
build.
A
So
I
did
a
really
bad
version
of
this
down
here,
which
hayana
gracefully
did
not
laugh
in
my
face
about,
but
this
is
kind
of
what
we're
thinking.
It's
just
a
very
simple
tile
view
that
shows
here's
your
test
coverage
and
here's
some
sort
of
way
to
indicate
the
direction
it's
going.
What
we
hear
as
we
talk
to
these
customers
is,
they
need
a
red
light,
green
light
kind
of
a
situation,
so
they
need
no
green
great.
I
don't
need
to
care
about
it
today
or
red
hey.
I
need
someone
to
look
at
this.
A
A
We
can
build
this
to
learn
and
see
how
many
people
are
clicking
into
that
and
then
what
do
we
need
to
build?
On
top
of
that,
I
show
code
quality
violations
here
as
well.
This
was
an
idea
before
we
handed
off
that
category.
A
We
may
come
back
and
build
that
so
that
we
have
that
data,
and
then
the
sas
team
static
analysis
team
can
build
out
from
there
or
build
something
else
and
drop
it
in
here
or
take
this
out
and
put
it
back
into
the
security,
the
vulnerability
dashboard,
maybe
where
it
belongs
or
where
people
might
be
looking
for
it
so
where
people
might
be
looking
for.
It
gets
me
to
one
of
the
first
goals
that
I
have
as
part
of
our
design
and
our
solution.
A
A
They
cannot
find
the
project
test
coverage
either
of
those
history,
graphs,
they're,
buried
in
analytics
in
analytics
repositories,
90
of
users,
that
I've
interviewed
and
gone
through
the
job
you'd
be
down
and
go
find
historical
test
coverage
go
into
analytics,
ci
cd,
so
that
might
be
a
great
place
for
us
to
put
it
or
we
can
test
out
with
a
whole
new
place
to
put
that
as
well,
and
then
I
already
touched
on
the
second
goal.
We
really
want
to
give
them
data.
That's
I'm
going
to
call
it
red
light,
green
light.
A
They
know
just
by
looking
at
it,
that
it's
either
trending
in
the
right
direction,
or
it's
starting
to
trend
in
the
wrong
direction
and
from
there
we
can
build
out
in
later
iterations
on.
What's
the
actionable
thing,
is
it
creating
an
issue
or
whatever,
and
we
don't
need
to
design
for
that
today.
We
just
want
to
design
for
this
mvc.
So
the
presentation
here
should
be
really
simple.
Other
reports
are
going
to
have
more
details
and
we
can
flesh
those
out
at
a
later
date
as
part
of
other
design
efforts.
A
So
I
really
just
want
to
get
this,
not
this
design
cleaned
up.
This
was
just
where
my
head
was
at
that
day.
It's
something
that's
going
to
show
those
two
data
points,
something
that's
easy
to
find
and
something
that's
directional
for
them.
So
I
will
set
up
some
time
if
you
guys
talk
through
this,
ask
any
questions
or
answer
any
questions
that
you
might
have,
so
we
can
get.
This
kicked
off
as
we
get
closer
to
14,
1
and
I'll
share
this
video
with
everybody.
In
slack
thanks.