►
From YouTube: 2022-05-04 Workspace AMA
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
And
michelle
you
have
a
first
question:
you
want
to
verbalize.
B
A
A
Our
customers
demand
them
to
be
on
the
other
level,
so
that
settings
can
cascade
and
so
on.
Right
now,
whenever
there's
something
on
a
group
level,
project
and
project
level,
that
requires
two
implementations
that
that
need
to
happen.
Those
groups
and
projects
slightly
differ
and
those,
so
those
implementations
differ,
and
also
this
requires
not
only
two
implementations,
but
also
any
change
requires
changing
into
places.
A
By
creating
this
this
project,
we
aim
for
simplification.
We
aim
for
those
containers,
groups
and
projects
to
behave
more
like
equals.
So
whenever
we
want
to
work
on
a
project
work
on
a
any
feature,
that's
supposed
to
be
for
projects
and
groups,
we
can
implement
it
once
and
then
create
parity
between
those
two.
Those
two.
A
Those
two
entities
in
the
system.
A
B
Okay,
I
have
the
next
one:
how
does
this
work
impact?
Other
areas
outside
of
your
group.
A
I
like
to
say:
maybe
it's
not
very
harmful,
but
I
like
to
say
that
workspace
group
is
like
in
the
heart
of
gitlab.
We
are
like
the
the
idea
of
chiraki
the
the
groups
and
project
hierarchies
like
a
spine
of
everything.
A
That's
that's
done
in
gitlab,
so
this
can
impact
all
the
other
areas
if
they
right
now,
if
they
choose
to
we
create
foundation,
so
other
groups
can
benefit
from
this
work
can
whenever
they
have
features
that
are
on
a
on
one,
just
one
of
the
levels
and
they
want
us
to
bring
to
the
other
level.
It
will
be
easier
now,
so
we
aim
this
work
also
to
impact
to
have
to
have
some,
for
example,
performance
performance
improvements
in
the
future.
But
right
now
it's
mainly
for
this.
A
This
consolidation-
and
this
can
this-
can
benefit
other
groups.
They
will
be.
They
will
have
easier
time,
creating
their
changes.
B
A
I
know
that's
a
container
security
group.
I
believe
this
is
the
name,
but
I
may
I
maybe
I
may
be
wrong.
They
wanted
to
create
one
feature
that
was
supposed
to
be
on
groups
and
project
level,
and
they
were
like
aiming
to
do
this
using
the
new
framework,
because
this
makes
their
work
easier.
A
B
A
Phase
one
was
the
foundation
space
before
phase
one,
and
we
were
just
on
the
very
beginning
of
this
project,
and
that
was
some
time
ago,
and
we
all
know
how,
like
alexandria,
knows
how
how
much
work
it's
it
took
to
finish
phase
one
phase.
One
allowed
us
to
create
project
namespace,
so
namespace
record
for
every
project,
and
this
was
the
like
the
core
of
phase
one
creating
this.
This
entity
in
the
system.
A
And
this
was
the
foundation
like
a
building
block
that
we
can
use
going
further
and
phase
two
we're
exploring
how
to
consolidate
those
features.
We
focused
on
database
consistency
how
to
create
what
if
we
have
features
like
that
is
using
the
database
heavily
how
we
can
how
we
can
let
those
those
records
take
advantage
of
this.
We
were
cooperating
with
the
fantastic
database
team
and
alexandria
and
charlie
with
help
from
imra
and
jan.
A
They
created
this
framework
of
how
to
how
to
backfill
those
information,
so
those
changes
can
be
very
flexible
and
not
disruptive
for
users
alexander.
We
can
speak
more
about
this.
How
to
migrate
the
database
changes.
C
C
Creating
a
corresponding
namespace
record
in
the
for
for
every
project
in
the
namespaces
table.
So
what
what
that
gives
us
is
basically
now
when
you
want
to
implement
a
feature
for
project
or
for
group
you
can.
You
can
start
with
the
group
basically
and
you
reference
that
namespace
id
right
from
the
namespaces
table
like
if
you
want
to
move
that
to
the
project
table.
C
All
we
need
to
do
is
is
basically
reference
it
to
that
the
corresponding
namespace
id
that
is
of
type
project
as
now
and
can
eventually
like
we
can
eventually
remove
that
type
and
just
have
everything
behave
as
a
as
a
namespace
in
a
way.
So
so
that's
that's
different.
I'm
like
it
sounds
simple,
but
to
get
there,
we
had
to
do
like
a
lot
of
juggling
of
things
to
not
break
stuff
and
and
so
on
and
so
forth.
So
that's
that's.
C
What
from
like
it
more
of
a
technical
engineering
perspective
that
phase
one
is
the
phase
two
is
really
now
going
on
and
using
the
project
name,
space
id,
so
basically
the
corresponding
namespace
for
every
project
in
different
ways
and
what
we
started
with
is
the
members
and
the
routes
so
now
like
for
the
routes
you
have
different
routes
for
name
spaces
and
different
routes
for
the
projects,
and
now
you
can
consolidate
everything
in
just
like
query.
C
Only
the
namespaces
table
pull
the
project
data,
the
name,
the
the
route
and
everything
from
one
single
place.
So
that
should
give
an
improvement
in
performance.
You
don't
have
to
have
that
the
routes
can
be
simplified.
Obviously,
that's
not
that
simple.
C
It
just
requires
a
lot
of
work,
but
but
like
generically,
you
can
simplify
a
lot
of
stuff,
eventually
even
drop
the
whole
project
model
right
it's
tightly
coupled
with
repositories,
but
if
we
ignore
that
for
a
second
you
can
you
can
eventually
just
like
drop
that
all
together
and
that
same
thing
goes
for
the
memberships.
C
We
have
memberships
for
projects,
memberships
for
groups,
we
have
inheritance
and
all
that
stuff.
That
goes
up
down
and
then
having
everything
reference,
a
single
type
of
object
and
not
two
different
types
projects
and
namespaces
having
to
look
up
different
tables,
also
kind
of
simplifies
a
lot
of
this
stuff.
So
that's
what
the
well,
it's
not
the
complete
phase,
so
it's
phase
two
and
some
extension
of
it,
because
we
want
to
leave
it
the
phase
two
to
only
kind
of
backfilling,
the
the
namespace
reference
for
every
single
project.
C
So
like
right
now
we
have
this
members
table
that
that
uses
a
polymorphic
association
to
the
source
of
the
membership
which
will
point
to
either
a
group
or
a
project
and
like
by
by
adding
a
column
to
the
to
the
table
that
points
to
just
the
namespace.
C
We
can
remove
that
polymorphic
association
and
make
that
those
things
simpler.
So
what
what
the
phase
two
would
do
is
basically
backfill
that
project
or
that
namespace
id
with
where
with
the
corresponding
group
or
project
namespace
id
basically,
and
then
we
can
just
drop
that
polymorphic
association,
that's
something
that
we
as
back-end
engineers,
don't
really
like
in
a
way
to
have
those
polymorphic
things
and
single
table
inheritance
and
so
on,
and
so
forth.
C
So
yeah
that
that's
that's
a
nice
simplification
there
and
really
after
phase
one
again,
anyone
who
wants
to
implement
something
on
the
group
or
project
level
can
do
so
by
by
referencing
the
project
namespace
record.
Basically
so
like
right
now,
it
it'll
be
slightly.
C
Cumbersome
so
to
say,
because
you'll
have
to
to
pull
the
the
project
namespace
and
then,
if
there
is
very
specific
attribute,
that's
that's
on
the
project.
C
Only
right,
they
don't
have
it
in
the
namespaces
they
will
you'll
have
to
go
and
and
then
pull
the
project
and
then,
from
that
project,
get
your
your
attribute,
but
eventually,
as
we
start
moving
features,
because
that's
that's
the
the
intention
to
move
features
from
project
into
the
namespace,
so
that
eventually
we
can
like
completely
drop
that
project
model
and
we
will
differentiate
the
namespace
and
the
project
only
by
that
type.
So
we'll
need
to
figure
out
a
way.
How
do
we?
How
do
we
actually
handle
the
project?
C
Very
specific
project
features
that
that
we
don't
want
to
move
to
the
to
the
group
level,
because
if,
if
the
feature
is
intended
to
move
from
project
level
to
the
group
level,
that's
that's
an
easy
thing
right.
You
either
add
it
to
the
namespaces
table
or
have
a
an
extension
to
the
namespaces
table
that
holds
all
these
features
and
attributes
that
the
project
has.
And
then
you
basically
don't
even
need
to
go
to
the
project
model
or
table
to
pull
that
feature,
because
you'll
already
have
it
on
the
on
the
namespace
itself.
C
The
the
like
the
problem
is
what
to
do
with
the
features
that
are
very,
very
specific
to
the
project
and
don't
end
up
being
on
the
name
space
or
on
the
group
on
the
group
level
right
like
like,
for
instance,
repository.
I
don't
know
if
we
have
an
intention
to
have
repositories
on
group
level,.
A
I
just
want
to
clarify
one
thing
because
to
be
very
clear
by
saying
dropping
project
model:
we
do
not
mean
project
idea
from
the
system.
This
means
only
a
back-end
artifact
for
that,
because
I
know
that
mike
is
here,
and
we
already
had
this
conversation.
I
just
want
to
make
it
make
it
very
clear
that
we
are
talking
about
how
we
define
it
on
the
back
end,
not
the
idea
of
the
project
in
a
gitlab
as
a
as
a
system.
C
Yeah
that
that's
a
big
more,
it
goes
into
a
philosophical
question
of,
if,
like
let's
say,
we
take
this
view
of
projects
and
groups
having
like
the
complete
parity
of
the
features.
How
do
you
really
distinguish
between
the
two
like
which
one
is
a
project
and
which
one
is
a
group
like?
How
do
you
make
the
difference?
C
Where
do
you,
as
a
customer,
really
want
to
to
reference,
as
this
is
actually
my
project
and
everything
else
is
just
like
the
structure
that
I
want
to
keep
right
for
for
my
organization
or
how
I
want
to
handle
the
project
and
so
on,
because
if
you
have
the
parity
you
you
kind
of
get,
I
think
there
will
be
a
lot
of
confusion
at
that
point.
C
We
are
like
a
long
way
away
from
that,
but
but
like
that's
something
that
we
need
to
consider
but
yeah,
like
eventually
everything
that
can
be
backed
by
a
single
object
on
the
back
end
on
the
implementation
side
of
the
things
which
gives
a
lot
of
flexibility,
but
also
gives
a
lot
of
complexity
in
terms
of
ux
and
and
so
on.
So
so
yeah.
B
So
this
was
actually
a
really
helpful
answer.
Alexandru
joshua
mentioned
earlier
that
one
of
the
problems
this
is
solving
is
consolidation
and
it
sounds
like
what
you're
saying
is
that
your
working
phase,
two
is
consolidation.
You
had
said
you're,
building
on
phase
one
now
you're
actually
using
that
stuff.
So
to
me
that
implies.
B
Memberships
is
incredibly
difficult,
but
to
me
that
implies
that
there
could
be
other
groups
today
doing
their
own
consolidation
on
simpler
things.
Is
that
right.
C
Yeah
yeah
that
that's
correct,
I
I
think
one
tweak
so
to
say,
would
be
that
with
this,
this
part
of
the
phase,
two
that
we
do
backfilling
for
memberships
and
and
routes,
would
kind
of
serve
as
a
example
even
taking
their,
mr,
as
as
the
way
that
is
implemented
as
an
example
of
how
to
backfill
things.
Like
let's
say
we
want
to
move
issues
to
the
group
level
right
you.
You
have
issues
now
only
referencing
projects.
C
How
do
you
make
them
reference
the
groups,
so
we
can
take
the
memberships
or
the
the
routes,
consolidation
backfilling,
as
an
example
of
how
to
do
that?
Basically,
but
yeah
there
are
things
that
can
be
done
from
basically
by
any
group.
C
Obviously,
every
single
feature
has
its
own
meta
data
and
details
that
may
not
fit
into
the
membership
or
routes
implementation,
like
I
don't
know
like
something
that
needs
to
flow
up
up
the
tree
right
up
the
hierarchy,
which
is
probably
not
true,
either
for
membership
or
or
routes.
I
think
for
memberships.
We
have
some
sort
of
an
inheritance
from
top
down,
but
again,
all
that
of
the
inheritance
or
pushing
things
up
is
not
something
that
is
yet
structured
like.
C
A
From
my
perspective,
probably
the
features
that
can
can
get
take
advantage
of
our
work
from
now
are
the
the
ones
that
are
not
referencing
memberships
directly,
for
example,
the
the
example
of
issues
that's
like
with
members
like
issues
are
incredibly
complicated,
with
many
different
connections
to,
for
example,
to
reviewers
to
assignees
to
people
who
are
mentioned
so
that
might
be
complicated
without
memberships
being
like
consolidated
fully
only
like.
A
We
are
like
working
on
this
database
layer
now,
but
if
the
feature
is
more
on
like,
for
example,
on
a
project
level,
and
it's
like
not
that
entangled
with
memberships,
it's
like
easier
to
to
move
it
right
now,
so
we
can
think
about
which
features
make
the
best
candidates
to
move
like.
Let's
focus
on
simpler
ones,
the
less
entangled
ones,
because
there
are
lots
of
loads
of
them,
of
course.
So
that
would
be
my
my
personal
opinion.
D
I
have
one
question
regarding
the
ids
so
right
now
we
have
a
separate
project
table
and
there's
an
id
and
we
will
move
everything
to
the
namespace
and
we
will
keep
the
id
somewhere
around.
I
guess
for
legacy
reasons,
but
how
is
the?
How
is
it
like
moving
forward
like
what
are
these?
Will
these
projects
have,
if
it's
only
in
the
namespace
level,.
C
Yeah,
so
so,
right
now
the
flow
we're
still
creating
projects.
So
when
you
create
a
project,
we
still
create
the
project
object
and
at
the
same
time
we
create
a
corresponding
project.
Namespace
id.
We
are
not
yet
at
the
point
where
so
so,
eventually,
as
probably
as
part
of
phase
two
or
something
after
that,
we
need
to
switch
from
creating
project
to
to
creating
a
project
namespace
and
we
will
still
keep
creating
the
project
and
that's
simply
because
we
cannot
drop
the
the
repository
attachment
to
that
right.
C
But
but
but
what
will
happen
is
at
least
in
my,
in
my
view,
is
that
project
now
can
be
created.
Asynchronously
like
you,
can
create
a
project
namespace.
It
will
have
the
route,
it
will
have
everything,
but
the
project
will
basically
be
a
wrapper
around
the
the
repository
and
all
other
features
that
that
the
project
has
and
and
it
can
be
created
asynchronously
if
it
didn't,
even
if
it
wasn't
created,
we
show
an
error
or
something
like
that.
C
So
yeah
the
perspective
slightly
changes,
but
we
continue
to
do
that
up
until
to
the
moment
where
we
can
either
drop
it
or
make
somehow
that
repository
can
be
attached
to
the
group
or
somehow
that
it
becomes
some
sort
of
a
feature
or
something
that
can
be
turned
on
off
things
like
that
right.
But
up
until
that
moment
we
have
to
keep
the
project.
It's
just
that
the
project
name
space,
where
the
like
the
namespace
object,
will
become
more
of
a
developer
facing
or
user
facing.
D
It
makes
sense,
but
so
we
at
some
point
will
still
drop
the
project
right.
C
D
C
It's
it's
perhaps
years
away
before
we
can
fully
drop
the
project,
but
like
the
long-term
vision
is
like.
Why
keep
the
model
like
that
table?
That
is
fairly
big.
If
we
can
do
everything
at
the
nace
based
level
right.
D
C
We
can
keep
like
we
already
do
that
for
some
of
the
things
like
we
keep
a
project
id
to
project
namespace
id,
so
that
table
will
shrink
down
to
only
two
columns
to
keep
this
legacy.
So
if
you
cannot
find
like,
if
you
reference,
you
have
your
old
legacy
references,
they
will
go
through
project
table
and
then
pop
up
to
the
to
give
you
the
corresponding
project
namespace
but
yeah
yeah.
C
That
will
not
totally
go
away
simply
because
we
need
to
keep
that
legacy
functionality,
but
all
of
the
other
things
that
is
feature
related
and
all
those
columns
will
be
gone.
Okay,.
A
Okay,
I
think
we
have
reached
the
end
of
the
agenda
thanks
all
for
joining
and
for
this
for
all
your
questions
and
if
you
have
any
further
questions,
we
are
welcoming
them
on
f,
dash,
simplifying
groups
and
workspace
channel.
You
can
find
us
on
slack
and,
of
course,
welcome
any
questions
anytime.