►
From YouTube: Plan | Weekly Sync 2022-08-03 Part 2
Description
A
I
will
attempt
to
stitch
these
together.
These
two
recordings:
where
did
you
get
to
in
the
agenda.
B
A
Cool
yeah,
so
I
was
just
curious
about
the
list.
I
would
expect
it
to
be
filtered
to
issues,
but
I
don't
know
I
can
see
nick
said
it
was
discussed
somewhere.
C
Yeah,
I
think
donald
made
the
same
proposal.
I
think
my
concern
with
that
is
like
we
don't
typically
pre-filter
lists,
and
I
just
worry
that
it
would
be
confusing
to
like
why
it
would
be
there.
We
also
know
that
some
teams
use
that
list
as
the
incident
slash
issues
like
man
like
to
manage
both
of
those
things
simultaneously,
which
would
mean
every
single
time
they're
like
clearing
a
filter.
C
C
C
Is
everything
right?
Any
anything
that
has
anything
that's
within
like
an
issue
and
has
an
issue
type
is
like
true.
D
C
I
mean
that's
kind
of
how
we're
treating
it
right
like
it's
we're
calling
I
mean
it
goes
back
to
this,
like
broader
confusion
of
issues,
meaning
two
things
but
like
we're,
basically
treating
it
as
issues
the
like
super
set
of
anything.
That
could
be
an
issue,
but
not
specifically
the
issue
type
issue
which,
if
you
think
of
it
like
work
items,
we're
basically
calling
this
like
all
work
items
which
I
think
is
fine.
I
think
that
makes
sense
for
now.
C
It's
also
how
like
jira
and
stuff
works,
you
you
have
to
kind
of
sub
filter
once
you
go
in,
so
I
I
think
that's
all
right,
but
we
should
definitely
like
keep
looking
at
that
and
finding
ways
to
make
it
better.
A
C
Feels
yeah,
I
I
don't
think
that
we'll
well
we'll
either
need
to
like
correct
the
terminology
or
or
change
the
ui
or
both
at
some
point,
so
that
it's
not
well
you're.
Also
gonna
have
epics
in
here.
So
there's
already
gonna
be
a
change
potentially
is
like
if
epics
and
issues
end
up
getting
sort
of
more
sort
of
coupled
into
one
list.
A
I
already
have
requirements
as
well,
so
you
know
if
this
was
a
work
items
list
instead
of
an
issues
list
then
like.
If
people
need
easy
access
to
one
type,
I
don't
see
why
we
couldn't
just
have
that
type
in
the
sidebar
and
point
it
to
a
pre-filtered
work
items
list,
at
least
for
a
short
period.
You
know,
but
currently
the
the
fact
that
you
click
on
issues
and
you
see
all
different
types
of
work
items
to
me-
is
just
more
confusing
because
we
know
their
issues
under
the
hood
like.
A
Currently,
we
intend
them
to
be
like
not
issues
under
the
hood,
but
they
belong
they're
in
the
issues
table
right,
but
we
call
them
work
items.
We
consider
them
work
items
and
we
consider
issues
to
be
like
one
type
of
work
item.
So
to
me,
it's
more
confusing
that
we
call
it
issues
in
the
sidebar,
but
when
you
click
it,
you
get
a
whole
bunch
of
other
things.
You
know.
C
I
think
right
now,
though,
we
call
them
issue
types.
I
mean
I
wasn't
here.
Those
decisions
were
made
or
kind
of
what
the
discussion
discussion
was
but
like
that
was
sort
of
my
understanding.
You
know
initially
started
by
treating
them
all
as
issues
and
they
have
issue
types
and
that's
why
they
show
up
there.
This
isn't
really
like
a
new
problem
with
tasks,
but
tasks
are
probably
gonna
or
could
probably
scale
to
a
larger
degree
than
like
incidents
or
requirements
or
test
cases
do.
I
would
guess.
A
Yeah,
it's
possibly
like
an
evolution
of
nomenclature
over
time,
but
definitely
the
feedback
I'm
getting
on.
I'm
seeing
on
issues
related
to
requirements
is
that
people
do
not
want
them
to
be
issues
right,
and
this
confusion
is
like
disappointing
for
some
customers
like
who
think
that
we're
going
to
make
requirements,
issues
like
everything
else
and
they're
going
to
be
closable
and
have
all
these
other
like
assignable,
and
things
like
that
and
they're
like
this
doesn't
make
sense
for
requirements
and
that's
not
what
we're
trying
to
do.
A
C
Okay,
I
mean
that's
a
good
point
with
the
requirements
and
I
think
we
should
probably
look
at
that
specifically
is
to
because
I
think,
like
tasks
and
issues
like
obviously
are
very
tightly
correlated.
I
don't
know
that
much
about
requirements
or
how
people
perceive
them,
but
if
they're
perceived
as
a
separate
object
type,
then
you
probably
do
want
to
treat
them.
A
They
go
through
different
states.
For
a
start,
that's
a
that's
the
main
thing
they
shouldn't
be
like
closable,
because
that's
not
a
concept,
they
should
be
archivable
and
we
made
a
mistake
originally
and
allowed
people
to
close
requirements
because
they
were
coupled
with
their
own
issue,
and
this
was
really
confusing
for
people.
They
were
able
to
close
the
requirement
issue
and
or
work
item
type
and
and
then
that
was
copied
over
to
the
requirement
itself
and
it
was.
E
A
C
I'm
not
sure
that
there's
an
answer
defined
for
that
at
the
moment.
I
think
it
could
be,
but
it
could
also
be
like
we
could
probably
also
just
use
like
planning
or
plan
or
something
related
to
like
the
notion
of
planning,
as
basically
the
way
to
get
into
the
the
views
but
yeah
like
if
required
requirements
can
be
built
as
a
work
item
from
our
perspective,
but
it
doesn't
necessarily
have
to
be
presented
as
a
work
item
to
the
user.
C
F
I've
seen
a
lot
of
exploration
around
just
putting
it
under
kind
of
like
a
planning
umbrella,
like
you
said,
nick,
like
they're,
all
just
within
the
umbrella
of
plan,
and
then
the
types
of
objects
are
almost
like
templates
over.
You
know
types
of
templates
in
a
way
that
enable
planning,
so
I
think
we're
exploring
that
in
navigational
explorations
and
foundations
as
well.
So
we
could
loop
in
with
them.
B
Cool
and
so
like
also
regardless
of
the
naming
of
it,
is
there
a
plan
to
have
a
a
view
on
the
maybe
it's
linked
on
the
left,
sidebar
or
just
just
anywhere
a
view
of
every
single
work
item
like
in
one,
including
things
like
requirements
and
tasks
and
issues
and
epics
and
everything
are
we
always
going
to
have
kind
of
a
limited
list
within
either,
regardless
of
what
we
call
it
like?
B
So
if
we
have,
if
we
continue
having
issues
on
the
left
hand,
sidebar,
are
we
always
going
to
have
things
outside
of
issues
in
that
list?.
C
Issues
and
like
the
like,
the
legacy
issue,
like
type
issue,
sort
of
sense
yeah,
I
would
say,
probably
like
probably
not
only
because
as
issues
as
work
item
types
expand,
especially
if
we
enable
like
custom
types
and
stuff
like
we're
gonna
have
to
move
towards
a
more
generic
sort
of
container
for
those
and
then
allow
people
to
create,
like
basically
saved
filters
or
something,
and
now
maybe
there's
a
way
for
those
saved
views
to
show
up
there
like.
C
I
think,
that's
something
that
you
know
we're
looking
at,
how
how
you
would
do
that
and
you
could.
You
know
we
could
provide
a
default
saved
view.
That
is
just
issues
and
like
that,
would
basically
get
you
there,
but
whether
that
shows
up
in
the
sidebar
or
whether
that
shows
up
once
you're
in
the
like
planning
space,
I
think
is,
is
still
to
be
determined.
B
Cool
yeah,
I
think
the
so
right
now
going
to
issues
is,
is
a
bit
more
confusing,
because
everything
in
that
list
looks
like
an
issue
looks
the
same
once
we
add
like
the
task
icon
and
some
of
the
other
icons
to
that
list.
I
think
it'll
be
a
little.
B
E
Oh
yep,
so
when
you
were,
when
you
were
demoing
work
items,
I
checked
the
docs
and
we
only
mentioned
the
work
items
feature
flag,
and
so
I
asked
that
do
we
need
to
update
the
dogs
or
since
you
mentioned,
we're
going
to
be
removing
the
create
from
markdown
flag.
E
Do
we
just
want
to
ignore
it,
and
then
I
got
lost
and
then
kushal
said,
which
I
think
he
also
said
during
his
demo
that
he
wants
to
update
the
docs
to
reflect
current
state,
to
which
I
say
thank
you.
E
Awesome
if
I
can
do
a
non-sequitur
to
go
back
for
a
second
donald
asks
about
work
items
in
the
ui,
and
I
think
we
would.
We
will
need
to
make
a
decision
somehow
and
what
nick
said
plan
planning
to
get
there
will.
If
we
only
pick
this,
it
will
still
like
take
us
to
awkward
places
with
wording,
because,
right
now
I
am
thinking
about
the
docs
and
with
all
the
things
that
you
can
link
linked
issues
linked
epics
now
respond
is
adding
linked
resources
to
incidents
as
well.
E
I
was
thinking
of
creating
a
page
that
would
link
to
these,
so
we
would
add
it
to
the
tooltip
to
the
question
mark
button
on
the
links,
items
widget
and
then
because
right
right
now,
I
don't
think
we
have
this
question
mark
button,
but
if
we
had
linked
items
and
then
it
would
have
task,
but
it
still
takes
you
to
a
linked
issues,
documentation
page,
so
I
was
you
know.
I
was
thinking
how
to
call
it
this
page
and
you
know
either
we
start
calling
these
just
items
or
I
don't
know
like
like.
I.
C
Yeah,
well,
I
mean
we'll
have
to
introduce
it
sooner
than
later.
I
just
think
like
right
now,
because
we're
using
task
for
everything
like
there
is
there's
a
risk
that
we
confuse
people
by
like
three
places,
calling
it
task
in
one
place,
calling
it
work
item
when
workout
only
means
task
for
for
the
current
moment,
but
I
think
that
probably
deserves
more
of
a
rollout
plan
of
like
at
some
point.
F
E
Oh
anyway,
oh
yeah,
okay,
so
I
noticed
we
have
a
cc
quick
action
and
it's
so
it's
not
in
the
docs
and
it's
not
it's
never
render
it
well,
it's
always
rendered
when
people
type
it
out
and
so
heinrich,
and
so
I
asked
if
we
should
just
remove
it
and
that's
the
question
to
my
ux
folks,
primarily
because
it's
not
doing
anything
and
it's
the
same
as
just
typing
cc,
without
the
slash
or
just
mentioning
somebody
yeah
so
heinrich
mentioned
that
it
was.
It
was
added
to
support
no
up.
E
D
A
So
there's
a
slight
wording
difference
in
the
to-do
right
like
and
it
depends
if
you
use
the
person's
what's
the
name
username
at
the
start
of
the
line
or
in
the
body
of
text,
and
I
wonder
if
it's
also
depends
if
you
use
cc
with
a
slash
or
cc
without
a
slash,
if
you
use
it
with
the
slash,
it's
a
quick
action
and
then
the
user
main
name.
There's
no.
Like
technical
difference
like
I
think
it's
just
a
slight
different
wording
on
the
cd.
D
D
E
Okay,
I
didn't
know
this
technique,
but
yeah
delete
your
failing
test.
A
I
don't
know
of
any
other
quick
action
that
remains
in
the
body
of
text.
That's
executed,
but
also
remains
in
the
body
of
text,
so
maybe
it
serves
as
an
example
to
you.
I
don't
know
this
is
a
terrible
reason
to
keep
it.
There
is
no
good
reason
to
keep
it.
As
far
as
I
can
see.
B
Yeah,
like
this,
the
I
link
to
the
cc
filter
on
to
do's.
I
mean
I
guess
we
could
yeah,
I
don't
know,
but
so
I
think,
as
a
user
that
uses
the
quick
action
just
because
it
will
throw
me
off
if
it's
no
longer
available.
B
F
D
A
E
A
Has
been
had
in
meetings
before
like
about
this
quick
action,
and
that
has
been
the
conclusion
every
time
just
leave
it
alone.
It's.
E
B
I
think
we
should
also
create
a
issue
proposing
that
we
remove
it
just
to
see
if
we
get
a
lot
of.
B
Do
we
have
a
confidential
note,
quick
action.