►
From YouTube: Plan Stage Weekly 2021-06-09
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
All
right
welcome
everyone
to
the
plan
stage
group
sync
we're
going
to
use
the
time
today
to
go
through
the
planning
objects.
Kickoff
part
two,
but
I
wanted
to
welcome
melissa
to
the
call.
A
C
Thank
kristin
and
hi
everyone
I'll
reach
out
to
each
of
y'all,
because
I
do
want
to
have
coffee
chats
with
everyone.
It's
going
to
take
me
time
to
get
through
everyone,
but
in
the
meantime,
if
you
want
to
just
drop
something
on
my
calendar,
please
feel
free
to
do
so
about
me.
I'm
in
austin,
texas,
I've
been
with
gitlab
for
about
a
year
and
prior
to
this
I
was
working
in
manage
access,
so
I
may
have
interacted
with
some
of
you
in
issues,
but
maybe
not
but
excited
to
be
here.
C
Yeah
so
funny
thing
is:
I
started
my
role
three
weeks
ago,
but
then
I
had
signed
up
to
be
ceo
shadow,
basically
after
my
first
week
on
this
job,
but
now
I'm
back.
It
was
a
really
great
experience.
If
any
of
you
are
interested
in
learning
more
I'm
happy
to
chat
offline
about
it,
but
it
was
really
good
you
should
you
should
all
sign
up.
A
A
I
wanted
to
just
mention
that
after
our
last
call
and
we
can
scroll
down
and
look
at
the
notes
from
last
call,
we
didn't
get
through
very
much,
but
there
was
a
lot
of
risk
that
was
highlighted,
included
being
blocked
by
the
migration
of
projects
and
epics
and
a
lot
around
how
big
the
migration
would
be
and
how
much
work
it
is
to
get
the
goal
of
epics
being
live
in
six
months.
A
It
just
seemed
kind
of
insurmountable
from
my
side
as
I
was
reading
through,
and
I
worked
a
little
with
justin
to
try
to
think
about
how
to
break
this
down
or
make
it
more
achievable
from
a
product
standpoint,
because
we're
really
looking
at
like
an
additional
six
to
even
12
months
of
risk
based
on
just
looking
at
where
things
are
at
and
how
big
this
is,
and
so
I've
added
a
proposal
to
break
this
down
smaller
and
to
change.
A
My
goal,
which
was
have
epics,
live
in
six
months
to
just
working
on
a
project
level
planning
object
that
I'm
I'm
going
to
call
story
for
this
mvc
and
I'll.
Just
I'll
walk
you
through
it.
So
you
can
sort
of
think
hear
my
thinking.
A
So
there's
been
and
if
you
want
to
see
some
background
from
product,
there's
a
youtube
video
where
scott,
anupe
and
justin
talk
about
hard
cut,
overs
and
migrations
in
their
careers
and
how
hard
that's
been
for
teams
and
ours
was
essentially
rolling
up
to
be
a
hard
cut
over
because
we
had
to
have
api
switch.
A
We
had
to
have
customers
switch
over
to
this
new
ui
and
they're,
relying
on
epics
and
issues
for
their
daily
work
and
a
migration
and
have
that
all
kind
of
come
together
in
a
grand
symphony
or
like
a
moment
where
we
would
just
cut
over
and
so
to
de-risk
that
that
well
I'll
just
go
through
this.
So
the
original
was
a
full
epic
migration.
In
six
months.
A
Looking
at
all
of
the
feedback,
and
just
talking
to
some
of
the
teams,
there's
going
to
be
a
really
long
timeline
with
tons
of
risk,
so
we
wouldn't
be
able
to
really
lock
it
in
and
tell
our
customers.
When
things
were
happening,
it
would
have
a
need
for
precision
and
perfection
with
our
existing
users.
A
We
would
have
a
big
migration
we'd
have
to
support
the
old
apis
and
then
the
burden
on
users
for
a
large
cut
over
where
we
may
just
have
ui
bugs
to
work
out.
What
I
mean
by
that
is
like
we're
going
to
be
testing
this
new
layout
for
issues
and
like
just
having
our
current
customers
suddenly
have
that
be
on
their
epics
would
be
a
lot
more
noise
for
them.
While
we
work
out
the
small
things
and
they're,
just
it
just
adds
risk
to
our
customers.
A
A
A
That
story
object,
and
we
would
make
sure
in
the
docs
that
we
make
it
clear
that
that
object's
in
beta
or
some
minimal
maturity
and
not
suggested
for
business
use
until
we
get
it
to
a
point
where
we
feel
comfortable,
and
so
these
mvcs
are
all
up
for
iteration.
These
are
just
me
thinking
this
through,
and
so
this
is
why
I'd
really
like
the
team's
input
as
well,
but
I'm
just
gonna
talk
through
each.
How
I
could
see
it
initially
chunking
down
and
then
I'm
sure
you
all
have
some
other
ideas.
A
So
this
is
just
a
diagram
of
what
I
was
explaining,
but
essentially
we
would
leave
epics
at
group
level,
as
is
they
could
still
relate
to
issues,
and
we
would
just
work
on
this.
New
story
object
single
level,
so
we
could
work
on
list
views,
details,
views
urls
having
them
render
on
issue
boards,
template
hierarchies
behind
the
scene,
scalable
urls
tracking
things
like
that
mvc2
we
could
layer
in
that
multi-level
epic.
We
would
already
have
parenting
figured
out
for
one
level,
then
it's
figuring
out.
How
do
we
have
up
to
seven?
A
So
this
is
essentially
building
the
multi-level
epics.
It's
that
group
making
sure
this
works
on
the
new
system,
where
we
could
go
to
seven
levels
deep
and
again
supporting
that
in
these
different
views
and
vc3
is
starting
to
render
these
on
different
areas
together.
So
up
until
now,
we
usually
just
either
render
an
epic
and
or
an
issue
on
a
board,
but
now
suddenly
we
can.
These
are
all
going
to
be
issue
types.
A
We
could
start
rendering
stories
and
other
things
on
our
roadmaps
or
other
places
around
the
app
and
then
once
we're
unblocked
by
the
merging
of
groups
and
projects
or
whenever
that
happens,
or
whenever
it
makes
sense
to
the
team.
A
Then
we
could
like-
and
we
know
this
structure
then
we
can
start
this
migration
effort
and
I'm
willing
to
add
like
to
the
guesstimated
time
like.
I
know
we
said
six
months
just
to
talk
to
tell
our
customers
moving
back.
For
this
whole
thing,
I'm
going
to
be
adding
another
three
months
to
support
the
epic
migration
at
the
end.
A
So
yeah
I
want.
I
wanted
to
just
get
the
team's
take
on
that
see
if
that,
if
it
makes
sense,
it's
a
departure
from
the
the
big
push
over
to
epics,
but
I'm
just
curious
to
hear
from
the
engineering
team
your
thoughts
on
that
and
if
it
would,
if
it
makes
sense,
if
there's
any
way,
we
could
tweak
it
to
make
it
even
more
iterative.
B
Thanks
kristen
just
a
first
thought
or
question:
what
is
the
exactly
difference
between
a
story
and
epic
objects
supposing
that
in
mvc4
or
whenever?
Basically,
both
can
leave
on
project
level?
So
what
will
be
the
differentiation
between
ports.
A
Yeah,
so
they're
gonna
behave
the
same
way
and
essentially
any
object
that
has
children
would
behave
like
an
epic,
so
it
really
comes
down
to
what
we
call
it.
So,
at
the
time
of
migration,
we
could
call
stories
like
project
level
epics
if
we
wanted
to
retain
them
and
we
could
talk
to
our
customers
and
then
have
epics
be
the
ones
that
live
at
group,
so
we
could
have
them
side
by
side
in
the
issue
type
table.
A
B
E
A
I
get
it
right
or
technically,
but
the
old
object,
but
we're
still
going
to
have
that
as
a
feature.
So
the
group-
and
maybe
I
misunderstood
your
question
once
this
works
and
once
we
can
move
issue
types
up
to
the
group
level,
we
will
have
a
default
object
called
group
at
epic
level
and
it,
but
it
will
be
based
on
issue
type.
F
One
other
question
is
because
we
allow
issues
to
be
linked
to
epics
how
the
relationship
work
between
epics
and
stories
and
features,
and
so
on.
We
do
not
allow
do
we
break
the
linkage
between
the
issues
and
the
epics
yeah
we
just
allow
for
so
for
issue
type
issue
to
be
linked
to
the
epics.
What's
the
idea
there.
A
This
object
is
going
to
be
deprecated,
so
the
in
this
plan,
epic,
as
it
lives
now
and
epic
boards
that
run
off
that
option
that
different
object
from
the
issue
type
model
would
go
away
so
for
six
months
to
12
months.
However
long
it
takes
us
to
do
this
mark,
our
customers
will
keep
using
their
epics
and
their
issues
as
is,
and
their
epic
boards
they'll
have
everything
they
need
to
keep
their
business
running.
A
Then
we
have
to
figure
out
once
issues
can
live
at
group
level
from
the
merging
of
groups
and
projects,
then
the
the
questions
you're
asking
around
the
migration,
which
would
be
that
final
step,
actually
migrating
the
epic.
So
we
have
they'll
have
a
choice.
The
team
are
to
figure
out
how
to
do
that.
We
could
take
what
we've
built
here
at
project
level.
A
A
I
don't
think
we
would
merge
these
down
the
current.
I
don't
think
we'd
migrate
them
onto
a
project
level,
epic,
because
our
customers
are
used.
They
are
all
built
at
the
group
level,
so
it
wouldn't
really
make
sense
to
migrate
them
down
into
the
project.
F
Eventually,
that's
where
they
will
end
up,
it
will
just
be
sort
of
an
extra
step
for
them
to
press
that
migrate
button.
Well,
the
virtual
migrate
button.
So
to
say,
when
we
have
the
feature
on
the
story,
the
epics
will
will
end
up
basically
at
either
project
or
or
group
level,
yeah,
it's
like
during
the
implementation
phase
of
the
feature
and
story
and
all
that
stuff.
While
we
don't
well,
we
have
both
epic
and
the
issue
types
it
seems
like.
F
A
A
F
Creation
might
not
be
that
easy,
where
I'm
not
sure,
I'm
not
visually
envisioning
it
right
now,
but
it
seems
to
complicate
things
quite
a
bit.
A
A
Like
that's
another
way,
we
could
architect,
it
just
have
an
alternate
story
to
issue:
that's
only
exposed
to
our
project
and
we
and
then
none
of
our
customers
would
even
see
this
object
until
it's
ready
to
go.
But
that's
a
good
point
yeah.
We
would
want
to
just
the
way.
Epics
right
now
can
filter
issue
types
that
aren't.
A
E
A
That
eventually-
and
I
think
I
showed
this
last
time
so
currently-
our
default
is
just
epics
and
issues
or
if
you
have
multi-level
on
it,
goes
epic
sub
epics
to
issue,
but
our
customers
in
portfolio
planning
want
to
do
things
like
stack
a
template
like
initiative,
epic
story
task
like
or
project
epic
issue
task.
A
We
also
have
there
could
be
simpler
models
where
you
just
have
two
in
this
in
the
stack.
So
where
we're
going
with
this
is
that
the
template
needs
to
be.
I
called
the
customer
created
template,
but
the
stacking
of
those
items
needs
to
be
a
part
of
this
work
that
we're
doing
right
now
to
figure
out
how
these
things
come
together.
F
Some
default,
I
think,
we'll
come
up
with
epic
story
with
some
default
names,
but
they
will
be
editable
by
user.
They
can
redefine
them
if
they
want
to.
Oh.
E
A
It
collab
jacks
for
a
while
and
now
we're
calling
them
planning
objects
is
a
bit
like
generic,
because
the
word
issue
type
to
our
customer
doesn't
make
sense
because
they
think
about
these
objects
like
epics
or
stories
not
as
issues,
but
under
the
hood.
It's
our
yeah.
We
can
call
it
whatever
we
want.
They
stay
as
issue
types
and
sorry.
I
didn't
make
that
more.
C
Clear
so
kristen
to
kind
of
tailwing
on
that.
Essentially
the
problem
that
you're
trying
to
solve
the
first
problem,
you're
tackling
with
this
iteration,
is
having
a
object
hierarchy
within
a
project
right,
that's
the
essential
goal
of
like.
If
you
only
have
a
project,
you
can
create
a
one-level
work
breakdown.
F
A
A
Just
for
I
tried
to
pick
the
simplest
one
yeah,
so
it
would
be
a
one
level
we
could
also
you
could.
We
could
choose
to
not
do
stories
and
make
it
issues
as
the
parent,
but
there's
a
lot
more
people
using
issues
and
we,
but
we
could
go
the
other
way
and
say
the
first
thing
we're
going
to
do
is
do
a
task
off
of
an
issue
they're
all
going
to
do
the
same
thing,
though.
Essentially
it's
they're
going
to
have
children
and
they're
going
to
have
one
level
deep.
E
A
E
Well,
so
I
guess
my
question
is:
why
are
we
bringing
a
new
concept
of
story
into
this?
Necessarily,
it's
really.
We.
We
just
need
to
add
the
hierarchical
components
that
epic
has
now
into
issues
to
give
that
ability
and
then
add
the
custom
issue,
type
stuff
and
right
get
most
of
this.
A
So
I
mean
we
could,
if
engineering
decides
that,
that's
the
way
it
should
go
and
we
should
do
it
under
issues.
First,
we
could
do
that
from
the
portfolio
planning
team,
because
we're
making
this
investment
as
well
and
just
like
stopping
six
to
nine
months
of
work,
I
need
to
be
able
to
have
new
objects
to
talk
about
with
our
customers,
how
they're
going
to
work,
get
their
feedback.
A
This
is
how
they
think
they
think
about
stories,
issues
and
things
like
that
around
epics,
so
it
makes
sense
from
my
standpoint
to
start
with
the
one
above
it
and
then
also
no
one's
relying
on
that
view.
Yet
so
it
gives
us
more
play
in
terms
of
having
something
truly
new
that
we
could
turn
off
from
everyone
and
not
even
get
into.
We
could
work
on
this
this
view
page
and
the
issues
would
all
be
showing
as
children
and
our
like
customers
could
be.
None
the
wiser
that
this
exists
for
a
while.
F
Can
you
show
the
the
incident
epic
story
diagram
one
more
time,
it's
initiative.
F
F
So
if
you
have
like
you
as
a
customer,
I
think
we
need
to
allow
them
to
define
these
kind
of
validations.
Where
you
say,
initiative
should
only
have
ch
as
child
epics
or
another
way
to
say.
Epic
can
only
have
a
spot
in
the
initiative,
and
story
can
only
have
aspirin
the
epic,
and
you
cannot
have
the
story
to
have
the
parents
initiative.
Is
that
correct.
E
But
but
but
isn't
doesn't
that
I
mean
each
of
each
of
these.
These
custom
issues
are
are
basically
infinitely
configurable,
because
the
customer
can
make
them
anything
they
want.
They
can
change
the
name
of
the
story
to
something
else
unless
you're,
unless
you're
making
them
first
class
objects
in
the
system,
which
I
don't
know,
necessarily
that
we
are.
F
No,
but
if
you
have
an
issue
with
type
issue
and
an
issue
with
type
incident
right,
you
should
not
be
able
to
to
make
that
issue
type
incident
parent
for
the
issue
right.
So
there
is
another
level
of
validation
on
top
of
of
currently,
because,
like
we
have
linked
issues
you
can
you
can
create
this
hierarchy
right
now
and
every
single
initiative.
Epic
story,
will
just
be
an
issue
right.
E
F
E
A
From
a
ux
standpoint,
the
reason
why
also
is
because
we'll
have
the
new
view
app
running
on
this
new
object.
We'll
do
the
new
layout
that
holly
and
alexis
have
been
working
on
that
will
heavily
involve
getting
the
children
in
the
right
way
so
that
it
makes
sense
when
you're
doing
a
top-down
plan
that
we
have
in
epics
right
now.
So
just
to
be
clear
where
all
the
other
thing
is
we're
migrating
onto
view.
C
So
that's
something
to
consider
and
then
also
I'll
say,
at
least
from
my
experience,
like
probably
80
of
customers
have
a
very
specific
mental
model
already
around
like
stories
like
tasks.
Stories
features
epics
right
because
of
like
the
frameworks
that
exist
out
there.
So
we
build
a
pretty
basic
default
model,
that's
baked
into
gitlab,
with
that,
I
think
that's
like
80
or
more
percent
of
people.
D
Yeah
this
is
it.
This
is
a
little
confusing
because
we
have
like
yes.
Ideally
it
would
be
a
brand
new
object,
but
in
reality,
on
the
back
end,
it's
not
we're
just
extending
our
current
issue
of
bulls
table.
So
I
think
to
brett's
point
and
you
kind
of
went
through
the
same
thinking
that
I
did.
D
I
think
it's
easier
to
go
with
hierarchical
issues
before
we
start
worrying
about
like
defaults,
because,
we'll
add
we'll
add
a
we'll,
add
an
issue
type
for
stories
here,
which
will
essentially
just
be
everything
from
the
issues
table
with
just
another.
Just
another
param.
D
Let's
say
that
says
it's
a
story:
do
we
really
need
to
box
that
in
on
the
back
end
side,
probably
not
that's,
probably
something
we
can
figure
out
on
the
front
end
like
if
we
want
a
complete,
separate
ui
for
something
that
are
stories,
it
can
just
be
a
complete,
completely
separate
ui
for
issues
that
that
have
a
child
issue.
H
I
just
think
that,
like
we
haven't
yet
done
the
figuring
out
of
how
we
would
implement
this
so
like
think
of
story
or
whatever
term
in
this
as
the
concept
of
like
here's,
the
goal
we're
trying
to
achieve,
and
it's
to
simplify
so
that
we're
not
we're
not
dealing
with
epic,
which
carries
a
lot
of
current
baggage
and
functionality
around
it.
We're
dealing
with
something
new
and
if
that's
something
new,
is
an
implementation
of
the
issue
type
stuff
that
you've
already
been
thinking
about.
H
Then
that's
that's
fine,
like
that's
a
good
approach
to
to
get
us
there.
I
think,
is
what
if
that
makes
sense,
I
don't
know
if
that
helps
clarify
anything
at
all,
but
I
think
that,
like
it
doesn't
the
story
as
presented
in
the
the
the
mvcs
that
kristen
put
together.
H
G
A
G
D
Real
quick,
john,
the
only
difference
there,
though,
is
that
they
will
have
issues
as
children
right.
D
A
G
G
I
think
that's
that's
the
intention
right
and
then
we
get
a
little
closer
to
epics
at
the
project
level
generally
and
sort
of
shrink
that
problem
surface
area
a
little
bit
further,
but
I
I
would
take
on
board
like
some
of
the
things
that
brett
said,
they're
like
when
we
do
get
to
the
point
where
we
have
custom
issue
types:
are
we
going
to
allow
customers
to
create
a
custom
issue
type
and
define
what
that
issue
type
will
be
able
to
be
the
parent
of
like?
G
G
G
So
if
I
don't
get
the
functionality,
in
other
words,
that
we've
defined
I.e
incident
goes
to
epic
goes
to
story.
Our
initiative
goes
to
epic
goes.
The
story
goes
to
issue
and
I
really
just
want
initiative
going
to
a
set
of
issues.
I
have
to
create
a
separate
custom
issue
type
for
that
and
create
that
whole
relationship
myself.
F
E
F
Shared
some
some
vision
on
that,
where
we
defined
the
types
and
then
we
defined
how
those
types
relate
to
one
another.
So
so
that's
the
kind
of
the
end
goal.
I
like
iteratively,
how
we
get
there
it
depends,
but
I
think
he
was.
He
was
saying
that
what
we
want
to
do
is
being
allowing
customers
to
define
the
types
and
then
allowing
them
to
also
define
the
relationships
between
the
types
themselves,
which
will
kind
of
act
as
a
validation
on
the
actual
issue,
objects
right.
D
Yeah
and
then
us
just
having
like
templates
that
say,
okay
for
this,
this
way
of
doing
project
management.
You
have
epics
the
stories
to
issues,
but
someone
else
can
go
in
and
say
they
want
to
have
issues
to
epics
the
stories.
The
other
way
around.
E
I
mean
we're
cur
we're
currently
already
working
on
putting
custom
issue
types
in
play
with
a
default
set,
so
a
bug
feature
a
couple
other
ones.
So
that's
you
know
we
have
mrs
open
for
that.
Already
that
begin
that
process.
So
then
we're
just
we.
You
know
it
sounds
like
we
want
to
be
able
to
add
the
hierarchy.
On
top.
A
The
other
thing
to
consider
is,
we
do
still
need
to
charge
for
and
have
gating
around
multi-level
and
that's
why
I
added
that
in
as
the
second
iteration
being
able
to
go
seven
levels
deep
of
the
same
object
and
that's
up
for
discussion
in
terms
of
how
we
figure
out
the
pricing.
But
that
would
be
the
other
gate.
It's
just.
A
There
needs
to
be
a
reason
to
up
tier
for
some
of
this
and
that's
up
to
product
to
figure
out
where
those
gates
are
around,
but
I
just
wanted
to
mention
that,
because
maybe,
if
their
ultimate,
they
could
go
to
infinity
and
then,
but
we
would
also
have
to
make
sure
that
the
ui
and
the
architecture
supports
it.
Because
we
put
a
cap
of
seven
on
multi-level
right.
E
A
D
G
C
A
Yeah
we
can
talk
about
that
when
we
get
a
little
closer,
but
that
that
is
a
question
to
have
and
whether
they
would
just
want
them
to
stay.
My
assumption
would
be.
The
majority
would
just
want
them
to
kind
of
stay
as
epics
as
is,
but
if
we
could
allow
them
to
choose
the
object,
that
could
be
very
cool.
I
just
want
to
be
cognizant
of
it
being
small
enough
chunks
for
us
to
consistently
do
it
and
then
have
a
consistent
like
if
we
leave
it
up
to
the
user
to
make
a
choice.
A
G
It
might
make
more
sense
to
from
a
technical
perspective,
to
do
the
stories.
First,
then
epics
them
are
multi-level
epics
at
the
project
level
as
issue
types
and
then
migrate.
Everything
and
then
worry
about
all
the
other
different
types
so
yeah,
but
hang
on
because
I,
how
do
you
decide
which
project
to
merge
the.
E
A
But
the
all
of
these
are
fuzzy
nvcs
that
I
put
up,
so
we
can
break.
We
have
to
put
four.
We
could
break
this
into
seven.
We
could
have
like,
like
you
mentioned
all
of
our
single
level,
epic
user
customers
be
their
own.
Migration,
then
have
a
separate
one
for
multi-level,
like
we
could
get
more
specific
and
break
these
out.
This
is
just
the
very
beginning
of
the
iteration
in
terms
of
how
the
mvcs
work
across
the
board
in
this
issue,
too,.
D
Real
quick,
the
nbc's
you
have
within
this
is
within
the
proposal.
Npc
one
is
for
project
level,
object,
called
story
issue.
Those
are
nbc's
of
the
mvc
right,
not
not
nvcs
of
the
higher
level.
A
Yeah,
I
wasn't
sure
what
to
call
them.
To
be
honest,
I
said
the
proposal
is
mvc1
because
before
we
just
had
it
like
epics,
as
this
whole
thing
going
out
in
six
months,
so
maybe
I'll
call
it.
The
initiative
at
the
title
proposal.
Initiative
for
project
level
object,
called
story,
and
then
the
mvcs
can
be
separate
from
from
that.
B
G
I
thought
it
would
be
an
issue
link,
but
just
with
a
new
link
type
apart
from
related
or
blocked.
B
A
B
Yeah,
I
was
just
curious
about
whether
we
need
a
new
issue
type
or
not,
because
I
I
understood
this
would
be
just
another
reusable
widget
or
component.
I
mean
this
parent
child.
Here
are
his
same
as
we
have
we.
We
will
have
either
related
issues
or
whatever
we
want.
So
then
we
can
just
easily
configure
for
which
issue
types
this
hierarchy
will
be
available
and
which,
for
which
it
won't.
But
we
can
dive
into
these
details.
A
Later
but
yeah
the
parented,
I
have
that
in
hot
pink,
because
anything
in
hot
pink
is
kind
of
like
new.
With
this
new
object,
that's
something
that
does
have
to
be
figured
out,
the
parenting
widget
or
whatever
we
call
it
would
be
dropped
into
this
new
story
object.
Does
it
also
start
existing
on
test
cases,
requirements?
A
E
F
B
Yes
right,
I
yeah,
I
mean
yeah.
B
B
A
A
F
F
But
what
would
be
the
issue
to
having
them
use
both
to
you
like?
Why
are
you
raising
this
like
having
these
stories
be,
as
is
kind
of
a?
We
can
still
keep
the
epics
as
a
separate
widget
and
component
and
show
it
in
sidebar,
where
wherever
we
want
to
right,
yeah
and
then
having
the
the
so
to
say,
another
widget
or
component
called
parent,
which
will
show
either
story
or
any
other
initiative.
B
F
Yeah,
it's
a
bit
overwhelming
the
whole
vision
to
think
about
that
like
to
the
end,
but
that's
and
that's
probably
to
me-
that's
the
main
problem
right
now
to
break
it
down
to
next
step.
What
do
we
do
next
to
get
us
that
much
closer
to
that
end
vision,
and
I
I
kind
of
praised
it
and
it's
like
it's
a
bit
overwhelming
to
think
about
the
entire
thing
and
how
we
get
there.
B
Also,
we
had
a
couple
of
chats
with
imre
from
manage
team
and
they
are
taking
project
group
consolidation
as
a
high
priority
now,
and
there
should
be
some
update
on
the
blueprint.
But
there
is
some
chance
that
this
will
move
forward
in
in
let's
say
next
months
or
next
cycles.
So
we
should
take
into
account
the
chance
that
projects
and
groups
will
be
consolidated
into
one
into
the
same
same
object,
yeah.
B
C
Other
voice
over
what
I,
what
if
I
see
you're
responding
kristen
we
can,
we
can
discuss,
but
I
think,
having
multiple
parents
for
a
single
thing
makes
it
confusing
later
down
the
line.
If
you
ever
want
to
do,
reporting
and
attribution
of
work
right
and
sort
of
slicing
and
dicing,
because
then
it's
like
well,
where
does
it?
Where
is
the
credit
go
to
right,
parent,
one
or
parent
two
or
like?
How
do
you
split
it?
C
It
becomes
complicated
when
you're
thinking
about
these
kind
of
like
higher
level
executive
reports,
so
my
vote
would
be
to
have
a
single
parent
for
an
issue
and
then,
if
we
want
to
have
different
ways
that
we
can
say
like
this
is
related
to
this,
or
also
contributes
to
this.
It's
like
that
would
be
my
preference
right,
but
as
far
as
like
parent,
it's
much
easier.
If
there's
one.
A
But
it's
something
we
have
to
look
at
for
sure
and
just
figure
out
in
this
new
world.
Could
we
get
away
without
multiparent?
Is
there
a
way
to
do
that
or
do
we
have
to
still
light
that
up?
But
that's
a
big
ask
from
their
side
that
we've
been
trying
to
figure
out
from
a
portfolio
planning
space?
How
do
we
actually
support
our
executive
team
in
get
lab.
C
Yeah,
I
think
I
agree
right,
there's
a
need
to
like
relate
things
and
slice
and
dice,
but
as
far
I
think
what
is
helpful
to
me
in
this
perspective
is
like
thinking
about
work
breakdown
versus
relationships
of
like
what
does
this
work
contribute
to
right?
It's
a
little
bit
different.
We
can
talk
offline.
I
should
probably.
E
C
Down
a
bunch
of
thoughts
about
this,
but
it's
different
when
you
think
of
like,
what's
the
high
level,
almost
like
budget
sort
of
like
item
that
you're
chipping
away
to
work
on
this
thing
versus
what
does
this
issue
move
the
needle
on
right?
It's
a
little
bit
different.
A
A
D
In
there
yeah
I'll
work,
probably
technically
at
times
yeah
yeah,
we
can
go
until
then
30.,
the
that's
my
question.
I
lost
track
of
it.
Oh
so,
if
we're
sandboxing
this
for
this
mvc
stories,
are
we
gonna
show?
So
is
the
plan
then
not
to
show
stories
within
the
issue
view
until
down.
C
A
D
Okay,
so
that
might
be
a
little
weird,
then
if
something
is
like,
if
people
are
using
epics
and
stories.
F
A
Yeah,
I
think
that
if
we
end
up
doing
this
behind
a
feature
flag,
then
it
would
be
okay
to
have
that
and
have
it
work
on
it
for
our
own,
because,
like
yeah,
this
issue
technically
could
go
into
both
or
we
could
start
top
down
and
just
work
on
the
story
detail
view
if
that
makes
more
sense
to
the
team
and
just
look
down
at
your
children
from
that
standpoint.
H
Well,
I
would
say
we
probably
don't
have
any
fewer
questions
than
we
came
in
with,
but
I
think
like.
We
have
at
least
some
more
some
better
direction
and
we
can
there's
there's
plenty
of
discussion
too.
I
do
think
and
kristen
thank
you
for
kind
of,
like
I
think
you
echoed
what
many
of
us
were
feeling
after
the
last
time.
We
talked
about
this,
which
was
just
sort
of
like
an
overwhelming
sense
of
dread.
H
So
thanks
for
sort
of
like
narrowing
it
a
bit
and
and
then
we
can
kind
of
go
from
here
to
you
know,
and
especially
taking
into
account
some
of
the
stuff
that
that
that
brett
and
yon
were
both
talking
about.
With
regards
to
issue
types,
I
think
that
also
gives
us
an
opportunity
to
kind
of
align
this
more
practically
with
like
stuff
that
we've
already
been
doing
and
thinking
about,
and
we
have
code
in
progress
for
so
it
doesn't
necessarily
feel
like.
H
You
know,
pivoting
from
a
lot
of
stuff
that
we've
already
been
doing
so.
I've
noted
you
on
one
thing
with
regards
to
your
question
on
on
how
we
would
sorry,
I
just
lost
my
train
of
thought
entirely,
but
like
whether
the
parent
child
hierarchy
should
be
implemented
as
a
reasonable
component
or
something
that
has
its
own
table
or
whatever
it
is.
H
I
think
that's
a
pretty
deep
one,
so
we
should
break
that
out
into
if
it's
not
already
in
the
the
longer
threat
that
alexandria
put
together
and
we
can
keep
working
on
that
and
then
something
that
came
up
in
my
one-on-ones
at
least
was
the
possibility
of
doing.
I
think
we
can
make
a
lot
of
progress
on
these
discussions
asynchronously,
but
you
know,
should
we
continue
talking
about
the
synchronously?
H
Some
of
this
stuff
is,
is
big
and
hairy
enough,
where
it
feels
like
easier
to
talk
about
synchronously,
but
it's
also
hard
to
get
all
the
viewpoints
we
want.
So
I
don't
know
how
you
all
feel
about
that.
E
And
kristen,
I
I
just
wanted
to
say
this.
This
all
looks
pretty
good,
I'm
sorry,
I'm
I'm
my
head's
already
down
and
then
they'd
be
gritty,
details
and
stuff.
A
It's
all
good,
I
think,
we're
all
trying
to
get
to
the
same
place
and
any
feedback,
even
if
we
do
it
async
and
that
issue
if
we
can
break
those
nvcs
to
smaller.
Please
let
me
know
I'm
also,
if
you
want
it
like
jake
just
suggested.
If
we
want
to
keep
doing
sync
calls
like
on
a
weekly,
cadence
or
bi-weekly
until
we
get
some
really
high
level
decisions
made
about
next
steps.
A
C
Maybe
kristin
and
next
step
would
be
to
kind
of
like
outline
what
those
boxes
that
need
to
be
checked
are
and
then
like
figure
out
how
many
of
those
can
be
done.
Asynchronous
asynchronously.
A
So
I'll
draft
an
engineer
like
a
list
for
the
engineering
team
to
fill
out
in
terms
of
like
what
are
the
high
level
decisions.
I
know
last
week
we
made
one
it
was
that
we're
gonna
stay
on
the
issue
table.
That
was
the
one
thing
I
pulled
out
of
the
the
notes,
but
if
there's
open
open-ended
decisions
to
be
made
around
the
parenting
widgets
or
things
like
that,
let's
just
get
it
into
one
place.
So
we
can
see
some
bullets
on
that
and
then
we
can
organize
around
it.
G
Kristin,
could
you
see
alex's
issue
to
see
if
that
sort
of
fulfills
that
requirement
like,
ideally,
if
we're
going
to
have
sync
calls?
Ideally,
the
the
questions
would
start
as
topics
in
this
issue
and
then
a
lack
of
resolution
would
mean
that
it
requires
some
synchronous
discussion.
But
if
we
can
resolve
them
asynchronously
in
the
issue,
then
we
should
just
try
and
close
off
as
many
of
these
as
possible.
A
G
Yeah,
I
don't
recommend
getting
you
know
studying
too
much
of
the.
G
Of
how
this
will
be
designed,
but
undoubtedly
like
some
of
the
decisions
will
be
contingent
upon
product
decisions
as
well
and
and
some
of
the
outcomes
will
be
so
like
borderline,
that
the
products
requirements
might
actually
tip.
One
decision
either
way.
Yeah
and
the
good
thing
about
the
skoda
is
that
it
should
put
everything
into
the
into
the
issue
description.
Like
summarize,
all
the
main
points
in
the
issue,
description,
so
that
you
don't
have
to
go
down
through
the
discussions
and.
G
I
didn't
I
wasn't
able
to
watch
that
far
in
the
traditional
video
on
the
skoda.
For
some
reason
it
kept
freezing
for
me.
So
I'm
not
quite
sure
what
those
mean,
but
I
think
like
if
there's
anything,
if
there's
some,
if
there's
a
point
that
somebody
wants
raised
like
so
that
everyone
outside
of
the
technical
discussion
can
see,
can
see
it
they'll,
add
pro
or
con
in
front
and
the
point
point
prefix
that
causes
it
to
be
entered
automatically
into
the
issue
description.
G
F
F
A
Okay,
so
these
are
our
current
all
of
our
open
questions
that
need
to
be
solved,
and
then
status
on
those
is
going
is
ongoing
and
we'll
figure
out.
If
we
need
sync
calls
to
talk
through
some
of
them
and
then
we'll
I'll
figure
out
sort
of
when
we,
because
we
have
to
start
scheduling
for
14.1,
we
need
to
figure
out
what
we're
scheduling
are
we
scheduling
spikes
are
we
have?
Can
we
get
some
of
this
work
started
to
do
this
nbc
of
a
story?