> > I disagree on Level2. This is not possible to do. Its just to much
> > work to use a static document to manage all this information.
> I have not thought of a static document but of listed documents; my
> drift here is to make "working" feature descriptions, relevant
> discussion and proposals available in an easy accessible way which the
> forum mailing list cannot provide. Ideally I would see a list of well
> documented "working" features, and each could have a "tail" of
> discussion papers adjacent to it, where any people could comment
> (message board). Of course this list should never have any claim for
> completeness, but be just an offer for a working aid.
> Ok, I will reconsider the SF stuff - and agree to put the idea aside for
> now. If we can fill that with life what we already agreed on, would make
> my very happy indeed. ;)
I recommend you again to examine the sourceforge stuff. In my
opinion you can easily achieve the goals you stated with the things
sourceforge offers. For example every bug-report/feature-request/todo-list
has the ability to append comments and sometimes even files.
We have a discussion forum and can create how much forums we need.
We even have a system to take surveys (Umfragen)! And note that
we have a mailinglist-archive (sadly without a search option).
> For that, I have added below an outline proposal for a html doc scheme
> for the project homepage. I think this is the right place for it. - Then
> one of the first references and docs there should be about "Ant"!
If you want to find out more about ant visit http://jakarta.apache.org/ant/.
You are right. I already thought about it, too. I'm going to add this
to our dependy page.
> #START PROPOSAL
> User Documentation
> - unforseeable future -
As I already stated in another message, I'm going to create a framework
for this, too. But yeah, you are right: The contents _in detail_ is
at the current state "unforseeable" ;-)
> Developer Documenation
> A. Support Files
> a) Rules and Standards
> (What developers for Columba must know and should consider)
> b) Utilities
> (Docs and references for tools and libraries from external
> sources; everything non-trivial which is not developed by ourselves)
> B. Program Documentation
> 1. About Program Documentation
> 2. Level 1 : Program Layer Documentation
> a) Functional layers
> b) Source Packages
> c) Externalized Data Structures (files)
> C. History
> - Feature Change History (doc)
> #END PROPOSAL
This looks very good to me. The only thing, which we should discuss, is
if we should really add feature change history to the developer documentation.
We already have a changelog of the most important changes in our
distribution packages and on our website:
We don't need this information in the developer documentation, in my
Thanks for your input,