links to this page:    
View this PageEdit this PageUploads to this PageHistory of this PageTop of the SwikiRecent ChangesSearch the SwikiHelp Guide
Harvesting guidelines
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.

Reviewing Submissions

When reviewing a submission:

Approving Submissions