►
From YouTube: Plan | Stage Weekly Sync 2022-01-19
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
Sounds
like
a
yes
cool
plan,
weekly
meeting
19th
of
january
2022.,
gabe.
B
B
Trying
to
be
more
efficient,
you
know
more
focused
and
less
noise,
so
I
found
that
when
I
started
at
6
30,
I'm
actually
able
to
dig
into
some
of
the
bigger
things
earlier
on
before
some
of
the
folks
in
the
us
wake
up.
So
it
also
enables
me
to
spend
a
couple
more
hours
of
daylight
with
my
kids
in
the
afternoon,
which
is
win-win.
C
Yeah
we
can
skip
mine.
I
was
just
going
to
applaud
gabe
for
getting
up
that
early
and
say
that
I
love
the
early
shift
so.
A
D
A
Cool
I'll
jump
in
the
confidential
notes,
so
there
are
a
few
issues
on
at
the
minute
on
the
products
part
of
the
product
planning
side
of
the
team
that
I'm
keeping
an
eye
on
and
one
of
them
is
confidential
notes.
These
are
either
issues
that
have
been
started
and
taken
forward
by
a
community
contributor
or
started
by
us
in
the
past
and
continued
up
to
a
point.
A
Confidential
notes
is
an
interesting
one
because
the
way
it's
implemented,
currently,
it's
not
ready
for
general
availability,
because
we
can't
be
absolutely
sure
that
confidentiality
is
respected
in
all
circumstances.
So
you
won't
see
confidential
notes
in
the
ui
and
I
believe
we've
removed
them
from
activity
feeds.
But
we
haven't
checked
things
like
rss
feeds,
email,
notifications,
you
know
maybe
different
parts
of
the
api-
I
don't
know
so
we
need
to
harden
it
first.
A
The
problem
is,
we
kind
of
need
to
define
an
mvc
that
we've
already
kind
of
had
community
contributors
push
forward
into
what
would
be
a
second
iteration,
and
so
what
I
wanted
to
do
in
this
call
was
to
try
and
for
everyone
on
the
call
like
who's
interested
in
this.
Like
try
and
come
up
with
an
mvc
I've
proposed
one,
it
seems
to
me
to
be
logical.
A
One
of
the
main
problems
we're
having
with
this
is
that
you
can
already
like
it's
behind
a
feature
flag,
but
you
can
already
go
into
the
api
and
convert
a
note
to
be
confidential
and
that
is
not
behind
a
feature
flag.
So
that's
kind
of
worrying
because
you
can
do
it
on
any
note,
including,
like
mr
diff
notes,
which
is,
it
doesn't
really
have
a
use
case.
As
far
as
I
know,
and
opens
all
this
complexity.
A
So
what
I'm
suggesting
is
that
we
devise
an
mvc
epic
stuff
everything,
that's
not
in
the
mvc
into
another
feature
flag
for
the
future,
or
even
remove
it
entirely
from
the
code
base
and
that
the
nvc
should
be
pretty
simple,
and
I
think
that
means
like
you
can
create
a
private
note
as
the
root
of
a
discussion
which
then
the
rest
of
the
discussion
is
private
by
default
and
you
can't
toggle
it
to
public
ever
and
that
it's
restricted
to
epics
and
issues
so
yeah.
Any
thoughts
on
that
as
an
mvc.
First
of
all,.
B
I
think
it's
great,
I
also
just
gonna,
highlight
that
zendesk
does
not
allow
me,
at
least
to
my
knowledge,
to
change
the
confidentiality
notes.
They
also
call
it
an
internal
note,
which
I
think
more
clearly
communicates
what
what
it
means
actually,
but
just
another
data
point.
E
Yeah,
I
was
just
saying,
maybe
something
very
specific
about
the
type
of
notes
if
we
should
limit
that
and
if
we
issues
one
discussion
note,
maybe
by
checking
the
type
of
note
where
we
created
not
allowed
it
to
be
confidential.
If
it's
not
a
discussion.
A
Yeah,
I
actually
think
that
yeah
we
shouldn't
there's
no,
the
there
was
a
community
contribution
to
try
to
bring
in
toggle
ability
and
it
got
stuck
in
the
weeds
and
the
community
contributors
quit
on
it
because,
as
far
as
I
understand,
there's
no
object
in
the
database
currently
to
describe
a
discussion.
That's
just
a
relationship
between
a
root
comment
and
replies
to
that
note.
A
A
F
A
No
no
need
to
apologize
yeah.
I
think
that's
it's!
It's
me
like
it's
also
the
simplest
thing
to
do.
We
might
never
need
to
toggle
ability.
You
know
people
might
never
ask
for
it
anyway.
You
might
get
90
of
that
and
it
it
just
brings
in
so
much
complexity
that
we
don't
really
want
to
be
solving
up
front.
We've
already,
like
I
said,
had
two
community
contributors
who
really
wanted
to
see
the
feature
released,
who
just
quit
on
the
mr,
because
it
was
too
complicated.
A
Did
that
I
don't
know.
If
I
answered
your
question,
though
eugenie
I
think
it
should
be
limited
to
discussion
notes
only
like
we
don't
think
we
would
want
to
make
system
notes,
for
example,
or
mr
death
notes.
I
think
we
should
just
avoid
mrs
altogether
in
the
first
iteration
focus
on
issues
in
epics.
E
So
so,
like
I
said
that
the
image
thief
note,
so
that
when
you
go
and
comment
in
an
image
and
not
by
ui,
but
you
can
go
to
the
api
and
create
that
type
of
note
and
make
it
confidential.
It
doesn't
really
show
us
confidential
because
it
doesn't
have
the
ability.
But
it's
it's
just
like
the
confidential-
is
in
every
note
any
type,
even
in
comments
snippets.
Everything.
G
A
The
problem
is
that,
like
then,
we
run
in
we've
run
into
already.
I
think
this
thing
where
it's
we
have
to
maintain
it
then
for
merge,
requests
you
know,
or
somebody
has
to
maintain
it
and
it's
like
you.
You
then
have
to
look
at,
like
mr
diff
notes,
right
and
kind
of
say
like
well
think
of
all
the
special
cases
that
those
notes
have
right
or
or
maybe
maybe
not-
I
don't
know
like
so
maybe
on.
A
Mrs
you
could
have
discussion,
notes
be
confidential
as
well,
but
only
discussions
and
replies-
I
don't
know,
I
don't
know
enough
about
the
code,
but.
B
We
could
also
in
that
line
ahead
of
point
b,
so
I
think
notes
right
now
are
resolvable,
but
there's
no
ui
for
on
issues.
We
can
do
a
similar
type
thing
where
we
don't
overthink
it
too
much,
but
we
like
don't
add,
explicit
support
for
it
and
in
the
ui.
So
if
you,
if
you
like,
if
you
look
at
a
note
that
can
already
be
marked
as
resolvable
on
an
issue,
I
think
technically,
but
it's
not
like
a
formally
supported
thing
that
could
be
a
viable
workaround
too.
G
C
Yeah
just
expand
on
your
point.
Brett
on
the
front
end
the
I
believe
the
diff
code
is
pretty
coupled
between
like
at
the
issuables
level,
so
it
might
actually
be
more
difficult
to
separate
them
out
and
not
do
it
on,
mrs,
if
we
were
going
to
do
it
on
the
issue
side
of
things.
C
A
A
Right
cool:
well,
thanks,
brett!
Actually,
so
that's
the
next
thing.
We
should
probably
look
at
it's
like
if
we're
gonna
try
to
create
an
mvc
out
of
it,
we
can
nail
that
down
and
also
we've
got
to
figure
out
what
we're
gonna
do
with
the
with
the
api.
A
D
H
Regarding
this
private
nodes,
I
think
that
mvc
sounds
like
a
great
idea.
I
was
wondering
if.
H
What
happens
if
some
external
user,
or
not
external
but
unprivileged
user,
is
pinked
in
my
command,
but
virginia
already
answered
my
question.
So
thanks
and
I
was
wondering
if
we
could
somehow
get
rid
of
edge
cases
like
tools
or
notifications,
if
you
would
just,
for
example,
ignore
these
users
in
a
first
mvc.
A
G
Well,
we
I
mean,
I
don't
know
if
it's
done
in
the
bonds,
I
mean
that's,
we
do
the
redaction
there,
but
in
general,
if
you
mention
somebody
on
a
confidential
issue,
they
don't
necessarily
get
pinged
right
if
they're
not
part
of
the
they're
from
the
community
or
whatever.
That's
there's,
there's
some
logic
in
there
somewhere
for
doing
that
already,
I
would
think
so.
Maybe
we
can
tap
into
that.
A
Okay,
cool
I've
linked
the
epic
or
issue
there
already.
So,
if
you
want
to
take
a
look,
anyone
who's
contributed
here
as
well
like
if
you
want
to
go
in
and
put
your
ideas
in
there
for
the
mvc
like
ideally,
there's
then
like
three
things
to
do,
which
is
to
you
know,
sort
out
the
api
we
still
need
to
figure
out
like
have
any
confidential.
A
Have
any
notes
been
converted
to
private
when
they
shouldn't
have
been
through
the
api,
and
then
I
would
recommend
just
put
that
behind
a
feature
flag
defaulted
to
off
and
then
in
the
future.
If
we
want
to
iterate
on
this,
we
use
that
feature
flag,
cool,
donald,
here's,
the
next
thing,
if
there's
no
more
comments
on
that.
C
Cool,
do
you
all
know
what
time
like?
I
wonder
if
melissa
wants
to
be
involved
in
this
conversation,
though
I
know
she
said
she's
going
to
be
a
little
late.
Does
anyone
know
how
late
she's
going
to
be.
C
Yeah
all
right,
we'll
just
continue
so
work
items.
Okay,
so
there
was
a
there's
a
conversation,
a
long
thread
in
the
planned
back
end
channel
around
kind
of
the
level
of
flexibility
we
want
to
allow
on
work,
item
types.
C
Do
y'all
want
to
just
jump
into
the
conversation
on
it
or
I
talked
to
natalia
a
little
bit
and
she
has
a
demo
ready
of
her
of
her
branch
and
it
may
be
helpful
to
have
that
as
kind
of
the
baseline
for
the
conversation.
I
I
can,
I
can
totally
run
a
demo,
please
be
ready
to
the
fact
that
this
is
a
local
mutation.
It's
not
calling
any
kind
of
back-end
stuff
and
it's
not
selecting
a
work
item
type.
So
we
are
following
the
old
design
where
we
will
creating
a
task,
but
maybe
it
would
be
nice
to
kickstart
the
conversation
about
the
selection
of
work
item
type.
So
let
me
share
my
screen
quickly.
I
So
currently
we
have
this
flow.
Hopefully
my
gdk
is
not
freezing
right
now.
Whenever
work
item
feature
flag
is
enabled,
we
will
have
this
little
button
clicking
on.
It
will
give
us
a
popover
with
convert
work
item,
and
here
is
where
the
problem
starts.
Currently,
whatever
we
are
doing
here,
when
we
click
create
work
item,
it
just
changes
locally
the
dom,
but
we
would
need
to
send
the
mutation
to
the
back
end
here
and
as
it
was
discussed
in
slack,
we
cannot
send
the
mutation
to
create
a
task
or
any
kind
of
predefined
type.
I
I
Do
we
want
to
have
this
drop
down
in
the
model
or
in
the
top
over
and
in
general,
like?
What
do
we
expect
to
have
here?
Whenever
user
clicks
on
this
link,
like
opening
a
generic
work
item,
because
it's
quite
important
to
understand
how
we
want
to
display
things
on
the
work
item
view
in
the
model
or
in
the
separate
route,
what
will
define
them
and
so
on
and
so
on?
B
I
think,
given
wanting
to
maintain
flexibility
for
the
long
run,
I
think
that's
an
important
principle
and
I
kind
of
highlight
that
down
below
just
like
it
will
allow
us
to
extend
the
work
item,
to
support
more
jobs,
to
be
done,
adjacent
basically
personas,
like
tickets
and
opportunities
and
incidents,
and
so
on.
I
think
users
should
be
able
to
create
any
type
of
work
item
where
the
type
selector
lives,
I
think,
is
a
ux
decision.
B
Honestly.
I
think,
if
there's
a
way
that
we
can
allow
them
to
click
the
convert
to
work,
item
button
and
default
to
a
basically
child
for
premium
once
we
sort
of
the
product
planning
team
has
done
some
of
that
work,
that's
something
that
we
could
do
sort
of
when
we
open
up
the
modals
query,
the
kind
of
higher
e
or
the
relationship
structure
and
then
default
to
one
does
below
the
current
type.
B
That's
that's
sort
of
my
like
two
cents
on
that,
but
I
think
going
into
my
few
thoughts.
We
want
it
to
work
by
default
and
pre
pre,
I
guess
determine
to
me
just
looks-
is
like
a
template
basically
of
your
relationships,
but
we
want
to
keep
them
generic
enough
so
that
users
can
modify
that
and
or
select
a
different
kind
of
template
like
if
they're,
using
one
planning
methodology
where
you
have
the
named
hierarchy
of
this
or
they
have
a
custom.
B
One,
that's
maps
their
business
domain
really
like
what
it
is
is
having
somewhere,
where
you
define
the
relationships
between
your
types
and
then
we
we
launch
with
a
couple
different
default
templates
or
planning
hierarchies,
which
is
just
a
relationship
mapping
and
that
will
give
us
the
latitude
to
kind
of
use
the
same
primitives
but
to
present
the
and
package
some
of
the
work
item
features
and
the
hierarchies
and
relationships
into
different
methodologies.
B
I
think
anything
that
is
specific
to
like
jobs
to
be
done,
whether
it's
like
linking
a
requirement
to
a
test
case
or
to
an
actual
test
that
runs
the
code
like
extract
that
into
its
own
standalone
sort
of
like
app
that
can
be
enabled
for
work
items.
We
can
certainly
shape
our
own
default.
Like
hierarchy-
and
I
think
we
should
so
it
works
by
default,
but
always
thinking
through
the
lens
of
not
hard
coding.
Some
of
the
stuff
would
be
ideal.
I
I
I
G
One
one
of
the
things
I
mentioned
in
the
thread
and
that
we've
talked
about
in
the
past
is
you
know
each
work
item
type
has
a
set
of
capabilities
abilities
whether
it's
supports
children
or
supports
the
estimate,
time
estimate
and
all
these
different
things-
and
I
always
thought
at
least
in
terms
of
when
we
were
creating
tasks,
that
there
was
something
that
we
marked
as
this
is.
This
work
item
is
taskable
it.
It
is
a
task.
G
I
don't
know
how
we
treat
that
differently
or
what
behavior
that
means.
But
I
assume
that,
because
we
were
making
it
a
task,
there
was
some
special
behavior
to
it,
and
if
that's,
if
we
do
that,
then
any
we
can,
you
can
request
any
work
items
that
have
that
flag
and
those
are
the
ones
that
can
be
presented
and
carried
over
to
other
workspaces
or
whatever.
So
that
would
be
not
based
on
the
name
but
based
on
a
flag
that
we
say.
Yes,
this
supports
task
functions,
whether
that's
how
they
get
listed
out
or
whatever.
H
C
Yeah,
so
I'm
just
wondering
how
this
would
work
around
the
around
creation
so
like
for
tess,
we
go
to
create
a
task,
it
shows
up
with
the
modal
and
then
we
offer
a
drop
down
where
they
should,
where
they
choose
the
work
item
type
and
do
we
not
show
any
fields
or
any
widgets
until
they
select
the
work
item
type
and
then,
at
that
point,
how
do
we
know
what?
B
My
thinking
was,
if
we
look
at
the
designs
that
the
product
planning
group
has
already
done
for
the
hierarchy
right,
like
you,
sort
of
have
a
set
of
types,
and
you
want
to
be
able
to
store
the
type
names
and
other
type
names
and
sort
of
also
like
the
same
need
arises
with
customizing
the
names
and
the
way
that
I
was
thinking
about.
It
is
that
each
work
item
gets
a
schema
that
we
store
right.
B
The
schema
defines
the
apps
or
the
fields
or
the
widgets
or
whatever
that
exists
on
it,
as
well
as
their
relationships,
and
so
that
way
like
we,
we
know
what
the
schema
is
for
a
given
like
what
fields
are
available
in
a
given
work
item
type.
B
The
other
kind
of
example
that
has
happened
recently
is
we've
gotten
lots
of
feedback
on
incidents
that
some
teams
have
switched
back
to
using
issues
because
incidents
don't
have
the
iteration
field
on
them
or
and
whereas
other
teams
don't
want
the
iteration
field
on
them,
because
the
they're
using
incidents
as
true
firefighting,
things
does
not
follow
on
like
stuff
you're
going
to
schedule
into
a
time
box,
and
so
I
don't
know
that's
just.
B
J
I
think
alexis
has
thought
through
a
lot
of
these
scenarios.
I'm
sure
holly
did
as
well.
I
think
where
it
gets.
A
little
gray
is
just
that
when
we
started
to
do
tasks,
we
took
it
off
with
features,
and
so
now
this
ui
is
kind
of
necessary
to
support
tasks.
So
there's
some
overlap,
but
I
think
there
should
be.
We
should
be
looking
at
comp's
designs
as
we're
talking
through
these
things
as
well
and
looking
at
the
front-end
work.
That's
already
been
done
for
to-do's
for
tasks
and
just
figuring
out.
J
What's
the
minimum,
we
can
do
to
support
the
flexibility
as
well
as
having
a
really
a
flow,
that's
consistent,
so
that
it
will
work
for
epics.
It
will
work
for
for
tasks,
and
I
think
we
are
we're
all
on
the
same
page
as
that
we
just
need
to
allow
a
line
around
the
actual
designs
and
even
maybe
a
clickable
mock-up,
or
something
to
see
how
it
feels.
K
There
is
a
prototype
that
I
put
into
the
agenda
there
and
it's
just
currently
showing
the
drop
down.
Let
me
share
my
screen.
D
K
Excellent,
so
in
this
case,
just
as
natalia
was
showing
the
three
dot
menu
to
the
side,
click
on
it
gives
you
the
convert
to
work
item
prompt.
K
Oh
no,
did
it
just
lock
up
there
we
go,
and
in
this
case
I
included
the
type
task
it
defaults
to
task,
but
there
is
a
type
selector
where
someone
can
go
in
and
change
it
if
they
choose
to.
Donald
makes
a
good
point,
though,
that
the
fields
that
are
listed
below
it
probably
would
change
dependent
upon
the
type-
and
I
only
included
these
here,
as
they
are
part
of
the
longer
term
vision
they're,
not
in
vc
the
assignees
in
weight.
K
J
J
G
I
I
think
you're
right,
I
think
we
can.
We
can
box
this
for
the
nbc
as
long
as
what
is
determined
to
be
a
task
comes
from
the
back
end,
not
from
the
name
of
the
type.
So
in
other
words
we
we
know
where
the
vision
is
and
and
the
flexibility
we
need,
and
in
order
to
do
that,
the
back
end
needs
to
be
able
to
say
this
type
is
a
task
and
keep
it
boxed
to
that
right
now
and
then
we
can
open
it
up
later.
G
D
Right:
do
you
think
that
that
should
be
like
some
sort
of
capabilities
like
thing
that
can
expand
to
cover?
You
know
additional
like
if
we
can
put
a
taskable
boolean
on
the
model
and
just
have
it
be
like?
Is
this
work
item
type
taskable,
but
is
your
opinion?
Is
that,
like
we
have
some
sort
of
like
broader
capabilities
like
indicator.
G
Yeah
we
well,
we,
we
know
that
we
need
this
list
of
abilities,
slash
widgets,
slash,
apps
or
whatever.
That's
that's
where
this
is
built
into,
and
you
know
if
we,
if
we
just
now,
have
an
abilities
that
can
only
hold
a
flag
that
says
it's
taskable,
then
we
can
do
that
and
then
we
we
can
expand
it
on
the
back
end
later
and
then
in
the
ui
to
start
filling
this
out.
But
I
don't
think
we
have
to
go
with
creating
many
different
work
items
if
we're
not
ready
to.
J
I
think
that
that
would
be
good
to
have
a
session
where
we
just
go
through
that,
because
there's
alexis
has
done
tons
of
work
on
that
on
her
ideation
and
how
it
would
look
another
question
that
comes
to
mind
just
from
seeing
that
mock-up
task
has
a
specific
label.
It's
getting
in
the
ui
after
you've
converted
it
that
flow
indicates
that
task
would
be
a
set,
get
lab
work
item,
type
that
you
wouldn't
mess
with
or
change
if
it
needs
to
get
special
treatment.
J
If
I
could
convert
any
one
of
those
check
boxes
to
whatever
other
work
item,
I
have
an
epic,
an
issue,
an
incident
and
they
all
get
the
exact
same
ui
where
there's
a
label
that
goes
in
on
them
after
I'm
done
converting
and
it's
all
consistent,
but
something
also
not
sure
if
we're
thinking
about
it
that
way.
But
there
are
some
types
like
task
requirements
incidents
we
may
want
to
lock
in
and
we
have
in
our
docs
and
their
true
features
that
people
would
turn
not
be
able
to
turn
on
and
off.
J
G
G
J
B
Yeah
with
that
one
in
particular,
the
the
name
task
is
just
pulling
the
type
name,
but
really
what
we're?
Storing
there
is
the
id
of
the
work
item
type
itself.
So
that
way,
it
could
be
like
any
work
item
types
that
we
have,
whether
it's
ones
that
we
ship
by
default,
or
that
the
customer
or
user
adds
or
specifies
or
edits
whatever
like.
B
If
you
change
the
name
of
task
to
foo
right,
then
it
would
just
show
up
as
foo
in
that
little
indicator,
so
it's
sort
of
like,
instead
of
thinking
about
it
as
a
special
we're
just
getting
we're
just
rendering
the
type
name
there
for
for
context
for
the
user.
If
that
makes
sense,
because
we
did
add
the
work
item
types
table,
I
think
right
which
specifies
like
the
different
types.
So
we
already
are
storing
the
id
and
then
the
name
which
is
separate
and
that's
why
we
moved
away
from
enum.
J
J
As
long
as
the
model's
flexible
enough
to
handle
everything,
I
think
it
can
work
it's
just.
We
should
probably
have
more
communication
around
what
the
actual
use
cases
are
for
it
and
how
that
maps
up
to
the
templates
and
then
to
tiering,
because
obviously
tiering
is
going
to
play
in
to
whether
you
can
even
have
a
child.
A
You
could
imagine
they
would
have
a
work
item
to
complete
a
design
dock
or
a
work
item
to
complete
a
quality
feature
spec.
So
in
order
to
deliver
this
issue
first,
we
must
complete
the
design
dock,
complete
the
feature,
spec
and
then
three
tasks.
Is
that
what
we're
saying
like?
So
it's
a
task
list,
but
it
contains
all
sorts
of
different
work
items.
J
So
it's
we
also
have
a
concept
of
checklist
counts
that
rolls
up
onto
issues
like
10
out
of
30
check
boxes
are
done.
This
would
be
another
one
which
is
we
have
checklists
then
this
would
be
a
count
of
children,
but
I
think
the
closing
the
open
closing
is
the
simplest
that
we
need
to
follow
and
it
would
get
weird
mixing
objects
if
they
didn't
have
the
checkbox
in
their
definition.
J
J
Maybe-
and
maybe
I
haven't
seen
the
updated,
but
I
was
thinking
that
checkboxes
were
like
a
title
and
a
checkbox,
but
maybe
they
are
truly
closed.
Open
closed.
A
Oh,
I
see
what
you
mean,
so
maybe
I
wasn't.
I
probably
wasn't
clear,
like
the
I'm
just
working
off
what
I've
seen
there
in
the
designs,
so
you
can
convert
something
from
that's
part
of
a
check.
Let's
call
it
a
checklist
because
that's
less
confusing,
so
a
checklist
that
has
the
you
know
the
classic
like
check
box
and
then
a
title.
So
you
can
convert
that
to
a
work
item
and
you
choose
the
work
item
type.
So
let's
say
we
have
a
checklist
with
five
items.
First,
one's
write,
an
architecture
document.
A
Second,
one
is
write,
a
feature
spec.
Third
one's
you
know
do
some
programming.
Fourth
ones,
do
some
more
programming
like
whatever
so
the
first
two.
Let's
say
they
have
their
own
work
item
types.
Well,
when
you
convert
them
as
part
of
the
checklist
to
a
work
item
you
could
say.
Well,
I
don't
want
that
to
be
a
task.
I
want
it
to
be
a
design
document
and
the
next
one.
I
don't
want
it
to
be
a
task.
A
I
want
it
to
be
a
feature,
spec
request
and
then
for
the
next
three
will
be
just
tasks
and
they'll.
All
still
be
in
the
checklist
right
and
they
can
be
open
and
closed.
I
presume
with
the
check
box,
but
I
suppose
what
I'm
asking
is.
Can
I
define
a
work
item
type,
define
it
as
taskable
and
add
it
to
this
checklist.
Is
that
ultimately,
where
we
want
to
go
in
in
the
end.
J
A
D
B
Design
document
you
wouldn't
close
that
it
would
say
open,
probably
right.
This
is
long-lived
and
also
brett
brought
up
a
lot
of
good
points
about
like.
If
you
go
edit
things
later,
you
can
like
basically
remove
the
reference.
You
can
add
the
reference
and
it's
like
would
be
sort
of
impossible
to
like
try
to
figure
out
how
to
sync
the
state
of
the
work
item
to
the
gitlab
flavor
markdown
state.
B
So,
like
simplest,
mvc,
just
ignore
the
fact
like
once
something's
done,
you
can
check
the
box
if
you
want
right,
it's
sort
of
a
separate
type
thing
if
that
makes
sense,
but
yes
it
the
that
is
the
design
goal,
john,
so
that
you
can
have
a
list
of
different
things
in
a
checklist
right
like
let's
say,
I'm
working
on
an
epic
eventually,
I
want
to
convert
that
into
a
child
thing,
and
the
child
thing
in
the
hierarchy
is
a
user
story
right
when
I
convert
it
to
that.
B
I
Summarize
the
discussion
should
we
go
with
the
attributes
like
brad
proposes,
because
this
idea,
I
really
like
this
idea.
It's
really
easy
to
implement
on
the
front
end
as
well
as
well
as
a
back
end,
because
we
can
simply
filter
work
item
types
by
the
attribute
by
passing
and
it's
nicely
scalable,
because
we
can
define
in
the
future
not
only
taskable
but
more
like
different
attributes,
where
we
want
to
partly
define
the
behavior
of
the
work
item.
So
should
we
go
forward
with
this.
B
B
G
Whatever
work
item
is
created,
I
you
know,
I'm
not
sure,
but
at
the
very
least
we
could.
We
could
attach
that
to
our
default
task
item
that
we
create
and
allow
the
ui
to
to
use
that,
and
then
we
back
in
can
return
a
bunch
of
stuff
later.
If
we
need
to
we
can.
I
think
we
can
expand
that
if
we,
if
we
need
to.
F
Forgive
me
if
this
is
a
silly
question,
but
is
there
a
reason
why
it
can't
just
be
promoted
to
just
like
a
very
bare
mbc
of
like
whatever
the
task
is
or
even
just
convert
it
to
an
issue?
And
then
the
user
could
decide
what
they
want
to
do,
but
they
want
to
promote
it
or
change
it
to
something
else.
For
nbc.
G
I
I
think
that
might
be
reasonable,
but
and
that's
kind
of
what
I
was
saying
we
would
we
would.
We
would
push
up
a
single
type
of
task
and
that
would
be
defined
on
a
single
work
item
and
then
yeah.
They
could,
I
suppose,
edit
the
work
item
and
change
its
type
if
they
really
needed
to
as
a
as
an
initial
nbc.
I
don't
think
that's
the
direction
we
want
to
finally
go
but
yeah
something
to
move
forward.
F
Yeah
because
I
guess
in
other
products
something
I
see
often
is
just
your
you're
kind
of
promoting
this
small
checklist
into
like
the
smallest
work
item
right
and
then
from
there
you
can
keep
promoting
or
editing.
I
don't
know
if
that's
really
the
way
we
want
to
go,
but
maybe
for
mbc,
it's
like
you're,
just
promoting
it
to
the
next
level
up
for
now
and
then
editing
from
there.
If
that
makes
sense-
which
I
guess
at
the
moment
would
be
an
issue
because
I
don't
do,
we
have
a
task
work
item
to
find.
B
No,
and
I
think
the
promotion
is
going
to
go
away
once
you
can
just
switch
types
like
with
incidents
and
things
like
that.
You
just
change
the
type
and
then,
depending
on
what
type
you
are
currently
and
the
the
hierarchy
rules.
However,
properly
won't
do
that.
I
would
assume
that
it
would
tell
you
what
types
you
can
convert
it
to
right,
and
so
I
don't
I
don't.
I
think
that
that
is
a
fine
thing.
L
I
I
think
the
thing
to
remember,
though,
is
that
if
we
expose
this
and
people
start
using
it
right
with
creating
issues
and
that's
not
what
we
want
them
to
do
long
term,
we're
sort
of
guiding
them
on
this
path,
and
then
we
have
to
guide
them
back
to
whatever
it
is
that
we
do
need.
We
do
want
them
to
do
long
term.
D
G
No
we're
keeping
those
separate,
so
the
the
markdown
list
will
have
some
additional
information
added
to
it
that
links
to
the
to
the
new
work
item
or
issue
or
whatever.
But
there
won't
be
a
a
relationship
link
between.
H
G
D
B
That's
it
it's
really
that's.
The
special
attribute
is
converting
it
to
an
issue
or
a
work
item.
Then
it
has
a
type
task
right
and
the
special
attribute
or
thing
that's
special
about
it
is
that
when
you
create
it,
you
want
to
be
able
to
specify
that
it's
related,
if
it's
in
free
and
then
eventually
a
child.
If
it's
in
premium.
B
We'll
just
like
that's
the
special
behavior
that
we're
trying
to
define
right
now
when
we
create
a
new
work
item,
is
like
the
relationship
right
and
then,
depending
on
what
what
relationship
you're
trying
to
find
and
what
peer
you're
in
defines,
which
types
you
can
create
as
a
linked
thing
or
as
a
child
or
a
parent
work
item.
J
Yeah,
I
think
it's
the
cheering
and
the
parenting
that
we
have
to
think
through
still
and
discuss.
I
just
noticed
you
in
our
docs
with
we
do
have
it.
It
says
it's
in
our
docs
already
tasks
as
a
14-5.
G
Well,
the
url
type,
I
think,
is
locked
down,
but
but
I
believe
we
I'd
have
to
go.
Look
at
the
code
again.
I
believe
we
do
create
a
default
task
type
at
the
top
level.
It's
a
it's
one
of
our
system
defaults
that
we
ship,
but
I
think
it's
probably.
I
think
it's
not
shown
until
that
feature
flag
is
on,
but
I'd
have
to
go.
Look
at
it
again.
J
Because
if
you're
I'm
curious
too,
the
url
is
one
thing
that
once
that's
locked
down
that
will
help
visualize
in
terms
of
like,
if
you
edit,
the
name
of
cast
to
be
something
else,
I
think
we
decided
work
items
is
going
to
stay
locked
and
then
it's
just
the
id
right.
So
it
doesn't
matter
what
they
call
it.
F
J
B
Yes,
those
are
all
capabilities
and
that's
what
sort
of
enables
you
to
easily
have
defaults
for
like
different
behaviors
or
different
work
items
as
well
as
extend
them.
If
you
want
to
extend
them
later
by,
like
let's
say,
I
want
to
have
the
ability
to
link
a
work
item
to
a
code
level
test,
and
I
want
to
call
it
not
a
requirement,
but
I
want
to
have
that
capability
on
a
bug
or
on
something
like
that
right.
B
So
that
way,
if
there's
a
bug,
I
can
link
it
in
and
see
that
every
time
that
the
test
run,
that
the
test
that
solves
the
bug
or
prevent
from
regressing
or
still
passing,
I
mean
there's
like
lots
of
things,
and
I
think
that's
where
encapsulating
them
in
these,
like
what
I
call
apps
right,
that
can
be
that
can
work
on
any
work
item
is
sort
of
the
the
flexibility
that
we're
looking
for,
because
then
each
team
can
build
apps
instead
of
worrying
about
duplicating
everything.
That's
happening
on
the
work
item,
all
right.
B
So
if
incidents
wants
to
build
something
specific
or
monitor
once
build
something
specific,
for
instance,
they
build
a
little
app
that
can
be
enabled
for
a
specific
type
of
work
item,
and
then
it
can
be
disabled.
If
other
teams
don't
want
to
use
that
feature
right,
I
think
that's
the
long-term
goal
and
it
sort
of
decouples
the
special
logic
and
encapsulates
the
special
behaviors
of
these
likes
kind
of
more
self-contained
apps
that
people
can
build,
contribute
manage
maintain
that
sort
of
thing.
D
D
Do
we
want
to
try
to
that
topic?
That's
under
that's
next
that
we
need
to
take
private,
but
we
should
discuss
that
at
some
point.
I
don't
know
how
we
want
to
handle
that.
A
A
You
want
to
see
another
doc
from
this,
maybe
and
create
a
meeting,
especially
to
talk
about
this.
Instead
for
anyone
who's
interested,
I
would
recommend-
probably
at
least
dm's
and
pm's
attend
like
because
we'll
probably
have
to
figure
out
what
we're
going
to
spend
the
next
quarter
on,
and
I
think
it
would
be
a
good
idea
probably
to
do
that
together,
but
everybody's
welcome.
Of
course.
What
do
you
think,
or
do
we
bump
it
to
next
week?
A
It
feels
like
another
week
like
means
that
we're
starting
the
quarter
already
nearly
then
without
this
sort
of
doubt
so
yeah
any
thoughts.
B
A
We
have
plan
off
source,
but
I
would
expect
that
yeah
we'd
be
expected
to
attend
publicly
and
discuss
it
publicly,
which
probably
isn't.