Last updated at 4:02 pm UTC on 19 November 2005
These guidelines are for the core group of Harvesters who are actively reviewing submissions during the Harvesting Process.
Need to flesh out these guidelines some more.
First some philosophy. The harvesting process is how the Squeak image gets better. So the most important thing to understand is "what is better?". Think about the fact that the Squeak images are the common basis for the experiences of lots of different Squeak users, with different knowledge levels, and also the common basis for a lot of different packages. IOW, it is an environment, and a platform.
As an environment, it needs to be pleasant and learnable in how the user experiences it, including how it looks, what tools are there and hints that help find them, and how clear the code is for those that will go read it.
As a platform, it should make it easy to write and maintain programs of all kinds. It should be as easy to understand as possible, and therefore simple. The shared infrastructure it includes should be robust.
So when thinking about approving a submission, you should consider if it improves Squeak as an environment, and improves Squeak as a platform. If a submission could live as a package, tell the author so. If the design is not robust, or the code is not clean, make sure it improves before it becomes part of the image. As a rule of thumb, every change that isn't trivial (1k) should be externally reviewed and tested before being included.
Remember that you as a harvester aren't supposed to do all the testing and reviewing yourself - anyone in the community can review, and as you get to know peoples work you can trust their opinions.
When reviewing a submission:
- Use the BFAV tool to view submissions.
- When possible, test it to see if the submission does what it claims to do, and add an [et] (externally tested) tag, especially if the submission doesn't already have a [et] tag from someone else. Same with [er], etc. (See Commenting Bugs and Fixes for details.)
- Clean up any weird formatting problems (use prettyPrinting if all else fails).
- If the submission is older, make sure it doesn't inadvertently overwrite more recent changes in the base image. You can use the ConflictChecker tool to help with this. Perhaps we should have a [cc] tag to indicate that an older submission has been run through the ConflictChecker.
- To approve a submission, post an email to the squeak-dev list with the proper subject line format, and include the [approved] tag in the subject comment.
- A harvester is generally not allowed to approve his or her own submission. (This rule has been relaxed a bit... a simple fix of less than 1K can be self-approved. But as a general rule a harvester should primarily approve other people's submissions.) If a harvester does a self-approval, an explanation should be included as to why that is being done.
- If someone objects or raises a concern after you approve the submission, but before it is incorporated, you'll need to eventually respond with another reapproval once the concern has been settled. (covered in Step 4 of the Harvesting Process)