Versions Compared


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


  • 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):
    1. Is the ticket about 1 thing?  If not, then either split the ticket yourself or ask the submitter to do so.
    2. Does the ticket clearly state the problem? If not, then either update yourself or ask the submitter to do so.
    3. 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.
    4. 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.
    5. Does the ticket include a link to other relevant discussion (such as a clojure-dev thread, IRC conversation, etc)?
    6. 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: Rich
  • Report: Triaged tickets
  • Goal: second check on whether the bug/enhancement is worth working on and decision of whether it's suitable for the next release.
  • Actions:
    • 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)
  • Report: 
  • Goal: create a high quality ticket and patch for consideration (see sections below)
  • Actions: 
    • 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
  • Reports: 
    • Screenable tickets (for new vetted tickets with patches)
    • Incomplete tickets that have changed recently - need to re-review if submitter has updated ticket since marked Incomplete.
  • 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):
    1. Is there a patch?
    2. Is there a test?
    3. Has author signed the CA?
    4. Can you apply the patch to current source tree? 
    5. Do all tests pass?
    6. Is patch clean (no extraneous whitespace or changes outside the scope of the problem)?
    7. Are docstrings still accurate?
    8. Are there potential performance impacts? If so, what benchmarks have been performed?
    9. Does the solution follow code guidelines and look like the surrounding code in style?
    10. Does the solution imply possible similar changes elsewhere?
    11. Does the solution introduce new failure conditions that might need to be considered or documented?
    12. Does the solution change external or internal APIs that might affect users?
  • Actions:
    • Set Approval=Incomplete and add comment describing needed improvements
    • Set Approval=Screened - ticket and patch are perfect and Rich should review