►
From YouTube: Plan | Weekly Sync 2022-06-08
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
plan
weekly
meeting
june,
the
8th
2022.,
both
items
are
read
only
really
because
I
was
not
here,
but
it
seems
like
there's
a
lot
of
feedback
on
this
item.
So
I
wonder,
should
we
go
ahead
and
talk
about
it
anyway?
Probably.
B
A
Okay
cool,
so
I
can
I'll
verbalize
for
coachella
and
then
all
the
participants
in
the
discussion
are
here
anyway.
Okay,
so
removing
requirements
and
test
cases
from
the
issue
list.
A
When
we
moved
to
view
issues
list
and
started
using
graphql
to
fetch
the
asus
list,
both
requirements
and
test
cases
started
showing
up
along
with
regular
issues
and
incidents.
All
four
of
these
types
are
issuable
objects.
Graphql
query
to
fetch
the
issues
list
supports
a
types
filter
which
can
accept
an
array
of
enums
to
determine
what
to
include
in
the
list
as
per
our
documentation.
A
Incidents
can
show
up
in
the
list
both
test
cases
and
requirements
do
not
support
all
the
features
of
initial
ebola
and
if
a
user
tries
to
open
these
from
the
issue
list,
they're
incorrectly
rendered
with
the
legacy
issues
view
requirements
showing
up
in
issues
list
is
clearly
a
bug
and
is
being
fixed.
So
his
question
is:
do
we
want
to
show
test
cases
in
the
issue
list?
A
If,
yes,
do?
We
have
to
update
the
link
url
to
point
at
the
actual
test
case
page,
which
is
under
a
different
url
in
a
different
view.
To
render
it
correctly
and
in
his
opinion,
we
should
not
show
test
cases
within
issues
as
test
cases,
do
not
support,
commenting
and
only
support
labels
beyond.
B
I
don't
really
know
what
that's
going
to
look
like.
I
think
we're
trying
to
figure
out
the
best
option
here,
because
we
don't
want
to
clutter
the
nav
bar
with
everything,
but
on
the
flip
side,
if
you're
trying
to
work
on
requirements-
and
you
want
to
jump
to
requirements-
you
don't
want
to
have
to
spend
you
know
all
this
time
clicking
around
and
filtering
and
all
this
stuff.
B
I
think
in
the
meantime,
though,
you're
absolutely
correct.
The
issue
we
ran
into
for
those
people
who
aren't
aware
is
since
requirements
show
up
in
the
issues
list.
It's
really
nice.
You
can
go
and
add
labels,
so
you
kind
of
get
that
feature
for
free,
that
we've
always
kind
of
wanted
and
john
did
a
great
job
and
went
out
and
added
some
labels
to
issue
to
tesca
requirements,
and
it
was
great,
but
one
of
our
customers
did.
The
same
thing
was
like:
oh,
I
can
just
close
it
and
they
closed
it.
B
Well,
now
it's
in
the
state
that
you
can't
recover
from
because
the
requirement
itself
doesn't
support
closing.
So
if
you
go
to
the
requirements
view,
it's
just
gone
gone.
There's
it
doesn't
show
up
in
the
like
closed
status.
It's
just
forever
gone.
They
couldn't
figure
out
how
to
get
it
back.
So
that's
where
we're
running
into
problems
is
these
incompatibility.
So
I
think
in
the
short
term,
you're
absolutely
correct.
We
should
split
requirements
out
and
test
cases
are
probably
in
the
same
boat,
because
we
can
see
the
writing
on
the
wall.
B
C
I
think
I
had
the
next
point
and
same
thing,
so
we
can
skip
mine.
The
only
thing
that
I
was
thinking
about
is
that
once
we
do
have
everything
in
the
same
place,
let's
say
we
want
to
get
rid
of
the
url
for
requirements
or
for
test
cases
or
whatever
we're
going
to
have
to
support
redirects
to
the
new
url
at
some
point,
which
also
is
in
line
with
something
that
we
want
to
do
long
term
with
work
items
which
is
properly
handled
moving
them.
C
So
I'm
not
sure
where
we
want
to
fit
that
into
the
workflow,
but
instead
of
right
now,
when
you
move
an
issue,
it
closes
the
issue
and
creates
a
copy
of
it.
I
think
we
want
to
move
to
a
place
where
we
don't
close
and
we
just
actually
move
it
while
keeping
it
open.
So
I
I'll
let
the
engineers
weigh
on
on,
if
or
when
that's
important.
That's
just
the
only
thought
I
had.
B
I
cannot
stress
from
a
product
perspective
enough
how
important
it
will
be
when
we
finally
fix
this,
because
this
causes
no
end
of
customer
questions,
confusion,
consternation
and
problems
on
customer
calls
are
like
wait.
I
moved
it.
Why
do
I
still
have
a
closed
issue
over
here?
I
didn't
want
to
close
it.
I'm,
like
you,
didn't
close
it.
You
closed
the
copy.
Like
you
closed
the
old
one
and
opened
a
new
one
like
well,
why?
Why
do
I
have
a
closed
issue
now
and
it's
like
this
huge
thing
so
yeah.
A
It
also
causes
some
really
unpleasant
edge
cases
and
things
like
service
desk,
where
the
the
conversation
continues
to
come
in
on
the
closed
issue
and
people
comment
on
the
moved
issue
and
think
that
people
are
seeing
their
comments
and
they're
not
so
it's
like.
Yes,
this
is
painful.
These
strange
educations
yeah
and
we
actually
skipped
your
comment.
Do
you
want
to
add.
D
Yeah,
I
just
think
the
old
discussion
when
I
was
asking
the
similar
question.
I
agree
with
with
what
was
already
said
and
longer
term.
It
makes
sense
to
me
to
list
all
together
if
a
short
term,
we
filter
out
some
of
items
in.
E
D
For
example,
in
drop
downs
or
some
auto
completion,
quick
actions
and
stuff
like
this
or
referencing
in
our
markdown.
F
So
I
think
the
bug
here
was
specifically
around
the
issues
list
page
but
yeah.
Now
that
you
mentioned
about
the
other
places
where
we
have
auto
completion,
specifically
in
places
like
related
issues
there.
F
I
think
we
go
by
the
symbol
where
we
provide
the
number,
but
it
would
be
interesting
to
see
like
what
would
happen
if
I
use
hash
as
a
symbol,
and
then
I
provide
the
number
which
points
to
a
test
case
or
requirement
and
not
an
issue,
then
in
that
case,
would
it
still
show
the
results
in
autocomplete
and
if
it
does
show
it
then
clicking
on
add
what
would
happen?
I
mean
felipe
would
know
better
because
he
worked
on
test
cases
back
in
and
the
idea
was
to
keep
them
as
issuables.
F
It
is
just
that
we
wouldn't
support
all
the
attributes
from
the
sidebar,
like
assignees,
due
dates,
wait,
etc,
and
with
regards
to
test
cases,
we
only
supported
labels
and
even
discussions
weren't
supported.
But
if
you
open
test
cases
from
the
issues
list,
then
you
can
see
the
entire
ui
for
commenting
and
then
starting
discussions,
and
it
does
allow
you
to
add
comments
there.
F
It
doesn't
fail
anywhere
because
underlying
object
supports
it,
but
then
it's
not
correct,
because
if
user
visits
the
same
test
case
from
the
ci
cd
url
of
the
test
case,
then
we
don't
show
any
commenting
ui
there.
So
it
would
only
confuse
user
as
long
as
we
keep
showing
test
cases
within
the
issues
list
same
thing
goes
for
auto
completion.
F
I
think,
for
I'm
not
sure
whether
rest
api
does
support
providing
types
filter,
but
everywhere,
where
we
are
using
graphql
to
fetch
issues
list
a
types
filter
can
be
utilized,
so
we
can
at
least
mitigate
those
places
and
make
sure
that
we
are.
We
are
only
filtering
the
results
and
include
the
issues
and
incidents
and
nothing
else,
but
for
rest
api.
I
don't
think
it.
It
has
any
sort
of
types
filter
present
there.
D
Cool
thanks.
I
think
that
it
will
make
sense
to
the
action
item
from
this
to
to
verify
a
backend
on
on
what
all
places
we
filter
out
some
specific
type
from
this
issue
listing,
because
I
know
we
do
this
at
least
on
the
index
page,
but
I
remember
that
it
was
not
perfect
at
all
and,
for
example,
on
api
and
somewhere
else,
all
issue
types
were
listed
anyway.
So
I
believe
that
this
is
not
a
total
or
complete
isolation,
and
some
action
will
be
probably
needed.
C
I
was
just
going
to
add
one
thing
that
we're
doing
with
tasks,
because
tasks
had
the
same
problem
where
you
could,
if,
from
the
list
view,
it
would
open
up
into
the
issue
url
in
the
issue
detail
page
and
I
think
one
of
the
things
that
we're
doing
with
tasks
that
hopefully
is
done
by
the
the
freeze
for
this
release.
So
we
can
make
test
finally
available
is
having
them
render
at
the
new
work
item
url
and
so
not
just
from
the
list
view,
but
also
from
places
like
profiles.
C
Where
there's
your
activity
feed,
basically
anywhere
in
the
application
that
you
can
click
in
to
or
have
the
url.
For
this
thing
present,
which
should
also
be
references.
I
think
mario,
is
planning
on
updating
the
links
attributes
in
the
rest.
Api
with
the
point
to
the
correct
urls
could
be
not
remembering
correctly,
but
we
could
also
take
the
same
approach
with
requirements
and
test
cases.
C
Once
we
have
the
widgets
for
the
to
the
various
objects,
you
can
use
the
same
approach
to
more
or
less
render
them
in
the
new
work
item
ui,
and
that
way
they
won't
have
labels
and
or
like
all
the
things
that
they
shouldn't
have
on
them.
Yet
if
that
makes
sense,
so
we
don't
have
to
wait
down
your
point
john
on
five.
I
don't
know
if
we
have
to
wait
until
we
have.
C
Oh
you
did
say
it
includes
all
the
witches
working
on
sports
anyway.
It
could
be
a
good
way
to
fast
follow
with
those
other
two
objects
solve
the
same
problem.
A
Yeah,
that's
what
I'm
thinking
so
like
the
three
criteria
would
include
like
that.
This
new
work
item
view
so
say
for
requirements.
Requirements
just
have
off
the
top
of
my
head.
I
think
title
description
status
right
like
archived
or
not
or
satisfied
or
not,
and
then
they
can
be
archived.
So
as
soon
as
the
new
work
item
view
supports,
like
those
four
widgets,
let's
say,
then
we
can
start
rendering
requirements
as
work
items
until
then.
G
F
Sorry
go
ahead
right
I'll
finish.
It.
A
Being
that
you
know
we
can
filter
the
might
somehow
if
people
want
to
and
then
secondly,
that
are,
thirdly,
that
it
makes
sense
right,
like
I
don't
know,
if
having
things
ever
in
the
issues
list
makes
sense,
with
the
possible
exception
of
things
that
act
very
like
issues
like
incidents,
I
think
that
I'm
always
going
to
want
to
see
my
requirements
separately
and
and
possibly
always
see,
test
cases
within
that
context,
and
I
just
don't
know
like
a
single
work
items
view
I
think,
makes
a
lot
of
sense,
especially
while
we're
developing
this,
because
we
had
this
problem
before,
but
that
tasks
would
be
orphaned.
A
Well,
if
you
have
a
work
items
list
that
you
can
filter
they're,
never
orphaned,
because
you
can
always
dig
through
that
list
and
find
them.
So
from
that
point
of
view
it
makes
sense,
but
then
I
also
think
there
are
other
parts
of
the
application
where
I'm
just
never
going
to
want
to
see
requirements
and
issues
side
by
side,
for
example,.
F
Yeah,
so
regarding
work
items,
I
don't
think
we
really
need
to
worry
about
how
the
work
item
view
needs
to
treat
the
data,
because
by
design
it,
it
basically
supports
all
the
widgets
that
are
going
to
be
provided
by
graphql
response.
So
the
way
work
item
queries
were
developed
was
that
it
would
basically
bring
the
widget
information
from
the
backend.
So
the
view
is
not
aware
before
making
the
query
that
what
are
the
widgets
it
is
going
to
expect
and
based
on
the
graphql
response
that
we
get
from
the
back
end.
F
We
determine
what
widgets
to
mount
and
show
on
ui.
So
work
item
can
basically
act
as
a
bare
bones:
shell,
where
it
would
basically
wait
for
the
response
to
come,
and
then
it
would
dynamically
mount
all
the
relevant
widgets
which
are
part
of
that
particular
work
item.
So
I
think
that
problem
won't
be
affecting
work
items
in
general.
F
It
is
just
that
issues
have
been
a
legacy
feature
and
they
were
all
the
views
which
render
issues
are
defined
in
a
way
that
they
have
certain
expectations
like
what
kind
of
data
to
show
there.
So
if
the
data
is
not
available,
it
basically
bars,
but
with
regards
to
work
items,
we
don't
have
to
worry
about
it,
like
all
the
widgets
will
be
present
there,
but.
A
But
does
that
even
true
at
the
minute,
like
I
mean,
are
they
just
the
existing
components
that
we
have
for
the
issues
page
because,
like
surely
the
new
work
item
view
just
only
at
the
minute
just
seems
to
support
enough
for
tasks.
So
like
title-
and
I
don't
know
what
else-
maybe
that's
a
close
closer.
F
Yes,
so
if,
if
I
understand
the
and
again
natalia
and
probably
florey
and
anyone
else
who
worked
extensively
on
work
item,
frontend
would
know
it
better,
but
based
on
the
limited
front,
end
work
that
I
did
on
work
items.
F
The
way
it
works
is
that
so
for
today,
for
example,
if
you
have
a
issues
query
developed
today
with
regards
to
work
items
where
it
would
bring
in
all
the
information
for
issues
in
in
a
work,
item
style,
api
response,
then
it
would
show
the
title
and
description
of
issues
and
it
would
not
include
any
other
widget,
because
the
widget
is
not
implemented
yet.
F
So
as
we
go
on
and
add
new
widget
types
for
work
items,
and
if
those
widget
types
are
also
supported
by
these
issua
issuable
objects,
then
they
would
get
included
in
the
api
response
and
then
front
end
would
take
care
of
it.
A
Cool
yeah,
so
that's
just
what
I
meant,
and
the
second
point
was
that,
like,
if
you
sent,
if
you
returned
a
requirement
as
a
work
item,
I
don't
think
it
would
show
that,
like
requirements,
have
a
special
status
satisfied
or
or
not,
or
how
they're
satisfied
manually
or
automatically
and
so
on,
so
I
don't
think
that
would
render
yet
so
it
doesn't
make
sense
to
me
to
like
render
them
in
the
issue
list
as
a
work
item.
You
know
because
the
view
doesn't
support
it.
A
Moreover,
if
your
end
of
them
actually
is
an
issue,
you
get
the
issue
that
this
customer's
complaining
about,
and
now
I'm
actually
worried
that
like.
If
we
take
this
away,
customers
are
not
used
to
adding
labels
to
their
requirements
and
they'll.
Ask
why
can't
I
add
labels
to
requirements
anymore?
I
could
do
this
last
milestone,
and
now
I
can't
and
well
it's
because,
like
you
were
also
able
to
close
the
requirement,
which
was
something
we
never
wanted
to
do
it.
So
this
is
really
a
regression.
F
So
for
self-managed,
I
don't
think
we'll
ever
know,
but
at
least
for
gitlab.com
we
can
ask
someone
from
the
site:
reliability
team
to
at
least
run
a
query
on
db
to
at
least
know
that
of
all
the
existing
requirements
across
gitlab.com.
What
requirements
have
labels
assigned
to
it
because
those
are
essentially
corrupted
objects,
and
if
we,
if
there
are
too
many
of
those,
then
I
think
we
have
a
bigger
problem
to
tackle
that.
Just
hiding
requirements,
though.
H
Yeah,
so
that
kind
of
brings
it
back
to
to
gabe's
point.
So
we
have
we've
got
a
choice
here.
We
can
either
show
requirements
within
the
issue
list
and
have
requirements
linked
to
the
requirements
url
similar
to
what
we're
doing
with
tasks
currently
in
that
tasks
are
just
going
to
the
work
items
url
and
then
issues
go
to
the
issue
url
or
the
other
option
is
to
have
what
we
did
before
just
filter
out
requirements
from
the
issue
list.
B
H
B
So
every
requirement
is
put
in
two
places
right
now.
If
I'm
understanding
things
correctly,
one
isn't
a
normal
issue,
issuable
type
item
and
one
is
the
requirements
database
we're
trying
to
deprecate
the
requirements
database.
Now
everything
move
over
at
some
point:
it's
just
we
haven't
pulled
the
trigger
to
do
the
migration,
yet
so
what
you're
actually
interacting
with
are
two
separate
things
which
is
what's
causing
us
grief
right
now.
B
H
I'm
sorry,
but
what,
when
you
say
its
own,
it
has
its
own
page,
but
it
doesn't
have
its
own
url.
It's
still
going
to
the
like.
You
can
go
to
the
issues
url
and
throw
in
a
requirements
id
and
see
the
requirement
correct.
You
can't
go
to
like
slash
requirement,
slash
id.
H
So
then
yeah,
I
think
we
should
filter
today
until
we
until
we
fix
that
problem,
that's
going
to
be
more
effort,
I
think,
to
get
requirements
to
get
requirement
its
own
requirements,
view
outside
of
the
requirements
list
view
view.
C
It's
also
worth
saying,
like
the
the
drawer
for
requirements
is
really
nice.
I
don't
know
if
we
want
to
do
a
drawer
or
modal
for
war
crimes,
but
also
just
so
future
thinking.
You
should
be
able
to
open
up
a
work
item
from
the
list
view
and
without
leaving
a
list
view
like
whether
it's
modal
or
drawer
or
whatever
ux
wants
to
do
so.
That's
just
also
something
that
we
want
to
do.
C
The
the
reason
why
we
have
to
have
the
dedicated
page
is
for
those
weird
times
where
you
give
somebody
a
direct
link
or
something's
in
your
profile
or
like.
You
still
need
to
have
that
like
canonical
source
of
location,
but
we
want
to
start
rendering
work
items
within
the
context
where
they're
linked
as
much
as
possible,
so
that
you
can.
D
B
Ironically
enough,
I
did
talk
to
one
customer
who
found
that
you
can
find
requirements
in
the
issues
thing
and
they
were
super
thrilled
that
they
could
add
labels
to
the
requirements.
Finally,
so
they
were
like
yeah
that
and
the
biggest
thing
was
they
go,
but
boo
you
got
rid
of
the
drawer,
you
really
like
the
drawer,
so
yeah
there.
You.
B
A
You
can
lock
the
conversation,
even
though
there
isn't
one
like
yeah.
It's
it's
a
bit
of
a
mess,
so
I
would
also
vote
to
remove
them
from
the
issue
list
for
now
take
the
heat
and
maybe
fast,
follow,
and
I
also
like
the
drawer-
and
I
thought
that
maybe
at
some
stage
you
know
the
new
work
item
view
would
incorporate
something
similar
for
those
who
are
interested.
The
there
are
two
objects
on
the
back
end
they're
kept
in
sync
such
that.
A
If
you
make
a
change
to
the
requirement,
it's
copied
to
its
corresponding
issue,
and
if
you
make
a
change
to
the
issue,
it's
copied
to
the
corresponding
requirement,
and
unfortunately
that
includes
the
closed
status
and
that's
why
it's
a
problem
really
is
that
you
can
go
into
an
issue
and
close
the
issue
requirement
and
it
will
somehow
also
close
the
requirement
requirement
and
that's
just
not
something
people
expect
so
yeah.
That's
why
my
vote
is
to
remove
them
from
as
you
list
for
an
eye
and
then
maybe
circle
back
later.
B
B
I
agree
with
requirements
we
should.
We
should
fix
our
back
pedal
for
now
and
I'm
happy
to
take
the
heat
for
that
one
just
so
we
get
it
right
because,
right
now,
I
think
it's
causing
more
problems
than
good.
It
does
show
us
where
we
want
to
go,
though,
which
is
nice
test
cases
I
think,
are
a
bit
more
open-ended.
I
could
go
either
way
on
those
and
I
think
whatever
is
going
to
cause
us
less
grief
from
the
engineering
side.
I
don't
want
to
delay
anything
unnecessarily.
B
So
if
there's
one
way,
that's
a
faster
way
to
develop.
If
we
isolate
it,
we
can
move
quicker.
Then
I
think
we
should
isolate
them.
If
we
can
move
quicker,
if
they're
together,
then
I'm
fine
with
keeping
them
together,
but
the
the
resultant
is
what
enables
us
to
move
quickly
and
gives
us
less
errors,
because
what
we
don't
want
to
do
is
have
to
go
fighting
bugs.
I
don't
want
to
roll
something
half
out
like
we
kind
of
different
requirements
and
then
have
to
field
six
or
seven
questions
which
takes
up
everybody's
time.
F
A
No,
they
just
they
just
redirect
and
in
the
case
of
test
cases,
if
you
try
to
visit
it
at.
A
Link
it
redirects
to
the
quality,
slash
test
cases,
id
link
which
just
supports
the
things
that
test
cases
support.
Nevertheless,
I
still
don't
think
it
makes
the
other
two
criteria.
I
don't
think
it
makes
a
lot
of
sense
in
the
issue
list,
so
yeah
I
would
vote
to
personally.
I
would
vote
to
take
them
out
of
the
issue
list
for
now,
but
I'm
open
to
dissenting
opinions,
yeah
and.
F
Then
the
thing
is
yes
yeah,
so
I
was
saying
that
the
graphql
response
that
we
get
from
the
issues
query
regardless
of
what
type
senum
that
we
have
passed
with
that
query.
The
response
contains
web
urls,
which
are
all
issue
urls.
So
even
if
the
underlying
object
is
of
type
test
case,
the
web
url
would
still
point
to
the
issues
url
for
that
particular
test
case.
H
I
don't
think
that's,
I
don't
think
that's
accurate.
I
think
so.
Test
case
is
the
one
that's
a
little
bit
different
and
we're
doing
the
same
thing
with
with
tas
in
web
url.
The
web
url
for
test
case
goes
to
the
test
case
url,
where
and
same
with
tasks
where
everything
else,
including
requirements,
goes
to
the
issues
url.
H
Maybe
when
test
cases
become
a
work
item
similar
to
tasks,
we
can
determine
what
we
want
to
show
in
the
issues
list.
Honestly,
I
prefer
like
if
we
had,
if
we
had
an
issues
list
or
a
work
item
type
list
specifically,
then
we
just
go
to
the
url
with
those
things
already
filtered
out.
So
as
a
query,
param
just
include
the
type
name
there,
but
we
can
kind
of
decide
that
in
the
future.
B
We
know
that,
but
we
want
to
make
this
as
generic
as
possible,
because
if
somebody
wants
to
copy
between
different
types
in
the
future,
it'd
be
much
easier
to
like
overlay,
a
bit
mask
or
something
than
fight
with
having
to
update
20
different
parameters
to
the
right
values
and
fix
the
code
in
10
different
places.
If
you
just
and
over
the
top
of
bitmap
that
says
it's
now
an
issue:
here's
your
bit
mask
boom
done
and
then
every
time
you
go
to
do
something
says:
am
I
allowed
to
do
that?
Based
on
this
mask?
C
Yeah,
I
think
the
plan
was
to
to
do
the
back
end,
sort
of
and
design
it
that
way
and
then
eventually
layer
on
the
ui
to
allow
customers
to
do
it
themselves
right
where
they
want.
So
it
is
important
to
keep
that
in
mind
as
we
build
this
out,
because
we're
trying
to
do
the
mvc
approach,
which
is
no
ui
and
do
it
just
for
us.
C
But
then
we
do
want
to
allow
customers
to
sort
of
be
able
to
create
new
work
item
types
and
then
specify
which
widgets
they
want
to
use
for
that
work.
Item
type
and
then
also
be
able
to
switch
between
types
seamlessly,
and
we
did.
C
I
did
ask
ubs
how
they
wanted
to
sorry
well,
anyway,
how
they
wanted
to
handle
that
or
what
their
expectations
were
whenever
you
switch
types
and
they
they
kind
of
noted,
as
long
as,
if
you
delete
data,
maybe
for
a
new
type
that
doesn't
support
the
widgets
on
the
current
type,
at
least
just
leave
a
system.
Note
logging
that
it
was
removed
or
whatever,
instead
of
and
that
way,
there's
not
a
trail,
but
we
it
would
help
solve.
C
Some
of
that,
like
problem
of
data
retention,
when
you
switch
types
and
there's
widgets
and
art,
support
and
all
other
stuff,
so.
G
Apparently,
the
design
team
found
that
there
is
this
type
selector
this
morning,
there's
a
whole
discussion
as
to
why
that
existed.
In
the
the
new
issue
view
there's
just
yeah,
it's
sort
of
an
odd
experience.
It's
also
the
current
experience,
so
people
have
learned
to
live
with
it,
but
it's.
We
should
avoid
that
when
we
get
to
work
items
for
sure.
H
D
E
C
No,
it
doesn't
we're
not
I,
I
don't
think
so.
I
think
there's
going
to
be
rules
around
the
hierarchy
in
terms
of
what
can
be
a
child
of
what
or
what
could
be
parented,
but
that
doesn't
mean
that
something
can't
exist
without
being
an
apparent.
I
just
think
it
would
be
specified
if
I
created
standalone
task.
The
only
thing
I
can
associate
to
from
a
parent
standpoint
is
whatever
the
hierarchy:
rules
dictate.
C
The
one
thing
with
the
requirements
moving
over
that
this
did
point
out
is
the
only
like
really
conflict
that
I
see
there
may
be
more
so,
but
one
of
them
is
like
a
work
item,
that's
closed
and
a
requirement
gets
archived,
and
I'm
thinking
about
this,
I'm
wondering
if
we
should
transition
work
items
to
being
archived
in
the
long
run.
C
So
these
all
show
up
also
in
reports
and
things
like
that,
which
leads
to
inaccuracies
because
more
or
less
saying,
hey,
we
completed
all
these
things,
but
there's
no
way
to
tell
if
it's
complete
or
incomplete,
that's
sort
of
the
whole
onus
behind
the
configurable
statuses,
where
what
we'll
be
able
to
support
with
that
is
sort
of
you'll
have
open
and
closed,
which
are
states
right
and
then
within
each
state.
There's
sort
of
different
buckets
of
statuses,
like
inactive,
active,
completed
and
incomplete,
and
so
what?
C
What
will
eventually
happen
is,
and
the
reason
why
you
we
want
to
have
all
these
be
open
in
the
open
state
is
because
there's
some
times
where
you
have
multiple
teams
working
on
the
same
issue
and
they
want
to
put
the
work
item
through
different
workflows,
so
think
about
a
dev
team
that
goes
through.
You
know
ready
ready
for
dev
and
dev
ready
for
review,
and
then
it
gets
handed
off
to
another
team.
C
They
want
to
be
able
to
have
like
a
burnout
chart
that
represents
their
workflow
and
it
you
can't
do
that
if,
if
everything's,
based
on
just
the
closed
state,
there's
lots
of
nuance
problems
with
that,
but
one
of
the
interesting
things
that
this
does
solve
for
us
if
we
wanted
to
use
it
is
that
you
could
maybe
set
some
of
the
completed
or
incomplete
statuses
to
auto
archive
an
issue,
but
for
cases
like
where
a
requirement
or
something
like
that,
it
would
keep
it
open
the
whole
time,
and
that
way
we
sort
of
could
move
towards.
C
This,
like
archived,
is
where
we
sort
of
hide
things
away,
and
then
you
just
have
sort
of
everything
in
open
state.
It's
what
linear
does
pretty
well
and
it's
sort
of
nice.
So
that's
just
one
way
we
could
go
about
solving
it,
I'm
not
sure
if
anyone
else
has
a
better
suggestion,
but
we
also
want
to
think
about
archiving
for
things
like
we're
doing
archiving
for
iteration
cases.
C
I
think
we
eventually
want
to
have
archiving
for
labels,
so
it
could
be
like
a
fairly
consistent
end
state
if
we
want
to
work
towards
that.
A
C
You
know
the
parent
child
rules
for
hierarchies,
your
statuses,
your
blah
blah,
and
then
they
can
go
and
tweak
the
the
knobs
and
the
dials
if
they
want
that's
like
long
long
long
term.
But
yes,
we
will
always
ship
with
some
sort
of
defaults
and
we'll
fall
back
to
our
product
principles,
which
are
you
know,
ship
the
things
the
defaults
based
on
what
we
use
and
then
let
customers
go
from
there.
B
A
B
Mean
from
what
I'm
used
to
there's
completed,
there's
closed
and
then
there's
archived
completed
means.
The
work
is
done
closed
means.
The
work
was
not
done
so
and
at
some
stage
we
closed
it
without
doing
the
work
and
archive
means
it
was
done
in
a
previous
iteration
like
so
that's
sort
of
the
history
that
I
was
used
to
when
I
came
to
get
lab,
I'm
not
saying
it's
right,
just
saying
that
that's
that's
sort
of
another
perspective
on
how
some
people
are
working.
C
B
To
think
about,
because
I've
heard
a
lot
of
people
like
farnoosh
was
complaining
about
this.
A
lot
during
release
post
time
is
just
because
it's
closed
doesn't
mean
we
did
the
work.
We
could
have
gotten
halfway
through
three,
mrs
we're
done
on
it
and
we
realized
we
didn't
want
to
do
it.
So
we
just
closed
it,
but
it
was
never
released.
It's
not
done.
It
was
closed
with
no
action.
C
I
I've
thought
about
a
lot
in
my
head.
It
it
sounds
like
it.
I
think
I
worked
it
out
in
my
head,
but
the
practical
I
don't
know
if
they'll
stand,
the
test
of
engineer
screwed
me
so
that'll
be
the
next
fun
part.
D
Yeah,
I
haven't
thought
so
further
about
this,
but
I
was
just
wondering
if
there
I
think
what
would
block
us
to
add
actually
more
states
if
it's
desired.
Like
you
mentioned,
completed
or
at
heist
I
mean
I'm
just
thinking.
If
there
is
some
poker,
why
we
couldn't
add
it
now
to
the
current
two
states,
which
are
open
and
closed,
maybe.
B
D
I
don't
know,
but
it
might
be
about
investigation.
I
mean
from
what
I
know
about
now.
We
are
quite
strict
on
backhand
side
to
just
not.
E
D
On
specific
back-end
states
like
we
would
check
statically
if
it's
closed
or
open
so
and
we
use
a
state
machine.
So
it
might
be
quite
easy
to
extend
this
with
additional
states.
Maybe.
C
Our
states
and
status
is
the
same
thing
because
I
tried
to
like
maybe
I
over
engineered
my
head,
because
I
was
thinking
that
we
couldn't.
We
didn't
want
to
introduce
any
breaking
changes
necessarily
anyway,
we
we
can
talk
about
this
offline,
but
if
it's
not
a
big
deal,
this
is
gonna.
C
This
is
like
up
next
on
our
direction
page
because
the
configurable
things,
because
the
basic
premise
is
once
you
have
a
work
item
and
then
you
we
introduce
these
statuses
and
they're
sort
of
configurable
and
that
stuff
works
out
and
they're
categorized
by
inactive,
active,
completed
and
incomplete.
C
Then
we
expose
a
mechanism,
so
customers
can
put
them
into
a
workflow
right
which
this
the
progression
workout
would
go
through.
But
then
we
can
measure
things
like
time
spent
waiting
for
work
times
in
aggregate
like
on
value
stream
reports
active
time.
So
how
much
time
is
actually
being
worked
on
this
based
on
the
statuses
and
then
for
different
type
work
item
types.
C
We
can
use
the
value
stream
analytics
back-end
to
calculate
the
average
time
it
takes
for
a
work
item
once
it
gets
picked
up
by
an
engineer
to
when
it's
done
and
then
eventually
even
like
surface
the
x
expected
completion
time
right
directly
within
a
work
item
view
depending
on
some
of
these,
like
details
and
things
like
that.
So
it's
a
little
bit
more
nuanced
than
just
a
state
machine.
C
D
A
A
Well,
in
the
interest
of
time
we've
only
10
minutes
left,
so
maybe
we
could
park
that
move
on
natalia
left,
something
read-only
current
work
item,
assignee
state.
We
have
some
issues
with
overriding
gitlab,
ui
token
selector
component
behavior
and
styles,
we'll
probably
need
to
contribute
to
good
lab
ui
to
make
our
implementation
less
hacky
cool.
Anyone
got
more
context
on
that.
I
don't
really
understand
it.
G
G
So
we
want
to
do
things
like
hiding
the
like
a
remove
button
on
a
token
when,
in
like
a
read-only
mode
or
something
like
that,
so
some
of
those
things
just
don't
really
exist
today
and
she
and
I've
been
kind
of
going
back
and
forth
on
how
to
merge
the
current
capabilities
in
the
ux.
A
Cool
thanks
I'm
going
to
mark
this
next
item
as
read
only
because
maybe
somebody
could
help
me
out
with
like
collecting
materials
for
where
we've
made
decisions
about
work
items,
and
I
mean
both
like
architectural
decisions
and
product
decisions,
because
I
think,
like
it's
becoming
like
a
little
confusing
for
people
joining,
say
spikes
where
we're
spiking
something
to
do
with
with
work
items.
I
know
we
have
architecture
blueprints.
I
know
we
have
an
issue
with
where
you've
discussed
certain
things,
but
I
don't
see
where
we've
collected
all
these
together.
A
So
if
you
have
any
thoughts
or
anything,
please
just
add
them
to
this
part
of
the
agenda.
You
can
ping
me
directly
and
I'll,
build
a
handbook
page
or
something
for
it,
but
it'd
be
good
to
have
them
in
in
one
spot,
unless
anyone
has
strong
feelings
about
that.
I'm
just
gonna
race
on
to
the
next
item,
because
we've
only
a
few
minutes
left
like
do
like
a
zoom
emoji
or
something.
If
you
have
strong
opinions
about
that.
One
like.
A
Both
right
I
mean
like,
is
there
somewhere
central
that
we're
collecting
things
like
we've,
just
like,
for
example,
we
just
designed
the
widgets
api
to
deal
with
the
fact
that
we
need
parent
child
hierarchies.
Should
we
put
that
somewhere
to
make
it
more
visible
to
people
or
is
it
sitting
like
nested
deep
in
an
mr
somewhere
in
a
conversation
you
know
things
like
these,
like
I
don't
know
the
answer,
and
so
I'm
not
criticizing
one
way
or
the
other.
A
I
just
think
that
like
or
decisions
about
things
like
in
the
first
iteration
issues
will
only
parent
tasks
and
it
will
be
one
level
deep
like.
Is
that
an
easy
decision
to?
Is
it
easy
to
find
the
single
source
of
truth
for
that
decision,
or
do
you
have
to
like
spelunk
through
discussions
and
issues
and
epics
that
look
like
they're
named
very
similarly
so
yeah?
It's?
The
reason
I
ask
is
that,
like
in
future
we're
going
to
spike
a
lot
of
these
things,
I
think
on
the
product
planning
side
anytime.
A
We
want
to
introduce
something,
and
so
it's
much
faster
to
do
that
if
you
can
access
all
the
decisions
that
were
made
along
the
way,
and
we've
also
made
a
couple
of
mistakes
already
along
the
way
here
and
we've
had
to
go
and
try
and
find
where
the
decision
was
made.
So
I
think
it
would
just
be
easier
if
there
was
one
single
place
where
all
this
stuff
was
documented.
Very
simply
and
briefly,
you
know,
but
that
may
already
be
the
case
and
that's
why
I'm
asking.
E
Yeah,
I
don't
think
it's
the
case,
but
I'd
suggest,
especially
with
work
items
that
resurface
that
in
like,
in
top
best
epic
rather
than
handbook,
it
feels
like
a
nightmare
to
how
to
go
back
to
the
handbook
and
edit
it
every
time
that
you
kind
of
make
a
change,
because
it's
in
development
a
lot
of
the
time
you
just
change
on
on
the
fly,
because
something
doesn't
work
out.
So
you
need
to
add
yet
another
restriction
where
yet
another
requirement.
E
A
Cool
all
right
thanks.
So
the
second
item
I
have
is
kind
of
related
to
that
yeah.
I'm
also
like
I'm
trying
to
investigate
why
some
mistakes
are
made
over
over
the
time
that
we've
been
designing.
These
features,
and
I
think
that,
like
it's
very
common
here
in
the
async
kind
of
environment,
to
use
like
language
kind
of
to
use,
common
terminology
for
things
and
interchangeable
words
for
the
same
things
and
then
they're
sometimes
also
used
for
other
things.
I
came
up
with
a
couple
of
examples
like
during
epic
links.
A
We
changed
the
name
about
four
times
or
we
didn't
change
the
name,
but
we
settled
on
a
name
from
what
various
people
were,
calling
it
and
then
also
with
confidential
notes.
Although
it
was
a
little
more
strict,
we
decided
like
to
change
the
name
from
confidential
notes,
but
with
work
items
in
particular.
It's
I
think
it's
pretty
pronounced.
A
So
what
I'm
proposing
is
like
we
capture
this
somewhere
in
the
handbook
or
something,
and
we
agree
on
a
set
of
terminology
for
work
items
that
we'll
use
here
on
it.
Like
so
I'll
give
you
one
that
I
do
like
all
the
time
when
I'm
talking
to
people
is,
I
say
like
one
day:
epics
will
be
issues
right,
epics
will
never
be
issues.
What
I
mean
by
that
is
epics
will
be
moved
to
the
issues
table
to
be
part
of
the
to
become
work,
items
right
and
it's
this
kind
of
like.
A
Maybe
it's
just
me
like
I'm
the
source
of
all
the
confusion,
but
I
think
it's
probably
just
common
enough
to
make
to
have
use
ambiguous
language.
So
what
I'm
thinking
is
like
we
capture
this
somewhere
right
and
we
just
have
a
bunch
of
agreed
terms
and
we
try
to
only
use
those
terms
so
we're
talking
about
the
legacy
issues
list.
We
call
it
the
legacy,
issues
list
or
the
issues
list,
but
we
agree
on
a
term
for
that
and
the
work
items
list
when
it
comes
is
something
different
again.
A
The
work
items
view
is
something
clearly
different
from
the
legacy
issue
view
right
and
we
had
that
problem
this
month,
where
we
accidentally
built
the
component
on
the
wrong
view,
because
I
guess
it's
possible
we're
interchanging
these
terms.
So
yes,
like
I'm
open
to
any
thoughts.
Where
should
this
page
go?
Do
you
think
this
is
not
a
good
idea
or
pedantic
or
whatever
too
much
effort
fine,
but
yeah
any
feedback.
C
I
think
it
would.
I
think
it
would
make
a
lot
of
sense,
as
you
kind
of
like
heard
earlier
nick
had
to
explain
what
type
was
and
what
that
feel
was
on
the
work.
The
task
view
right,
which
is
the
new
work
item
view,
and
if
it's
the
only
my
only
suggestion,
was
putting
it
on
the
that
work
items
page.
C
So
that
way,
if
we're
in
an
mr,
if
we're
talking
slack
or
whatever
it's
sort
of
in
this
more
official
place,
instead
of
like
a
team
handbook
page-
and
it
would
be
more,
it
seems
like
efficiency
for
the
right
group
comes
to
mind.
It
would
be
easier
to
share
that
out,
and
it's
also
would
be
a
little
bit
more
discoverable
for
anybody
who
happens
to
assemble
a
crossword
kind
of
stuff
when
looking
at
development
docs.
But
I
like
standardizing
on
names,
I
think
it's
really
important.
Sid
would
also
agree
too.
C
A
E
Yeah
I
was
going
to
we
have
a
couple
more
minutes.
I
guess.
E
Is
there
anything
else,
so
I
was
going
to
to
say
about
the
the
breaking
things
and
so
on,
but
like
us
all,
and
especially
like
from
for
myself,
with
different
as
engineers
or
engineers,
to
push
back
a
bit
more
when
we
introduce
these
kind
of
changes
like
the
displaying
different
items
in
the
issue
is
to
to
go
greenfield
as
much
as
possible
so
that
we
don't
change
current
behavior
in
any
way.
E
I
know
it's
like
tempting,
especially
for
me
as
engineer,
because
we
do
some
back-end
code
and
everything
just
works
out
of
the
boxer
to
say
because
they're
like
it's,
not
that
difficult
to
show
all
the
types,
but
it
usually
has
like
consequences
that
we
don't
think
about
in
the
ux
ui
and
so
on.
E
So
I
I
I'm
thinking,
I
know
it's
more
work
usually
to
do
the
greenfield
stuff
because
you
kind
of
have
to
at
least
maintain
two
different
states
of
the
same
thing
for
a
period
of
time,
but
it
feels
like
we
would
break
less
things
for
the
customers.
It
makes
it
more
difficult
for
us,
but
but
easier
and
less
confusing
for
the
customer,
so
yeah
I
just
like
at
the
team
level.
A
Yeah
fully
agreed,
I
think,
the
issues
list,
these
items
appearing
in
the
issues
list
was
specifically
a
regression.
It
wasn't
intended
ever
to
happen
and
it,
and
there
were
a
few
things
we
could
retrospect
at
the
end
of
51,
to
figure
out
like
why
that
happened
and
what
we
could
do
in
future
to
avoid
it.
But
I
think
your
general
point
that
we
should
be
trying
to
build
more
like
like
not
disrupt
what
people
are
already
using.
E
Yeah,
like
even
with
the
tasks,
I
know
it's
working
and
everything
like
that,
but
I
I
feel
like
it
would
have
maybe
been
somewhat
better
to
to
keep
the
issues.
This
is,
and
maybe
I
can
add,
a
work
items
list
that
will
now
have
included
the
tasks
and
the
issues
and
then
from
there.
Even
if
you
break
it,
you
kind
of
don't
affect
the
old
workflows
and
people
can
go
back
and
do
their
stuff.
E
The
old
way
as
we
develop
an
iterate
on
the
on
on
something
new
right,
so
yeah,
just
in
those
in
kind
of
those
terms
to
think
maybe
moving
forward.