[Kst] Long Term Goals

[George Staikos]

On Tuesday 23 November 2004 18:04, Andrew Walker wrote:
> The difficult part now is to take this document and create a
> document that represents the view of a project manager. I think
> this should first involve setting a release date for 2.0 and then
> ripping out everything that can't be done by then, based on the
> resources available. This would involve getting time estimates
> for all of the major features.

  2.0 only comes out when we break compatibility.  The next release is 1.1.  I 
hope we can release it within a month to a month and a half because we need 
to get the HFI requirements in ASAP.  

> Following that would be documents from the point of view of a
> development manager. This would involve creating specifications
> for each new feature with UI mockups, highly detailed behaviour
> descriptions. This is something we have generally been very bad at
> in the past.
>
> After that comes the class and interface design, and then implemenation.

   This is an opensource project, and we have 2.5 developers at most right 
now.  No managers, no design team, etc.  The app is indeed Barth's app, and 
as procedures traditionally work in this form of development, he gets the 
last call overall.  Maintainers of various components get their say on that 
component.  Other than that, developers implement their features and if 
they're accepted (by some sort of concensus), merge them in.  This procedure 
is well proven.  We've seen how it can produce far better software nearly for 
very little money as compared with a company with a multi-million/billion 
dollar development budget and many times the number of developers.  
Furthermore, we are driven from two angles: overall end-goal, and immediate 
user needs (on a very short timescale).  The only approach we can really take 
is to work to implement the user needs with a mind toward that end-goal, and 
work directly on that end-goal when user requirements are not in the way.

   Where do we need to improve specifically?
1) When -especially-complex- or -intrustive- features are done, write a design 
document, UML, or other tools.  (See what was done with the object redesign, 
the view object design, plugins, etc.)  This is important when you might step 
on someone else's code.
2) When implementing something "majorish", discuss the approaches for design 
and implementation on the mailing list.  (Common opensource procedure, and 
works well generally.)
3) Create testcases to help avoid regressions and make sure we follow our 
specs.

UI mockups are useful for #2 sometimes, but not really always necessary.  A 
detailed list of features for a given release is really not realistic for us 
right now, though an overall vision is helpful.  "We want this sooner, we 
want that later."  We have to avoid multiplying our workload.  In addition, 
forcing various requirements for features in order to make a given release 
rarely works with projects like this.  (I know, I've done all kinds of them.)

I don't think we need to do more types of plans and specs, but just actually 
do the ones that are already typically done.  (again, see devel-docs, 
although some have been removed because they're obsolete)  I am most 
concerned with making sure that one of our biggest features - internal object 
design - on which I spent a very large amount of time, is preserved.  This is 
important for so many reasons that are very obvious in the futures document.  
Beyond that, there is not much wrong with a bazaar model for Kst, and infact 
I think it's the -best- approach.  It is very effective for 2.5 developers or 
less, it is well proven, and it's easily accessible for newcomers.  Afterall, 
the platform that Kst runs on was entirely built using this model.  I don't 
know of any project that is as bazaar-like as KDE.

Note: http://www.catb.org/%7Eesr/writings/cathedral-bazaar/cathedral-bazaar/

-- 
George Staikos
KDE Developer			http://www.kde.org/
Staikos Computing Services Inc.	http://www.staikos.net/