Rankings should be per-context rather than global

I have seen quite a few issues raised in the Atlassian GreenHopper project related to ranking, and I too have found several bugs and odd behaviors with the new Rapid Boards. One of which in particular was particularly relevant to my reason for creating this issue.

Since issues are tracked with a single, global ranking field, odd things happen when multiple teams want to prioritize the same piece of work differently. For example, suppose an issue is created to change a piece of common functionality shared by 2 products. Further, suppose a team independent from either product is doing the actual work. The team doing the work really is the one responsible for organizing, prioritizing and tracking the issue on their backlog. However, for planning purposes it is helpful to include the same DI on each of the products backlogs as well to ensure their releases are on schedule. Similarly, the relative importance of that work will likely be different for each of the three teams with respect to the other work on their backlog. Now suppose one team decides that the priority of this issue has changed - perhaps it is more important now so they send it to the top of their backlog. Because the ranking values are global this action indirectly affects the priority of this DI on the other two teams backlogs as well. Even worse there is no notification that this change has been made. The other two teams are left to their own accord to figure out why issue priorities are magically changing on their backlogs, assuming they notice the changes at all.

This workflow is suggestive that perhaps rank should not be a property of an issue but rather a property associated with an issue within the context of a particular backlog. Perhaps the rank could be relative within a filter (for Kanban workflows), or perhaps relative to specific sprints (for Scrum workflows). I suspect such a change would be quite invasive as it strays from the current design pattern for your tool, but I would think that it models more closely the real-world relationship between work items and teams. A piece of work, generally speaking, does not have one universally acceptable level of importance. Its importance is relative to each person tracking the work.

From a brief examination of some of the "ranking" related issues currently existing in your GreenHopper project, there are quite a few people who have tried to introduce "contextual" rankings thus working around this problem (with varying results, many causing more problems that they fix it seems), however these seem like a band-aid solutions attempting to circumvent this rather subtle design problem.

So, to summarize, I created this DI in part to report a bug with the GreenHopper global ranking mechanism however I suspect that this behavior is by design and a more significant implementation change within the tool would be required to address the issue robustly. This is why I created it with an issue type of Story rather than a bug.