Uploaded image for project: 'Jira Data Center'
  1. Jira Data Center
  2. JRASERVER-20616

JIRA needs support for lists of issues

    XMLWordPrintable

Details

    • We collect Jira feedback from various sources, and we evaluate what we've collected when planning our product roadmap. To understand how this piece of feedback will be reviewed, see our Implementation of New Features Policy.

    Description

      NOTE: This suggestion is for JIRA Server. Using JIRA Cloud? 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

          Activity

            People

              Unassigned Unassigned
              bbaker ɹǝʞɐq pɐɹq
              Votes:
              9 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: