Cees De Groot wrote:
> Certainly. Even though people usually just scratch their itches (which
> makes it hard to predict which features will be built :-)), usually
> one or more people sign up for, say, a release and they are usually
> committed to do some grunt work, stick with what is agreed, etcetera -
> just as in a regular project. The biggest difference is probably that
> you don't know how much time people will be able to give.

Sure, you don't want people to not be able to 'play', at least in this 
kind of community. If you defined the backlog of stories as being things 
that would be fully integrated and potentially releasable, then at least 
you would know where you stood with respects to how fast you are burning 
stories that have been agreed to by the community.

The main difficulty is going to be maintaining a backlog where everybody 
in the community is a stakeholder, and everybody in the community will 
be estimating stories.

> I think the most important thing we're not doing is timeboxing.
> Releases should be time-based, not feature-based. This keeps things
> cooking so to say - regular releases will put some pressure on working
> towards "we can release at any moment" systems: daily builds,
> automated testing, etcetera. Releasing twice a year or even quarterly
> also makes the feedback loop shorter (and thus better), so the
> community can better steer the course of development. Finally, short
> release sprints will make it easier for people to sign up and even
> commit time - I can predict in advance how much time I can spend the
> next quarter. I cannot predict in advance how much time I can spend
> until, say, the original 3.9 feature list is complete. In fact, I
> changed jobs in the meantime and I've switched from full-time Squeaker
> to something very different :-).
> 
> I'd suggest a major release per year (so you can break backwards
> compatibility once a year :-)), and a point release per quarter.

Can't fault your conclusion there.

Cheers

Daniel