►
From YouTube: Dev:Manage/Plan/Ecosystem UX Design Reviews - 11.22.21
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
B
B
C
C
A
I
don't
know-
and
I
I
have
two
versions
of
it
on
my
calendar.
One
is
red
and
one
is
blue,
which
I'm
guessing
one
is
like
a
shared
calendar
and
one
is
not
I'm
afraid.
I'm
gonna,
edit
the
shared
one
and
maybe
that's
mike,
was
originally
the
one
that
created
it.
So
it's
even
weirder,
but
it
looks
like
maybe
I
did
the
updated
version.
So
let
me
see
if
I
can
change
it
so.
A
A
B
A
C
C
D
A
That's
fine
with
me
as
well.
If
we
need
to
wrap
it
up
a
little
earlier,
we
can,
if
not
we'll,
have
five
extra
minutes-
okay,
so
just
yeah
so
daniel.
Just
to
recap
for
you,
we
were
just
extending
it
kind
of
having
the
conversation
of.
Do.
We
need
a
little
more
time
or
did
we
just
roll
over
the
conversations
from
week
to
week?
So
that's
just
kind
of
what
happened
there
and
let
me
see
if
there's
is
there
anything
else
that
I'm
missing
from
labor's
fred.
A
C
Maybe,
while
you're
looking
that
up,
I
could
ask
a
question
that
I
recalled
from
last
week
that
I
meant
to
ask
but
forgot
to.
Is
there
a
unique
slug
or
like
character
to
delimit
a
task
like
we
use
the
hashtag
or
the
ampersand
for
like
epics
and
issues?
Is
there
going
to
be
one
for
testing
they're
just
going
to
use
the.
C
C
A
Be
eventually,
but
I
think,
that's
still
an
ongoing
discussion,
because
I
believe
that
will
be
tied
to
work
items
as
a
whole,
since
the
task
is
really
kind
of
the
first
version
of
a
work
item.
So
just
to
give,
I
don't
remember
if
I
went
into
this
last
week
or
not,
but
just
to
give
a
little
background.
Work
items
has
changed
where
the
first
version
of
a
work
item
we
are
going
to
offer
is
a
task
which
would
be
a
child
element
of
an
issue,
and
this
actually
this
particular.
A
A
So
one
of
the
things
that
we're
exploring
is
is
there
value
in
showing
more
information
as
it
relates
to
that
issue,
and
I
think
the
long-term
goal
will
be
to
show
different
versions
of
work
items,
but
it's
kind
of
surfacing
right
now
as
issue
types.
So
in
option
a
here.
This
is
just
showing
a
couple
of
different
versions
of
how
this
might
look
and
the
way
that
people
can
control.
This
is
by
going
to
do.
I
have
this
issue
handy.
A
A
Should
it
show
the
the
comment
here
associated
with
the
information,
or
is
there
more
or
less
detail
that
people
would
like
to
see
as
it
relates
to
the
issue?
So
what
I'm
trying
to
think
through
is.
I
believe
that
context
is
very
important
here.
I
don't
want
to
just
show
people
three
different
ways
to
view
this
information
and
tell
them
what's
going
on.
A
A
B
C
Be
anything
so
just
imagine
like
a
in
the
description
or
in
a
comment.
Someone
puts
the
mark
down
for
check
boxes
right.
I
probably
think
the
area
you
would
most
commonly
see
this
used
would
be
like
in
our
okr
issues
when
there
are
like
seven
check
boxes
for
each
group
or
each
stage,
and
sometimes
they
link
to
an
issue,
but
sometimes
they're.
Just
like
a
task
for
one
of
the
people
to
take
on
it
could
really
be
a
mixture
of
things.
Right
is
that.
A
But
when
you
do
copy
and
paste
a
link
to
something
currently
to
an
issue
or
to
an
mr,
it
resolves
very
much
like
this,
where
it
just
shows
the
id
and
then
the
symbol
associated
with
it.
So
we're
exploring
showing
a
little
bit
more
information,
and
that
might
be
again
the
title
it
might
be
to
show
an
icon
to
show
the
status
or
maybe
to
show
the
type
of
element
and
then
also
potentially
a
label.
A
We
wouldn't
show
both
a
label.
Well,
we
might
show
a
label
and
an
icon.
That's
something
else!
We're
thinking
through
this
icon.
Here,
though,
is
being
used
currently
to
show
open
and
closed
for
issues,
so
we
would
probably
have
to
change
that
a
little
bit
and
it's
probably
redundant
also,
if
you're,
showing
the
the
status
down
here
as
far
as
closed
or
not.
D
D
A
C
So
I
think
today
it
would
be
mostly
just
issues,
maybe
epics,
but
the
other
things
aren't
either
used
much
or
they
don't
exist
yet
so
we
wouldn't
be
able
to
quite
discern
when
tasks
would
show
up.
I
guess
we
could
like
look
at
our
own.
Metadata
might
be
a
little
bit
hard
to
tell,
but
I
think
about,
like
our
ux
research
issues
and
task
lists,
like
sometimes
it's
like
where's
the
issue
for
your
recruiting
request.
But
then
the
next
thing
is
like
create
a
script
like
you,
don't
need
an
issue
for
that.
D
C
A
Yeah
see
one
of
the
challenges
that
we're
having
in
plan
is
that
our
primary
user
is
the
product
manager
and
we
receive
a
lot
of
feedback
from
product
managers.
Saying
I
feel
like
this
product
is
created
for
someone
who
has
a
strong
technical
background,
and
I
don't
always
feel
like
one
of
the
most
interesting
pieces
of
feedback.
I
heard
one
time
from
a
product
manager
was.
C
C
A
However,
I
can
see
there
being
value
in
preparing
for
tasks
coming
down
and
the
fact
that
we
will
offer
people
the
option
to
convert
a
checklist
item
to
a
task
as
part
of
our
mvc4
tasks.
So
I
think
that
this
is
initially
going
to
be
related
to
that,
but
I
don't
want
to
just
add
more
stuff
to
the
ui,
unless
I
know
that
it
is
valuable-
and
I
want
to
understand-
is
this
the
time
that
it's
valuable?
A
When
is
it
valuable
and
why
is
it
valuable
in
those
various
places
and
locations
as
well
as
what
else
is
going
to
be
affected
by
this
decision?
Is
this
going
to
impact
mrs
and
incidents?
I
assume
we
would
have
to
do
the
same
setup
in
each
of
those
areas
and
are
they
going
to
then
also
adopt
this,
this
process
of
showing
title
or
status
or
whatever,
when
their
links
resolve
for
epics?
And
mrs
and
things
like
that.
So
that's
where
it
becomes
a
bigger
question.
I
think
in
the
issue.
A
A
C
Oh
yeah,
that's
all
it's
all
really
good
stuff
I'll
share
my
thoughts
and
I'd
love
to
hear
more
from
like
gleeborn
daniel
on
it
too.
I
think
it
can
be
really
easy
to
over
bias.
The
focus
on
can
you
discover
which
of
these
items
in
a
list
is
a
task
versus
an
issue
which
I
think
is
like
an
important
distinction.
C
So
I
almost
lean
towards
the
fact
of
seeing
how
little
you
can
get
away
with
and
then
start
like
being
more
solutionized
you're,
starting
with
that
very
very
small
thing
and
then
waiting
for
people
to
say
I
I'm
having
a
hard
time
distinguishing
between
issues
and
tasks
in
the
list,
so
if
it
was
simply
just
that
they
look
the
same,
but
when
you
hover
over
them,
the
pop
over
distinguishes
between
an
issue
versus
a
task
cool.
So
it's
still
discoverable.
It's
just,
maybe
not
screaming
at
you
as
you're
scanning.
C
What's
the
main
task
that
we
would
assume
users
are
trying
to
do
in
an
issue
or
a
merge
request
in
an
epic
and
then
like?
What's
the
smallest
ui
change
that
we
could
get
away
with,
that,
still
like
meets
good
like
design
principles,
but
also
is
at
least
creating
some.
You
know
distinguishing
feature
between
them
without
like
adding
an
icon
and
a
badge
and
a
new
anchor
tag
and
additional
details
like
just
because
we
end
up
in
a
situation
where
there's
so
much
in
the
ui
and
now
we've
created
more
for
the
user.
A
Yeah,
I
completely
agree
with
you.
I
would
much
prefer
to
start
simply-
and
I
always
tell
my
students
this
too
start
simply
because
you're
always
going
to
add
in
stuff
later
and
it's
harder
to
remove
something
from
the
ui
when
people
have
become
used
to
seeing
it,
even
if
it
doesn't
necessarily
provide
value
it.
It
shuffles
up
their
routine
for
things
to
be
moving
around
and
changing.
A
So
I
would
prefer
to
go
simply
an
add-on
as
needed,
rather
than
show
all
the
things
and
then
potentially
find
that
they're
not
valuable,
but
now
they're
there
and
you
gotta
have
the
conversation
of
removing.
So
thank
you
so
much
for
that
feedback.
I
I
personally
I
agree
with
you.
I
would
love
to
hear
what
libor
and
daniel
think
as
well.
If
you
all
have
thoughts
on
it,.
D
B
Ahead,
I
had
a
question.
I
was
wondering
if
it
would
be
better,
you
know,
instead
of
showing
some
of
the
lorem
ipsum
in
order
to
get
better
feedback.
Maybe
just
set
it
up
in
more
of
like
a
story,
just
put
it
into
a
little
bit
more
context
like
show
me
what
an
actual
list
would
look
like.
Maybe
in
an
issue
too.
D
That's
kind
of
the
problem
that
I
had
like
I
was
going
to
ask
because
I
asked:
can
I
see
this
in
context,
and
I
think
that
was
what
I
was
trying
to
get
to
not
just
this
but
like
in
the
bigger
picture
like
within
the
whole
issue.
I
don't
think
it
would
add
much,
but
it
would
definitely
help
put
you
already
into
the
the
place
where
it
should
be
mentally,
just
in
terms
of
what
austin
had
said
about
reducing
the
complexity.
D
First,
that's
really
fair
to
say
I
my
the
the
thing
that
I
brought
up
earlier
about
the
icons
instead
of
the
the
pound
or
the
other
symbol
in
front
that
could
help.
But
I
would
say
that's
up
for
debate.
I'd
want
to
ask
users
if
you
switched
that
out
with
an
icon
or
something
would
that
kind
of
help.
This
process
like
as
an
mvc
or
something
I
wouldn't.
A
A
A
D
If
you
just
copy
paste,
the
whole
link
it'll,
actually
truncate
the
whole
link
to
just
be
the
hashtag
with
the
number
so
there's
a
weird
like
behavior
there,
that's
not
assumed
or
understood
like.
I
saw
that
on
an
issue
earlier
I
tried
to
edit
the
link.
I
was
like
wait
a
minute:
it's
not
a
link,
it's
a
pound
and
a
number
within
the
markup.
I
was
like
oh
yeah.
I
forgot
we
could
do
that.
A
D
A
D
D
C
C
D
A
The
whole
url
and
paste
it
because
there's,
I
guess
some
sort
of
quiet-
fear
in
me
that
I'm
going
to
be
in
the
wrong
project
and
get
the
wrong
id,
because
I'm
in
a
different
project
than
what
I
normally
would
be
in.
But
I
don't
know
that
most
of
our
users
would
have
that
problem,
because
they're
probably
only
associated
with
one
or
two
key
projects,
and
we
use
you
know
a
few
different
ones
for
different
things.
B
D
What
we
did
the
migration
from
ee
or
ce,
or
something
like
that,
so
all
the
links
change
everywhere
does
that
cause
anything
to
go
wonky.
That's
just
my
ideas
that
I'm
throwing
out
in
terms
of
like
using
this
shortcut
and,
like
I
said
like
I
didn't
even
remember,
the
shortcut
existed
that
you
could
just
type
hashtag
two
and
it
would
be
there.
C
A
A
B
C
C
C
B
Do
now
thinking
about
it,
what
we
do
is
we
check
if
it
is
the
jira
id
in
the
beginning,
because
you
have
to
reference
the
I
you
prefix,
the
your
issue
with
the
id
or
the
branch
that
you're
on
so
so
once
that's
prefixed,
you
know
we
could
do
a
lookup
and
see
okay,
that's
a
jira
issue.
All
we
do
is
just
make.
We
just
make
it
a
link.
B
Yeah,
definitely
I'm
glad
you
bring
that
up
holly,
actually,
the
work
I'm
doing
right
now
on
the
for
the
slack
integration,
I'm
doing
something
similar
to
a
similar
exercise
where
I'm
trying
to
figure
out.
What's
the
most
minimal
kind
of
thing
we
could
show
about
an
issue
once
it
gets
unfurled
in
slack.
A
Somebody
was
telling
me
the
other
day
that
they
hate
when
they
need
to
know
if
someone's
just
responded
with
like
a
yes
or
no
or
looks
good,
you
know
and
they
don't
need
to
see
a
full
context,
but
just
having
that
detail
without
having
to
leave
their
current
context
would
be
great
and
showing
a
little
preview
could
help.
With
that.
I
don't
want
to
hog
up
all
the
time.
I
know
we're.
We've
got,
I
guess
a
few
minutes
left,
but
thank
you
all
so
much
for
the
feedback.
I
appreciate
your
help.
D
A
A
C
A
A
D
A
C
Yeah,
oh
yeah.
The
way
I
think
about
it
is
like
some
of
those
admin
features
that
are
driving
the
experience
of
a
namespace
will
kind
of
live
in
the
workspace,
but,
like
daniel
said,
I
guess,
technically
speaking,
the
workspace
itself
is
a
namespace
that
can
contain
other
namespaces,
which
we
more
traditionally
would
refer
to
as
groups
and
projects.
A
I'm
looking
forward
to
it,
I
love
that
she
put
this
disclaimer
and
by
the
way,
I
feel
like
everything
related
to
work
items
should
have
this
like
just
fyi.
This
is
just
used
for
conversational
purposes
and
not
necessarily
a
final
version
of
the
design
work,
so
I'm
gonna
just
for
time
sake
I'll
just
focus
on
the
mvc
solution.
Here
it
looks
like
there
are
a
ton
of
designs
which
I
I
am
always
blown
away
at.
How
amazing
alexis
is
at
showing
her
design
process.
A
C
A
A
A
A
A
An
incident
also
has
nothing
below
it
same
with
requirement
and
test
case,
but
my
understanding
is
that
eventually
you
can
have
a
work
item
that
could
have
any
of
these
four
elements
as
child
elements
and
then
we'll
continue
to
add
on
and
eventually
users
can
create
their
own
versions
of
work
items
and
define
them
as
what
they
want.
Give
them
icons.
You
know
to
address
them
as
they
want
to
in
the
ui.
B
C
An
issue
can
live
within
an
epic
or
an
epic
can
live
like
within
an
epic
and
so
on
so
forth,
but
there's
a
hierarchy,
kind
of
mapped
out.
I
don't
know
if
maybe,
if
there's
going
to
be
an
interaction
to
change
your
hierarchy
at
all,
but
it
feels
to
me
more
like
a
documentation
page
where
it's
like
educating
you
on
the
information
architecture
of
gitlab.
C
A
I
see
what
you're
saying,
though,
because
I
guess
I
made
an
assumption
when
I
first
looked
at
this,
that
this
was
just
kind
of
maybe
heard
documenting
for
our
discussion
purposes,
but
now
that
you
mentioned
it
you're
right.
Maybe
this
is
a
proposal
kind
of
like
an
empty
state
document.
Maybe
that
shows
because.
A
Yeah,
that
makes
sense.
I
can
see
that
as
well.
Well,
let
me
just
go
back,
which
I
I
have
an
issue
by
the
way.
In
case
I
don't
know,
if
anybody's
interested
in
this
or
not,
but
every
time
I
open
an
image
that
is
not
in
design
management.
It
opens
in
the
same
window,
and
that
makes
me
crazy
because
sometimes
I'll
close
it
thinking
that
it
has
opened
in
a
new
window.
So
I
have
an
issue
out
there
to
change
that,
so
that
it
always
opens
them
in
a
new
window.
C
Yeah,
I'm
also
kind
of
slowly
going
through
some
other
ones,
there's
one
that
has
like
a
the
available
work
items
and
you
can
toggle
on
whether
or
not
they're
visible
with
some
promotional
stuff
telling
you
what's
coming
soon.
So
that
feels
like
maybe
like
a
settings
page
where
you
can
customize
the
look
and
feel
of
your
gitlab
namespace
or
maybe
it
is
a
workspace
configuration
option.
I
think
it's
just
trying
to
help.
You
understand.
C
C
C
A
A
A
little
workout
yep
that
looks
like
settings
to
me
and
this
is
showing
the
different
types
currently,
and
this
is,
I
guess,
showing
if
something
is
a
parent
sibling
or
child,
or
maybe
that
it
has
yeah
so
like.
But
this
indicates,
if
I
understand
this
correctly,
it
seems
to
indicate
that
a
test
case
can
have
a
child
which
is
not
what
was
on
the
other
page.
So
maybe
I'm
misunderstanding:
that
of
project
level
object
that
nests
under
appearance
satisfies
requirements.
C
A
Yeah,
that
makes
sense,
and
it
is,
I
think
it
actually
is
a
child
element
of
a
requirement
in
the
visibility.
So
that
would
be
the
settings
and
I'm
curious.
What's
in
this
delete,
name
general
actions,
it
looks
like
related
to
that
aspect
coming
soon
features
and
tasks
yeah.
So
that
looks
like
just
settings
information.
I
think
this
type
section
there
for
me
is
still
a
little
confusing,
but
the
description
helps.
Visibility
is
clear.
To
me,
menu
is
clear.
Anybody
else
have
any
questions
or
thoughts
about
this
view.
B
A
A
B
C
C
A
This
is
interesting.
We're
down.
We've
only
got
a
minute
left,
but
in
this
case
it
looks
like
there's
a
separate
hierarchies
tab
and
I
don't
know
if
that
would
just
be
information
or
if
you
can
actually
somehow
change
and
manipulate
hierarchies
associated
with
work
items
here.
But
that's
really
interesting.
I'm
curious
about
that.
If
that's
functional
or
just
information.
C
B
C
D
Yeah,
it's
still
a
technical
concern
right
now,
so
it's
not
really,
you
know
defined
so
to
speak,
just
as
you
mentioned
like.
How
would
this
look
like
it's?
It
would
arguably
look
the
same
across
from
whatever
level
you're
at
until
you
reach
a
certain
lack
of
visibility.
So
if
you're
like
six
levels,
deep
you'll
see
theoretically
six
five
things
above
your
level,
so
if
you
get
to
the
very
top
you're
only
gonna
see
the
one
thing
where
you
exist
that
so
there
wouldn't
be
anything
below
it.
A
A
D
D
D
A
I'm
glad
you
mentioned
that
because
it
does
have
sometimes
we
do
have
a
tendency
to
maybe
over
complicate
things
for
the
smaller
organizations
while
trying
to
address
the
needs
of
the
more
complex
situations
associated
with
enterprise.
Well,
I
know
we're
a
couple
minutes
over,
but
anything
else
anybody
wants
to
touch
on
today
before
we
wrap
up.
This
was
great.
Thank
you
all
so
much
for
your
feedback
on
tasks.