►
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
My
name
is
Michael
Lee
of
the
source
code
group
and
I'm,
going
to
talk
about
a
group
level,
merge
request
rules,
specifically
the
minimum
required
approvers.
So
this
is
my
view
on
how
we
can
handle
this
with
the
context
of
Branch
rules.
So
Branch
rules
are
something
that
we've
introduced
in
the
project
level.
To
encapsulate
rules
focused
around
the
branch
so
think
about
your
protective
branches
and
merge
request
approvals
status,
checks,
things
like
that
and
with
Branch
rules.
A
We
do
display
merge,
request
approvals
like
this,
and
this
is
where
the
minimum
required
approvals
or
the
default
rule
that
exists
for
merge,
request
approvals
and,
at
the
moment,
zero.
That's
the
default.
We
do
handle
the
case
for
branch
rules
at
the
project
level
to
handle
all
branches
and
all
protective
branches
in
the
context
of
the
group
rules.
I
think
what's
really
interesting
is
that
we
do
already
provide
a
pathway
to
handle
all
protective
branches.
A
So
if
I
click
the
protect
the
branches,
that
would
create
me,
a
new
Branch
rule
with
all
protected
branches
that
has
the
one
default
rule
here.
The
minimum
required
approvals-
and
here
you
can
add
specific
rules,
approval
rules
for
that
you
know,
if
you
wanted
to
add
team
leads
or
things
like
that
at
the
group
level
you
could
so,
let's
have
that
in
mind.
At
the
group
level,
we
may
not
have
status
checks
for
the
time
being,
and
so
we
can
just
focus
on
merge
request
approvals.
A
So
how
would
this
work
in
the
world
of
the
group?
So
at
the
moment
our
repository
settings
are
just
these
things
here.
If
we
introduce
Branch
rules,
of
course,
by
default,
there
won't
be
any
branch
rules.
But
if
you
add
one
branch
rule,
the
only
one
that
you
can
do
right
now
would
be
all
protective
branches,
but
we
could
introduce
the
biocard
ones
where
you
target
like
Dev
star,
and
things
like
that.
A
As
you
can
see,
this
rule
here
would
apply
to
150
projects
jumping
into
the
details
here,
jumping
into
here.
Okay,
this
would
be
the
branch
rules,
details
for
all
protective
branches
at
the
group
level,
and
we
changed
this
from
the
default
to
zero
to
two
with
the
intent
that
all
projects
that
inherent
from
this
will
now
have
two
as
the
required
approvers.
A
Okay,
how
that
might
look
like
at
the
project
level
would
be
like
this,
where
that
approval
required
box
for
a
minimum
required
approvals
is
no
longer
editable,
because
it's
a
group
level
setting.
We
can
leverage
the
same
pattern
that
we've
been
using
for
this
type
of
stuff
by
using
the
padlock
and
then
hovering
over
the
padlock
will
tell
you
hey,
there's
a
group
level
setting
you
need
to
be
admin
or
the
Groupon
need
to
change
it.
A
A
This
is
one
way
to
do
it.
Another
way
to
do
that
is
to
separate
any
inherited
approval
rules
until
it's
on
their
table.
So
here
we
have
the
same
scenario:
this
minimum
required
approvers
is
now
in
the
inherited
one
and
so
like
looking
at
scanning
I'm
like
okay.
These
rules
here
are
actually
inherited
now.
Okay,
so
minimum
required
approvals
is
actually
inherited
from
web
group.
So
one
step
now
from
the
padlock
is
that
I
can
actually
see
which
parent
group
I
am
inheriting
from
I.
A
A
We
displayed
the
group
level
setting
popover,
and
why
do
we
want
to
do
this
because,
potentially
this
can
set
us
up
for
a
framework
for
to
show
all
types
of
inherited
approval
rules
and
then
one
example
of
that
is
security
policies
where
there
could
be
approval
rules
that
appear
for
a
branch
based
on
certain
conditions
right.
So
this
way,
if
I'm
someone
who's
just
looking
at
managing
my
project,
I
can
look
at
this
and
actually
see
oh
okay,
while
I'm
setting
up
all
these
other
checks.
A
I
I'm
also
aware
that
there
are
these
other
rules
that
could
come
into
play
on
my
protective
branches
and
I
have
this
one
from
the
super
security
policy
and
the
one
that
we
just
talked
about.
The
minimum
required
approvers
I
can't
change
this,
because
it's
a
group
level
setting
and
then
this
one
here
if
I
hover
over
it.
You
know
the
text
can
change
here,
but
I
can
say.
Oh
this
is
inherited
by
the
super
policy
and
then
I
can
click
on
this
to
then
go
change.
A
The
policies
if
I
have
the
permissions
but
I,
think
displaying
the
read-only
rules
is
really
powerful
from
the
project
owner
perspectives,
because
there
are
no
surprises.
You
know,
you
know
what
kind
of
approvers
rules
will
come
into
play
on
your
branches
before
you
even
bother
setting
up
your
own
custom
approval
rules
at
the
project
level,
so
yeah
I
think
we
can
start
with
the
padlock
or,
if
you
want
to,
we
can
explore
this
idea
of
the
separated
approval
rules,
but
those
are
two
ways
that
we
can
approach
this.