►
B
A
A
And
this
kind
of
triggered
a
discussion
on
why
we're
not
actually
using
our
own
built-in
product
to
to
use
the
same
thing
now.
This
is
like
an
open
conversation
that
we
want
to
learn
and
see
what
we
can
do
in
order
to
get
you
to
know
the
future
and
already
from
the
get-go,
I
can
tell
you
that
one
of
the
big
gaps
that
I
see
is
that
we're
looking
at
a
merge
request
view,
whereas
the
current
implementation
looks
at
issues.
A
C
If
you
scroll
up,
there
should
be
a
metrics
definition
here.
Therefore,
you
click
the
third
link
on
the
right
hand,
side
in
the
box,
mr
types
classification,
so
in
the
handbook
app
it
takes
you
to
that
definition
and
you
scroll
down
a
little
bit,
there's
a
list
of
projects
that
are
part
of
product.
If
you
scroll
down,
please.
C
A
C
Projects
here
we
go
yes,
so
this
pulls
data
from
two
gitlab
instances,
gitlab.com
and
also
opskit.net.
In
addition
to
that,
if
you
click
on
the
csv
files,
it's
not
all
the
projects,
it's
just
a
subset
of
them.
That
is
only
pertaining
to
our
product,
shipped
to
the
users
part
of
product
development.
So
these
are
not
like
a
metric
at
the
group
level
pass-through.
This
is
just
a
subset
of
them
and
we
we
have
approval
processes
on
when
to
include
them.
If
a
new
project
gets
created,
doesn't
mean
it
gets
created,
it
gets
included
by
default.
C
C
So
those
would
be
the
two
main
challenges
I
see
if
we
were
to
shift
the
teams
to
use
the
product
itself
and
the
other
being
that
size
sense
is
still
the
source
of
truth.
So
we
need
to
figure
out
a
way
how
to
build
a
chart
here
in
the
product,
but
also
be
have
it
made
available
in
size
sense.
Maybe
it's
a
pass-through
thing:
we
don't
do
any
processing
in
sizes
anymore.
It's
just
another.
C
A
C
Yeah,
I
I
agree
if
we
can
move
in
that
direction
and
start
to
get
usage
out
of
the
product
itself,
and
if
the
team
dashboards
are
in
the
product
and
the
top
level,
one
is
in
size
and
I
think
that's
that's
a
a
really
great
improvement,
so
we
don't
have
to
point
to
the
size
sentence
anymore.
Another
one,
sorry
with
those
fresh
off
my
mind
is
the
embeddability
of
the
the
charts.
C
A
A
A
C
B
A
Okay,
so
that's
one
challenge
that
we
see
here
in
terms
of
labels.
So
sorry
I
wasn't,
I
didn't
notice.
I
was
on
on
the
image
and
not
on
the
product,
but
in
terms
of
labels,
do
you
think
that
would
also
be
easier
for
you
if
you
could
select
here
predefined
list
of
labels
instead
of
you
know
only
going
through
the
ui
and
selecting
the
types
you
would
have
like
a
csv
file
very
similar
that
would
map
to
specific
labels,
and
those
would
be
the
ones
that
are
presented
on
the
graph.
C
A
C
A
A
Saying
that
we
could
have
like
different
dashboards
per
whoever's
looking
at
this,
so
if
we're
looking
at
the
quality
dashboards
that
are
equivalent
to
here,
it
would
be
scoped
to
the
types.
But
if
someone
else
was
looking
for,
I
don't
know
like
customer
issues,
they
would
have
their
own
dashboard
to
look
at
something
something
other
by
scoped
labels.
C
A
It's
a
it's
a
good
question:
they
so
the
way
that
we
have
it
in
value
stream.
For
example.
Here
you
can
select
what
your?
What
is
the
view
you're
looking
at
so
imagine
that
you
can
toggle
between
them.
It's
actually
very
similar
to
insights,
but
I
mean
you
said
that
you
worked
on
pretty
pretty
much
before
handing
it
over,
so
you
could
select
whatever
you're
looking
at.
So
you
can
look
at.
You
know,
feature
types,
customer
types,
tech
that
whatever
is
interesting
to
the
person
who
created
the.
A
C
A
Okay,
so
so
another
gap
is
the
fact
that
currently
it's
the
same
for
everyone,
you
can't
predefine
and
the
fact
that
and
the
fact
that
it's
really
annoying
that
you
have
to
select
this
every
time.
So
if
we
could
get
that
called
by
a
csv
file
or
whatever,
we
should
probably
have
a
default
that
we
suggest
and
then
let
everyone
else
choose
whatever
they
want.
A
C
A
C
B
C
A
C
A
C
A
C
C
When
engineering
managers
go
in
and
figure
out,
okay,
what
is
my
merge
request
rate
looking
like
they
are
able
to
filter
down
to
each
team
here
and
then
get
an
export
of
what
their
teams?
Mrs
look
like,
and
we
provide
this
because
we
tell
people
to
be
more
accurate.
They
want
to
see
okay.
My
mr
list
has
features.
Are
they
actually
features
or
they're,
something?
That's
actually
in
maintenance?
A
So
I
think
that
here
we
actually
have
a
benefit,
because
you
can
filter
result
results,
so
you
could
probably
filter
by
a
specific
team
if
a
specific
manager
is
interested
in
how
their
team
is
performing
or
by
maintenance
and
the
team.
So
actually
this
would
probably
be
easier
and
then
having
the
export
at
any
given
at
any
time
could
have.
You
could
theoretically
have
every
manager
getting
whatever
data
they
want,
which
could
be
pretty
cool.
C
Yes,
as
long
as
the
filter
is
pre-configured,
the
mechanisms
you
give
the
team
now
is
when
they
give
them
a
link,
it's
filtered
to
their
team
right.
The
handbook
dashboard
also
gets
filtered
that
see,
they
only
need
to
click
once
and
then
I
have
to
add
additional
filters
and
all
that,
and
even
the
export
is
also
already
there.
It's
not
a
csv
file.
It's
if
there's
a
widget
here
that
shows
the
list
of
of
merchant.
A
A
A
Forward,
it's
iterations
the
first,
the
first
real
iteration
that
I
see
is
duplicating
the
data
right.
That's
the
one
that
I
think
is
the
most
important
one
and
and
to
have
the
predefined
scope
labels
here
and
see
that
at
least
at
the
top
level
we're
seeing
the
same
data
and
that
you
know
there's
no,
no
loss
of
data.
That's
the
most
important
thing
for
me
for.
A
C
If
you
go
back
to
the
sci-sense
dashboard
view,
the
stakeholder
view
has
a
drill
down
of
everything.
So
there's
a
side-by-side
view
of
dev
ops,
sec
right,
you
scroll
all
the
way
down.
There.
Are
these
teams
so
you're
able
to
spot
outliers
and
teams
that
are
not
in
a
given
pattern
pretty
easily?
How
you?
How
are
we
gonna
do
that
in
the
product.
A
We
can
do
this
pretty
easily
with
labels
if
we,
if
we
do
end
up
doing
a
filter
with
that
sorry
filter
with
here
that
filters
by
label
and
type
it's
pretty
easy
to
get
them
side
by
side,
and
we
were
talking
about
doing
that
for
different
times
for
different
groups
and
what
was
the
third
one?
The
time
do
you
remember
the
comparative
view?
A
What
I
really
liked
about
not
doing
sisense
and
doing
this
in
our
project
is
that,
theoretically,
if
we
do
have
this
one
page
that
drills
into
the
same
table,
theoretically
we
have
one,
that's
not
filtered,
you
can
see
how
all
gitlab
is
doing
and
then
we
could
probably
put
a
custom
report
based
on
specific
teams
and
labels
and
really
it's
just
a
subset
of
the
same
data.
So
we
don't
actually
have
to
pull
the
data
again
and
again
and.
C
A
C
C
Well,
we
we
were,
we
were
working
on
it
for
a
while.
We
were
asked
to
move
this
to
give
this
away
into
the
product,
and
we
shifted
our
priority
to
something
else.
I
think
they're
still
asked
in
size
sense
that
we
are
not
able
to
to
get
get
to.
We
are
now
able
to
filter
on
labels.
I
don't
think
we
can
render
mrs.
Yet
what
was
the
other
one.
A
A
C
Okay,
it's
for
context
here,
the
reason
we
built
insights
because
they're
our
logic,
customized
logic
that
we
need
and
that's
why
it's
via
yaml
file,
we
didn't
had
people
front-end
people
configuration
at
a
time
to
make
it
an
editor
where
you
save
and
it
gets
it
gets
affected
immediately.
So
we
use
the
yaml
file.
I
don't
think
that
has
been
iterated
after
things
have
transitioned
away
from
the
team.
No.
C
C
Yeah
one
thing
we
can
do
there
is
for
historical
data,
go
to
size
lens
with
the
most
refreshed
data.
If
the
product
is
faster,
that's
something
we
could
leverage
a
team
to
use.
I
think
team
structure
is
important,
filtering
on
a
set
of
dimensionality
on
the
metrics,
the
type
only
and
other
others
go
into
undefined.
That's
important
and
filtering
on
the
groups
of
projects
that's
important
and
that
are
that
on
its
own
are
two
iterations.
A
A
C
Yeah,
I'm
not
saying
that
bsn
should
solve
it.
I
think
there
are
some
things
that
may
be
better
done
in
size
sense,
because
it's
aggregated
from
two
gitlab
instances,
I'm
not
sure
if
you
want
to
have
like
a
federated
gitlab
configuration
that
one
instance
pull
from
the
other.
That
seems
very,
very
many
iterations
away
in.