- 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 of triaged ticket belowin 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
- Who: contributors (anyone with signed CA)
- Goal: create a high quality ticket and patch for consideration (see sections below)
- Edit ticket or update patch to address problems or gaps based on comments.
- Adding a new patch and changing "Patch" attribute to "Code" or "Code and Test" automatically causes a patch to move from the "Needs Patch" to the "Screenable" list of tickets. However, adding a patch to an incomplete ticket does not. Alex Miller periodically scans Incomplete tickets to see if they appear ready to go back to Screenable, and makes those state changes manually.
- Who: Screeners
- Goal: verify that ticket and patch are ready for Rich to review. The quality bar is HIGH - the ticket and patch should be perfect.
- Checks (see Creating Tickets and Developing Patches):
- Is there a patch?
- Is there a test?
- Has author signed the CA?
- Can you apply the patch to current source tree?
- Do all tests pass?
- Is patch clean (no extraneous whitespace or changes outside the scope of the problem)?
- Are docstrings still accurate?
- Are there potential performance impacts? If so, what benchmarks have been performed?
- Does the solution follow code guidelines and look like the surrounding code in style?
- Does the solution imply possible similar changes elsewhere?
- Does the solution introduce new failure conditions that might need to be considered or documented?
- Does the solution change external or internal APIs that might affect users?
- Set Approval=Incomplete and add comment describing needed improvements
- Set Approval=Screened - ticket and patch are perfect and Rich should review