►
From YouTube: Settings UX - Compliance
Description
Austin walks through how settings works at admin to project level
A
B
C
B
A
C
C
So
that's
been
one
of
the
first
challenges
we've
been
trying
to
address
so
like.
If
you
can't,
you
can't
create
a
merge
request,
approval
rule,
for
example,
at
the
instance
level,
we
want
to
be
able
to
at
least
bring
that
in
at
the
instance
and
then
there's
no
way
to
create
any
approval
rules
at
the
group
level.
C
C
That's
not
super
helpful
for
the
administrator
that
wants
to
make
swift
changes
across
or
be
able
to
quickly
change
each
one
they're
going
to
be
responsible
for
well.
I.
What
I
would
imagine
is
like
keeping
one
tab
up,
so
they
can
look
at
their
admin
settings
and
then
going
into
each
project.
Making
them
match
that
so
we're
trying
to
make
some
of
that
work
easier
so
that
compliance
isn't
so
painful
to
manage.
A
C
C
C
How
do
we
give
the
people
that
manage
instances
and
groups
more
dexterity
to
make
changes
or
observe
the
different
settings
across
different
projects,
and
I
think
I'd
ask
somewhere
in
the
ux
co-working
channel,
or
maybe
it
was
just
the
ux
channel,
but
I
didn't
know
exactly
what
our
pattern
was
in
terms
of
like
defining
settings.
So,
if
we're
going
to
introduce
another
setting
at
the
instance
level
is
a
default
behavior.
This
should
not
be
inherited
by
all
projects,
or
should
it
be
inherited
by
all
projects.
C
So
we're
trying
to
match
whatever
behavior
is
there
today
so
exam,
for
example,
we're
not
trying
to
change
the
push
rule
settings
in
terms
of
how
they
are
inherited
so
the
instance
level
we
set
them
up,
they're
not
inherited
by
projects,
we're
not
going
to
change
that.
Instead,
we're
going
to
drive
from
the
compliance
dashboard
away
to
understand
which
projects
aren't
matching
the
instance
level,
so
you
could
get.
C
A
C
The
stickiest
one
has
been
the
merge
request
approvals
between
the
instance
and
project
level,
so
we
have
like
several
videos
of
me
trying
to
break
down
the
logic
of
it.
So
it's
not
an
excel
sheet,
it's
probably
in
like
a
loom,
video
or
on
unfiltered
yeah,
and
I've
tried
to
also
break
it
down
in
figma
to
show
like
how
it
would
percolate
across
the
different
layers.
A
C
Yeah,
I
don't
know
exactly
which
milestone
it's
all
going
to
go
into.
I
have
to
probably
pull
up
our
planning
issue
to
figure
out
where
it's
coming
from,
but
some
of
those
things
were
just
kind
of
some
of
them
were
solidified
in
13,
5
and
solution
validation,
so
they
would
be
going
into
planning
breakdown.
C
B
B
C
Yeah
totally,
I
thought
of
a
much
more
granular
example
of
something
that
hasn't
necessarily
been
fully
defined.
Yet
in
terms
of
how
do
we
configure
this
to
the
different
layers
but
say
you're,
an
administrator,
and
you
want
to
change
like
the
default.
Merge
request
approval
rule
to
require
at
least
two
people.
C
C
How
do
we
allow
the
imagery
to
not
only
set
the
sensible
default,
but
also
potentially
lock
it
down,
so
that
it's
just
everybody's
going
to
use
the
same
rule
and
they
can
add
additional
rules,
but
they
don't
ever
want
to
allow
it
to
become
any
less
strict
than
two
would
be
the
example
I
can
think
of
like
I
know
some
we've
had
a
couple.
Customers
be
like
we
have
projects
that
can
use
zero
and
we
want
all
them
to
be
amusing,
at
least
two.
C
C
A
A
B
A
B
The
bigger
part
is
probably
like
setting
the
guidelines
or
structures
like
so
we're
thinking,
high
level
and
saying
cool.
These
are
the
common
problems
is
what
we're
going
to
solve
and
as
it
gets
more
granular,
so
let's
say
the
specific
settings
for
your
group.
We're
not
going
to
tell
you
what
to
do
there.
C
B
Might
just
say:
hey
austin,
here's
the
new
guidelines
and,
like
I
try
to
apply
this
to
your
group
for
consistency
like
sake
and
then
there
might
be
some
edge
cases
in
in
in
your
scenario
where
you're
dealing
with
different
instances
or
the
cascading
is
like
different
than
how
other
teams
are
doing
it.
So
that
cool
will
like
jump
in
and
like
help
out
with
that.
So
that's
kind
of
what
we're
doing
with
settings
and
then
with
that
it.
A
B
Close
relations
to
how
you
navigate
between
settings,
you
know
whether
it's
at
the
instance
level
down
to
the
project
level
and
all
that
stuff.
I
think
that's
another
scenario
where
we
might
leverage
more
insight
on
your
team
to
understand
how
that
works,
so
that
we
can
come
up
with
a
more
general
solution.
And
then
we
might
leave
it
to
you
to
like
assist
in
guiding
us
in
how
to
make
it
better
for
specific
scenarios.
A
C
Yeah
that
makes
sense
and
I'll
work
with
matt
my
product
manager
to
see
how
he
can
fit
in
some
of
these
things
like
some
of
them
seem
very
easy.
Like
fixing
the
border
color
yeah
the
table
yeah,
if
we're
touching
the
table
already
and
adding
things
to
it,
yeah
we
can
just
change
the
css
there,
but
we'll
see
about
some
other
ones
that
are
a
little
bit
more
complex
and
see
if
they
make
sense.
C
Because
a
lot
of
these,
like
we
don't
own
necessarily
the
responsibility
for
a
lot
of
these,
it
just
happens
to
be
that
we
might
be
touching
that
part
of
the
code
base,
and
so
it's
just
convenient
for
us.
If
we're
already
there,
we
might
as
well
add
a
little
extra
value
to
the
quality
of
life.
Yeah.
B
Yeah
that
feel
free
to
ping.
The
slack
group
over
myself
when
there's
parts
where
like
settings
is
an
interesting
one,
because
historically
no
one
group
really
owns
it
right.
So
it's
like
one
group
might
like
it's.
It
connects
to
all
the
groups,
but
no
one
group
really
owns
it.
So
bigger
bigger
changes
is
probably
in
in
our
remit
of
arena
where
it's
a
larger
overhaul.
That's
like
too
big
for
one
group
like
yours,
who
are
focused
on
a
certain
user
feature
delivering
user
value.
B
C
C
C
C
So
some
of
those
settings
are
kind
of
confusing,
like
this.
Checkbox
is
associated
to
this
checkbox,
but
they're
doing
the
exact
opposite.
So
if
this
one
is
unchecked,
this
one
will
be
checked.
We're
gonna
fix
it.
We're
gonna
clarify
the
ui
text
because
it's
non-obvious,
so
this
is
a
good
example.
I
have
settings
set
for
gdpr.
This
one
is
not
a
gdpr
project,
so
I'm
going
to
switch
it
over
to
one
and
then
it
should
inherit
the
settings.
C
C
B
A
C
No,
but
that
is
something
we're
going
to
be,
adding
in
we'll
be
adding
an
alert
to
provide
some
info
saying
that
the
settings
that
are
read-only
have
been
set
by
the
instance
level
or
the
group
level
to
give
some
clarity
to
whoever
is
within
the
settings.
So
they
know
why,
because
I
figure
it
out
yeah,
there
are
some
more
oddities
like
the
rules
are
currently
put
into
a
read-only
state
and
you
can't
add
any
new
ones
that
wasn't
necessarily
intentional.
We
still
want
to
allow
more
the
addition
of
new
rules
right
yeah.
C
We
don't
want
to
restrict
adding
rules,
but
also
we
want
to
be.
We
want
to
be
able
to
take
these
like
this,
like
approval
rule
section,
bring
it
up
so
that
the
administrator
can
configure
some
defaults
to
be
inherited.
So
this
is
just
a
great
example
of
like
clearly
there's
a
lot
of
difference
between
having
all
the
available
merch
request
approval
functionality.
C
A
C
Yeah,
I
I
know
it's
it's
confusing
and
hopefully,
by
the
time
you
get
around
to
it,
you
don't
have
to
worry
about
it.
We
do
have
a
lot
of
good
ideas
in
terms
of
like
improving
just
some
small
things
like
putting
these
check
boxes
in
the
same
order
having
all
the
same
checkboxes
present
using
the
same
text.
A
C
C
C
C
So
source
code
owns
it
but
we're
trying
to
like
improve
some
of
the
administration
of
it.
So
it's
kind
of
a
weird.
We
have
to
really
collaborate
with
a
lot
of
different
teams
that
own
these
different
parts
of
the
app
to
make
sure
that
we're
not
breaking
their
entire
experience
right
but
yeah.
So
far,
it's
been
good.