►
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
Michael
Lee
of
the
source
code
group
and
today,
I'll
be
talking
about
group
level
approval
rules
specifically
targeting
all
protected
branches.
So
what
we
have
here
is
the
flow
of
adding
group.
Double
merge,
request
approval
rules,
so
here
we
are
at
the
group
level
settings-
and
this
is
in
general
settings
because
that's
where
merge
request
approvals
currently
is
we
have
these
approval
settings
set
at
the
top
group
level
and
we're
going
to
introduce
approval
rules
clicking
on
by
default
nothing's
added.
A
We
can
click
on
this
button
to
either
add
the
minimum
required
approvals
or
a
customer
approval
rule
if
we
do
the
minimum
approval.
This
is
what
we
see
currently
in
the
project
level,
known
as
any
eligible
users,
but
I'm
going
to
add
a
label
to
this
called
Rule,
and
that
will
be
minimum
approvals
in
the
Target
branch
is
all
protective
branches.
A
Now,
with
this,
you
can
see
that
it's
added
and
there's
a
toast.
So
let's
say
I
change
this
to
two.
A
A
Now,
if
I
want
to
add
my
own
custom
rule
approval
rules
such
as,
and
you
know,
team
leads
across
the
group
for
all
projects.
I
would
add
a
customer
approval
rule
and
that
opens
up
the
current
model
that
we
have
a
model
that
we
have
right
now.
The
rule
name
team
leads
Target
Branch
for
this
issue.
A
It
gets
added
all
the
different
approvers
get
resolved
to
individual
users
as
it
is
currently
at
the
project
level,
and
we
get
a
toast
that
says:
approval
rule
added
great
if
I
want
to
edit
that
I
will
click
this
and
it
will
pop
open
up
tomorrow
again
for
editing,
and
this
is
at
the
end,
you
know
no
toast
at
the
end
of
the
day.
This
is
what
it
would
look
like
at
the
group
level
because-
and
we
said
things
at
the
group
level
and
they
all
projects
underneath
inherited.
A
So
this
is
the
project
level
view
we
can
see
that
I
have
these
inherited
approval
rules,
so
we
have
two
of
them
in
this
scenario
here
and
we
can
see
that
there's
these
lock
icons,
which
we
currently
use
for
approval
settings
to
show
that
these
are
read
only
and
their
settings
that
have
been
configured
at
a
group
level.
A
So
we
had
our
minimum
required
approvals
and
the
leads
we
see
the
target,
Branch,
all
protective
branches.
You
know
it's
all
same
there
and
if
you
hover
over
that,
we
can
see
that
there's
a
pop
over
that
says
this
was
configured
in
the
group
and
you
can
change
it
there.
A
The
label
here
says
setting
inherited
there's
a
question
whether
we
should
continue
using
the
word
settings
enforced,
which
is
what
we
use
elsewhere,
or
should
we
change
that
language
to
inherit,
but
I
think
that's
a
minor
thing
that
we
can
resolve
when
the
time
comes
all
right,
so
that,
in
a
nutshell,
is
what
this
whole
thing
would
look
like
and
operate.
A
One
consideration
I
had
was
around
the
minimum
required
approvals.
So
let's
say
someone
set
this
up
as
two
at
the
group
level,
but
for
my
project
that
you
want
three
minimum
requirements
required
approvals.
So
one
way
we
could
approach
this
is
that
to
treat
the
minimum
required
approvals
to
be
whatever
is
set
at
the
group
level
and
therefore,
if
a
user
enters
a
lower
number,
they
can't
do
that.
A
So
you
know
if
the
minimum
is
two
and
I
try
to
enter
one.
There
will
be
some
feedback
saying.
Oh,
you
know
this
number
is
not
valid,
because
the
minimum
required
approvals
is
set
to
two
at
the
group
level.
Please
set
up.
A
Let's
set
a
higher
number
of
approvals,
so
I
think
this
could
give
us
more
flexibility
for
those
organizations
where
they
may
set
the
minimum
required
approvals
to
be
one,
and
you
could
have
more
projects
with
stricter
rules
to
set
their
own
values
that
are
higher
than
the
minimum
required
approvals.
So
I
think
that
could
be
something
that
we
explore
in
the
future
for
the
time
being,
what
I
propose
is
to
just
lock
it
down
right
now.
That's
something
yep!
A
It's
also
a
consideration
of
simplifying
the
page
itself,
so
we
just
have
ADD
approval
raw
and
the
minimum
required
approvals
is
added
there
by
default,
just
how
it
is
in
the
project
level,
with
any
eligible
users
and
default
set
to
zero.
My
one
consideration
against
doing
something
like
this
is
that
by
default,
what
we
would
need
to
do
is
have
a
rule
that
says
if
this
number
is
zero,
we
don't
display
that
at
their
project
level
at
all,
and
if
we
do
that,
then
we
should
be
fine.
A
A
That's
configured
at
the
group
level
being
set
when
you
know,
maybe
they
didn't
intentionally
set
it
and
it
was
just
there
by
default,
because
we
released
the
feature
so
I'm
open
for
engineering
feedback
on
this
one,
because
I
think
you
could
simplify
things
but
I'm
just
had
to
add
in
a
special
rule
of
saying
like
if
it's
zero,
don't
display
the
setup,
a
project,
level
and
I'm,
not
sure
of
what
other
scenarios
that
could
could
work
against
us.
A
If
we
decide
to
have
special
rules
to
hide
and
show
approval
rules
depending
on
what's
set
here,
like
you
know,
if
I
set
a
custom
raw
to
be
zero
so
like,
if
I
said
this
one
to
be
zero,
but
I
displayed
at
the
project
level
or
not
and
like.
If
this
we
don't
display
it,
and
this
was
Zero
as
well
like.
How
can
we
display
this,
but
not
that
I
think
there's
a
little
bit
of
potential
confusion
that
could
be
arised,
but
I.
A
Think
another
case
could
be
made
that
you
know
the
simplification
of
this
flow
trumps,
that
potential
confusion
and
then
the
other
thing
that
I
think
that
we
could
explore
is
starting
to
use
the
drawer
method
for
instead
of
using
modals,
and
this
allows
us
to
head
towards
the
direction
of
what
we're
trying
to
work
with
for
branch
rules
and
where
we
take
whatever
is
in
the
drop
down.
A
Now,
where
you
know
you
can
add
users
and
groups
at
the
same
time
to
actually
expand
it
out,
so
that
you
had
users
and
AD
groups
in
the
same
manner,
but
separately,
so
that
you
can
see
clearly,
what's
a
user
and
what's
a
group
and
at
the
end
adding
them
together
into
the
approvers
list
rather
than
resolving
everyone.
A
At
this
time
you
would
display
the
groups
and
the
users
individually
and
I
think
from
a
maintenance
from
a
setting
up
perspective,
displaying
that
you
have
selected
a
group
rather
than
resolving
everyone's
name
out,
and
there
is
a
benefit
there
for
understanding
that
okay
I
set
it
up
as
a
group,
and
you
don't
need
to
like
scan
every
single
name
to
ensure
that
you
have
full
correctness.
But
those
are
the
designs
that
I
have
in
the
works
around.
A
So
those
are
some
considerations:
I'm
open
to
engineering
feedback
on
what's
feasible.
What
I
proposed
right
now
is
more
of
a
simplistic
approach
of
handling
merger,
Quest
approval
rules
at
the
group
level,
leveraging
existing
screens
that
we
have
at
the
project
level
and
then
maybe
once
we
get
all
that
sorted,
then
we
can
start
thinking
about
expanding
things
out
into
using
the
drawers
or
using
the
minimum
as
a
minimum
for
approval
rules
and
yeah.
Thank
you.