lex at cc.gatech.edu wrote:
> I disagree.  The current harvesting process is quite inefficient, and we
> need to fix it, not get even more people to work on it.  It is not a
> good use of time to go through endless patches, most of which any
> individual reviewer cannot add input to.
>[and more details]

Halleluja. Some honest to god, Colin-style "This is not working, we need
to change it" feedback. Some points I want to respond to:
1. "buearaucratic" - Marcus answered that partially - the process
actually isn't (IMO), but people sometimes experience it that way (for
reasons that may or may not depend on them). If you see a way to do
that, please say so (preferably, refer to the "official" version on the
wiki - that's what people are/should be seeing).
2. Hard to find things in the BFAV - I think you're absolutely right.
Some ideas (for anyone that wants to improve the process), in order of
increasing madness:
 - Make the BFAV order the posts according to simple criteria: dont show
topics I'm last poster on, show at top subjects I posted on at some
point, and am not last poster on...
 - Use the Bayesian text classifier in Celeste to order the rest of the
posts in order of "likely to be interesting to specific user".
 - Do something server side that annotates/autocloses fixes that are now
identical to the code in the image (because another fix got there first,
for example).
 - Use BWT algorithm to detect code duplication between different
proposed patches and notify authors so they can merge/review/complete
one anothers posts, preventing some of the duplication, and turning it
into mutual aid.
 - Use some sort of classifier (Bayes, SVM...) to detect patches that
are "unlikely to be approved", and notify the author. If people start to
classify why they don't want to approve a patch ("dont see what it
fixes", "don't understand the code", "not documented enough, what the
heck is it"...) then patch authors could even get a predicted cause for
failure in some cases.
3. Nominate Czars - actually, any approver can nominate himself czar of
something, and can approve anything in the area except his own code.
Might be a good time to designate more approvers, possibly, as you
mention, with topical powers. I do think that anyone that's going to put
code into the general system does need a little more qualification than
"first post". Don't you? if not, why? I'm thinking a little familiarity
with the process and experience (say, reviewing a few of other peoples
posts, some a bit complex) might be sufficient for most.
4. Getting new people into the process is wrong - I completely disagree.
How else are we going to find out where its broken, and how it can be
improved? we need the fresh eyes. But I do completely agree we should
also definitely fix the process/tools.

Daniel

> To put it another we, we already have TONS of volunteer effort in
> Squeak.  It is crazy to suggest that we need even more before we can
> make progress.  Somehow, we need to figure out how to rationally use the
> tons of effort we already have.
> 
> 
> To show what I am talking about, let me give you a quick story.  I
> received an email a couple of days ago asking that I resubmit a FIX and
> this time include a test case.  Actually, the post did include a test
> case; it simply wasn't in SUnit form.  When I tried to write one, I
> noticed that the code was no longer broken!  It turns out that someone
> else had fixed it, this time with a SUnit test, and had their fix
> included.
> 
> What do we see from this example?
> 
> 	1. Email was wasted because a clear fix is not done in the most perfect
> beaureacratic way.  All someone had to do was run the example one-liner
> that was broken, look at the patch, try the patch, run the code again
> and see that it was fixed.
> 	
> 	2. Multiple people have fixed the same bug.  This is wasteful.
> 
> 	3. Everyone is having trouble searching BFAV.  At least two people did
> not realize the same bug had already been fixed: the person who emailed
> me, and the other person who fixed it.  I myself wasted time trying to
> build a SUnit test case for something that had already been fixed
> without my noticing.
> 		
> 	4. On the whole, much more effort was expended talking about this bug
> and the different fixes, than was spent solving the problem itself. 
> This patch changes two lines of code, for a grand total of 14
> characters.  (It changes "Number" to "Integer" in two places.)  Even
> going through an expedited cross examination would have been overkill
> for such a tiny patch, but when you look at the quite slow process that
> happened in practice, it is truly awesome how inefficient we were at
> dealing with this bug.
> 
> 	
> 
> My favorite direction to go in would be to put reasonable people in
> charge of various parts of Squeak, as we have already begun to do so. 
> And if some part of Squeak is too obscure for anyone to volunteer as the
> maintainer of it, we shouldn't lose too much sleep that it is not being
> maintained.  Once maintainers are in place, we can trust those guys to
> do the right thing most of the time and not subject them to lots of
> cross examination on every little change.
> 
> If there is a problem with getting people to volunteer, then perhaps the
> first person to post a fix to a new area should get a chance to become
> the maintainer for that part.  After all, they new enough to fix
> something, so they have to be a reasonable choice.
> 
> Anyway, to make this approach work really well, BFAV would need to have
> tags for which part of the system a bug report is associated with, and
> it should be possible for people to reassign those tags.  Alternatively,
> of course, we could use any existing off-the-shelf bug tracker; all of
> the ones I've seen have this functionality.  Even email might work
> better, honestly, if we also had a swiki page listing the points of
> contact for each portion of the system.
> 
> At any rate, let's please back off from trying to recruit more people to
> get out of the car and push.  Let's focus on getting the engine started.
> 
> Lex