integrate the RfC entries into the new website structure

admin/rfc.sh

@@ -358,7 +358,7 @@ create)
           -f "./doc/devel/rfc_dropped/${name}.txt" ]]; then
         echo "$name.txt exists already"
     else
-        source ./doc/template/rfc.txt >"./doc/devel/rfc_pending/${name}.txt"
+        source ./doc/devel/template_rfc.sh >"./doc/devel/rfc_pending/${name}.txt"
         edit "./doc/devel/rfc_pending/${name}.txt" 2 abstract
         git add "./doc/devel/rfc_pending/${name}.txt"
         process "./doc/devel/rfc_pending/${name}.txt"

doc/design/gui/GuiDiscussion/TimelineDiscussion.txt

@@ -1,7 +1,7 @@
 Timeline: Discussion
 ====================
-:author: Joel Holdsworth
-:revdate: Fall 2008
+:Author: Joel Holdsworth
+:Date: Fall 2008
 
 This is Joel Holdsworth's attempt to amalgamate all the ideas from all the brainstorming to one consistent idea that makes sense, can be implemented, and seems like it would be nice to use. Comments are welcome.
 

doc/devel/rfc.txt

@@ -1,23 +1,42 @@
 Design Process
 ==============
 
+//Menu:   include rfc
+//Menu:   include rfc_pending
+//Menu:   include rfc_dropped
+
+//Menu:   put child 'rfc_dropped' after 'rfc'
+
 How it Works
 ------------
+Design Process entries (RfC) can be created by anyone.
+Each entry goes through several stages until it's accepted (or rejected).
+All our RfC entries are filed here, either in the  link:rfc/index.html[RfC accepted] section,
+or as link:rfc_pending/index.html[pending RfC] or as link:rfc_dropped/index.html[RfC dropped].
 
 * Every proposal starts out as _*Idea*_, allowing other people to review and comment on it, while still working out details.
-* When the _Idea_ is in a proper shape and worked out in most details it becomes a _*Draft*_. This _Draft_ need to be carefully reviewed, commented, perhaps corrected and rated by the other Developers.
+* When the _Idea_ is in a proper shape and worked out in most details it becomes a _*Draft*_.
+  This _Draft_ need to be carefully reviewed, commented, perhaps corrected and rated by the other Developers.
 * We decide on some proposals to talk about that another time, these get a _*Parked*_ state.
-* At some point we may decide that a _Draft_ becomes a _*Final*_. Usually, this happens in our link:MonthlyMeetings[]. _Final_ Documents will be imported into the git repository (currently to the tiddlywiki).
-* Sometimes proposals will become dropped for some reason, this is indicated by changing their state to _*Dropped*_, they still stay in the system for further reference.
+* At some point we may decide that a _*Draft*_ becomes a _*Final*_.
+  Usually, this happens in our link:/devs-vault/meeting/index.html[monthly developers meetings].
+* Sometimes proposals will become dropped for some reason, this is indicated by changing their state to _*Dropped*_,
+  they still stay in the system for further reference.
 
-Generally you should refrain from editing someone others proposals (except for typo and gramatic fixes) when this is not acknowleded with the original author. Rather only add comments to the pages and end them with  `@SIG@` to make it easier to find out who is the contact person for some note.
+Generally you should refrain from editing someone others proposals (except for typo and grammar fixes)
+when this is not acknowledged with the original author. Rather only add comments to the pages and please
+care to sign your comments in order to make it easier to find out who is the contact person for some note.
 
-.Add a new Proposal:
-. Check if there is no similar proprosal below! If yes, contact it's author and contribute to that one.
-. Think of a good/descriptive *WikiName* for the Proposal. It will be used to create a RfC subpage.
-. Read the instructions and add your proposed text.
+What qualifies as an RfC proposal
+---------------------------------
+CAUTION: to be written
+
+Handling of RfC entries in practice
+-----------------------------------
+
+.Adding a new Proposal:
+. Check if there is no similar proposal below! If yes, contact it's author and contribute to that one.
+. Think of a good/descriptive _Name-ID_ for the Proposal. It will be used to create a RfC sub-page, so no embedded spaces please.
+. [red,yellow]#!TODO!# _please describe how to use the +rfc.sh+ here_.
 
 
- * link:rfc[RfC accepted]
- * link:rfc_pending[RfC pending]
- * link:rfc_dropped[RfC dropped]

doc/devel/rfc/index.txt

@@ -0,0 +1,11 @@
+Accepted Design Proposals
+=========================
+
+//Menu: label accepted
+//Menu: sort children
+
+-> read link:../rfc.html[more about Lumiera RfC] and the Design Process
+
+The RfC entries listed here where discussed, maybe modified and finally agreed upon
+during some developers meeting in the past. So they represent design decisions taken.
+

doc/devel/rfc_dropped/ApplicationStructure.txt

@@ -183,10 +183,9 @@ don't think we get much program options, maybe something to set a GUI skin.
 Moreover, I've written last year a thin wrapper around the commandline and
 integrated it with the boost options parser such that user code can receive the
 remaining options as a vector of std::strings. Please have a look at
-http://git.lumiera.org/gitweb?p=LUMIERA;a=blob;f=tests/common/mainsuite.cpp;h=45
-bfd98effd0b7dbe6597f712a1bdfa35232308;hb=HEAD[the test class runner main] for
-an usage example. I really want our Lumiera main to be clean and expressive in
-the way showed there. Probably the most important part of the startup is
+link:http://git.lumiera.org/gitweb?p=LUMIERA;a=blob;f=tests/common/mainsuite.cpp;h=455bfd98effd0b7dbe6597f712a1bdfa35232308;hb=80e1e382f42512ebf2e10a802f77e50327b8fb73[the test class runner main]
+for an usage example. I really want our Lumiera main to be clean and expressive
+in the way showed there. Probably the most important part of the startup is
 pulling up the session core; because of that I think most of the startup
 process falls into the realm of the Proc-Layer. Within Proc, I don't want any
 significant string manipulations done with C-strings and I don't want raw

doc/devel/rfc_dropped/index.txt

@@ -0,0 +1,18 @@
+Design Proposals not accepted
+=============================
+
+//Menu: label dropped
+//Menu: sort children
+
+-> read link:../rfc.html[more about Lumiera RfC] and the Design Process
+
+The RfC entries listed here where discussed, but then concluded not to be applicable
+for some reason. Either the discussion turned up a completely different solution, or
+maybe they got just superseded by changing circumstances.
+
+Besides that, sometimes we find an entry impossible to care for and discuss in detail
+currently, because we know to be occupied with other stuff. In that case, we put that
+entry ``on hold'' (state _*Parked*_). Currently (as of 2/2011) these entries show
+up in this category here too.
+
+

doc/devel/rfc_pending/index.txt

@@ -0,0 +1,21 @@
+Design Proposals in discussion
+==============================
+
+//Menu: label pending
+//Menu: sort children
+
+-> read link:../rfc.html[more about Lumiera RfC] and the Design Process
+
+The RfC entries listed here where proposed but not finally decided or agreed on --
+
+* entries in the _*Idea*_ stage are yet to be worked out in detail. Usually they
+  just sit there and only receive occasional discussions, until the original author
+  considers them mature and puts them on agenda on some developers meeting.
+* entries in the _*Draft*_ stage are basically ready for discussion or decision;
+  but sometimes they are kept _on hold_ -- maybe there is something controversial
+  or some details need to be investigated further.
+* sometimes we just decide to postpone the discussion -> see
+  link:../rfc_dropped/index.html[dropped and parked entries]
+
+
+

doc/technical/infra/MenuGen.txt

@@ -1,7 +1,7 @@
 Website Navigation Generator
 ============================
-:author: Hermann Voßeler
-:revdate: 2/2011
+:Author: Hermann Voßeler
+:Date: 2/2011
 
 
 This page contains documentation and notes regarding the +menugen.py+ --

doc/template/DIR_INFO

@@ -1 +0,0 @@
-skeletons for formal documents