►
From YouTube: 2021-10-05 Work Items Weekly Sync
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Thank
you.
So
it
seems
like
we
have
two
options
for
the
creation
part
of
the
work
item
process
at
least
two.
Those
are
the
initial
two
and
that
is
having
a
default
type
applied
and
showing
corresponding
widgets
for
that
type
and
then,
secondly,
having
no
default
type
applied
and
an
empty
state
for
widgets
until
the
user
selects
a
type
and
then
the
widgets
will
populate
based
on
that
particular
type,
and
I
talked
with
gabe
about
it
later
and
I
feel
like
he
was
also
a
little
fuzzy
on
where
we
landed.
A
Personally,
I
like
the
thought
of
not
defining
the
type
for
initial
creation,
but
I
can
see
the
benefit
of
providing
a
default
type
in
some
cases
you
know
like,
maybe
once
we
have
relationships
set
up
and-
and
you
have
certain
child
elements
that
can
be
created,
maybe
you
only
have
one
child
element
type
that
can
be
created
to
me.
That
makes
sense
to
provide
a
default
type
in
that
case,
but
just
wanted
to
kind
of
throw
that
out
there.
Also
those
questions
again
apply
to
that
specific
creation
part.
A
So
that
leaves
a
separate
question
for
me
of
once.
The
item
has
been
created,
can
the
type
be
changed
at
that
point?
I
think
this
creates
a
better
user
experience.
It
gives
our
users
more
control
over
what
they're
trying
to
accomplish,
but
I
feel
like
there
were
some
concerns
in
terms
of
their
relationship
aspect
and
I
I
feel
a
little
fuzzy
on
that.
The
level
of
understanding
I
have
about
that
challenge
as
well.
B
B
A
So
if
we
choose
the
default
type
for
them,
they
have
not
yet
created
the
work
item.
There
may
be
still
in
the
process
of
building
the
details
for
it,
but
we
create
it
for
them
and
then
can
they
switch
it
before
it's
created
if
they
choose
to,
and
if
not,
can
they
switch
it
after
in
the
event
that
what
we
have
recommended
is
not
the
the
path
that
is
best
or
perhaps
they
choose
the
wrong
path
for
lack
of
education
or
understanding
as
to
what
those
items
are
or
make
a
mistake.
B
I
would
say
during
the
creation
process,
they
should
be
able
to
change
it,
but
not
after
eventually
right
but
maybe
not
for
the
first
nbc,
but
I
also
see
where
you're
going
and
I
think
there
probably
are
a
set
of
common
elements
between
all
work
items.
Right,
like
title
description
assignee,
I
don't
know
others
right.
B
We
can
brainstorm
what
those
are
and
if
we
can
identify
those,
then
yeah
we
can
make
it
where
there's
no
default
type
like
you
said
right
and
they
just
fill
in
the
quote-unquote
basic
details
and
then
like,
maybe
even
for
an
mvc,
like
none
of
the
advanced
ones
show
up
until
after
right.
I
don't
that
could
also
be
a
possibility.
A
So
the
latest
design
does
reflect
that
it
reflects
the
ability
to
change
it
until
creation,
but
once
created
that
field
for
the
selecting
type
becomes
inactive,
just
read
only
if
the
user
adds
in
information
to
it
or
for
whatever
reason
realizes
that
they
don't
want
that
particular
type
applied.
They
will
need
to
delete
and
then
create
a
new
version,
correct,
okay,
yeah.
I
would
definitely
prefer
to
have
the
ability
for
them
to
change
that
down
the
line,
but
I
recognize
there
are
concerns
in
terms
of
scope
with
that.
C
D
A
D
Yeah,
essentially,
are
we
planning
on
having
an
option
for
a
user
to
create
a
new
work
item,
or
can
they
only
create
like
specific
work
items
so,
like
new
work
item
versus
new
issue,
new
incident,
new
epic
new,
merge,
request,
yeah?
Basically,
that's
a
question.
D
Even
even
so
from
say,
an
issue
view
or
today's
issue
view
a
user
can
click
on
the
new
issue
button.
Are
we
still
going
to
give
that
option
and
only
that
option
or
are
we
going
to
say?
Are
we
going
to
replace
new
issue
with
new
work
item.
D
A
Personally,
I
feel
this
should
be
a
decision
made
by
the
team
because
it
doesn't
just
affect
issues
but
epics
and
various
other
parts
of
the
product.
My
thought
is
that
eventually
we
would
want
to
have
the
ability
to
create
kind
of
a
blank
slate
item
and
give
the
user
the
ability
to
define
its
type.
I
think
this
goes
into
gabe's,
long-term
vision
for
extensible
issues,
giving
them
the
ability
to
kind
of
customize
that
page
layout,
for
that
particular
type.
A
That's
my
thought
on
it
and
that
whenever
you
go
to
a
list
of
things
see,
I
think
also.
This
could
change,
though,
how
you
filter
things
like
it
could
change
so
much
in
terms
of
really
creating
a
good
user
experience
when
you
think
that
far
out
for
thinking
a
little
more
short
term,
I
would
expect
that
if
you
go
into
an
issue
list,
this
would
be
a
good
case,
I
suppose
for
going
to
new
and
then,
when
you
start
to
create
that
new
work
item,
it
defaults
to
maybe
an
issue
same
with
epic.
A
You
go
into
epic
list,
click
new.
You
know
similar
situation
we
default
to
it,
but
if
they
choose
to
change
it
to
something
else,
they
could
I'm
saying
this
on
the
fly,
though,
I
could
also
see
there
being
some
weirdness
for
users,
like
I'm
in
the
epic
section
and
I'm
creating
an
issue.
Is
that
it's
different
from
what
I
thought
you
know.
So
I
want
to
think
through
that
a
little
bit
more
and
see
what
maybe
the
gotchas
could
be
in
that
for
the
user.
E
Yeah,
I
ideally,
I
think
we
would
want
to
taking
the
consideration
the
context
in
which
a
specific
work
item
is
created
right.
If
you
are
an
epic
list
by
default,
one
probably
want
to
create
an
epic,
but
then
I
also
have
the
option
to
change
that
type
while
creating
to
an
issue,
because
because
it's
possible
right,
you
can
have
issues
underneath
epics.
E
A
A
E
Like
I
don't
see
us
changing
it
in
a
very
like
near
future,
changing
all
the
buttons
from
new
issue,
new
incident,
new
anything
to
new
work
item.
I
don't
think
at
least
I
don't
think
that's
mvc.
This
is
where
I
think
it's.
It
becomes
like
very
confusing
in
a
way
because
you
click
new
issue,
but
then
you
create
an
item
that
I
I
don't
know
how
that
works
out
from
ux
perspective.
This
is
why
I
was
more
thinking.
E
F
E
Maybe
we
can
do
something
like
keep
the
bottom
new
requirement,
but
then
the
the
form
actually
says
work
item
or
something
and
then
the
type
is
selected
as
as
requirements.
Maybe
that's
a
way
to
introduce
slowly
the
work
item
concept.
I
don't
I
don't
know.
A
I
don't
need
dates
or
anything
like
that,
but
just
what
we
anticipate
to
accomplish
between
now
and
then
that
would
help
me,
because
these
are
all
great
points
and
questions,
and
I
don't
want
to
speak
for
alexis,
but
I
would
imagine
it
would
be
beneficial
to
her
as
well
to
think
about
all
the
various
connections
that
might
need
to
be
made,
such
as
context
when
making
these
decisions
I'm
happy
to
take
a
stab
at
it
and
see
if
that
would
be
helpful,
but
would
that
be
beneficial
to
anyone
else?
E
Yeah,
I
think
that
would
be
helpful
that
will
help
us
align
into
like,
because,
like
it
seems,
we
are
going
back
and
forth
a
lot
between
the
what
we
want
to
do
now
and
what
we
want
to
do
next,
and
that
seems
to
me
at
least
that
it
shows
what
what
you
just
said.
We
don't
have
these
kind
of
milestones
or
phases
longer
phases
where
this
is
where
we
need
to
get.
How
do
we
get
there
right
so
that
that
would
be
helpful?
I
think.
B
We
did
have
to
start
with
some
of
what
kirsten
had
put
together,
but
it
sounds
like
there's
other
things
to
consider,
so
I
can
pass
this
on
to
gabe
and
kristen
first
to
collaborate
on
that.
If
there
are
specific
things
that
you
want
to
be
considered
in
this
iterative
plan,
maybe
we
can
start
just
inventorying.
Those
in
slack
and
just
say
like
here
are
the
things
that
I
like
from
you
holly
from
your
perspective
and
alexis
from
your
perspective.
Anybody
else
right.
B
A
I
think
that's
are
you
referring
to
the
nbc
one,
epic,
yes
and
q,
and
three
yeah?
I
I
think
that
was
that's
been
super
helpful
and
it's
been
a
great
place
to
start.
It
gets
fuzzier,
though
obviously
the
further
out
it
goes
and
then,
where
it
becomes
harder
for
me
to
try
to
understand
what
questions
I'm
going
to
have,
because
I
think
so
much
could
still
potentially
change
between
now
and
then
so
maybe
some
of
it
is
just
a
matter
of
settling
into
that
discomfort
and
dealing
with
the
the
iterative
process.
A
You
know
that
that
kind
of
happens
there,
but
any
any
insight
that
we
have
already
as
to
what
that
long-term
vision
could
be,
is
just
helpful
in
getting
those
questions
answered.
I'll
put
them,
though,
in
those
epics
as
those
questions
arise,
that's
probably
the
best
way
to
go
for
now.
Just
to
you
know,
keep
everybody
in
the
loop.
B
B
E
My
first
question
is:
when
do
we
start
introducing
the
work
item
in
the
ui
like
work
item
as
a
phrase
as
a
as
an
object
as
a
whatever
you
want
to
like?
When
does
the
user
start
interacting
with
an
arc
item
as
it
as
it
is
because,
like
we
want
to
make
it
smooth,
but
I
don't
know
if
that
will
work
or
it
will
be
not
confusing,
or
do
we
rather
still
use
the
specified
types
like
requirement
issue
incident?
E
What
not
and
then,
when
we
have
this
new
ui
for
the
work
items
where
you
can
change
the
types
in
between
and
all
that
worked
out,
then
we
do
some
sort
of
a
release,
some
sort
of
an
announcement
that
now
we're
going
to
use
this
work
item
versus
all
the
different
types
like.
I
don't
know
how
that
plays
out
because,
like
otherwise
to
when
I
I'm
not
a
new
accent,
I
feel
like
there.
B
Yeah,
we
already
have
the
start
of
some
of
that
with
issues
right,
because
you
can
select
the
type
right,
but
I
see
I
definitely
see
your
point
of
like
if
we're
gonna
have
new
terminology,
if
we're
going
to
have
a
new
yeah,
almost
like
model
where
these
things
are
more
together
right.
What
does
that?
Look
like
long
term,
like
one
question
that
I
myself
have
is
right
now
requirements
are
in
a
separate
part
of
the
ui
all
together
like.
B
B
So
yeah
I'll
talk
to
gabe
and
kristen
about
this
when
they're
back,
because
definitely
like
we'll
need
their
input
on
this,
and
thanks
for
the
link
on
story
maps
I'll
take
a
look
at
that
to
see.
If
that's
what
I
want
to
use,
I've
done
story
maps
in
the
past
and
they
are
useful.
I
agree.
G
A
A
What
I
would
want
to
understand,
though,
is
what
the
user's
mental
model
is
of
relationships
with
these
particular
items.
Does
it
differ
between
certain
items?
If
so,
why?
So,
obviously
the
ux
roomie
has
questions
about
that
experience,
but
my
short
answer
would
be.
I
think
it
could
be
any
of
those
things.
B
Yeah,
so
I
do
not
think
of
them
as
children
or
parents
related
in
that
way.
When
I
think
children
parrot,
I
think,
of
a
work
breakdown
structure
right
where
you're,
taking
like
a
big
thing
and
breaking
it
down
into
tiny
things
and
then
rolling
it
up,
and
I
think
of
these
other
things
as
like,
related
kind
of
like
how
we
have
that
today.
G
F
Yeah,
it's
colored,
but
by
knowing
the
way
that
these
are
implemented
on
the
back
end
but
yeah,
I
just
kind
of
think
of,
and
this
like
came
up
at
the
start.
When
we
first
started
thinking
about
this,
I
kind
of
see
them
as
the
same
as
in
like
it's
a
directional
relationship.
In
the
same
way,
that
blocking
is
a
directional
relationship
like
in
the
ui.
You
can
have
an
issue
blocked
by
another
issue,
but
on
the
back
end
we
store
a
blocking
relationship.
F
That's
directional!
It's
not
two
different
things.
It's
one
thing:
it's
the
direction
of
the
relationship
that
defines
whether
an
issue
is
blocked
by
or
blocking,
but
it's
the
same
thing
and
then
you
have
related,
and
I
see
sort
of
child
parent
as
just
another
type
of
relationship
between
two
work
items.
E
I
I
agree
on
the
back
end:
that's
how
we
implement
it,
but
like
to
me
in
in
your
why,
when
you
say
something
is
dependent
on
on
something
else,
I
would
see
them
like
structurally,
at
least
in
a
sort
of
a
three
structure
as
being
child
items,
because
then
for
me,
it's
easy
to
visualize
that
all
of
these
child
items
somehow
roll
up
to
this
parent
just
because
they
are
dependencies
and
then,
if
there
is
a
different
relationship,
just
things
relate
to
one
another.
They
not
necessarily
have
to
be
child
items.
E
They
just
just
are
related
in
one
way
or
another,
but
when
I
like,
or
to
put
it
in
a
different
way,
when
I
think
of
child
items,
I
almost
always
think
that
they
do
have
some
sort
of
a
dependency
on
the
parent
or
the
other
way
around
right,
so
at
least
like
visually.
This
is
easier
for
me
to
visualize
that
well,
these
things
are
dependent
on
this.
This
higher
up
item
right,
yeah,
I
don't
know.
E
Yeah,
I
don't
to
me,
there
is
no
difference
to
me.
The
related
item
is
something
that
does
not
affect
the
parent
in
any
way.
So
this
is
where
because
like
on
back
end,
this
is
still
the
same
relationship.
Just
we
we
we,
we
changed
the
type,
the
same
thing,
which
is
the
type
of
the
relationship,
but
it's
still
same
thing
same
data
structure
in
the
database,
but
like
from
a
user
perspective
from
a
visual
perspective.
E
If
this
is
dependent
on
them,
it
affects
the
patterns
in
one
way
or
another,
maybe
just
it's
hard
linked
to
that.
It
has
to
be
done
before
the
parent
is
done
and
it
has
some
sort
of
an
influence.
But
then
also
the
pattern
can
be
related
to
some
issues.
That
just
has
some
discussion,
but
has
nothing
to
do
with
the
completion
has
nothing
to
do
with
the
way
it
has
nothing
to
do
with
all
other
stuff
of
the
parent
right.
G
That
makes
sense
like
it's
not
necessarily
related,
but
it
just
needs
to
be
completed,
but
not
necessarily
completing
the
items
within
that
item.
That's
blocking
the
current
item.
They
won't
necessarily
like
transfer
over
and
help
complete
the
current
work
item.
You're.
Looking
at
it's
just
that
they're
a
step
before
that
needs
to
be
completed.
G
It
could
be
totally
unrelated,
so
it's
kind
of
like
related
versus
not
related
dependencies.
Almost
maybe
that's
the
I
don't
know
it's
all
the
same
terms,
my
brain.
It
makes
sense
in
my
brain,
but
not
when
I
talk
about
it,
but
I
I
think
the
way
you
talked
about
alexandria
like
helped
me
click
that
so
thank
you.
B
I
was
just
looking
through
because
I
used
to
use
this
when
I
was
a
project
manager,
road
monk.
It's
like
a
road
map,
visualization
tool.
I
like
running
yeah,
there's
a
bunch
of
versions
of
this
right,
but
I
was
just
looking.
They
also
treat
like
the
work
breakdown.
B
You
would
see
that
sort
of
like,
on
the
left
hand,
most
side
and
you
sort
of
like
create
children
issues
within
it,
and
then
dependencies
are
separate
where
you
like
actually
link
to
issues
and
how
they
show
that
even
visually
on
the
roadmap
is
different,
where,
like
parent
children
are
sort
of
like
roll-ups
and
dependencies
are
lines
between
things
and
related
to
me
is
sort
of
like
an
arbitrary
thing
right.