►
From YouTube: Manage Stage GitLabbers discuss the limitations & opportunities within the GitLab Admin panel
Description
Admin Area group discussion with Luca Williams, Drew Blessing, and Matt Gonzales.
A
B
A
Drew
please
feel
free
to
correct
me
if
I
misspeak
about
any
of
these,
because
I'm
also
still
learning
some
of
these
capabilities.
So
let
me
share
this
okay,
so
the
primary
primary
areas
that
I've
been
dealing
with
are
largely
around
push
rules,
so
push
rules
being
where
the
organization
can
control
how
changes
are
being
made
to
production.
As
far
as
like
does
the
commit
message
have
to
be
prefixed
or
meet
some
particular
pattern.
A
Does
the
the
author,
I
believe
or
the
others
email
have
to
match
their
domain,
such
as
customer
domain,
comm
and
so
they're
they're
defining
these
of
the
instance
level,
but
the
problem
that
we
run
into
is
that
they
like
it
generally,
but
every
group
and
project
can
be
different.
So
there's
usually,
let's
say
80%
of
projects
are
subject
to
some
strict
policy,
but
then
the
other
minority
percentage
shouldn't
have
those
same
strict
level
of
requirements,
and
so
there's
that
balance
that
can't
happen
right
now,
because
it's
either
all
or
nothing.
A
So
all
groups
and
projects
are
subject
to
these
things
or
they're,
not
as
my
understanding
so
we're
bringing
some
of
these.
So
we
just
brought
this
we're
in
the
process
of
bringing
this
to
the
group
level.
We
encountered
an
issue
when
trying
to
implement
it.
It
was
a
performance
consideration,
so
we're
navigating
that
and
that's
maybe
worth
exploring
as
well
as
we
bring
some
of
these
things
to
the
group
level
for
gitlab
comm
and
better
control
for
self-managed
customers.
There
may
be
those
performance
considerations
elsewhere.
The
other
area,
let's
see
I,
want
to
say.
A
This
one
I'm
looking
at
right
now,
because
this
is
the
the
feature
that
I
believe
Sid
came
down
and
said:
hey.
We
shouldn't
support
this,
because
this
is
counter
to
velocity.
It's
not
very
efficient.
The
end
of
this
there
is
customers
have
pipelines
that
they
want
to
run
regardless.
They
say:
hey
here's
this,
like
parent
or
default
pipeline,
that
should
run
for
every
single
merger
quest
or
deploy
to
production.
That's
ever
done,
but
developers
or
maintainer
should
be
able
to
amend
different
like
additional
pipelines
or
jobs
to
that.
A
So
they
have
this
like
parent
pipeline,
that
that
has
to
run
across
all
projects,
let's
say,
but
then
there
should
be
flexibility
to
support
localized,
maintainer
x'.
To
add
to
that,
and
so
right
now
we're
building
a
case
to
justify
like
hey.
We
should
empower
customers
to
be
able
to
do
this
thing
if
they
want
to
be
less
efficient.
That's
their
decision.
That's
not
our
place
to
be
prescriptive
necessarily,
but
this
is
one
area
that
we're
trying
to
figure
out.
How
do
we
bring
this
to
the
group
level,
which
is
the
ask
like
hey?
A
C
On
that
one,
so
so
the
things
that
we're
Amanda
and
I
are
trying
to
understand
is
the
gap
between
three-pointers
and
see
segments
in
that,
maybe
something
like
hypothetically
say.
This
is
like,
if
you,
if
you
drop
this
to
the
group
level
and
a
group
owner
can
do
it,
does
that
give
them
too
much
control
over
it.
We're
trying
to
look
for
that
like
what
are
things
that
like
we
don't
necessarily
want
to
drop
them
down
to
the
group.
C
I,
don't
know,
because
there
might
be
like
a
lot
of
three
points,
and
you
might
not
want
every
single
group
owner
to
be
able
to
do
this.
Well,
what?
If,
if
you,
if,
as
you're
kind
of
talking
about
these
things,
if
anything
with
like
oh
I,
wish
I
wish,
there
was
like
that
sort
of
middle
ground
where
we
could
like
enable
customers
to
do
this,
but
not
have
it
doe
open
they're
like
the
whole
customer,
every
single
group
owner
that
exists,
because
I
feel,
like
a
group
owner
permission,
is
exactly
that.
C
It's
two
owner
group,
whereas
it's
not
it's
not
necessarily
like
the
original
goal
about
wasn't,
who
administrate
something
it
was
to.
It
was
to
own
the
group
specific
when
there's
kind
of
more
to
it
than
that
so
yeah.
If
there
is
anything
like
that
that
pops
up
like
when
you're
talking
savings
like
a
really
helpful
to
know
after
the
we
consider
it
like
as
we're
animate
board
with.
A
No,
it
makes
perfect
sense.
I'd
have
to
maybe
go
back
through
some
call
notes,
but
I
can
tell
you
just
anecdotally
without
like
hard
quotes
or
data
points
to
refer
to
off
the
top
of
my
head,
that
that
is
a
underlying
problem
or
need
so
forget
for
self-managed
customers.
I
think
that
that
concern
is
valid
because
in
self-managed
you
have
access
to
admin.
But
if
we
bring
to
the
group
level,
then
that's
where
you
need
it
the
ability
to
lock
down
like
well.
A
We
don't
want
group
owners
to
have
this
because
we
as
admins
can
already
do
it.
Forget
lab
comm
it's
different
because
they
don't
have
access
to
that
elevated
admin
role.
So
to
your
point,
yes,
there
is
a
requirement
for
a
middle
ground
role
at
that
point.
So,
first,
if
I
had
a
delineate,
I
would
say
for
self-managed
customers
bringing
things
under
the
group
level
is
primarily
about
ease
of
use
and
configuration
and
managing
management,
overhead
of
the
groups
or
I.
A
C
Would
be
thank
you,
that's
very
helpful.
It
would
be
really
cool
if
we
could
somehow
like
label
these
issues.
It's
something
it
just
says.
This
is
the
indicates
like
hey.
This
is
something
that
we're
thinking
about,
but
it's
a
feature
that
would
be
great.
Would
you
Jenna
fit
from
having
this
additional
workspace
administrator
role
like
weather
later
BRR
it'd
be
good
to
be
able
to
have
identify
what
the
issues
are
as
you
working
on
them,
I.
B
A
As
an
interim,
I
could
probably
go
back,
at
least
from
my
planning
issues
and
compile
a
list
somewhere
for
you.
That
says,
hey
of
these,
let's
say
fifteen
you
spread
across
the
last
three
milestones
here
are
the
ones
that
I
think
could
be
in
part
or
in
whole
solved
by
that
worked.
Workspace
administrator
role,
be.
A
A
Think
those
are
the
big
ones
right
now,
so
the
compliance
group
added
this
section,
the
credentials
menu
item
to
bring
visibility
into
the
personal
access
tokens
and
SSH
keys.
The
intent
is
to
add
additional
secrets,
such
as
deployed
keys
or
anything
else
that
or
at
least
metadata
about
those
credentials
that
a
group
owner
administrator
once
visibility
into,
but
we're
still
kind
of
learning
and
validating
what
those
additional
ones
might
be.
A
C
A
B
A
C
A
A
You
know,
for
example,
like
we
have
deployed
keys,
separate
from
credentials
like
that's
one,
quick,
win,
I
think
we
could
achieve,
but
just
seeing
all
of
this
stuff
here
and
personally,
what
bugs
me
from
a
UX
perspective
is
how
this
is
all
laid
out
like
this
is
not
very
easy
on
the
eyes.
It's
not
easy
to
digest
everything.
That's
here,
it's
difficult
to
delineate
like
when
a
section
is
starting
and
stopping
especially
with
the
different
weighting
of
the
headers,
and
things
like
that.
So
just
in
general,
like
hey,
we
should
just
revamp.
C
C
B
A
A
Think
so
I
think
it's
kind
of
like
the
to-do
page
I
think
we
all
just
kind
of
add
stuff
to
it
and
do
our
best
to
make
it
a
unified
experience
which
I
think
we
generally
rely
on
like
the
UX
and
valid
solution.
Validation
processes
that
help
us
with
that
I,
don't
know
Luka
or
Dhruv.
You
have
a
different
perspective.
There.
A
But
if
not
I'll
continue
at
this
real
quick,
so
another
thing
we
added
that
I
can
explain
is
the
minimum
password
length.
There
was
a
lot
of
debate
about
helping
organizations
enforce
password
entropy
password
entropy
is
essentially
the
idea
that
the
complexity
of
a
password,
all
things
considered,
uppercase
lowercase
special
characters,
length
of
the
password,
all
of
those
create
an
output
value
and
that
output
value
is,
let's
say,
64,
and
that
is
the
entropy
of
the
password
or
the
strength
of
it.
A
We
went
with
minimum
password
length
as
an
MVC
first
iteration
management's
perspective
on
this
was
basically
like.
Well,
this
is
we
should
make
it
simple
best.
Practices
according
to
nist
are
to
keep
it.
You
know
basically
a
long
and
complex
password
without
specifying
what
complex
is
but
we'll
be
eventually
adding
to
this
to
say.
Well,
if
you
as
an
admin
once
you
optionally,
require
a
minimum
number
of
capitals,
numbers
special
characters
that
are,
you
should
be
able
to
do
that.
So
right
now
that
lives
in
sign
up
restrictions
which
I
don't
know.
A
If
that's
necessarily
the
most
makes
the
most
sense,
but
that's
one
area
I
can
provide
insight.
I
think
the
only
other
section
I
can
really
speak
to
that
we've
added
to
or
dealt
with.
Is
this
so
a
big
issue?
That's
a
headache
for
many
customers,
I
think,
there's,
probably
a
dozen
or
so
issues
open
that
are
maybe
related
in
some
way
is
tied
into
the
concept
that
particularly
on
gitlab
comm,
we're
looking
to
bring
these
settings
to
the
group
level.
A
I
think
these
two
in
particular,
because
right
now,
if
an
organization
says
hey
developer,
I
want
you
to
be
able
to
go
like
they
have
this
setting
right
that
developers
and
maintainer
can
create
projects,
but
then
their
default
branch
protection,
which
I
believe
forget,
lab
comm,
is
set
by
us
as
the
company
is
set
to
fully
protect
it.
So
that
says,
only
maintainer
x'
can
push
new
commits
so
on
get
lab
comm
a
developer
creates
any
project,
but
they
can't
initialize
it
with
a
readme
and
that's
exposed
as
an
option.
A
So
that's
one
UX
breakdown
or
expectation
breakdown
that
they
can't
initially
do
the
readme,
but
then
they
also
can't
push
the
first
commit
because
the
default
branch
protection
kicks
in
so
when
they
go
to
try
to
push
that
commit
only
maintainer.
X'
can
do
it,
because
now
that
feature
is
active
and
so
developers
like
well
I
can't
do
anything.
So
they
have
to
involve
a
maintainer.
C
A
A
And
so
I
think
we
discovered
that
there
is
two
primary
use
cases:
one
where
hey
we're
willing
to.
Let
our
developers
have
this
freedom
to
create
a
project,
push
some
code
and
then
we
as
a
maintainer
or
owner
can
go
in
later
and
change
that
default
branch
protection
to
only
allow
maintainer
x',
and
so
it's
protected
from
there
forward
the
night.
The
good
thing
about
bringing
these
to
the
group
level
is,
you
can
do
like,
and
let
me
know
if
this
context
isn't
helpful.
A
I
I'm
just
trying
to
navigate
that
like
bringing
stuff
to
group
level
or
not
the
nice
thing
about
bringing
this
to
group
level.
Is
you
can
say
well,
if
I'm
a
fairly
flexible
organization,
I'll
let
developers
and
maintainer
x'
create
projects
and
I'll.
Let
developers
also
push
new
commits
if
you're,
pretty
conservative
as
an
organization
and
real
risk-averse,
you
can
say
well,
I
only
want
maintainer
is
great
projects
and
I
only
want
maintainer
to
be
able
to
push
new
commits,
and
so
you
have
these
like
pseudo
grounds
in
the
interim.
A
Well,
we
figure
out
a
better
solution,
but
to
your
point,
Lucca,
there
is
a
separate
use
case
as
I
understand
it,
which
is
we're
an
organization
that
wants
even
more
flexibility
to
say
when
a
developer
creates
a
project,
promote
them
to
maintainer
for
that
project,
only
which
gives
them
a
lot
more
flexibility,
but
that's
not
desirable
for
the
more
risk-averse
organizations.
I
think
both
of
these.
C
A
C
B
A
Yeah
I
think
just
generally,
all
of
this,
our
majority
of
this
probably
makes
sense
to
bring
into
the
group
level,
because
if
the
idea
is
we're
trying
to
empower
group
owners,
primarily
thinking
about
get
lab
comm
and
until
we
have
that
workspaces
admin
concept,
then,
to
me
it's
logical
to
say:
well
everything
we
give
to
admins
more
or
less
without
breaking
things.
Technically,
you
should
probably
be
available
to
group
owners
is.
C
A
C
C
In
terms
of
priority
right,
so
there's
like
so
much
stuff,
it's
just
about
like
hey,
we
really
just
need
someone
else
to
be
able
to
own
this
workspace
level
or
whatever
we're
going
to
call
it,
but
maybe
he
makes
me
consider
like
what
do
we
do?
First,
like
what
did?
What
is
the
priority
in
terms
of
how
he
iterates
wards
like.
B
A
And
I
think
to
answer
your
original
question
there.
As
far
as
is
there
any
concern
over
what
settings
are
wearing
down,
I
would
have
to
go
through
and
do
an
audit
excuse
me,
but
I
think
the
general
rule
of
thumb
would
be
that
any
setting
in
here
that
was
originally
designed
to
apply
to
all
groups
on
the
SAS.
A
Offering
is
probably
something
that
we
would
want
to
pause
like,
for
example,
if
I
look
at
even
just
this
default
projects
limit
I
don't
know
if
it
makes
sense
to
have
that
be
an
unbounded
value
for
a
gitlab
comm
customer
for
self-managed.
Fine,
because
that's
their
resources,
that's
their
computing
power
and
their
cloud
infrastructure,
but
forget
lab
comm,
that's
our
infrastructure
and,
if
there's
a
use
case
where
they
need
more
than
a
thousand
projects
like
that's,
probably
something
that
should
be
sussed
out.
A
C
D
Couple
of
things
that
I
can
see
being
potentially
a
problem
or
something
we
at
least
need
to
work
through
I
know
right
now.
A
lot
of
these
settings
in
the
admin
area
are
just
defaults
and
can
be
overridden
at
a
group
and
project
level.
Push
rules
is
a
good
example
by
sending
push
rules
in
the
admin
area,
you're,
not
restricting
these
things
indefinitely.
D
C
I
was
that's
a
really
helpful
people.
I
didn't
know
that
I
didn't
know
that
they
were
just
saying
deep
thoughts.
I
thought
it
was
like
enforcement.
So
one
of
the
things
that
the
the
access
group
are
working
on
group
managed
accounts
right
now.
So
that's
one
problem
that
we're
trying
to
solve
just
for
from
an
authentication
right
so
like
when
you
can
only
use
set
like
how
people
can
can
log
into
its
a
group
I'll
get
up,
but
one
way
that
we've
considered
like
iterating
towards
more
of
a
more
of
an
isolated
kind
of
enterprise.
C
Experience
is
allowing
and
getting
up
on
customers
to
be
able
to
enforce
I
think
like
brothers,
like
it's
there
and
people,
and
then
people
underneath
that
can't
change
it.
So
it's
kind
of
an
interesting
point
to
like
know,
even
as
I've
been
like
one
of
the
things
that
actually
like
do
we
want
to
start
thinking
about.
How
do
we
enforce
settings
rather
than
like?
How
do
we
just
set
default?
Maybe
that
maybe
you
can
do
Barry's
I,
don't
know
well.
A
And
to
that
point
there's
be
the
last
thing
is
I
gotta,
hop
off
I
think,
but
this
I
think
touches
on
it.
So
we
release
this
in
twelve
eight
or
will
be
releasing
and
I
think
it
achieves
something
related.
So
in
the
admin
area,
we
added
these
three
project
settings
from
merge,
request
approvals
and,
if
enabled
by
an
admin
there
in
the
admin
panel,
then
at
the
project
level
they
become
unmodifiable
for
any
non
administrators,
and
that
was
a
major
ask
to
both
your
points
that
there
needs
to
be
an
enforcement
piece
to
it.
A
If
the
administrator
customer
decides
that's
the
case,
but
that
should
also
be
flexible
enough,
that
they
can
toggle
that
behavior
so
I,
don't
know
how
that
manifests.
If
it's
a
yes
enforce
this
everywhere
or
if
it's
only
enforces
for
slow
selective
groups,
which
is
one
feedback
we
got
which
is
hey,
this
is
a
little
too
broad.
We
need
to
be
able
to
select
what
groups
this
applies
to
or
which
ones
should
be
exempt
from
it.
I
mean.
C
If
it
was
like,
you
know,
I
tend
to
try
and
steer
away
from
additional
config
but
like
even
if
there
was
just
a
way
to
say
like
this
is
either
enforced
or
default.
They
give
its
default.
Then
it's
changeable
at
the
group
project
level.
If
it's
enforced,
then
it
can't
be
changed
at
all
and
then
maybe
you're
able
to
do
that,
like
the
intense
level
or
the
workspace
level
with
a
great
level
and
just
allow
more
angular
RTO
to
how
people
are
actually
managing
at
work
and
yeah.
A
Let's,
let's
definitely
reconnect
because
there's
another
issue
I'm
working
on
for
two-person
approvals.
So
if,
for
example,
one
use
case
is
this,
if
I'm
an
admin
and
I
enable
these
settings,
but
then
a
maintainer
is
like
no.
This
doesn't
apply
to
my
project,
we're
trying
to
build
an
experience
where
the
maintainer
can
unsolicited,
but
it
generates
kind
of
an
approval
request.
A
D
This
is
good
to
think
about
and
in
a
way,
I
kind
of
see
that
the
admin
level
settings
are
sort
of
like
a
part
of
the
group
hierarchy.
It's
a
little
bit
like
the
admin
settings
are
the
top
level
of
a
group
sub
group
setting
hierarchy.
So
maybe
whatever
we
come
up
with
at
the
group
level,
I
mean
we're.
Gonna
have
to
understand
how
that
hierarchy
affects
those
settings
for
groups.
So
then
maybe
that
can
be
extended
to
that
as
well.
B
B
C
B
D
C
D
C
Well,
let
let's
assume
that
we
have
something
big
slightly
bigger
than
a
group,
but
not
as
big
right,
so
we
have
kind
of
a
new
container
and
that
then
allows
enterprises.
You
decide
to
use
Dom
or
if
they
have
a
self-managed
instance,
they're
able
to
kind
of
start
siloing,
like
departments
like
from
each
other,
if
they
want
to
use
the
same
instance,
but
not
necessarily
have
those
departments
overlap.
We
have
one
large
customer
that
it's
asked
this,
but
yeah.
C
If
the,
if
there's
anything
that
you're
I
mean
back
to
my
earlier
question,
like
as
a
support
person,
I
know,
there
are
some
pain
points
where
you're,
like
I,
really
wish
that
customers
were
able
to
do
this
themselves
rather
than
support
folks
having
to
do
this
for
them.
That
was
the
two
factor
point
that
I
mean
and
then
yeah,
if
just
as
your
experience
like
watching
like
self-managed
admin
and
hey,
if
it
would
be
beneficial
like
to
have
as
a
at
the
additional
role
level,
that
would
be
interesting.
You
know.
D
Yeah
I
do
think
a
lot
of
this
could
could
be
moved
to
a
different
level.
A
couple
of
high
level
things
I
mentioned
the
confusion
or
lack
of
understanding
about
which
settings
are
enforced
versus
just
being
a
default.
That
calm
is
some
confusion
and
then
some
of
the
settings
at
a
group
level
for
self-managed
customers.
They
don't
want
group
owners
to
have
that
level
of
control
that
LDAP
piece
being
one
of
them.
C
One
thing
that
we've
focused
on
quite
a
bit
in
our
research
so
far
is
user
management.
It's
really
hard,
but
a
group
owner
today
I
wouldn't
manage
in
that
I
create
manage
and
delete
users.
They
can't
do
that
right
now.
They
can
only
invite
people
which
is
kind
of
a
big
pain
point
for
a
lot
of
smooth
that
decide
not
to
use
that
reason.
I
wonder
if
you
have
any
thoughts
on
that.
D
Yeah
I
think
that
that's
a
huge
issue
for
dot-com
customers
for
self-managed,
maybe
not
as
much
although
having
that
feature
exposed
for
some
finished
customers,
might
be
beneficial
in
a
larger
enterprise
that
has
a
little
bit
more
autonomy
in
in
smaller
groups.
So
maybe
letting
you
know
Department
level,
a
department
level
maybe
has
their
own
similar
or
LDAP,
and
they
want
to
manage
their
own
user
set
compared
to
another
department.
Yeah.
C
C
D
D
Yeah,
you
wouldn't
want
to
give
a
group
owner
the
ability
to
delete
a
user.
That
is,
you
know
not
just
in
their
group
even
within.
Like
me,
as
an
employee
of
gitlab,
you
can
even
say
maybe
that
get
loud
wants
to
be
able
to
manage
my
accounts
and
leave
the
company.
They
want
to
delete
my
user,
but
if
I
also
have
like
personal
projects
or
personal
groups
outside
of
that,
that
could
potentially
be
destructive.
D
C
D
D
D
Some
other
things
that
I've
seen
organizations
want
to
do
in
a
global
level
is
like
integrations
with
other
systems
that
they
use
and
want
to
configure
JIRA
integration.
At
the
instance
level,
Jenkins
I
think
that
there
is.
There
are
a
lot
of
customers
that
that
wanted
that
pipeline
enforcement
feature.
That
Matt
was
was
showing
earlier.
D
Yeah
I
think
that
there
are
a
lot
of
dog
home
customers
that
are
missing
a
lot
of
those
features.
I
mentioned
just
how
vast
the
settings
are
in
the
admin
area,
and
you
know
compared
to
a
group,
no
comparison.
There
are
some
things
that
we
probably
don't
want
that
to
take
out
of
the
admin
area
down
to
a
group
level.
I,
don't
know
exactly
what
those
are
at
the
moment,
but
there
probably
are
some
yeah.
D
C
C
Turnoff
registration-
they
might
not,
maybe
they
don't
want
people
to
be
able
to
register
for
a
group.
I,
don't
even
know
how
you
would
go
about
doing
that
now,
like
you,
can
only
invite
people,
and
so
it's
not
really
a
problem,
but
I
shall
see
it
may
be
becoming
one
in
return
on
I.
Don't
know!
If
that's
something
that
you
need
to
think
about
me
sure
like
if
they
have
you
go
to
like
customer
or
calm,
and
they
have
their
own
registration
or
signup
page
that
just
registers
them
for
that
workspace
or
group
or
whatever.
C
We
need
to
be
able
to
allow
them
registration
if
they
don't
necessarily
what
they
want.
More
control
over,
like
the
amount
of
users
that
they
have,
for
example
like
at
the
moment,
I
know
that
the
growth
could
partner
working
on
implementing
a
new
way
of
charging
easily.
So
when
a
when
a
group
owner
decides
that
they
want
to
add
users,
it
just
feels
like
credit
cards
like
at
the
time
of
adding
them
so
like.
If
people
are
able
to
register,
then
that
takes
the
autonomy
away
from
filling
up.