►
Description
DevOps Reports - https://about.gitlab.com/direction/manage/#devops-reports
Report Pages Epic - https://gitlab.com/groups/gitlab-org/-/epics/3214
Group Activity MR Chart w/ Single Series - https://gitlab.com/gitlab-org/gitlab/-/issues/217545
Group Activity Issues Chart w/ Single Series - https://gitlab.com/gitlab-org/gitlab/-/issues/217547
A
Hello
and
welcome
I'm
John
Shackleford
product
manager
for
analytics
here
at
gate
lab
in
this
release,
13
to
kick
off
video
I'll
be
sharing
the
first
of
a
series
of
updates
to
our
vision
for
the
DevOps
reports.
Category
I
haven't
been
at
get
lab
long,
but
one
comment
I
have
heard
over
and
over
again
from
users
and
members
of
the
gate.
Lab
team
go
something
like
this.
You've
got
so
much
great
information
in
this
one
application.
There
are
great
charts
and
there's
dashboards
of
different
kinds.
A
Many
different
analytics
features,
but
boy
I
sure
would
love
to
be
able
to
collect
those
in
one
place
and
see
them
in
one
dashboard.
Instead
of
having
to
navigate
all
over
the
product
to
get
a
view
of
how
things
are
going
well,
I
want.
If
you
share
a
few
things
about
that
feedback.
The
first
is:
we've
heard
you
loud
and
clear.
This
is
a
problem
we
experienced
as
get
lab
users
ourselves.
I've
heard
this
from
people
of
many
different
roles.
I've
heard
it
from
our
sales
team
from
engineering
teams
yeah
even
from
our
executives.
A
Second,
this
is
a
hard
problem
to
solve
it
harder
than
it
may
appear
for
for
two
key
reasons.
One
is
we
really
want
to
iterate
quickly
to
meet
customer
needs
I'm
part
of
our
secret
sauce
for
doing
that
is
not
waiting
on
dependencies,
but
allowing
our
autonomous
product
teams
to
be
laser-focused
on
the
customer
needs
they're
trying
to
serve.
So
we
don't
want
any
approach
to
a
consistent
experience
or
sharing
data
that
would
slow
teams
down.
A
Another
key
idea
is
that
each
product
team
is
focused
on
a
particular
set
of
personas
and,
and
each
persona
has
a
specific
need,
and
we
want
the
best
experience
for
each
of
those
personas.
So
we
don't
want
an
approach
that
would
in
any
way
compromise
those
tailored
experiences,
but
instead
we
need
to
find
a
way
to
make
those
experiences
richer,
while
at
the
same
time
enabling
users
to
pull
metrics
from
different
parts
of
the
product
into
a
single
dashboard.
A
A
The
first
page
I
want
to
show
is
our
managed
stage,
Direction
page,
and
we
have
an
analytics
category
on
that
page,
where
we
talk
about
DevOps
reports
and
really
break
down
what
we're
trying
to
do
and
why,
on
this
page,
so
I
I
just
want
to
make
you
aware
of
this
I'll
link
it
with
the
video,
and
you
can
read
all
about
that
vision
more
there.
Next
I
want
to
take
you
to
the
idea
of
what
we
call
our
report
page.
So
what
is
a
report
page?
Well,
let
me
pictures
worth
a
thousand
words.
A
So,
let's
start
there,
so
a
report
page
is
just
a
page
focused
on
a
given
metric.
It
might
be
talking
about
how
many
members
are
added
to
a
group
or
how
many,
what
has
happens
to
my
test
code
coverage
over
time
or
what
is
happening
with
builds
or
what
is
happening
with
value
stream
measures
such
as
the
time
cycle
time
and
so
on
over
time.
So
we
would
have
a
chart
there
that
describes
that
and
then
a
data
table
below
that
allows
you
to
drill
into
details.
A
A
People
in
my
organization,
using
get
my
power
things
changing
month
over
month
week
over
a
week
when
it
comes
to
issues
open
or
merge,
requests
or
new
members
joining
a
group
or
pipeline
builds
or
executions
or
new
releases
and
so
on,
and
so
we've
begun
the
process
of
adding
these
metrics
to
the
top
of
the
gate,
lab
or
I.
Guess.
A
Excuse
me
at
the
top
of
any
group
and
what
we're
doing
in
13
is
making
those
numbers
which
already
appear
a
hyperlink
so
that
I
can
drill
down
and
to
actually
explore
and
get
more
detail
and
and
when
I
do
I
come
to
a
chart
that
expresses
what's
been
happening
with
that
number
over
time
and
again
that's
this
experience.
We
get
richer
and
richer
over
time.
That's
what
we
mean
by
an
embedded
experience,
we're
drilling
down
from
one
place
in
the
product
to
another
to
really
be
able
to
explore
with
the
data.
A
What
we're
doing
is
creating
this
library
of
report
pages
and
allowing
users
to
define
their
own
report
pages
with
their
own
queries
with
their
own
data
and
so
on,
and
eventually
be
able
to
pull
those
together
into
a
dashboard
that
allows
you
to
look
at
all
of
those
things
going
on
at
once
in
terms
of
what
we're
doing
on
the
data
side,
our
very
first
MVC
with
this
we're
leveraging
the
query
engine
that
we
already
have
in
the
insights
feature.
In
order
to
create
that
query.
A
Drill
and
experience
for
merge
requests,
but
what
we've
done
there
is
built
the
infrastructure
that
allows
us
to
define
the
drillin
for
the
issues
opened
without
writing
any
additional
code,
just
by
defining
a
Hamel
file
that
defines
the
query.
That
itself
also
defines
the
page
that
constitutes
this.