goran@krampe.se wrote:
I have also some serious doubts about schemes/models that depend on "community work". With that I mean work "by" the community "for" the community, eh, if you know what I mean - instead of work "by" yourself "for" yourself. Hmmm, Ken has a much better english than me, but he is essentially saying the same thing.
Harvesting is a typical example, an unselfish act for the good of all - not directly connected to any personal immediate need. Or trying to maintain a Universe, yes, I *do* have doubts about that model - but at the same time I want to enable it - because I may very well be wrong :).
Or staking out the image, an act which has stalled numerous times for that specific reason I think. All these activities have that in common - they are "non individual" activities relying on community members to do the work "for the benefit of all".
Three ways to help here are: assign ownership, give credit, and make issues public. Ownership means if someone does something then it's final--they don't have to go through an approval process. The opposite, where three people have to sign off on something and where flamewars can erupt over the most trivial things, makes it very discouraging to contribute work. Credit means that the opening window and maybe the web site mentions the people who contributed. We should at *least* credit the release manager, and it would probably make sense to credit harvistors as well. Making things public is things like, marking which packages have open bugs. People prefer to do work if there is a publically visible result from it.
On the specific issue of harvesting, routing of bugs would help tremendously. The times I worked on harvesting I spent at least half of my time looking at old bugs that I wasn't qualified to help with. Routing can be done by direct manual assignment of a bug to a person, or by assigning bugs to packages.
Regarding the slow progress staking out the image, please remember that the little bit of experimenting we tried on this list went well. Yet, we decided to wait until later to move on it for real. I don't think we can draw any conclusions from the slow progress in partitioning, because the problem is that everyone is waiting on the Packages Group to say what to do and we haven't spoken up yet.
I have come to the personal conclusion that schemes depending on such work have a high risk of failure in the Squeak community. We simply aren't that good at it. We are much more individualistic and we like to scratch our own itches, which means there are two things we are really good at:
It's a risk, but let's be cautious how far we take the conclusion. Remember that some volunteer things do progress well for Squeak. For example, we get plenty of bug fixes submitted for the main image. Thus, let's just say that with a mostly volunteer effort, we cannot guarantee that any particular task is going to have enough volunteers.
That doesn't mean we give up on community projects. Aside from trying to make the quality degrade gracefully when any one task is not getting sufficient volunteers, we can also take the experimental approach: try something for a while, watch what happens, and then tweak it for the next release cycle.
Lex