►
From YouTube: Compliance: UX Office Hours (2021-04-30)
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
Hey
everyone:
my
name
is
austin,
I'm
a
senior
product
designer
at
gitlab
working
in
the
compliance
group,
I'm
going
to
cover
a
few
topics
from
this
week,
so
I
spent
about
a
day
and
a
half,
maybe
two
days-ish
refining,
this
blog
post.
If
you're
interested
in
reading
it,
it's
based
off
of
a
presentation
that
was
done
in
the
ux
showcase
several
months
ago,
kind
of
walks
through
how
ux
evolved
over
the
past
several
years.
So
if
you're
interested
you
take
a
peek
at
the
review
app,
I
suspect
it
will
be
merged
pretty
soon.
A
I
also
started
running
some
on
monterey
testing
on
renaming
push
rules
to
source
control
in
the
admin
area.
Preliminary
results
so
far
I've
only
started
running
a
variable
test,
meaning
I'm
testing
the
change
that
I
want
to
do
to
rename
source
control
good.
So
far,
people
have
been
able
to
find
it
really
easily.
I'm
interested
to
see
if,
when
I
run
the
control,
if
they
can
still
find
it
just
as
easily
when
it
was
named,
push
rules
so
we'll
see
what
the
outcome
is
of
that
and
I'll
keep
you
updated.
A
I've
also
got
a
few
issues
that
I'm
eyeing
for
improving
sus
as
that's
going
to
be
a
continued
focus,
moving
forward,
I'm
sure
with
okrs,
so
trying
to
get
a
little
bit
ahead
of
that,
I'm
thinking
we
could
start
with
audit
events.
It's
this
one's
pretty
simple!
It's
just
adding
a
helper
text
to
the
input
field,
clarifying
that
you
can
only
select
30
days,
because
that's
still
the
constraint
that
we
have
there.
I
know
users,
don't
love
that,
but
until
you've
really
resolved
how
our
backend's
handling
it
there's
not
much.
A
We
can
do
about
that
on
the
front
end.
A
little
bit
bigger
of
a
overhaul
would
be
to
the
project
deletion
experience,
I'm
still
tying
up.
Some
loose
ends
on
how
exactly
we
want
like
these
containers
to
render,
but
for
the
most
part,
it's
going
to
address
these
dirt
design,
heuristics
to
better
accommodate
how
users
would
expect
to
interact
with
gitlab.
A
And,
lastly,
I
was
talking
through
an
idea
with
sam.
It's
an
idea
that
we
have
at
some
point
in
time
in
the
past,
to
make
the
compliance
frameworks
the
way
that
we
enforce
different
settings
throughout
gitlab.
So
you
might
notice
that
we
have
this
tension
of
in
compliance.
We
want
to
be
able
to
enforce
and
have
them
cascade
down,
so
that
it's
not
annoying
to
go
through
thousands
of
projects
and
update
them.
A
We
want
to
enforce
them
in
one
place,
so
this
is
a
potential
idea,
I'm
trying
to
pass
by
the
other
groups
kind
of
see
what
they're
thinking.
I
think
this
is
a
challenge
first,
particularly
for
back
end,
to
keep
track
of
everything
like
this.
I'm
specifically
calling
out
what,
if
we
had
a
compliance
framework-
and
you
could
say-
enforce
mr
approval
rules
and
settings,
but
don't
worry
about
protective
branches,
push
rules
and
merge
methods
and
delay
project
deletion.
A
A
When
you
apply
these
changes,
it's
similar
to
what
we
were
already
talking
about,
but
the
only
way
that
this
happens
is
if
you
have
a
compliance
framework,
so
at
least
like
telling
users
like
if
you
want
to
get
rid
of
this
enforcement,
get
rid
of
the
framework.
Take
it
off
your
project
and
the
way
that
you
do.
That
is
you
get
your
group
owner
to
come
in
and
configure
it
because
they
are
able
to
manage
the
section
for
you.