►
From YouTube: Protect / Workspaces PM Sync
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).
B
B
So
we're
talking
about
workspaces
and
workspaces
has
been
a
project
that
we've
been
talking
about
for
years
and
we're
finally
acting
on
it.
This
is
previously
known
as
simplifying
groups
and
projects,
unless
there's
a
slack
channel
called
simplifying
grouping
projects
where
you
can
ask
all
the
different
questions
that
you
have
about
workspace
at
the
moment.
B
What
we're
planning
on
creating
is
that
the
workspace
would
be
the
top
level
name
space,
so
that
would
be
include
all
your
groups
and
your
subgroups
and
your
projects
and
your
whatnot
now
the
way
that
we've
decided
to
implement
this
in
terms
of
the
technical
architecture
is
that-
and
this
is
a
bit
different
weird,
because
our
end
goal
is
to
create
a
top-level
name
space
which
we
know,
there's
a
hierarchy
that
you
have
everything
and
the
goal
of
this
there's
actually
several
goals
for
workspace.
B
One
of
them
is
to
get
to
feature
parity
between
self-managed
customers
and
says
because
at
the
moment
sas
customers
are
on
a
disadvantage
because
their
all
the
instance
level
features
do
not
exist
for
them.
Our
top
level
is
a
top
level
group,
but
you
can
do
anything
in
instance,
level.
So
it
doesn't
cascade
down
to
everything.
B
And
really
what
that's?
What
we
want
to
do?
We
want
to
bring
that
experience
of
the
admin
panel
into
the
top
level
namespace,
but
also
let
you
do
everything
at
the
instance,
which
will
now
be
called
the
workspace
level.
The
only
difference
we
should
see
between
self-managed
and
sas
users
at
the
end
of
this
project
is
the
hardware
settings
which
are
not
applicable
for
sas
users,
so
that
should
go
away
and
everything
else
should
probably
be
the
same
now.
The
way
that
we
started
the
project
is
exactly
opposite.
B
So,
as
I
mentioned,
our
end
goal
is
top
level
name
space,
but
we're
starting
from
the
very
very
low
level
container,
and
what
we
want
to
create-
and
this
is
our
goal
or
okr
for
this
quarter-
is
to
create
a
construct,
a
container
that
can
theoretically
be
anything.
It
can
be
a
project,
it
could
be
a
group,
it
could
be
a
subgroup
and
it
can
be
that
topical
name.
B
Space
and
the
only
difference
between
them
is
the
hierarchy
and
what
we
are,
what
we
will
gain
when
this
is
actually
implemented
and
complete
is
that
we
will
get
rid
of
a
bunch
of
redundant
code.
All
of
us
pms
know
that
when
we
want
to
implement
something,
we
actually
have
to
implement
it
at
least
three
times
so
once
for
the
project,
one
for
a
group
and
one
for
the
instance,
and
that
creates
a
bunch
of
redundant
code
that
basically
does
the
same
thing
with
some
nuances.
B
So
that's
the
second
goal,
so
one
goal
was
parity
and
the
second
goal
is
cleaning
up
our
code
base,
which
will
also
have
really
great
positive
effects
like
reduce
weird
behavior
like
sometimes,
if
you
do
something
on
the
group
level,
it
doesn't
behave
as
you
would
expect
in
the
project
level,
and
also
some
security,
vulnerabilities
and
bugs
and
so
on,
which
are
all
because
of
the
weird
way
that
we
implement
stuff.
B
Our
first
group
that
is
joining
the
effort,
is
plan,
and
I
don't
think
that
we'll
we'll
complete
this
as
part
of
the
okr
that
was
supposed
to
be
the
ocr,
we
were
supposed
to
do
a
poc
once
we
had
this
construct
in
place
for
them
to
move
issues
to
that
to
the
top
level
namespace.
So
I
don't
think
that's
going
to
be
complete
this
corner,
but
we
wanted
kind
of
them
to
be
our
first.
B
Pilots,
zero,
do
a
little
poc
on
them
and
then
kind
of
instruct
the
rest
of
the
team
how
we
can
move
our
other
functionality,
because,
basically,
once
we
have
the
contract,
each
team
is
going
to
have
to
move
their
own
features
into
this
new
concept
of
workspace.
A
Yeah,
that
makes
sense,
so
let
me
share
a
little
bit
about
what
we
have
planned
and
then
we
can
talk
about
maybe
where
these
two
come
together
and
some
of
the
timeline
aspects
of
it.
If
that
works
for
you,
so
on
my
team,
we've
got
a
fairly
new
feature.
We
actually
just
turned
the
feature
flag
on
by
default
in
14.3
for
security
policies.
What
this
looks
like
is
in
the
ui.
A
You've
got
your
security
and
compliance
nav
item
and
then
your
policies
area
and
right
now
these
can
only
be
created
at
the
project
level.
So
you
know.
Obviously
the
next
step
for
this
is
users
want
this
at
the
group
level,
and
they
want
this
at
the
instance
wide
or
workspace
level
right,
not
not
tied
to
hardware,
but
they
want
it
for
their
entire
organization
and
these
policies.
Let
them
do
a
really
wide
variety
of
things.
Everything
from
requiring
certain
security
scans
to
be
run.
A
To
requiring
mr
approvals,
when
certain
numbers
of
vulnerabilities
are
found,
there's
a
really
wide
range
of
things
that
these
are
going
to
address,
but
right
now
we're
looking.
We've
got
an
epic
open
and
I
can
share
this
with
you
in
slack,
so
it
doesn't
get
lost
in
the
in
the
zoom
thread,
but
we've
got
these
plans
to
move
it
up
to
the
group
in
the
workplace
level
because
we
know
workspace
is
coming
and
back
when
melissa
was
over
it.
We
talked
about
the
workspace,
and
this
has
been
on
our
backlog
for
a
while.
A
So
I
haven't
really
stayed
up
to
date
with
all
the
plans
regarding
workspace
to
be
honest
for
the
last
several
months,
but
this
is
something
that
we've
been
working
towards
aspirationally
for
a
long
time
and
we're
actually
now
starting
to
get
close
to
being
ready
to
implement
this
so
just
to
share
some
of
the
designs
for
this.
It
would
be
that
same
security
and
compliance
page.
This
would
be
at
the
group
level
we
would
have
it
show
up
as
a
policy
page
we're
adding
in
a
new
column,
basically
saying
where
the
policy
exists.
A
There's
this
flow
down
inheritance,
so
any
policies
that
are
created
at
the
workspace
level
would
flow
down
to
all
of
the
groups
and
projects
beneath
them.
Any
group
level
policies
would
flow
down
and
affect
all
of
the
projects
inside
of
that
group.
So
we
get
some
language
here
showing
that
the
policy
applies
to
all
56
projects
in
this
group.
A
And
just
showing
where
these
things
came
from
right,
if
it's
inherited
from
another
group,
if
it's
inherited
from
a
workspace
or
if
it's
part
of
its
own
group
and
then
of
course
we
want
this
at
the
workspace
level
or
name
space
level,
I'm
really
not
sure
what
the
best
term
is
to
describe
that
at
the
moment.
But
we
want
this
at
a
per
customer
level,
and
I
don't
really
know
what
this
navigation
area
looks
like.
A
But
ideally
customers
would
be
able
to
say
you
know
I
want
to
require
secret
secret
detection
to
run
on
all
of
my
projects
for
all
of
my
groups
and
my
everything
that
I
own
right.
They
can
just
set
that
once
at
a
workspace
level,
and
that
would
flow
down
to
everything
inside
of
it,
so
that
those
are
the
designs
at
a
really
high
level,
and
I'm
just
trying
to
understand,
then
you
know:
does
this
fit
in
with
what
you're
doing?
How
do
we
take
advantage
of
that
inheritance?
A
You
know:
are
there
any
special
considerations
that
our
engineers
need
to
be
aware
of
as
they
go
to
fill
this
out,
and
I
guess
the
other
question
is
you
know?
Would
it
make
more
sense
for
us
to
take
do
this
at
the
group
level
first
and
then
the
workspace
level,
or
just
wait
until
that
new
container
you're
talking
about
is
done
and
build
it
out
in
that
shared
container
anyway,
a
lot
of
questions,
I'm
probably
throwing
too
many
at
you
at
once,
but
that's
the
really
high
level
of
what
we're
so.
B
The
container
is
supposed
to
be
done
by
14
fold,
so
there
isn't
too
much
time
to
wait
for
it.
But
will
that
happen?
I
hope
so.
As
you
know,
things
are
dynamic,
but
the
team
is
currently
working
on
it,
so
it
should
arrive
sometime
soon.
So
it's
up
to
you
whether
you
want
to
work,
wait
for
that
or
already
implement
it.
B
That's
the
short
answer.
What
I
would
suggest
you
to
do
is
ping
gosha
from
our
team
she's,
leading
the
effort
for
space
so
that
she
is
aware
of
this
issue.
B
So
you
know
technically,
she
could
probably
give
you
more
advice
than
I
can
in
terms
of
the
technical
implementation,
I
would
say
imra
because
he
led
the
effort
up
until
now,
but
he's
on
parental
leave,
so
pingosha
and
she
I
mean,
there's
really,
no
reason
why
you
and
plan
can't
work
in
parallel
to
get
your
features
in
there,
so
the
main
blocker
is
getting
the
construct
in
place.
That
container,
because
before
that's
done,
there's
really
no
point
to
work
to
move
anything
to
work
spaces.
B
As
I
said,
it's
a
little
bit
strange
because
we're
starting
bottom
up
instead
of
top
to
bottom,
but
but
I
think
it's
smart.
So
that
is
my
advice
in
terms
of
the
technical
questions
I
I
can't
give
you
better
ones,
because
I
don't
know
enough
about
the
code
base
to
kind
of
guide
you
through
there.
What.
A
About
the
ux
aspect
of
it,
you
know
the
front
end
piece
for
groups,
it's
pretty
clear
where
we
want
that
page
to
live.
What
are
we
looking
at
in
terms
of
navigation
at
that
workspace
level
and
ui.
B
B
So
I
think,
that's
also
being
considered
as
a
part
of
this
for
the
first
mvc
we're
not
even
touching
navigation.
What
we're
doing
is
just
like
giving
you
the
name
of
the
top
level
name
space,
the
workspace
and
probably
just
letting
you
link
quickly
to
the
groups
under
it,
the
the
largest
portion
that
will
require
a
navigation
change
from
our
side
and
what
we're
going
to
prioritize
is
the
admin
panel,
which
does
not
exist
up
until
now
and
says
so
it's
way
too
early
for
me
to
answer
your
navigation
questions.
A
Okay,
so
it
seems
like
probably
the
admin
panel
would
be
the
best
place
for
those
namespace
wide
settings
to
live.
B
Not
at
all,
I
can
show
you
what
the
very
high
level
mockups
look
like.
I
put
this
in
the
documentation,
so
the
link
is,
I
don't
know
why
I'm
gonna
go,
but
the
link
is
here
under
user
workspace.
If
you
just
search
the
docs,
and
you
can
see
that
this
is
kind
of
a
very,
very
preliminary
mock-up
of
what
this
is
going
to
be.
You
have
the
groups,
you
have
specific
features,
this
could
be
a
policy
or
maybe
not
admin,
and
then
you
have
admin
settings
blah
blah
blah.
A
This
will
make
sense,
like
that
looks
good.
I'm
just
trying
to
understand
from
a
mvc
perspective
right
without
having
my
team
go
and
build
all
of
that
ui
you
know.
Would
it
make
sense
for
us
to
just
put
that
in
the
admin
panel
today
and
then
eventually
you'll
get
to
it
and
move
it
over
and
into
sas,
or
you
know
well.
A
B
So
if
you
are
not
willing,
I
would
start
with
group,
because
workspace
and
instance
is
a
little
bit
more
complicated
if
you're
going
to
wait
for
the
admin,
because
I
assume
that
we're
going
to
start
with
lifting
and
shifting
before
adding
new
stuff
and
in
group
you
get
both
sas
and
self-managed
customers.
A
Right,
okay,
so
once
we
have
group
done,
though,
all
right,
okay,
so
that
makes
sense
so
you're,
basically
suggesting
we
implement
it
at
that
top
level
object
that
you're
creating
and
we
make
it
available
for
groups.
But
then
we
wait
to
do
the
front
end
ui
for
the
name
space
or
the
workspace
until
later.
Is
that.
B
B
Because
I
don't
think
this
is
the
final
view,
it's
just
a
very
preliminary
mock-up
to
give
people
like
a
sense
of
what
we're
talking
about,
but
I
think
it's
going
to
take
a
while.
But
I
mean
we
haven't
even
hired
a
front-end
engineer.
Yet.
A
Okay,
all
right
well
I'll,
explore
places
with
my
ux
designer
yeah.
The
admin
panel
definitely
has
the
downside
that
I've
managed
only
so
maybe
the
security
center
we'll
have
to
figure
that
out,
but
it
sounds
like
we'll
just
have
to
find
a
temporary
place
for
the
workspace
management
aspect
of
this
to
live
until
that
view
is
created.
B
Yeah,
just
ping
nick
post
on
it
because
he's
coming
into
the
workspace
designer
position
so
make
sure
he's
in
the
loop.
B
A
Yeah
no
worries
it.
It
just
helps
to
have
a
good
understanding,
because
that
helps
our
planning
right,
even
if
you're
just
a
little
bit
further
out,
like
I
said,
that's,
okay,
just
knowing
that,
so
that
we
can
plan
plan
around
it.