Issue Workflow

Hey everyone,

I have already talked to Rob about this when dealing with the Show/ Hide tree behavior. There were some different expectations with the search panel behavior as well. I would like to make issue tracking a bit more structured.

Bitbucket issues are a watered down version of JIRA's agile issues. Similar to JIRA I would like to format the issues into 2 main sections to avoid misunderstandings or different expectations of implementation. While we might be clear on the overall picture, the devil is too often in the details.

It shouldn't be very verbose, two main sections with a short sequence of bullet points is really enough.

1) User Story/ Use Case In case of a bug, describe steps how to reproduce the bug/ when it is occurring. If it seemingly occurs at random just add what was going on on screen (e.g. clustering/ navigating the matrix etc.) For proposals/ features explain how you as a user would like to experience it and how it is different from the current implementation. Describe the expectation of behavior you have for the feature (e.g. If the user clicks button X then Y should happen instead of Z.) 2) Acceptance criteria
A list that complements the story/ use case with details. Unless every point on this list can be checked off as completed/ implemented, the issue may not be closed. 3) Attachments Like usual: data sets, screenshots, mockups etc. This would help a great deal and avoid going back and forth on single issues.

Chris

Comments (5)