►
From YouTube: 2021-07-02 - Planning Object Eng Kickoff
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
Kickoff
for
engineering
we've
been
iterating
in
design
for
about
four
weeks
on
this,
so
it's
exciting
to
have
the
engineering
team
get
involved
and
we
can
start
thinking
through
some
of
the
tough
questions
around
planning
objects
and
where
we
go
with
this
feature
in
general,
I
wanted
to
just
start
and
quickly
give
a
high
level
on
the
meeting
format
and
just
sort
of
how
it
will
go.
A
The
first
section,
10
to
15
minutes,
will
be
a
combo
of
each
pm,
sharing
their
vision
and
kind
of
their
investment
in
this
and
where
this
is
going
and
then
we'll
have
holly
summarize
the
learnings
from
what
they've
learned
in
the
design
phase
so
far
from
where
we
want
to
go
and
then
the
last
the
biggest
chunk
of
it
will
be
for
everyone
to
think
through
deep,
like
deep
thinking
on
what
we
actually
need
to
do
to
make
these
mvcs
happen.
A
So
I
can
start
in
terms
of
investment,
so
the
product
planning
team,
I'll
just
speak
to
mine
first
and
gabe
and
mark-
can
also
talk.
But
we
recently
pushed
back
our
category
maturity
on
all
of
our
features
by
six
months.
So
we've
opened
up
a
six-month
window
where
we
can
devote
all
of
our
capacity
to
figuring
out
this
problem.
A
B
Pretty
much
the
same
for
project
management,
so
we're
kind
of
putting
most
new
feature
development
on
hold
until
we
can
refactor
some
of
the
stuff,
and
I
can
kind
of
talk
a
little
bit.
Why
I
I
feel
strongly
about
that.
But
I
also
welcome
dissenting
opinions
during
this
call,
if,
like
I'm,
making
assumptions
as
a
product
manager
that
aren't
in
correct
from
an
engineering
standpoint,
call
me
out
please
so
just
throw
that
out.
There.
C
Yeah
I
mean
to
summarize
what
game
and
christmas
said
I
I
think
the
requirements
or
the
the
certified
roadmap
has
pretty
much
aligned
with
the
next
six
months
being
having
the
need
for
linking
between
things
and
the
the
best
way
to
get
there
is
to
develop.
You
know,
requirements
as
an
issue
type
and
and
then
work
on
some
of
these
details
as
we
move
forward,
so
I
think
we're
in
the
same
boat
for
certify
we're
really
looking
forward
to
being
able
to
have
a
common.
B
Sure
let
me
share
my
screen
real
quick,
so
I'm
going
to
make
smaller,
I
just
switched
over
to
using
safari
it's
a
girl,
so
I'm
still
going
to
use
it
so
like
I'd
kind
of
diagram
this
out.
Just
so,
I
can
talk
very
easily,
but
this
is
sort
of
like
a
product
manager
trying
to
approach
some
of
these
problems
that
we
have
like
a
business
owner.
Well,
I
would
call
them
opportunities,
not
problems,
so
we
call
it
a
club
director.
Just
planning
object
is
what
we
renamed
it.
B
B
There's
like
lots
of
different
underlying
technologies
that
we're
using
both
on
the
front
end
and
the
back
end
to
a
certain
degree,
different
apis,
some
stuff's
in
view
some
stuffs
in
hamel,
some
stuff's
in
the
apollo,
some
stuff's
using
rest
api,
some
stuff,
some
graphql
and
all
this
like
is
makes
changing
harder
and
it
makes
it
more
complex
and
it
also
makes
like
it's
a
it's
a
larger
mental
model
and
cognitive
load
that
we
us
sort
of
all
have
to
carry
as
we
work
on
improving
the
customer
experience
and
the
value
we
deliver
to
our
customers
in
the
wider
community.
B
I
think
when
it
comes
down
to
like
why
why
refactor,
and
why
now
there's
a
couple
different
things
improving
code
quality
is
like
really
important.
I
think
if
you
we
improve
code
quality
across
the
board
like
because
a
lot
of
stuff
and
plan
is
legacy.
It
has
been
around
it's
like
one
of
the
oldest
stages
in
the
product.
So
like
it's
not
surprising,
and
when
I,
when
I
talk
about
technical
debt,
it's
not
a
bad
thing.
It's
just
a
it's
a
trade-off.
B
It's
a
decision
that
we've
all
made
as
we've
kind
of
decided
to
shift
customer
value,
speed
over
kind
of
completeness
some
of
those
different
things,
and
it's
really
just.
I
think,
we've
accrued
a
lot
of
it
through
various
decisions
that
you
know.
I've
made
that
we've
all
made,
but
I
think
it's
really
important
to
improve
code
quality
when
we
do
that.
We're
also
increasing
global
productivity
across
the
board
for
for
future
changes,
which
also
decreases
the
time
to
value
for
customers.
B
It
also
reduces
defects.
I
think
we
have
an
opportunity
to
improve
performance
as
well
setting
this
the
proper
foundation
for
enabling
things
in
our
product
to
be
real
time,
especially
within
the
plan
stage
in
our
span
of
control.
There's
also
like
numerous
like,
I
could
probably
list
a
hundred
bugs
that
exist
because
of
small
things.
Like
real-time
race
conditions,
you
know
somebody
picking
a
label
and
then
it
not
showing
or
basically
applying
quickly
quick
action
and
not
seeing
that
it
shows
up
in
the
sidebar
and
then
really.
B
We
want
to
reduce
the
future
cost
of
change,
and
so,
like
all
this
stuff
kind
of
goes
down
to
in
the
long
run,
it
will
improve
sus
like
making
things
real
time
and
fixing
some
of
these
like
sort
of
transient
bugs
is
one
of
the
one
of
the
big
pain
points
that
we've
heard
from
our
user
base.
When
it
comes
to
system
usability,
every
one
point
in
system
usability
equals
more
or
less
five
percent
growth
in
arr.
B
There's
a
research
study
that
kind
of
backs
this
up
that
I
can
link
to
if
you're
interested,
but
it
also
we
want
to
reduce
future
spend
so
instead
of
us
spending
time,
and
our
kind
of
like
time
is
all
we
have
instead
of
spending
it
on
fixing
defects
and
these
other
things
which
we're
always
going
to
have
bugs
but
like
I
want
to
spend
improving
customer
value.
So
I
think
refactoring
is
really
important
to
get
everything
under
the
same.
A
single
tech
stack
as
quickly
as
possible.
B
Another
part,
a
kind
of
goal
for
the
vision
is
being
able
to
interact
with,
like
a
planning
object
for,
and
I
call
a
planning
object.
You
can
think
about
a
requirement
or
an
epic
right
now
or
an
issue
or
a
test
case
or
anything.
That's
in
plan.
That's
like
a
thing
that
you
comment
on
or
that
tracks
work
or
track.
Something
is
we
want
to
be
able
to
interact
with
it
from
anywhere
in
the
product
like
we,
everyone
has
label
fatigue
and
it's
real
or
I
mean
tab
fatigue
and
and
label
50..
B
But
basically
I
have
to
open
up
like
100
tabs
a
day
just
to
work
in
gitlab,
and
part
of
that
is
because
we
can't
we.
We
basically
can't
open
up
the
issue
view
on
the
board.
We
can't
open
it
up
within
the
to-do's
view.
We
can't
you
know,
look
at
it
from
different
places
and
you
always
have
to
open
up
the
tab
to
go.
Look
at
the
issue
and
then
remember
to
close
the
tab
and
then,
before
you
know
it,
you
have
a
ton.
So
really
we
want
to.
B
We
want
to
make
it
so
that
you
can
interact
with
the
planning
object
from
anywhere
in
the
product.
I
think
that
will
also
increase
global
productivity,
not
just
for
ourselves
but
for
everyone
in
the
company,
because
everyone
in
the
company
uses
planning
objects
to
manage
and
facilitate
their
work.
So
that
also
will,
if
we
increase
productivity,
it
will
decrease
time
value
for
customers
so
on
and
so
forth.
It's
like
a
big
system
and
then
kind
of
getting
into
this
single
like
playing
object,
hierarchy
and
types.
B
One
of
the
things
that
I've
seen
a
lot
of
is
duplication
and
it's
just
like
it's
natural,
as
we
npc
our
way
towards
things
we
sort
of
start.
We
realize
we
need
something
at
the
epic
level
that
already
exists
at
the
issue
level,
but
then
we
forget
to
do
certain
things
like
tying
into
the
activity
feed
or
showing
up
on
your
contribution
graph
for
like
little
tiny
things,
but
I
think
we
can
really
reduce
the
amount
of
duplication
which
also
reduces
the
total
lifetime
cost
of
the
proc
surface
area.
B
So
for
for
managing
less
surface
area,
basically
like
in
and
can
achieve
the
same
solution
with
a
single
object
hierarchy,
it
will
make
it
easier
to
maintain
over
the
total
lifetime
of
the
product.
I
think
it
will
also
improve
usability
quite
a
bit
because,
like
you'll,
have
to
switch
between
groups
and
projects
with
episode
issues
and
like
it's
all
over
the
place,
it
will
also
make
metrics
and
reporting
easier.
So,
for
example,
the
optimize
group
is
building
value
streaming
analytics
and
it
only
reports
on
issues
and
merge
requests.
Well.
B
What
if
we
wanted
to
report
on
epics
well
they're
going
to
have
to
do
a
bunch
of
work
now
to
tie
into
that
object
and
so
by
having
a
single
object.
It
also
makes
integrating
and
other
stages
in
our
product
a
little
a
lot
easier
and
then
really
getting
into
like
kind
of.
We
talked
about
extensible
issues,
but
like
once,
we
get
there.
B
It
sort
of
unlocks
the
the
power
of
building
automation
as
a
first-class
thing
in
the
product
workflows
and
we
talked
about
custom
fields,
but
I'm
thinking
more
like
custom
data
objects
and
the
reason
why
is
like,
if
you
look
at
sort
of
some
of
the
broader
markets
out
there
and
I'll
kind
of
hop
over
here.
Right,
quick
and
what
git
lab's
sort
of
big
hairy
audacious
goal
is
it's
to
become
the
most
popular
collaboration
tool
for
knowledge
workers
and
for
like
right
now
we're
starting
with
devops.
B
Right
and
there's
lots
of
examples
where
we're
using
our
knowledge
workers
at
our
company
are
using
a
ton
of
different
tools
to
manage
their
knowledge
work,
whether
that's,
google
docs
we're
rolling
out
a
new
tool
for
okr
tracking
or
using
gainsight
to
manage
customer
relationships.
Proserv
uses
a
different
tool
for
budgeting
and
managing
projects,
and
if
you
look
at
sort
of
the
jobs
to
be
done
across
all
these
different
kind
of
knowledge,
workers
there's
some
common
threads
but
really
like.
If
you
look
at
it
developers
worldwide
by
2023
is
27.7
million
knowledge.
B
Workers
by
2023
is
going
to
be
1.14
billion,
so
there's
41
knowledge
workers
for
everyone's
software
developer
and
then
looking
at
some
adjacent
markets
like
the
collaboration
software
markets,
the
31.5
billion
dollar
market
business
process,
automation
is
19.6
information,
technology
service,
management's,
12.1
and
then
outside
of
devops
like
project
and
portfolio
management,
it's
4.4
billion
so
like
how?
B
How
can
we
build
a
product
in
a
way
that
makes
it
easier
to
extend
into
these
like
adjacent
markets
down
the
road
and
that
really
kind
of
goes
down
to
building
the
right
foundation?
And
I
think
this
is
is
part
of
that
foundation.
So
this
is
gonna.
Definitely
in
the
future
drive
our
monthly
active
users,
it's
gonna
drive
ar
growth
and
then
that
will
enable
us
to
more
efficiently
realize
basically,
our
big
carry
audacious
gold
down
the
road
and
then
also
net
ar
and
profitability,
and
which
then
will
drive
shareholder
value.
B
A
Thanks
all
right,
I'm
going
to
talk
through
just
three
examples:
these
build
on
what
gabe
already
said.
They
aren't
different
from
it,
I'm
just
kind
of
giving
some
of
the
high
level
examples
that
I'm
really
excited
about
for
product
planning
and
this
initiative,
so
the
first
one
I've
linked
to
the
whimsical
there,
I'm
just
going
to
share
my
screen
would
be,
as
mentioned,
that
we
end
up
having
issues
and
different
types
of
objects,
rendering
on
our
main
views
so
like
here.
A
I've
got
these
purple
items
representing
issues,
but
we
could
see
potentially
requirements
or
any
other
customer
defined
issue
on
roadmaps.
The
same
goes
for
boards.
I
didn't
mock
anything
up,
but
you
could
see
a
world
where
we
could
have
any
type
of
object,
type,
rendering
on
boards
and
list
view
as
well.
A
The
second
one
is
and
I've
this
is.
I
define
kind
of
as
a
parenting
requirement
for
mvc
is
to
support
this.
These
structures
that
we
currently
have
live,
so
the
default
was
just
epics
with
issues
below
it
and
then
also
the
sub
epics.
For
those
who
are
in
ultimate
so
that
we
have
seven
levels
of
epics
and
then
an
issue.
So
you
really
need
to
think
through
parenting
structure
multi-tree,
but
also,
how
do
we
handle
multiple
layers
of
parenting,
but
what's
exciting
about?
This
is
once
if
we
can
set
these
up
as
templates.
A
Eventually,
we
could
expose
these
to
the
customers
and
we
and
the
customer
could
define
the
structure
that
they
want.
So
they
might
want
to
go
from
an
initiative
to
an
epic
to
a
story
to
a
task
object
and
have
all
of
these
relate
and
also
rendering
all
of
the
views
or
any
custom
template
that
they
wanted
to
create.
A
A
And
then
the
last
thing
that
I
wanted
to
just
mention,
and
I'm
going
to
use
an
example
from
notion
from
this.
But
I
think
we
have
the
opportunity
and
we've
been
looking
at
this
in
design,
but
to
be
able
to
look
at
how
we
look
at
an
object
within
so
like
this
is
if
this
was
an
example
issue
here
being
able
to
open
it
and
not
lose
context.
I'm
still
on
my
dashboard.
A
C
Awesome,
I
guess
I'm
the
only
one
who
didn't
do
a
pretty
picture,
so
we're
just
going
to
go
verbal
here.
You
know
from
day
one
from
requirements.
The
intention
was
always
to
be
able
to
link
multiple
levels
of
requirements
to
have
like
group
level
requirements
be
like
system
requirements.
Then
you'd
have
projects
underneath
that
be
like
your
software
requirements,
your
firmware
requirements,
your
hardware
requirements.
C
C
We
had
always
kind
of
at
least
I
I
hopefully
always
made
it
clear
that
that
was
the
intention,
so
we
were
going
to
try
to
figure
out
how
to
do
that,
using
issues
and
sort
of
like
the
related
issue
concept,
we
were
going
to
sort
of
port
it
over
to
the
requirements
object
and,
as
this
opportunity
came
up,
it
was
really
exciting,
because
now
you
know
if
we
go
down
this
road.
C
Alongside
of
these
issue
types,
this
collaborative
you
know,
object,
idea
and
convert
requirements.
Not
only
does
it
give
the
benefit
that
we
need
for
the
requirements,
but
it
also
makes
requirements
linkable
to
things
that
we
didn't
originally
plan
on
linking
them
to
like.
We
can
link
a
requirement
to
an
issue
or
an
epic
very
easily,
now
not
just
requirement
to
requirement
linking,
and
that
was
something
we
had
actually
pushed
on
the
roadmap
far
down
the
road,
because
we
knew
it
was
yet
another
difficult
integration,
and
this
actually
enables
a
lot
of
that.
C
C
I
really
see
the
vision
that
gabe
and
christian
both
presented,
and
I
really
appreciate
that
from
the
planning
side,
and
it
just
goes
to
further
what
we
can
do
and
certify.
So
it's
really
exciting
for
me.
So
sorry
for
the
lack
of
diagram,
but
yes,
very
much
on
board
very
much
aligns
with
our
roadmap,
and
I
think
this
is
an
awesome
opportunity
for.
D
All
right
so
I'll,
just
kind
of
quickly
touch
on
some
of
what
we
were
striving
to
accomplish
with
this
research
and
then
I'll
show
some
visuals
as
well.
But
I
don't
want
to
alarm
anyone,
because
we
were
looking
to
go
kind
of
big
initially
with
our
thinking.
So
there
are
a
lot
of
things
in
the
designs
that
I'll
show
here
in
a
moment
that
are
not
proposals
they're
just
things
we
were
kind
of
exploring.
D
D
How
might
we
statements
we
had
for
this
research,
included
understanding
more
easily
what's
changed
or
new,
since
the
user-less
interacted,
with
the
planning
object,
ways
that
we
could
capture
decisions
and
threaded
discussions
and
kind
of
setting
those
things
as
a
source
of
truth
and
then
reducing
context?
Switching
between
discussions
and
the
title,
as
well
as
between
planning
objects
themselves.
So
let
me
just
quickly
share
some
of
that
and
I
shared
the
link
in
the
agenda
too,
but
it
might
look
a
bit
messy
and
again,
that's
partly
because
it
was
just
exploratory
work.
D
Can
you
all
see
my
screen
and
I'll
zoom
in,
of
course
awesome?
Thank
you.
So
some
of
the
things
that
we
had
started
with
were,
as
gabe
had
mentioned,
we
were
looking
at
ways
to
provide
users
with
the
ability
to
access
an
issue
from
anywhere
in
the
product,
and
I
started
by
evaluating
all
of
the
different
places
that
you
can
access
an
issue
and
I
do
still
think
there's
opportunity
to
maybe
provide
some
adjustments
down
the
line
in
terms
of
what
you
see
in
an
issue
when
you
access
it
from
one
place
versus
another.
D
Just
because
there
are
certain
things
that
I
think
are
going
to
provide
more
value
than
than
not
in
certain
contexts.
But
I
started
with
the
to-do
list
as
just
kind
of
a
place
to
analyze
what
that
might
look
like,
and
let
me
just
well
yeah
I'll,
just
quickly
show
the
so.
The
work
that
we
were
exploring
for
this
is
maybe
having
the
issue
open
in
a
panel,
and
this
is
kind
of
a
simplified
view
of
the
issue.
D
D
But
again
the
thought
was
in
this
case
you
select,
maybe
one
of
your
to
do's
and
a
panel
comes
out
from
the
right,
and
perhaps
it
has
you
know
we
had
explored
this
sort
of
action
bar
feature
at
the
top
that
lets
you
access,
maybe
your
assignees
and
labels,
and
things
like
that
from
the
single
location,
as
well
as
see
the
title
and
description
and
threaded
comments.
D
But
some
of
this
again
was
more
exploratory
like
this
layout
for
the
actual
threaded
conversations,
we're
not
going
to
be
pursuing
that
necessarily
for
nbc,
but
that
could
be
something
that
we
could
look
into
in
the
future
as
ways
to
reduce
some
of
that
clutter.
We
were
also
looking
to
use
progressive
disclosure.
So
how
can
we
maybe
kind
of
hide
some
things
from
the
initial
view
until
the
user
needs
it
and
then
give
them
access
to
it
at
the
right
time?
And
that's
also
some
of
the
work
that
that
we
were
exploring
here.
D
So
you
can
see
a
lot
of
this
is
kind
of
messy,
but
when
you,
when
you
click
on
this,
it
kind
of
just
when
you
click
on,
maybe
the
emoji
here
at
the
top.
It
would
you
know,
pull
out
this
panel
that
shows
the
emojis
and
you
could
work
with
those
and
same
with
labels
so
again
exploratory
work
and
I'm
just
kind
of
quickly
going
through
it,
because
I
don't
want
anyone
to
think
that
this
is
proposal.
D
Another
approach
that
I
had
explored
was
maybe
going
with
this
sort
of
icon
set
up
at
the
top
and
when
you
click
on
that
it
pulls
up
the
activity
feed
and
you
can
kind
of
see
everything.
That's
happened
with
that
particular
issue,
and
some
of
the
exploration
surrounding
that
was
maybe
having
the
most
recent
things
highlighted,
so
you
can
kind
of
quickly
gauge.
You
know
what
has
has
changed
recently
versus
what
was
maybe
a
bit
older.
D
Let
me
see
if
there's
anything
else
worth
quickly
touching
on.
I
still
need
to
do
some
exploration
surrounding
the
mobile,
but
then
also
had
looked
at
maybe
some
ways
to
further
show
or
better
surface
the
relationships
with
dependencies
and
child
elements.
So
kristen
had
talked
about
kind
of
that
child
aspect
that
we're
looking
to
introduce
into
this,
and
that's
something
that
I
think
is
still
being
explored.
So
not
a
lot
of
that
particular
type
of
aspect
here,
but
just
to
kind
of
show,
maybe
some
of
the
initial
high
level
designs.
D
So
just
to
quickly
summarize,
we
are
exploring
the
modal
versus
side,
sidebar
view
for
use
of
usertesting.com
and
hoping
to
get
some
feedback
as
to
which
approach
is
going
to
be
better
there.
D
We
are
still
kind
of
evaluating
some
ways
that
we
can
take
the
existing
issue
layout
and
reduce
some
of
that
visual
clutter
through
using
progressive
disclosure.
We
also
wanted
to
reduce
the
scrolling
required,
so
this
view
here
is
kind
of
showing
maybe
the
larger
issue
view
when
you
select
from
a
side
panel
or
from
a
modal
to
go
to
maybe
the
full
issue
view
we'll
still
have
that
view.
But
how
can
we
reduce
the
back
and
forth
required
between
reviewing
the
conversation
and
then
having
to
go
back
up
and
see
the
description?
D
We
have
the
sticky
title.
Obviously
so
that
stays
with
you.
But
how
can
we
further
simplify
this
experience
by
having
maybe
title
and
description
on
one
side
and
then
the
comments
and
conversation
on
the
right
side?
D
Something
else
I
really
love
the
thought
of
is
maybe
providing
kind
of
a
center
bar
here
that
you
can
kind
of
drag
left
and
right
so
that
you
can
either
reduce
or
expand
the
particular
part
of
the
page
that
you
want
to
have
more
focus
on
and
yeah.
So
that's
essentially,
I
think
everything
that
I
wanted
to
touch
on
today
is
there
anything
visually
that
I'm
missing,
gabe
or
kristen,
that
that
might
be
valuable
to
quickly
run
over.
B
No
not
right
now,
but
I
also
I
was
just
going
to
add
the
clarifying
point
that
when
we
say
like
node
net
new
features,
it
doesn't
mean
that
we
can't
make
significant
changes
to
the
ui
ux.
So
like
right,
we
can
make
the
issue
or
the
planning
object
view
whatever
we
need
to
do
for
the
optimum
user
experience.
I
think
when
we
say
like
no
net
new
features,
we're
saying
we're
not
going
to
go
like
keep
building
iterations.
B
You
know
in
the
middle
of
this
or
go
build
a
new
widget.
That
is
some
new
data
point
to
the
add
to
the
the
object
model.
So
I
I
do
think
we
should
continue
to
keep
an
open
mind
about
how
to
improve
the
user
experience,
especially
if
we're
going
to
be
refactoring
things
in
the
front
end.
It's
a
great
opportunity
to
do
that.
So
just
wanted
to
like
that
distinction,
clear.
D
Yeah,
thank
you
for
clarifying
that.
We
had
also
explored
inline,
editing
too,
so
you
know
being
able
to
click
on
the
title
and
just
edit
it
in
place
and
click
on
the
description
and
edit
it
in
place,
without
necessarily
having
to
go
into
kind
of
this
bigger
wysiwyg
view,
but
I
think
there's
separate
discussion
going
on
now
with
a
different
group
regarding
best
ways
to
edit
that
kind
of
thing.
So
again,
that's
that's
kind
of
the
type
of
thing
that
I
meant
by
new
features.
D
F
Yeah
sorry,
it
was
me
I
was
writing
writing
in
the
dark
anyway,
but
yeah.
First
of
all,
these
are
they
look
really
really
fresh
and
really
cool,
and
I
really
like
that
they
give
exactly
the
information
I
would
want
in
in
that
modal
or
sidebar,
like
the
information
that
kind
of
is
just
enough
right
like
so.
If
I
see
the
avatar
of
people,
I
work
with,
you
know
regularly
as
the
assignees
that's
enough
for
me
to
know
who's
assigned.
F
I
don't
necessarily
need
to
go
in
and
see
a
tooltip,
but
if
I
need
more
information,
I'll
go
in
and
so
on.
So
I
just
think
it's
first
of
all
like
these
are
like
look
like
fantastic
proposals
to
me
as
just
a
back-end
person
like,
but
what
I
know,
but
I
was
wondering
like
I
noticed.
The
designs
are
called
things
like
call
objects,
so
they're,
obviously
intended
you
know
for
every
you
know
to
be
as
permissive
as
possible
in
terms
of
like
it
could
be
an
epic
or
an
issue
or
whatever.
F
So
how
do
we
distinguish
them
like
to
look
at
this?
I
can
tell
by
the
fact
that
you
know
the
issue
icon
in
the
sidebar
is
highlighted
that
this
is
an
issue,
but
at
first
glance
and
I'm
thinking
about
other
software
products
like
I
would
know
immediately
whether
it
was
an
issue,
an
epic
or
some
custom
issue,
type
that
I've
created.
D
Types
of
course
is
still
kind
of
separate
work,
that's
going
on
in
terms
of
being
able
to
identify
something
as
a
bug
or
as
a
feature
or
something
else,
but
I
think
that
just
simply
having
an
icon
and
then
potentially
so,
let's
look
at
the
actual
the
initial
issue,
types
that
we're
going
out
the
door
with
would
be
still
issue,
epic
and
incident,
and
so
in
that
case
I
would
expect
that
we
would
still
have
kind
of
a
similar
experience
to
what
we
have.
D
I
mean
you
would
still
have
the
and
actually
that's
a
great
question
as
far
as
breadcrumbs,
because
I
think
that
one
of
the
ways
that
people
differentiate
between
those
is
breadcrumbs
and
that
you
can
see
the
id
of
the
element
at
the
top.
So
that's
a
great
question,
john.
I
know
again,
we've
talked
about
icons,
but
I
think
there
are
better
ways
to
surface
it
beyond
just
using
an
icon.
D
You
know
the
id
with
something
that's
relative
to
either
an
issue
or
an
epic
or
something
like
that
using
initials,
which
I
think
some
of
our
competitors
do.
But
that
would
be
a
larger
change,
so
I
would
say
to
start
simply
probably
iconography
and
then
maybe
a
label
associated
with
that.
Potentially
and
when
I
say
label,
I
don't
mean
labels
in
terms
of
our
lab
labels,
but
some
sort
of
text
associated
with
it.
F
Yeah,
I
was
just
going
to
say
that,
like
we
can
get
to
it
later,
but
we're
going
to
have
to
solve
the
id
problem
anyway,
and
we
already
use,
as
we
mentioned
yesterday,
like
req,
for
a
requirement
if
I
saw
an
icon,
a
color
and
an
id
that
was
prefaced
with
that,
you
know
three-letter
abbreviation.
I
think
that
would
be
more
than
enough.
B
I
also
want
to
clarify
too
we
might
like
we
for
multi-level
epics
we're
going
to
have
to
have
some
sort
of
like,
even
if
it's
hardcoded
for
initial
launch
a
work
item,
hierarchy,
template
that
has
different
names
for
the
different
levels.
Probably
right,
I
think
unless
we
want
to
call
everything
sub-epic
so
we'll
have
to
solve
for
that
like
immediately
so,
however,
we
want
to
do
that
from
ux
standpoint.
I
don't
have
strong
opinions,
but.
A
I
think
we're
a
little
over
on
the
pm
design
side.
I
want
to
just
be
cognizant
of
time
as
well
that
we
get
into
the
engineering
questions
and
we
will
wrap
this
up
at
the
20
25
past
the
hour.
E
Yeah,
I
mean
it's
kind
of
engineering
kind
of
depends
on
the
answer
to
that
anyway.
But
so,
as
far
as
your
designs
is
the
idea
that
and
yeah
also
designs
look
great,
but
is
the
idea
that
the
design
is
kind
of
the
base
planning
object
there.
So
every
other
planning
object
that
inherits
or
extends
off
of
the
base
planning
object
is
going
to
have
what
are
in
your
designs
now
and
to
further
that
question.
D
D
But
I
would
say
the
core
pieces
are
title
description
and
probably
the
discussion
aspect.
B
I'd
go
step
further
and
say
just
a
title
because
in
the
future
you
could
use
it
for
like
a
wiki
page
or
like
anything,
and
it
might
have
a
description.
It
might
not.
But
I
think
it's
a
title
like
that's
a
title
and
a
type
basically
read
like
the
two
things
I
would
think,
but
that's
just.
A
E
Okay,
so
just
just
to
clarify,
then,
because
I
think
there
has
still
been
some
discussion
around
things
extending
off
of
an
issue
and
an
issue
being
the
core
type.
In
reality,
a
planning
object
is
going
to
be
the
base
type,
and
then
an
issue
is
going
to
extend
off
of
that
base
planning
object.
B
Yes,
but
I
think
the
issue
will
eventually
not
be
called
like.
There
won't
just
be
an
issue
so
when
we're
doing
issue
types
right
now,
we're
launching
with
the
default
type
of
issue
called
issue
right,
but
we're
also
having
features
and
other
things
like
that
and
over
time.
I
think
the
whatever
we
call
it
in
the
back
end
like
we
can
use
the
issue
data
model
if
we
want
or,
however
we
want
to
do
it,
but
but
everything
will
extend
off
of
one
common
object
model,
whatever
whatever
engineering.
B
However,
engineering
wants
to
approach
it
and
it
doesn't
matter
if
it's
called
an
issue
like
any
api,
but
in
the
ui
it
could
be
called
lots
of
other
things
right
and
I
think
that's
how
a
lot
of
these
other
products
handle.
It
is
like
you
have
a
base
data
type,
but
then
how
it's
presented
to
the
end
user
and
the
user
interface
is,
is
sort
of
like
varied.
If
that
makes
sense,.
G
Currently
the
escape
set,
we
extend
issue
issue
model,
but
this
is
far
from
the
basic
id
and
title
it
contains.
But
bunch
of
attributes
do
we
plan
to
take
this
out
of
the
issue
table
into
some
extensible
digits
in
future,
or
do
we
plan
to
keep
this
on
issue
table
model
and
just
keep
hiding
these
attributes
for
selective
issue
types
as
we
do,
for
example,
for
test
cases.
B
I
think
one
of
the
things
that's
interesting,
especially
if
you
I'll
try
to
find
it
the
way
that
notion
does
your
data
model.
Is
they
let
you
transform
like
their
widgets
into
lots
of
different
types
of
things,
but
they
don't
mutate
the
data.
So,
if,
like
you
need
a
certain
piece
of
data
that
like
for
a
requirement
that
doesn't
exist
on
another
type
of
issue,
and
you
want
you
want
to
convert
the
requirement
to
another
type
of
issue,
you
leave
the
data
there.
B
So
that
way,
if
you
want
to
go
back
to
it
being
a
requirement,
you
still
have
the
data
that
you
originally
put
in.
So
I
think
it's
like
we
don't
it's
sort
of
like
having
one
object
and
then
all
the
attributes
are
possible,
but
then
letting
the
user
decide
which
attributes
they
want
to
use
on
specific
types
of
issues
and
letting
it
be
configurable.
But
that
way
when
you
switch
between
one
or
the
other,
you
don't
like
we're
not
like
deleting
a
bunch
of
stuff
like
whether
we
store
in
one
table
or
not.
B
I
don't
that's
an
implementation
decision,
but
I
also
think
that
we
want
to
make
it
so
that
you
can
switch
between
types
easily
without
like
losing
a
ton
of
information
that
helps.
A
I'll
just
add
to
it
for
in
terms
of
scoping
this,
like
for
this
mvc,
consider
what
we
need
to
do
to
get
epics
onto
the
new
planning
object
and
what,
in
terms
of
what
you're,
hiding
and
showing
to
the
end
user,
it
should
feel
kind
of
the
same
using
an
epic
when
we
go
live
for
this,
but
under
the
hood.
Yes,
every
field
should
be
available,
whether
we
expose
them
or
not.
E
So
yeah
I
mean,
I
think
we
should
still
keep
talking
the
actual
implementation
of
that,
though,
because
that
kind
of
is
my
first
question
there
like.
Are
we
going
to
keep
the
issue
or
issue
a
bulls
table,
or
are
we
planning
on
having
a
completely
new
table
and
then
eventually
migrating
current
issues?
Over
to
this
new
data.
E
G
F
And
even
moving
things
off
that
table
into
separate
objects
or
separate
tables
would
even
cause
more
more
work
right
like
if
we,
because
we
filter
by
those
things.
So
if
we
say
that
we're
going
to
move
everything
off
and
just
have
a
table
with
associated
other
tables
like
we
have
to
rewrite
all
our
queries,
it
just
seems
to
make
more
sense
to
retain
the
existing
issues
table
since
it's
the
largest
anyway.
E
Okay,
just
does
that
affect
the
migration
plan
at
all
or
like
the
rollout
of
this,
and
do
we
have
to
consider
that
at
all.
F
E
Yeah
kind
of
so
like
if
we
continue
using
issuables
like
we
can't
give
users
the
option
of
like
slowly
upgrading
to
this
new
issuables
or
this
new
planning
object
format.
It's
either
all
or
nothing
right,
like
everyone
needs
to
be
upgraded
at
the
same
time
essentially
does
that
matter.
F
From
their
perspective
in
the
first
iteration,
no
because
I
mean,
if
it
shouldn't
there
should
be
no
change
for
them
in
experience
really
like
between
having
epics
as
its
own
thing
and
having
epics
as
part
of
the
issues
table
in
the
first
iteration
anyway.
F
Strongly
suspect
that
once
we
start
the
work
and
we
realize
we
get
some
stuff
for
free
that
it
will
be
hard
to
say
no.
So
if
you
can
have
a
signees
on
epics
and
that's
something
we've
wanted
for
a
long
time
and
it
is
actually
more
work
to
restrict
that
than
to
simply
support
it
in
future.
Then
it
to
me
it
would
make
more
sense
to
to
just
do
that.
F
B
Too
risky
it,
if
it's,
I
don't
know
how
to
approach
it,
but
I
think
the
migration
is
one
aspect
of
it,
but
then
I
think
it's
also
building
things
in
a
way
that
we
realize
that
they're
in
a
future
state
or
scenario.
We
will
allow
the
users
to
pick
and
choose
which
fields
they
want
on
which
types
of
issues.
B
If
that
makes
sense-
and
I
can
show
an
example
if
that's
helpful-
but
it's
sort
of
like
we'll
ship
with
defaults,
of
course,
for
everything,
but
you
may
or
may
not
see
the
assignee
on
a
type
of
issue,
it's
sort
of
like
an
an
extension
that
you
can
add
to
the
to
the
to
the
experience.
So
it's
part
of
the
core
data
model,
but
it
may
or
may
not
be
used
by
the
end
user.
B
If
that
makes
sense-
and
I
think
that's
sort
of
like
the
goal
with
each
of
these
types
of
things
like
letting
the
user
decide
hey,
are
we
going
to
use
estimation
or
not?
If
not,
we
might
not
show
the
weight
field
right
or
things
like
that,
but
it's
still
part
of
the
core
data
model.
It's
just.
G
Okay,
migration
of
requirements.
We
just
we
just
map
because
requirements
attributes
are
subset
of
issues.
Basically,
we
just
map
them
to
issues
attributes
and
we
just
hide
any
additional
attributes
which
are
not
visible
for
requirements,
and
this
is
not
cast.
Custom
is
able
by
users
it's
just
in
the
code
yeah.
We
don't
consider
this
option
for
the
first
iteration
that
users
would
customize
attributes
on
issue
types
specifically
on
requirements.
B
Maybe
but
there's
also
a
place
where
we
will
show
up
with
defaults
like
maybe
instead
of
like
hard
coding
that
has
to
have
this
thing,
there's
certain
things
that
a
requirement
might
have
to
have
like
you
know,
test
reports
or
whatever.
But
there
are
certain
things
like
incidence
is
a
good
example
where
there's
some
like
they.
B
They
hit
a
bunch
of
fields
like
iterations
and
milestones
on
the
incident
view
and
then,
like
a
bunch
of
customers
like
hey,
we
want
to
be
able
to
assign
incidents
iterations
to
milestones
and
there's
other
customers
that
don't
right
so
it's
sort
of
like
there
might
be
core
things
that
we
are
like
system
defaults,
but
there's
also
giving
the
power
to
the
end
user
to
use
the
certain
fields
that
they
may
or
may
not
want
or
hide
the
things
that
they
don't
want.
So
it's
not
as
noisy.
B
So
it's
the
same
sort
of
thing
where,
for
the
nbc,
we
don't
have
to
expose
the
ability
for
the
end
user
to
do
that,
but
from
an
architecture
and
like
how
we
build
it.
Keeping
that,
in
the
back
your
mind,
would
be
helpful
so
that
when
we
do
get
to
wanting
to
do
that,
like
you
know
a
year
from
now
or
however
long,
we
don't
have
to
go
back
and
like
rejigger
a
whole
bunch
of
stuff,
so
hiding
it
from
the
user,
but
working
towards
that
is
the
end
goal.
B
F
Basically,
like
we,
we
have
a
commitment
not
to
not
to
break
make
breaking
changes
to
the
rest.
Api,
for
example,.
F
G
G
G
Downside
is
that,
then
we
don't
have
migration
under
our
own
control
and
it
will
be
longer
longer
action
to
do
it
and
just
a
small
reminder
fall
epics.
Migration
is
blocked
by
by
converting
or
consolidating
project
and
groups,
but
I'm
sure
everyone
is
aware
of
this,
so
I
will
not
dive
again
into
this
problem.
B
Along
those
lines,
michelle
gill
is,
is
the
engineering
dri
for
moving
that
forward,
and
I
think
the
access
group
was
going
to
work
on
stuff.
But
if,
if
that
is
a
dependency
of
moving
forward
with
this,
then
I
think
it's.
It
would
be
great
for
our
ems
and
engineers
to
talk
to
her
and
be
like
hey.
We
we
need
to
work
on
this
at
least
getting
issues
you
know
at
the
group
level.
How
can
we
contribute
to
the
consolidation
works
so
that
we
can
achieve
that
so
that
we
can
unblock
ourselves
here
as
well?
B
B
A
A
Up
to
it,
jan
said
quickly:
could
we
phase
it?
This
was
out
of
order
now.
Could
we
start
with
a
button
and
then
move
over
like
bring
everyone
over
at
a
certain
point?.
G
I
I
don't
see
a
big
problem
in
either
way.
Supposing
we
choose
the
way
I
described,
I
think
both
options
are
possible.
I
think
much
bigger
problem
is
the
project
group,
consolidation
or
the
alternative
part
to
support
issues
on
groups
level.
So
I
I
think
that
it
will
take
at
least
the
half
of
the
year
to
get
to
the
phase.
We
are
able
to
migrate,
epics
or
start
migrating
this
epic,
so
just
to
get
better
idea
about
time
schedule.
F
I
had
some
concerns
about,
like
the
benefit
of
having
that
button
like
for
the
extra
work
that
it
would
require,
given
that,
like
the
user
already
has
to
take
like
an
instance,
administrator
already
has
to
take
an
action
to
upgrade
to
the
latest
version
of
gitlab
what
benefit
adding,
also
a
button
to
decide
when
they
want
to
migrate
this
by
specific
part
of
gitlab.
What
benefited
ads,
but
I'm
open
to
suggestion
on
that.
Like
we're,
nearly
I
think
we're
out
of
time
what
I'm
going
to
do
with
the
back
end.
F
F
As
mark
pointed
out
yesterday,
we
don't
actually
have
a
a
a
requirement
page,
so
we
won't
run
into
the
problem
with
iid
collisions
because
we,
you
know
in
urls,
so
so
we
won't
solve
everything
like,
but
I
think
like,
rather
than
lose
the
information
I'll
put
them
in
an
issue
and
we
can
kind
of,
as
we
figure
things
out
for
requirements,
we
can
sort
of
answer
some
of
those
questions.
B
One
thing
to
solve
the
id
problem
we
didn't
get
to
it's
further
below,
but
there's
an
open
issue
for
properly
handle
moving
issues,
because,
right
now
we
just
close
an
issue
and
and
create
a
new
one.
Basically,
but
if
we
properly
handle
it
and
handle
the
redirects,
I
think
that
same
solution
could
work
here
for
redirecting
from
an
epic,
an
old
epic
url
to
a
new
issue
type
I
id
that
makes
it
so
I'll
link
it
down
there
somewhere
towards
the
bottom.
B
F
F
So
somebody
can
correct
me
on
that.
Like,
but
again
you
know
it's
it's
two
different
id
spaces
or
pools
of
ids,
if
you
like,
so
there's
a
possibility
of
collision
and
then
the
question
arises
like
what
do
we
do
about
this
like,
and
so
I
think,
like
thinking
higher
level
about
ids,
specifically
and
giving
them
like
a
global
context.
G
A
Okay,
it
looks
like
we're
at
time,
so
we'll
transport
what's
left
into
issues
and
or
next
week's
meeting
agenda
thanks
everyone
for
your
participation,
it's
really
exciting
to
kick
this
work
off
and
to
see
what
we'll
accomplish
over
the
next
six
months.
This
is
a
big
thing,
so
I
hope
everyone
is
on
board
and
excited
for
what
this
could
mean
for
a
plan
at
gitlab
thanks.
Everyone
thank.