►
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
So
maybe,
to
recap
with
daniel,
I
could
ask
the
question
to
make
sure
I
understand
what
you're
asking
so
you
linked
us
to
a
thread
in
an
issue
around
the
workspace
functionality
greenbrought.com
and
how
it
replicates
or
replaces
what
we
currently
experience
as
the
admin
area
and
self-managed.
B
I
think
what
you're
asking
is,
how
do
you
like
visually,
represent
the
workspace
in
place
of
the
admin
area?
So
when
you're
looking
at
that
drop
down,
you're
showing
like
in
that
or
around
like
the
fly
out
in
the
navigation
item,
were
you
asking
about
that
like
admin
area,
hyperlink,
which
then
opens
into
the
admin
area
page
becoming
like
workspace,
or
something
instead
and
then
opening
into
a
new
version.
A
A
Sorry
I
was
muted,
so
this
was
the
other
part
of
the
screen.
So
the
idea-
or
at
least
the
proposal,
was
that
you
have
this
drop
down.
Similarly
you're
just
looking
at.
B
A
Yeah
and
there's
the
admin
feature
that
we
were
discussing,
that
would
look
like
what
we
would
currently
expect:
the
admin
which
would
be
settings
or
user
administration
or
whatnot
whenever
you
go
to
this
admin
screen
in
the
r
environment
currently,
but
I
was
saying,
should
I
back
up
and
think
about
this
more
long-term,
more
holistically
is
that
this
drop
down
is
functionally
a
list
of
links
to
things
that
should
exist
in
a
contained
environment,
which
would
be
your
workspace
or
your
groups
or
your
milestones.
A
Your
snippets
activity,
wiki,
whatever
you
have
in
terms
of
content
here,
and
would
it
make
sense
to
manifest
this
drop
down,
as
rather
a
navigational
object,
which
has
features
because
of
the
idea
long
term
where
we
want
to
say
I
want
to
be
able
to
click
on
my
groups
or
understand
all
the
analytics
I
have
with
across
my
organization,
monitoring,
whatnot
or
if
I
want
to
click
on
my
groups.
I
see
all
the
groups
that
I
have
for
my
organization
and
sort
of
anything
else.
A
When
I
have
that
we
would
look
at
things
laterally
and
I
say
I'm
using
right
now.
Admin
users
is
a
as
a
kind
of
iteration
on
that,
because
that's
the
first
task
we
have
going
currently.
One
of
my
tasks
was
to
actually
go
through
and
categorize.
The
the
settings
that
currently
exist,
and
so
a
lot
of
the
settings
would
change
to
settings
that
don't
exist.
A
Let
me
back
up
a
step.
If
you
look
at
the
admin
screen
in
our
current
environment,
you'll
see,
there's
a
bunch
of
stuff
that
would
work
for
your
installation
of
gitlab,
which
won't
necessarily
make
sense
if
you're
trying
to
play
with
the
sas
model,
because
obviously
we
would
have
limitations
on
what
people
would
be
doing
within
our
hardware
environment,
for
example.
A
So
that
was
one
of
the
tasks
I
do
is
get
rid
of
all
those
settings.
So
here
at
this
first
iteration,
I
wanted
to
make
sure
that
I
was
thinking
about
it
as
a
long-term
project
as
not
just
oh
we're
going
to
expose
the
admin
as
a
first
thing
right
and
backing
up
a
step
is
exposing
the
admin
the
first
iteration.
B
C
A
B
B
Let's
say,
the
users
from
the
admin
area
is
what's
supposed
to
be
in
the
workspace
setting
or
the
workspace
like
container
as
you're
calling
it
for
this
next
iteration,
then
just
exposing
only
that
one
feature
in
that,
like
admin
area
experience
all
like
we
click
on
workspace,
all
you
get
is
just
like
the
users
and
slowly
you'll
add
in
more
of
the
features,
so
you
reach,
like
the
parity
between
the
hardware
versus
like
the
software
configuration
side,
but
you
go
into
the
slow
additive
approach,
trying
to
reuse
as
much
of
the
admin
area
layout
architecture
as
possible,
mostly
just
like
toggling,
on
what
users
can
or
cannot
see,
but
that's
just
my
assumption
of
what
would
work
well
with
engineering.
A
Yeah
and
that's
exactly
what
we're
thinking
more
or
less
is
that
which
caused
me
to
back
up
a
bit
is
that?
Well,
I
thought
to
myself:
perhaps
I
shouldn't
jump
straight
into
the
admin
users.
Perhaps
I
should
first
build
a
container
for
that
and
say
this:
is
this
new
container
object
in
the
future?
It
will
have
things
attached
to
it.
One
of
those
things
is
user
administration,
epics
overview
et
cetera,
et
cetera,
as
we
go
forward.
B
Yeah,
I
see
what
you're
saying
I
guess.
One
thing
I
always
consider
too
is
like
the
permissions
and
the
roles
of
who
can
see
what
so
the
admin
area
obviously
is
linked
only
to
administrators
who
do
we
give
permission
to
the
workspace
container
like
they're
calling
it
is
it?
Does
it
go
to
the
group
owners,
or
does
it
go
to
somebody
else.
A
A
However,
one
of
the
more
technical
things
about
this
and
not
specifically
on
a
front
environment,
is
the
the
issue
of
cascading
settings
inheritance
for
access
permissions.
So
because
we
don't
have
this
top
level
structure
just
yet
we
have
to
do
define
settings
at
every
local
object.
You
have
to
assign
everyone
to
a
group.
A
Sometimes
filtering
down,
doesn't
work.
Filtering
across
definitely
doesn't
work.
So
if
you
have
two
different
groups-
and
you
want
to
try
and
do
anything
between
the
two-
like
the
easiest
example-
we
can
experience
today
is
try
using
a
label
or
yeah
using
a
label
like
on
our
retros.
You
can't
ever
use
that
because
they're
in
the
retro
group
and
not
in
the
gitlab
group
and
for
some
reason
they
don't
cross-pollinate,
mentioning
somebody
who's,
not
in
the
group.
A
A
It's
just
weird
why
it
doesn't
exist
simultaneously
in
the
same
group,
even
though
it's
the
top
level,
and
so
the
next
point,
alexis
kind
of
makes
a
point
there
about
how
users
have
a
tough
time,
differentiating
between
groups
and
projects.
A
It's
one
of
the
things
we're
doing
and
part
of
this
work
is
merging
groups
and
projects.
The
logical
objects
in
the
background
for
the
architecture,
so
functionally
won't
be
any
different,
or
let
me
back
up
a
set
visually
for
a
user.
They
won't
be
any
different,
but
because
they're
not
going
to
change
what's
on
their
front
end,
they
still
want
to
have
access
to
their
projects
and
their
repos
etc.
A
But
on
the
back,
it'll
just
be
one
thing:
it'll
just
be
what's
called
a
namespace
container
and
that's
what
the
workspace
object
is
supposed
to
be
as
well
and
marcel
had
brought
up
the
the
point
of
confusion,
also
that
we
already
have
groups
subgroups
and
projects
and
now
we're
going
to
introduce
a
new
object,
called
workspaces,
and
I
was
trying
to.
A
I
want
to
also
agree
that
I
think
it's
weird
to
introduce
a
new
object,
but
I
think
if
we
call
it
just
a
top
level
container,
it
kind
of
helps
clarify
that.
So,
when
I
did
a
validation
on
this
previously
for
groups
and
subgroups
users
had
the
same
confusion,
they
didn't
understand
what
the
difference
between
a
project
or
a
group
was
or
a
subgroup.
A
And
so
I
would
totally
agree
with
alexis
there
that
it
doesn't
necessarily
make
sense
what
we
call
it.
But
the
idea
is
that
we
want
to
make
sure
that
it's
usable,
obviously
from
the
front
end.
I
hope
that
was
the
point
you
wanted
to
get
to
alexis.
C
Wait
is
the
workspace
basically
an
instance.
Is
that
how
we're
thinking
about
it.
A
So,
yes,
the
idea
being
that
it
would
be
like
the
instance
of
a
self-managed
installation.
So
one
of
the
things
we're
going
to
do
in
the
future
is
an
instance
or
hopefully
an
instant
swapper.
So
kind
of
like
you
look
at
how
slack
has
environment
switching
or
group.
Switching
the
same
sort
of
idea
would
be
to
add
that
as
a
feature,
because
there's
been
requests
for
that.
A
So
another
way
to
think
about
that
locally
would
be
like.
If
I'm
a
developer,
I
have
my
own
little
personal
project
in
gitlab,
but
then
I
also
log
into
my
company's
gitlab
account,
and
I
have
all
my
private
company
stuff
in
there
and
I
can
switch
back
and
forth
really
easily
apart
from
having
to
sign
out
and
sign
back
in.
C
A
Yep
exactly
this
is
one
of
the
features
I
want
to
bring
forward
in
the
future.
Hopefully,
but
that's
all
all.
This
is
based
on
us
unifying
the
objects
between
groups
and
projects
and
subgroups,
saying
it's
one
actual
object
and
then
making
the
inheritance
model
much
more
clean
and
that's
tied
to
what
this
workspace
container
is.
So
the
workspace
project
tries
to
solve
a
number
of
things,
one,
the
architectural
problem
and
two.
How
do
we
interface
with
that
object
to
assign
or
define
settings
features
across
your
organization.
B
Actually,
you
asked
it
the
exact
same
way
that
I
was
going
to
so
they
clarified
it.
I
was
just
asking
hey:
is
it
basically,
just
like
an
instance
of
self-managed
means
yeah
we're
just
trying
to
expose
the
settings
that
make
sense
to
our
com
users,
so
you're
not
going
to
get
control
over
gitlab.com
hardware,
but
they
should
have
control
over
the
people
that
are
in
their
like
domain
area.
A
Yeah,
it's
mostly
just
informational
right
now,
like
I
said,
go
through
the
thread
and
follow
up
because
there's
a
lot
more
stuff
in
there.
But
I
want
to
say.
C
There's
a
line
there,
something
like
just
off
the
wall.
I
know
it's,
I
don't
know.
Maybe
it's
just
me,
but
when
I
think
of
workspace
I
think
of
like
my
workspace.
So
do
you
see
in
the
future
like
the
idea
of
like
a
user's
workspace
versus
like
an
instance
level
workspace
like
I
have
my
own
little
area
for
like
organizing
my
own
self,
like
kind
of
like
that
person.
A
D
I
know
we
only
have
about
nine
minutes
left,
but
I
thought
I'd
go
ahead
and
throw
it
in
and
just
see
if
y'all
have
any
ideas.
This
came
about
from
talking
with
valerie,
not
too
long
ago
about
cross-stage
collaboration
challenges
and
how
we
want
to
try
to
reduce
some
of
the
siloing
that
happens
at
times,
which
I
know
we're
all
always
trying
to
resolve
anyway.
D
D
But
it's
not
as
top
of
mind
as
I
would
like
for
it
to
be,
and
obviously
I
can't
go
super
deep
top
of
mind
all
the
time,
but
I
would
like
to
have
better
understanding
of
some
of
the
other
stage
groups
and
just
the
problems
they're
solving
things
like
that.
So
I
told
her
that
I
would
do
a
showcase
on
plan
project
management
specifically,
but
I
don't
want
to
be
redundant.
I
know
a
lot
of
this
stuff
people
already
have
some
knowledge
of.
Is
there
anything
specific
that
you
all
feel?
D
That's
my
just
super
quick
and
dirty
list
right
now
of
what
I'm
planning
to
cover
with
the
first
couple
of
items
just
being
really
fast,
because
I
think
most
people
have
some
idea
of
that
anyway.
D
A
D
A
D
A
B
I
was
gonna
say
I'm
like
partially
torn
because
I
know
hypothetically,
I
should
be
reading
this
in
the
handbook
and
looking
through
our
docs
and
better
understanding
it.
On
the
other
side,
I
just
love
to
hear
my
teammates
talk
about
what
they're
working
on,
because
it
brings
a
level
of
like
humanness
to
the
problems
that
I
can
better
empathize
with.
I
understand
where
they're
at
so.
A
A
Just
real
quick
to
also
expand
on
that.
Like
you
say,
we
should
go
to
the
handbook
and
read
it.
But
what
if
this
video
was
at
the
top
of
the
handbook
page,
it
was
the
intro
and
broke
down
everything
about
that,
so
you
could
actually
click
on
the
link
and
read
more
in
depth
or
how
they
could
give
like
the
10
15
minute
presentation
at
the
top
and
kind
of
also
structure
your
presentation
based
around
the
page
content.
So
if
somebody
wanted
to
read
more.
D
B
D
B
B
Just
talking
to
my
pm
about
who
to
do-
and
we
default
to
looking
at
where
the
categories
at
what
stage
do
they
align
to
like
to
do,
is
listed
like
under
plan.
But
if
someone
else
is
working
on
it,
we
can
lose
that
in
translation,
and
so
things
like
that
are
helpful
to
know
so
that
we
don't
just
hammer
holly
and
alexis
on
everything
that
we
see
under
plan
when
some
other
working
group
or
another
group
is
working
on
a
specific
feature
for
a
period
of
time.
D
So
when
you
say
holly
specific
things
are
you
looking
and,
and
that
being
one
of
those
kinds
of
things?
Are
you
looking
for
personal
challenges
that
I
have
within
the
plan
stage
that
might
be
beneficial
for
others
to
know
about
or
something
that
might
be
knowledge
that
I
have
as
being
sort
of
the
dri
for
project
management,
specifically,
that
could
be
beneficial
to
others
or
something
else
entirely.
D
B
Let
me
clarify
yeah,
so
I
guess
what
I
was
saying.
Is
you
shared
a
pain
point
where
you
were
brought
into
conversations
around
like
to
do's
but
you're?
Not
really
the
point
of
the
point
of
contact
that
people
should
be
looking
to
so
better
understanding?
Well,
how
do
I
self-serve
my
knowledge
and
understanding
who
I
can
contact
if
polly's,
not
the
person,
but
the
category
list
tells
me
to
do's
are
under
planned,
then
how
do
I
know
who
to
talk
to
better
understanding
how
you
even
got
to
that
understanding
of
like?
B
Well,
it's
not
to
me
it's
to
this
person,
because
this
group
is
actively
working
on
it
and
you
could
know
that
if
you
were
looking
at
this
merge
request
for
this
epic.
That
shows
you
kind
of
like
the
breakdown
of
how
it's
going
right
now,
yeah
the.
B
B
Doesn't
belong
to
my
group
that
one
I
can
fall
back
easier
on
because
I
can
say
it's
actually
in
the
handbook.
It's
actually
not
aligned
to
me
just
to
clarify,
but
it
is
kind
of
a
pain
point
to
know
who
owns
what.
D
Yeah,
but
to
your
point
about
the
handbook
I
saw
recently
where
someone
had
asked
sid
about
the
handbook
saying
that
we
are
now
up
to
like
13
000
pages
in
our
handbook,
which
feels
to
me
like
it's
getting
pretty
large
and
harder
and
harder
to
find
things,
even
though
it
has
become
a
really
great
resource
and
that
so
much
documentation
is
out
there.
D
I
do
worry
a
little
bit
that
what
I'm
doing
here
is
attempting
to
put
a
band-aid
on
potentially
a
problem
at
least
a
problem.
I
think
I
see
that
maybe
should
be
addressed
by
using
the
handbook,
and
I
don't
want
to
necessarily
do
that.
I
just
kind
of
want
to
help
bring
it
to
the
top
of
everyone's
minds.
D
Maybe
add
a
little
clarity
as
to
what
we
do
here
and
just
kind
of
refresh
everyone
on
the
the
value
of
visiting
other
stage
groups
and
learning
about
other
stage
groups
beyond
just
I
know
I
have
a
thing
that
I'm
working
on
and
I
have
been
told
I
need
to
you,
know,
tag
michael
in
it
and
pull
him
in
and
not
necessarily
know
how
the
relationships
interact
and
how
the
pieces
fit
together,
and
maybe
it's
just
me
that
feels
that
way.
Sometimes
I
don't
know.