►
From YouTube: Design concept - Editing branch rules
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
Name
is
Michael
Lee
of
the
source
code
group
and
this
is
an
update
on
editing,
Branch
rules.
So
it's
been
a
while
since
I
provided
an
update
on
this,
but
I
wanted
to
show
you
all
where
I'm
at
right
now.
So
this
is
what
the
editing
experience
for
editing.
Branch
rules
is
at
right.
Now
we
have
your
branch
rule
details.
You
can
delete
it.
You
have
your
pattern.
A
A
Help
Branch
protections
are
done
right
now
you
have
the
branch
and
wild
card,
and
then
you
have
the
this
ability
to
change
who's
allowed
to
merge
and
who's
allowed
to
push
and
merge
my
biggest
pet
peeve
with
all
this
is
that
for
a
simple,
relatively
simple
kind
of
thinking
setup.
A
You
know
you
want
your
protective
branches
to
be
to
have
changes,
be
submitted
with
merge
requests
and
you
actually
have
to
play
around
with
these
things,
set
your
allowed
to
push
and
merge
to
no
one,
and
you
can
do
whatever
with
merch
like
I
said,
whoever
you
want
to
be
able
to
merge,
but
that's
not
very
obvious
and
clear,
and
that
was
something
that
I
really
wanted
to
tackle
as
part
of
this
as
well.
A
Just
updating
the
experience,
some
other
things
that
I
wanted
to
address
also
were
like
these
numbers
that
we
have
right
now
in
our
read-only
view,
details
I
personally
think
that
they
don't
make
any
sense
so
developers
and
maintainers.
That
could
be
that's
that's
two
roles
or
many
many
people
inside,
and
we
put
this
one
here
so
I
think
we
can
lose
these
numbers
and
make
our
UI
a
little
bit
more
clear
in
the
beginning.
Maybe
six
months
ago,
this
was
the
direction
of
the
design
and
some
of
the
feedback
around
here
was
around.
A
You
know
this
is
editing
with
a
drop
down,
but
this
is
editing
with
with
like
a
button
and
is
very
disjointed
and
then
with
push
keys.
This
was
like
the
approach
that
I
had
at
the
time,
and
that
could
be
multiple
push.
Keys
here,
deploy
keys,
I
mean
for
push
and
merge,
and
that's
not
very
clear,
also,
and
at
the
same
time
we
have
one
layout
for
approvers,
merge,
request,
approvers
and
a
different
layout
for
this.
A
In
recently,
there
have
been
some
changes
in
settings
doing
a
single
column
instead
of
doing
this,
two
column
thing,
as
well
as
the
introduction
of
GL
card
to
hand
those
scenarios
of
presenting
information
like
this,
but
also
handling
this
narrow
of
presenting
information
and
the
approval
rule
a
month
ago.
This
was
the
exploration.
A
I
was
doing
with
the
GL
card,
where
I
have
things
listed
out
here
and
where
you
can
add
different
roles
and
groups
until
that's
emerge
and
I
was
playing
around
with
this
idea
of
you
know
a
checkbox
to
say
that
you
want
changes
to
be
submitted
with
merge
requests,
but
at
the
end
of
the
day,
it
didn't
really
do
anything,
because
there
are
some
scenarios
where
you
would
want
people
to
push
to
branches,
but
they're
they're,
not
really
bypassing
Branch
protections.
A
It's
just
how
you
set
up
your
oh
repository
to
work
like
that.
So
I
was
playing
around
with
this
idea
of
bypass
Branch
protection,
which
was
a
way
to
surface
allowed,
to
push
and
merge
and
in
a
way
it
makes
sense,
but
I
think
I
made
the
UI
a
lot
more
busy
and
cluttered,
especially
with
this
kind
of
interaction
for
entering
users.
A
A
So
we
are,
let's
walk
through
on
the
branch,
close
work
and
what
that
looks
like
today
at
the
moment.
So
we
have
branches
like
this
today.
Everything
is
in
jail
card.
A
A
Merger
requests
are
required
for
all
changes,
except
those
allowed
to
push
and
merge,
and
those
people
who
are
allowed
to
push
merge
are
those
with
the
roles
of
administrative
maintenance
developers.
So
it
just
reads
reads
well
together,
and
this
doesn't
allow
Force
pushing
so
we're,
not
disabling
elements,
we're
actually
presenting
information
in
a
read-only
way.
We
already
do
this
currently
with
our
Branch
details,
so
there's
just
changing
things
up
a
little
bit,
and
this
is
an
example
where
nobody
has
been
set
up
to
push
and
merge.
A
So
therefore,
everyone's
a
required
to
submit
a
merge
requests
with
the
changes,
so
I
feel
that's
a
little
bit
clearer
around
what
you
know
how
you
set
up
your
branch
protections.
It
actually
reads
like
this.
Potentially,
if
you
could
lose
this
line
as
well
or
think
of
cleaning
this
up
actually
like
combining
them,
let's
go
through
example
of
creation,
because
I
think
that's
more
interesting.
A
So,
with
the
branch
rules,
when
you
click
add
rental,
you
can
add
it
by
a
branch
pattern
or
name
all
branches.
You
know
protected
branches,
so
this
is
all
branches,
and
all
protective
branches
is
something
that
exists
in
merge
request
approvals
now,
and
we
just
want
to
support
that
with
Branch
rules
as
well.
So
as
you
can
see,
there
are
zero
Branch
rows
at
this
time.
A
Okay,
if
you
choose
by
the
name
or
pattern
similar
to
help
protect
the
branches
work
right
now,
you
click
on
it
and
you
search
for
the
name.
The
name
doesn't
exist.
You
can
create
a
wild
card
and
you
click
on
that
and
then
it
creates
a
branch
rule
with
that
pattern,
and
you
can
see
that
it's
matching
16
branches
with
the
branch
protections.
This
is
all
the
default
stuff
that
comes
out
this
I
think
at
the
moment
the
default
actually
is
zero.
A
So
we
can
change
that,
but
there's
a
lot
of
toast
to
say
that
this
potential
has
been
created.
So
that's
the
feedback
mechanism
that
we're
going
to
use
in
our
updates
is
using
toasts.
There's
no
save
button
on
the
page.
Everything
is
just
dynamic,
so
let's
go
in.
A
So
what
we're
going
to
do
now
is
editing
allowed
to
merge
so
I
click
on
the
edit
button.
This
thing,
pops
up
administrators
and
maintainers,
are
currently
selected,
and
so
those
roles
are
selected
here.
There
are
more
rules
to
be
added
and
they
can
be
added
to
the
top
here
and
that's
fine
here
to
add
users
and
groups
and
you
we
would
type
it
in
search
for
them
and
as
if
we
find
them,
we
can
add
them
to
our
list.
Click
update
and
we
see
that
are
allowed
to
merge
the
little
table
here.
A
A
little
GL
card
has
a
table
with
roles
and
users
and
groups
listed
out
there,
there's
a
toast
that
pops
up
and
you
can
undo
the
change.
A
The
next
thing
we're
going
to
do
is
enter
in
the
push
and
merge
part
similar
to
before,
but
the
only
difference
here
is
that
you
can
search
for
deploy
Keys
as
well
for
pushing
and
once
that's
resolved,
we
have
a
key
with
the
name,
the
and
the
play
key
itself.
This
is
much
better
than
just
displaying
the
key
Alone.
A
A
pop-up
is
not
really
necessary,
but
we
could
introduce
something
there
to
display
who
owns
this
key
and
potentially
with
the
pattern
of
the
hash
key
could
be
so
now
we
added
some
people
here
and
what
you
can
see.
That's
different
is
that
there's
no
line
here
or
no
Force
pushing
now
that
we
added
people
in
here
and
who
can
push
we're
using
Progressive
disclosure
to
reveal
extra
functionality,
because
there's
no
point
of
showing
a
loud
Force
push
if
there's
no
one
allowed
to
push.
A
So
that's
the
idea
of
just
revealing
this
once
you
have
someone
some
some
roles
groups
or
deploy
Keys
set
here.
So
when
that
was
added,
he
had
a
toast
and
you
kind
of
do.
You
have
a
click,
a
little
Force
push,
because
it's
a
toggle,
it's
immediate,
so
it
doesn't
go
and
allow
Force
push
is
enabled
simple
code
owners.
A
It's
a
toggle
so
immediately
after
pressing
that
it
updates-
and
the
next
thing
that
we're
going
to
do
is
change
this
number
from
one
to
two,
and
this
is
how
it
currently
works
for
version
request
approvals
right
now
for
all
eligible
users,
you
change
the
number
in
it
changes,
but
there's
no
feedback,
so
the
feedback
we're
going
to
use
here
is
using
the
toast
again.
A
So
that's
that
what's
next
adding
merge,
request
approval
rules,
so
we
have
something
called
a
coverage
to
check
in
that
check
is
run
when
the
test
coverage
decreases.
A
A
The
flows
are
pretty
much
the
same
as
it
is
currently
today,
when
you
specify
the
rule
name
approvals
and
the
different
groups
and
users
here,
yeah
I.
Don't
think
there's
roles
here,
so
we
can
just
remove
that
for
now
groups
and
users.
A
The
difference
between
the
branches
approach
is
that
the
target
branch
is
already
determined
by
the
pattern
up
here.
So
a
field
for
selecting
a
branch
is
not
here
for
approval
rule,
so
that's
the
difference.
Yep
you
found
some
people
in
the
coverage
check
one,
the
name.
You
can't
change
and
potentially,
if
we
can
add
some
description
about
what
this
coverage
check
can
do
and
that
approval
rule.
A
So
once
that's
added,
you
can
see
that
we
would
use
the
toast
for
each
individual
rule
that
got
added
and
then,
if
a
rule
got
updated,
we
would
show
the
toast
again
and
potentially
have
the
undo
button
on
it
as
well.
A
Once
that's
done,
we
have
our
status
checks.
This
is
a
lot
more
straightforward,
clicking
add
status.
Checks
opens
up
a
model.
You
enter
your
service
name,
your
API,
to
check
and
status
check
and
boom
your
your
business
here,
and
so
you
get
the
toast
for
feedback,
and
this
is
your
overall
page
for
branch
rules
for
editing
in
yes,
I
think
the
biggest
part
for
feedback
is
whether
this
is
necessary
or,
if
there's
other
ways
to
present
this
information.
Some
things
that
I
was
been
thinking
about
is
moving
this
description
inside
here.
A
So
that's
part
of
this
block,
so
that
might
be
something
that
could
be
done.
But
I
do
like
that
idea
of
using
Progressive
disclosure
that,
once
you
add
roles
in
here,
then
you
would
show
these
two
things.
A
Yes,
so
that
is
editing
Branch
rules,
and
it
feels
like
it's
not
too
far
off
from
where
we're
at
right
now,
but
I
think
it's
just
an
active
refinement
over
the
last
couple
of
months
to
get
us
to
this
date
so
and
your
feedback
is
greatly
welcome.
Thank
you.