lessons from the 2.4 development cycle; looking forward toward 2.6

Just some thoughts on the how the 2.4 development cycle went.

My basic conclusion is that a 6-monthly development timetable does not,
and will not work for AbiWord:

1. The 3-month period for work on new features was too short, and number
of the things we individually wanted to do did not get finished. I think
this is to do with the fact that we are a small team of complete
volunters and it can easily happen to any number of us that from the
three months there are large chunks of time we just cannot work on
AbiWord. Were the tree to be open for longer, things might even out a
bit more.

2. The intended 3-month bugfixing period was also too short. Having put
in 3 extra months, we have done pretty well and now have a much better
product for it, and looking back I am glad that sum1 and others spoke up
clearly against releasing in early July.

My suggestion is that we plan the 2.6 cycle over 12 months, 5 months
given to work on new features and 7 months set aside for bugfixing (if
it happens that we get a good quality stable application before the end
of the 7 months, there is nothing stopping us from releasing earlier, of
course.)

Assuming 2.4 is imminent, I would suggest the following time table:

Branching early October, 2005
Uwog's dbl work more or less simultaneous with branching
Feature Freeze February 28, 2006
Expected Release September 30, 2006

Personal wishlist for 2.6 (roughly in order of priorities)

* Unicodisation of the win32 AbiWord (using unicows on win9x)
* Finish the Merge Documents command + framework for collab editing
* Reimplementation of PT as suggested by cuenca
* The Pango graphics class

Tomas

                
___________________________________________________________
To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com
Received on Thu Sep 29 18:22:42 2005