►
From YouTube: Compliance: Iterating on a settings inheritance model
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).
B
A
Okay,
so
last
week
you
posted
a
message
in
slack,
saying:
hey,
gabe
was
really
interested
in
our
proposal
for
how
we
were
gonna
do
merge,
request
approval
rule,
so
the
group
level,
considering
also
how
we
might
simply
instance,
level
and
some
put
together
a
diagram
to
help
show
the
logic
behind
it.
I
really
struggle
to
put
it
in
a
logical
like
diagram
and
like
a
relationship
diagram,
I
just
felt
like
well
it's
it's
kind
of
simple
you
just
inherit,
what's
above
you,
but
it
depends
on
who
your
parent
is.
A
A
The
reason
why
I
was
asking
for
your
clarity
was
I
I
think
there
is
a
difference
between
how
we're
doing
like
protected
branches
and
push
rules
versus
merge,
request
approvals,
the
unique
attribute
being
the
merge
request,
approval
rules.
You
can
use
a
compliance
framework
label,
the
other
things
you
can't,
because
that's
just
not
how
it
is
today,
so
I
don't
feel
adequately
informed
to
say
one
is
better
than
the
other.
I
just
understand
why
using
compliance
labels
gives
us
more
customization.
A
So
it's
harder
to
know
if
this
should
be
like
the
thing
that
gets
adopted
by
every
group,
because
I'm
I'm
still
not
even
sure
on
it,
and
so
when
I
walked
through
the
first
example,
I
was
trying
to
show
like
how
it
would
inherit
if
there
were
no
labels
and
then
the
second
one
was
if
there
would
be
labels
so
I'll
stop
there
and
I'm
going
to
try
and
go
pull
up
your
comment.
So
I
can
refer
back
to
your
specific
points.
B
Sure
so
so
maybe
what
would
be
helpful
is
for
me
to
back
up
a
little
bit
and
say
one
of
the
catalysts
for
the
labels.
Was
that
conversation
with
sid,
where
we
as
get
lab,
do
not
want
to
build
features
that
negatively
impacted
the
developer
experience
on
a
very
broad
level,
which
is
in
direct
conflict
with
what
enterprise
customers
want,
which
is
to
impact
the
experience
on
a
very
broad?
Well,
that's
not
fair!
That's
not
what
they
want.
B
So
the
reason
the
labels
made
sense
was
we
could
add
this
delineation
attribute
to
projects
groups
to
be
able
to
refine
that
scope,
but
that
of
course,
isn't
the
only
way
to
do
it,
I'm
sure
and
maybe
there's
a
different
way
to
leverage
them
that
still
achieves
the
same
outcome.
So
that's
a
little
bit
more
background
on
it,
but
that's
helpful.
A
Yeah,
I
think
it
does
help
set
the
context.
I
think
the
challenge
then
comes
in
when
we
talk
about
things
like
actually
using
the
labels,
but
the
way
that
we
have
it
currently
designed
you
can
only
apply
the
same
rules
for
one
or
many
labels.
You
can't
have
different
rules
for
socks
and
different
rules
for
hip-hop.
A
A
So
I
think
your
like
intuition
is
leading
you
towards.
We
should
still
work
towards
the
example
where
we're
introducing
rules
that
use
labels
as
a
way
to
percolate
down
inheritance,
and
then
the
second
thing
you
brought
up
was
okay.
If
you
disallow
changes
and
set
its
approvers
too,
I
don't
think
it's
changing
everything
too.
B
I
was
thinking
about
this
and,
as
we
talk,
it
sounds
maybe
more
like
a
more
simple
approach,
potentially
so,
for
the
sake
of
bringing
things
up
to
group
and
instance,
level.
For
the
sake
of
standardization
and
automation,
ignore
enforcement
for
a
second,
we
can
get
rid
of
the
label
concept
and
say
we're
going
to
add
this
to
the
group
level
and
we'll
give
you
control
on
how
and
where
this
inherits
down
to.
But
we
won't
give
you
the
ability
to
enforce
that.
B
Maybe
instead
for
the
enforcement
piece,
we
can
say
when
you
create
this
custom
label,
you
can
connect
it
to
a
project
template
and
that
project
template
would
have
all
of
these
settings
right.
It
would
have
merge,
request
approval
rules
that
would
have
protected
branches.
It
would
have
all
of
these
like
bits
and
bobs
and
levers
and
buttons.
B
You
could
push
and
pull
and
all
that,
and
so,
when
you
apply
the
sox
label
to
a
project
that
has
inherited
these
standardized
rules,
it
then
overrides
them
with
the
project
template
that
you're
referencing,
which
maybe
makes
this
a
lot
simpler
from
several
facets,
but
then
also
uses
an
existing
primitive
of
the
project.
Template
feature
to
be
able
to
connect
those
dots
and
it
saves
us
from
having
to
pile
on
enforcement
onto
this
already
complicated
inheritance
model.
But
what
do
you
think
about
that?.
A
So
I
think,
if
I
understand
you
correctly,
agnostic
of
labels
they'll
just
make
a
basic
tree
structure
of
your
inheriting
from
the
thing
above
you.
Although
nothing
is
going
into
read-only
mode,
all
your
children
can
still
go
in
and
change
things.
A
B
And,
and
so
there's
there's
a
couple
of
things
there
right.
We
already
know
that
customers
are
doing
something
like
this
because
they
call
it
compliance
as
code,
but
one
of
the
things
they
do
is
they
take
sort
of
this
project
build
file.
I
think
it's
maybe
a
json
or
yaml
file
and
they
say,
compare
this
project
to
this
file
and
where.
A
B
Could
emulate
on
our
back
end?
Natively
is
whatever
this
project
template
specifies.
That's
our
reference
point.
So
when
you
apply
a
sox
label,
we
can
check
everything
programmatically
or
even
just
like,
restrict
it
or
whatever
like
we
can
build
on
top
of
that
paradigm,
instead
of
having
to
build
complexity
into
the
default
inheritance
model.
B
B
Oh,
I
need
to
change
that.
You
just
go
change
the
project
template
and
then
we
can
figure
out,
like
does
that,
you
know
retroactively
apply,
or
does
it
just
allow
for
flexibility
or
whatever?
But
I'm
wondering
if
that
might
be
helpful
in
this
case,
because
we're
separating
the
two.
So
we
can
tackle
this
inheritance
problem
for
standardization
automation
and
then
we
can
tackle
the
enforcement
piece
in
a
way
that
abstracts,
the
two
or
like
separates
the
two.
A
So
yeah,
no,
I
I
like
the
idea
of
using
templates.
I
think
I
need
to
look
more
into
how
project
templates
work
to
better
understand
how
they
are
consumed
and
reused,
but
I
do
really
like
the
idea
of
focusing
more
on
the
logic
layer
of
settings
kind
of
in
general,
so
push
rules
and
protective
branches
would
be
included
in
this
standardizing
that
behavior
and
then
using
the
overrides
as
something
that's
driven
by
a
broader
template
that
can
be
pulled
in
so
in
this
example.
A
I
don't
have
it
labeled,
because,
obviously
I'm
not
ready
for
that
since
we're
doing
this
on
the
fly
sure.
But
if
this
was
like
our
project
down
here
right-
and
so
this
is
how
our
instance
is
configured
today.
It's
all
naked.
Let's
just
assume
this
was
a
socks
project
and
it
had
a
special
one.
So
if
I
made
changes
here-
and
I
set
this
to
two,
this
guy
would
have
maybe
just
stayed
at
zero.
A
If
that's
what
the
template
was
saying,
if
the
template,
for
whatever
reason
said
number
of
required
approvals
would
have
been
zero,
it
wouldn't
change,
but
the
group
inherited
it
because
the
instance
changed
and
this
project
inherited
it
because
the
instance
changed
and
then,
if
this
group
changes
nothing
would
have
changed
down
here.
Still,
it's
still
it's
only
pulling
from
its
template.
It
can
add
on
new
things,
like
you
can
add
on
an
additional
rule.
A
B
Follows
the
get
lab
single
source
of
truth
philosophy,
which
is
good
and
I'm
assuming
more
efficient.
A
B
B
Yeah-
and
I
think
why
I
like
that
more
as
an
additional
point
is
that
we're
doing
the
exact
same
thing
except
one
of
them,
has
fewer
steps
or
complexity.
If
we
do
the
current
paradigm
we're
exploring
yeah,
we
have
this
additional
toggle
and
we
only
care
about.
You
know
regulated
projects
beyond
that.
B
Just
do
standardization
and
automation:
it's
a
lot
simpler
and
gives
them
a
baseline
to
work
from.
A
So
I
I
want
to
try.
I
heard
you
correctly
on
this
one:
are
you
saying
you
still
think
we
would
want
to
use
and
allow
changes
toggle?
So,
even
if
it's
outside
of
the
scope
of
using
a
compliance
framework
label,
we'd
still
want
to
give
instance,
administrators
or
group
owners
the
ability
to
turn
on
and
off
this
thing
or
no.
B
A
A
B
To
validate,
if
this
is
like
copacetic
with
our
customer
use
cases,
I
think
it
would
be
an
improvement
over
the
current
proposal.
The
one
like,
however
comma,
would
be.
If
I
like.
I
imagine
there
are
organizations
like
I
know,
of
one
for
sure
that
wants
to
apply
a
blanket
policy
across
the
board.
Right
on
one
hand,
you
could
say:
okay,
we'll
just
apply
the
label
to
every
project,
because
you
can
do
it
via
api
and
it's
easy
enough,
but
the
second
is
well.
Maybe
there
is
a
use
case
we
haven't
thought
about.
B
That
makes
sense
where
you
apply
the
project
labels
to
projects,
but
then
every
other
project
in
the
group
or
whatever.
It's
like
you
do
want
this
mechanism,
but
I
mean
this
is
derived
from
what
customers
have
told
us.
They
want
and
us
doing
some
validation,
but
I
think
now
we're
at
the
point
where
we're
thinking
like
okay.
Is
this
really
the
best
way
to
solve
it,
and
I
think
we're
finding.
A
A
So
contrasting
this
to
push
rules,
if
this
was
kind
of
how
it
looked
today
ignore
bottom
project
over
here,
because
this
is
our
socks
project
and
it's
a
special
child
and
does
whatever
it's
told
by
project
template
if
the
instance
administrator
changes
this
to
four
the
push
rules.
A
Logic
today
would
say
we
don't
push
changes
down
right,
since
these
have
deviated
projects
yeah
two
existing,
it's
only
the
new,
so
I
think
that's
one
of
those
paradigms
you
would
still
be
changing,
I
think,
is
when
you
are
in
an
instance
or
even
at
a
group
like
you're,
going
to
impact
existing
things,
and
I
think
there
are
other
objects
and
settings
that
don't
do
that.
I
think
that
might
be
the
biggest
thing
we
need
to
work
with
across
the
board
on
is
inherit
or
only
apply
to
new
things.
B
Yeah-
and
I
think
that
and
I'm
not
convinced
that
that's
necessarily
the
wrong
default,
like
I
think,
it's
probably
okay-
to
default
to
only
new
objects,
but
there
should
be
some
action
available
to
say.
Well,
I
want
to
retroactively,
apply
this
to
everything,
or
at
least
existing
in
that
case,
because
all
new
ones
would
still
inherit
and
with
the
project
template
concept.
You're
do
you're,
essentially
providing
that
option.
B
A
Yeah
and
I
think
even
the
way
that
we're
considering
how
would
work
with
push
rules
today,
where
we're
saying
like
okay,
if
you're
in
the
compliance
dashboard,
you
get
a
report
of
all
these
projects
in
this
group
that
aren't
matching
your
group
rules.
You
can
push
that
default
to
them.
We
realize
that
you
may
have
said
it
and
that's
going
to
affect
all
your
new
projects,
but
now
you
know
for
the
500
that
already
exists
in
your
group
who
who's
not
matching
it.
A
You
can
decide
whether
or
not
they
deserve
or
where
or
they
should
be
at
least
updated.
I'm
not
going
to
say
in
force,
because
sometimes
it's
just
like
an
update.
It's
like.
Oh,
we
forgot
to
update
these
they're,
not
a
regulated
project,
but
we
just
want
to
swiftly
make
all
of
them.
A
I
was
saying
like
without
having
a
project
template
to
update
the
rules.
How
would
I
do
it
if
it
wasn't
being
inherited?
So
if
it
doesn't
update
based
off
of
its
parent
that
which
we
have
to
do
the
push
rules,
because
it's
not
updating
existing
projects,
so
we
have
to
give
the
a
way
to
recursively
apply
those
things.
As
we've
said,.
B
Yeah,
I
I'm
so
ignoring
the
technical
complexity
of
it
or
feasibility.
I
I
would
assume
that
we
could
say.
Okay
when
I
create
this
template,
I'm
gonna
store
it
in
such
a
manner
that
I
can
then
pull
against
that
for
these
projects
and
then,
if
it
doesn't
match
I'll
click,
a
button
and
it'll
force
that
project
to
reference
that
template
and
if
it
does
match
the
no
action.
Does
that
make
sense.
B
Converge
on
here,
yeah
and
that's-
the
thing
too
is
like
you:
projects
have
push
rules
at
the
project
level,
and
so
those
could
become
part
of
that
template
mechanism
with
labels,
and
so
maybe
the
group
level
implementation
should
only
ever
be
standardize
and
automate
and
default
only
to
new
objects.
And
then,
if
you
want
to
retroactively
apply
things,
maybe
we
just
do
that
by
means
of
adding
a
label
rather
than
adding
it
at
the
group
level.
B
A
Know
it
would
it
would
throw
a
wrench
in
what
we
currently
have,
but
I
think
it
might
be
the
better
idea
because
I
mean
like
if
we
okay,
diverging
away
from
merchandise
approval
rules
going
over
to
push
rules
as
the
example-
and
I
am
in
the
gitlab
org
group
and
I
have
500
projects.
Three
of
these
just
happened
to
have
different
push
rules
configured.
A
I
have
the
choice
to
set
to
default.
It
is
unclear
what
that
means,
but
I
think
the
intent
was
either
to
step
to
the
default
of
whatever
the
push
rules
are
set
at
the
group
level,
or
I
think
we're
saying
is
what
we
could
do
is
maybe
use
the
project
template
as
the
truth
single
source
of
truth
for
the
rule
set.
B
A
A
Yeah,
I
do
think
it
makes
it
easier
for
enforcement.
I
think
the
project
template
is
a
great
year
for
the
enforcement
and
putting
things
into
a
read-only
state.
I'd
like
that,
a
little
bit
more
than
just
having
to
toggle
on
and
off
allow
changes.
Yeah.
I
like.
A
A
B
Everything
you
said
I
agree
with,
and
so
I
think
that
gives
us
two
concurrent
solutions
here.
The
group
level
push
rules
we'll
stay
to
that
example
for
simplicity,
and
we
can
define
it
at
the
group
level
and
it
will
standardize
and
automate
the
inheritance
for
new
objects.
A
B
Then
simultaneously
we
have
the
the
labels
mapped
to
project
templates,
which
would
be
used
for
solely
the
enforcement
piece,
at
least
initially
and
say.
If
I
want
this
project
to
be
different
here
is
a
label
that's
tied
to
a
template?
That's
going
to
dictate
the
settings
and
the
inability
for
people
to
change
that.
B
But
then
I
think
the
projects
may
eventually
also
have
some
action
to
override
existing
project
settings,
because
I
imagine
that
especially
there
it'll
be
more
common
for
people
to
say
right.
You
know.
Oh,
I
have
this
ecosystem.
I
need
to
go,
create
this
new
label
for
some
reason
and
it
deviates
from
existing
label
project
templates.
So
I'm
going
to
create
it,
marry
it
to
a
new
project
template
and
then
apply
that
to
this
handful
of
projects.
That.
A
B
B
B
A
Yeah,
I'm
trying
to
illustrate
this
a
little
bit
or
at
least
get
that
diagram
started
one.
I
am
I'm
awful
at
mural
because
it's
different
than
both
sketch
and
sigma
and
I
swear
I
keep
hitting
shortcuts
and
it's
like
you
open
this
drawer
and
I'm
like
no,
I
just
want
to
copy
paste
anyone.
A
B
A
B
A
All
I
can
drop
this
in
the
chat
in
case
you
want
to
jump
in
here,
but
we
got
five
more
minutes.
Does
this?
Does
this
change
at
all?
How
we're
going
to
approach
the
conversation
with
discussing?
How
is
the
meeting
labeled
is
labeled,
discuss,
group
level,
push
rules
and
related
roadmap
items.
So
does
this
change
how
we
want
to
approach
the
group
level,
push
rules.
B
I
think
we
should
still
present
it
as
if
this
was
the
original
solution,
but
I
think
we
should
then
throw
them
the
curveball
and
say
okay.
But
what
do
you
think
about
this
other
thing
that
we've
been
thinking
about
as
we
assess
some
of
the
technical
challenges
of
this
implementation
and
I
say,
propose
both
and
get
their
feedback
side
by
side
in
that
way,.
A
I
think
the
only
thing
is:
I'm
not
gonna
probably
have
this
ready
with
you
in
15
minutes
for
20
minutes.
We
could
try.
A
B
A
A
A
A
A
Don't
kill
me
for
this
just
trying
to
show
like
the
organization
like
a
flat.
B
A
We're
very
focused
on
socks,
as
you
can
tell
so
in
the
instance
of
push
rules,
we're
saying
today
in
our
designs
and
proposals
you
can
push
down
the
group
level
defaults
to
your
projects,
but
what
we're
saying
is
potentially
like
this
guy
could
instead
decide
to
pull
from
the
sox
related
one
wow-
let's,
let's
not
do
it
like
that.
It
was
awful
copy.
This
paste
it
and
here
I'll
link
here.
A
B
So
I
don't
think
the
group
one
is
necessary.
Okay,
like
I
think,
basically,
what
happens
is
we'll
start
from
the
top
level.
At
the
instance
level,
we
define
push
rules,
those
get
inherited
by
new
objects.
B
B
I
think
the
only
difference
between
you
and
existing
is
one
you're
having
to
prompt
them
for
ux
and
say
this
is
about
to
change.
It
will
probably
break
stuff,
but
I
don't
think
we
need
anything
at
the
group
level
other
than
the
ability
to
define
the
standard
rules,
but
just
no
enforcement
mechanism.
A
The
way
I
could
do
that
is
by
going
into
a
group
going
to
their
compliance
dashboard
and
saying,
like
the
what's:
what's
a
fun
all
right
this,
this
is
fun.
B
A
A
And
then
the
same
logic
would
exist,
though,
for
like
groups
going
to
subgroups.
So
if
I
have
an
instance,
it's
set
up,
I
created
a
new
group.
I
inherited
things
from
it
and
I
and
I
adjust
my
group
settings
and
I
create
a
subgroup.
Then
that
subgroup
is
going
to
inherit
its
groups,
design,
not
the
instance
design
and.
B
A
Well,
they
have,
they
have
control
over
it
today,
technically
if
they
can
add
and
remove
the
label,
but
that's
a
problem
for
a
different
day:
okay,
okay
yeah.
So
I'm
on
my
screen
now,
but
so
that
still
allows
this
design
to
work.
We
would
just
be
specifying
that
you're!
You
can
pull
from
your
instance
if
you
want
to
to
set
a
default
to
a
project,
so
it
gives
you
some.
B
A
B
Yeah
and
maybe
that's
okay-
I
think
we
just
have
to
validate
it
because
usually
they
want
to
standardize
it
at
the
group
level
so
that
it's
standardized
at
the
project
level
is
what
I
interpret
for
that.
A
A
So
to
me
it
sounds
like
for
cameron,
they'd
be
more
concerned
about
okay
yeah.
I
have
all
these
interesting
projects.
I've
updated
my
rule
set,
it
looks
great,
but
maybe
I
don't
want
to
use
a
compliance
framework
template
to
enforce
these
rules.
I
just
want
to
help
create
sensible
defaults.
Let
me
update
all
those
okay.
B
A
B
A
A
A
B
B
Want
is
that
control
the
instance
level
at
the
instance
level
you
create
your
like
secret,
powerful
top
level
group
or
project
or
whatever
you
like,
create
these
templates
in
there
or
well
sorry,
you
create
your
single
source
of
truth
group
and
then
you
create
the
project
project
templates
and
there,
and
so
let's
say
you
have
the
two
projects:
well
you're,
controlling
that
as
admins.
You
only
grant
permission
to
that
group
to
whomever
you
want
and
then
by
adding
the
labels.
B
B
A
Okay,
then
maybe
it
is
worthwhile
at
least
to
touch
on
the
issue
just
in
case
they
have
just
so
they're,
not
like
what.
What
is
this
thing
you're
talking
about
over
here?
You
have
work,
that's
in
your
flow
already.
We
could
talk
about
how
that
I
might
say
we,
I
assume
you're,
presenting
the
idea.
Somehow.
This
is
currently
solving
a
problem
given
how
git
lab
works
today,
but
then
we
could
also
touch
on
the
fact
that
there's
a
broader
initiative
to
improve
the
settings
ux
overall,
including
things
related
to
the
inheritance
model.
A
This
is
how
we're
considering
evolving
over
time
and
then
we,
if
it
makes
sense,
we
could
work
through
this
mural
board
a
bit
with
them
to
talk
through
some
of
that
logic.
B
Yeah
yeah
I'll
start
the
conversation
and
I'll
ask
them
if
they
want
us
to
go
into
the
deeper
technical
dive
and
if
they
do
then
I'll
hand
it
over
to
you
to
walk
through
your
mock-ups
that
you
had
where
it
was
like
using
the
socks
label
versus
not
or
whatever
you
feel
is
appropriate
to
demonstrate
that.
But
then
I
would
probably
then.
A
B
Them
through
this
rationale,
so
we
have
the
side-by-side.
A
Yeah,
I
think
the
only
thing
I
would
probably
end
up
bringing
up
is
just
the
group
level
stuff.
I
don't
think
that
this
step
through
prototype
makes
sense
the
way
that
it
stands
today
and
just
add
more
confusion.
The
only
thing
I
would
be
totally
open
to
helping
you
with
is
clarifying
the
issue,
it's
mock-ups
for
the
proposal
and
talking
through
our
diagram
if
they
want
to
get
into
the
nitty-gritty
of
how
we
see
things
evolving,
but
I
would
love
a
data
point
on
if
they
think
this
makes
sense
to
them.