►
From YouTube: Workspace AMA Dec 7th 2021
A
A
The
way
that
we
started
this
project
was
actually
bottom
up
and
not
top
to
bottom.
So,
even
though
our
ultimate
goal
is
to
reach
the
workspace
level,
which
is
the
top
level
namespace,
we
started
by
creating
a
project
level
namespace,
which
was
the
common
foundation
level
namespace
on
which
we're
going
to
build
the
workspace.
A
A
Austin
is
not
on
the
call
either
but
I'll.
I'm
gonna
read
his
question
out
loud
so
austin
said
I'm
working
on
mapping
out
features
and
settings
that
would
be
looking
to
leverage
workspaces
for
group
compliance.
How
could
I
ensure
a
seamless
transition?
This
is
a
great
question
and
it's
not
only
oh
hey
elsin.
I
was
just
reading
your
question
out
loud.
So
it's
a
great
question
because
it
isn't
very
only
specific
to
compliance.
A
B
Yeah
sure,
sorry,
I
had
some
trouble
finding
the
passcode
for
the
meeting,
but
that
put
that
in
the
agenda
as
well
yeah.
So
as
I'm
considering
the
number
of
features
that
my
group
is
responsible
for
and
I'm
sure
other
designers
are
asking
themselves
the
in
question,
I'm
trying
to
better
understand
how
I
can
ensure,
like
a
smooth
transition
for
the
features
that
are
spread
across
the
different
areas.
B
A
good
example
for
compliance
is
we
have
a
different
version
of
the
audit
events
feature
in
the
admin
area
for
groups
and
for
projects.
Mostly
it's
due.
It's
like
back
end
constraints
of
performance
queries.
So
when
we're
talking
about
creating
like
a
single
space
and
within
a
namespace
or
within
a
workspace
trying
to
understand
how
I
can
help
paint
that
vision
for
what
it's
going
to
become.
A
So
great
I
answered
very
generically,
but
if
gosha
wants
to
jump
into
the
technical
evaluation,
I
let
her
do
that
as
well.
So
short,
the
short
version
is
like
this.
The
whole
point
of
the
project
that
we're
working
on
now
is
to
consolidate
groups
and
projects,
so
that
would
mean
that
there
would
be
the
same
name
space
for
projects
and
groups,
but
it
would
change
the
behavior
would
change
by
based
on
the
hierarchy
of
where
they're
located
so
subgroups
groups
and
so
on.
A
This
is
unrelated
to
the
admin
panel,
and
so
theoretically,
if
you
haven't
started
implementing
a
feature,
I
would
recommend
doing
it
first
in
this
new
namespace
concept,
so
that
it
would
work
for
both
project
and
groups.
When
we're
migrating
existing
features,
we
need
to
migrate
it
to
this
nayspace
and
then
theoretically,
we
only
have
to
have
it
implemented
once
one
of
the
goals
of
workspace.
Besides
creating
this
top-level
namespace
is
really
getting
rid
of
a
bunch
of
redundant
code.
A
A
lot
of
us
have
the
same
feature
implemented
for
project
and
then
for
group,
and
maybe
in
instance-
and
maybe
we
even
have
it
in
some
other
places.
So,
for
example,
for
plan
the
label
picker,
which
is
our
official
name
for
this
feature,
which
is
where
you
select
labels
to
add
to
issues
it's
implemented
in
six
different
locations,
and
so
this
simplifies
it
and
lets
you
implement
it
once
okay,
so
that
that's
an
added
bonus
that
we
have
from
this
implementation
and
why
it's
worthwhile
for
us
to
do
it
in
the
lab
internally.
A
Regarding
the
admin
panel,
that's
a
little
bit
different
because
that
functionality
is
available
for
different
users
and
it
has
a
whole
different,
ux
component,
and
so
I
think
that
you
can
start
with
moving
the
functionality
to
groups
and
projects.
Once
we
finish
phase
three
of
my
allowing
migrating
new
features,
but
the
admin
panel
will
probably
have
to
wait
until
the
admin
panel
actually
moves
to
the
workspace
to
the
top
level.
Namespace.
B
A
B
D
Okay,
so
I
was
just
wondering
how
what
is
the
future
for
groups
and
projects,
and
how
should
we
think
about
these,
because
when
I
think
about
me
joining
get
lab,
this
was
the
most
confusing
area
of
all,
which
is
the
navigation
menu
around
groups
and
projects
like
knowing
what
group
I'm
in
and
what
project
I'm
in
and
what's
the
difference,
and
why
is
there?
A
difference
was
confusing.
So,
first
of
all,
thanks
thanks
to
everyone,
who's
doing
this
for
clarifying
this.
D
For
our
users,
this
will
be
very
important
to
remove
some
of
the
confusion,
like
a
lot
of
the
sus
scores
that
I've
been
reading
through
the
individual
responses
talks
about
how
confusing
the
navigation
is,
understanding.
What
things
are-
and
I
think,
comes
from
the
fact
that
we
belong
to
a
group
and
a
project,
and
these
two
things
are
different
and
you
can
do
one
and
one
and
one
in
the
other.
So
this
is
great,
so
I
was
wondering
what
the
future
is
will.
E
We
have
created
this
concept
of
groups
and
projects
and
there's
sort
of
to
the
user
right.
It
feels
like
artificial
differences
between
them.
So
that's
one
of
the
things
that
we
want
to
do
away
with
and
essentially
have
one
container
of
resources
and
features
that
can
be
stacked
into
a
hierarchy
right
and
and
that's
the
future.
It's
going
to
take
a
lot
of
work
to
get
there
right,
both
from
the
engineering
and
ux
side
to
basically
transition
from
where
we
are
to
there.
E
But
right
now
the
team
is
working
on
laying
down
the
foundations.
For
that,
and
essentially
there
was
a
lot
of
discussion
and
I
can
find
the
architectural
blueprint
and
link
it
here
in
case
you
are
interested
of
like
what
the
best
way
was
to
approach
this
shift
and
what
was
decided
from
the
engineering
perspective.
Is
that
basically
we're
going
to
have
a
namespace
for
behind
the
scenes
right
in
the
database
for
groups,
projects
and
personal
namespaces?
D
D
So
what
does
what
does
it
mean
to
me
that
question
which
is
wow
now-
and
I
think
this
this
may
be
interesting
for
other
groups
as
well,
but
sort
of
looking
from
the
import
perspective
where
we
do
have
group
exports
group
imports,
project
exports,
project
imports,
where
we
like
rely
on
trends.
You
know
taking
that
data,
you
know
serializing
and
deserializing
somewhere
else
and
then
creating
recreating
that
particular
concept.
D
D
When
can
we
expect
those
to
be
different
or
different
enough,
or
will
they
ever
be?
I
mean
or
will,
will
there
be
magic
behind
the
scenes
that
makes
it
so
that
I'm
able
to
export
a
group
and
export
a
project
and
import
a
group,
a
name
for
the
project,
and
it
goes
from
a
namespace
to
the
namespace
and
import?
D
E
Yeah,
that's
a
great
question.
I
would
say
it's
all.
I
don't
have
a
concrete
answer,
but
I
think
for
you
specifically
right,
if
I
think
of
the
use
case
of
import
that
you
just
laid
out,
you
would
need
to
wait
until
all
of
the
components
that
you
would
be
touching
basically
are
tied
to
a
namespace
in
order
for
it
to
be
so
like
to
the
point
where
you
can
migrate,
either
to
a
group
or
a
project
for
one
or
the
other.
E
So
I
think
for
you,
you
would
need
to
wait
and
I
think
there
will
be
a
point
we
haven't
discussed
what
the
timeline
for
this
is,
I
would
say,
it's
probably
more
than
a
year
out
right.
There
will
be
a
point
where
we
would
retire
the
concepts
of
groups
and
projects,
and
it
would
just
be
a
container
right.
I
don't
know
we
haven't
defined
the
name,
but
namespace
is
basically
what
it
is
behind
the
scenes.
E
A
I
actually
think
there
is
some
things
that
import
would
probably
need
to
do
before
others,
so
right
now
we're
in
the
process
of
backfilling
existing
projects
to
project
name
space.
So
I
think
that
the
importer,
once
they
import
new
projects,
they
would
probably
need
to
take
that
into
consideration
and
already
import
into
project
names.
I'm
not
sure
it's
ready
yet
dosha.
So
you
tell
me
when
we
should
expect
that.
C
I
believe
that
there
are
issues
on
that,
so
I
will.
I
would
thank
you
harris,
but
I
think
that
team
was
like
prepared
to
manage
it
by
them
by
them.
Workspace
team
was
ready
to
manage
it,
as
we
are
like
updating
that,
for
example,
service
that
creates
projects
like
the
new
projects,
but
I
will
tag
you
in
the
right
issues.
Harris.
D
C
Of
course,
but
the
first
first
implementation,
that's
going
on
right
now
is
is
rather
like
everything
is
happening
in
the
same
time.
So
we
are
not
touching
the
current
implementation,
just
like
adding
a
little
bit
so
then
we
can
like,
like
make
a
make
a
change
in
a
way:
that's
invisible
for
for
users
and
it's
not
creating
any
any
problems.
D
Oh
perfect,
thank
you
some
students,
I
have
I
so
I
did
have
a
sub
question,
and
that
is
so,
as
other
groups
maybe
decide
to
move
things
from
project
or
group
into
a
namespace,
let's
say
issues
or
labels
or
some
some
of
those
concepts
move
into
that
is
that
does
it
continue
to
be
transparent
to
the
importer?
So
if
the
importer
is
asking
for
a
project,
will
we
get
those
labels
still
or
do?
D
E
D
Is
just
sort
of
how
we
work,
and
this
is
general
for
gitlab
2,
and
that
is,
if
you're
implementing
any
feature
that
you
know
changes
other
things
you
are
kind
of
responsible
for
adding
it
to
other
things
as
well.
So
you
know
if,
if
on
issue
we
implement
something
like,
I
don't
know
something
that
we
currently
don't
have
some
kind
of
a
date
or
some
you
know
like
a
co-owner
or
some
other
attribute,
and
that
is
added
to
the
data
schema.
D
That
team
is
responsible
for
adding
it
to
the
export
and
the
import
and
the
logs
and
the
database
and
adding
it
to
all
the
different
aspects
that
we
do
have.
So
I
just
want
to
kind
of
state
that
so
that
everyone
is
aware
that
importing
you
know,
isn't
gonna
be
able
to
just
play
a
catch-up.
So,
like
you
know,
we
implement
something
new
that
breaks
the
imports,
and
now
the
import
team
needs
to
like
in
an
emergency
fashion.
Add
that
to
the
importer
is
not
how
it
works.
D
So
I'm
not
saying
this
is
happening
now,
but
I've
I've
seen.
I
have
seen
projects
where
things
were
just
added
to
either
a
project
or
a
group
or
any
kind
of
a
data
structure,
and
people
will
typically
forget
also
to
add
it
to
the
like
a
project,
export
and
then
also
the
project
imports.
All
of
a
sudden
like
that
thing
is
not
working,
and
sometimes
they
even
make
it
a
required
field
so
that
when
we
try
to
create
the
project
with
that
field
missing
now
all
the
project
imports
start
failing.
D
C
I
was
wondering
if
workspace
is
a
user-facing
term
or
something
we're
just
using
internally,
and
also,
I
think,
marcel,
you
kind
of
summed
up
what
I'm
really
getting
at
here
is.
How
is
this
going
to
change
the
ui
like
it?
Are
we
going
to
hear
our
customers
saying
I
just
spun
up
a
new
workspace
of
git
lab
or
is
the
term?
Is
it
going
to
replace
the
term
instance?
These
are
all
kind
of
questions
going
through
my
mind,.
A
So
yes,
workspaces
customer
facing
we
already
created
some
documentation
around
it,
which
I
think
is
an
agenda
in
my
mind.
It
should
replace
the
instance
at
some
point,
but
it's
going
to
take
us
a
while
till
we
get
there.
So
the
idea
is
that
a
workspace
is
your
landing
page
for
your
organization,
and
this
is
what
you're
going
to
see
so
obviously,
the
most
like,
besides
moving
features
to
this
top
level
namespace
or
the
top
parent
group,
you
can
think
about
it
like
that.
A
The
two
really
big
features
here
are
the
admin,
ability
and
settings
that
can
be
cascaded
and
inherited.
Those
are
the
two
big
ones
that
will
be
a
big
change
for
sas
users,
but
at
some
point
we
would
get
rid
of
the
differences
between
instance
and
and
workspace
at
some
point
again,
this
is
going
to
take
us
like
over
a
year,
but
there
are
very
small
nuances
that
would
change
like
hardware
settings
which
sas
users
don't
need,
and
we
need
to
keep
that
in
self-managed
and
so
on.
A
G
A
E
I
put
a
link
there
and
a
lot
of
other
tools
have
a
similar
concept.
I
just
azure
was
the
first
one
that
came
to
mind
I'll,
find
additional
ones,
but
I
put
a
link
to
how
azure
sort
of
what
their
model
looks
like
they
have
an
organization,
it's
what
they
call
it
and
then
within
there
they
have
like
teams
and
projects,
and
it's
all
within
their
big
sass
instance,
and
it
works
the
same
way
for
the
like
for
self-managed,
that's
more
similar
to
where
we
would
end
up
as
a
concept,
not
the
details.
G
A
Have
nick
on
the
call,
so
just
nick,
let
me
keep
me
honest:
the
user
shouldn't
feel
any
difference
whether
or
not
they're
creating
a
group
or
project
right
now,
if
it's
a
namespace
or
if
it
should
be
the
regular
flow.
We're
not
changing
anything
dramatic
right
now,
so
it
should
stay
the
same.
The
dramatic
change
will
be
once
we
get
to
that
workspace
top
level
namespace
where
we're
like.
What
are
we
going
to
show?
A
H
But
eventually
we
want
to
merge,
but
we
haven't
got
around
to
that
yet
so,
in
the
meantime,
projects
and
groups
are
going
to
stay
the
same
until
we
get
to
the
point
where
we're
ready
to
actually
transition
properly
and
merge
everything
together
and
then
we
need
to
have
a
lot
more
detailed
plan
of
how
that's
going
to
work
out,
but
in
the
in
the
short
to
medium
term,
not
much
is
going
to
change.
I
imagine.
H
Sure
I'll
drop
in
a
couple
of
links
as
to
the
like
the
exploration
around
that
new
workspace
construct
and
container,
like
my
focus,
has
been
on
on
some
other
stuff
at
the
moment,
but
yeah
like
eventually
I'll
get
around
to
to
like
fleshing
that
out
and
a
little
bit
more
fidelity
for
you
as
well.
But
I'll
drop.
Some
links
in.
E
B
I'm
I'm
wondering
how
do
we
prevent
the
same
problem
that
we've
created,
essentially
with
groups
and
projects
today,
where
groups
essentially
become
a
container
for
projects
and
workspaces
then
become
a
container
for
namespaces?
How
do
we
avoid
this
whole
that
we
got
ourselves
into
initially?
I
don't
really
know
all
the
origins
of
how
a
group
started.
All
I
know
is
like
initially
gitlab
just
had
projects,
and
then
groups
were
added
so
perhaps
like
daniel
is
maybe
alluding
to.
G
F
F
I
F
H
And
and
also
we,
we
have
got
a
solution,
validation
issue,
which
I
posted
further
up
in
this
agenda,
where
we
will
be
testing
these
names
out
as
well
with
with
users
just
to
make
sure,
because
workspace,
namespace,
they're
placeholders,
that
we're
working
with
in
the
meantime.
But
we
want
to
test
all
this
stuff
out
with
users
make
sure
it's
understandable.
H
E
Is
that
there'll
be
more
functionality
in
it
like,
for
example,
users
right,
like
your
collection
of
users,
will
live
at
the
workspace
level
as
an
example
right
so
you'll
have
different
sets
of
users,
groups
and
projects
settings
all
within
a
workspace
and
configuration
like
ldap
and
saml.
I'm
saying
access
features,
because
those
are
the
ones
that
I've
thought
about
the
most,
but
those
will
all
live
tied
to
a
workspace.
E
I
C
E
A
Yeah-
and
I
also
want
to
remind
that
that
cascading,
the
settings
is
the
the
big
deal
here
that
doesn't
automatically
happen
today
and
you
know
also
the
ability
to
have
that
admin
view.
You
know
how
many
seats
do
I
use.
How
do
I
unblock
a
user
today?
Our
customers
actually
have
to
go
through
customer
support,
which
is,
you
know,
drag
so
it's
a
big
deal
to
get
to
this.
To
this
top
level.
Name:
space,
workspace
concept.
E
E
E
We
turned
some
things
off
intentionally
right,
we
don't
know
yet
we
basically
decided
to
tackle
the
hairy
problem
of
merging
groups
and
projects
first,
because
we
knew
that
was
something
that
we
did
need
to
do
regardless
and
basically
see
where
we
ended
up
after
that,
and
if
it
was
possible
to
reuse
the
same
implementation
of
container
so
that
we
don't
have
basically
two
versions
of
a
very
similar
thing
again
but
tbd.
But
your
concern
is
definitely
something
that
we've
discussed
internally
at
length.