►
From YouTube: Compliance: UX Office Hours (2021-04-09)
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
everybody:
my
name
is
austin.
I'm
a
senior
product
designer
at
gitlab
this
week,
I'm
going
to
jump
into
the
agenda
and
start
off
with
a
update
to
our
pajamas
documentation
where
we're
finding
an
idea
to
better
clarify
how
we
go
about
actually
using
the
question
mark
the
help
icon
throughout
our
gitlab
interface.
A
I
also
wanted
to
thank
everybody
for
helping
me
get
this
merged,
specifically
thanks
to
dennis
who
taught
me
how
to
get
the
svg
library
to
update
locally
for
me
and
precompile
that
so
that
it
would
actually
render.
So
I
could
get
my
after
screenshot
super
glad
to
see
that
finally
made
it
in
and
also
great
work
to
jeremy
who
designed
the
logo.
A
I
also
want
to
do
a
brief
touch
on
what
ux
debt
is.
I
was
going
through
and
refining
some
of
the
issues
with
my
manager,
mike
an
issue
should
be
considered
ux
debt.
If
at
the
point,
when
we
decided
to
build
the
feature,
we
steered
away
from
doing
something
that
wasn't
as
great
for
the
user
experience
that
we
plan
to
come
back
to
later.
A
great
example
of
this
is
a
hipaa
logo.
When
initially
we
created
the
hipaa
project
template,
we
were
just
using
the
general
tanuki
logo.
A
We
knew
that
wasn't
a
great
identifier
for
the
project
template
itself,
so
we
created
ux
debt
to
go
back
and
fix
that
an
example,
something
that's
not
necessarily
ux.
That
would
be
like
discovering
that
the
border
of
a
table
isn't
the
right,
color
gray,
that's
more
technical
debt,
so
I'll
continue
to
keep
my
eye
on
what
is
truly
ux
step,
but
really
we
need
to
have
a
decision
to
say:
hey.
We
aren't
doing
this
thing
here,
but
we're
going
to
come
back
to
it,
so
we
can
refine
the
user
experience
later.
A
A
I
tend
to
add
a
rocket
ship
next
to
the
ones
that
are
done
and
the
locks
are
more
for
dedicating
that
it's
compliancing,
it's
not
actually
locked
down,
but
I
took
those
out
of
the
bigger
manage
area
because
there
were
just
a
lot
of
them
in
here,
and
so
that
should
help
break
things
down
easier
and
if
you're
looking
for
stuff,
I
really
do
try
and
stick
to
either
labeling
something
by
its
epic
or
its
issue,
depending
on
how
it's
linked
in
gitlab.
A
Ultimately,
I
don't
see
a
huge
impact
towards
the
feature
we
already
built
so
far,
at
least
for
this
release.
But
I
think
what
we
are
going
to
try
and
hone
in
on
next
week
is:
how
will
that
approver
gate
that
approvalgate
appear
in
the
merge
request?
A
So
currently
we
are
proposing
to
have
it
show
up
in
the
approver
section.
Instead,
I
think
what
is
a
fair
compromise
to
make
this
a
little
more
clear
on
the
merge
request.
Page
itself
is
putting
this
alongside
the
other
merge
request
widgets,
since
this
isn't
necessarily
preventing
the
merge
from
going
in
it's
more
used
as
an
informational
point
to
inform
the
approvers
of
whether
or
not
they
should
approve.
A
We
might
get
to
the
point
where
we
actually
can
make
this
more
restrictive
in
terms
of
actually
preventing
the
progression
of
a
merge
request,
but
for
now
I'm
trying
to
keep
this
as
minimal
of
a
change
as
possible.
Just
so,
we
can
start
exposing
this
data
because
otherwise
team
users
are
going
to
have
to
go
outside
of
gitlab
to
go
verify
these
things
anyways.
So
this
helps
us
bring
it
into
the
workflow
a
little
bit
more,
even
if
it's
not
the
perfect
home
for
it.
A
A
A
lot
of
the
ui
from
the
approver
section
could
be
useful
was
also
maybe
toying
with
the
idea
of
adding
it
to
the
form
of
when
you
create
a
protected
branch.
A
So
this
would
be
neat
to
be
able
to
tie
these
things
together,
so
maybe,
instead
of
having
under
merge
checks,
maybe
we
introduce
this
under
a
protective
branch,
so
I
think
the
only
thing
tricky
here
is:
we
want
to
make
sure
we
can
add
multiple
checks
for
a
specific
branch,
and
it's
not
just
going
to
be
one
check.
Normally,
I'm
sure
there'll
be
more
than
one
and
you
know
it's.
I
also
want
to
talk
to
annabelle
about
thinking
about
how
the
policies
builder
is
going
to
work.
A
She
has
like
a
vision
for
how
it's
going
to
play
out
for
a
number
of
different
other
types
of
policies,
but
what
if
we
also
could
create
a
policy
for
status
checks,
and
perhaps
that
status
check
policy,
it
could
be
a
similar
form.
I
added
in
some
more
ideas
here
from
kind
of
like
microsoft's
idea,
but
being
able
to
say
we
want
this
to
fail
a
merge
request.
We
want
this
to
change
whenever
there
are
new,
with
a
status
update
when
there's
a
new
change.
A
Just
should
give
some
more
control
over
the
policy
itself,
but
then
I
was
trying
to
think
okay.
So
do
we
define
the
policy
which
branches
associates
to
or
do
we
define
the
policy
like
the
group
level
and
then
give
the
ability
to
pick
a
policy
within
a
protected
branch,
not
really
sure
I'm
going
to
continue
talking
to
some
of
the
other
designers
and
see
what
they
think
so
that'll
be
like
mcnichols
and
pedro
and
annabelle
to
kind
of
figure
out?