►
From YouTube: Plan Stage Weekly - 2021-09-01
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
Cool
welcome
to
plane
stage
weekly
september
1st.
We
have
a
short
agenda.
We
talked
a
little
bit
about
so
far
before
we
recorded
talk
a
little
bit
about
the
designs
on
work
items
and
when
we
need
to
get
designs
done,
I
mentioned
that
we
can
hold
on
we're
not
front.
End
is
not
going
to
be
blocked
by
designs
until
we're
actually
going
to
be
implementing
the
widget.
So
just
a
little
bit
before
we
plan
on
implementing
them
now,
gabe
has
a
question
on
workspaces.
B
Yeah,
so
I
was
just
going
to
ask
since
so
many
of
our
engineers
are
slated
to
go
work
on
that.
I
was
just
curious
how
things
are
going.
I
know.
Melissa
and
mary
were
working
on
creating
issues
that
can
be
worked
on
a
parallel
and
she
is
back,
I
think
today,
but
is
there
anything
that
I
can
help
with
in
terms
of
like
do?
Does
everyone
have
work
to
do?
Is
it
clear?
Is
there
any
confusion,
how's
it
going
in
general.
C
Yeah,
I
think,
of
all
the
engineers
on
the
only
one
but
yeah
we're
making
some
progress.
I
don't
think
it
is
full
speed
just
yet
we're
introducing
this
project
namespace,
and
there
is
an
mmr
for
that.
I
can
link
it
in
the
doc
if
anyone
is
interested,
but
then
there
is
also
parallel
discussion
into
backfilling
data
for
the
project
namespace.
So
basically,
what
will
happen?
C
Every
project
will
get
sort
of
a
clone
name
space
to
it
attached,
which
is
different
from
projects
linking
to
their
parent
namespace
just
to
to
make
it
somewhat
clearer
and
even
like
before.
We
can
really
start
to
backfill
that
data
that
needs
to
some
stuff
needs
to
happen
like
we
need
to
make
sure
that
moving
a
project
to
a
different
group
copies
over
also
the
namespace.
C
And
all
that
stuff
exporting
your
project
and
and
all
that
interesting
stuff.
So
we
need
to
implement
that
even
before
we
start,
we
start
backfilling
data
into
the
database
because
then
otherwise,
when
you
do
export
a
project
that
already
has
an
attached,
namespace
will
not
have
that
functioning
so
we'll
either
have
to
clean
up
the
old
name.
Space
create
a
new
one.
C
So
there's
all
sorts
of
interesting
things
happening
so
yeah
things
are
moving,
but
I've
been
off
two
days
this
week,
so
I'm
kind
of
catching
up,
but
yeah
that
there
is.
I
think
we
are
at
the
point
where
we
need
to
decide
how
we
break
down
those
into
parallelized
issues
that
can
be
worked
on
before
we
start
actually
doing
this
big
migration
of
backfilling
data,
so
that's
sort
of
a
shortish
update
on
what's
going
on
cool.
Thank
you.
B
C
C
Yeah,
I
don't
think
we
need
anything.
I
think
there
is
a
lot
of
stuff
that
needs
to
go
into
database
and
backend
and
and
really
structuring
that
code
base
around
how
we
want
it
to
to
work.
We
may
need
some
help
from
import
export
team
with
if
we
will
not
be
able
to
dive
like
into
the
import
export,
how
that
happens
and
and
all
that
stuff,
because,
like
initially
I
I
for
some
reason.
C
We
do
expert
groups
separately
without
exporting
projects
and
we're
doing
expert
projects
like
as
a
separate
thing,
so
yeah
we'll
need
to
see
how
that
how
easy
that
is
to
combine
and
to
be
used,
but
yeah,
nothing
from
the
front
and
use
the
experience.
I
don't
think.
D
Yeah,
I
think
I'm
getting
my
question
answered
in
the
agenda,
so
I'm
also
the
the
temporary
new
deck
writer
for
managed
workspace,
and
so
I
was
just
a
little
confused.
I
knew
that
we
were
giving
something
up,
but
I
didn't
know
that
our
engineers
were
working
on
it
as
well.
So.
E
Yeah,
so
basically,
everybody
who
got
head
count
reset
away
from
plan
for
the
next
three
releases
is
to
help
with
that
workspaces
stuff
on
the
managed
side.
So
they
kind
of
have
several
manage.
Has
several
engineers
coming
in
from
different
teams
to
work
on
different
areas,
but
thankfully
workspaces
is
sort
of
aligned
closely
with
plan,
so
our
folks
got
to
go
and
work
on
that,
and
I
think
the
goal
is
like
to
hire.
E
They
have
a
head
count
to
hire
into
that
team
to
sort
of
fully
staff
that
team,
but
this
was
kind
of
an
acceleration
of
that,
so
they
should
have.
I
think,
by
the
time
all
the
dust
settles.
They
we
one.
We
should
get
our
people
back
and
then
they
should
also
have
hired
people
to
to
kind
of
take
over
that
stuff.
B
Yeah
the
next
question:
it
was
really
just
around
given
this
kind
of
shift,
what's
the
best
way
to
best
utilize
front,
end
engineers,
time
getting
the
losses
back
in
to
work
spaces.
B
Just
curious,
like
there
was
like
as
a
product
manager,
if
I
needed
to
shift
my
focus
to
like
refining
some
other
low-hanging
fruit
for
front
end
or
if
we're
good,
with
the
work
we
have
on
our
plate.
That's
mainly
what
I'm
looking
to
get
answered.
A
A
Like
we
want
to
start
working
on
the
architecture
and
some
of
the
things
that
that
where
it
makes
sense
to
to
get
ahead
on
there
are,
I
don't
think
we
should
work
100
on
the
front
end
on
work
items
so
yeah,
if
you
do
have
low
hanging
fruit
on
the
product
side,
feel
free
to
send
that
to
us.
I'm
thinking
we'll
also
take
care
of
some
of
our
bug
backlog
over
the
next
couple.
Next
few
months
too,
but
yeah
definitely
send
over
loving
it.
F
At
what
donald
said
that
we
can
focus
a
bit
more
on
widgets,
because
we
will
need
to
require
them
anyway
on
work
items,
so
we
can
refactor
a
few
sidebar
widgets
to
be
more
reusable
as
well.
This
is
also
a
part
and
speaking
about
the
schema
we
are
going
to
define,
we
would
probably
need
some
attention
from
back
end
I
or
discussed
this
with
donald
for
reviews.
So
when
we
will
be
defining
types
on
our
schema
for
work
items,
it
would
be
nice
to
have
at
least
one
backend
engineer
reviewing
this.
B
B
She
was
concerned
about
as
she's
working
on
the
new
work
item
ux
like
how
much
can
she
change
without
giving
front
end
engineers
a
headache
in
terms
of
like
how
the
design
and
the
interactions
behave
and
I've
kind
of
given
her
guidance
that,
like
we're
going
to
be
refactoring,
some
stuff
anyways,
so
do
what
is
best
for
the
end
user
and
we'll
sort
it
out,
but
I
just
want
to
make
sure
like
if
we
do
propose,
you
know
like
we.
B
The
data
is
not
really
going
to
change,
because
we
know
what
the
data
is
for
a
lot
of
these
things
right,
but
in
terms
of
like
maybe
how
the
interactions
work
or
what
the
ui
looks
like.
Is
it
gonna
be
a
huge
headache
if
you
do
refactor
some
other
things
to
the
sidebar
to
widgets?
And
then
we
want
to
change
like
you
know
the
style
look
and
feel
you
know
some
of
the
interactions
with
the
widget
itself.
F
B
Good
yeah,
I'm
kind
of
saying
I've
also
told
holly
that
if
we
need
to
change
pajamas,
we
should
change
pajamas
upstream,
like
because
even
like
the
labels
interaction,
I
was
going
through
it
and
it's
there's
so
many
broken
things
about
it
like
and
like
we
have
the
labels,
like
the
the
actual
label
for
labels
for
the
field.
We
have
like
a
a
bunch
of
stuff
that
doesn't
work
even
like
the
close
button
on
the
drop
down,
doesn't
work
so
like
it's
almost
like.
B
I,
I
think
some
things
need
to
change
upstream
too,
and
so
I've
encouraged
her
to
not
be
scared
of
proposing
those,
but
she
did
just
create
she's
going
to
start
creating
an
issue
for
each
widget.
I
think
this
is
an
mvc3
and
start
working
through
ux
for
each
one.
So
if
there's
a
specific
widget
that
you
want
to
work
on,
like
let
holly
know,
probably
in
the
issue
or
in
the
epic
or
whatever,
and
that
way
she
can
kind
of
focus
on
thinking
to
the
ux.
B
For
that,
while
you
want
to
do
the
refactoring,
if
that
makes
sense,
because
you
can
sort
of
like
work
on
these
in
any
order
when
you
get
to
that
point,
so
I
don't
think
it
really
matters
to
her
which
one
she
works
on,
but
it's
a
great
opportunity
to
like
collaborate.
So
we
don't
do
a
bunch
of
wasted
effort.