History

This page outlines the (proposed) workflow for using QGIS redmine.

There is some inconsistency in managing tickets in QGIS redmine: closed tickets can have different status ("Closed","Rejected" or "Resolved"). This is a bit confusing and makes search complicated (see also #3972, #3992, #3997, #4263). I think we need create more strict rules (workflow) for tickets. Here is my proposal, feel free to discuss or modify it.

For new tickets:
  • bugs should have tracker "Bug"
  • feature requests should have tracker "Feature"
  • add a "crash or cause data corruption" tag, to allow create tickets with a very high priority (Giovanni Manghi). Not sure that we need it, there are "Urgent" and "Immediate" priorities. Is it not enough? (Alex Bruy)
When closing tickets:
  • if bug fixed - set status "Resolved" with appropriate resolution tag ("fixed")
    • If a pull request has been submitted for this issue and the patch is waiting for commiters feedback, this is the state to set (hmercier)
  • if this is duplicate and other invalid ticket, then status should be "Rejected" with appropriate resolution tag ("duplicate", "invalid", "worksforme")
  • if feature implemented - set status "Closed" with appropriate resolution tag ("fixed")
    • If a pull request has been supplied and is now accepted (hmercier)
  • if feature rejected - set status "Rejected" with appropriate resolution tag ("wontfix")

======================
Some more questions to help users filling in tickets (Alister):

Can we clearly state what properties the average user is or is not expected to set when filing a ticket?
e.g. I suspect we do want them to set the "Category" (or their best guess at which category is applicable).
We probably don't want them to set "Assigned to", "Target version", etc.
Should they fill in their platform and platform version? Or should they state this in the report, and these fields will be filled when it is established that the problem is not applicable to other platforms.

Do we need to define the "priorities" so that reporters can assign them accurately?
LOW =
NORMAL =
HIGH =
URGENT =
IMMEDIATE =
We might need to define them for both bugs and feature requests.

In the past we had this:
blocker - bugs that should block the release. Since we are going to release pretty much 'come what may' I would like no bugs allocated to this category without consultation with me [Tim] and / or PSC
critical - bugs that cause the application to crash or corrupt data
major - application features that do not function at all
minor - features that function but imerfectly e.g. labels placing incorrectly
trivial - gui useability issues or small issues with the documentation, install notes etc.