►
Description
Slack: #wg_simplify-groups-and-projects
Working Group Page: https://about.gitlab.com/company/team/structure/working-groups/simplify-groups-and-projects/
Update Issue: https://gitlab.com/gitlab-org/gitlab/-/issues/254991
B
Well,
so
I
am
going
to
give
justin
a
little
challenge
and
we're
going
to
see
how
it
goes.
Part
of
this
is
to
help
illustrate
some
of
the
concepts
that
the
simplified
groups
and
project
working
group
has
been
thinking
through.
So
the
basic
scenario
is
this:
there's
bob
and
he
needs
you
to
help
plan
his
project.
B
The
project
was
requested
by
ralph
who's.
The
project
sponsor
slash,
executive
bob
is
a
project
manager,
sorry
typo,
and
he
also
has
on
his
team,
jane
tom
and
taylor,
and
so
the
basic
objective
is.
This
ralph
brings
an
important
business
goal
to
a
project
team.
He
explains
the
goals,
business
rules
and
a
high
level
overview
of
the
three
big
modules
that
need
to
be
completed.
B
Ralph
also
gives
the
project
team
access
to
three
factories
that
can
be
tooled
to
produce
the
necessary
components
for
the
three
modules
raf
ralph
tasks,
bob
with
creating
a
project
plan
and
executing
against
it.
Given
the
business
rules,
bob
is
a
bit
stuck
with
where
to
go
and
has
come
to
you
to
ask
for
help.
How
would
you
coach
him
towards
getting
a
project
plan
in
place?
B
So
this
is
what
prop
project
yep.
This
is
what
project
success
looks
like
there's
these
three
modules
and
they
each
require
some
components
to
be
built.
They're,
color,
coded
and
you'll
kind
of
see
why
in
a
second,
but
they
all
come
from
different
factories
different
places,
they
all
need
to
be
combined
and
assembled
into
these
modules.
There's
also
some
dependencies
where
a
red
component
cannot
be
built
until
all
the
necessary
yellow
components
are
done.
First
and
a
purple
component
cannot
be
built
until
the
necessary
blue
components
are
done.
First,
questions.
A
B
Not
by
any
factory,
so
this
was
where
again
in
the
factories,
each
factory
has
a
color-coded
workstation,
where
the
widgets
or
components
have
to
be
built.
Okay
and
the
basic
rule
is
we'll
get
into
business
rules
a
second,
but
each
factory
can
coordinate
with
their
workstations
workstations
is
where
the
components
or
widgets
get
built.
A
B
B
So
the
reason
for
that
is,
each
factory
invoices
the
project,
each
workstation
factory
invoices
the
project
for
the
parts
it
uses
all
right.
A
workstation
requires
a
workflow
and
quality
standards
to
be
talked
about.
Factories
can
coordinate
with
their
workstations,
but
not
with
each
other,
and
the
project
plan
that
bob
creates
must
live
within
a
factory
and
be
visible
to
ralph.
So
ralph
could
track
the
overall
progress
without
relying
on
daily
updates
from
bob
and
then
lastly,
number
five
we
kind
of
talked
about
dependencies
before
module
can
be
assembled.
B
A
A
I
interact
with
the
question
yeah
back
to
your
slide.
Four
are
there,
so
are
there
components
that
I
have
to
build
the
oh
yeah,
okay,
so
they're
components
that
can
only
build
in
one
factory
that
have
a
dependency
on
components
that
are
built
from
a
completely
different
factory,
correct
and
business
releases.
They
can't
talk
to
each
other,
correct,
okay.
This
is
like
bringing
me
back
to
like
the
sats,
where
I
do
like
hard
work
problems.
B
Okay,
so
the
first
thing
bob
does
to
get
started.
Is
he
realizes
that
you
can
create
a
basically
a
workflow
and
a
set
of
standard
qualities?
That
is
true
for
all
components
and
every
component,
when
it's
being
built,
can
go
through
the
same
workflow
process
and
each
component
follows
the
same
quality
standards.
B
But
each
of
the
workstations
has
to
be
configured
manually
because
that's
the
way
that
the
factories
work
and
each
each
time
it
takes
about
a
day
to
configure
each
workstation
with
the
workflow
and
the
quality
standards
which
are
really
the
same
across
all
of
them,
and
so
he's
gotten
this
far
and
now
he's
not
really
sure
what
to
do
next.
Does
that
make
sense
yep
all
right
so,
given
each
station
requires
a
work
order?
Where
would
you
tell
bob
to
create
his
work
orders
for
the
different
components.
A
B
A
A
Yeah
and
sorry
go
back
to
the
question
number
eight
or
slide
eight
specifically
very
quickly,
reverse
different
components.
I
mean,
I
guess,
you'd
create
the
work
order
at
the
factory
level
or
the
widget
level
he's
gonna
have
to
do
it
manually
for
each
one,
which
is
tedious
right
and
anytime.
You
said
they're
all
the
same
or
it's
the
same
construct
for
all
of
them.
So
it's
also
tedious
if
he
has
to
change
something
at
some
point.
A
A
B
A
Yeah
I
figured
this
question
was
coming
and
I
was
like
brain
was
melting,
trying
to
figure
out
what
to
do,
because
your
project
plan
really
should
be.
I
mean
if
you
go
up
a
slide
like
this
is
kind
of
your
project
plan
like
in
a
visual
representation
like
you
need
each
of
these
modules
to
exist
to
call
the
project
complete,
but
those
modules
consist
of
work,
that's
created
in
different
factories
and
with
the
dependency
model,
there's
dependencies
that
traverse
those
factories.
A
So
it's
like
I
I
don't
know
like
I
don't
know.
My
like
naive
answer
is,
like
you
have
to
do.
A
lot
of
duplication
like
you'd
need
to
create
the
project
plan,
the
same
project
plan
in
factory
a
b
and
c
so
that
you
have
the
visibility
of
those
dependency
maps,
but
then,
as
soon
as
something
changes
in
one
factory
like
a
status,
changes
in
one
factory
like
widget,
one
blue,
widget
got
completed
or
whatever,
like
factory
c,
is
not
going
to
know
that
or
what's
different
dependency
map.
A
B
A
Orders
like
it's
going
to
create,
maybe
even
create
more
of
a
bottleneck,
because
this
project
plan
is
only
in
one
place,
but
those
factories
need
to
operate
off
of
something
and
so
he's
having
to
manually
create
those
work
orders
constantly
where,
if
you're
building
it's
a
naive
example,
if
you're
building
like
five
yellow
widgets,
you
shouldn't
have
to
like
constantly
have
to
copy
and
paste
and
move
stuff
over
sub-optimal
either
direction.
You
go.
I
guess
so.
It's
like
either
duplicate
them
across
all
factories
or
put
them
in
one
factory.
B
B
B
A
Well,
I
would
probably
make
it
so
that
I
would
combine
all
the
factors
into
one
right
and
make
it
so
that
each
factory
can
produce
the
same
widgets.
You
could
also
create
like
a
parent
factory.
I
guess
that
has
that
contains
the
child
factories
and
then
have
the
project
plan
live
there
and
have
like
a
configurable
workflow
layer
that
then
gets
auto,
updated
below
you
know,
but
in
some
way
like
you
can't
have
you
need
to
break
either
change
it.
So
you
don't
have
the
hard
boundaries
between
each
factory.
B
B
B
Okay,
cool,
so
that's
kind
of
the
next
question
is:
if
you
can
change
anything
about
the
behavior
factories,
including
adding
new
contracts
or
layers
to
help
you
solve
the
problems
of
having
a
single
source
of
truth
project
plan,
what
are
some
things
you
might
try
to
change?
We
talked
about
a
few
of
them.
Was
there
anything
else?
If
you
could,
if
you
literally
do
anything
here
to
make
it
so
you
could
have
a
single
source
of
truth.
What
would
you
do.
A
An
individual
workstation
or
a
factory
of
itself
like
if,
if
maybe
maybe
the
better
question,
is
like.
What's
the
point
of
the
factories
like?
Could
we
just
have
a
single
factory
that
was
able
to
contain
the
project
plan?
The
quality
standards,
the
workflow,
since
those
are
all
duplicate,
duplicative
and
then
the
individual
workstations?
Just
hang
off
of
that
to
simplify
it.
The
other
thing,
if
we
didn't
do
that,
I
would
make
it
so
that
these
things
can
interrupt
better
right
like
break
the
rule
or
the
business
rule.
A
That
says
they
can't
talk
to
each
other
and
make
it
so
that
these
things
aren't
so
specialized
that
they
have
the
ability
to
to
communicate
with
each
other
and
report
back
either
status
or
a
change.
I
think
you
still
need
to
move
the
quality
standards
and
workflow
up
a
level.
That's
probably
an
unstarter,
but
if
you
still
had
some
separation
for
some
reason,
you
need
a
way
to
like
break
through
that,
like
punch
through
the
firewall
and
enable
them
to
communicate
with
each
other
yeah.
B
Where
the
in
order
to
complete
the
project,
you
have
to
have
work
that
spans
a
zone
a
which,
maybe
might
have
the
workflows.
For
you
know
the
single
workflows
for
all
the
different
factories
and
whatnot,
and
then
zone
b
also
has
factories
and
widget
stations
and
all
that
stuff,
and
you
need
to
figure
out.
Ralph's
boss
wants
to
see
when
the
project
is
going
to
be
done.
Yeah.
A
So
he
needs
to
punch
in
deeper
yeah
there's.
I
I
see
it
as
two
things,
one
you
could
continue
to
add
wrappers,
but
I
don't
know
how
far
you're
going
to
take
me
down
that
rabbit
hole
of
like
no
now
ralph's
boss
has
a
boss
and
ralph
spots,
his
boss's
boss's
boss,
so
but
whatever
like.
Maybe
a
path
is
that
now
you
have
a
more
like
a
super
parent
grandparent
rapper
here
that
combines
zone
a
and
b.
A
A
Viewed,
edited
updated,
kept
up
to
date,
agnostic
of
where
it
belongs,
and
that
way
ralph
his
boss,
his
boss's
boss,
bob
et
cetera,
have
all
have
access
to
it,
but
then,
at
the
same
time
it
needs
to
be
able
to
push
work
orders,
I'm
assuming
work
orders
into
the
individual
factories
and
the
individual
workstations
in
zone
a
or
zone
b.
It
also
needs
to
know
the
outputs
or
the
the
success
or
failures
of
the
creation
of
the
widgets
from
each
workstation
as
well.
So
there
needs
to
be
connection
there.
A
B
A
A
A
A
a
subset
of
a
much
larger
project
plan
to
exist
with
some
independence,
whether
it's
under
a
factory
or
under
the
zone
in
zone
a
or
whatever,
but
him
be
able
to
see
the
other
project
plan
or
the
other
parts
of
the
project
plan
that
he
can
see
and
be,
and
let
those
two
things
talk
to
each
other,
because
I
assume
the
reason
why
he
has
visibility
into
some
part
of
b.
Is
that
that's
where
a
dependency
lives
right
yep?
A
A
B
B
So
how
does
this
apply
to
gitlab
like
if
and
the
things
that
we're
trying
to
solve,
as
you
think
about
like
a
zone,
sounds
like
a
group
right
right
now.
Factory
is
a
subgroup.
Let's
say
that
a
workstation
is
a
project
and
these
all
have
slightly
different
behaviors
and
so,
like
one
of
the
things
that
we
don't
do
in
gitlab
anywhere.
Is
factories
can't
talk
to
each
other?
Workstations
can
never
talk
to
each
other.
Zones
can
never
talk
to
each
other
about
anything
period.
B
We've
been
spending
some
time
thinking
about
how
to
solve
for
this,
but
we
also
like
to
put
some
initial
constraints
on
whatever
solution
we
would
come
up
with,
and
one
of
them
would
be
like
iterating
on
existing
organizational
constructs.
So
take
what
we
have
and
make
it
better,
don't
just
build
something.
New
second
constraint
was
delivering
tangible
customer
value.
Every
release,
so
don't
go
in
a
hole
for
a
long
time
and
build
something
new
and
then
basically
number
three
for
somebody
or
customers
to
migrate
into
this
thing
or
cause
a
bunch
of
disruptions.
B
So
another
constraint
is
no
migrations
or
disruptions
for
end
users,
and
then
the
fourth
constraint
was
no
hard
requirement
for
ui
changes
except
those
that
will
improve
overall
usability
to
drive
sus
improvements
so
like.
How
can
we
fix
all
these
problems
without
also,
at
the
same
time
requiring
us
to
make
a
substantial
amount
of
ui
changes?
B
So,
even
if
you
were
to
make
everything
kind
of
work
and
from
that
standpoint,
at
some
point,
you
will
get
to
the
level
where
an
instance
can't
talk
to
another
instance,
which
you
can
consider
just
like
a
zone
so
like
that
kind
of
is
a
is
a
like
hard
constraint
due
to
the
way
like
in
terms
of
how
far
you
can
scale
the
thing.
So
the
first
thing
that
we
talked
about
doing
was
you
know:
groups
have
certain
features,
projects
have
certain
features.
You
said
it
earlier
like.
B
We
can
call
it
whatever
we
want
in
the
code
doesn't
matter
and
what
this
does
is
it
lets
us
wrap
a
group
with
this
new
kind
of
construct,
that's
completely
invisible
to
the
end
user
and
create
a
kind
of
project.
That's
also
invisible
but
then
start
to
expose
features
like
a
wiki
within
the
group
right.
So
the
the
job
of
the
space
is
basically
to
resolve
resources
from
a
project
or
group
that
or
both
live
within
the
space.
B
A
Can
I
ask
a
question
yeah
just
to
clarify
so
you're
using
your
example
from
our
exercise
earlier
in
in
this
world?
This
would
solve
for
the
problem.
Where
say
the
individual
factories
can't
talk
to
each
other
and
and
turn
the
individual
workstations
can't
talk
to
each
other.
If
they
were
all
part
of
this
space,
then
ostensibly
they
could
communicate
with
each
other,
because
they're
part
of
this
invisible
to
them.
They
they
still
are
a
factory.
A
B
Not
not
quite
there
yet
with
this
illustration
think
about
this
is
like
I'm
going
to
create
a
widget,
basically
workstation
inside
of
the
factory,
but
it
like
it's
basically
putting
a
workstation
inside
the
factory
level.
So
if
we
want
to
create,
let's
say
a
work
order
and
we
want
to
have
a
widget
workstation
and
it
all
lives
at
the
factory
level
and
not
below
it,
so,
okay.
So
instead
of
like
having
two
disparate
things,
you
can
now
have
one
thing
that
does
all
the
things
within
the
factory.
So
it's
first.
A
B
B
Yeah,
so
we're
not
creating
anything
new
we're
basically
taking
what
is
a
workstation
behind
the
scenes
and
and
exposing
the
features
within
it
available,
so
that
the
the
factory
or
the
group
can
use
them
cool
and
so
continuing
down
this
example
and
gitlab
speak.
You
could
do
this
with
wiki
approval
rules,
issues.
Those
are
all
things
that
customers
were
requested
at
the
group
level.
So
once
you
kind
of
like
do
this
within
the
group,
you
then
inverse
this
and
you
do
this.
B
What
what
is
the
workstation
level,
so
you
wrap
a
workstation
or
a
project
to
get
loud,
speak
with
a
space,
and
then
you
create
a
shadow
or
behind
the
scenes
group
or
factory.
So
what
we're
essentially
doing
is
making
eventual
parity
between
what
would
be
a
group
and
a
project
or
a
factory
workstation.
So
there
is
no
difference
between
them.
We're
not
really
addressing
the
communication
across
them
right
now,
but
just
make
like
working
towards.
There
is
no
difference
between
a
factory
and
workstation
because
they
can
both
all
do
the
same
thing.
A
Right
so
solves
problem,
one
where
bob's
at
the
bob
love
before
you
added
the
ralph's
boss
right
correct.
This
allows
bob
to
much
more
easily
report
to
ralph
this
and
ralph
to
see
what
the
status
of
the
project
is
to
know
what
components
are
working
well
without
which,
with
each
other
excuse
me
where
the
dependencies
lie,
et
cetera,
et
cetera,.
B
That
sort
of
thing,
so
eventually
you
can
remove
what
we
currently
call
a
factory
or
a
workstation
and
call
it
something
new,
because
it's
not
quite
a
factory.
It's
not
quite
a
workstation,
it's
more
like
a
combined
super.
I
can
do
anything
within
this
space
kind
of
thing
and
we're
not
making
decisions
about
what
it
should
be
called
in
the
product.
At
this
point,
we're
just
using
this
as
a
placeholder
to
say
it
can
be
called
something-
and
this
is
where
you
know.
B
If
we
want
to
make
the
change
to
call
it
something,
and
have
it
be
the
same
thing
we
can,
we
could
leave
it
being
a
group
and
a
project,
it's
really
kind
of
up
to
what
would
this
giving
ultimate
flexibility
to
ux
to
drive
some
such
improvements
based
on
what
would
work
for
customers
without
basically
requiring
them
all
to
happen
at
the
same
time?
So.
A
Then
eventually,
so
real
quick,
though
back
one
slide
at
this
point,
or
at
that
point
you
you
don't
have
to
like
the
ui
hasn't
necessarily
changed
for
the
user
like
they
could
be
unaware
of
this
change.
Aside
from
the
fact
that
the
permissions
model
or
the
the
interrupt
between
subgroups
and
projects
is
now
much
easier
right
like
there's,
not
a
yeah
groups.
A
B
B
And
all
the
things
you
can
do
the
group
level
now
that
you
can
at
the
project
yep.
So
then
over
time.
Instead
of
having
these
shadow
things
forever,
we
start
to
extract
those
features
out
and
make
them
either
be
kind
of
more
independent
of
us
of
a
group
or
project
entirely,
or
they
basically
will
eventually
just
live
within
whatever
we
call
the
new
thing
and
we
have
all
the
features
and
it's
essentially
a
one-to-one
parity
between
what
is
now
a
group,
a
project.
A
So
long
long
term,
the
idea,
then,
is
like
groups
and
projects
sort
of
cease
to
exist,
but
because
you've
driven
parity
between
them.
With
this
invisible
object,
you
now
have
the
option
to
basically
turn
them
off
and
say:
no,
you
just
have
features
at
these
different
levels
and
then
you
construct
your
organizational
hierarchy.
How
you
want
to-
and
you
can
do
anything
at
any
level
of
that
hierarchy-
basically
yep.
B
So
another
thing
that
we've
been
looking
at
solving
is
is
like:
how
do
we
kind
of
look
at
this
now
at
the
instance
level
and
start
to
bring
some
of
these
features
that
are
the
instance
level
down
into
a
space
right,
so
it
could
be,
it
could
be
a
group
it
could.
We
could
call
it
whatever
we
want.
Let's
just
assume
it's
a
group
or
we
could
call
something
in
an
organization,
but
at
the
end
of
the
day,
it's
not
creating
a
new
object.
A
B
I
came
across
this.
Interestingly,
it's
really
just
setting
for
delayed
deletion,
so
you
can
schedule
basically
within
a
group
you
can
enable
the
ability
to
delay
deletion
of
a
group
or
of
a
project
until
a
certain
time
period.
Right
now,
it's
default
to
seven
days,
so
group
admins
can
turn
that
on
and
off,
but
they
can't
specify
the
number
of
days.
That's
an
instance.
B
You
can
continue
moving
things
in
and
then
eventually
we
can
make
an
instance,
an
identity
provider
and
so
right
now
users
belong
to
the
instance
level,
and
they
also
can
belong
to
a
third-party
external
identity
provider,
but
a
lot
of
the
stuff
that
happens
within
the
instance
itself,
and
so
whenever,
for
example,
gitlab.com
somebody
needs
to
make
some
changes.
Some
some
hamill
or
some
samwell
like
things
that
and
reset
basically
some
settings
that
only
admin
admins
could
do.
B
They
have
to
open
a
support
ticket
which
then
gets
ping
back
into,
like
you
know
the
infra
team
to
make
all
these
changes
and
to
fix
all
these
things,
instead
of
allowing
individual
folks
to
self-service
their
own
like
users,
and
so
the
idea
is
here.
Is
you
created
this
identity
provider
where
now
these
spaces-
or
you
know
kind
of
groupings
of
features,
can
use
either
gitlab's
identity
provider
for
the
users
or
they
can
also
connect
in
a
third
party
identity
provider?.
B
A
B
B
Cool,
but
what
this,
what
this
opens
the
door
for
is
allowing
us
to
do
more
or
less
federated
gitlab.
So
we'll
talk
about
like
the
the
relationship
thing
that
will
let
you
poke
holes
across
the
different
things
in
just
a
second,
but
what
you'll
eventually
be
able
to
do
is
if,
since
every
like
grouping
shares
the
same
shape,
there's
no
differences
between
the
shapes
at
all
whatsoever.
B
You,
it's,
then
makes
it
easier
to
do
geo
replication,
because
the
data
structure
is
the
same
across
all
of
them.
You
can
also
more
easily
do
federation
because
the
data
shapes
the
same
across
all
of
them
and
if
you
want
to
use
the
gitlab
identity
provider
from
an
instance,
you
can
use
that
across
all
instances.
So
like
you
could
use
one
git
lapse.
B
Instance,
I
didn't
provide
or
power
others
or
you
could
continue
to
use
like
an
external
one,
but
it
sort
of
kind
of
sets
the
stage
for
federation,
which
is
pretty
cool,
yep
and
then
the
last
thing
that
we're
still
working
on
a
little
bit
in
terms
of
an
iteration
plan.
But
it's
this
idea
where
you,
instead
of
a
strict
hierarchy,
we
create
the
ability
to
connect.
B
B
This
is
like
the
most
complex
part,
I
think,
of
the
working
group
and
we're
still
working
through
the
iteration
plan
here.
But
the
idea
is-
and
I
can
bring
up
this
kind
of
diagram
is
a
better
way
to
visualize
it.
But
assuming
you
have
these
different
spaces
and
you
have
iterations
and
epochs,
and
all
these
things
these
planning
objects
across
them,
which
you
could
consider
work
orders
from
our
example.
B
You
connect
space
a
to
space
b,
which
would
be
like
the
kind
of
factories
that
can't
talk
to
each
other,
and
maybe
space
b
wants
to
push
objects
into
space
a
and
space
a
wants
to
basically
or
space
b,
wants
to
pull
objects
from
space.
A
it's
a
it's.
It's
like
a
directed
acyclical
graph
relationship.
B
A
It
looks
like
we
through
this.
You
have
a
path
to
move
towards
a
dag
for
those
of
us
who
aren't
super
familiar
with
these
things.
Can
you
give
a
quick
high
level
overview
like
why?
Why
are
we
on
a
forced
inheritance
model
today?
What
are
the
benefits
of
it?
Why
do
we
need
to
move
to
what
is
a
dag,
and
why
do
we
need
to
move
to
it?
I
think
I
have
an
understanding,
but
I'd
love
for
you
to
talk
to
you.
B
Yep
yep,
so
the
forced
inheritance
or
the
way
that
it
works
now
is
great
because
you
can
configure
things
in
one
place
and
then
everything
downstream
can
inherit
them.
You
can
also
have
things
that
are
downstream,
that
can
kind
of
flow
upwards.
So
an
issue
is
a
good
example
right.
If
I
have
my
let's
say,
I
create
a
work
order
using
the
example
and,
and
one
of
my
workstations-
that's
immediately
visible
in
the
factory
level,
without
any
extra
work,
so
it
automatically
shows
up
there
by
default.
B
The
factory
has
visibility
into
it,
and
so
it
can
do
kind
of
roll
up
reporting
and
it
gets
notified
by
the
things
that
are
happening
downstream.
Membership
is
another
example
where
I
can
add
bob
and
his
team
to
a
factory
and
all
the
workstations
below
it
get
access
to
it
automatically,
which
is
great.
So
there's
like
a
lot
of
benefits
to
it,
but
the
the
drawbacks.
Are
you
can't,
like
factories
can't
talk
to
each
other
and
so
right?
B
How
this
is
manifesting,
yeah
and
how
this
is
manifesting
itself
in
customers,
like
a
really
simple
example
to
say,
is
we
have
three
top
level
groups
where
we
have
three
top
level
factories
right?
I
have
issues
or
work
orders,
as
I'm
assigned
to
and
each
of
my
factories
and
each
factory
can
see
them
right,
but
my
manager
bob
in
this
example.
He
can't
create
a
project
plan
and
see
all
of
the
work
orders
across
all
the
factories
in
one
board,
because.
B
B
The
problem
comes
in
the
fact
that
organizations
don't
want
to
give
bob
access
to
the
organization
level.
They
don't
want
him
to
see
everything
at
the
organization
level.
They
want
to
give
him
least
privilege
actually
access
to
just
the
things
that
he
needs
to
see
from
the
factories
that
he
needs
to
see
and
right,
which
is
why
you
have
to
have
a
different
way
of
expressing
your
relationships
across
your
factories.
B
Instead
of
just
rolling
everything
up
and
pushing
it
down,
you
need
to
have
more
flexibility
so
that
maybe
bob
creates
his
his
project
plan
and
his
products
top
level
group
which
or
group
level
right
and
then
there's
issues
in
he
gets.
He
gets
access
to
the
customer
related
thing
and
to
the
libs
thing,
and
maybe
there's
even
another
top-level
group
over
here
that
he
shouldn't
have
access
to.
B
But
this
will
allow
them
to
create
the
connection
across
these
three
so
that
the
the
basically
the
objects
or
the
issues
can
flow
freely
between
them
in
a
very
prescriptive
way,
it's
sort
of
like
the
next
iteration
of
doing
a
forced
inheritance
by
making
it
more
flexible.
So
you
still
get
the
inheritance
by
default
when
you
create
a
sub
group
or
subspace
right,
but
you
can
also,
within
your
top
levels,
be
more
expressive
about
defining
how
how
data
can
move
between
the
two
got.
It.
A
That
makes
sense.
Thank
you
any
other
questions.
I
have
one
more
meta
question.
I
guess
back
to
your
iteration
plan,
but
if
you
have
other
things
to
share,
we
could
talk
about
that.
First,
that's
it
for
now.
Okay,
so
back
to
your
iteration
plan,
if
you
don't
mind
pulling
up
the
slides
so
kind
of
like
that
first
step,
if
you
can
find
that
slide
like
I'm
curious,
the
first
iteration
yeah,
so
the
next
one
yeah
next
slide.
So
what
would
be
the
first
thing
like?
A
B
I
it
depends
on
how
much
we
get
done.
I
need
to
talk
to
engineering
about
that,
but
in
the
early
proof
of
concept
we
did
where
we
actually
created
this
sort
of
rapper
behind
the
scenes
and
created
this
phantom
project.
I
think
alex
worked
on
this.
He
spent
a
day
or
two
and
was
able
to
get
all
of
the
group
level
features
working
or
available
so
wiki's
issues
so.
A
B
He
actually
he
worked
on
a
code
and
we'll
do
a
demo
of
that
separately,
but
he
wrote
the
code
to
make
this
work
at
a
high
level.
Okay
and
it
worked
which
was
really
cool,
and
so
I
think
the
first
release
post.
We
would
target
basically
wikis,
I
think,
are
not
all
the
way
there
being
moved
to
the
group
if
they're
ready,
then
maybe
not
that,
but
issues
certainly
is
one
of
them.
Merge
request.
Approval
rules
is
another
one
that
is
been
highly
requested
by
customers.
B
B
Very
small
one
that
was,
you
could
set
environment
variables
at
the
group
level
versus
the
project
level,
that's
resolvable,
so
the
first
thing
would
be
and
I've
gotten
feedback
from
customers
is
hey.
I
have
all
my
repos
down
here
my
projects.
I
want
to
do
all
my
planning
at
the
group
level
and
right
now
I
don't
want
to
create
a
project
to
do
that.
So
just
let
me
manage
my
issues
at
the
group
level.
A
Yeah,
it
seems
like
a
that,
seems
like
a
pretty
as
the
plan
group
manager.
That
seems
like
a
pretty
nice
nice
win
for
low
effort,
so
but
you
could
think
of
it
simple
as
some
in
a
simple
way
of
like
there.
I
know
of
like
merger
quest
approval
rules
or
wikis
or
whatever,
like
there's
a
dozen
things
on
teams
backlogs
across
all
of
gitlab.
That
are,
you
know,
x,
feature
at
the
group
level.
So
it's
basically
like
ship
two
of
those
just
do
it
slightly
differently.
A
Instead
of
copying
the
functionality
from
the
project
level
to
the
group
level,
you're
applying
this
model
through
alex's
proof
of
concept,
and
then
you
ship
that
feature
but
you're
it
behind
the
scenes
of
the
customer.
It's
happened
very
differently
than
what
we've
done
in
the
past.
When
we've
done
this
type
of
work.
B
B
And
then
another
one
would
be
prioritized
labels
right
now,
so
we
have
group
labels,
but
you
can't
set
label
priority
of
the
group
right,
which
means
that
every
every
project
below
has
to
go
sort
of
like
create
your
own
workflows.
Every
project
has
to
then
go
and
configure
the
priority
labels
from
the
group
labels,
and
so
we
would
be
able
to
get
group
label
priority
labels
for
free.
B
A
You
haven't
migrated
customers
in
a
way
that
is
a
one-way
door.
Migration.
You
haven't
right,
you
have
the
and
you
have
the
ability
to
compare
like
was
that
actually
faster
and
more
efficient
from
an
engineering
perspective?
Do
we
get
the
usability
that
we
felt
like
we
would
get
because
you've
done,
we've
done
a
half
dozen
that
I'm
aware
of
types
of
efforts
where
we've
moved
features
from
the
project
to
the
group
level,
so
correct
makes
sense.
Okay,
cool!
B
Well,
thank
you
for
walking
through
this
with
me
and
being
a
guinea
pig
for
my
helping
bob
plan,
his
project
example.
I
think
it
illustrated
things
sort
of
well,
I
hope,
in
a
simple
way
and
we'll
continue
to
release
some
videos,
that
kind
of
show
some
of
these
poc
demos
and
also
try
to
kind
of
convey
some
of
these
more
complicated
things
in
a
simple
way.