View Source

Not all tickets are created equal. What follows is a conversation starter about how tickets should be prioritized by the core team:

type	impact	complexity	patch included?	core will typically	typical urgency
defect	high	low	yes	screen	highest
defect	high	low	no	vet, implement, screen	high
defect	high	high	yes	screen	high
defect	high	high	no	vet, implement, screen	medium
defect	low	low	yes	screen	medium
defect	low	low	no	vet	medium
defect	low	high	yes	screen	medium
defect	low	high	no	vet	medium
enhancement	high	low	yes	screen	low
enhancement	high	low	no	vet, implement, screen	low
enhancement	high	high	yes	screen	low
enhancement	high	high	no	vet, implement, screen	low
enhancement	low	low	yes	screen	none
enhancement	low	low	no	vet	none
enhancement	low	high	yes	screen	none
enhancement	low	high	no	vet	none

How this maps to the current JIRA workflow:

defect and enhancement are ticket types
impact is not tracked as a field
complexity is not tracked as a field. Maybe I should use the work "subtlety" here. A thing is complex if it interplays with other things. Things are often more complex than they look!
patch is tracked explicitly with the "patch" custom field, and implicitly by presence of attachments
core team's actions are tracked by workflow and by the "Approval" custom field
urgency is not directly tracked, but can be inferred from
- scheduled release (most useful!)
- priority (less useful)

Not captured in this picture:

Core team will mark tickets as acceptance: incomplete when more information is needed.