You are viewing an old version of this page. View the current version.
Compare with Current |
View Page History
Design Notes
- be mimimalist: we are trying to spend our time innovating in Clojure, not JIRA!
- capture existing Assembla data with fidelity
- capture Relevance best practices across a variety of ticketing systems
- avoid language that presumes defects (or even software)
- state names represent motion toward goal (usually)
- states are almost implied by roles
- don't stay open, or re-open: use references
Basic Workflow
- Open | Vetted | In Dev | Ready to Screen | Screened | Accepted | Completed (Closed)
- Patch status not part of workflow
- field for no patch | patch | patch + test
- no special "pushed back a step" statuses
- e.g. no "Returned to Dev"
- maybe add field for "pushed backwards at any point"
- ticket types: defect | enhancement | task
- resolutions: completed | declined | duplicate | incomplete
Issues
- name choices
- vetted ~ ready for dev, approved for dev
- accepted ~ OK
- mechanisms for prodding for action
- no equivalent to showcase
- does it all work in JIRA?
- JIRA out of the box not even close
- I am reduced to hand-editing XML already. Seems to work, but ouch!
- Can JIRA enforce workflow constraints?
- Where does this get documented?
Labels: