►
From YouTube: Work Items Weekly Sync 2021-08-10
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).
B
Oh
so
I
have
the
first
thing,
which
was
last
week
so
john
last
week
we
had
this
meeting
and
one
of
the
kind
of
questions
coming
out
of
that
was
sort
of
what
do
we
need
to
do
to
break
down
mvc0
further
or
just
like
make
sure
that
that
was
all
set
up
for
success,
and
we
had
a
discussion
around
if
we
will
be
able
to
kind
of
deliver
the
default
work
item
types
as
part
of
14.2,
which
led
to
a
additional
discussion
which
I'm
not
realizing.
We
didn't.
B
B
B
C
C
Why
do
we
need
that
table
if
all
work?
If
all
you
know
namespaces
are
going
to
have
all
issue
types,
all
the
hard-coded
types
like?
Do
we
really
need
a
table,
or
can
it
just
be
in
code
and
then
we
can
control
access
to
different
types
like
so
I
had
some
technical
questions
about
that,
but
it
seems
like
that's
probably
more
to
do
with
me
coming
back
off
pto
though,
and
not
having
read
the
technical
discussion
rather
than
it
being
a
bad
idea.
I
just
haven't
seen
it
yet.
B
C
B
From
my
perspective,
it
feels
unlikely
that
we'll
ship
something
that's
like
user
facing
I
mean
we
have
like
made
progress,
and
we
have
the
mr
for
the
table
in
place
and
the
default
types,
mr,
but
I
I
legitimately
don't
have
an
insight
into
the
front-end
side
if
that's
making
progress
or
not
so
I'll
have
to
follow
up
on
that.
But
I
would
you
know,
given
what
I
know
now
I
would
say
it
seems
unlikely
that
we
would
ship
something
that's
user-facing
that
relates
to
work
items.
A
Just
asking,
if
there's
any
technical
questions
or
concerns
from
a
front
end
or
back-end
standpoint
that
would
prevent
us
from
when
ready,
getting
started
with
the
front
end
for
the
new
work
item
view
like
the
base
of
it
wrapper
all
that
good
stuff
and
I'll.
If
you
you,
don't
think
you're
ready,
that's
fine
too.
I
just
was
checking
in
to
see
like
how
I
feel
about
it.
I
haven't
looked
at
it
recently,
so.
D
I
I
feel
like
I'm
ready,
I'm
going
through
and
adding
in
the
annotations.
I
had
had
to
go
back
and
revisit
the
prototypes
and
fill
in
a
lot
of
gaps,
because
I'm
hoping
to
get
some
feedback
from
usertesting.com
on
those
designs.
I
had
created
those
issues
and
had
tagged
anna
and
I'm
kind
of
waiting
to
hear
her
thoughts
on
how
to
move
forward
with
that,
but
I'm
adding
in
the
annotations
right
now
and
not
much-
has
changed
the
only
real
change.
D
I
think,
from
the
last
time
I
had
shown
it
was
the
creation
of
a
modal
based
view
to
try
to
reduce
the
context,
switching,
which
is
something
we've
already
talked
about
previously
anyway,
but
the
other
elements
are
really
the
same,
and
all
of
that
should
be
in
that
issue.
I'll.
Add
it
again
to
the
agenda
that
has
the
design
updates
in
it.
So
if
anybody
has
any
questions
at
any
point,
please
let
me
know.
D
E
E
E
E
And
the
scenario
that
I
went
through
when
I
was
kind
of
running
through
these
different
product
products
was
really
am.
I
able
to
link
things
together
like
work
items
together
and
see
how
they
cascade
up
to
a
larger
initiative
goal
whatever,
because
I
think
that
is
like
one
of
the
larger
jobs
we
could
perhaps
fulfill.
E
So
I
believe
it
is.
Let
me
see
so
I
believe
I
was
ally
performed
actually
the
best
gay,
but
I
think
you
used
la
as
well,
so
you
might
have
some
thoughts
there.
We
performed
pretty
poorly
on
things
like
having
a
tool
that
the
entire
team
can
use.
So,
like
anyone
understands
the
terminology
and
can
kind
of
jump
in
and
use
it,
they
don't
have
to
be,
let's
say,
a
developer
or
a
product
manager.
E
Also
our
calls
to
action,
weren't
super
clear
on
features
or
workflows,
so
we
might
have
some
kind
of
like,
let's
say
a
widget
or
maybe
our
like
related
items.
Widget
exists,
but
maybe
users
don't
immediately
understand
the
value
of
it
or
how
to
use
it
like
what
they
should
do
with
it,
how
it's
valuable
to
them
and
their
workflow.
E
So
I
had
like
a
million
issues
from
this
that
I
need
to
create,
so
I'm
going
to
go
through
and
do
that
today,
but
I
listed
out
kind
of
some
of
the
main
ones
here
and
the
agenda,
and
I
think
so,
wave
finding
and
nesting
as
nav
was
something
that
came
up
a
few
times
so
like
wave
finding
meaning
wherever
I
am
in
the
product
and
wherever
I
am
within
the
hierarchy.
I
need
to
know
what
is
that
you
are
here.
Where
am
I
right,
like?
E
I
know,
there's
this
big
structure
that
I'm
within
but
like.
Where
am
I
at
the
moment
and
then
how
do
I
navigate
around
the
structure?
So
those
are
really
important
things
that
I
think
we
should
better
incorporate
or
like
improve
within
our
product
and
as
we
move
forward
with
work
items
I'll
stop.
Is
there
any
questions
there.
A
The
breadcrumbs
are
the
only
way
to
navigate
through
that
efficiently,
which
is
problematic.
I
don't
like
them,
but
literally
it's
the
only
way
that
I
can
move
up
to
my
parent
group
easily
with
a
single
click
or
two
and
then
that
they
showed
a
graph
of
like
a
chart
of
how
the
navigation
structure
and
wave
finding
currently
works
versus
what
our
customers
want.
A
E
C
Yeah,
I
don't
love
them,
but
it's
not
like
my
pet
peeve.
My
pet
peeve
is
the
cognitive
load
of
trying
to
figure
out
exactly
where
I
am,
and
what
I'm
looking
at,
like
so
I'll,
come
back
to
something
I'll
forget
if
it's
an
epic
or
an
issue,
and
I
use
the
weirdest
like
heuristics,
I've
noticed
to
figure
out
what
it
is
like
I'll
scroll.
I
notice
they'll
scroll
if
it's
an
epic
and
if
because
issues
like
have
sticky
title,
if
it
doesn't
stick.
B
C
It's
an
epic,
I
mean
it's
ridiculous
like
I
mean,
but
it
is
like
probably
a
symptom
of
something
like
that's
not
right.
It's
everything
looks
too
similar
groups
and
projects.
Look
too
similar
when
you're
in
them
or
when
you're
inside
issues
in
groups
in
a
group
or
a
project
like
it's
very
hard
to
know.
If
you're
looking
at
group
issues,
project
issues
breadcrumbs
like
at
least
you
could
say,
they're
functional
they're,
not
particularly
pretty
but
yeah
again,
even
looking
at
the
breadcrumbs.
Sometimes
I'm
still
not
entirely
sure.
D
I've
heard
similar
feedback
gabe.
You
tagged
me
in
something
recently
where
someone
was
talking
about
breadcrumbs
and
I
forget
who
it
was,
but
they
were
saying
that
they
have
trouble
knowing
how
to
interpret
them,
and
something
that
I
found
in
the
mobile
testing
is
that
when
you've
got
lots
and
lots
of
layers
deep
into
groups
and
projects,
then
it
just
wraps
and
it
looks
terrible
in
a
mobile
setting.
A
Yeah,
we
already
do
do
that
where
what,
if
it's
a
long
breadcrumb,
we'll
just
truncate
it
and
show
the
first,
the
top
level
ellipsis,
that
you
can
click
on
to
select
the
level
below,
and
I
use
that
a
lot
when
I'm
demoing
to
customers,
because
I
use
those
deeply
nasty
groups.
I
wouldn't
even
mind
if
it's
just
sort
of
like
the
ellipsis
before
the
current
context
that
I'm
in
and
so
that
way
like.
I
don't
even
have
that
extra
noise
because
they
never
go
up
to
the
top
level
group.
A
A
D
E
Yeah,
I
think
we
I
mean,
I
know
I've
looked
at
an
issue
around
truncation
I
think
I
was
secure,
was
working
on
it
like.
Where
do
we
truncate
at
the
end
at
the
beginning
in
the
middle,
and
there
was
a
study
into
what
was
best
practice
there.
So
I
could
try
to
dig
that
up
later,
thanks
for
posting
that
gabe
cool.
Thank
you
all.
That's
really
good
feedback,
john,
especially
that's
so
interesting
what
you're
doing
over
there
so
searching
for
work
items.
E
This
is
mostly
a
git
lab
issue
and
I
think
we
all
kind
of
know
about
it,
but
one
thing
I
encountered
because
I
was
just
kind
of
like
pretending,
I'm
a
new
user
that
doesn't
know
much
about
gitlab
right
and
especially
after
testing
out
these
other
two
products
that
were
similar.
I
really
wanted
to
just
type
in
the
title
of
the
object
that
I
want
to
add.
So
let's
say
I'm
in
an
epic
tree.
I
want
to
add
an
existing
issue
or
epic.
E
I
just
want
to
type
in
the
title
of
that
and
have
that
be
selectable,
whereas
if
I
type
if
I
start
typing
within
our
tree,
I
might
type
in
like
the
and
then
once
I
hit
space.
You
know,
of
course
that
becomes
the
item
I'm
searching
for
and
I'm
assuming
that's
like
you
know
the
logic
and
maybe
I
could
put
quote
marks,
I'm
not
sure,
but
I'm
just
kind
of
wondering
what
are
the
constraints
there
like?
Is
there
anything
we
can
do
to
make
this
kind
of
more
friendly?
A
The
constraints
are,
if
you
are
in
one
project,
we
only
look
in
that
project
for
related
issues,
because
it
would
be
too
expensive
to
look
in
all
the
projects
you
have
access
to.
So
if
you
want
to
expand
out
and
do
sort
of
like
auto
matching,
basically
on
all
the
projects
you
belong
to,
that
then
that's
problematic,
that's
sort
of
why
I
was
sorry
my
zooms
like
or
my
safari
is
crapping
out.
While
I
was
looking
at
assigning
issue
to
multiple
groups
or
projects
right.
B
B
I
was
just
saying
I
had
a
note
there
that
I
thought
you're
when
I
was
reading
the
agenda.
I
thought
it
was
more
about
the
like
search
page
for
like
the
issue
search
that
exists
currently
rather
than
sort
of
referencing
or
finding
them,
but
it
should
from
a
search
perspective
like
it's
functionally
the
same
as
the
issue,
search
that
we
currently
have,
but
hopefully
with
what
heinrich
is
working
on.
It
will
be
faster
and
not
routinely
500.
Every
time
someone
tries
to
search
too
too
large.
E
B
Well
right
now
it
searches
title
and
description
like
that's
the
two
kind
of
like
buckets
that
are
searched
when
you
put
text
in,
but
I
know
that
the
ability
to
search
comments
is
something
that
has
been
hotly
requested,
but
it's
kind
of
a
unknown
insurmountable
amount
of
figuring
out
how
to
do
that.
Right
now,.
E
Yeah,
no,
it's
like
no
priority.
Well,
not
in
my
end,
maybe
gabe's
end,
but
I
just
think
that
could
be
interesting
cool
and
do
you
think
that
will
speed
up
the
search,
I'm
assuming
right,
because
I
know
if
you
search
for
just
plain
text
within
a
filter,
for
example,
it's
like
searching
everything,
so
it
kind
of
takes
forever.
B
Yeah,
though,
the
initial
kind
of
like
proof
of
concept,
was
a
drastic
speed
improvement.
There's
some
there's
some
implementation
details
around
different
languages
that
are
designed
differently
than
english
language,
just
broken
on
spaces
that
we
have
to
kind
of
resolve
how
to
deal
with
those,
but
it
should
be
much
much
faster,
which
is
sort
of
the
motivator
like
right.
Now
we,
the
the
search,
is
unacceptably
slow,
like
it's
not
really
usable.
So
it's
a
big,
a
big
problem
both
from
a
user
perspective
and
from
a
infrastructure
and
database
perspective.
B
A
Gonna
say
is
that,
right
now
we
have
just
like
sort
of
a
different
kinds
of
relationships
between
work
items.
You
can
have
just
the
loose
related
blocking
blocks,
there's
not
any
sort
of
the
types
of
relationships
between
issues
and
merge
requests,
but
there
needs
to
be
because,
like
I
can
mention
an
issue
in
a
comment
of
mr
that's
not
even
related
or
like,
isn't
implementing
that
issue
and
it
still
gets
marked
as
related
right,
and
so
you,
especially
for
auditing
purposes
and
other
things
like
that.
E
A
That's
what
jira
does,
but
it's
gets
really
convoluted
really
fast.
When
I
was
reviewing
jira
with
a
couple
of
executives,
they
were
walking
me
through
it.
They're
like
I
have
no
clue
what
the
this
means
like
what
is
implements
like.
I
mean
when
showed
me,
this
giant
list
of
drop
downs
and
relationship
types,
and
he
had
no
clue
what
any
of
them
were,
and
it
was
super
complex.
A
I
would
prefer
not
to
make
that
customizable
just
because
like
or
if
we
do,
it's
gonna
be
way
down
the
road
right.
Like
I
wanna,
I
think
we
can
do
a
good
job
of
defining
you
know
like
is
it?
Is
it
a
child?
Is
mr
a
child
of
an
issue,
or
is
it
just
related
like
that's
the
only
difference
that
we
really
need
to
have?
In
my
opinion,.
A
Not
for
the
relation
between
an
mr
and
an
issue,
no
I
mean
if
like,
if
you
think
about
it,
if
it
if
emerge
requests,
is
a
child
of
an
issue,
it's
already
blocking
the
issue
because
it
has
to
be
delivered
before
the
issue
can
be
closed
right.
So
that's
sort
of
like
where
it's
in
implicit,
like
as
a
child,
you're
already
blocking
your
parent.
A
Then
you
can
have
cross
hierarchy
blocking
things
right,
but
maybe
you
could
have
merge
request.
It's
not
a
child
block,
an
issue
eventually,
but
I
don't
know
I
actually
just
got
off
a
call
with
folks
from
the
editor
team
and
they
wanted
they
more
or
less
wanted
to
be
able
to
put
weights
on
merge
requests
and
have
that
weight,
roll
up
to
issues,
and
so
I
showed
them
the
work
item
stuff
and
they
basically
said
that
they
want
to
work.
A
They
want
the
merch
request
to
be
a
work
item
so
that
way
like
they
can
like.
There's
no
reason
why
there's
the
separation
of
the
two
in
their
minds,
because
now
you
have
like
different
views
for
different
things
and,
like
you,
just
artificial
work
to
create
issues
so
that
pms
can
see
what's
going
on
and
they
make
a
really
valid
point.
A
E
A
Okay,
well
because
they
also
said
that
they
never
go
through
and
manage
workflow
labels,
because
all
they
care
about
is
their
mrs
and
then
getting
issue
closed
right.
So
they'll
keep
their
mr
up
to
date,
but
they
will
never
keep
the
issue
up
today,
because
it's
not
automated,
which
then
leads
to
like
bad
reporting,
poor
visibility
for
pms
and
all
sorts
of
other
things.
So
I
think
it's
worth
exploring
that
eventually
too
it's
just
like
should
a
merge
request,
just
be
a
type
of
work
item
which
I
think
it
should.
A
A
Yeah
we
talked
about
those
a
little
bit
already.
There
are
valid
use
cases
in
the
parent
child
relationship
where
some
things
you
need
to
roll
up
from
your
children,
some
things
from
the
parent.
You
want
to
roll
down
some
things
you
want
to
have
both
like
you
know.
If
you
have
a
weight
on
a
parent,
you
want
to
be
able
to
set
that
as
like
an
estimated
way
and
then
also
see
the
actual
weight
rolling
up
from
your
children.
A
So
what
I
would
suggest
in
this
is
like,
instead
of
trying
to
solve
it
all
at
once,
like
as
we
work
through
each
field
on
the
work
item,
existing
widget,
let's
think
through
how
the
inheritance
should
behave,
and
then
I
think
once
we
get
through
a
few
of
them,
a
pretty
clear
standard
pattern
will
emerge
and
that's
like
what
we
want
to
get
to,
but
it's
a
much
broader
conversation
that
could
be
had
right
here.
That's
my
only.
E
Any
other
thoughts
think
that
makes
sense
so
like
first
think
about
what
might
make
sense
to
inherit
otherwise
a
lot
of
stuff
about
like
providing
users
with
kind
of
like
the
ideal,
and
not
necessarily
templates
but
kind
of
what
you
were
saying
before:
okay,
but
like
okay.
If
this
is
a
child,
this
means
it
might
be
blocking
like
having
documentation
and
guidance
on
that
within
the
product
as
well.
A
One
small
thing-
and
this
is
just
ux-
that
we
didn't
get
to
like
in
terms
of
relationship
types
and
things
like
that.
I
can't
mark
a
issue
as
blocked
if
it's
already
related
to
an
issue,
I
can't
mark
it
as
blocked
unless
I
delete
the
related
relationship
and
then
I
re-add
it
as
a
blocked
relationship.
I
can't
switch
it
right.
So
that's
the
kind
of
thing
just
like
we
want
to
make
switching
issue
types
easy.
Just
like
a
drop
down
switch.
A
I
think
we
really
need
to
focus
on
making
it
simple
to
switch
the
type
of
relationship
it
is
without
having
to
like
hit
a
neck
right.
Click
copy
paste.
The
link
hit
the
x
on
the
relationship.
Click
add
select,
block
supply,
you
know
paste
it
in
hit
enter,
so
you
could
go
from
like
six
clicks
to
two.