JIRA Audit Notes
Possible things to change:
- remove regular user permission for fields that should not be edited except by core team:
- due date, fix versions (used for release assignment), patch, approval
- this will cause the fields to simply not appear on data entry screens
- implies creation of "core" group that still do have these permissions
- RH - yes
- remove all time tracking features other than release assignment
- RH -ok
- fix default assignment (think things get assigned to project owner, currently Rich)
- RH - yes please
- create some components
- language/docs/??
- if not, then mask out component field
- RH - let's wait and see what makes sense
- How will contrib libs work?
- make sure assignment can only be done by core team
- again, wat about contrib libs?
- run the re-index (apparently necessary but makes JIRA temporarily unavailable)
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:
