►
From YouTube: Workspace Design discussion
Description
The Workspace team discuss follow up design/direction questions that came from the previous Workspace weekly meeting - https://www.youtube.com/watch?v=k8sBg4feOvU
A
A
C
So
the
reason
why
I
was
going
down
that
path
was,
I
was
looking
at
like
as
we
move
features
from
one
to
the
other,
and
if
you
play
that
out,
you
know
to
the
limit
and
there
is
complete
feature
parity
across
right.
All
things,
I'm
not
sure
at
that
point.
A
user
would
be
able
to
understand
like
you
said,
but
there
is
a
logical
order
to
them,
but
if
they
all
have,
if
they
all
have
the
same
things
like
that
logic,
order
kind
of
breaks
down.
C
A
So
one
more
thing
to
think
about,
even
if
we
get
feature
parity
between
I'm
just
going
to
first
simplifying
this
conversation,
say
groups
and
subgroups.
Whenever
I
say
groups,
that's
also
going
to
include
subgroups
okay,
so
one
distinction
between
projects
and
groups
is
the
aggregation
of
the
data
right.
A
But
on
from
the
administrative
point
of
view,
you
can
also
set
things
that
will
cascade
down
and
if
you
think
of
this
as
like
and
we're
going
more
to
the
enterprise
model,
where
the
enterprise
says
here
are
my
compliance
regulations,
every
project
must
have
xyz,
you
can
get
that
down
and
then
whatever
doesn't
comply
to
that
can
have
its
own
individual
setting.
So
I'm
gonna
just
make
it
super
simple.
A
Imagine
that
we
just
that
you
know
all
the
settings
are
the
same
besides
appearance,
so
we
can
have
a
background,
a
blue
project
and
a
green
project,
and
that
would
be
the
difference
between
the
two,
but
they
could
still
have
that
own
attribute.
That's
that
differs
between
them.
Does
that
make
sense.
D
D
A
Yeah,
I'm
gonna
touch
upon
something:
that's
not
work,
space-based,
but
it
helps
understand
and
that's
permissioning
and
the
enterprises,
especially
the
highly
regulated
industries
that
are
looking
for
least
privileges
for
people,
and
so
they
want
people
to
have
specific
privileges
in
a
specific
project
and
they
don't
want
that
to
cascade
so
that
also
the
like
separation,
I'm
going
to
say
duties,
but
it's
really
separation
projects
here
is
really
fundamental.
To
address
that
specific
use
case.
A
So
what
is
a
team?
That's
like
a
philosophical
question
and
we
don't
have
that
capability
in
gitlab
today.
We
can
totally
do
everything
that
we
want
in
workspace
and
achieve
beyond
the
nvc
without
having
a
team.
A
team
is
a
totally
different
subject,
but
in
terms
of
what
I
was
thinking
is
today,
we
don't
have
a
concept
of
a
team
at
gitlab.
So
when
you
add
members
they're
really
individual,
you
can
add
a
group,
but
a
group
is
not
a
team.
A
A
group
is
a
multiple
projects
or
at
least
one
project,
and
so
it
doesn't
translate
well
when
you're
thinking
about
a
team
of
people
and
not
projects,
I'm
going
to
give
you
again
an
example
not
from
workspace,
but
workspace
is
everything
so
so
I'm
going
to
allow
myself
one
thing
that
comes
up
from
customer
conversations
that
I've
been
having
around
value
stream
analytics.
Dora
metrics,
for
example,
is
that
high
performing
teams
they
want
them
to
have
full
autonomy
over
their
workflows.
A
So
imagine
again,
you're
in
a
highly
regulated
industry,
and
you
have
a
protocol
that
says
you
have
to
have
a
manual
sign
off
before
deployment
to
production.
Someone
has
to
manually
push
the
button,
however,
if
there's
a
team
that
has
high
performance,
because
they
you
know,
met
the
criteria
of
value
stream
or
doran
they're
like
amazing,
they
they
waiver
that
and
they
let
them
to
do
the
whole
process
automatically.
A
A
D
A
C
So
going
back
to
the
data
aggregation
line,
I
guess
I'm
just
thinking
about
it
like.
If
that
is
the
goal
of
a
group,
I
feel,
like
we've
already
extended
beyond
that
right.
Once
things
start
existing
epics
labels,
things
start
existing
at
that
group
level.
It
ceases
to
be
a
data
aggregation
tool
and
it
starts
to
be
a
data,
aggregation
tool
plus
feature
aggregation
or
feature
housing.
C
Basically-
and
I
think
this
problem
just
gets
worse
over
time,
so
you
know
repository,
I
think
we
talked
about
it
gosha
at
one
point
like
nobody's
asking
for
repositories,
and
then
gabe
gave
us
a
whole
slew
of
evidence
that
people
do
actually
want
repositories
at
the
group
level,
which
is
interesting,
but
I
guess
once
that
happens,
like
the
data
aggregation
aspect
of
groups,
in
my
opinion,
gets
so
muddied
that
it
yes,
it
does
do
that,
but
it
also
is
trying
to
do
other
things.
So
it
seems
like
we're
going
to
maintain
this
hard
line.
A
A
However,
if
you,
if
that
label,
is
missing,
it's
going
to
show
up
as
like
empty
when
you
search
for
the
group,
so
when
I'm
thinking
about
group
aggregation,
I'm
thinking
about
like
when
I
search
for
text
in
slack,
it
asks
me,
do
you
want
to
look
in
a
specific
channel
or
here's
everything
we
found,
here's
everything
we
found
on
the
channels,
here's
everything
we
found
about
people,
here's
everything
we
found.
So
that's
kind
of
why
I
think
people
would
use
things
at
the
group
level
mainly
for
visibility
and
for
searching.
A
C
And
I
don't
disagree
with
that.
I
absolutely
100
I'm
100
on
board
with
that
view
of
the
group,
but
if
they're
also
using
them
as
another
place
to
house
things,
let's
say
issues
right.
I
think
that's
a
pretty
common
one.
They
want
to
put
issues
at
the
group
level
because
it
doesn't
belong
in
this
project.
It
doesn't
belong
on
this
project.
C
Then
it
ceases
to
have
like
to
design
a
flow
ideal
for
the
user,
where
they
can
go
in
and
accomplish
that
task,
and
that
task
is
to
look
broadly
across
things,
but
if
there's
also
these
assets
that
are
tangential
to
that,
then
it's
it's
going
to
muddy
that
flow.
It's
it's
going
to
be
the
same
problem
that
we
currently
exist
today,
where
it's
trying
to
do
too
much
is
what
I'm
saying
I
fully
am
on
board.
A
I
would
say
it's
people
are
treating
the
issue
like
an
epic
and
now
that
we
introduce
tasks
that
may
make
sense
for
those
of
you
who
use
jira.
You
know
you
can
actually
define
the
hierarchy
wherever
you
want
and
you
can
have
issues
and
tasks
and
issues
and
epics
and
pillars
and
themes,
and
I
don't
even
know
what
goes
on
top
of
that.
Maybe
one
day
we'll
do
that
too.
I
don't
know.
C
I
guess
let
me
see
if
I
this
will
make
it
clear
right.
So
as
long
as
you
have
buckets
that
contain
assets,
and
then
you
have
things
that
aggregate
those
buckets
as
long
as
you
can
have
assets
at
this
layer,
then
you're
going
to
want
to
layer
on
top
of
that
and
as
soon
as
that
has
assets,
then
you
want
a
layer
on
top
of
that.
The
only
way
to
stop
the
madness
of
climbing
the
ladder
continuously.
C
Then
people
just
want
to
be
able
to.
If
there
are
assets
there,
then
people
want
to
collect
those
assets
anytime,
they're
in
assets.
People
are
going
to
want
to
collect
them,
so
the
only
way
to
stop
the
madness,
in
my
opinion,
is
to
have
something
whose
job
it
is
to
is
solely
its
job
is
to
contain
things
not
to
also
have
assets
as
a
part
of
it,
and
the
groups
already
are
able
to
contain
assets,
and
if
we
continue
down
the
feature
parity
path,
they
will.
C
C
So
there's
no
connection
mechanism
there,
whereas
if
it
was
a
pure
aggregate
thing,
then
it
everything
would
have
to
be
below
it,
and
maybe
it
could
look
this
way
in
that
way,
but
it
as
long
as
you
have
to
go
aggregation
has
to
look
down
it
can't
look.
Horizontal
is
what
I'm
basically
trying
to
say.
C
A
Okay,
that's
the
million
dollar
question.
I
think
this
is
the
most
important
open
issue
which
is
not
defined
yet
we
we
started
the
project
bottom
up
and
not
top
to
bottom,
so
we're
really
starting
from
feature
parity
and
then
at
some
point
we'll
get
to
the
top
of
the
group.
In
my
mind,
the
top
level
mechanism
or
group
is
simply
a
group.
We
could
define
specific
behaviors
to
that
top
level
group
when
it
makes
sense.
Maybe
your
example
is
one
of
them.
A
A
However,
I'll
give
you
an
example
of
a
feature
that
I
think
would
be
only
in
the
top
level
and
wouldn't
go
down,
though
it's
also
open
for
discussion
billing,
okay,
so
thinking
about
a
workspace
as
like
the
thing
that
holds
everything
for
a
specific
organization,
probably
there's
one
person
who
is
in
charge
of
purchasing
licensing
and
checking
billing
and
whatnot,
and
so
they
can
extend
renew
things
like
that.
I
I'm
not
sure
that
makes
sense
to
be
way
down
at
the
project
level.
A
A
But
I
still
think
this
needs
to
be
problem,
validated
solution,
validated
and
also
the
terminology.
We
didn't
mention
this
in
your
question
before
which
we
spent
19
minutes
on
but
namespace.
In
my
opinion,
there
is
no
way
that
should
ever
ever
be
in
the
user
interface
it's
very
confusing
even
internally.
I
would
not
want
to
know
what
a
user
thinks
when
they
see
the
word
namespace
and
the
same
thing
for
top
level
or
workspace.
A
A
C
Organizational
model
inheritance
model.
It's
a
very
similar
question
to
the
first
question,
honestly,
I
think
at
its
core,
but
a
lot
of
the
stuff
that
I
that
I
saw
as
I
was
going
through.
Those
videos
was
that
kind
of
problem
of
cascading
inheritance
things
needing
to
live
in
different
places
in
the
tree
that
are
hard
to
make
them
live.
A
C
C
A
B
I
would
need
to
know
more
about
I,
don't
I'm
not
familiar
with
structures
loops.
Three
one
is
the
one
that
we
have
like
now
so,
but
I
know
that's
many
organizations
are
asking
like,
for
example,
group
sharing.
That's
like
the
thing
that
we
are
like.
That's
how
we're
breaking
the
tree-
and
this
was
asked
for
many
times.
C
C
A
A
I
just
think
it's
more
complicated
and
I
wouldn't
want
to
start
with
a
complicated
solution.
Daniel
created
a
really
nice
mock-up
for
how
to
cascade
settings,
which
I
think
is
really
simple
to
understand.
Again,
I'm
not
going
into
design,
but
it's
really
easy
to
understand.
Like
you
have
a
group
and
you
have
a
enforced
globally
option
and
whether
or
not
this
is
checked
anything
that
is
beneath
it,
whether
it's
a
subgroup
or
project.
A
A
D
I
think
that
arie
really
right
in
the
very
beginning
of
her
answer
in
particular,
I
think,
hopefully
we
could
get
to
I'd
love,
to
see
sort
of
a
pros
and
cons
model
of
of
these
different
structures
against
each
other.
I
have
yet
to
see
one
I've
spoken
with
gabe
a
lot
about
her,
dag
and
and
the
advantages
to
some
of
that,
but
that
conversation
has
been
very
isolated
to
just
that,
and
not
necessarily
in
comparison
to
what
the
others
are
in
the
environment.
D
I'd
love
to
see
like
okay,
if
we
wanted
to
put
in
the
work
to
go
with
a
dag,
which
would
be
very,
very
an
uphill
battle
and
very
complicated
for
permissions
levels.
What
advantages
is
that
getting
us
over
the
traditional
tree
model
that
we
have
already
and
are
there
others?
I
hear
a
lot
about
dag,
but
I
don't
hear
much
about
others.
D
So
if
we
truly
want
to
like
to
like
answer
this
question,
where
do
we
want
to
go
with
these
organizational
models?
Is
this
truly
an
open
question?
Can
we
do
this,
then?
I
would
really
want
to
start
with
just
a
simple
pros
and
cons
list
of
advantages
of
one
over
the
other
which
I
haven't
seen.
Yet.
I
think
that
that's
the
important
part
I
haven't
seen
it
yet
yeah.
D
A
C
E
Can
I
ask
another
question:
that's
not
on
the
agenda
because
I
I
just
spoke
to
gabe
before
this
meeting,
which
was
great
but
also
even
more
complex
than
anything
I've
seen
so
far,
and
he
described
that
the
very
long-term
goal
for
him
would
be
to
go
into
like
a
knowledge,
topology
model
that
fits
to
what
the
organization
needs.
Is
that
also
how
you
think
about
it
that
he
showed
me
like
this?
E
You
know
product
flow
model,
organizational
model
and
then
how
knowledge
is
structured
in
the
organization
and
that
they
look
very
different,
but
that,
ultimately,
we
want
to
match
the
knowledge
model
more
to
the
organization,
and
that
should
be
the
highest
goal
of
this,
because
I
think
it
would
have
quite
an
influence
on
how
we
have
to
think
about
it.
But
it
also
made
the
whole
space
a
lot
bigger
than
what
I've
seen
so
far.