►
From YouTube: How we're dogfooding Insights at GitLab
Description
Kyle Wiebers, Quality Engineering Manager, Engineering Productivity at GitLab, gives an overview of how we use Insights at GitLab to monitor trends in workflow, bugs, merge requests and more.
A
B
B
B
Yes,
let
me
go
ahead
and
just
share
my
screen
here,
all
right,
so
insights
is
a
feature
of
yet
lab
that
enables
configuration
of
dashboards
like
the
one
you're
seeing
here
for
issues
in
merge
requests
using
labels,
and
that
can
help
you
identify
trends
in
your
issue
and
label
workflow
to
see
how
how
many
merge
requests
are
being
completed
or
merged,
for
example,
or
how
many
issues
are
being
created
and
closed
over
a
certain
period
of
time.
So
this
dashboard
here
this
is
our
merger
quest
throughput
dashboard.
B
This
shows
us
how
many
merger
quest
we're
completing
on
a
given
week.
So
this
is
a
weekly
view.
We've
configured
this
dashboard
at
the
gitlab
org
group
level.
So
this
looks
at
all
the
projects
under
the
group
and
then
shows
us
how
many
merger
quests
were
merged
each
week
and
it
and
we're
able
to
actually
do
a
stacked
bar
chart
here,
which
will
show
us
show
us
the
merge
request
by
type
so
I
get
lab.
We
have
types
to
emerge,
request
that
helps
us
categorize.
This
a
feature
is
this:
a
bug.
B
Is
this
a
community
contribution
from
like
an
open
source
contribution
from
a
community
member
and
that
helps
us
understand
what
type
of
work
is
being
completed
over
that
same
period
of
time?
This
chart
right
here
also
allows
us
to
look
at
it
weekly
or
monthly.
So
we
can
look
at
short
term
trends.
Longer-Term
trends
to
see
are
we
delivering
more
work?
Are
we
kind
of
hitting
a
bottleneck
or
we
plateauing,
and
that
allow
us
to
dive
a
little
bit
deeper
and
take
the
corrective
action.
B
B
This
is
the
get
lab
project
within
that,
so
our
main
mono
repo
that
we
use
to
build
our
product
here
we
can
look
and
see
the
same
dashboard,
leveraging
that
same
configuration
the
same
in
sites
dashboard
configuration
I
should
say
to
get
this
the
the
same
to
see
the
same
trends
on
a
specific
project
level.
This
didn't
require
any
configuration
at
the
project
level.
We
just
configured
this
dashboard
once
at
the
group
level
and
then
we
were
able
to
see
it
at
both
the
the
project
and
group
level.
B
B
Another.
So
I'll
add
another
thing
that
we
leveraged
insights
for
is
looking
at
issues
as
well,
so
insights
that
you're
able
to
see
trends
and
issues
and
merge
requests.
One
of
the
items
that
really
led
to
the
creation
of
this
was
looking
for
a
bug,
SLO
adherence,
so
trying
to
see
how
how
well
it
are
we
as
an
organization
doing
at
closing
our
bugs
within
our
service
level,
objectives
that
we've
defined
in
our
documentation
so
for
p1,
for
example,
that
would
be
within
30
days
here.
B
You
can
see
our
chart
again
at
the
group
level
of
what
bugs
are
past
SLO
by
month
by
created
month,
so
there's
a
all
open
bugs
and
then
all
open
customer
bugs
here
which
will
allow
us
to
again
did
that
kind
of
filtered
view
of
the
data
or
of
the
issues.
So
this
is
across
all
bugs,
and
these
are
across
the
ones
that
were
reported
by
a
customer.
B
B
So
we
really
were
having
success
looking
at
these
outside
of
the
product
and
with
that
success
we
wanted
to
bring
that
functionality
in
so
kind
of
getting
back
to
your
question.
Yeah
insights
really
helps
us
do
this
helps
us
get
a
sense
of
how
are
we
doing
according
to
a
specific
objective
measurement
objective,
seeing
that
vision
really
presenting
it
to
for
anyone
to
see
and
then
again
dive
deeper
and
take
that
corrective
action.
B
The
other
thing
where
we
get
lab
have
maybe
more
of
a
unique
challenge
when
it
comes
to
when
it
comes
to
insights,
is
we
have
large
number
of
teams
working
in
projects
that
are
inside
this
group,
so
being
able
to
filter
down
to
a
light
filter
further
to
look
at
throughputs
or
bugs
by
team
right
now
would
require
a
team
to
create
their
own
insights
dashboard.
However,
one
of
the
things
we're
working
towards
is
being
able
to
apply
a
filter
in
line
to
this
dashboard,
so
something
supplemental
to
the
dashboard
configuration
all
that
powers.
B
The
other
thing
that
get
lab
is
maybe
a
little
bit
more
unique.
You
can
see
here.
We
have
twenty
five
thousand
open
issues
on
this
one
project.
That's
a
lot
of
issues
to
sort
through.
We
have
a
lot
of
activity
on
our
project,
I
think
compared
to
a
lot
of
our
customers,
but
maybe
using
this
and
to
kind
of
help
make
insights
more
effective.
For
us,
we
use
a
lot
of
automation
to
ensure
label
hygiene
so
that
we're
applying
labels
or
identifying
where
we're
not
and
nudging
someone
to
apply
a
type
label.
B
A
bug
or
feature
or
backstage
or
make
sure
that
there's
the
severity
and
categorize
the
priority
on
bugs
so
that
we
can
determine
what's
the
SLO
there's
a
variety
of
automation
that
we
use
with
our
triage
ops
project
that
we
do
on
a
daily
and
weekly
basis
to
help
ensure
all
of
the
issues.
Our
merger
quest
flow
into
these
charts
in
a
very,
very
clear
manner,
and
we
don't
have
a
lot
of
things
falling
out.
B
A
B
Click
over
to
the
documentation
here
and
then
all
the
other
additional
configuration
is
done.
Leopard
labels
on
those
issues
or
merge
requests,
so
you
may
be
filtering
down
to
a
population.
So
in
this
example
here
this
is
looking
at
just
looking
at
open
issues
with
a
filter
label
of
a
bug
and
that's
where
those
issues
are
really
important
because
they
can,
they
will
either
exclude
items
if
they
don't
apply,
or
you
may
have
charts
that
lists
a
number
of
non
categorized
items
when
it
comes
to
priority.
B
So,
for
example,
like
this
section
here
there's,
this
is
just
this
is
a
regressions
dashboard
showing
how
many
bugs
are
caught
that
are
regressions
from
a
previous
release
to
where
we
broke
something
in
a
previous
release
and
there's
26i
issues
here
that
are
that
don't
have
an
Associated
milestone
that
they
were
tied
to.
So
so
that's
where
label
hygiene
is
very,
very
important
to
make
sure
that
you
don't
have
this
section
of
issues
or
merge
requests
that
are
falling
outside
of
your
dashboards.
B
B
So
some
of
the
other
ways
that
we
dog
food
insights
here
so
I
talked
about
throughputs
and
bug
SLO.
We
actually
leveraged
it
internally
in
a
number
of
different
ways,
so
our
support
team
is
actually
just
taken.
The
out-of-the-box
insights
configuration
to
look
at
how
many
support
tickets
are
created
and
closed
per
month,
so
they
can
get
a
sense
of
again.
How
is
they're
trending
performance?
These
are
actually
just
like
this
issue's
dashboard
is
the
standard
the
standard
configuration
if
you
were
to
just
create
an
insights
dashboard
with
what's
available
in
the
product.
B
Another
way
that
leverage
the
specific
on
the
quality
Department
is.
We
have
an
initiative
right
now
to
test
ye
like
the
Enterprise
Edition
features,
and
we
created
a
agate
lab
project
to
identify
what
is
all
the
scope.
So
we
created
a
test
cases
for
those
and
we
can
see
what
are
the?
How
many
issues
do
we
have
open?
B
How
many
issues
do
we
have
closed
by
product
area
so
by
group
here
and
then
by
tier,
so
looking
at
starter
premium
ultimate,
so
we
can
ensure
we're
focusing
on
closing
test
case
gaps
on
the
right
areas
and
again
identifying.
Where
do
we
need
to
provide
more
attention
to
compared
to
where
we
are
so
looking
at
this
chart,
we
may
say:
maybe
we
should
have
a
few
people
focus
on
the
gaps
and
verify
because
it
has
the
most.
At
the
current
point.
A
B
So
there
is
a
documentation
page
for
insights
that
does
list
out
what
are
the
different
kinds
of
charts.
What
are
the
configuration
options,
so
you
can
kind
of
see
how
can
data
be
presented
in
different
manners
and
then
how
do
you?
How
do
you
actually
power
that,
from
a
schema
perspective,
so
I'm
going
to
pull
up
test
cases
project
here
and
look
for
the
insights
configuration?
So
the
insights
configuration
is
actually
stored
in
Linus
code,
so
it
can
be
changed
as
just
like.
Just
like
you
do
any
of
your
code.
B
It
can
be
version
controlled,
so
you
can
see
changes
over
time.
That
gives
you
a
lot
of
value
to
just
ensure
that
there's
very
clear
traceability
into.
Why
was
this
dashboard
change
and
when
was
it
changed?
Sometimes
other
dashboarding
tools,
changes
just
happen
and
data
looks
different,
which
creates
a
lot
of
confusion
here,
there's
a
single
source
of
truth
for
why
those
changes
occurred
and
it's
all
version
controlled.
So
the
chart
that
we
were
just
looking
at
the
test
cases
chart.
You
can
see
the
configuration
here.
B
It
looks
at
it's
a
bar
chart
looking
at
issues
that
are
open.
Filtering
down
to
labels
that
have
this,
so
this
is
a
label,
that's
applied
to
our
issues.
To
identify
this
is
a
test
gap
and
then
these
collection
labels
are
what
broke
out
those
bars
into
different
columns
here
same
thing
for
closed
test
cases.
It's
very
similar.
Just
with
an
issue
state
of
closed.
A
lot
of
that
is
described
here.
You
can
get
very
intricate
and
complex
when
you
start
looking
at
stacked
bar
and
other
types
of
charts,
but
the
schema
to
actually
configure.
A
B
Yeah
as
long
as
as
long
as
you
have
an
understanding
of
how
you
how
you
would
search
for
the
issues
on
the
issue
tracker,
so
this
chart
I
think
the
initial
iteration
before
the
chart
was
looking
at
issues
in
the
issue.
Tracker
we're
gonna,
grab
this
filtered
label
here
and
saying
I
want
a
filter
for
sorry.
I
want
to
label
label
equal
to.
B
Right
here
and
we'll
look
for
here
and
here's
everything
that
would
be
returned
in
that,
so,
if
you're
used
to
finding
a
collection
of
issues
or
merge,
requests
based
on
filtering
very
similar
to
this,
you
can
likely
take
that
same
criteria
and
poured
it
over
into
this
format
as
well
as
get
some
additional
functionality
of
aggregating
by
other
labels.
It's
all.
It
does
kind
of
connect
back
to
your
your
own
workflow
and
label
hygiene
practices
relatively
straightforward
as
long
as
you're,
familiar
with
how
you're
finding
the
issues
or
merge
requests
that
you're
trying
to
identify.
B
A
Very
interesting
so
then,
who
are
some
of
the
sort
of
customer
personas
or
what
sort
of
teams
that
might
be
using
gitlab
could
really
benefit
from
this
tool
either
out
of
the
box,
or
also
in
terms
of
how
they
could
flexibly
sort
of
change
based
on
their
issue
or
labeling
system
and
workflows.
Two-Pronged.
B
Yes,
so
I
think
from
an
out-of-the-box
who
could
benefit
from
this
any
any
individual
on
the
team
who
to
be
interested
in
trends
of
how
am
I,
how
are
my
issues
I'm
doing
from
an
open,
close
perspective
over
time
to
see?
Am
I
this?
Is
my
backlog
of
work
growing
or
is
it
shrinking
or
is
it
staying
the
same?
A
lot
of
what
we
see
here
is
engineering
leaders,
so
managers,
maybe
product
managers
and
directors,
are
interested
in
that
type
of
information
of
how
are
my
power,
my
issues
doing
from
an
open,
closed
perspective?
A
A
B
B
From
the
customized
version,
I
think
leaders
is,
is
the
big
group,
so,
like
leaders
of
a
team
leaders
of
you
know,
maybe
a
whole
organization
would
be
the
individuals
who
want
to
see
the
insights
of.
However,
how
is
the
the
collection
of
issues
or
merge
requests
that
I
care
about
performing
based
on
my
own
defined
workflow
within
the
product?
The
team
would
likely
also
want
to
know
those
those
those
trends
and
see
those
results.
I
think
leaders
would
be
the
individuals
who
would
be
most
interested
in
seeing
how
those
trends
are
over
time.
A
B
B
Nothing
that
I,
don't
think.
We've
really
we've
really
touched
on
I
I.
Think
the
things
to
really
think
about.
If
you're,
if
you're,
considering
using
insights,
are,
do
you
find
yourself
pulling
data
out
of
gitlab,
either
through
the
API
or
through
a
CSV
export
and
then
building
charts
over
issues
in
merger
quest?
If
you're,
finding
yourself
doing
that
insights
may
be
a
really
good
candidate
for
you
to
look
at
creating
something
where
the
single
source
of
truth
is
right,
in
line
with
your
group
or
project
but
you're
trying
to
report
on
and
then
the
other.
B
The
other
thing
just
to
consider
as
you're
as
you're
looking
for
its
insights
is
be
sure
to
have
a
defined
workflow
and
in
an
automated
mechanism
to
ensure
and
label
hygiene
along
that
workflow.
That's
rituals
like
get
lab
triage,
which
is
an
open-source
tool
that
get
lab
get
labs,
does
a
lot
of
the
development
for
can
help
you
define
policies
to
ensure
that
the
label
hygiene
for
your
workflow
is
being
enforced
and
identify
areas
where
they're
falling
outside
so.
A
B
B
B
That'll
help
you
just
build
your
build
your
dashboards
around
the
process
that
you're
already
doing,
there's
no
requirement
to
do
automation,
but
if
you
find
yourself
having
a
large
backlog
of
issues,
that's
where
automation
sit,
so
a
large
backlog
of
issues
similar
to
get
lab.
That's
where
automation
can
assist
you
with
ensuring
the
conformity
of
your
work
of
your
issues
in
merge,
requester
your
work
so.
A
We've
definitely
been
dogfooding
issue
or
not
issue.
Sorry
insights
here,
I
get
lab
and
you've
definitely
learned
a
lot.
It
seems
like
through
actually
using
the
tool
when
you're
applying
it
to
get
labs
specific
use
cases.
But
what
what
do
you
think
is
next
and
for
for
the
insights
tool
and
technology
like
what
are
you
working
on
to
make
improvements?
A
B
So
I
would
say:
focus
on
improving
that
deeper
dive.
So
I
refer
to
that
a
few
times
earlier.
You
may
notice
a
trend,
that's
out
of
alignment
and
you
need
to
dive
deeper.
Now.
What
that
looks
like
is
going
to
the
issue:
tracker
filtering
down
to
the
same
population
and
exporting
that
data
out,
potentially
maybe
what
that
looks
like
for
customers.
B
So
we
want
to
provide
that
CSV
export
ability
in
here
the
ability
to
drill
deeper
into
like
what
are
the
issues
that
are
in
this
set,
but,
for
example,
or
create
additional
filters
to
narrow
down
to
a
smaller
population
of
issues
or
merge
requests
within
a
dashboard
kind
of
dynamically,
so
that
you
can.
You
can
do
that
deeper
dive
within
the
tool
itself
versus
having
to
go
outside.
B
No
I,
you
know
nothing
that
that
we
haven't
already
talked
about.
Insights
is
just
a
very
flexible
tool
that
allows
you
to
customize
dashboards
depending
on
your
own
requirements,
and
it's
something
that
we
found
a
lot
of
value
here
at
gitlab
in
looking
at
some
of
our
key
performance
indicators
related
to
bug,
SLO
and
throughputs
across
all
of
our
projects
and
I'm
sure
my
customers
may
find
similar
value
as
well.
Cool.
A
B
So
the
issues
for
insights
are
tracked
within
the
gitlab
project.
Issue
tracker
so
feel
free
create
an
issue
just
like
you
would
any
other
feature
of
the
product
and
and
there's
there's
labels
that
could
be
applied
for
insights.
That
will
help
indicate
that
it's
for
that
specific
product
area.
If
there's
no
labels
applied,
there's
a
there's,
a
wafer
up
the
quality
department
to
identify
those
those
issues
and
find
them
so
that
they
can
get
acted
upon
accordingly.
Okay,.