release planning and 0.7

[Vlad Skvortsov]

Hi!

I was thinking recently about our release planning -- I feel that the 
current model doesn't work too well. Let's face it -- we don't have 
enough resources which leads to *huge* gaps between releases and hurts 
both our users (waiting half a year for a minor feature?) and us (the 
projects looks as "stalled"). I would like to heal that situation by 
switching to kind of "sprint" model, when we try to deliver a release at 
least once a month. This way we'll all feel more rewarded, get more 
feedback and gain more visibility.

 From now on, starting with release 0.7, I propose to plan the following 
way. For a release we choose a list of 10 issues, of which
* 1 is a major/architectural change;
* 3 are medium complexity;
* 6 are minor/trivial changes.

We will target a release (code freeze, in fact) in 4 weeks exactly. If 
by the end of this sprint at least 7 of the nominated issues get 
resolved, we roll out the release. Of course if all 10 get resolved 
earlier than the end of the sprint, we release earlier.

Comments? Opinions? I'll come up with proposed nominated list for 0.7 by 
the weekend.

-- 
Vlad Skvortsov, vss at 73rus.com, http://vss.73rus.com