►
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Hi
there,
my
name
is
austin,
I'm
a
senior
product
designer
here
at
gitlab
today.
I
wanted
to
do
a
little
overview
of
the
work
that
daniel
and
I
collaborated
on
as
a
ux
scorecard
evaluation
as
it
would
relate
to
creating
audit
deliverables
so
daniel
first
and
foremost.
Thank
you
so
much
for
all
of
your
effort
going
through
the
different
tasks.
Posting
your
videos,
your
summaries
and
highlighting
the
workflow
and
the
pain
points
in
your
mural
diagram.
All
that
was
super
helpful.
A
A
The
first
thing
I
noticed
was
you
jumped
in
as
an
administrator,
which
was
fine.
The
struggle
that
we
actually
run
into
is
most
users,
don't
get
the
permission
to
be
administrator
or
let
alone
an
owner,
and
so
they
can't
necessarily
perform
all
the
same
actions
that
you
got
to.
It
was
okay
that
you
did.
I
understood
the
instructors
were
kind
of
using,
but
overall
you
did
a
great
job.
We
do
know
that
we
need
to
improve
what
roles
have
access
to
specific
pieces
of
data
in
gitlab.
A
So
we
have
a
pretty
old
issue
open
to
expand
the
auditor
role.
This
might
tie
into
the
role
based
access
control
effort,
that's
kind
of
being
collaborated
on
with
some
other
designers
right
now,
as
we
try
and
rethink
how
to
make
that
more
flexible
and
more
useful
for
users,
because
at
the
end
of
the
day
not
everybody
can
be
administrator
and
get
lab,
not
even
everybody
be
an
owner
and
that's
a
real
pain
point
for
users.
A
Additionally,
as
you
were
going
through
your
evaluation,
you
highlighted
a
number
of
good
pain
points
like
the
object
being
not
a
great
descriptor.
Sometimes
it
describes
a
project.
Sometimes
it's
describing
a
user
or
a
group
or
something
else,
and
that's
not
necessarily
clear.
So
I
think
it'd
be
great
to
revise
some
of
these
headers
to
better
describe
what
the
data
is
underneath
it.
A
A
You'd
see
that
you
know
this
is
listed
as
a
project
or
that
this
was
actually
listed
as
a
compliance
framework
in
a
project
setting,
I
think,
bringing
some
of
the
data
into
the
table
itself
could
make
this
a
lot
more
readable
and
leave
less
guesswork
that
or
even
just
redefining
what
makes
a
target
just
using
the
name
of
the
target
isn't
necessarily
the
most
useful
information.
As
you
can
see
from
my
dummy
data,
it
doesn't
necessarily
make
sense
all
that
well
anyways.
A
Additionally,
you
identify
that,
like
hey
this
export
csv
button
is
really
helpful
in
the
admin
area.
I
agree.
We
already
have
issues
open
to
put
that
in
the
group
area
and
the
project
area.
It's
not
a
security
thing,
it's
literally
just
an
effort
thing.
It
just
takes
time
to
add
each
of
these
pieces
of
functionality
we
just
haven't
gotten
around
to
prioritizing.
Yet
with
that
said,
there
were
a
couple
things
I
also
wanted
to
cover
in
terms
of
how
these
events
pages
are
structured.
A
A
So
if
you
were
a
sas
customer
using
gitlab.com,
that's
very
annoying,
but
the
reason
we
can't
show
all
these
events
together,
even
at
the
group
level
is
it
doesn't
perform.
Well,
we
our
queries,
just
don't
meet
our
standards,
and
so
it's
currently
just
a
gap
in
the
user
experience.
So
I
understand
that
sucks
and
we're
trying
to
find
ways
around
it.
Honestly,
I
think
if
the
workspace
group
is
able
to
help
kind
of
bring
down
some
of
those
features
out
of
the
admin
area
expose
them
more
to
our
sas
customers
and
users.
A
Furthermore,
you
definitely
identify
a
pain
point
that
happens
with
the
calendar
picker.
So
like
I
can't
pick
september
1st,
that's
just
because
we
only
allow
you
to
pick
31
calendar
days
and
a
early
30
calendar
days
comes
to
about
a
month.
So
it's
annoying.
We
know
users
want
to
be
able
to
pick.
You
know
from
the
first
of
the
month
through
august
31st,
but
unfortunately
we
just
can't
right
now
it
doesn't
perform
well
in
our
database.
A
A
We
can't
really
do
and
or
filtering
right
now,
it's
just
not
possible
with
our
search
component,
so
we
kind
of
are
blocked
just
by
that
needing
to
become
a
priority
for
get
lab
to
build.
So
right
now,
users
are
kind
of
stuck
with
what
they
can
do
here
and
they
can
look
up
specific
users.
They
can
look
up
specific
projects,
but
they
can't
do
anything
more
than
that.
A
It's
just
it's
just
not
viable
right
now,
so
I'm
not
going
to
open
an
issue
for
that
currently,
just
knowing
that
it's
gonna
have
to
happen
at
some
point
and
for
the
second
task,
all
right.
So
really
what
this
comes
down
to
is
a
lack
of
knowledge
of
what
separation
of
duties
typically
means
in
the
compliance
world.
So
I
loved
your
interpretation
and
effort
that
you
put
towards
trying
to
figure
that
out
by
reading
through
the
audited
events
to
figure
out
were
there
any
separation
of
duty
problems.
A
We
actually
have
an
area
in
the
product
that
helps
identify
this
a
little
bit
better
and
some
information
in
docs
that
can
help
as
well.
So,
if
you're
in
a
group-
and
you
go
to
the
compliance
report,
page
you'll
see
that
there
are
a
list
of
emerge
requests
and
this
approval
status
column
is
designed
to
help
you
understand
if
a
merge
request
did
not
hear
a
separation
of
duties.
So
if
you're,
if
you're
wondering
what
that
is,
I'm
gonna
just
do.
A
So
we
try
and
help
users
understand
if
their
merge
requests
didn't
comply
with
a
separation
of
duties,
policy
that
may
or
may
not
be
enforced
at
their
company
by
highlighting
whether
or
not
something
had
a
merge
request
author
that
approved
their
own
merge
request
or
maybe
a
committer
approved.
The
merge
request
that
they
added
commits
to
these
are
just
kind
of
considered
no-no's
in
the
compliance
world.
A
So
we
know
whether
or
not
this
is
happening
I'll
go
ahead
and
say
that
we
know
that
this
dashboard
itself
is
been
identified
as
rather
useless.
We
did
solution
validation
around
it.
Last
december,
like
december,
2020
came
out
with
some
good
insights
and
we're
just
now
kind
of
getting
around
to
actually
working
on
that.
So,
like
one
thing,
we
added
was
a
drawer
that
starts
bringing
in
some
of
that
very
pertinent.
A
The
reason
why
this
is
important
is
as
a
regular
aspect,
a
part
of
many
audits.
Are
you
have
to
go
and
figure
out
if
there
were
any
of
these
rules
that
happen
to
be
violated?
Yes,
we
have
merge,
request,
approval
settings
that
help
prevent
these
actions
from
happening,
but
who's
to
say
that
a
project
maintainer
doesn't
change
the
setting
and
then
the
action
occurs
to
get
around
it.
And
then
you
have
a
change
that
reaches
to
production.
A
This
creates
a
single
place
for
users
to
go,
find
when
things
happen
in
the
past
and
be
able
to
identify
them.
So
you
didn't
get
around
to
this
part,
that's
totally
cool.
The
only
thing
I
I'll
just
help
reinforce
with
this
is
that
we
have
a
whole
epic
to
try
and
make
this
better
already
and
hopefully
in
the
future.
That
will
make
it
easier
for
users
to
even
identify
it
in
the
first
place
when
they
are
trying
to
go
in
and
figure
out
if
there
are
any
failure
to
maintain
separation
of
duties,
all
right
cool.