►
From YouTube: Plan Stage Weekly - 2021-06-23
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Cool
welcome
everyone
planned
stage
weekly
june
23rd
gabe.
You
have
the
first
point.
B
Just
wanted
to
make
another
plug
and
a
reminder
to
hopefully
continue
to
foster
alignment
around
this
epic
that
we're
working
on
starting
in
14.1
kristen,
put
together
a
mvc
plan
for
us
and
the
the
basic
tldr
is
we
want
to
create
a
new
kind
of,
I
guess:
planning
objects
of
all
planning
objects
that
we
can
eventually
migrate,
epics
to
and
also
part
of
that
work
is
creating
a
new
issue
view
or
planning
objects
view
it's
an
issue
behind
the
scenes,
we're
just
calling
a
planning
object,
so
everyone
understands
we're
trying
to
consolidate.
B
You
know,
requirements
and
test
cases
and
issues
and
types
of
issues
and
epics
into
like
kind
of
one
one
core
object.
So
I
just
wanted
to
resurface
that
and
ask
if
there's
any
feedback
concerns
questions
and
maybe
get
some
input
from
engineering
on
thinking
about
breaking
down
kind
of
the
big
nbc's
even
further
into
smaller
things
or,
if
there's
a
better
way
to
tackle
it
yeah.
C
C
And
there
is
there
is
this
idea
where
we
will
eventually
like
this
is
further
down
the
implementation
path?
I
guess
so
it's
not
the
mvc,
but
we
wanted
to
clarify
this
nonetheless,
so
we
have
here
this
idea
that
subgroups
can
inherit
some
of
the
defined
issue
types
at
a
higher
level
right
now.
The
question
that
popped
up
is:
does
subgroup
now?
C
Is
subgroup
able
to
modify
the
properties
of
these
two
issue
types
or
they
just
inherit
them
as
they
are,
and
they
can
add
a
different
issue
type
that
they
can
now
define
as
they
wish.
So
I
guess
the
question
is:
are
these
issue
types
at
the
subgroup
level
exactly
the
same
as
the
ones
at
the
group
level?.
B
Yes
right-
and
I
think
just
to
reiterate
this
is
much
much
further
down
the
path
right
and
I
think,
out
of
the
gate
we
just
want
to
go
to
where
we're
gonna
ship
with
default
issue
types
and
all
groups
and
projects.
There
are
all
groups
and
they
would
be
the
same
and
of
course,
all
projects
would
also
get
those.
B
But
the
way
that
I
was
thinking
about
it
eventually
is
the
manage
access
team
has
worked
on
a
cascading
settings
framework
that
sort
of
behaves
in
that
same
way.
That
lets
you
set
things
at
a
parent
group
level
and
then
optionally
choose
to
lock
it
so
that
children
can't
change
the
properties
of
things
or
or
even
like,
add
additional
settings
or,
like
add
additional
issue
types.
So
I
think
the
way
that
I
was
thinking
about
it
is
if
something
is
created
and
apparent.
The
parent
is
the
one
who
controls
the
properties
of
it.
B
If
it's
locked,
then
the
children
can
even
like
add
additional
like
issue
types,
if
that
makes
sense,
there's
a
lot
to
figure
out
and
why
I
say
this
should
be
way
down.
The
road
is
just
in
terms
of
the
problem
that
we
have
right
now
with
labels
when
labels
are
in
children
and
they're
they're
not
owned
by
the
parent
group,
then
like
there's
some
weird
behavior
in
terms
of
like
what
the
parent
group
can
filter
on
and
what
they
can
create.
B
Boards
on,
and
things
like
that,
so
I
just
was,
keep
it
as
simple
as
possible
out
of
the
gate,
if
if
that
makes
sense,
but
I.
C
Was
thinking
about
it
so
yeah
I
mean
again,
this
is
down
the
road,
but
I
what
is
your
vision
like
at
the
parent
level
group?
C
B
I
think
that
the
parent,
since
the
parent,
if
we're
thinking
about
an
inheritance
model
or
access
model,
the
parent,
should
have
access
to
everything
in
the
children
all
like
children
and
be
able
to
view
things
and
so
the
way
that
I
would
think
about
issue
types
on
boards.
You
could
maybe
have
a
list,
but
I
personally,
if
I
were
using
it
today,
would
use
a
swimlane
based
on
type.
So
I
could
like
segment
it
out.
So
if
there's
an
incident,
I
can
have
a
swimlane
in
the
top
for
my
incidents.
B
I
can
have
like
a
for
features
for
different
things
like
that.
That's
one
way
that
I
know
customers
will
use
it
and
I
might
as
well,
and
so
if,
if
like,
there
isn't
an
issue
type
of
tech
debt
in
the
subgroup,
that's
going
to
already
be
rolling
up
into
the
parent
groups.
Issue
list
right,
so
we
would
need
to
be
able
to
like
do
everything
that
you
can
do
with
it
within
the
sub
group
and
the
parent.
D
And,
and
what
I
heard
I
also
heard
you
say
before,
was
that
bug
and
feature
at
the
subgroup
level
are
not
are
not
immutable,
meaning
that
the
group
parent
could
say.
Oh
yeah,
any
subgroup,
you
can
change
what
bug
is
or
features
or
they're,
or
they
always
locked.
B
The
they're
always
locked,
I
don't
think
you
would
let
the
subgroup
change
properties
on
them.
What
locking
wouldn't
do
is
letting
you
preventing
you
from
adding
additional
issue
types
right,
so
you
can
only
you
can
only
like
would
only
be
able
to
ever
change
properties
on
a
type
of
issue.
B
If
you
have
access
to
the
group
that
owns
that
type
of
issue,
and
I
could
also
see
a
world
where
and
we
came
for
everybody
yeah,
I
could
also
see
a
world
where
lock
would
allow
somebody
to
disable
an
issue
type
like
if
they
don't
want
to
use
it
right,
because
that's
one
of
the
downsides
from
jira
that
I've
heard
from
customers
is
that
when
you
have
these
sort
of
like
settings
that
get
inherited
and
a
group
doesn't
use
certain
amounts
of
them,
they
can't
turn
them
off.
B
Then
it's
just
like
noise,
but
I
think
staying
true
that
only
if
you
have
access
to
the
group
that
created
or
owns
the
type
of
issue
would
you
be
able
to
change
anything
about
it
and
it
would
and
it
would
propagate
across.
B
Cool:
that's
is
that
as
simple
as
it
could
be,
or
can
we
make
it
simpler.
C
B
I
mean,
I
think,
that
the
first
try
to
work
is
getting
the
default
issue,
types
kind
of
like
what
we
talked
about,
reserving
features
so
that
we
can
do
all
the
work
on
it
and
then
working
on
parenting
and
the
new
kind
of
issue
view
together.
So
that
way,
I
think
that
gets
us
closer
to
what
kristen
put
together
for
her
nbc.
And
then
we
can
like
look
at
each
each
sort
of
field
on
an
issue,
because
some
of
them
are
the
behavior
will
change,
because
we're
adding
parenting
to
issues.
D
No
you're
right
you're
right.
We
just
don't
want
to
try
not
to
box
ourselves
into
a
corner.
E
E
E
Have
we
looked
at
the
like
the
structure
under
the
hood
for
how
we'll
filter
out
certain
types
of
issue
types,
such
as
requirements
and
test
case
cases
which
are
planning
objects
and
are
used
in
menus
and
in
other
places
those
are
currently
moving
onto
planning
objects
as
well
so
like?
Have
we
thought
about
how
we
will
have
multiple
hierarchies?
Has
that
entered
the
engineering
discussion
yet.
D
The
way
I
understand
it
is
that
an
issue
is
really
a
planning
object
and
we
are
going
to
be
adding
abilities
to
an
issue
when
that's
the
hierarchy
and
stuff
like
that.
So
anything
that
becomes
an
issue
or
we
can
rename
the
planning
object.
That's
fine,
but
it's
really
under
the
covers
the
same.
The
same
beast,
we'll
inherit,
whatever
abilities
we
get
with
the
ability
to
turn,
you
know
things
off
for
certain
ones.
D
So
that
means
that
we
can
we'll
be
able
to
filter
out
at
our
at
our
get
lab,
defined,
specific
types,
incident,
test
cases,
basic
issue
and
then
a
requirement,
and
then
custom
issues
fall
under
the
subcategory
of
an
issue
which
which
feature
epics
etc
would
be
part
of.
E
E
D
Well,
those
are
at
the
moment,
those
are
those.
Are
the
hard-coded
get
lab
issue
types?
In
other
words,
the
custom
issue
types
are
what
customers
can
define
and
it's
a
different
structure,
because
we
need
to
provide
the
custom
ability
of
it
customization
of
it
change,
particularly
changing
the
name
and
the
description,
and
all
that
kind
of
stuff
you're
not
going
to
be
able
to
do
it.
Do
that
with
the
description
I
mean,
I'm
sorry
with
the
requirement
or
something
like
that.
D
C
Okay,
like
I
have
another
question
in
terms
of
these
hierarchies,
and
we
call
all
of
them
planning
objects,
but
to
me
like
requirements
or
a
certified
part
of
this
planning
object
will
have
its
own
hierarchy.
Then
the
project
management
will
have
kind
of
its
own
hierarchy
now,
as
a
user,
when
I'm
selecting
the
issue
type,
do
I
just
see
every
single
type
of
the
issue
or
like
do?
We
need
to
cut
in
some
way
containerize
these
parts
of
the
application?
C
So
if
I'm
in
a
part
of
the
application,
where
I
manage
my
requirements
and
certifications
and
all
that
stuff,
I
only
see
this
batch
of
of
issue
types
and
then,
when
I'm
doing
project
management,
I'm
only
seeing
this
other
batch
of
issue
types
with
all
of
its
hierarchies
and
so
on.
Do
we
need
to
have
some
sort
of
a
ui
ux
separation
between
these
concepts
as
well
or
how
do
we
handle
that.
E
Yeah
and
that
will
be
in
the
second
nbc-
the
hierarchy
will
start
to
be
discussed
a
bit
more,
but
I
think
this
is
why
we
need
to
talk
about
it
now
to
do
there
will,
I
think,
be
multiple
templates
for
these
hierarchies
and
although
they
will
behave
the
same
way
in
a
certain
part
of
the
system,
we
may
only
be
in
planning
like
in
epics
and
we're
showing
the
planning
object,
hierarchy
and
how
those
objects
align
together
and
then,
with
like
test
cases,
incidents
and
requirements,
that's
a
different
flow
and
so
creating
multiple
templates
of
these
parent-child
relationships
will
be
necessary.
E
D
E
C
C
That
will
also
be
helpful
in
like
to
me,
especially
when
you
start
adding
custom
types
when
you
go
to
a
filter
bar
and
you
want
to
filter
by
a
specific
like
specific
issue
type,
it
will
be
useful
to
know
that
this
issue
type
is
within
certified
group
or
is
within
project
management
group
right,
because
then,
when
you
have
all
these
different
names
for
the
issue,
types
that
are
not
may
not
exactly
suggest
what.
Specifically
these
are
describing
right.
If
you
have,
I
don't
know,
issue
type
x,
it's
not
very
talking
to
you
like.
C
D
But
go
ahead,
I
understand
the
hierarchy.
There's
there's
two
hierarchies
that
I'm
seeing
one
is
the
hierarchy
that
alexander
is
talking
about
in
terms
of
issue
types.
In
other
words,
there
is
a
defined
structure
of
what
issue
type
can
inherit
from
which
issue
type
that's
seems
to
be
a
little
different
than.
B
Yeah,
I
would
just
say
I
think
we
can
get
a
lot
of
mileage
out
of
not
making
the
hierarchies
like
overly
configurable
out
of
the
gate
like
we
can
launch
multi-level
requirements
without
changing
much
in
the
ui.
We
could
have
like
surface
group
them
within
the
picker,
so
people
know
what
they
are,
but
I
I
guess
I
want
to
try
to
defer
any
any
sort
of
configurability
for
as
long
as
humanly
possible.
B
Right
and
you
are
correct,
like
they
are
two
separate
things-
there's
even
a
third
with
test
sessions
which
are
gonna,
have
test
cases
below
them
right
so
like
there.
There
are
going
to
be
different
ones
and
we
want
them
to
be.
Allow
like
work
with
the
issue,
types
to
be
interlinked
between
them
or
related.
So
I
think
that's
something
to
think
about,
but
just
guidance
that,
while
long
long
term,
we
may
want
to
make
some
things
configurable.
B
We
want
to
also
to
follow
our
park
principles
and
avoid
that
as
long
as
possible,
right
and
see
if,
like
we
ship
some
of
these
things,
if
it
resolves
some
of
the
customer
needs
right,
because
I
think
we
can,
especially
when
we
have
issue
types
in
a
hierarchy,
and
we
have
statuses
that
can
be
kind
of
customized.
There's
going
to
be
so
much.
That
opens
the
door
in
terms
of
like
what
that
will
provide
without
going
overboard
and
turning
into
jira.
B
E
So
all
the
heavy
lift
will
be
on
a
set
template
hierarchy
and
the
get
lab
default
objects
that
we're
starting
with,
but
I
want
to
make
sure
also
that
yeah
it
can
work
for
that,
and
I
need
to
fully
understand.
I
keep
saying
planning
objects
to
me.
That
is
the
configurable
issue
type
under
the
hood.
That
will
work
for
all
of
these
objects
and
be
consistent.
E
If
there
is
a
the
first
class
idea,
I'm
going
to
try
to
understand
that
more
understand.
Why
sometimes
we're
saying
issue
and
issue
type
to
me
at
some
point,
I
think
any
of
these
objects
could
be
converted
into
others
or
be
displayed
in
any
ui.
So
I
just
want
to
make
sure
that
that
I'm
grocking
that
nuance
to
how
engineering
is
thinking
about
it.
D
F
Part
of
that
confusion
stems
from
just
the
words
in
the
code
so
like
the
issue
model
and
issuables,
and
things
like
that,
like
they
probably
won't
change,
or
you
know
or
like
most
likely,
won't
migrate
that
to
a
new
name.
So
it's
some
of
that's
that
consent
that
confusion
is
going
to
persist
just
because
the
difference
between
like
what
we're
talking
about
from
the
actual
products
like
what
we're
creating
versus
what
what
it
exists,
as
in
the
code
base.
E
F
G
Side
no,
but
I
think
the
general
point
is
fair,
like
we
need
to
sort
of
standardize
on
nomenclature.
Otherwise,
like
there's
a
lot
of
confusion,
just
coming
from
the
fact
that
we're
using
different
terms
for
everything
and
some
of
those
terms
overlap.
B
We
could
do
that
right
now,
so
we
have.
What
is
it?
What
what
is
the
difference
between
a
planning
object
and
an
issue?
All
right?
I
guess
what
do
we
want
to
call
the
the
thing
that
is
the
core,
like
master
object
like
an
issue
whatever.
G
No
see
that's
the
thing
the
eigen
issue
would
have
been
the
issue
of
type
issue
like
which
I
would
propose
that
we
simply
call
issues,
because
that's
what
we'll
call
them
in
the
interface
and
the
issues
of
any
type
could
be
called
planning
objects.
In
fact,
we
could
probably
rename
the
table
in
the
database
if
it
wasn't
a
painful
thing
to
do.
Planning
objects
instead,.
G
Unless
anyone
has
any
opposing
views
on
that,
that
would
be
the
existing
issue
table
right,
they're
issued
I'm
just
saying
we
could
I'm
not
saying
we
should,
but
since
we're
going
to
refer
to
everything
as
planning
objects.
Anyway,
when
we
say
like
a
requirement
as
a
planning
object,
an
epic
is
a
planning
object.
An
issue
is
a
planning
object.
We
might
as
well
refer
to
the
the
issues
table
and
the
meta
object
as
a
planning
object,
and
then,
when
we
say
issues
we're
specifically
referring
to
the
type
issue.
H
I
H
Planning
object
essentially
replaces
what
we
were
considering
issuables
in
the
past
and
then
an
issue
is
a
planning
object.
That's
an
issue
type.
B
Just
for
context,
playing
object
came
about
because
initially,
when
taught
working
with
ux
and
doing
cv,
experience,
there's
confusion
about
the
goal
or
the
outcome
of
would
an
epic
become
an
issue
like
what?
What
is
the
thing
right?
And
so
I
think
that's
where
we
we
set
that
to
remove
confusion.
We
call
the
planning
object
for
that
case,
but
we
already
have
issues.
We
already
have
an
issue
table
and
then
we
have
types
of
issues.
B
G
J
E
I,
like
that,
I
I
think
we
came
around
to
fairly
good
understanding
there.
As
long
as
we
use
the
issue
type
to
differentiate
the
object
or
the
actual
name,
I
guess,
and
in
reference
to
the
generic
object,
it
would
be
planning
object
instead
of
maybe
just
issuables
need
to
get
get
replaced
with
planing
object
as
a
term.
F
D
D
But
okay,
so
so,
just
so,
I'm
again
clear
planning
object.
It's
not
an
epic!
It
is
this
lar.
This
thing
that,
with
this
super
issue,
this
thing
that
we're
adding
all
these
attributes
to
that
we're
making
configurable
or
whatever
that's
what
a
planning
object
is
and
epics
fall
under
that
and
requirements
will
fall
under
that,
and
everything
falls
under
that
this
is
the
new
right.
The
new
meta
issue,
okay,.
D
D
B
Exactly
somebody
kindly
re
define
issue
for
me,
so
I
can
write
it
down.
D
D
B
I
said
I
captured
that
in
the
notes
it's
a
type
of
playing
object,
so
we
can
migrate
all
existing
issues
to
a
type
issue,
so
it's
like,
instead
of
forcing
every
user
to
like
pick
a
different
thing
when
we,
so
we
basically
can
launch
it
working
by
default.
This
is
like
the
way
that
we
enable
that.
E
D
Yeah
but
there's
no
difference
between
there
won't
be
any
difference
between
an
issue
and
a
bug.
Let's
say
I
mean
their
issue
would
just
happen
to
be
the
generic
name
that
we
had
in
order
to
get
everybody
on
the
new
system.
There's
no
inherent
value
in
it
that
I
can
see
right
or
is
or
would
be.
Are
we
going
to
be
able
to
put
a
real
usability
around
it?
That's
a
that's
a
default.
You
should
create
all
your
issues
because
that's
the
main
thing
and
then
you
can
create
bugs
and
tasks
and
other
stuff.
E
B
B
K
D
E
Yeah
we'll
have
different
models
of
project
or
product
management
as
well
like
safe
and
things
where
people
could
change
their
whole
setup
to
use
a
different
set
of
rules
or
hierarchies.
D
So
that
means
that
we
leave
issue
as
a
generic
standard
object.
It's
one
of
the
what
I
call
the
first
class
ones,
but
it
doesn't
have
a
specific
subtype.
He
just
kind
of
defaults.
We
have
we
happen
to
name
it
issue
with
some
kind
of
description,
but
in
order
to
make
it
configurable,
you've
got
to
do
a
bunch
of
stuff
on
the
database
back
in
in
order
to
fill
in
extra
rows
and
all
this
kind
of
stuff.
So
anyway,
we
just
need
to
think
through
it.
Some
more.
That's
all
sorry
to
derail
here.
B
I'm
also
wondering
if
we
can
do
like,
instead
of
doing
whatever
migration
all
at
once,
if
we
start
doing
it
behind
the
scenes
over
a
couple
of
releases
and
if
there
is
a
way
to
limit
it
to
some
sort
of
name
space
or
something
we
don't
have
to
do
it
all
at
once.
If
we
can
figure
out
a
way,
but
I
do
think
that
making
making
eventually
making
the
issue
one
of
those
generic
customizable
types
will
allow
people
to
get
rid
of
it.
If
they
don't
want
to
use.
B
H
So,
just
to
clarify,
there's
custa
customizable
type,
but
that
is
not
a
sub
type
of
issue
like
where
does
where
does
bug
sit
in
this?
Is
that
a
subtype
of
issue,
or
is
that
a
first
class
object
or
is
it
a
custom
object
in
the
future.
H
C
C
J
D
The
issues
today
already
have
an
issue
type,
meaning
it
could
be
issue
test
case
incident
requirement.
I
think
that's
it.
That's
what
I
call
that's
what
I've
been
calling
a
first
class.
We
can
name
it
something
else,
but
those
are
I
get
this
object
and
it
is.
The
type
is
hard
coded
into
the
issue.
C
C
D
C
My
understanding
was
my
understanding
was
that
that
issue
type
will
point,
so
the
issue
type
column
right
will
point
to
a
type
that
is
customized
by
the
by
the
customer.
So
if
they
add
a
new
type
called,
I
don't
know
new
object,
then
this
issue
record
will
point
to
that
type.
So
it
cannot
be
in
two
types.
At
the
same
time,
it's
either
our
predefined
type
or
it's
the
customer's
custom
type.
It
could
not
be
both
a
bug
and
the
customer's
custom
type.
I
C
D
I
B
B
It
is
just
that
if
you
treat
issue
types
all
the
same,
this,
the
first
class
ones
that
we
are
now
the
only
thing
is
it's
just
their
system
defaults
and
they're,
not
editable
right,
but
that
doesn't
mean
that
we,
I
don't
know
if
we
want
to
treat
them
differently
like
and
it's
totally
up
to
the
engineers.
It's
an
implementation
decision
that
I'm
definitely
not
the
bri,
for
so
it's
whatever
y'all
think,
but
whatever
we
can
do
to
keep
things
as
simple
as
possible
and
make
sure
that
whatever
we're
doing
is
the
most
performant
approach.
B
Well,
if
you're
on
a
board
you
might
want
to
filter
by
like,
in
the
let's
say,
the
filter
bar,
you
have
a
drop
down
filter
by
incident
or
filter
by
test
case
right.
That's
a
really
common
use
case.
When
I
talk
to
sarah
and
monitor,
is
people
on
boards
want
to
be
able
to
have
swim
lanes
for
different
types,
like
maybe
swim
lane
for
an
incident
a
swimming.
B
So
there
are
places
where,
if
we
get
to
the
point,
even
where
we
allow
people
to
have
a
little
bit
more
control
over
how
they
set
up
their
views
where
they
want
to
create
a
view
that
has
requirements
and
like
test
cases
or
it
just,
I
think
they,
the
types
all
all
need
to
be
treated
the
same
in
the
back
end.
So
we
don't
run
into
this
weird
thing
where
we're
having
to
like
mash
together
a
bunch
of
different
things.
But
I
am
that's
just
an
opinion
so.
I
B
If
I
have
a
feature
in
these
other
things,
we
can
kind
of
sort
that
out,
but
that
would
also
allow
us
to
get
to
a
migration
where
it's
working
by
default
and
we
don't
even
have
to
have
any
configuration
to
let
them
enable
custom
types
or
whatever.
It's
just.
You
have
issue.
Everyone
has
issue
types
right
and
that
way,
there's
like
a
standard
approach,
but
we
can
follow
up
offline
too.
F
Okay,
let's
spin
up
a
thread
on
the
implementation
issue
discussion,
and
so
we
can
like
capture
it
there.
I
think
I,
from
my
perspective
as
a
sort
of
third
party
here,
I
think
you
guys
might
be
actually
pretty
close
to
agreement
on
the
way
you're
talking
about
it
and
it's
just
a
confusion.
But
maybe
I'm
misunderstanding
too:
it
sounds
not
too
terribly
different,
so
hopefully
there's
yeah.
We
can
figure
it
out
and
move
forward.
J
Yeah
hi,
so
I
I
started
thinking
about
these
planning
objects
like
because
some
of
this
discussion
sounded
like
quite
back-end,
because
you
know
like
what
what
is
in
what
table
is
not
as
important
to
end
users
right
but
then
do
we
want
to
start
using
planning
object
in
the
documentation.
How
we
talk
about
these
things
and,
like
I
said,
I'm
also
thinking
about
how
we're
going
to
talk
about
the
feature
object
and
before
I
before
we
started
discussing
this
here.
J
J
G
J
G
Yeah
sure
I
think
in
the
developer-
docs
possibly
we
might
want
to
like,
as
I
said
before,
the
nomenclature
matters
like,
but
from
the
user's
perspective,
I
don't
think
they
need
to
care
about
planning
objects.
There
are
other
carobid
features
bugs
stories,
epics
issues
and
we
should
maybe
even
avoid
using
it
in
public
facing
documentation,
makes.
J
E
We'll
probably
still
need
to
use
some
terms
and
doc
in,
like
the
docs
around
certain
key
object
types
but
like
epics
or
things
that
people
are
looking
for
in
a
product,
but
yeah,
I
think,
focusing
on
the
types
would
be
the
main
push
and
potentially
we
could
call
them
planning
objects
with
our
customers.
We'd
have
to
see
how
that
rolls.
E
It
makes
sense
to
me,
but,
like
you,
can
change
planning
object,
type
versus
telling
them
you
can
change
issue
type
people
seem
to
not
like
the
word
issue.
In
some
cases.
B
E
B
G
B
What
is
the
issue
now
in
their
terms
of
their
business
domain
and
what
how
they
talk
about
it
so,
like
I,
don't
know
how
we
remove
issue
completely
from
the
ui,
but
if
we
can
find
a
path
to
do
that
and
like
allow
people
to
like
still
know
what
the
types
are
and
things
like
that,
then
that's
great
and
I
think
the
jira
is
at
least
next-gen
has
done
a
good
job
about
balancing
that
where
it's
still
called
an
issue
behind
the
scenes,
but
they've
limited
that
in
the
ui
in
lots
of
places.
G
I
think
for
people
running
software
projects,
perhaps
open
source
software
projects,
and
things
like
that.
The
word
issue
is
like
an
industry
standard
term.
You
know
our
main
competitors
use.
So
from
that
perspective
we
probably
want
to
keep
it
in
there
like
as
an
option,
at
least.
K
Yeah,
I
guess
my
perspective,
I
think
it's
like
a
legacy
term
that
came
about
from
where
all
these
trackers
came
from,
which
is
bug
tracking
right,
but
now
people
have
taken
this
concept
and
expanded
it
to
track
like
agile,
work
right
and
so
now,
there's
like
all
these
different
things,
but
at
the
core,
a
lot
of
these
tools
still
have
the
origin
of
issue
tracking
right
like
bug,
tracking
and
they've.
Just
like
kept
the
terminology,
at
least
that's
the
case
with
jira
and
bugzilla,
and
a
bunch
of
these
tools.
C
Well,
what
other
places
other
than
like
the
sidebar,
where
we
say
directly
issues?
Do
we
have
any
like
other
major
places
where
we
use?
That
name?
Can
that
be
replaced
by?
I
don't
know
plan
and
then
you
have
list
and
what
not
there
and
then
just
have
all
of
the
objects
that
you
have
there
like.
I'm
not
my
expert
just
saying.
If
we
don't
have
a
lot
of
the
usages
of
the
issues
name
within
the
ui,
maybe
we
can
just
fairly
easily
get
rid
of
that.
I
don't
know.
J
Hey
gabe,
do
you
want
to
specify
I'm
not
sure
what
you
mean
by
type
issues
type
issue
and
the
last
thing
you
typed.
B
So
if
we
want
to
make
issue
types
work
by
default,
we
currently
have
a
hard-coded
the
type
issue,
the
type
requirement,
type
test
case
and
type
incident
right.
So
we
have.
If
we
are
going
to
migrate
to
like
an
issue
types
table,
then
we
sort
of
have
to
support
the
current
type
issue.
Otherwise
we
can't
make
it
work
by
default
and
we'll
we'll
force
or
require
customers
to
sort
of
like
pick
a
different
type
when
they're
doing
the
migration.
B
So
thinking
about
that
way
like
how
do
you
take
everyone
from
this
hard-coded
thing
to
this
other
thing
right
and
make
it
work
by
default?
I
think
that
was
a
challenge,
and
so
one
of
the
proposals
to
solve
that
is
to
add
a
type
issue.
So
we
can
literally
migrate
all
the
hard
code
types
to
this
now
like
types
table
and
then
eventually,
if
the
customer
doesn't
want
to
use
type
issue,
they
can
rename
it
to
whatever
they
want.
I
B
So
it's
really
whatever
will
be
the
we
can
make
it
not
customizable
until
we
get
them
like
the
merge
happens,
some
form
or
fashion,
but
if
we
do
want
to
make
them
customizable
doing
it
the
highest
possible
level,
so
you
only
do
it
in
one
place
would
be
the
desired
behavior.
From
a
customer
standpoint,
I
think.
J
E
E
Are
there
any
other?
I
know
we're
almost
out
of
time.
We've
got
two
minutes
here.
Any
other
questions
concerns
things
we
could
take.
E
E
I
think
that's
the
end,
then,
of
the
agenda.
Just
a
reminder.
We
do
have
team
day.
Events
during
the
day
today,
I'm
definitely
going
to
join
the
next
one
and
maybe
the
later
one
we'll
see.
G
E
G
Yeah,
it
should
be
lowest
common
denominator,
really
yeah,
just
in
the
phone
with
like
sticky
sweaty
fingers.
That's
my
plan.
F
F
You
can't
even
use
a
mouse
just
straight
angles:
just
a
keyboard,
arrows,
yeah.