The job of screening is to create a funnel, so that the highest importance, highest urgency items are brought to the BDFL's attention first, already vetted and tested.

Choosing Tickets to Screen

  1. Bugs first, then features. Most users do not edit the issue type or severity fields, so most tickets start marked as bugs, and job 1 is to recategorize them.
  2. Focus on tickets with code. If there isn't code yet, you will have to write it, and have someone else screen it.
  3. No new features during Beta. The most a feature request can hope for during Beta is to be assigned the "Approved Backlog" release
  4. Do the important bugs first. There is no AI query to find these. One obvious criterion for importance is difficulty of workaround. Another is regression. Another is upvoted issues.
  5. Vote up issues you think important.

Fail Fast

Reasons to decline a ticket:

The following are required in the ticket. Mark the ticket incomplete if any are missing (or fix the gap if you can):

  1. Clear description of the problem.
  2. For defects, a reproducing case in a basic repl (no gists, no external github projects, no jars, etc unless absolutely necessary due to AOT etc).
  3. For defects, a description of the cause of the problem.
  4. The approach to fixing the problem (or implementing the enhancement). This should explain (as a narrative) the change in the patch.
  5. For changes that have a performance impact, a performance analysis. Results should be in a table showing before and after timings. Example code to reproduce the timings should be either linked or included. Specify the Clojure and Java version used to take the timings.
  6. The name of the patch to consider (unless there is only one patch, and even then, it wouldn't hurt).
  7. Links to background discussions or other relevant material a screener should read.

The following are required in the patch. Mark the ticket incomplete if any are missing:

  1. Patch file should end in .patch or .diff.
  2. Commit message should start with the ticket id and have a brief 1 line description of the change. Optionally, it may have a longer description after that.
  3. Patch should be in proper format and include tests.

Want to Become a Screener?

Screeners are a subset of contributors who are responsible for moving tickets through a review process, and then funneling tickets to the BDFL.

It would be great to have more screeners. If you are interested, just do all the steps described in this document, without actually changing any ticket attributes. Instead, add a comment to the ticket explaining what you would have done to screen it. (Screeners: keep an eye out for such comments, and where sensible provide feedback so that we are grooming more screeners.)

Process in Detail

Periodically, screeners will review tickets whose approval is marked 'Test'.

To apply someone's changes you need to first create a branch:

$ git checkout -b freds_fixbug42
$ git am --keep-cr -s --ignore-whitespace < their-patch-file.diff

Once you have a working copy, you should take note of the following kinds of things:

After review, if you are happy, you should

If you are not happy, but the ticket is fixable:

If you are not happy, and the ticket does not seem fixable

If you aren't sure