►
From YouTube: UX Showcase Work Items and Tasks
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
All
right
well
for
those
I
haven't
met
yet
nick
leonard
I
joined
around
the
same
time
as
as
mike.
I
did
not
have
the
sense
to
also
just
call
this
the
the
the
first
90
days
of
work
items,
but
I
think
similar.
A
This
has
been
an
open
sort
of
initiative
for
for
much
longer
than
I've
been
working
on
it,
and
so
I've
inherited
a
lot
had
to
get
up
to
speed
on
a
lot
and
and
have
been
kind
of
working
to
kind
of
make
some
of
the
first
iterations
of
this
possible.
So
we'll
talk
a
little
bit
today
around
some
of
that
background.
What
we're
trying
to
do
and
then
kind
of
where
we're
at
right
now
and
I'm
stuck
in
the
basement,
because
I
have
contractors
here.
A
So
apologies
if
you
hear
really
horrible
metal
grinding
in
the
background.
A
So
what
is
a
work
item
so
work
items
are
essentially
an
iteration
of
issues
or
issue
types.
I
think
it
actually
started
out
of
issue
types
and
kind
of
realized,
some
of
the
limitations
of
that
not
to
mention
the
confusion
that
I
think
we've
all
probably
experienced.
Of
you
mean
an
issue.
Is
both
an
issue
and
an
issue
type?
A
It's
the
name
of
the
primitive
and
the
type,
and
it's
very
confusing
from
a
just
information
architecture
perspective
so
relabeling
that
I
think
work
items
which
exist
kind
of
just
as
the
primitive
name
as
opposed
to
being
a
type
and
they
serve
to
catalog
work
to
be
done.
A
So
they
are
kind
of
the
essential
planning
object
in
the
future
and
they'll
be
defined
by
types
so
similar
to
issue
types
but
not
called
work
out
of
types
and
the
types
will
define
which
widgets
are
present,
so
it's
essentially
a
platform
or
framework
that
can
have
multiple
different
variations
or
types
that
each
hold
different
information
which
is
held
by
these
these
widgets.
So
just
a
little
note
on
terminology,
this
is
a
little
bit
small.
Let's
see
if
I
have
it
open
here,
there's
a
lot
of
confusion.
A
I
think
within
our
team
working
on
this
in
project
management,
and
so
I
can
only
imagine
for
folks
who
don't
see
this
all
the
time
as
to
what
what
is
what
what's
a
workout
type.
What's
the
issue
was
issue
issuable,
like
these
terms,
get
thrown
around
a
lot.
It
took
me
a
while
to
kind
of
get
up
to
speed
on
it,
so
we
made
this
nice
little
table
of
terminology
in
the
work
items,
docs
page,
so
you
might.
A
If
you
start
hearing
like
legacy
issue
view,
we've
tried
to
start
using
that
to
refer
to
anything.
That's
in
the
current
issue
view
so
like
issues
today
are
still
in
the
legacy
issue
view
as
opposed
to
work
items
or
work
out
in
views
right
now.
Tasks
are
the
only
thing
that
exists
as
an
actual
work
item.
A
Everything
else
is
still
like
on
the
issue
model
and
you
know,
is
sort
of
further
out
to
get
kind
of
ported
over,
but
so
you'll
see
these
kind
of
intermixed,
workouts,
specifically
kind
of
means
future
state
issue
or
legacy
issue
view.
Basically,
that's
the
status
quo
for
what
exists
outside
of
tasks.
A
So
why
workout?
So,
I
think
the
the
biggest
part
of
this
is
really
a
bit
of
a
re-architecture
that's
happening
on
the
back
end,
to
bring
all
these
things
into
standardization.
I
think
right
now.
What
we
found
is
that
there's
a
lot
of
cases
where
one
update
actually
ends
up
being
four
updates,
because
a
lot
of
these
things
that
are
built
on
issues
a
lot
of
the
widgets
are
a
bit
more
piecemeal.
A
So
the
thing
that
exists
on
an
epic
might
not
be
the
same
as
what
exists
on
the
issue
and
you're
updating
things
twice.
Just
you
know
also
might
mean
there's
a
different
user
experience
between
those
things
in
a
way
that
isn't
necessarily
intended.
A
So
I
think
a
lot
of
the
the
origin
of
this
came
out
of
this
effort
to
streamline
those
make
it
sort
of
one
update
instead
of
five,
but
then
also
to
provide
some
greater
flexibility
and
that's
flexibility
both
I
think
for
us
to
build
new
types
and
offer
new
functionality,
but
also
potentially
for
customers.
A
I'll
talk
a
little
bit
more
on
the
next
slide
about
what
exactly
flexibility
means,
since
that
could
mean
kind
of
a
lot
and
then
easier
to
adopt.
So
one
of
the
challenges
that
we
have
on
on
project
management
is
that
you
know
a
lot
of,
especially
the
bigger
enterprise.
Customers
have
a
very
kind
of
well-established
way
in
which
they've
tracked
their
work
and
they
want
to
kind
of
bring
that
into
gitlab,
and
it's
not
always
easy
for
them
to
do
that
in
the
current
model.
A
So
a
lot
of
so
sort
of
the
extensions
that
we're
adding
into
work
items
are
to
help
sort
of
make
that
migration
possible
allow
them
to
adopt
the
planning
features
and
not
get
kind
of
stuck
with
with
some
of
the
legacy
issue.
Roadblocks
that
they
experienced
today-
and
all
of
this
is-
is
really
in
order
to
kind
of
enhance
the
planning
tool
set
to
become
the
most
popular
collaboration
tool
for
knowledge
workers
in
any
industry.
A
Right,
like
that's,
the
the
the
plan
planning
extension
of
the
overall
kind
of
git
lab
was
the
the
big
hairy
audacious
goal
so
flexibility.
So
flexibility
can
mean
a
lot
of
things.
I
think
in
this
case,
in
the
near
term,
it'll
mean,
like
I
said,
easier
tools
for
for
gitlab
to
introduce
new
features
on
top
of
work
items.
In
the
long
term,
it
could
mean
more
customer
control
to
kind
of
maintain
their
way
of
working
and
and
manage
things.
A
So
there's
issues
out
there
right
now
for
configurable
statuses,
so
that
would
mean
for
an
issue
right
now.
An
issue
can
be
open
or
closed,
but
maybe
in
the
future
it
could
be
in
progress,
or
you
know,
ready
to
release
or
whatever
it
kind
of
is,
is
useful
for
them.
We
already
use
slightly
different
statuses
for
a
number
of
things
like
incidents
and
requirements,
so
it's
kind
of
just
again
kind
of
making
that
a
standard
model
that
can
be
used
for
different
work
items.
A
Hierarchy
is
a
big
component
that
the
product
planning
team
is
working
on.
That's
kind
of
sits
on
top
of
work
items
and
being
able
to
define
a
flow
from
epics
down
to
issues
down
to
tasks,
or
you
know
kind
of.
However,
they
they
organize
their
work
and
then
visualize
that,
in
a
way
that
allows
them
to
plan
effectively
workflow
that
could
be
in
automation.
Things
like
you
know.
A
We
could
actually
offer
the
capability
with
work
items
in
the
way
that
they're
built
for
customers
to
define
their
own
type.
They
want
to
create
something
that
we
don't
have
out
of
the
box,
that
there
may
be
tools
for
them
to
do
them.
A
That
will
never
be
kind
of
the
the
default
right
like
it'll,
always
be
kind
of
works
out
of
the
box,
but
you
know
we
could.
We
could
eventually
enable
them
to
do
that
with
the
model.
That's
that's
being
created
with
the
goal
of
you
know
allowing
customer
teams
to
spend
more
time
managing
their
work
right
now.
A
lot
of
them
are
kind
of
managing
these,
these
workarounds
and
trying
to
figure
out
how
to
make
tools
like
labels
sort
of
fit.
A
But
it's
it's,
maybe
not
the
experience
that
they're
used
to
coming
from
other
tools
and
it
can
be
a
bit
of
a
challenge
for
them
to
get
up
to
speed
at
times.
A
There's
a
lot
here:
I'm
not
going
to
read
all
this
but
feel
free
to
on
your
own.
These
are
just
some
ux
principles.
A
I
came
up
with
basically
taking
the
general
get
lab
design,
principles
and
just
trying
to
think
through,
like
how
would
I
apply
these
to
work
items
and
like
what
are
some
of
the
work
items,
specific
experience,
goals
that
were
defined,
some
of
them
were
defined
before
I
started,
but
you
know
kind
of
looking
at
those
taking
the
pieces
that
I
thought
were
kind
of
meaningful
and
trying
to
come
up
with
a
set
of
things
that
I
would
think
to
find
sort
of
an
ideal
outcome.
A
So
a
couple
that
I
I'll
just
highlight
here:
one
is
collaborating
in
real
time,
so
the
more
we
can
get
to
that
sort
of
feeling
of
real-time
collaboration.
You
know
the
better
and
as
part
of
that
sort
of
shortening
the
context
to
action
flow.
A
So
why
do
you
use
work
items
it's
typically
to
convey
some
sort
of
context
as
something
that
needs
to
be
done
and
it's
going
to
be
continually
updated
as
as
the
work
gets
done
both
by
you,
but
also
by
the
other
people
in
your
team,
so
whether
you're
coming
to
something
for
the
first
time
and
understanding?
Oh
there's
a
thing
to
do
or
you're
coming
to
it
for
the
100th
time
and
trying
to
catch
up
on
all
the
updates
that
have
been
made.
A
How
quickly
can
we
allow
you
to
see
what's
see,
what's
going
on
update
something
if
you
need
to
and
kind
of
do
the
work
that
you
need
to
do
blossom
I'll
note
here
is
just
iterating
from
familiarity
again
we
have
a
lot
of
customers
into
the
space
that
are
kind
of
ingrained
in
in
some
of
the
tools
that
they
use
and
are
trying
to
migrate
over.
A
This
is
the
smallest
form
of
work
to
be
done,
as
you
can
think
of
it
as
a
child
of
issues
that
actually
will
be
kind
of
the
hierarchy
that
is
set
by
default
and
right
now
in
other
products.
They
might
utilize
this
as
like
a
sub
issue,
or
sometimes
a
task
in
gitlab
today,
these
are
represented
either
as
like
a
linked
issue
or
related
issue
or
like
a
checklist
item,
which
means
that
they're
kind
of
again
those
are
kind
of
ways
to
manage
this,
but
they're
they're
not
exactly
like
trying
to
solve
this
goal.
A
It's
a
bit
of
a
workaround.
You
might
have
a
related
issue
just
because
somebody
tagged
it
in
the
comments
and
it's
not
actually
like
a
sub
issue
of
that
work
item
and
your
checklist
items.
You
know
you
could
you
could
put
whatever
you
want
in
there,
so
this
is
more
of
a
sort
of
first
class
way
to
to
solve
this.
A
A
Things
like
statuses,
things
like
weight
things
like
assignees,
and
then
it
also
extends
this
concept
of
hierarchy
beyond
epics
to
to
actually
kind
of
showcase,
some
of
what's
coming
in
the
future,
so
again
that
whole
model
of
epics
to
iter,
to
issues
to
the
tasks,
I
think
you
know
you'll
be
able
to
start
seeing
that
a
bit
more
clearly
with
some
of
the
components
that
are
coming
out
alongside
tasks
and
with
tasks
as
kind
of
a
representative
object
of
that
hierarchy,
and
then
it
enables
rapid
iteration
without
disrupting
high
volume.
A
Existing
features
like
rather
than
starting
with,
let's
rebuild
issues
as
work
items.
It's
like
great,
the
50
000
issues
that
exist
on
gitlab
are
suddenly
going
to
look
and
feel
a
lot
different.
We
start
with
something
that
doesn't
exist
today,
that
can
kind
of
provide
a
lower
risk
way
to
test,
see,
see
how
people
use
it
learn
from
the
model
and
then
build
out
some
of
that
architecture.
A
A
So
right
now
this
is
out
there
behind
a
feature
flag.
The
workout
is
feature
flag.
It
is
live
on
on
gitlab.org,
so
you
can
use
it
if
you
want
to
I'll
show
you
how
to
do
that
in
a
second.
I
think
right
now
we're
targeting
this
for
fifteen
two
pending
some
cleanup
work
that
we
need
to
get
done
and
I
think,
potentially,
alongside
the
kind
of
first
iteration
of
that
hierarchy,
component,
that
the
product
planning
team
is
working
on
so
again,
you'll
be
able
to
kind
of
see
those
those
relationships.
A
There's
a
lot
of
additional
widgets
in
development
and
some
work
on
the
next
type,
so
the
next
workout
type
would
be
requirements
and
taking.
So
that
would
be
one
that
actually
exists
today,
getting
moved
into
the
workouts
framework
and
then
a
lot
of
kind
of
work,
kind
of
happening
around
work
items
just
in
you
know,
validation.
So,
looking
at
tasks,
how
are
tasks
used?
What
sort
of
feedback
can
we
get
from
tasks,
building
out
primary
workflows?
So
this
create
a
checklist
item
then
didn't
create.
A
A
task
is
not
really
the
long
term
primary
workflow,
it's
kind
of
a
short
term
way
to
do
this.
Eventually,
you
would
be
able
to
actually
create
and
manage
tasks
and
all
their
work
items
through
more
standard
list,
views
moving
into
creation
flows
and
things
like
that.
We
started
with
the
checklist
item.
I
believe,
just
to
again
sort
of
isolate
that
feature
without
having
to
sort
of
and
try
to
embed
it
into
this.
A
This
legacy
process
and
all
that's
still
kind
of
in
progress,
so
maybe
maybe
expect
some
further
updates
in
later
showcases.
A
Okay,
so
let's
take
a
look
at
a
task,
real
quick,
so
I
just
have
a
checklist
here
in
this
issue.
A
couple
of
these
have
already
been
converted
to
a
task,
so
I
can
open
this.
It
opens
in
the
modal
view
right
now.
I
can
come
in
here
and
change
this
sort
of
directly
so
that
shortening
the
context
to
action,
workflow
again
is
like
trying
to
make
everything
sort
of
as
easy
as
possible
just
to
to
edit.
So
I've
changed
my
title.
A
I
can
change
my
status
right
now.
It's
just
open
and
close,
because
we
haven't
really
built
the
full
status
components
out
yet,
and
I
have
a
description
that
I
can
edit
and
change
I
think,
eventually,
in
later
iterations.
We
would
like
this
to
to
also
sort
of
be
more
directly
editable,
there's
a
bit
more
limitations
there,
but
that's
that's
kind
of
where
this
is
going.
A
And
then
you
can
see
that
here
and
and
reopen
it,
there's
not
like
a
direct
connection
between
these
for
various
reasons
that
get
super
complicated
as
to
like.
If
I
check
this,
does
it
change
the
status
and,
and
things
like
that,
I
think
that
will
be
more
clear
as
we
build
out
those
primary
workflows
and
then
one
last
sort
of
note,
so
that's
tasks
as
they
exist
today.
Just
you
know,
starting
to
think
through.
Like
you
know,
what
does
this
mean
for
for
other
things?
A
You
know
this
is
a
bit
more
of
a
vision
for
sort
of
that
real-time
collaboration.
There's
some
work
happening
in
another
single
engineering
group
around
like
real-time
collaboration
and
issue,
editing
it's
like
what
does
what
does
it
all
look
like
when
we
put
these
things
together
and
think
about
sort
of
real-time
collaboration?
A
You
know,
if
you
had
an
issue
in
the
work
items
model
where
you
could
actually
see
you
know
who's
working
on
it
who's.
You
know
what
are
they
working
on
be
able
to
see
extending
sort
of
the
widget
model
from
both
widgets
that
are
more
like
fields,
so
this
is
primarily
what
we're
working
on
right
now
with
just
updating
data,
but
actually
thinking
about
like
more
interac
interactive
widgets,
like
you
know,
a
planning,
poker
sort
of
app
that
can
live
within
the
work
item
and
could
be
reused
in
different
places
for
different
reasons.
A
All
those
pieces
sort
of
coming
together
that's
a
ways
off,
but
that's
kind
of
the
the
direction
in
which
we're
headed.
I
think
that
is
all
I
have
right
now,
but
I
am
happy
to
take
questions.
B
Awesome
I
have
the
first
question.
I
was
curious
if
you
could
give
us
a
sense
of
what
scenario
would
cause
a
user
to
attach
a
task
to
an
issue
rather
than
attaching
an
issue
to
an
epic
or
sub-epic.
A
But
I
think,
if
you
have
the
you
know,
epic
is
sort
of
the
the
feature
level
like
what
are
we
trying
to
do
and
then
the
issue
might
be
broken
down
into
different
tasks
or
different
sort
of
activities
for
different
teams
to
do
those
could
then
get
broken
down
even
further,
so
you
could
have
an
issue
that
might
be
add
assignees
to
tasks
and
you
could
have
tasks
from
there
that
could
be
broken
down
by
maybe
the
discipline,
so
you
could
have
a
task,
for
you
know,
design
the
assignees
thing
and
then
a
task
for
build
the
you
know
endpoint
for
assigning
a
assignee.
A
You
know
that
kind
of
get
divvied
out
at
that
more
granular
level,
that's
kind
of
one
way.
We
expect
teams
to
use
this.
You
could
also
use
that
for
even
more
granular.
So
you
know
one
of
your.
Your
issue
could
be
validation,
research
for
for
your
assignees
and
then
your
task
could
be
schedule.
A
People
by
this
date-
and
you
know,
build
a
session
guide
by
this
state
and
you
can
sort
of
track
the
progress
as
opposed
to
right
now,
where
you
would
probably
have
to
create
just
like
checklist
items
where
you
don't
have
a
discrete
due
date.
You
don't
have
discrete
assignees,
you're
kind
of
just
doing
that
in
the
in
the
markdown.
This
would
allow
you
to
kind
of
bring
that
into
a
more
trackable
and
reportable
way.
D
Yeah
thanks
blair,
can
you
describe
the
experience
perspective
or
point
of
view,
so
in
the
slide
where
you
talk
about
this,
is
why
we're
starting
with
tasks
I
heard
more
about
this
is
technically
feasible.
It's
lower
risk.
What
is
your
perspective
on
the
actual
user
experience?
A
Yeah
well
for
one,
I
think,
there's
a
number
of
customers
that
are
looking
to
to
get
to
this
level
of
more
granular
planning,
so
hopefully
it'll
enable
them
to
kind
of
play
in
their
work.
But
I
think
also
in
terms
of
just
the
different
sort
of
ux
present
four
tasks.
It's
just
a
way
that
we
can.
We
can
test
that
out
and
see.
A
This
is
a
task
that
lives
within
this
issue
without
having
to
navigate
back
and
forth
or
open,
like
you
know,
on
a
customer
call,
as
on
the
other
day
like
talking
about
you
know
how
many
tabs
they
have
open
at
any
given
time
and
kind
of
see
like.
Does
this
actually
solve
and
start
to
solve
the
problem?
Are
they
able
to
use
this
in
a
way
that
addresses
some
of
these
pain
points
that
they're
experiencing
today?
Around
just
having
to
open
so
many
things
to
get
to
context.
D
What
I
guess,
I'm
still
struggling
to
understand
why
we
started
with
tasks
versus
the
other
options
that
are
available
in
work
items.
The
other
types
I'm
probably
screwing
up
the
I
don't
have
the
the
little
cheat
sheet
up
right
now.
A
No,
I
think
workout
types
would
be
would
be
right.
My
understanding
is
is
in
terms
of
task
it's
just
again,
because
it
doesn't
because
it's
new
and
it's
something
that
we
can
sort
of
test
in
a
bit
more
of
an
isolated
fashion,
that
you
know
we're
able
to
both
build
something
that
provides
new
value
as
well
as
kind
of
test
some
of
the
patterns
and
architecture
that
needs
to
exist.
A
For,
for
other
things,
I
think,
in
terms
of
the
ux
it's
more
about
not
making
like
the
the
bigger
disruption
to
you
know
something
like
issues
or
epics
that
are
being
used
sort
of
regularly
all
the
time
today
and
get
something
out
there
that
we
can
get
feedback
on.
E
Yeah
thanks
for
sharing
this
nick,
I
was
just
curious.
E
I
know
we've
had
some
conversation
about
this
and-
and
I
think
one
of
the
mrs
are
issues
but
just
the
consideration
for
inline
editing,
with
consideration
for
accessibility
and
just
in
regards
to
the
rest
of
the
product
when
we're
introducing
a
pattern
like
that
that
would
make
this
just
this
experience
may
be
just
inconsistent
in
the
way
that
in
some
places,
maybe
it
is
editable
and
in
other
places
you
go
to
a
you
know,
into
an
issue
or
elsewhere,
and
it's
it's
not.
A
Yeah,
I
think
I
mean
it's
definitely
a
good
consideration.
I
think
consistency
in
the
experiences
is
probably
our
most
aware,
like
problem
that
we're
gonna
face
in
the
short
term,
because,
especially
with
tasks
being
the
only
work
item,
how
do
we
test
some
of
the
things
that
we
want
to
look
at
from
a
work
out
in
perspective,
but
in
that
sort
of
more
isolated
view
without
having
to
build
every
other
type?
A
It
does
kind
of
lead
to
the
fact
that
tasks
look
and
feel
different
from
the
rest
of
of
of
the
ui
and
even
from
other
things
that
will
eventually
be.
You
know,
work
out.
A
It's
like
like
an
issue,
so
something
that
I
think
is
a
short-term
issue
and
as
we
learn
from
tasks
and
get
feedback
on
there
and
you
know,
build
out
the
additional
work
item
types
it'll
close
some
of
those
gaps,
you
know,
as
other
work
items,
become
more
consistent
with
the
the
work
item
experience
those
those
will
become
more
consistent
with
internally
to
work
items.
I
think
you
know,
as
we
learn
from
the
experience
of
tasks
and
and
build
those
patterns.
A
I
think
you
know
that's
kind
of
where
it
would
really
behoove
us
to
kind
of
see
like
what's
the
relationship
to
not
just
work
items
but
to
the
entire
sort
of
product
experience,
and
you
know:
where
do
we
need
to
either
standardize
or
or
bring
things
into
other
parts
of
the
product
or
where
are
there
opportunities
to
kind
of
feed
things
back
from
work
items
to
to
the
product
at
large?
I
think
accessibility
is,
is
definitely
something
that
you
know.
B
C
Sasha's
talk
in
particular
the
lightning
talk,
so
I
think
we
got
a
few
minutes
to
maybe
do
your
question
or
marcel's
question.
However,
you
guys
want
to
dole
that
out
one
more
question:
I
think.
B
Marcel
you
want
to
go,
some
mine
can
be
async
if
needed.
It's
okay,.
F
Sure
I
didn't
fully
complete
it
yet
so
I'm
just
going
to
do
it
a
bit
more
sync
from
the
existing
types
of
work
items.
We
have
issues,
incidents,
requirements
and
test
cases.
The
vast
majority
of
users
only
use
these
issues
have.
D
A
Yeah,
that's
that's
a
good
question.
I
think
you
know
it
definitely
could
introduce
some
additional
complexity.
I
think
we'd
want
to
manage
that
by
basically
making
smart
defaults.
You
know
much
like
today.
Most
people
use
issues
like
you
know.
Can
we
just
default
in
most
cases
to
you
know,
creating
an
issue
while
giving
them
some
more
of
that
context
around
sort
of
what
that
what
those
other
types
are
and
sort
of
how
they
would
use
it.
A
So
if
they
want
to
extend
their
their
usage,
they
could
or
they
could
just
continue
using
issues
as
they
used
today.
I
I
think
you
know
we'll
want
to
avoid
kind
of
anything
where
we're
forcing
people
to
make
choices
at
every
step
that
you
know
we're
enabling
them
to.
Basically,
you
know
just
use
it
as
default
and,
if
that's
how
they
want
to
operate
or
if
they
decide
as
a
team.
Okay,
we
see
the
value
of
how
we
can
sort
of
utilize.
A
These
different
objects
in
different
ways-
and
you
know,
then
they
can
sort
of
define
how
they
how
they
decide
to
to
use
those
cool
thanks.