Re: Development Plan

(Hopefully my vicious cutting of my original post doesn't mar the 
meaning of Phil's words.)

On Tuesday, October 29, 2002, at 06:25  PM, Philippe C.D. Robert wrote:
>>
>> 1. Produce a major feature list
>
> Yes, this would also help newcomers to understand what it is all 
> about. I suggest we create a white paper for this purpose which 
> eplains the 3DKit a little.

A white paper is good. As I said before, I'd be happy to write such a 
thing, or edit it, or whatever -- given a list of subject matter and 
general guidelines to start off. Let's just get an outline written and 
posted to this list and the website. A page or two to start would be 
plenty -- just a direction or a mission statement.
>
>> 2. Identify the functional sub-systems
>
> I am working on this. I also hope to make things as easy as possible 
> by the layout of the PB project (see the GeometryKit as an example).

Yes, I've noticed that -- I approve!
>
>> 3. Specify the code standards

> I think we should just use the GNU standards as it is a GNU project. 
> This requires reindentation of the GeometryKit as well, I assume.... 
> The rules should be available on the GNU pages. We should also add the 
> link to the 3DKit page.

Can you please reply with a link to a relevant GNU page? Is this 
GNUstep, or GNU in general which sets these standards?
>
>> 4. Dependencies
>
> Hmmm ...  this should go into the white paper mentioned above as well, 
> no? But to give a final answer the design has first to be finalised.

I agree this part cannot all be done in the early stages, but as you 
mentioned we don't want to use glu; that is an example of the kind of 
thing I mean. Crystal Space depends on libpng and zlib (and something 
else). We obviously depend on the Objective-C language and Foundation 
framework. I personally have no preferences whether the dev plan is all 
in one document or in separate documents. I would say separate 
initially -- we can combine them all later. I recommend the white paper 
server as a roadmap of the whole plan which will serve as an 
introduction -- a summary of the other sections.
>
>> 5. Construction Plan
>> The last main thing might be to map out the order that the first set 
>> of features should be addressed...
>
> I try to write a first version of such a white paper covering many of 
> these issues within the next few days. I will then post it via CVS and 
> hope that others will jump in and provide useful 
> feedback/additions/corrections.

CVS is a great way to ensure the documentation gets around. Did you 
decide on what text format the design documentation was going to be in? 
I guess all Unix-friendly formats will be handled properly (but I've 
had problems with Word documents -- not that you'd use them, but I'm 
just wondering).
>>
>
> I read your emails, it was not the wrong list..:-) It's just that I 
> try to sort out my thoughts and then I will come up with a preliminary 
> idea which I hope will cause some heavy discussions. From there we can 
> plan the further development process.
>
> I also understand that it is hard to jump into the project w/o having 
> any real code. I really try hard to change this ASAP. I am sorry that 
> it takes me so long...

Well, this is why I like the top-down approach. I mean, doing it 
committee style can suck bad, but, Phil, if you just write up an 
outline, and expand on what you already know, we can start to fill in 
the details. An initial outline would tell people what topics are under 
consideration and, importantly for sorting through later, establish the 
right terminology. Even if you don't have time to expand on anything 
now, you could put little discussion notes like, "Part A, section 1: 
[bleah] -- open for discussion", "Part A, section 2: [something] -- 
plan in progress, published ASAP", ... , "Part E, section 5: [whatever] 
-- not sure, but we _won't_ be doing such and such...".

My only problem with contributing directly right now is I have no idea 
whether anything I do will be compatible, contrary, or what. I'm 
researching and doing my own parallel work, but I don't mind if I get 
assignments or suggestions or even a list of "To Do" items as a guide 
for where to put what time/energy I have. I guess that's my major 
motivation for this -- writing up a task list so that people can 
contribute immediately, and you, Phil, don't have to feel pressure to 
meet imaginary deadlines. It's perfectly OK for you to just play 
manager sometimes.
>
>> What I do hope to do, when there is enough design-oriented material 
>> on the list, is to then assemble something, perhaps even a system to 
>> pull information out of the list archives dynamically and assemble it 
>> into a rough draft, which could be edited for clarity and cohesion. 
>> If we could identify a skeleton for the development plan 
>> documentation, like with section names or, even better, a numbering 
>> system, this data mining process would be dramatically simplified. 
>> But it's just an > idea.
>
> This would be really nice. Maybe you want to write a list of topics in 
> a first move which can then be discussed here so that material for the 
> draft can be generated for all these subjects?

I'm happy to. I expect such a list may betray my inexperience, but it 
would satisfy my need to summarize 8^).

You know, you shouldn't be afraid to cut and paste from other GPL/LGPL 
documents when and if it is suitable/permissible, at least as a first 
draft. I assume that the same rules apply to documentation as to code??

--
Brent Gulanowski				[email protected]

http://inkubator.idevgames.com/
Working together to make great software.