►
From YouTube: 2021-06-08 Plan Team Planning Objects Design Sync
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
Prototype
that
I
had
created
there,
we
go
sorry
good
call,
no
good
call.
Let
me
just
start
over
again
real
quick.
I
conducted
seven
interviews
on
usertesting.com
with
the
prototype
that
I've
created
and
have
gotten
some
good
feedback
so
far,
something
I
was
surprised
about
and
I'm
still
going
through
the
notes,
but
I'll
put
them
all
in
the
issue.
A
So
most
folks
felt
that
when
I
asked
them
to
find
a
couple
of
different
ways
to
view
the
layout
for
the
issue
that
they
had
opened,
they
would
go
back
to
the
to-do
list.
So
let
me
just
share
really
quick.
My
screen
and
I'll
kind
of
show
the
prototype
itself.
A
And
they
are
paving
the
street
in
front
of
my
house,
so
I
apologize
if
you
hear
some
rumbling
out
there
so.
A
A
I
gave
just
a
little
overview
of
kind
of
what
this
view
is
for
folks
that
weren't
familiar
with
gitlab
or
similar
products
and
then
asked
them
to
choose
the
issue
from
jeremy,
which
everyone
did
with
no
problem,
had
them
kind
of
describe
what
they
see
and
asked
them
to
find
two
other
ways
to
view
this
content
or
to
view
this
issue.
I
called
it
in
in
the
instructions.
A
So
most
people
read
through
it
a
couple
of
folks
and
I
did
a
little
bit
of
internal
review
as
well,
and
almost
everyone
has
said
they
felt
that
this
view
and
the
side
panel
view
were
a
little
like
cluttered.
There
was
a
little
bit
too
much
information
there.
So
that's
good
feedback.
That's
that's
helpful
for
me
to
know,
maybe
that
we
need
to
reduce
some
of
what
we
have
there
or
explore
some
other
ways
to
maybe
do
progressive
disclosure
and
and
reduce
some
of
the
visual
noise.
One
person
said.
A
B
B
A
Could
be
awesome?
Thank
you.
One
person
said
that
they
thought
that
this
comment
box
would
be
the
opportunity
for
them
to
reply
to
this
specific
comment.
A
So
that
was
a
little
bit
of
concern
that
I
had,
but
it
could
be
that
if
they
were
able
to
scroll
in
this
case
that
they
would
see
that
wasn't-
and
I
didn't
put
that
functionality
in
because
we
were
mostly
testing
the
switching
of
the
views
in
this
case,
but
another
person
said
that
he
felt
that
the
breadcrumbs
in
this
view
was
odd,
which
I
thought
was
kind
of
interesting
when
he
navigated
to
the
full
screen
view.
He
said.
A
A
B
A
Those
statuses,
so
that
was
also
interesting.
I
had
also
changed
the
filters.
This
was
just
me
experimenting
to
a
single
options
menu,
and
I
did
have
that
clickable
before
I
put
the
prototype
out
for
testing
but
didn't
want
to
derail
the
conversation
or
the
results
by
distracting
them
with
that.
B
A
Kind
of
collapsing
everything
under
one
menu.
If
you
came
off
one
comment
too
like
it,
would
be
so
cool.
If
that
was
just
the
one
comment
you
were
seeing
and
everything
else
was
collapsed
or
something
yeah
yeah
that's
possible
and
then
your
like
options
could
let
you
go
like
view
all
or
like
I
don't
know
like
they
could
change
it,
to
show
the
whole
scope,
that's
really
cool,
so
the
next
task
again
was
for
them
to
find
two
other
ways
to
view
this.
A
Another
interesting
point
was
about
half
of
the
participants
when
they
read
that
immediately
closed
this
and
started
looking
here,
they
thought
maybe
that
kind
of,
like
you've
got
fluidview
options
that
are
global
settings.
They
kind
of
had
an
expectation
that
you
would
do
like
a
one
and
done
setting
to
view
all
of
your
issues,
either
in
the
side
panel
or
in
a
modal,
which
I
thought
was
interesting
as
well.
A
Another
person
single
person
made
the
comment
that
they
would
expect
to
be
able
to
do
that
in
a
contextual
way,
so
that
maybe
in
boards
you
would
see
you
could
choose
to
see
everything
in
a
side
panel.
For
example,
but
in
another
portion
of
the
product
you
could
choose
to
see
everything
in
you
know
a
modal
view.
B
A
Some
people
liked
this
simple,
succinct,
modal
view.
The
last
person
I
listened
to
specifically
said.
I
love
this
view.
I
like
being
able
to
see
everything
in
one
place,
so
that
was
also
great
and
then
the
first
candidate,
and
maybe
even
one
of
the
others,
specifically
said
that
they
liked
the
full
screen
view.
B
A
Side
panel
view,
and
then
you
can
also
from
both
places,
go
to
the
full
screen
and
one
person
said.
Oh,
I
love
this
view.
This
is
the
view
that
I
would
spend
most
of
my
time
on,
because
I
can
see
everything
that
I
want
so
again.
Some
people
want
this,
the
sort
of
succinct
view
and
others
want
the
more
detailed
view,
and
I
think
it
just
depends
on
what
your
needs
are
at
that
time.
B
A
A
I
did
remove
and
I
did
get
some
feedback
that
people
didn't
like
the
changing
of
the
navigation
which
I
completely
get,
but
I
did
remove
switch
to
modal
or
switch
to
side
panel
view
from
the
detail
view
because
you
could
access
it
from
anywhere
and
how
would
we
know
what
to
show
in
the
ground,
so
it
made
sense
to
me
to
remove
it
from
there,
but
it
is
a
little
jarring
for
the
user.
Naturally,.
B
A
A
A
The
same
thing
that
you
had
said
about,
I
think
it
was
notion
being
able
to
just
do
the
swipe
and
go
back
previously.
So
I
think
that
if
we
can
allow
that
as
well,
then
that
would
also
be
helpful
yeah.
So
that's
the
the
research
that
we've
done
so
far
and
what
I've
heard
so
far
from
the
users,
good
feedback
and
still
kind
of
processing,
some
of
it.
So
once
I've
got
it
all
documented
I'll
put
it
somewhere
where
everybody
can
see
it
I'll
also
tag
alexis.
A
She
was
out
when
I
created
this,
but
I'll
tag
her
in
this.
So
she
can
see
this
research
I'd
love
to
see
what
she's
working
on
as
well
just
to
find
those
opportunities
for
overlap.
So
I
hope
that
she
can
attend
today,
and
I
can
see
that
because
I
know
she
showed
a
little
bit
of
it
this
morning,
but
that
was
the
the
first
I'd
seen
of
it
and
she's
been
so
and
she's,
probably
just
getting
to
it.
A
Yeah
she's
been
out
this
past
week
as
well,
but
I
think
I
know
she
did
do
some
on
the
issue,
but
she
also
did
a
lot
of
diving
around
hierarchies
and
parenting
so
initially
so
we'll
have
to
see
how
we
should
divvy
that
up
between
the
two
of
you
as
well
yeah
I'll,
go
through
the
two
issues
and
get
some
put
some
thoughts
in
there
and
tag
her
in
it
to
get
her
feedback.
A
I
met
yesterday
so
normally
on
mondays.
I
don't
know
if
you're
invited
to
this
or
not,
we
have
the
plan
issue
board
review
conversation
you're,
not
on
that
one.
You
should
be
on
that.
One.
A
Run
early
in
the
morning,
it
is
actually
12.
B
A
A
It
probably
would
be
good
just
for
this
project,
because
the
majority
of
the
conversation
gave
us,
but
obviously,
but
it
was
just
myself
and
jake
and
donald.
The
majority
of
the
conversation
was
around
this
project
and
they're.
I
think,
still
struggling
a
little
bit
to
figure
out
where
to
start
from
an.
A
Standpoint
like
where's
the
best
place,
and
I
think
there
could
be
opportunity
to
further
scope
down
the
ux
changes
that
are
being
proposed.
Just
to
ensure
that
we
are
on
the
right
track
for.
A
A
Be
a
team
discussion,
so
I
just
talked
to
the
two
ems
on
my
side
about
a
new
scope
down
plan.
I
should
have
had
jake
lear
on
that
as
well,
but
he's
not
my
em,
so
I
just
wasn't
thinking
it
through
sure.
I
don't
know
if
I
could
take
you
through
that
or
if
you
had
a
chance
to
look
at
the
issue.
Yet
with
the
story,
I'm
not
sure.
A
Okay,
so
the
first
meeting
we
had
last
week
on
wednesday,
there
was
a
lot
of
awesome
talk
around
what
to
do,
but
there
was
a
lot
of
risk
coming
out
of
the
conversation
like
if
we
scroll
down
in
here.
The
main
blocker
was
that
epic's
migration
would
be
blocked
by
projects
and
groups
merging
and
just
a
lot
around
keeping
apis
up,
and
things
like
that.
We
had
we
kind
of
just
hit
time
before
we
even
got
into
the
front
end
work
or
like
what
should
be
structured
in
that
way.
A
So
after
talking
to
justin-
and
all
of
this
like
it
felt
way
too
big
to
me-
and
I
had
proposed
this
earlier
and
gabe-
had
it
well
as
well.
Gabe
had
also
proposed
scoping
down
a
long
time
ago,
but
it
got
missed.
So
he
has
a
comment
here
where
he
was
like
explaining
almost
exactly
the
iteration
pan
that
I
just
came
up
with
so
we're.
We
are
really
on
the
same
page,
okay,
but
what
I
think
I'll
change
it
to
is
as
long
as
the
engineers
are
on
board.
A
The
old
way
is
that
we
migrate
everything
for
epics
within
six
months,
and
that
was
my
goal,
and
I
said
I
moved
my
features
because
of
that,
but
it
has
a
lot
of
timelines.
We
have
to
be
precise,
because
on
day
one
our
existing
epic
customers
are
gonna.
Have
this
new
experience
and
like
are?
Is
it
gonna
work
for
them?
Is
it
going
to
mess
up
their
workflows?
A
We
have
to
have
a
huge
like
migration.
We
have
to
support
old
and
new
apis
and
so
to
make
it
less
risky
and
a
little
more
iterative.
I'm
proposing.
We
just
start
at
the
project
level
and
do
a
new
issue,
type
called
story,
and
that
will
work
the
same
way
as
an
epic.
So
it's
essentially
we're
doing
project
level
epics,
and
that
will,
let
us
be
more
iterative
users
could
try
it
sooner
because
we
could
go
live
with
it
like
this
week.
A
A
A
We
could
talk
about
supporting
it
on
boards,
but
that
would
be
kind
of
the
first
level
of
mvc
and
then
the
second
one.
We
would
just
add
a
multi-level
option
above
it
and
call
it
feature
or
epic
v2
project
or
whatever.
We
want
to
call
that
object,
but
we
would
start
really
small.
Like
can
we
first
support
just
a
single
level?
Parent
can
issues
be
a
child
of
this
thing?
Can
the
ui
support
it
and
then
the
third
step
would
be
to
render
like
both
together
on
it?
A
A
Whether
at
that
point,
it's
come
together
where
groups
and
projects
are
merged
and
we're
just
keeping
them
at
group
and
we're
merging
them
on
or
have
some
kind
of
migration
plan.
Then
at
least
we'll
know
what
we're
working
with,
because
we'll
have
a
fully
operating
multi-level
system
happening
at
the
project
level.
A
A
What
does
it
look
like
to
be
a
story
and
looking
down
on
this
issue
and,
like
figuring
all
those
nuances
out
in
the
the
ui
and
then
whatever
you
want
to
do
to
the
actual
look
feel
of
what
an
issue
looks
like?
You
could
do
right
here
at
the
story
initially
on
the
story,
one
which
is
green
field
and
get
it
as
far
as
possible
and
then
like
the
team,
could
decide
when
they
want
to
roll
that
view
out
onto
the
issue
as
well.
A
If
you
want
to
do
it
in
parallel,
if
you
want
to
just
if
we
want
to
take
three
to
four
releases
on
stories
and
just
nail
the
experience
and
then
they
could
roll
it
off
onto
issues
just
gives
us
a
sandbox
to
play
in
where
we
can
deliver
a
lot
smaller
chunks
and
get
a
lot
more
specific,
with
the
interactions
versus
rolling
it.
A
I
think
that
makes
sense,
and
I
like
the
fact
that
it
seems
like
we
wouldn't
necessarily
have
to
worry
about
retrofitting
the
existing
issuable
things
into
this
new
thing,
so
we
could
kind
of
build
it
separately
and
get
feedback
and
test
it
and
play
with
it
without
necessarily
having
to
impact,
because
that
was
one
of
the
concerns
that
donald
and
jake
had
yesterday
was.
If
we
create
this
new
thing,
are
we
going
to
try
to
convert
all
of
the
existing
issuables
to
this
new
thing?
And
what
does
that
look
like?
A
B
A
A
A
This
could
help
to
direct
what
you
would
be
like
designing
for,
like
you
were
saying,
instead
of
retrofitting,
you
could
think.
Okay
well
with
the
story
with
my
new
layout
it'll
have
a
title.
It
will
have
a
description.
It
will
have
comments.
You
could
decide
kind
of
what
you
want
to
design
first
and
it
will
need
to
have
its
children
somewhere
in
it.
A
So
is
the
story
kind
of
our
new
planing
object,
starting
point
then,
for
now,
yeah
it'll
be
the
and
that's
the
single
level
version.
So
it's
one
level
deep
until
we
add
one
that
does
multi-level
deeps
of
itself
feature
could
go
to
seven
kind
of
like
sub
epics,
okay,
but
yeah.
I
think
that
like
when
you
solve
it
for
this,
it
will
work
also
for
multi-level
there'll,
be
more
nesting
and
things
the
higher
we
go
up,
but
it
should
work.
A
B
A
B
A
Like
I
was
just
mentioning
with
like
even
to
do's
right,
like
a
story,
will
be
an
issue
type
under
the
hood,
so
it
will
spawn
it
to
do
your
like
the
modals
and
the
sidebars.
You
were
just
showing.
Can
all
work
off
this
object,
so,
okay,
that
new
layout,
like
that,
I
think
all
of
that
should
be
you
figuring
out
how
those
all
work
together
like
the
geography
of
the
issues
and
whether,
if
we
lit
this
up
on
an
issue
board,
how
would
that
look?
A
B
A
A
A
For
supported
views
there
I
had
created
a
list
of
all
the
places
that
you
can
currently
pull,
or
access
issues
in
particular.
Do
we
need
to
start
thinking
about?
I
think
it
also
includes
epics,
but
incidents
test
cases,
mrs
just
yet
or
not.
Yet
I
think
we'll
just
go
off
this
and
then
the
next
step
will
be
to
move
those
other
objects
over.
A
Okay,
I
think
we'll
leave
all
of
the
current
navigation
as
much
as
we
can
we'll
leave
it.
As
is.
Let
me
just
find
the
planning
objects
thing
by
the
way.
They
asked
me
to
present
something
tomorrow,
just
to
have
a
third
person
from
plan
presenting
for
our
ux
showcase,
and
this
is
the
only
thing
that
I've
really
been
working
on.
So
I
recognize
that
that
could
be
opening
a
can
of
worms
by
pulling
everybody
in
I'm
gonna.
A
Try
to
keep
it
clear
that
it's
still,
you
know
very
high
level
discovery
and
kind
of
maybe
touch
on
some
of
the
things
that
we've
talked
about
today
as
future
yeah
planning,
but
just
a
heads
up
that
there
may
be
more
conversations
coming
once.
It's
kind
of
opened
up
to
right
once
it
goes
out
there,
but
I
think
it's
better
that
we
have
those
conversations
sooner
rather
than
later.
The
the
later
we
wait,
the
heavier
the
impact
it
feels
like
of
getting
that
feedback.
So
I'd
rather
do
it
as
soon
as
possible.
A
Yeah,
I
think
that's
good,
and
so
this
would
be
that
these
pink
ones
I
had,
which
was
now
they're
stories,
but
we
might
decide
yes
to
title
description.
Attachments
linked
objects,
mrs
like
it
might
just
mirror-
essentially
what's
turned
on
for
right
now
for
issues
or
epics,
whichever
one
I
guess
this
would
be
epics,
so
we
would
mirror
that
down
and
so
you'd
be
building
out
to
support
really
just
to
report
any
of
these
being
turned
on,
but
initially
like
it
would
just
be
an
issue
with
children.
A
A
A
A
But
we
had
just
kind
of
started
on
that
and
just
looking
at
the
collab
jack
view,
this
I'm
going
to
change
the
name,
but
like
the
new
view
that
would
roll
out
and
we
could
have
to
do's,
run
off
of
it
and
the
new
ui
and
all
of
the
things.
So
we
could
start
using
some
of
the
ux
that
holly's
figured
out
around
like
modals
versus
sidebars
right
off
the
bat,
with
the
new
view,
with
the
new
object.
A
B
I
don't
know
if
you
heard
me
sorry
feedback
on
what
oh,
the
different
like
views,
I'm
trying
to
create
like
feedback
issues
around
all
the
ideation.
I've
done.
A
I
know
you've
been
out,
so
I
want
to
just
tag
you
in
all
the
things
that
I've
been
working
on,
so
you
can
kind
of
see
what's
going
on
there
and
I'd
love
to
see
what
you're
working
on
as
well,
because
I
think
we're
going
to
need
to
get
together
and
sort
through
our
designs
make
sure
we're
in
alignment
those
are
kind
of
similar
to
god.
My.
A
So
there's
not
really
anything
behind
it.
You're
just
like
now,
I'm
on
the
issue
and
so
like
the
ones
that
spawn
on
top
of
each
other,
modals
or
sidebars
could
always
have
a
link
to
that
sort
of
landed
issue
view.
That's
the
old
school
one
kind
of.
B
So
we
can't
have
just
modals
or
sidebars
or
like
we
still.
That
makes
sense,
because
I
think
in
any
case
you
would
want,
like
that
full
view
right
so
yeah
for
writing
and
like
google.
A
B
Yeah,
that
was
something
I
was
asking
feedback
on,
like
the
idea
of
like
full
modals
right,
like
full
screen
modals,
where
it
could
actually
go
over
the
navigation.
Everything
like
that,
giving
you
more
focus
room
for
focus,
but
if
we
have
like
a
full
page,
you
know
the
details
page
and
then
also
the
full
screen
modal.
I
wonder
what
that
would.
It
might
be
weird
or
not,
but
anyway,.
A
A
B
Yeah
like
playing
around
oh,
these
are
all
look
really
ugly
but
yeah
like
the
idea
of
inline.
I
tried
to
like
think
of
the
kind
of
jobs
to
be
done
around
all
of
these,
and
it
does
get
a
little
strange
and
thinking
about
like
do.
We
want
to
be
opinionated
sometimes
right
like
do
we
want
to
say
at
some
views
like
if
you're
in
a
list
view,
then
it
must
be
a
full
screen
modal
or
if
you're,
within
an
epic.
B
A
B
And
I
was
playing
around
with
unpainting
like
pinning
it,
and
I
don't
know
when
you
would
want
this,
but
hey
someday,
maybe
but
yeah.
I
think
maybe
how
I
you
and
I
can
play
around
with
this,
but
like
what,
because
I
was
just
trying
to
figure
this
out-
I'm
like
what
are
the
jobs
to
be
done
when
you're
like
creating
versus
you
know
viewing
versus
editing,
because
I
know
we
were
talking
about
also
like.
Is
there
some
kind
of
view
mode?
B
That's
like
not
you
don't
edit
you're,
just
viewing
it's
more
of
like
a
reporting
mode
right
and
then
thinking
about
that
across
all
the
different
like
views.
We
have
like
within
a
single
object
within
a
list
view
or
road
map
or
like
visualization,
like
what
are
the
differences
there
and
yeah.
I
don't
know.
Inline
is
interesting
for
like
a
placeholder,
but
it
seems
less
useful
and
then
the
idea
of
like
sidebar
versus
full
screen
modal.
B
A
I
I
like
that.
I
also
wonder
from
what
we
learned
this
morning
with
eric
the
or
just
talking
holly.
You
brought
up
the
concept
of
layouts,
which
we
haven't
really
gotten
into.
We
keep
determining
the
layouts
for
list
view
and
modal
view
at
some
point
you
could
give
that
over
to
the
user
as
well
like,
if
they
don't
use
health
status
ever
like
they
take
it
out
of
their
layout
and
they
put
weight
over
in
that
top
right
corner
or
whatever.
The
thing
is
that
they
care
about
more.
A
B
A
And
diced
different
ways
like
I
might
have
a
layout
for
a
card.
That's
I
like
to
show
up
the
chain,
that's
a
lot
more
minimal
or
like
something,
and
then
I
have
like
a
detailed
like
label
throw
up
on
one
of
them,
because
I
need
to
actually
monitor
all
the
labels
like
there
could
be
different
fields
exposed
into
different
views
as
well.
A
A
Oh,
I
see
what
you're
saying
template.
Maybe
we're
saying
them
into
interchangeably
to
what
you
have
here.
The
layout
or
template
to
me
would
be
the
fact
that
there's
drag
and
drop
zones
or,
like
you
were
saying,
with
elementor
like
you've
got
a
title.
You've
got
a
bar
and
it's
got
like
three
sections
in
that
bar
and
now
I
can
decide
what
goes
in
each
of
those
three.
I
really
like
design
management.
So
I
drag
it
into
the
very
top
bar
or
like
do.
B
We
want,
I
think,
holly
you
mentioned
this
too.
Like
do.
We
want
a
column
on
the
right,
that's
like
just
design
management
and
then
a
column
on
the
left.
That's
like
you
know
whatever
like
a
task
list
with
assignees
attached
to
editor,
but
that
yeah
that's
what
I
think
the
layout
is
too,
but
that
could
be
a
template
right.
A
I
think
to
have
it
render
that
way
for
everyone,
and
I
think
that
this
is
kind
of
what
gabe
is
thinking
about
for
extensible
issues.
But
from
what
I
understand,
it
is
more
of
a
templated
situation
where
you're
creating
something
that
can
be
reused
again
and
again,
not
making
decisions
for
individual
issues
necessarily
but
more
for,
like
a
template
for
an
issuable
or
yeah.
Exactly
like
a
story.
A
Type
like
you'd
lay
out
a
story,
maybe
slightly
different
than
a
to
do
because
you're
different
things
right
and
you,
if
you're
a
parent,
you
could
have
customizable
widgets
on
your
template
that
are
tallying
things
up
from
its
children
like
a
roll
up
like
counting
all
the
issues
or
counting
weights
or
yeah.
So
tim,
I
said
layout
but,
like
I
think,
we're
saying
the
same
same
thing
with
a
template.
B
A
A
I
think
you
should
all
figure
out
the
best
way
to
show
the
story
or
an
issue
or
an
epic
like
like
we
were
saying
from
the
beginning,
what
needs
to
be
there
and
then
have
those
turned
on
with
the
mind
that
there
could
be
thinking
these
in
the
future
might
be
drop
zones
for
like
widgets,
and
when
you
finish
it,
you
might
find
some
are
full
with
some
like
what
do
they
look
at
if
full
width
descriptions
are
always
full
width,
but
maybe
they're
not
on
a
task?
Maybe
they're
tiny
or
I
don't
know.
B
A
Get
there
someday,
I
think,
for
now.
We
just
want
to
know
what
the
heck
are.
We
building
for
mvc
yeah,
so
epics
like
a
story,
essentially
support
the
idea
of
having
children
in
an
issue
type
and
use
those
new
modals
and
whatever
the
geography
of
it
needs
to
be
to
have
a
better
experience
built
on
view.
B
B
A
A
A
A
The
initial
proposal
was
a
full
epic
migration
within
six
months,
because
I
bumped
all
of
our
category
maturities
by
six
months,
but
I've
bumped
it
out
another
three
months.
I'm
gonna
do
the
mr
after
I
hear
from
engineering
but
another
three
months,
which
will
give
us
nine
months
total
for
getting
epics
over
so
six
months
to
figure
out
basically
project
level,
epics
and
then
another
three
months
for
the
team
to
take
what
we've
learned
and
do
a
migration
of
our
existing
users,
which
will
be
heavy.
A
Good,
I
I
admit
that
that
doesn't
sound
super
confident,
but
I
think
any
time
we
go
with
something,
this
big
there's
always
a
little
bit
of
room
for
discomfort
and
messiness
and
taking
risks.
So
I'm
I'm
comfortable
with
that
discomfort.
If
that
makes
sense,
is
that
around
the
timeline
of
it
or
the
the
steps
not
so
much
the
timeline,
I
think
the
I
think
the
steps
actually
sound
good
as
well.
A
I
think
it's
been
more
that
it's
just
felt
a
little
messy
up
until
this
point,
but
that
again
is
common
in
my
experience
that
it's
just
kind
of
messy
when
you're
trying
to
figure
out
exactly
where
to
start,
and
I
do
feel
like
we're
on
the
right
track
now
in
terms
of
defining
that.
So
that
feels
good
to
me.
B
A
This
one
yeah,
that's
the
one
I
was
talking
about
yeah,
I'm
gonna
change.
It
I'm
bouncing
the
new
plan
off
everyone.
I
got
gabe's
buy-in.
I
got
my
two
ems
buy-in,
I
guess
still
j
clear.
I
need
to
talk
to
and
we're
going
to
say
to
the
whole
team
tomorrow
on
the
call
it's
kind
of
the
new
plan
and
see
how
and
the
engineers
take
it,
but
within
here
this
is
like
my
proposal
to
take
it
to
stories,
and
then
there
are
still
in
terms
of
design
in
here.
A
But
we
can,
we
can
rework
these
to
whatever
your
heart's
content,
for
both
of
you
like
to
to
whatever
makes
sense
to
support
this
new,
like
the
new
move
towards
doing
stories.
Probably
what's
in
here
may
not,
I
think,
parenting
and
relating
is
really
going
to
be
applicable
and
customizing.
The
objects
which
is
the
showing
and
hiding
of
certain
columns
or,
but
we
don't
have
like
timelines
on
these
or
anything
or
actual
deliverables
tracked
to
them.
A
A
So
feedback's
like
welcome
on
that
as
well.
I
might
try
to
add
some
definition
or
some
timelines
rough
around
those
two.
I'm
not
sure
how
you
all
want
to
divide
your
work,
divide
and
conquer,
or
keep
going.
A
And
this
might
change
once
engineering
decides
as
well.
So
story
would
be
project
level
single
level,
epic,
in
this
diagram,
and
then
this
shows
what
I
called
it
a
feature,
but
we
could
call
it
anything.
That's
where
we
would
iterate
and
add
a
multi-level,
the
equivalent
of
having
sub
epics
at
the
project
level,
feature
story,
issue.
A
This
is
the
one,
though,
that
when
they
figure
out
multi-level
feature-
or
we
could
call
this
epic
at
the
project
level,
once
that
exists,
then
later
we
can
do
the
migration
from
the
normal
epics
to
the
project
level
ones,
because
groups
and
projects
will
have
merged
by
them
as
well.
A
There's
nothing
so
the
goal
is
we
get
on
this
new
object.
Epics
are
deprecated
issues
will
keep
existing,
but
the
idea
of
epics
and
epic
boards.
We
don't
need
anymore
because
we
have
all
of
these.
We
basically
already
built
epics,
and
these
will
render
on
boards
and
roadmaps
and
everything
else
by
this
point,
so
this
outlier
doesn't
really
need
to
exist,
but
our
customers
can
keep
using
it
for
six
months
and
keep
using
epic
boards
as
long
as
it
takes.
A
A
A
So
these
could
be
like
feature
story
issue
to
do
and
like
how
do
you
turn
epic
or
like
how
do
you
when
you
create
a
board,
you
set
its
base
as
one
more
thing,
this
board
is
just
epics
or
is
it
just
issues
or
is
it
multiples
there's
a
lot
of
fun
things
to
figure
out,
but
that
I
put
that
as
a
second
or
mvc3
was
like,
and
these
can
break
into
smaller
chunks,
but
rendering
both
on
one
view
is
something
we
haven't
done
yet
so
once
we
have
the
single
level
story,
we
could
then
render
issues
and
stories
on
a
roadmap
or
on
a
border
or
wherever
else
and
figure
that
out.
B
A
A
Okay,
the
new
object
and
because
it's
apparent
it
would
probably
like
mirror
epics,
but
we
could
decide
that
we
would
get
some
of
these
other
things
for
free
from
issues
that
we
hadn't
done
yet
on
fx.
So
you
might
just
decide
that
first,
like
we'll
make
sure
it
has
at
least
what
epics
have.
But
oh,
we
get
assignees
for
free
now,
because
we
never
had
those
before
on
epics,
but
we're
gonna
add
them
over
here
on
stories
so
that
that
that
should
be
the
opinionated
view,
you're
right,
where
it's
just
like
everything.
A
B
It's
okay,
though,
on
my
side
through
the
nbc's
and
just
kind
of
like
thoughts,
if
I
have
them,
but
thank
you
for
you
know
breaking
that
apart
and
scoping
it
kristen.
A
Yeah,
I'm
glad
everyone
kind
of
got
on
board
with
it.
I
was
worried,
gabe
wouldn't,
but
he
had
already
like
he
had
the
same
idea,
so
it
worked
out
pretty
well
so
hopefully,
the
engineering
team
will
also
be
on
board
with
that
and
we
can
just
get
around
a
whole
lot
of
those
risks
and
blocks
and
api
discussions
right
off
the
bat
and
just
get
into
the
ui
and
how
do
they
connect.
B
A
A
All
right
well,
thank
you.
Thank
you
and
alexis
I'll
tag
you
and
all
the
stuff
that
I've
been
doing
just
so
you
can
be
involved
there.
B
B
Awesome,
thank
you.
Oh
and
I'm,
like
I
said,
I'm
going
to
try
to
post
more
like
ideation
stuff,
so
we
can
catch
up
like
async
as
well.
Cool
sounds
good.