- Maintain Clojure quality
- Fix problems that are important to users
- Engage the community in working toward the best possible Clojure Clojure
There are several groups involved in this process with increasing levels of responsibility:
- JIRA status- these govern the default JIRA workflow and consist of Open, In progress, Reopened, Resolved, Closed
- The Clojure workflow does not really distinguish between these much other than general open/closed differentiation
- Approval- a custom field that is (mostly) how Screeners change the state of a ticket
- None - new ticket
- Triaged - screener has approved the ticket as worth working on
- Prescreened - screener has approved the ticket and screened the patch for review
- Vetted - screener and Rich have approved the ticket as worth working on
- Screened - screener has approved a ticket's patch for review by Rich
- Incomplete - screener has requested improvements to a ticket or patch
- Ok - Rich has approved the ticket for inclusion
- Patch- qualifies the kind of patch attached
- None - no patch
- Code - code only, no test
- Code and Test - code and test
- Fix version
- Release X.X - specific targeted release
- Backlog - will consider in future release
- Resolution- when a ticket is closed, it will have a resolution
- Declined - did not accept a ticket for work
The colored blocks represent activities performed by different groups - the colors correspond to the group (Orange = contributors, Blue = screeners, Green = BDFL). Diamonds represent decisions to be made during an activity. Activities are described in more detail below the diagram.
Image RemovedImage Added
- Who: Screeners
- Report: Open tickets
- Goal: decide whether the bug or enhancement described in the ticket is actually a real bug or enhancement.
- Process (see: Creating Tickets):
- Is the ticket about 1 thing? If not, then either split the ticket yourself or ask the submitter to do so.
- Does the ticket clearly state the problem? If not, then either update yourself or ask the submitter to do so.
- For larger enhancements / features, it is probably better to suggest the submitter post to clojure-dev and then create a page on the design wiki instead.
- For bugs, there should be some demonstration that the problem actually exists (output from a repl, test, etc). Verify the problem exists in the current release of Clojure.
- Does the ticket include a link to other relevant discussion (such as a clojure-dev thread, IRC conversation, etc)?
- At this stage, it is not necessary for there to be a patch or to validate it fixes the problem.
- Actions, pick one of:
- Comment on ticket to ask for more information, better description, better demonstration of problem, etc
- Close with Resolution=Decline, reasons:
- Not a bug: submitter misunderstood or misused a feature or ticket doesn't make sense
- Scope too big: feature may be better served by creating a page in the design wiki than in a ticket
- Enhancement not wanted: enhancement is not something we want to do
- Duplicate: of existing ticket
- Too many things: break this ticket apart into smaller pieces
- Set Approval=Triaged - problem is ok
- If needed, adjust ticket to standards in Creating Tickets
- Who: Screeners
- Report: Triaged tickets
- Goal: improve the ticket and screen the patch before Rich does vetting, allows faster path through the remainder of the process
- Set Approval=Prescreened - patch is ok
- Comment on ticket regarding issues with patch (leaves in Triaged)
- Who: Rich
- Report: Triaged and Prescreened tickets
- Goal: second check on whether the bug/enhancement is worth working on and decision of whether it's suitable for the next release.
- Close w Resolution=Declined - as above, ticket may not be something we want to address
- Set Approval=Vetted - problem is good