[Kst] Long Term Goals
staikos at kde.org
Wed Nov 24 04:24:55 CET 2004
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
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.
KDE Developer http://www.kde.org/
Staikos Computing Services Inc. http://www.staikos.net/
More information about the Kst