Details
-
Suggestion
-
Resolution: Won't Do
Description
NOTE: This suggestion is for JIRA Cloud. Using JIRA Server? See the corresponding suggestion.
For the last 4 months I been using JIRA a lot. As JIRA bug master I have a "reason" to really use JIRA. And the way it works affects the way I can work.
I think JIRA needs a new feature. Lets call them Lists.
A JIRA List is simply a set issues that have be "placed" together into the list. Simple as that.
Why Not Filters
Filters are "views" on some data. If the issue data has matching attributes, then it presented by the filter. When it not longer
has matching attributes, its not.
Lists differ in that once an issue is added to the list, it stays there. An issue's data attributes can change as much as you
like but they are still in the list.
One does have to ensure that the data stays stable with lists compared to filters. If you have a filter looking for unresolved bugs in v3.13.3 and some one changes the version accidently, then its out of the filter. But with a list the inclusion condition is that at one point it was added to the list.
Lists Are More Personal
Lists are more personal and/or more specific than filters. If I create a list its because I have decided what needs to go into it.
Its not data attributes but rather human reasoning that puts issues in lists.
I figure having lists in JIRA will increase its "social value" in a sense. A group of people can be sharing a list, and making group decisions about whats in it or not.
To this end lists should be shareable (like filters and dashboards) but also have an "editable" permisson. Hence a list can be shared with a person/group/role and optionally have a "editable" flag also with that person/group/role.
Lists Are More Transient
I can imagine lists being used in an Agile teams.
For example a "weekly iteration" can be a list, created at the start of the iteration.
Time is logged against the issues in the "iteration" list.
One could imagine that lists may be able to "add" up the time logged against the issues in them.
When the iteration ends, the list can be kept or discarded.
Unfinished tasks can be put in another "iteration" list by "dragging/copying" a list (via UI checkbox selection).
Compare this to a filter scenario.
One has to have a custom field called "Iteration" or use something like Lables.
The field needs to be set the same value in
all of the issues.
The creator of the tasks/issues has to be responsible for getting the value right to include the issues in the filter.
Then when the iteration is over, the issues need to re-edited top move them to the next iteration. A lot of management overhead for a weeks list of tasks/issues, that are transient in nature.
Lists Are More Work Process Oriented
So while fitlers may tell you what things are candidates to be done, lists can be used to make a "subset" of work you planned to do.
So from the 100 bugs you could possibly do, imagine a list of the "most important", a list of the "ones needing product management review", the ones that "you thought had been addressed before", a "watch list", a "performance list" and so on.
So you can use lists as a.... wait for it... a TODO list.
Filters arent really TODO lists. Once they get large that are a less useful for this function.
I can imagine that issue sin the list have a DONE status or not WITHIN the list.
So JRA-1234 might be done in list X and not done in list Y. Contrast this with filters where once a field value is changed (say resolved) its done in all filters.
Simple Features Of Lists
A list is an arbitary set of issues.
Lists have names (editable at all times like filters)
Lists are shareable
Just like filters and dashboards
Need an extra flag to idicate that those who can see the list can edit the list
They would also be "favouritable"
Anywhere you see an issue key, you get a like to add it to a list
In the issue nav / issue view page / whereever
A pop up that shows favourite list
Also the ability to start a new list at any time
List would primarily be show in portlets
Issues can be created from within the list context
Much like the sub task quick create
List can be created from other lists
The user goes into copy mode and "selects" the issues to copy across
Maybe copy to existing lists or create a new list
Extended Features Of Lists
(These are less clear in my mind or are much harder)
List are sortable inside themselves
A bit like the issue navigator
Maybe by a standard set of fields
Maybe via a set of customizeable fields (like the issue nav)
Lists can be part of a project
No one owns it, the project does
Its on the Browse Project page
May create issues in a project can edit the lists (maybe not)
List would have a TODO nature for each issue in the list
So an issue in a list of DONE/NOT DONE in terms of that list
People can "check" off the issues as done
Lists can be retrieved/created via REST/SOAP
JQL could be used on a list
Select from list='list name' where x y z
Attachments
Issue Links
- is related to
-
JRASERVER-20616 JIRA needs support for lists of issues
- Closed