Where we are going with partitioning and harvesting etc.

[Lex Spoon]

goran at 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