►
From YouTube: 2022-05-04 Workspace AMA (APAC/AMER time)
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
Hello,
everyone,
it's
a
very
small
group,
welcome
to
the
second
workspace
ama
we
have
charlie,
who
has
been
working
on
a
workspace
project
for
quite
some
time
now
so
she's
our
specialist
on
the
subject.
A
B
B
C
Sure
it's
only
just
me
yeah,
who,
who
is
there
a
dri
or
a
group
responsible
for
this
work?.
A
A
That's
why
alexandria
and
charlie
are
with
us
and
jan
was
with
us
and
a
couple
of
other
people
who
were
helping
workspace
team
that
was
just
established,
get
started
with
that
and
now
workspace
group
grew
and
we
hope
we
that's
what
we
and
we
want
to
bring
this
this
work
for
to
the
group,
but
and
in
this
at
the
same
time,
we
want
particular
features
to
be
to
be
taken
care
of
by
groups
that
are
responsible
for
this
feature.
A
So
we
are
not
planning
to
move
every
feature
to
project.
Namespaces
will
be
responsible.
This
the
particular
groups
will
be
responsible
for
that.
Yet
we,
of
course
we
want
to
help
and
and
that's
why
we
do.
We
have
built
this
foundation
work.
C
A
A
Yes,
so
there
are
two
channels
that
you
can
ask
us
questions
one.
It's
f
dash
simplifying
groups
and
projects-
and
this
is
like
for
for
this
particular
project,
but
gm
manage
workspace.
Is
the
other
channels
like
this.
You
can
ask
us
questions
and
we
will
we
will
get
to
those
as
well
without
any
problems.
C
Cool
I've
got
a
second
question
as
well.
I'm
just
wondering
what
project
namespace
like
how
it
will
it
be
visible
to
users
like
groups
or
would
it
be
largely
invisible.
D
Well,
now
it's
not
feasible,
but
eventually
that
is
going
to
be
user
facing.
That
does
involve
like
changing
the
flow
of
creating
the
projects
right,
because
now
we
create
a
project,
and
we
have
this
callback
that
creates
the
project
namespace
record.
So
we
need
to
reverse
the
code
basically
to
make
that
the
other
way
around,
create
the
project.
Namespace
and
kind
of
then
create
the
project
so
so
long
term,
yeah,
that's
going
to
be
user.
Physic
is
like
eventually,
because
we
are
moving
this
stuff
to
the
namespace.
D
Eventually,
the
project
model
and
table
as
it
is,
is
not
going
to
be
used
and
useful
anymore
right.
We
will
probably
keep
it
for
just
like
for
legacy
stuff
to
map
like
old
links
or
stuff
like
that.
If
we
need
to,
maybe
we
don't
even
need
that,
because
we
can
do
that
through
the
roots,
but
anyway,
maybe
project
stable
will
stay
in
some
sort
of
a
mapping
for
the
legacy,
relationships
and
stuff,
but
but
eventually
that
should
kind
of
go
away.
D
It's
a
big
question
because,
like
repositories
are
very
much
hard
linked
to
the
projects,
I
don't
know
how
much
work
and
we
didn't
discuss
with
the
kid
on
the
team
like
how
much
work
that
is
to
kind
of
try
and
and
and
link
repositories
to
the
to
the
groups
and
so
on
and
so
forth.
But
that's
very
far
away.
D
I
would
say
there
were
a
lot
of
a
lot
of
features
that
need
to
be
moved
from
project
to
group
like
drop
a
lot
of
columns,
so
to
say,
like
quote
unquote
from
the
projects
table
before
we
can,
I
guess
we
can
even
get
to
the
repository
feature.
A
And
yeah-
and
we
are
talking
about
like
you-
know,
back-end
code,
because
we,
I
don't
think
right
now.
Anyone
has
this
idea
to
drop
like
the
project
idea
from
the
system
like
there
are
very
like
long-term
plans
like
and
discussions
around,
that
like
how
we
want
to
structure
this,
but
this
is
like
very
far
away
in
the
future
and
it's
like
right
now.
It's
only
like
very
theoretical
discussions
in
the
near
future.
There's
no
idea,
no
ideas
to
drop
project
as
a
project
in
gitlab,
and
so
it's
like.
C
C
D
C
D
Create
a
test
project
and
then
I
realize
well.
I
actually
need
some
sub
projects
for
this
project
and
then
now
test
project
is
actually
not
a
project
anymore.
It's
kind
of
like
a
a
wrapper,
a
container,
a
group
and
that's
fine
for
us
for
for
the
backend
perspective
right
like
you,
can
do
whatever
you
want
to.
But
then
there
is
a
big
question
in
in
the
ux
and
ui
and
and
how
does
that
not
confuse
the
user
and
so
on,
because,
like
eventually
you
can
have
a
project?
C
Yeah
question
is
yeah,
I'm
I
don't
know
personally,
as
a
user.
I
remember
when
we
added
when
we
overloaded
groups
with
not
just
groups
of
projects,
but
groups
or
users,
it
just
got
super
confusing.
So
if
we
have
like
project
namespace
with
sub
project,
namespace
and
subproject,
I
don't
know
yeah
yeah.
D
I
think
that's
a
big
question
for
the
designers
and
for
for
pms,
and
so
on,
like
to
me
really
to
me,
a
project
can
be
some
sort
of
a
sub-hierarchy
right
like
I
can
have
multiple
groups
and
multiple
leaf
nodes
like
and
things
like,
multiple
repositories
and
that's
that's
a
project
in
itself,
so
so
maybe
like
and
I'm
like
speculating
a
lot
here.
D
That's
that's
a
question
for
the
professionals
who
can
think
about
that,
but,
like
it's
more
like
I
did,
I
would
see
myself
seeing
a
dashboard
saying
this
is
like
project
x
and
you
have
this
hierarchy.
You
have
this
like
repositories
and
all
that
stuff,
and
then
you
can
easily
kind
of
navigate
through
that.
But
this
is
an
open
question
at
this
point
like
we
offer
this
capability
to
do
whatever
you
need
to
do.
It's
just
really
at
this
point
we're
doing
this
because
it's
always
been
a
big
ask.
D
Well
now
we
want
issues
at
group
level
and
now
we
want
epic
epics
at
project
level,
and
we
want
this
at
group
level
and
the
other
thing
at
the
project
level.
So
a
lot
of
these
features
seem
to
be
needed
at
different
levels
in
the
hierarchy
and
then
like
we
have
to
copy
code
or
or
do
like
concerns,
and
you
end
up
just
with
two
models
that
basically
do
the
same
thing
and
you
have
to
duplicate
code
and
you
have
to
maintain
it
and
so
on
and
so
forth.
D
So
it
kind
of
makes
sense
to
unify
everything
from
that
perspective,
but
yeah
it
does
get
confusing
when
you
start
to
get
a
project
and
then
some
projects
and
then
that's
different
from
groups
and
and
so
on.
So
yeah.
A
I
would
quote
our
designer
who
I
was
talking
last
week,
who
said
that,
like
this
work
allows
us
to
have
features
on
project
and
group
level,
but
we
need
to
make
sure
that
we
also
want
those
features
on
groups
and
project
level
and
what
features
on
which
level
makes
sense.
So,
let's
say
like
we
want
to
add
flexibility,
but
it
doesn't
mean
that
we
need
to
use
it
in
in
every
for
every
feature
and
for
every.
You
know
case
that
we
have
in
system.
C
B
I
would
say
that
once
once
we
do
the
consolidation
of
project
in
groups
and
that's
the
scope
of
the
work
with
the
simplify
projects
and
groups
project.
That
makes
sense.
I
think,
once
that
consolidation
is
complete,
then
we
can
start
exploring
now.
What
does
a
project
actually
mean
and
start
to
explore
that?
B
But
I
think
I
don't
know
if
that's
been
explored
in
the
uk,
but
it's
definitely
like
an
interesting
possibility,
but
I
would
say
I
would
say
that
the
scope
of
what
we're
doing
is
is
simply
to
consolidate
those
things,
and
then
we
can
explore
that
you're
going
to
look
like
all.
C
D
Yeah,
so
not
like
adding
a
new,
like
my
my
my
recommendation
or
advice,
when
a
new
feature
is
being
added
added
to
the
group
level.
First,
like
think
how
you
would
do
it
at
a
group
level,
and
then
it
kind
of
automatically
goes
into
the
project
level,
because
you
just
link
the
project
namespace
id
right.
It
is
it'll,
eventually
go
to
the
project
level.
D
So
if
you
think
about
the
feature
that
you're
adding
at
a
group
level,
it's
a
bit
more
complex,
and
I
can
understand
that
because,
like
adding
it
at
the
leaf,
node
right,
it
may
feel
easier
because
you
don't
have
to
think
about
inheriting
stuff
down
or
or
pushing
stuff
up.
You
just
have
it
at
the
at
the
project
level,
but
if
you
like,
with
with
the
project
namespace,
if
you
add
a
feature,
think
of
adding
a
feature
at
the
group
level,
you
kind
of
get
it
for
free
at
the
at
the
project
level.
C
See
the
the
problem
with
group
level
is
the
head.
Well,
one
of
the
big
reasons
for
doing
it
at
project
level
is
that
you
get
access
to
the
repository,
so
you
can
do
do
stuff
with
that,
whereas
at
a
group
level
you
run
into
like
yeah
permissions
and
what
what
repository
do
I
even
use?
D
B
D
At
the
group
level,
it
seems
like
you
need
to
think
in
in
aggregates,
like
when
you're
at
the
group
level.
You
need
to
scan
all
the
projects
beneath
yourself
and
then
do
some
stuff
right,
some
sort
of
an
aggregation
about
your
repositories
and
so
on.
So
then,
at
the
project
level,
you're
just
doing
that
aggregation
for
a
single
project
or
something
something
along
those
lines,
but
yeah
we
don't
have
all
the
answers.
B
You
don't
want
to
think
about.
Oh
sorry,
go
ahead.
D
Yeah,
I
didn't
hear
about
a
request
like
that
just
yet,
but
I
don't
I
don't
know.
B
Yeah,
we
might
want
to
think
about
ways
in
which
project
level
features
that
need
a
harvard
repository
could
be
started
to
be
implemented
at
the
project
repository
or
the
project
name
space
level,
and
that
could
unblock
some
feature.
Work.
C
A
If
you've
ever
seen
a
issue
that
someone
was
requesting
repositories
on
group
level,
if
you
stumble
upon
those
issues,
please
send
them
my
way,
because
that
can
be
like
something
to
read
and
explore
with
designers
with
pms
and.
A
C
Okay,
I've
run
out
questions.
I
feel,
like
I've
been
talking
a
lot.
A
Those
were
great
questions,
but
if
there's
nothing
else
to
to
say,
let
me
let
me
just
say
that
if
you
ever,
you
know
come
up
with
another
question.
Please
bother
us
on
slack.
We
love
questions
about
that
and
the
links
are
in
the
doc
and
then
I
will
finish
the
recording.