The Harvesting process and the BFAV

Hi guys.

The BFAV has become the technical basis for harvesting progress. In this
it has improved the rate of harvesting by removing much of the dirty
work that was involved in the old processes. It has improved the
efficiency of the approvals many fold.

It has also allowed us to elaborate the process by adding the quality
tags, and for the first time having a more or less closed list of
patches to be dealt with.

The purpose of the QA tags was to distribute the work of harvesting
among more people, by allowing casual participants to help by reviewing
or testing code without accepting the responsibility of the formal role
of harvester. 

As the efficiency of approvals went up, and we have an in-squeak list of
posts and their full status, it has become much more visible that our
bottleneck is not approvals. It is very clearly in the reviewing/testing
stage. The reasons are very clear - rather few people help with the
reviews/testing, and that quite sporadically. 

This bottleneck is a result of our current structure, and won't go away
by itself. It causes a situation where most patches meant for the squeak
image are ignored. I think this is not likely to last - either we
balance this by removing the bottleneck, or contributors of patches will
balance it by posting less, an outcome I find regrettable.

In fact, I think it likely that people are already deciding not to post
fixes they have available because they're likely to be ignored.
Therefore, I think that if we can remove the bottleneck, and reach a
state where patches submitted are all processed in reasonable time, we
will get far more patches, and be able to make much better progress than
we are now. 

I think the following steps are in order -
1. We want to lower the barriers to casual participation. So, the BFAV,
as a prerequisite for participating, should never be absent for anyone.
It should be included in the base image.
2. We should improve and simplify the tools to help reviewers/testers do
their job. 
- ClassBoxes, when they're ready, could become a big aid to testing, by
allowing patches to be installed temporarily and then completely
removed.
- The BFAV should be improved, especially for casual users. Brent, I
recommend to open its development so more people can help with this. The
Swiki page is already pretty good, just point to it from the help in the
BFAV. Also it might be good that its future development be carried on
using Monticello, to make it easier to create and integrate
improvements. 
3. The current flood of BFAV traffic makes people automatically ignore
the harvesting process. Therefore it MUST be selectively moved away from
squeak-dev. Cees, or whoever has administrative rights on lists.sqf.org,
can you please create a new mailing list called "squeak-harvest"? This
fits Berts existing filters. Having this list would allow some
selectivity without losing information.
4. When all is said and done, many people currently won't participate no
matter how low the barriers are made, because of different priorities.
Some of this is obviously reasonable, people need to pay the rent and
play with whats fun for them, of course. But some of this is IMO not
reasonable, and comes from a misperception. I think the NewLook code
showcases this very clearly. The voices for its inclusion are very loud,
but nobody bothers to review it, therefore, it isn't included. So I
guess that the people doing the requesting somehow fail to perceive that
the condition for inclusion is within their grasp. Of course, I could
just be wrong about this. Ideas to solve this or alternative
explanations would be welcome.

Daniel