►
From YouTube: Manage:Spaces - Category and Direction Discussion
Description
Eric Brinkman and Jeremy Watson discuss a possible direction for the Spaces group within the Manage stage.
A
Cool
thanks,
I've
just
switched
on
recording
I'm
Jeremy
Watson
I'm
here
with
Eric
Brinkman,
we're
talking
a
little
about
the
spaces
group
here
at
git,
lab
and
kind
of
what
that
some
of
the
problems
that
that
group
is
going
to
solve
regarding
workspaces
and
teams
Eric,
you
were
just
talking
a
little
bit
about.
You
know
how
you
kind
of
see
kind
of
like
our
category
strategy
right
now
and
some
of
the
problems
that
we
should
kind
of
concentrate
on
solving
a
time
in
the
near
future.
Yeah.
B
B
Maybe
we've
designed
our
categories
in
the
spaces
group
to
be
maybe
too
prescriptive
and
how
we,
how
we're
actually
going
to
like
implement
like
the
actual
outcome,
that
we
want
the
spaces
team
to
do
and
I
said
so.
I
was
about
to
share
my
screen
with
Jeremy
when
he
very
kindly
recommended
that
we
record
this,
which
it
was
a
great
idea.
B
This
screenshot
is
essentially
what
I
think
we
all
and
when
I
say
all
of
us
I
mean
myself,
you
Luca
Tim
Zalman
from
engineering,
a
kind
of
agreed
direction
like
we're
the
spaces
team
to
go
in
terms
of
the
outcome,
we're
delivering,
and
so,
if
you
look
at
this
screen,
I
think
this
is
what
I
would
expect
if
I
have
it
some
sort
of
team
concept
inside
of
the
gate
lab
where
there's
a
there's,
a
landing
page
I
can
tell
very
quickly
who's
in
who's.
In
my
team,
I
can
bear.
B
I
can
tell
very
quickly
to
the
work
that
the
team
is
doing,
what
projects
they
care
about.
What
what
is
the
feed
from
an
activity
perspective,
perhaps
even
like
what
code
could
review
actions
are
outstanding
and
I
actually
really
like
this
screen
in
general,
because
the
way
that
these
teams
are
kind
of
organized
is
software
development.
B
Web
mobile
backends,
like
it's
a
single
team,
but
if
we
take
like
manage
as
an
example
like
we
could
have
manage,
be
the
top-level
team
here
and
then
we
could
say:
okay,
these
are
the
manage
PMS
or
even
these
are
the
the
team
members
for
say
access,
and
then
you
can
even
break
it
down
further
and
say
these
are
the
front-end
engineers
for
access
to
the
back
end
engineers
for
access
and
I
kind
of
just
have
this
visualization
of
like
a
drill
down
capability.
It's
a
specific
teams.
B
It's
like
you
could
start
at
the
top
level
and
and
like
for
me,
I
could
I
could
just
go
to
the
manage
team
page
and
say
this
is
all
the
work
that
the
manage
team
is
doing
and
the
things
that
are
delivering,
maybe
even
have
like
a
burn
down
chart
for
the
for
the
release
that
were
we're
doing.
You
can
do
some
of
this
today,
but
you
have
to
use
labels,
but
this
would
be
just
a
better
experience,
I
think
in
general
and
then,
like
you,
know,
Jeremy
you
as
the
group
manager.
B
That
would
be
useful
view
for
you,
but
say
for
Luca
who's,
the
the
PM
for
four
spaces
like
she
could
drill
into
the
spaces
group,
and
then
maybe
the
engineering
managers
could
drill
in
you
know
into
into
individual
back-end
and
front-end
components,
and
so
I'm
curious.
If
and
I'd
love,
to
get
your
thoughts
on
this
Jeremy.
B
A
Think
reliant
like
I
think
that,
though
we
started
out
the
spaces,
we're
thinking
with
two
with
two
primary
categories.
There
are
other
categories,
but
the
main
things
that
this
group
is
focused
on
our
teams
and
workspaces.
I
think
that
the
the
right
way
of
thinking
about
it
is
is
not
that
we're
going
to
introduce
like
a
new
concept
and
a
new
object
and
get
lap
call
teams.
The
way
that
I've
been
thinking
about
it
is
that
we
need
to
solve,
for
the
need
of.
A
There
is
no
kind
of
like
first
class
concept
of
being
able
to
create
a
people
only
group
in
gitlab
and
the
problems
that
the
manifesto
or
in
terms
of
issues,
we
can't
assign
issues
or
tasks
to
teams
of
people
where
they
can
triage
them
as
a
team
and
then
assign
them
for
it
to
individuals
from
there
for
portfolio
planning.
We
cannot.
We
do
not
know
which
groups
are
people
only
groups
to
be
able
to
assign,
like
a
you
know,
a
number
of
an
amount
of
capacity
to
what
that
group
of
people
can
accomplish.
A
A
Do
we
do
that
with
an
individual
object
or
do
to
do
that
with
with
the
confines
of
the
group
structure,
same
thing
with
workspaces
which
we're
not
you
know,
I'm,
not
interested
in
necessarily
adding
a
ton
of
complexity
of
the
product,
and
you
know
making
it
harder
for
us
to
iterate
by
adding
this
new
concept
called
a
workspace
all
of
a
sudden
there's
a
new
thing
that
we
have
to
deal
with
their
nest
groups
than
that
I.
Don't
the
problem
that
we
want
to
solve
is
that
especially
for
get
live?
A
Comm
groups
are
not
sufficient
for
the
amount
of
security
and
capabilities
that
someone
on
get
live.com
really
needs
to
be
successful.
So
those
are
the
problems
that
we're
trying
to
solve
with
those
categories.
How
we
do
it
I
I
have
not
seen
like
a
you
know,
a
proposal
that
says
that
you
know
groups
are
not
going
to
be
sufficient.
We
need
to
go
beyond
that,
like
I.
Have
no
evidence
thus
far
that
that's
the
case.
A
Until
we've
proven
out
the
mean
like
we
actually
have
to
have
to
like
have
this
concept,
which
is
going
to
be
totally
independent,
and
then
we
can
propose
that
as
a
category
and
then
make
a
case
for
that,
then,
but
I
think
that
you
and
I
are
aligned
like
when
you
walk
through
spaces
like
that's
exactly
kind
of
like
how
I've
been
seeing
it
in
my
mind,
which
is
being
able
to
drill
into
different
teams
at
gitlab.
You
know
the
manon
see
you
as
like
a
product
director.
A
Can
click
into
the
spaces
group
see
everyone
on
that
page,
get
a
sense
of
kind
of
what
everyone
is
doing
or
working
on
what
our
priorities
are,
and
then
you
know
without
having
to
hunt
around
in
the
product
like
look
around
for
like
filter
by
issues.
Look
at
Direction
pages.
You
just
have
everything
in
a
safe
place,
so
I
think
that
we're
definitely
aligned
and
I'd
love
to
see
what
what
did
you
think
about?
How
do
you
think
our
category
should
evolve?
I
just
mentioned,
possibly
even
removing
them
for
right
now.
A
B
Let
me
pull
up
the
category
page.
Just
so.
I
can
get
the
full
lay
of
the
land
here
and
I.
Think
there's
three
right:
oh
there's,
four
users.
Okay,
so
we
have
so
groups,
users,
teams
and
workspaces,
and
teams
and
workspaces
are
the
two
new
ones
that
we
added
we
renamed
groups
and
made
that
in
the
summer,
so
some
groups
and
users
I
think
they
stay.
B
We,
you
know
shouldn't
touch.
Those
are
pretty
foundational
to
the
product
at
this
point
in
time,
teams
and
workspaces
I
think
after
digging
and
a
little
bit
more
here's
kind
of
what
I
was
thinking
last
night
and
this
morning,
which
is
I,
think
maybe
teams
goes
as
a
category
because
I
think
by
nature
of
teams
being
introduced
as
a
category.
We
basically
decided
that
subgroups
can't
be
used
as
as
teams
but
I,
actually
like
workspaces
as
a
category
or
maybe
it's
just
spaces.
B
Maybe
it's
the
spaces
group
with
the
spaces
category,
which
is
kind
of
a
rallying
cry
to
build
that
outcome.
That
experience
that,
like
landing
page
in
the
application
where
the
team
lives
as
a
as
an
experience
because
I,
don't
think
that
you
would
just
put
that
as
a
sub
feat
like
to
me:
that's
not
a
sub
feature
and
a
sub
group.
It's
not
a
sub
feature.
The
user,
like
it's
its
own
experience
with
its
own
maturity,
I
think
you'd
want
to
mat
measure,
so
I
guess
my
might
take.
B
B
But
then
we,
we
kind
of
refactor,
that
category
direction
page
to
basically
describe
the
outcome
that
we
want
and
then,
if
we
can
use
subgroups
to
get
it,
if
we
can
use
users
to
get
it,
we
can
use
groups
to
get
it
that's
great,
and
if
we
need
a
new
object,
a
new
object
or
new
construct
in
the
application.
I
think
that
we
can
cross
that
bridge
when
and
get
there.
If
we
need
a
new
category,
if
like
say
subgroups
can't
solve
the
problem
for
us,
yeah.