►
From YouTube: 2022-04-27 Workspace meeting
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
B
A
B
I'm
hoping
it
is
yeah,
so
I
I
was
just
looking
through
this
and
I
noticed
a
few
themes
coming
up
and
the
first
one
was
trying
to
get
my
head
wrapped
around
what
namespaces
are
going
to
be
more
long-term
vision.
B
I
know
the
answer
for
the
short
term,
or
at
least
I
think
the
answer
for
the
short
term.
Hey
blair,
is
that
no
changes
right
you're,
just
the
engineering
team-
is
doing
some
back
back
behind
the
scenes
things
and
there
are
no
surface
changes
to
the
ui
or
to
the
user.
To
anything,
my
question
is:
is
that
a
long-term
answer,
meaning
are?
B
Is
this
namespace
thing
going
to
manifest
itself
for
the
foreseeable
future
as
groups
and
as
projects,
and
just
have
some
changes
that
happen
between
them
or
do
we
think
that
it
is
going
to
eventually
manifest
itself
in
some
other
form.
A
You
ask
about
team,
and
I
know
that
the
idea
of
a
team
was
circled
at
the
round.
There's
an
epic
for
that
that
I
asked
recently
about
and
or
it
said
like.
Oh,
this
is
a
dream,
and
so
we
keep
it
open,
but
I
would
delegate
this
question
to
alright
about
long-term
vision,
because
I
I'm,
I
just
don't
know
exactly
if
they
have
like
if
product
have
a
long-term
vision.
I
know
that
right
now
I
haven't
heard
about
like
engineering,
specific
ideas
about
like
different
things.
B
I
guess
let
me
first
say
by,
like
the
hope
was
to
present
this
question.
So
is
this:
is
this
the
right
format
for
that?
I
guess,
or
is
this
more
of
an
engineering-focused
meeting.
A
A
It's
still
a
beginning,
because
this
is
you
know
we
are
in
this
like
phase
two
of
like
really,
which
is
like
first
phase
to
even
go
there
when
where
we
want
to
go
so
any
questions
are
are
good
now,
because
we
can
understand
more
what's
coming
next.
B
Okay,
so
yeah,
I
don't
really
want
to
get
caught
up,
and
you
know
I
maybe
shouldn't
even
put
the
the
teamwork
out
there
right.
I
I
don't.
I
don't
think
I
want
to
go
to
the
level
of
like
you
know
what
these
things
should
be.
I
guess
I
I
think
the
core
question
is
is:
are
we
planning
changes
or
is
it
going
to
just
be
the
same
as
it
is
today,
and
I
guess
maybe
a
follow-up
question
to
that
is
like
feature-wise
right.
I
know
there's
talk
of
inheritance.
B
That
will
maybe
change,
but
are
you
know
like,
for
example,
our
project's
gonna
get
ethics,
and
things
like
that
are
we
are
we
talking
about
like?
I
know
the
name,
space
object,
probably
from
what
I've
read,
would
have
the
potential.
Yes.
B
A
Yes,
that's
just
an
example.
Yes,
I
think
I
think
even
there
was
a
discussion
like
that
discussion
about
if
project
should
have
epics,
because
that's
like
the
idea
behind
what
we
are
doing
now,
so
we
have
like
more
parity
between
projects
and
groups,
so
any
new
features
can
be
on
like
both
levels
very
easily,
because
right
now
they
are
like
we
have
like.
I
know
how
to
describe
it.
Device
like
the
groups
and
projects
are
something
different,
but
because
we
want
to
have
like
similar
the
same
features
on
both.
A
We
need
to
duplicate
code
so
and
then
we
are
like.
We
are
constantly
in
this
like
discussion
like
of
this,
like
this
little
part
of
code
everywhere,
like
is
this
group
or
is
this
project?
Is
this
group
member?
Is
this
project
member?
We
just
want
to
say
like?
Oh,
this
is
a
member
of
a
namespace
and
we
don't
care.
It
is
a
group
or
project
and
the
same
with
features.
A
We
have
feature,
I
don't
know
feature
a
and
this
code
is
existing
on
the
like
namespace
level,
and
it
serves
groups
and
projects
in
a
like
same
or
similar
way,
and
the
idea
is
to
make
this
to
make
these
changes
to
have
similar
code
have
like
more
clarity,
so
the
features
can
be
like
the
features
can
be
really
on
the
both
level.
Without
you
know,
hustle,
for
example,
imagine
that
we
have.
You
know
labels
on,
like
you
know,
group
level
and
project
levels
whenever
there's
like
a
need
to
change
something
in
labels.
A
C
I
was
just
gonna
jump
in
there
because
I
think
that.
C
The
surface
level
thing
that
you
always
hear
about
workspace
is
oh,
I
can't
do
this
because
I'm
in
a
project-
or
I
can't
do
this-
because
I'm
in
a
group-
and
that's
like
that
number
one
sort
of
experience
thing
everyone's,
like
that's
our
our
customer
complaint
right
about
that
now,
the
obviously
works
workspace
takes
on
a
much
deeper
level
than
that
and
for
many
reasons,
but
it
it.
C
So
it's
it's
more,
and
this
is
jumps
right
on
to
what
gotcha
was
saying,
which
is
it's
more
democratizing
our
feature
set
across
the
entire
product,
all
the
way
up,
so
that
we
don't
have
to
worry,
and
that
creates
a
lot
of
benefits
for
us,
not
just
for
the
user
being
restricted
on
where
they
can
do
things
and
what
they
can't,
but
also
to
what
gosha
was
saying,
which
is
on
the
back
end.
It
creates
a
lot
more
efficiencies
for
us
as
well.
C
So
now
one
thing
I
do
want
to
mention
is
the
previous
product
designer
had
done
an
exploratory
about
removing
like
migrating
from
projects
to
groups
or
oh
we're,
gonna
drop
groups
or
whatever
or
projects.
I
don't
think
that
that
is
a
part
of
the
equation.
C
The
intent
there
was
to
simplify
and
just
have
one
container
and
whatnot,
but
it
definitely
threw
a
lot
of
people
made.
A
lot
of
people
go,
wait
a
second,
no,
no
we're
not
doing
that.
We're
not
getting
rid
of
any
any
part
of
the
crucial
experience
that
we
have
now
in
order
to
simplify
things,
but
we're
kind
of
moving
the
other
way,
which
is
in
order
to
simplify
things,
we're
just
going
to
have
parity
with
the
feature
set
across
the
board.
B
And
I
I
think
that
all
makes
sense
and
that's
exactly
why
I'm
asking
this
question
is
following
that
discussion
and
seeing
those
designs
that
were
thrown
out
there,
and
then
I
saw
where
they
were
met
with
resistance
and
my
and
what
I
was
trying
to
figure
out
was
that
resistance
was
that
short
term
or
long
term.
But
let
me
play
out
a
counter
point,
maybe
to
that.
B
If
groups
and
projects
have
feature
parity
and
let's
play
it
all
the
way
forward,
where
they
have
complete
feature
parody,
how
would
a
user
ever
know
whether
to
create
a
grouper
project
or
how
to
use
a
grouper
right
like
it?
It
in
many
ways
alleviates
problems
of
like
I
want
to
be
able
to
do
this
here.
I
want
to
be
able
to
do
this.
I
want
to
be
able
to
do
this
here,
but
the
I
don't
know
where
I
am
in
gitlab
problem
in
my
opinion
is
going
to
get
dramatically
worse
with
feature
parody.
B
So
I
don't
know
what
problem
to
start
trying
to
tackle,
and
I
think
that's
why
this
is
a
key
question
of
you
know.
I
mean
on
one
hand
if,
if
there
is
an
absolute
like
definitive
reason
why
we
need
to
keep
groups
and
projects
and
I
think,
there's
a
great
argument
for
it.
You
know
the
one
you
just
made
and
you
know
I
was
talking
with
daniel
more
about
this
a
little
bit
of
like
yeah.
B
You
don't
want
to
like
drop
users
into
a
whole
new
thing
and
relearn
your
whole
system
and
all
that
stuff.
I
completely
agree
with
that
point
of
view,
but
at
the
same
time
like
I'm
lost,
and
I
don't
know
what
to
do.
Problem
is
mounting
and
I
think
we'll
continue
to
mount
as
feature
parity
gets
there.
So
is,
as
they
ask
more
and
I
don't
even
know
who's
doing
the
ass,
but
it's
the
task.
B
A
I
don't
think
that
we
were
aiming
at
like
100
future
parity
because,
for
example,
like
projects
are
right
now
strictly
connected
to
repositories
and
like
so
like,
where
the
code
is
actually
like,
stored
and
pipelines
executed
and
so
on.
So
I
don't
think
it
was.
There
was
ever
a
discussion
to
like
to
like
to
like
move
this
to
a
group
level.
I
think
there
was
like
one
design,
but
it
was
like
met
with
huge
resistance
and
it
was
not
like
it
was
not,
I
think
ever.
A
I
don't
think
engineers
were
asked
like
what
they
they
are
thinking
about
this,
but
so
I
don't
think
we're
aiming
at
100
parity.
We
are
aiming
at
bigger
parity
and
also
simplification
of
what
we
are
doing
now,
for
I
I
will
you,
I
will
use
an
example.
I
just
answered
in
a
issue
about
user
badges,
because
I
got
an
idea
that
maybe
we
can
use
it
as
a
like
mvc,
because
you
said
like
we
can
do
it
on
a
group
level.
So
my
idea
is
like
why
do
like?
A
So
if
we
have
like
a
group
and
project
inside
why
we
should
like
we
should
prevent
project
members
from
getting
the
same
badge,
and
if
we
establish
this
feature
on
this
new
project,
namespace
level.
That
means
that
we
can
like
implement
it
once
and
then
use
it
on
a
group
and
project
level,
because
it
will
like
it
interacts
with
the
same
objects,
so
it
can
be
implemented
once
easily
and
then
use
it.
So
this
is
like,
and
it's
not
as
right
now
with
project
name
spaces.
A
It
doesn't
require
implementing
it
twice
on
group
and
project
level.
We
can
do
it
once
and
use
it
on
both
on
both
on
both
levels.
So
there's
like
this
is
like
an
I
think,
good
example
of
like.
Oh,
we
have
this
little
thing
and
we
are
not
constrained
with
like
amount
of
work,
because
the
amount
of
work
will
be
like
no
they'll
be
like,
let's
implement
it
for
the
namespace,
and
it
will
be
for
groups
and
projects.
In
the
same
time,.
B
Probably
it
does
like
why
wouldn't
you
if
you
have
members
of
the
group,
but
so
maybe
that
is
you
know
I
that
that
is
I've
had
in
the
back
of
my
mind
of
tasks
that
need
to
happen,
and
you
know
I
had
him
like
kind
of
wrap
my
head
around
everything
figure
out
like
the
big
vision
and
then
eventually,
I
always
assumed
that
every
feature
known
to
man
and
gitlab
would
have
to
be
evaluated
at
group
project.
B
C
C
Yeah,
I
I
I
think
there
may
be
a
level
of
that
evaluation
of
of
all
features,
all
the
features
across
the
board
and
and
where
they
are,
what
what
level
they
can
and
cannot
be
done.
I
think
that
that
that
may
be
now
is
that
a
hundred
percent
the
responsibilities
of
just
the
workspace
team.
I
don't
think
so.
I
think
that
that's
in
particular,
what
we
start
interacting
with
the
rest
of
the
product
teams
goes
for
it
now.
C
C
You
know,
I
think
there
is
no
doubt
in
particular
that
workspace
will
take
a
while,
as
kosher
said,
what
is
if
we
play
this
out.
What
is
that
long-term
vision?
Is
it
you
know?
Is
there
a
possibility
of
projects
and
groups
going
away
in
favor
of
another,
a
different
hierarchy
or
no
hierarchy
at
all
that
the
sort
of
teams
sort
of
idea
flat
structure?
C
C
I
think
it's
jarring
for
users
and
for
in
our
engineers
as
well,
but
I
think
ultimately-
and
I
was
just
on
an
interview
with
a
for
a
group
manager-
a
group
product
manager
for
for
manage.
They
had
some
interesting
thoughts
about,
like
you
know,
back
it
up
a
little
bit.
C
We
need
to
stop
trying
to
force
them
to
organize
themselves,
to
the
way
that
we
do
it
and
give
them
a
tool
set
so
that
they
can
organize
git
lab
the
way
that
they
do
it.
So
it's
more
about
meeting
the
needs
of
those
people
that
have
their
own
organizations
and
their
own
organization
structure
and
and
how
that
plays
out
in
the
long
term.
C
I
think
it
could
be
more
drastic
than
than
we're
looking
at
right
now,
but
I
think
that
there's
a
long
time
to
answer
that
question
as
we
move
along.
So
I
think
that
that's
a
that's
a
big
play
in
the
game
there,
which
is
how?
How
do
we
give
these
leading
to
large
customers
the
tool
set
to
meet
the
way
that
they're
organized
versus
forcing
them
into
our
own
mental
level?.
B
B
B
C
B
C
It's
the
age-old,
like
almost
iteration
like
how
do
we
create
a
grand
vision,
what
is
possible
and
then
what
are
the
steps
for
us
to
get
there
that
allows
us
to
create
value,
but
also
flexibility
for
ourselves
to
change
that
end
state?
If,
if
need
be
workspaces,
the
end
date
is
so
far
away
that
we
can't
predict
the
way
it's
going
to
be,
but
we're
already
seeing
shifts
of
change
in
outside
of
gitlab.
C
The
way
things
are
done,
and
I
think
that
in
particular,
the
the
teams
aspect,
the
flatter
structure
that
marcel
talks
about
with
backstage
and
spotify.
That's
why?
I
think
in
particular
with
that
original
workspace
working
group
where
marcel
was
involved,
gabe
was
involved,
there's
a
lot
of
those
work.
That's
where
you're
going
to
find
those
drastic
ideas,
that's
where
you're
going
to
find
that
pushing
the
modern
edge,
and
we
need
to
sort
of
marry
that
vision
with
with
where
we
are
now
and
what
it
is.
B
I
think
the
the
downside,
though,
or
of
yes,
we
do
have
a
long
time,
but
if
you
know
speaking
to
like
the
broader
ux
team
right
like
if
we're
gonna
merge
groups
and
projects.
B
You're
gonna
have
to
touch
everybody
and
say
like
how
is
that
going
to
affect
your
feature
set
and
that
ain't
going
to
happen
overnight
right?
That's
we're
going
to
have
to
give
them
a
massive
runway
to
allow
them
to
have
the
time
to
think
about
that
space.
So,
yes,
we
have
time,
but
no,
we
don't
right
in
that
sense
of
it's.
B
I
also
go
back
to
the
like
the
configurability.
I
love
the
idea
of
configurability
as
well,
but
I
feel
like
I
have
to
channel
my
inner
pedro
pedro
is
great
about
reminding
us
of
this
of
we
do,
have
you
know
a
product
principle
of
convention
over
configuration
and
that
we
have.
We
have
made
some
efforts
to
not
allow
like
infinite
configurability,
which
is
oftentimes
what
customers
ask
for,
but
we
have
found
that
like
by
by
keeping
them
on
the
straight
and
narrow
it
actually
does
produce
a
better
product
and
a
better
experience.
C
Absolutely
we
struggled
with
that
in
my
past
job
as
a
in
particular
ipad
designer,
where
at
users
were
almost
screaming
for
a
configurable
dashboard
of
tiles
and
stuff
like
that,
and
then
we
sort
of
tested
that
with
users
and
98
of
them
left
them
exactly
the
way
that
they
were
and
never
configured
anything
and
so
yeah
you're
exactly
right
there.
There
is
certain
we
need.
C
C
Listen,
I
mean
these
are.
These
are
the
people
three
of
us
are
gonna,
be
the
ones
that
make
make
all
the
decisions
and
all
the
choices
for
workspace,
no
pressure,
but.
C
Absolutely
like-
and
that
is
true
right
like
so
often
when
mike
sort
of
asked
me
these
three
original
questions
and
that
I
see
it
like
in
your
answers
by
the
way
gosha,
which
is
like
there
are
just
so
many
things
that
were
just
like
arie
would
be
great
to
talk
about
this
right
now
and
she
hasn't
been
around
good
for
her.
But
yeah
like
a
product
perspective
needs
to
happen,
which
is
great.
Why?
C
I
had
this
sort
of
interview
this
morning
with
this
person
for
the
the
group
manager.
He
had
a
lot
of
opinions
about
workspace
and
I
love
to
sort
of
see
that,
and
I
I
love
that
voice
so
yeah.
I
think
getting
the
pm
product
voice
in
this
discussion.
C
B
B
The
thought
of
like
what
feature
should
go
where,
but
I
almost
kind
of
feel
like
that
issue
needs
to
be
created
and
started
to
be
worked
on,
knowing
that
the
answer
to
that
is
probably
going
to
be
a
year
away,
but
I
think
we
need
to
start
chipping
away
at
the
problems.
Does
that
sound
like
a
reasonable,
create
an
issue
start
saying
like
what
are
we
mapping
to
where
both
on
the
up
and
down
verticals,
but
also
you
know
across
projects
and
groups
and
projects?
At
this
point?
A
Yes,
this
this
issue
was
actually
created
by
michelle.
After
after
there
was
like
there
was
iteration
office
hours.
We've
said
that
I
asked
this
question
like
how
we
can
like
iteratively
approach
this
problem,
and
he
suggested
like,
let's
start
with
some
small
feature
and
bring
it
to
the
project
and
group
level
simultaneously,
using
the
what
we
already
know,
what
the
team
already
done
and
then
we
started
looking
for,
like
you
know,
ideas
and
inspiration.
A
What
can
we
actually
like
move
and
but
of
course,
this
definitely
requires
like
taking
a
hard
look
if
this
should
be
on
both
levels
or
should
be
moved
from
project
to
group,
or
vice
versa.
B
B
Okay,
so
maybe
you
know
we
can
start
with
the
theory
that
that
those
are
the
way
things
would
move
but
keep
in
the
back
of
our
minds
that
you
know.
Maybe
there
is
other
flows,
definitely.
B
Okay,
awesome:
we
don't
have
to
talk
about
the
second
point,
because
I
think
it's
going
to
be
the
exact
same
discussion
b
and
c.
I
think
we
can
skip
because
I
think
it
it
is
con.
We've
we've
already
touched
on
those.
So
if
you
want
to
hit
on
the
number
two
point
there.
A
It's
only
fyi,
there
was
an
asks
who
created
to
establish
an
ami
ama
for
engineers
to
start
like
using
this
feature
that
we
are
doing,
I
posted
on
the
slack
channel,
but
this
is
like
mostly
for
engineers,
so
this
is
like
just
fyi
in
this
in
this
group.
This
was
like
ask
from
from
the
leadership
of
of
engineering
division.
B
I
will
say:
blair
and
I
had
a
discussion
and
I
feel
like
blair
is
probably
about
to
say
the
same
thing.
So
I'm
sorry
I'll
cut
you
off,
but
like
the
questions
that
I
have
above
this,
we
feel
like.
If
we
don't
have
some
sort
of
answer
for
those
questions,
we
might
look
less
prepared
in
the
ama
than
if
we
did
now.
B
Obviously
these
are
year-long
questions
to
answer,
but
I
do
feel
like
maybe
another
discussion,
preferably
with
or
eat,
would
be
very
beneficial
prior
to
that
ama
for
us
to
get
at
least
we
may
not
have
the
answer,
but
at
least
we
know
how
to
answer
the
question.
Sometimes.
A
A
Is
like
yeah,
this
was
supposed
to
be
like
more.
I
was
thinking
about
like
more
engineering
thing,
because
we
now
have
some
patterns
in
like
how
to
move
features
from
like
groups,
projects
or
like
how
to
like
deal
with
this
problem.
So
we
can
like
start
spreading
the
knowledge.
C
Yeah
because
I
know
where
mike's
coming
from
watching
maybe
the
past
most
recent
mma
for
workspace
that
arie
hosted
in
particular,
there
are
some
questions
that
were
asked
by
designers
for
designers
and
the
answers
were
not
satisfactory,
and
if
this
is
very
engineering
based
hosted
by
engineering
audience
probably
made
up
mostly
of
engineering.
C
Is
there
a
reason
for
a
for
us
to
to
prioritize
this
meeting
for
the
two
of
us
to
be
there
and
b?
Is
there
a
risk
for
us
to
be
asked
those
questions
and
if
not,
if
the
answer
is
no,
if
this
is
purely
an
engineering
ama,
then.
C
A
Was
thinking
of
more
engineering?
Am
I
because,
like
as
their
these
concepts,
are
in
the
code
right
now
in
the
code
base,
and
we
want-
and
I
know
that
some
groups
are
interested
in
those
concepts
we
need
to
like
start
spreading
knowledge,
like
you
know,
among
engineers,
so
that
was
this
was
my
idea
for
this
ama
and
for
like
more
maybe
long-term
vision.
I
might.
It's
definitely
requires
more
of
a
like
your
perspective
and
product
group
perspective
and
so
on.
B
But
at
the
same
time
like
we
do
need
to
have
a
discussion
about
these
items.
I
think
on
some
level
now
so
maybe
I
can
create
that
issue
and
maybe
we
can
async
a
lot
of
that
discussion.
B
B
Awesome
thank
you
and
thank
you
for
letting
me
dominate
the
conversation
today.
You're.