►
From YouTube: 2022-06-01 Workspace project meeting
Description
some of the discussion was cut.
B
B
A
B
If
I'm
a
p.m
or
I
don't
know-
and
I
have
multiple
projects
that
I
need
to
take
care
of-
that-
I
need
a
single
place
where
I
can
create
issues
in
different
places
of
those
projects
right,
so
that
I
don't
have
to
go
to
every
single
project
to
create
my
specific
issue,
I'm
just
on
a
single
page,
creating
my
those
same
like
three
or
five
or
ten
issues,
but
from
a
single
page.
I
don't
have
to
navigate
to
multiple
places.
I
think
that
kind
of
solves
what
you're
describing
right.
B
I
don't
need
to
go
and
to
like
navigate
through
all
this
messy
structure.
I
just
need
to
be
able
to
create
my
things
in
the
places
that
I
want
to,
but
but
then,
from
a
permission
standpoint
I
think
it's
easier
to
comprehend
and
understand
when
you
have
a
very
rigid
structure
rather
than
when
you
have
a
lot
of
these
relationships,
because
then
that's
very
easy
to
mess
up
like
it's
very
easy
to
to
link
a
group
to
another
forget
about
that,
and
then
don't
realize
that
you
actually
have
their
people.
B
That
should
never
be
seeing
stuff
that
you
define
in
this
other
place,
or
things
like
that
right,
whereas
when
you
have
this
very
well-defined
structure,
you
you
kind
of
it's
easy
to
understand
how
how
things
are
flowing,
at
least
from
mine.
From
my
perspective,
I
don't
know,
that's
exactly
true,
but
that's
how
I
understand
and
then
for
the
top
manager
or
executive
level.
Again,
I
think
that
is,
I
don't
think
they
care
too
much
about
how
the
structure
is
done.
But
more
of
how
do
I
see
what's
happening.
B
A
Feel
like,
if
that
that
complicated
node
sharing
right,
that
problem
is
a
going
to
be
a
performance
problem.
If
you,
inter
web
in
inter
connect
too
much
like
permission
inheritance
and
things
like
that,
we
know
that's
going
to
be
performers
problem.
But
is
there
a
way
to
like
extract
that
data
right
in
just
a
consuming
a
viewing
part
of
it?
That
is
going
to
be
performant?
Or
is
that
always
going
to
be?
B
So
so
let
me
just
so
that
I
understand
what
you're
asking
so
there
are
two
aspects
to
this
like
interconnectivity
right,
the
the
part
where
I
want
to
view
stuff
in
a
lot
of
groups
and
the
part
where
I
want
to
create
stuff,
and
so
to
me
these
are
very
two
very
different
actions
and
to
very
different
way.
Like
direct.
There
needs
to
be
two
different
ways
to
approach
it.
B
The
the
viewing
part
can
be
easily
solved
by
a
tooling,
like
you
have
a
page
where
you
can
select
one
or
two
and
a
million
groups
that
you
want
to
aggregate
data
from.
Even
if
those
are
not
related
or
stuff
like
that
right,
you
can.
You
can
suck
in
data
from
there
and
present
it
in
a
table
format
or
whatever
you
want
to
present
it.
B
So
that's
consuming
the
data
from
a
lot
of
the
places
and
that
doesn't
require
these
places
to
be
interconnected,
so
that,
because,
like
we
know
the
permissions
of
the
person
that
wants
to
to
view
this
stuff
anyway
right,
so
we
don't
have
to
interconnect
them.
If
they
have
permissions
there,
they
will
be
able
to
see
it
for
the
creation
part,
that's
a
bit
more
complicated,
I
think
but
yeah
I
I
don't.
B
A
What
I'm
basically
driving
at
is,
is
I
what
I've
seen
is
organizations
want
to
organize
their
stuff?
This
way
and
users
want
to
view
it
this
way
right
and
the
users
I'll
give
you
an
example.
I
I
you
know
I
get
up
this
morning.
I
got
emails,
I
go
in
there
and
I
have
two
two
emails
to
two
different
projects.
One
is
in
the
get
lab
project
and
one
is
in
the
gitlab
svg
project.
A
I
don't
care
about
that
information.
What
I
care
about
is
the
email
that
I
got
and
the
information.
What
is
the
task?
What
was
the
comment
that
I
was
given
right?
The
fact
that
it's
in
the
svg
project
and
this
one's
in
the
gitlab
project
is
largely
irrelevant
to
me
at
the
moment,
because
I'm
just
responding
to
the
comment
and
the
task
that
that's
at
hand
right.
A
So
in
that
sense,
like
I,
don't
have
to
know
anything
about
the
structure
of
how
these
projects
are
organized.
For
me
to
do
my
daily
job,
but
those
projects
are
structured
that
way
because
they
are
accomplishing
very
different
tasks
and
one
project
is
meant
to
do
this.
One
is
meant
to
do
this,
so
I
kind
of
always
feel
like
we're
going
to
have
this
this
way
that
people
want
to
organize
stuff
and
there's
other
way
that
people
want
to
view
stuff.
I.
A
B
B
You
would
you
would
see
all
of
your
tasks
whatever
you
need
to
do
in
one
place
and
just
respond
from
there.
Be
it
comment
or
be
it.
I
don't
know
upload
a
design
or
or
create
a
merge
request
for
that
change.
You
you'll,
do
it
from
one
single
place
rather
than
having
to
navigate
to
these
different
places.
To
to
accomplish
your
tasks.
Is
that
what
you're
saying
yeah.
A
Yeah
that
may
be
a
a
workspace
is
not
another
organizational
structure.
It's
a
view
into
how
you
want
to
see
your
data
from
your
perspective
right
whether
that
perspective
is
you
personally
or
you
know,
you're,
maybe
you're,
sitting
higher
up
and
it's
a
way
to
aggregate
data
right
yeah,
but
that's
more
of
a
view
into
the
data
than
how
it
actually
has
to
be
organized.
B
Yeah,
I
wonder
if
this
is
more
of
a
front-end
implementation
question
rather
than
how
the
data
is
organized
because,
as
you
said
like,
I
don't
care
in
what,
in
what
part
of
the
hierarchy
that
message
or
that
issue
is
all
ikea,
is
being
able
to
see
it
and
respond
to
it
and
then
be
able
to
see
the
feedback
right.
So
yeah.
A
B
Like
all
I'm
trying
to
say
is
like,
and
I'm
not
I'm
a
background
engineer,
so
I
might
be
saying
a
lot
of
nonsense
here
and
what
I'm
trying
to
allude
to
is
that
there
are
these
single
page
applications
right
where
you
don't
have
to
navigate
to
a
lot
of
places.
You
can
do
a
lot
of
stuff
from
one
single
page.
You
just
like
the.
B
B
Click
send
and
it
goes
away,
and
you
see
your
dashboard
or
I
don't
know
what
the
landing
page
of
that
single
page
application
is,
but
that's
basically
the
page
that
you
are
always
coming
to
and
seeing
do
I
have
more
tasks
to
do.
If
I
do,
I
click
on
it.
I
get
the
contextual
window
so
to
say
right
when
I,
if
it's
mesh
request
it's
a
different
kind
of
interface.
If
it's
a
issue,
it's
a
different
interface,
but
I
don't
have
to
to
kind
of
always
be
aware.
A
A
A
A
Right
and
really
like
from
a
consumption
side,
maybe
it's
better
to
just
see
issues
right.
I
go
to
issues
first,
that's
the
thing
I
care
about.
What
am
I
worried
about
today?
I'm
worried
about
merge
requests.
Am
I
worried
about
security
things
right
like
I
go
to
the
thing
first
and
then
find
the
thing
that
happens
to
be
in
a
project.
You
know
flipping
the
navigation
upside
down
where
right
now,
like
project
and
group,
is
kind
of
the
top.
A
I
always
have
to
go
to
the
project
then
make
the
decision
what
things
I
care
about
issues
feature
flags
whatever.
Maybe
I
would
just
want
to
see
like
issues
and
see
them
broadly
across
everything
that
I
have
access
to,
and
I
want
to
see
merge
requests
broadly
across
everything
right
flipping
the
navigation
upside
down.
A
B
I
have
a
ton
of
issues
in
in
a
lot
of
projects.
I
don't
really
care
whether
issue
is
is
leaving
as
long
as
I
have
permissions
to
access
that
issue
and
respond
to
it.
I
don't
really
care
if
it's
from
coming
from
gitlab
work
or
gitlab.com
or
whatever
place
it's
coming
from.
I
just
need
to
be
able
to
see
what
my
issues
are.
What
can
I
work
on
next
and
respond
to
those
and
do
my
job
where
that
becomes
important
is
for
the
people
that
do
manage
these
projects,
because
then
they
need
to
realize.
B
A
B
Yeah
yeah,
I
agree,
but
at
the
same
time
I
think
the
the
organizer,
the
one
that
organizes
when
they
want
to
consume
things
they
want
to
consume
in
the
same
level
as
the
developer
wants.
They
don't
need
to
go
to
different
places.
They
want
to
see
the
same
interface.
Well,
these
are
the
the
things
that
I
need
to
consume.
These
are
the
things
that
I
need
to
act
upon,
so
this
is
the
same
ui.
When
I
need
to
organize
things.
B
B
Yeah,
I
think
we,
I
think
we
already
do
that
from
from
the
back
end
perspective,
because
we're
pulling
things
from
different
places,
yeah.
What
I
think
we
don't
do
is
we
don't
present
them
in
that
way?
Yeah
like
we
don't
have
well,
we
do
have,
but
we
don't.
We
don't
have
this.
I
think
it's
dashboard
issues
or
something
where
I
see
all
my
issues
right,
but
I
don't
think
that's
a
very
used
feature
for
some
reason.
A
B
B
But
then,
when
you
want
to
create
an
issue,
then
that's
when
one
kind
of
the
organizer
in
the
developer
needs
to
to
get
in
right
when
I
want
to,
because
I'm
part
of
gitlab
working
gitlab.com
and
when
I
need
to
create
a,
I
don't
know
a
match
request
to
change
my
status.
Where
my
my
bio
on
the
team
page,
I
need
to
go
to
gitlab.com.
B
So
then
that's
where
I
need
to
know.
Where
do
I
create
that
message
request?
So
that's
that's
where
a
bit
of
the
organizer
decision
needs
to
come
in.
So
that's.
Maybe
where,
like
this
separation
of
workspaces
and
and
things
like
that,
would
come
in
yeah,
I
don't
know
again:
it's
I'm
not
getting
the
solutions,
I'm
discussing
with
you
as
well
as
but
like
from
from
beckham
perspective
I
do
have.
I
don't
think
we
have
a
lot
of
the
pieces
in
place
to
do
that
again.
I'll
say
it
again.
B
A
B
Yeah
I
kind
of
like
thinking
about
this,
like
when
you
get
that
email
with
the
link
to
the
issue
instead
of
being
brought
into
the
issue
page
only.
It
will
be
nice
to
be
brought
into
a
more
of
a
board
view
or
more
of
a
like
your
to-do's
list
view
with
the
issue
emphasized
or
the
issue
open
right.
So
then,
when
you
close
it
you
you.
B
I
think
that's
not
very
consumable
as
well,
at
least
for
me
as
a
developer
right,
because
there
is
always
a
lot
of
stuff
there.
That's
not
related
to
me,
so
maybe
a
better
page
for
me
would
be
the
group
page
with
the
issues
that
are
assigned
to
me
or
were
somehow
related
to
the
work
and
work
some
or
issues
where
I
was
notified,
or
something
like
that,
but
that
from
there
I
should
be
able
to
zoom
out
and
and
pick
up
some
other
work
that
I
need
to
do
right.
A
If
you
were
the
kind
of
company
that
structured
yourself,
where
you
had
like
one
project
for
the
mobile
app
one
project
for
the
the
website,
one
project
for
your
tv
streaming
app
right,
but
all
of
those
were
source
code
to
look
at
those
and
say
like.
Oh,
I
think
we
created
an
issue
about
that.
You
have
to
go
up
to
the
project
up
to
the
project
after
the
project
and
it's
just
impossible
to
look
at
it
so
like
also
from
that
perspective,
it
would
be
nice
to
see
like
no.
B
B
B
So
it's
basically
similar
to
what
boards
are
now
right,
because
you
have
this
you,
you
can
construct
your
boards
at
the
group
level
so
that
it
cuts
through
a
lot
of
the
projects
and
so
like
it
doesn't
have
the
full
capability,
but
at
least
theoretically
you
can
say
well.
I
want
this
board,
even
though
I
have
10
projects
beneath
this
group.
I
want
this
board
to
only
look
at
these
two
projects,
because
this
is
the
view
that
I'm
interested
about,
and
these
are
the
projects
that
I'm
actively
working
on
right.
B
So
any
issue,
I
can
click
on
that
and
add
in
the
description
or
add
a
comment
or
or
or
do
stuff
from
that
kind
of
a
view
that
you
are
suggesting
about
right.
I
have
a
view
that
cuts
across
these
specific
groups
or
projects
or
whatnot,
and
I
I
interact
with
that
data
and
I
can
view
it
in
different
ways.
B
B
A
B
A
B
Too
I
mean
I
I'm
yeah,
it's
cool,
it's
always
nice
for
me
to
discuss
these
kind
of
things,
even
though
I'm
not
very
much
involved
into
designing
or
thinking
them
like
at
that
product
or
or
designer
level,
or
react
or
ux
or
anything,
but
like
yeah
yeah.
That's
like
I
don't
know,
even
as
a
back-end
engineer,
I'm
somehow
all
like.
I
need
to
understand
the
whole
picture.
First,
before
I
kind
of
go
and
do
something
right.
B
A
B
Yeah,
it's
it's
a
good,
it's
a
big,
it's
a
long
way
from
using
stuff
and
designing
stuff
for
sure
and
having
like
using
it,
having
opinions
to
thinking
it
through
and
designing
it.
The
way
that
it
should
work
so
yeah
that
you
have
a
yeah,
a
big
amount
of
work
in
in
in
your
hands
there,
and
I
I
totally
I'm
sure
that
is
it's
a
tough,
tough
job.
So
I'm
not.