[xtodo-developers] Development planning

[Julian Kamil]

Ok, finally, let's start some discussions...  ;-)

I think there are two major issues that we need to address almost right away, before we add any more feature implementations.

(I) The first is modularizing the code in a way that will continue to keep deployment as simple as possible, but at the same would allow different pieces to be worked on independently with minimal possibility of conflicts. 

(II) The second is to come up with a reasonable plan for developing and adding new features.

On (I), I can see at least a copule of options.  We can reorganize the existing code into a small main code and a bunch of library scripts on separate files without rewriting anything.  This will address modularity for sure.  Or, we can refactor the code and rewrite it into a collection of classes and make the whole thing be more object-oriented.  This will certainly address modularity and if we implement the classes correctly, may help with reusability as well.

At first thought I was very attracted to the OO approach.  However, after investigating the OO features of PHP I was quite disheartened.  The difference between version 4 and version 5 is very significant, especially in terms of copy-by-reference versus copy-by-value treatment.  If we were to do OO with PHP, we must do it with version 5, because version 4 is just too kludgy.  The problem is, there are way too many people running version 4 with PmWiki at present and the inertia to move to version 5 is big.  So it looks like the more practical approach is to reorganize the code without OO redesign and reimplementation at least for the upcoming XToDo 1.x, and then perhaps build XToDo 2.x with PHP5 in an OO manner.

On (II), there seems to be two different types of use cases that should drive the feature selections.  The first is that of a personal use, where the interface is fairly simple and there is not any need to provide nested to do lists, protection, action history, traceability, and so on.  The second is that of a team use, where XToDo is selected to replace something more complex like Bugzilla, for example.  The appeal is a simpler UI, administration, and integrated Wiki capabilities.  For most small projects XToDo can be ideal because it can get the team up an running fairly quickly and won't require an admin that must understand DB administration.

So I think what we need to do with respect to (II) is to identify and list those features the belong to the personal use versus team use, and then build a development and release plan to accommodate those features.

Any thoughts or comments?

Julian I. Kamil

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com