►
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
So
if
you've
ever
edited
protective
branches
before
we
have
something
like
this
and
inside
each
of
these
drop
downs,
there's
actually
three
things
you
can
select
when
you're
dealing
with
trying
to
set
push
and
merge,
you
can
select
users
groups
and
deploy
keys
and
select
roles.
A
All
within
one
drop
down
talk
about
a
drop
down
that
works
hard
and
it's
really
hard
to
see
your
selected
states
by
putting
everything
into
a
drop
down,
and
we
have
this
opportunity
to
revisit
how
we
handle
this
and
eventually
think
about
you
know,
what's
a
better
way
to
do
it
so
initially
I
designed
I
pulled
out.
One
thing
here
is
the
roles,
and
here
we
can
have
a
checkbox
to
allow
you
to
select
whatever
roles
you
want
and
essentially
separating
that
out
from
users,
groups
and
employee
keys.
A
This
drop
down
or
search
behaves
very
similar
to
this
drop
down.
It's
it's
a
search
that
search
all
three
groups.
It's
really
powerful
because
you
just
go
to
one
place
to
select
whatever
you
want
and
then
at
the
end,
whatever
is
selected
shows
up
on
the
list.
A
Yep,
that's
a
little
bit
more
clear
than
this,
but
after
a
design
review
with
Andy,
he
posed
the
question
you
know:
is
there
another
interaction
pattern
that
we
could
use
here
to
make
this
even
easier?
A
And
that's
where
we
come
into
drawers
so
with
drawers
drawers,
allow
us
to
provide
contextual
information,
also,
while
keeping
the
main
object
in
view.
So
here
is
our
editing
experience,
but
also
the
main
object
is
in
view.
So,
unlike
a
model,
it
doesn't
block.
So
you
can
actually
scroll
and
look
around
so
as
I'm
editing
this
rule
for
allowed
to
push
and
merge.
A
But
if
you
look
at
this
design
here
and
you're
gonna
weigh
it
against
a
model,
so
if
I
put
them
side
by
side,
just
like
this,
the
benefits
aren't
really
there
right.
So
you
know
to
display
your
information
like
this
or
like
this.
It's
same
same,
it
doesn't
really
matter.
A
But
what
can
we
do
here
to
make
it
count
that
we
are
moving
towards
drawers
and
that
is
actually
splitting
up
users
groups
and
deploy
Keys
into
their
own
separate
areas
so
separating
them
out?
We
get
it
looking
like
this,
and
this
means
that
when
you
go
to
edit,
you
can
edit
roles,
users,
groups
and
employees
all
independently
of
one
another.
The
context
for
searching
users
is
just
limited
to
users,
and
if
you
want
to
add
groups,
you
go
down
to
here
to
add
groups.
A
This
would
open
up
a
model
that
allows
you
just
to
select
groups,
but
that's
very
slow
compared
to
the
existing
experience,
where
you
can
do
everything
all
in
one
go
using
the
drawer.
It
actually
allows
you
to
press
one
button,
the
edit
button
on
allowed
to
push
and
merge
and
allows
you
to
edit
all
these
things,
all
in
one
go
and
once
you're
happy
with
everything
you
click
save
changes.
A
But
I
think
what
we
can
do
is
settle
back
into
using
the
GL
card
which
we're
using
all
over
the
place
now
for
settings,
and
if
we
use
that
pattern
again
here
we
have
a
uniform
look,
you
search
and
add
by
users,
and
if
you
look
at
side
by
side
here,
I
think
it
just
groups
everything
nicely
into
little
blocks
and
I
think
that
works
for
me
and
if
we
look
at
that,
compare
the
drawer
approach
with
the
model.
A
I
feel
like
it's
a
much
more
clear
what
you
have
selected.
You
can
see
the
users
there's
two
of
them.
These
are
the
people,
the
groups
and
the
deploy
keys
and
no
longer
do
you
have
to
do
you
need
to
investigate.
Oh,
this
is
a
square
square
picture.
So
that
means
that's
a
group.
Oh,
this
is
a
circle,
so
this
must
be
a
user
there's.
None
of
that
anymore.
Everything
is
just
grouped
neatly
in
their
independent
list.
So
that's
definitely
a
move
to
move
towards
drawers
over
models
here.
A
I
think
one
of
pet
peeve
of
mine
with
protective
branches
has
always
been
like.
How
do
you
set
up
your
branch
so
that
everyone
needs
to
submit
a
merge
requests
for
changes
on
the
protective
Branch?
This
comes
up
often,
and
the
way
you
do
it
right
now
is
that
you
need
to
know
that
you
need
to
select,
allow
push
and
merge
to
no
one
and
then
allow
it
to
merge,
as
whoever
gives
whoever
you
want
to
give
the
role
of
emerging
to
it
could
be
teammates.
A
In
this
example,
here
is
developers
and
maintainers,
but
if
I
was
just
looking
at,
the
protective
branch
is
so
confusing
and
unclear
of
how
I
might
would
set
that
up.
So
the
one
thing
I've
added
in
the
previous
designs
was
I
had
this
text
down
in
this
area
here.
But
the
problem
with
this
execution
is
that
it's
an
action
and
I'm
using
a
link
for
an
action
and
that
doesn't
really
align
with
what
we
needed
to
do
because
we
want.
A
A
So
here,
if
you
want
everyone
to
require
a
merge
request
for
all
changes,
you
know
this
means
that
no
one
will
have
Push
access,
but
that
eventually
does
is,
if
you
toggle
it
on
you
see
that
oh
okay
nope,
this
whole
area
disappears
or
is
hidden,
visibly
and
because
it's
in
a
drawer
you
can
compare
and
contrast
with
what
it
is
currently,
and
you
can
say:
oh
okay,
right
now,
I
have
these
three
rows:
one
group
four
users
and
then
deploy
key
if
I
set
this
up,
nobody's
allowed
to
push
and
I
might
need
to
notify
these
people.
A
A
If
I
click
save
changes,
then
I
get
this
empty.
State
everyone's
required
to
submit
a
merge
request
for
changes
and
I.
Think
that's
interesting
flow
and
you
know:
if
we're
going
to
do
it
in
one
place,
we
might
as
well.
Do
it
everywhere
else.
Another
place
where
we
have
rules
is
in
the
approval
rules
themselves,
where
you
can
click
edit
on
them,
and
this
is
what
it
looks
like
on
the
right.
Currently,
we
have
the
name,
the
target
Branch,
but
in
the
world
of
Branch
rules,
the
context
of
the
branches
array
established.
A
So
in
this
scenario,
we
wouldn't
have
Target
Branch,
but
we
would
have
rule
name
approvals
required
and
the
ad
approvers
here
we
can
see
the
same
kind
of
combination
of
combining
users
and
groups
into
one,
and
this
is
how
it
could
look
if
you
separated
those
two
concepts
out
into
their
independent
list,
and
you
know
side
by
side
personally.
I
feel
like
this
is
a
much
more
clear
way
to
approach
editing
because
everything's
in
its
independent
list,
but
I'm
happy
to
hear
your
feedback
on
this
and
yeah.
There's
no
real
blockers.