Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


  • No extraneous changes (whitespace, unrelated mods, etc)
  • Docstrings should be adjusted if necessary
  • Test should be included if at all possible



ReportProjectStatusApprovalPatchFix versionResolution
VettedCLJO/IP/ROVetted NULL 
Needs PatchCLJO/IP/ROVettedNULL<nextRelease> 
IncompleteCLJO/IP/ROIncomplete <nextRelease> 
ScreenableCLJO/IP/ROVettedNOT NULL<nextRelease> 
OkCLJO/IP/ROOk <nextRelease> 


BacklogCLJR/C  Backlog, Approved Backlog 
DeclinedCLJR/C   Declined


  • O/IP/RO = Open / In Progress / Reopened
  • R/C = Resolved / Closed
Additional JIRA changes that may be useful:
  • Shared filter noise: 
    • We could lock down the Global Permission for Sharing Objects so that only a small group can share filters (this would reduce shared filter noise at the expense of someone not being able to share something useful)
    • A select group (currently Jira administrators) can change ownership of filters which allows them to take ownership and modify existing filters - this might be useful in maintaining a standard set
    • Could create filter naming conventions but no way to enforce that 
  • CLJ project "versions"
    • There are functions (latestReleasedVersion and earliestUnreleasedVersion) that would be very useful in making the reports above constant across releases but the latest/earliest is based on lexical sorting and right now things like "Approved Backlog" sort prior to all other "Release x.y". We could change naming schemes to make this better. It is typical for people to use just numbers "1.4" instead of "Release 1.4" in other JIRA projects for example. This has a side effect of sorting all versions ahead of pseudo stuff.
  • Deprecated fields
    • Approval - "Not Approved" and "Test" are not used in current process and could go away
    • Fix version - currently have "Approved Backlog", "Backlog", "Reviewed Backlog" which can all just be "Backlog" per Rich
    • Patch - many possible values right now but largely Code and Code&Test are the two that are used. Simplify?
  • Workflow
    • We could actually define and use a JIRA workflow to manage this process rather than our own conventions
    • Chas has built experimental versions of this. Might need to change process a bit.
    • This would make the workflow more concrete and would reduce many simple errors by requiring fields to be set at certain transitions, etc.