►
From YouTube: 2021-10-06 Workspace weekly
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
Okay,
well
welcome
everyone
to
the
first
workspace
weekly.
I
put
a
template
in
the
agenda
very
briefly,
so
I
expect
this
format
to
definitely
change,
and
I
really
appreciate
the
help
that
you've
already
given
me
by
kind
of
filling
out
some
of
this
in
advance.
Here's
melissa.
A
So
some
of
this
is
just
information
that
I
know
that
melissa
and
I
will
need
to
have
and
then
in
the
future
gosha
as
well,
because
she'll
be
the
work
space,
em
she's,
already
the
acting
em4
workspace
and
we're
really
trying
to
work
this
project
into
the
normal
product
development
flow,
and
so
we
don't
have
to
go
over
relate
all
of
it
like,
for
example,
slippage.
A
If
you
all
have
anything
that
you
see
is
labeled
as
14
4,
and
you
know
that
it's
not
going
to
be
14
4,
please
do
surface
it,
but
I
think
that
would
be
an
example
of
one
capacity
as
well.
This
is
a
really
opportune
time
to
go
over
capacity,
because
the
next
release
starts
basically
the
end
of
next
week,
but
that's
probably
not
an
every
every
week,
topic
either
and
then
progress
and
blockers.
So
before
we
get
started
on
that,
does
anyone
have
any
questions.
A
Okay,
so
capacity
for
next
release
for
all
of
you
on
the
call,
please
fill
out
pto
ninja
in
advance.
If
you
can
and
then
we
can
go
into
progress
and
blockers,
so
I
checked
the
epic
for
phase
one
and
it
looks
to
be
75
done
every
time.
I
check
this
epic.
You
all
have
made
significant
progress
like
almost
every
other
day
it.
The
issues
closed
just
keeps
increasing.
A
C
I
guess
this
whole
project
will
be
somewhat
similar,
at
least
that's
my
so
far.
That's
my
experience
because
we
just
uncovered
things
that
we
didn't
thought
of,
but
if
there
is
a
better
way
to
do
this,
then
let's
discuss
it
yeah.
I
took
the
liberty
to
move
some
of
the
issues
in
the
epics
and
and
try
to
kind
of
restructure
it.
But
again,
if
there
is
too
much
noise
or
anything
that
we
can
do
better,
let
me
know
let
us
know
but
yeah.
C
I
guess
that's
like
I've
been
mentioning
with
the
with
the
one
bigger
I
think
issue
that
is
left
with
preload,
where
yeah
loading
the
groups
at
this
point
just
historically,
because
we
didn't
have
any
other
types
for
the
namespaces
we
loaded.
Basically,
everything
from
the
namespaces
table.
Consider
that
a
group
for
something
along
those
lines,
and
now
we
have
different
types.
C
So
we
need
to
exclude
the
project
namespace
not
be
loaded
because
it
doesn't
really
behave
as
a
group
or
as
a
namespace
yet
so
that
is
a
bigger
issue
that
maybe
can
be
broken
down
into
smaller
ones.
But
I
don't
know
if
there
is
any
any
way
to
like
really
separate
some
of
the
these
exclusions.
Maybe
there
is,
and-
and
if
there
is
there
will
be
ideally,
we
would
have
multiple
issues
and
have
probably
several
engineers
work
on
that.
C
D
Yeah,
maybe
it's
it
depends
on
on
what
what
exactly
we
expect
or
from
this
exclusion,
because
so
far,
my
understanding
is
that
we
need
exclusion
from
getting
the
project
namespaces
when,
when
you
are
fetching
groups
in
the
hierarchy,
yeah.
So,
for
example,
you
are
getting
all
the
descendants
for
a
group
yeah.
D
I
couldn't
think
of
any
other
use
cases
when
we
would
need
to
filter
out
filter
out
project
namespace,
because
in
most
situations,
when
you
work
with
a
group,
you
just
work
with
a
group
model.
So
you
search
by
type
here,
so
there
is
no
chance
that
project
namespace
will
be
mixed
in
the
main
reason
why
we
need
to
exclude
this
project
in
spaces.
Is
that
it's
a
different
type,
so
the
rest
of
the
code
would
start
crashing
because
it
would
return
project
namespace
instead
of
group,
but
so
far.
D
But
we
have
to
prepare
the
code
in
phase
two,
I
mean,
for
example,
we
when
we
want
to
start
getting
issues
both
from
groups
and
project
nice
faces.
First,
we
have
to
update
the
code
or
the
query,
which
works
with
it
to
be
ready
that
also
project
namespace
is
returned.
So
that's
the
only
reason
why
we
need
to
exclude
the
project
namespace
at
this
point.
C
I
think
there
are
some
instances
at
the
namespace
model
level
just
because
I
think
some
of
the
at
least
I've
seen
in
this
some
of
the
validations.
It
makes
the
assumption
that
only
like
namespaces
of
type
like
it
doesn't
even
check
that
nature
is
of
tough
group,
will
have
will
have
children
so
so,
just
because
group
and
project
namespace
in
here
is
from
the
namespace.
There
is
some
functionality
now
that
doesn't
account
for
the
namespaces
to
be
of
type
project
namespace.
C
C
Maybe
we
can,
we
can
do
some
more
detailed
discussion
and
see
how
we
can
break
it
down
into
probably
several
issues
or
something
but
yeah.
D
Yeah,
so
maybe
if
you
could
add
a
comment
to
to
the
issue
about
this,
maybe
it
would
be
a
great
starting
point
at
this
point.
I
I'm
not
exactly
sure
what
each
of
this
sub
issue
should
actually
address.
C
A
D
D
C
It's
right-
and
this
is
the
create
project
name
space
when
a
new
project
is
created,
and
this
cannot
be
done
until
we
we're
doing
what
we've
just
been
discussing
filtering
out,
the
project
name,
spaces
on
fetching
groups
and
namespaces
and
so
on.
So
there
is
a
dependency.
I
think
it's
also.
It's
not
included
as
a
dependency.
Now,
because
it's
it's,
it's
moved
now
as
an
epic,
but
hopefully
it's.
C
I
thought
it
should
be
clearer
from
this
view,
but
maybe
not,
and
then
we
also
have
in
this
phase
the
username
spaces,
which
we
would
want
to
pre-populate
as
well
for
all
or
backfield
back
actually,
which
means
we.
We
only
need
to
change
the
type
for
the
ones
that
are
nil
into
a
user
type
and
we
are
already
creating
we're
already
creating
the
user
type
namespaces
and
we
have
like
yeah.
We.
C
B
D
D
D
This
epic
blocks
backfilling
of
project
namespace
for
every
project.
C
D
A
I
really
appreciate
how
proactive
you're
all
being
in
organizing
these
epics
for
us
and
just
for
transparency,
a
lot
of
these
backfill
issues
like
even
for
the
user
name
space
stuff.
A
A
And
so
phase
two
there's
only
12
issues
in
this
epic
and
so
correct
me
if
I'm
wrong,
but
it
sounds
like
this
still
needs
a
lot
of
discovery.
I
know
that
jan
you,
you
have
proof
of
concepts
open
that
you're
still
working
on
every
time.
I
check
those
updates
for
the
efficient
querying
so
in
terms
of
progress.
D
D
So,
regarding
the
efficient
querying,
I
put
the
task
aside
a
few
weeks
ago
and
rather
focused
on
issues
related
to
creation
of
project
namespace.
The
reason
is
that
efficient
querying
was
blocked
by
other
optimization,
which
alex
works
on
on
traversal
ids,
and
I
plan
to
get
back
to
it
in
upcoming
days
but
yeah.
Basically,
there
was
no
progress
on
efficient
querying
investigation
recently.
A
Okay
and
then
for
phase
three,
this
is
migrating
features.
This
is
dropped
from
the
okr
because
there's
still
a
lot
of
other
work.
That
needs
to
be
done
first,
and
so
this
was
kind
of
like
rescheduled.
I
don't
know
how
to
it's
re
retargeted
for
q4,
but
we
do
have
that
new
security
proposal
melissa
and
I
talked
about
we're,
not
sure
the
impact
that
will
have
on
q4,
and
so
this
is
really
just
a
disclaimer
for
you
all
the
new
security
proposal
in
case
you're,
all
unaware
or
if
anyone's
unaware.
A
This
would
require
effort
from
most
of
develo
dev,
most
of
dev
engineers
and
focusing
just
on
security.
And
so
we
don't
know
what
impact
that
will
have
focusing
on.
E
In
the
meantime,
I'll
verbalize,
when
do
y'all
think,
would
be
a
good
time
to
do
some
refinement
and
high
level
estimation
of
basically
what
kind
of
effort
we're
talking
to
migrate
features,
because
at
this
point
I'm
unsure,
if
we're
talking
like
one
milestone
or
like
five
right
to
migrate,
something
like
issues
or
labels,
and
that
would
really
help
as
we
think
about
like
how
we
schedule
this
work
in
the
future.
E
D
So
I
I
think
it's
hard
to
estimate
this
at
this
point,
because
we
are
still
working
on
just
the
basic
structure
which
would
allow
us
to
or
other
teams
to
start
migrating
features.
So
it
depends
on
when
we
are
done
with
with
this
basic
preparation
work.
I
mean
the
initial
phases,
so
it's
hard
to
do
estimations
for
phase
3
or
next
phases.
At
this
point,
or
at
least
I
don't
have
any
idea
when
it
can
be
for
sure
it
will
not
be
one
milestone.
For
example,.
E
C
Yeah,
I
think
somewhere,
maybe
even
in
the
middle
of
phase
two
or
somewhere
along
those
lines
we
can.
We
can
get
some
feeling
on
how
far
how
much
effort
there
will
be,
because,
like
we
at
least
my
understanding
is,
we
will
want
to
provide
at
least
one
two
examples
of
of
migrating
the
features
to
these
levels,
and
then
every
team
can
can
contribute
to
that.
C
A
Okay,
four
is
product
decisions
I
just
kind
of
put
that
there
for
anything.
You
all
want
to
surface,
which
I
think
is
really
this
questions
and
discussions.
This
whole
topic
here,
I'm
actually
just
gonna.
I
think
I'm
just
gonna
move
this
whole
conversation
up
melissa.
I
don't
think
you
need
to
necessarily
make
a
decision,
but
this
would
be
a
good
one
to
collaborate
on
okay.
There
you
go.
C
Yeah,
so
it
was
me
just
thinking
basically-
and
this
is
not
for
the
phase
one-
not
even
probably
for
the
phase
two,
because
we
will
try
to
keep
as
much
in
place
as
possible,
but
once
we
start
moving
features
around,
I
think
there
is
a
that's,
that's,
probably
a
a
phase
where
or
a
moment
where
we
would
want
to
make
these
interactions
for
the
user
clear.
At
least
I
don't
know
how
to
to
call
this
out
because,
like
once
a
project
becomes
a
namespace,
you
can
basically
add
child
namespaces.
C
C
Will
be
no
like
if
we,
my
understanding,
was
that
eventually
we
will
not
have
a
type
in
the
name
spaces.
It
will
just
be
a
name
space
right,
so
every
feature
will
be
at
the
namespace
level.
So
then
we
will
not
be
able
to
differentiate
and
to
know
which
one
is
the
project
which
runs
the
namespace.
Everything
is
going
to
be
a
namespace
or
a
group,
or
you
call
it
how
you
want
it.
C
C
If
you
suggest
the
repositories
to
me,
a
repository
is
just
like
another
feature
and
that
will
be
somehow
linked
to
a
project
in
a
repository
but
yeah.
I
don't
know
this
is
why
I'm
asking
guys,
like
very
I'm,
confused
on
how
we
will
do
that,
transition
from
ux
perspective
and
from
from
from
overall
application
level
but
yeah.
C
B
I
I
also
raise
this
concern
on
one
of
the
issues.
I
think
I
do
think
we're
going
to
have
to
before
we
migrate
any
features.
I
think
we
need
to
actually
get
project
name.
Space
fully
surfaced,
in
other
words
right
now
we're
working
on
excluding
it,
but
that's
a
hack.
We
don't
want
that.
We,
I
think,
before
we
start
moving
stuff
over,
we
need
to
have
the
full
tree
capable
the
ui
updated
to
know
that
it's
a
that.
B
C
C
B
D
B
D
We
we
say
that
both
have
to
exist
together
or
are
presented
to
user
as
just
one
entity,
and
it
doesn't
matter
if,
behind
in
the
code,
we
work
with
project
namespace,
then
no
user
user
facing
change
should
be
needed,
and
at
this
point
these
changes
can
be
done
just
on
code
level
or
code
base
level.
But
I.
F
No,
that
was
my
initial
assumption
on
the
mvc
or
first
iteration.
Is
that
from
the
user
perspective
the
idea
would
just
be
their
environment
would
stay
the
same.
There
would
be
no
change
in
their
interface
because
it's
different,
it's
not
so
much
that
I'm
moving
now
a
feature
over
I'm
strictly
re-architecting
the
foundation
and
the
foundation
is
not
something
that
users
necessarily
interact
with
apart
from
diving
into
groups
or
into
projects.
F
So
if
you're
talking
about
moving
features
around,
that
obviously
would
be
the
concern
where
the
ui
would
come
into
to
impact,
and
I
think
that
was
one
of
the
mvcs
that
was
being
proposed
about
bringing
plan
features
to
the
the
top
names
for
the
top
workspace
level.
But
I
think,
at
least
from
the
point
that
you
were
making
is
that
what
happens
when
we
now
manifest
the
namespace
object
and
stainer
instead
of
project
my
assumption
from
what
I
would
see
as
a
user
would
be,
I'm
not
seeing
a
difference.
E
E
They'll
just
be
containers
of
things
right,
and
what
does
that
ux?
Look
like
right,
number
one
and
then
two
like
what
does
the
transition
path
look
like
from
where
we
are
now
to
that
end
state.
I
think
that's
what
brett
and
alexander
are
bringing
up,
which
is
a
really
valid
point,
and
when
do
we
make
that
title
for
right?
Obviously,
it's
really
early
right
now
too,
but
it's
good
to
think
about
what
that
transition
will
look
like.
B
G
Hi,
I'm
nick
I'm
gonna
be
doing
that
so
yeah
I'll.
I'm
I'm
getting
started
on
on
this
stuff
this
week
and
we'll
start
with
the
mvc
of
how
it's
gonna
work
with
issues
and
and
labels
and
from
there
we'll
try
and
extrapolate
and
see
if
we
can
draw
some
general
principles
for
how
we
go
about
with
this
transition.
G
There's
going
to
be
some
complexity
there.
So,
let's
see
how
it
goes,
but
I'll
try
and
create
a
few
options
and
see
and
see
if
that's
useful,
for
everyone.
F
Generally
right
now,
this
the
work
that
I've
been
doing
was
trying
to
research
and
understand
the
needs
around
it.
What
features
made
more
sense
to
come
to
the
front,
but
it
sounds
like
plans
taking
the
lead
on
that
which
that's
fine,
so
I've
been
spending
time
doing
or
trying
to
organize
user
interviews
versus
admins
on
how
they
would
interact
or
manage
or
requirements
listing
for
the
workspace
and
how
they
would
want
to
manage
it
or
work
with
it.
C
C
F
So
it's
kind
of
just
like
a
a
dummy
placeholder
until
we
move
further
along
the
the
idea
or
excuse
me
the
process
to
visualize
or
manifest
the
creation
of
that,
so
we're
not
necessarily
allowing
anyone
to
create
that
in
a
different
capacity
right
now,
via
the
new
project
or
new
subgroup
or
new
group
button.
It's
just
now,
you're
making
a
new
namespace
object.
B
B
C
Yeah,
I'm
just
saying
that
we
will
always
have
this.
Dangler
project
record
object
linked
to
the
project
namespace.
We
could
not.
We
could
not
have
some
project
namespaces
that
have
it
just
just
have
to
have
it
and
some
that
don't
have
it.
It's
just
like
a
project
namespace.
Even
though
it's
a
namespace
and
the
user
sees
as
a
project
on
the
backend,
we
still
need
to
have
a
copy
of
the
project,
object
itself
in
the
database
and
in
all
other
places,
I
would
say.
D
G
Of
ins,
two
types
of
scenarios
that
occur,
one
is
the
the
feature.
Functionality
is
just
the
same,
and
the
namespace
is
effectively
impersonating
a
project
or
a
group
or
whatever
that
may
be,
and
then
scenario
two
is
by
introducing
that
feature
to
a
new
namespace
that
is
enabling
more
functionality
like,
for
instance,
you're
saying
that
a
project
could
have
then
nested,
namespaces,
underneath
neath
and
and
so
on
so
yeah.
G
Maybe
maybe
we
start
to
try
and
think
about
how
how
we
we
approach
the
design
in
the
back
end
for
these
different
scenarios
and
create
some
principles
out
of
it.
D
So
the
ability
to
for
project
management
is
to
have
any
other
namespaces
as
children.
I
think
it's
not
decided
or
necessarily
plan
it.
At
this
point
I
mean
really,
it
can
be
just
the
final
final
feature,
edit
yeah,
so
we
can
keep
the
restriction
that
project
namespace
is
a
leaf
node
in
the
hierarchy.
As
long
as
we
need
yeah
so
yeah
just
to
be
aware
of.