►
From YouTube: Compliance dashboard changes - Manage:Compliance
Description
Max (Senior Backend Engineer) and Austin (Product Designer) discuss the group-level compliance dashboard, its origins, where it's going and try to get Max up to speed to begin breaking down implementation issues.
A
A
Since
I
started
a
good
lab,
so
I
kind
of
want
to
have
just
a
pretty
brief
conversation
about
like
what
it
is
from
a
complete
beginner's
point
of
view,
and
then
what
we
see
the
differences
between
what
we
have
today
and
what
the
desired
outcome
from
this
issue
would
be
yeah
so
yeah
take
it
away.
Often
oh
great
questions.
B
In
dovetail,
too,
I
wrote
up
a
summary
kind
of
talking
through
those
findings
and
what
we
explicitly
learned
from
the
users
that
tested
the
compliance
dashboard
and
looking
into
different
ui
changes
and
why
we
would
want
to
make
those
so
that
all
basically
informed
how
we're
going
to
evolve
into
this,
but
taking
a
step
back
looking
at
the
compliance
dashboard
as
it
is
today,
there
are
a
couple
things
that
stood
out
as
not
useful
for
users.
Primarily,
you
only
see
the
most
recent
merge
requests
so
that
already
masks
a
lot
of
very
important
data.
B
B
A
B
It,
but
I
think
it
does
so.
This
is
a
project
gitlab
shell.
This
is
the
project,
get
lab
test
and
we're
only
seeing
the
most
recent
one
so
even
yeah
for
gitlab.org
ourselves,
there
yeah
there
would
be
potentially
thousands
listed
here
and
it's
only
looking
for
ones
that
merge
into,
I
believe
the
default
branch.
So,
in
our
case,
it's
master,
at
least
in
my
local
environment
might
be
main
some
other
places.
B
So
it
does
have
some
parameters
around
what's
displayed
here.
We
won't
care
if
someone
pushes
it
to
their
own
branch,
break
all
the
rules
you
want
to
show.
So
that's
the
first
thing.
Second
thing
is:
when
you
start
trying
to
better
understand,
what's
not
compliant
about
this,
it
requires
a
lot
of
effort.
So
this
one
tells
you
that
there's
at
least
one
one
rule
that
doesn't
adhere
to
separation
of
duties.
B
Okay,
what
rule
we
define
those
rules
in
our
docs,
which
is
great,
there's
three
rules
we
check
so
then
it
basically
requires
you
to
open
documentation.
Look
at
it
and
then
look
in
the
mr
and
look
for.
Did
it
pass
the
first
rule
yeah.
Did
it
pass
yeah?
Oh,
it
failed
the
third
rule,
okay
cool,
so
we
want
to
give
some
more
feedback
to
users
around
that.
So
they
better
understand
the
usefulness
of
these
merge
requests
violations
as
they
are,
so
those
are
like
primarily
the
main
detriments.
To
the
current
view.
B
A
number
of
people
also
communicated
that
this
isn't
a
dashboard
there's
no
metrics,
there's
no
like
aggregation
of
charts,
so
one
particular
participant
communicated
a
really
great
point.
They're
like
I
would
love
to
just
see
like
over
time.
My
number
of
merge
requests
that
had
not
done
separation
of
duties
properly.
So
am
I
having
more
approval
status
violations
over
time
or
are
they
going
down?
I
want
to
know
over
time.
Are
we
getting
better
at
compliance
or
are
we
still
being
the
worst
so.
A
B
B
That's
kind
of
where
the
name
compliance
report
is
coming
from,
probably
will
continue
to
emerge.
I
would
really
love
to
see
us
use
the
less
of
the
word,
compliance
as
a
prefix
to
things
and
be
more
descriptive.
So
a
great
example
of
this
is
the
security
team.
Calls
it
a
vulnerability
report.
It's
telling
you
about
vulnerabilities.
B
Yeah
yeah
it'd
be
a
great
great
coffee
chat
topic
for
sure.
So
that's
kind
of
just
like
a
base
overview
of
where
we
kind
of
stand
with
this
running
users
through
some
basic
tasks.
It
was
kind
of
clear
that
they
couldn't
really
accomplish
what
they
were
looking
for.
So
that
was
useful
to
know
and
so
through
several
iterations.
What
or
I
should
rather
say
several
ideations,
because
we
didn't
actually
iterate.
We
didn't
release
anything.
B
That
way
you
can
really
hone
in
on
what
the
problem
is.
So,
instead
of
only
seeing
through
that,
one
merge
request
that
fix
gilly
ruby,
not
starting
on
test
in
our
current
dashboard.
You
would
only
see
one
as
long
as
it's
the
most
recent
merge
request
now:
you're
seeing
okay,
it
didn't
it.
Had
an
author
approve
its
own
merge
request.
It
had
committers
approve
its
own
merge
request.
B
Those
are
what
we
consider
high
violations,
so
we're
introducing
also
this
concept
of
severities,
so
participants
communicated
they
didn't
understand
which
of
these
is
more
problematic.
What
should
I
go
after
first?
I
don't
know
so
we're
using
our
best
guess
honestly
around
the
priority
level
of
these
severities,
so
it's
kind
of
like
a
first
pass,
but
this
would
better
help
the
compliance
manager
start
actually
taking
action
on
these
things.
B
Several
participants
communicated
that
they
also
are
already
kind
of
creating
this
report
on
their
own,
so
they're
identifying
all
the
merchant
requests
that
didn't
do
the
right
things,
putting
them
like
an
excel
sheet
or
something
and
then
presenting
that
to
their
vps
to
kind
of
highlight
areas
of
improvement
and
then
how
they've
addressed
it.
This
would
kind
of
give
them
a
way
to
not
have
to
do
that
so
giving
them
direct
access
to
all
the
important
information.
B
A
B
Yeah,
this
would
be
something
that
we
would
be
opinionated
on
from
gitlab's
perspective
matt
and
I
kind
of
back
and
forth
on
a
couple
of
these,
but
this
is
kind
of
what
we're
thinking.
So
it's
not
completely
uninformed.
Some
of
this
was
expressed
by
participants
talking
about
percentage
of
code
coverage.
They
look
for
percentage,
drops
and
we're
thinking
that
things
like
separation
of
duties,
probably
is
higher
than
code
coverage
drops
for
the
most
part.
B
So-
and
this
is
totally
malleable
like
we
might
find
out
that
customers
really
think
pipelines
are
most
important
and
maybe
that
becomes
a
critical
severity.
We
have
ideas
for
other
ones
in
the
future.
I
don't
remember
it's
here.
Maybe
it's
might
be
at
the
epic
level
yeah.
So
we
had
some
ideas
for
additional
violations
that
could
come
in
the
future.
B
A
B
B
I
think
they
might
have
some
experience
with
customer
feedback
and
feeling
opinionated
on
whether
or
not
something
is
high
or
medium
sure,
but
yeah.
This
is
definitely
a
first
stab
at
it
and
I
would
not
be
surprised
to
find
out
that
there
are
people
with
strong
opinions
on
whether
or
not
having
less
than
two
approvals
is
a
flag.
B
A
All
okay:
that
was
my
next
question,
so
it
shows
up
in
a
report
and
it
would,
you
know,
be
flagged
up,
although
not
in
a
push
kind
of
way
to
a
compliance
manager.
It's
not
going
to
stop
anything.
It's
you
know
if
you're
breaking
these
rules,
you're
not
blocking,
merge,
requests
or
anything
like
that.
It
is
simply
a
reskinning
of
the
data,
essentially.
B
A
That
makes
sense.
Okay.
The
next
thing
I
need
to
do
then,
is
to
have
a
look
at
the
existing
system
and
figure
out,
I'm
still
not
clear
in
my
head
whether
those
violations
are
stored
in
our
database
or
whether
they
are
figured
out
on
the
fly.
That's
a
question
for
me:
I
can
figure
that
out,
but
it's
just
good
questions.
Certain
things
we
need
to
think
about.
I
suspect,
they're
generated
as
when
required,
based
on
what
I
can
see
here.
A
B
B
So
since
there's
going
to
be
such
a
volume,
especially
if
you
think
about
how
gitlab
runs
it
today,
being
able
to
go
from
like
all
projects
down
to
something
specific,
and
even
if
that
means
like
we
don't
allow
all
projects,
I
think
that's
also
totally
an
option
like
if
we
say
like
you,
have
to
specify
a
project
in
order
to
load
the
report.
I
hear
that
yeah
we
don't
want
to
just
have
it
sit
and
spin
for
minutes
not
ever
pulling
something
back.
A
A
Why
are
an
api,
in
which
case
we
may
be
able
to
lean
quite
heavily
on
the
front
end
rather
than
the
back
end,
and
this
is
all
speculation
at
this
point,
because
I
just
don't
know,
but
in
terms
of
filtering
you
know,
we've
got
some
constraints
on
audit
events
in
terms
of
you
can
only
filter
a
maximum
of
30
days,
but
that's
purely
down
to
the
fact
that
we're
talking
about
such
a
large
table
and
the
same
may
not
be
a
case
here.
We
may
have
to
enforce
pagination.
B
A
B
B
A
Yeah
cool
yeah,
okay!
Well,
in
which
case
I
don't
think
I've
got
any
more
questions.
This
was
really
really
helpful
because
I
now
have
about
a
thousand
percent
more
context
into
what
it
is
we're
trying
to
achieve.
So
my
next
job
will
be
to
get
back
into
the
epic
and
start
breaking
down
any
back-end
stuff.
That
needs
to
be
done,
trying
to
understand
better
what
we
can
already
do
and
how
far
away
from
that
we
are
today
and
then
we
can
begin.
B
To
break
it
down
yeah,
that
would
be
awesome
because
matt
was
absent
when
I
was
going
through
finishing
solution,
validation.
My
initial
stab
at
most
of
these
were
my
best
guess
at
implementation.
Issues
that
I
assumed
would
probably
need
to
be
broken
down
further,
like
I
just
said,
hey,
let's
make
a
drawer
for
the
compliance
report,
and
I
can
totally
imagine
that
this
drawer
is
going
to
then
be
broken
down
to
more
implementation
issues,
totally
fine.
B
A
That
it's
necessary
yeah,
I
think
the
biggest
back-end
thing
we're
going
to
need
to
think
about
is
how
we
represent
violations,
because
at
the
moment
we're
not
really
showing
a
violation
in
the
in
the
front
end
we're
showing
a
merge
request
and
a
bunch
of
information
about
that
merge,
request
we're
going
to
have
to
store
information
about
what
we
define
as
a
violation
and
that's
going
to
be
the
biggest
job.
But
once
we've
done
that,
then
it
becomes
a
case
of
making
sure
those
models
store
the
correct
information
and
then
we
display
it.