clean-up: drop superseded or obsoleted RfCs

See added comments for the reason

doc/devel/rfc/AllPluginInterfacesAreC.txt

@@ -173,8 +173,8 @@ documented in the repository (tiddlywiki/source)
 
 ct:: '2007-07-11 13:10:07'
 
-
+.State -> Dropped
-Development took another direction over course of the years;
+Development took another direction over the course of the years;
 Lumiera is not based on a _generic plug-in Architecture_ and the topic
 of interfaces for _dedicated plugins_ still needs to be worked out
 
@@ -190,12 +190,12 @@ Architecture. Experience with high-profile projects based on such a concept seem
 to show both tremendous possibilities, especially regarding user involvement, but
 at the same time also indicate serious problems with long-term sustainability.
 
-The practical development -- mostly driven ahead by _Ichthyo_ -- thus never really
+The practical development -- after some point mostly driven ahead by _Ichthyo_ -- never
-embraced that idea; rather structuring by internal interfaces and contracts was
+really embraced that idea; rather structuring by internal interfaces and contracts was
 preferred. The basic system for loading of Plug-ins, as indicated by this proposal,
 is still used though to load some dedicated plug-ins, most notably the GUI.
 
-To draw an conclusion: this proposal is now considered as *rejected*.
+To draw a conclusion: this proposal is now considered as *rejected*.
 Instead, Ticket https://issues.lumiera.org/ticket/1212[#1212 »Extension Concept«]
 was added to the list of relevant
 https://issues.lumiera.org/report/17[»Focus Topics«] for further development.

doc/devel/rfc/ApplicationStructure.txt

@@ -62,7 +62,7 @@ Then our application structure looks somewhat like (please refine):
   - ...
 
 Furthermore the interface and plugin system is flexible enough to provide things
-independently of their origin (if it is build in or a plugin/dynamic library).
+independently of their origin (if it is either built-in or a plugin/dynamic library).
 So deployment (where to link these things) is secondary.
 
 `"lumiera"` will then be the executable the user starts up,

doc/devel/rfc/CCodingStyleGuide.txt

@@ -3,7 +3,7 @@ Design Process : C Coding Style Guide
 
 [options="autowidth"]
 |====================================
-|*State*       | _Final_
+|*State*       | _Dropped_
 |*Date*        | _2007-07-03_
 |*Proposed by* | ct
 |====================================
@@ -212,5 +212,32 @@ point'', i.e. every point in the system, that can be extended by plugins.
 
 Ichthyostega:: '2007-07-10T17:23:33Z'
 
+
+.State -> Dropped
+During the last years, I have read this RfC several times, and I am still
+not sure what this proposal wanted to achieve, and what was the intention of
+proposing it this way. +
+A ``C coding style'', a ``naming system'' meant to be very verbose,
+but not intended to be about design, yet ``technically not needed when
+using the plugin system'' -- which all together touches at
+questions of design for sure.
+
+In the early stages of the project, there was a debate revolving around the
+idea of bootstrapping the application from a tiny core, with pretty much
+any functionality assembled from plugins, and internal functions being
+callable directly from Lua code. Combined with a low-ceremony, distributed,
+collaborative working style, such a setup was linked to the promise of
+fluid evolution of ideas in order to try out unconventional solutions
+and see what works best.
+
+Personally, this premise made me feel queasy, because I had a clear vision
+in my head, which required to build some rather advanced and challenging
+structures. Mastering complexity means to segregate and settle parts of a
+problem in order to avoid excess interdependencies. I'd rather attempt
+to deflect and redirect flexibility and differentiation towards the
+periphery and establish stable yet generic structures in the core.
+
+Ichthyostega:: '2025-09-16'
+
 ''''
 Back to link:/x/DesignProcess.html[Lumiera Design Process overview]

doc/devel/rfc/GitCommitMessageFormat.txt

@@ -5,7 +5,7 @@ Git Commit Message Format
 
 [options="autowidth"]
 |====================================
-|*State*       | _Final_
+|*State*       | _Dropped_
 |*Date*        | _Fr 31 Aug 2012 03:54:14 CEST_
 |*Proposed by* | Christian Thaeter <ct@pipapo.org>
 |====================================
@@ -20,8 +20,8 @@ Description
 -----------
 //description: add a detailed description:
 
-Git commit messages are almost free form text, the only exception is that git
+Git commit messages are almost free form text, the only exception is that Git
-threats the first line in a commit message specially to form the header one
+treats the first line in a commit message specially to form the header one
 sees in various outputs.
 
 Since we aim to automate some processing we refine the format for commit
@@ -174,6 +174,51 @@ We decided on the sept. 2012 devel meeting to finlize this RFC.
 Christian Thaeter:: 'Do 13 Sep 2012 03:57:23 CEST' ~<ct@pipapo.org>~
 
 
+NOTE: This RfC is now superseded by using the _Git-flow branching scheme._
+
+.State -> Dropped
+
+With the recent move to link:{ldoc}/technical/code/GitBranching.html[Git-flow]
+we acknowledge now -- by employing a branch model -- that the project history
+is _built_ and _conducted_ consciously, _by us._ In the current stage,
+it is not the goal of this project to churn out a stream of commits,
+using an automated production line to push some metrics high.
+
+Since any automation comes at a cost and incurs burdens and limitations,
+it should be employed to solve actual problems, but should not
+be introduced prematurely:
+
+- we spend most of our time with finding suitable solutions, not with
+  coding them up. When a part is completed, some time can be spent
+  to document it and to consolidate the history. Thus, leaving
+  formalised WIP and STASH marks is besides the point.
+
+- releases and even bugfixes require forethought, analysis, verification
+  and reflection. The extra time required to set a git tag manually, or
+  even to perform a merge, is negligible in comparison, and does not
+  justify the weight of automation.
+
+- documentation is written in the context of solving actual problems;
+  it is pointless to spot ``documentation commits'' by some markers,
+  because their relevance is already obvious from a meaningful context.
+
+- Git bisect is an essential tool when working with a code base which you
+  do not understand. With a well-crafted yet ambitious system the situation
+  is quite distinct: in such a system, the change which caused the breakage
+  is obvious and easy to spot -- while the actual challenge is to
+  understand _why_ difficulties arose -- not to mention the amount
+  of work required to develop a path of escape from a real dilemma.
+
+This RfC highlights some general considerations however, which remain
+valid anyway: to provide a short commit summary in the first line,
+and then, after an empty line, to provide a description for
+anything that is non-obvious, possibly with cross-references to
+tickets, URLs pointing to external sources and anything that might
+provide meaningful context for someone looking at this change
+years later. And, commit messages should be line-wrapped.
+
+Ichthyostega:: '2025-09-16'
+
 //endof_comments:
 
 ''''

doc/devel/rfc/RefactorLiblumieraOut.txt

@@ -5,7 +5,7 @@ Refactor Liblumiera Out
 
 [options="autowidth"]
 |====================================
-|*State*       | _Idea_
+|*State*       | _Dropped_
 |*Date*        | _Fr 22 Apr 2011 10:46:50 CEST_
 |*Proposed by* | Christian Thaeter <ct@pipapo.org>
 |====================================
@@ -226,8 +226,25 @@ Comments
 --------
 //comments: append below
 
+.State -> Dropped
+Ongoing development over the following years (after 2011) helped to clarify the situation
+regarding the support library in Lumiera. The improved language standards, most notably C++14,
+obsoleted most of the ad-hoc solutions in our library, since many aspects of system
+integration are now handled by language and STL facilities in a satisfactory way.
+On the other hand, by using the heightened capabilities of the language, some solution
+patterns very specific to Lumiera could be established, gradually turning the support
+library into some kind of an application framework.
+
+It is quite common in the field of software development to put great hopes into code
+reuse -- yet it is this very tendency towards a framework which prevents that ideal
+from playing out as anticipated, in practice. What seems to work best is to look
+at some well-made piece of software, understand how it works, and then to copy
+and extract parts in order to transform it into _your own solution._
+
+Ichthyostega:: '2025-09-16'
 
 //endof_comments:
 
+
 ''''
 Back to link:/x/DesignProcess.html[Lumiera Design Process overview]

doc/devel/rfc/SemanticTags.txt

@@ -5,7 +5,7 @@ Semantic tags
 
 [options="autowidth"]
 |====================================
-|*State*       | _Idea_
+|*State*       | _Dropped_
 |*Date*        | _Do 30 Aug 2012 21:06:54 CEST_
 |*Proposed by* | Christian Thaeter <ct@pipapo.org>
 |====================================
@@ -13,7 +13,7 @@ Semantic tags
 ********************************************************************************
 .Abstract
 We have a lot documentation which needs to be cross referenced. Adding well the
-known 'tags' concept and extend it slightly with some semantics will aid future
+known `tags' concept and extend it slightly with some semantics will aid future
 automatic processing.
 ********************************************************************************
 
@@ -21,15 +21,15 @@ Description
 -----------
 //description: add a detailed description:
 
-Every document (including sourcecode) could extended with some metadata, aka tags
+Every document (including sourcecode) could be extended with some metadata,
-which are then used to build automatic crossreferences.
+aka. ``tags'', which are then used to build automatic crossreferences.
 
-Commonly tags are just 'words' which are picked up and crossreferenceds. I propose
+Commonly tags are _just words_ which are picked up and cross referenced. I propose
 to extend this scheme slightly.
 
 Overall this scheme must be very natual and easy to use. A user should not need to
-know about the underlying machinery and a tag as in a single lowercase 'word' should
+know about the underlying machinery and a tag as in a single lowercase `"word"`
-be sufficient in almost all cases. Moreover Tags should be optional.
+should be sufficient in almost all cases. Moreover Tags should be optional.
 
 
 .Ontology
@@ -127,10 +127,13 @@ It is very urgent and important that we make our content much easier accessible.
 
 
 
-//Conclusion
+Conclusion
-//----------
+----------
 //conclusion: When approved (this proposal becomes a Final)
 //            write some conclusions about its process:
+⛔ This proposal was never expanded upon.
+While containing some interesting ideas, in its current form
+it is not deemed helpful for the project.
 
 
 
@@ -141,7 +144,7 @@ Comments
 
 //edit comment
 You may recall this proposal created some heated debate at the last developer meeting.
-After thinking it over some time, I can see now more clearly what irritated me.
+After thinking it over some time, I can _see now more clearly what irritated me._
 
 . for me, the proposal seems somewhat to lack focus. Right now we have some shortcomings at
   rather basic operations when *authoring content* at the website. This proposal tends to be more
@@ -192,6 +195,21 @@ reader will somehow ``get it''.
 Ichthyostega:: 'Mi 10 Okt 2012 05:36:35 CEST' ~<prg@ichthyostega.de>~
 
 
+.State -> Dropped
+It is now _many years later,_ and no further discussion happened, nor did
+anyone care to address the urgent practical needs related to stable cross-links
+when authoring the website content.
+
+- -> link:{rfc}/WebsiteSupportMarkup.html[Cross-links and Website support markup]
+- -> link:{rfc}/WebsiteNavigation.html[Website Navigation Menu]
+
+This proposal contains some intriguing ideas -- yet these ideas require more
+dedicated work to transform them into a closed specification, which can be
+judged for practicability. I would rather propose to start from the much
+more concrete issue with the cross-links and develop a matching algorithm
+which is sufficient to generate a ``linkfarm'' entry
+
+Ichthyostega:: '2025-09-17'
 
 //endof_comments:
 

doc/devel/rfc/TodoLists.txt

@@ -1,6 +1,9 @@
+How to organize work?
+=====================
+
 [options="autowidth"]
 |====================================
-|*State*       | _Parked_
+|*State*       | _Dropped_
 |*Date*        | _2008-03-05_
 |*Proposed by* | ct
 |====================================
@@ -12,30 +15,12 @@ We need some way to organize tasks to be done (tiddlywiki, testsuite, ...?)
 
 Description
 ~~~~~~~~~~~
+Cehteh::
+``I want something which doesn’t need much human care and I want one big `milestones' thing
+and a small `mini-task' thing''
 
-
+Ichthyo::
-Tasks
+could be refined as as `Roadmap' and `Near time task list'
-^^^^^
-
-
-Pros
-^^^^
-
-
-
-Cons
-^^^^
-
-
-
-Alternatives
-^^^^^^^^^^^^
-
-
-
-Rationale
-^^^^^^^^^
-
 
 
 
@@ -43,8 +28,51 @@ Rationale
 
 Comments
 --------
-We decided to use a Tiddlywiki for now until this is further worked out
+Discussed in the link:{ldoc}/devel/meeting_summary/2008-03-06.html#_idea_todo_lists[March.2008 developer meeting]. +
+We decided to use a TiddlyWiki for now until this is further worked out
 
 ct:: '2008-03-08T03:38:50Z'
 
+....
+​
+​
+​
+​
+​
+....
+
+.looking back at another era...
+What shall I say, just Whew! 😖
+
+For context, I can recall that _Cehteh_ had a very pronounced aversion against bugtrackers
+(and especially Bugzilla), because they are just plain confusing, filled with obsolete
+information and last but not least, they create spurious work without being helpful
+for the developer. Wouldn't it be much better to put everything into the code or
+close to the code (as markup in comments)? Git would propagate this information
+to the community of other contributors, which would decide about what is viable,
+just simply by merging or not merging -- and some clever tool could watch the
+resulting commit stream and extract the minimum necessary accounting to
+supply the developers with that amount of information
+ they need to be actually productive....
+
+.State -> Dropped
+Lumiera is quite another kind of project today. There _is_ a https://issues.lumiera.org/[Bugtracker],
+and I need all kinds of meta-tickets, tags, overview lists, the content in documentation pages plus
+my own personal notes in several mindmaps just to cope with the sheer amount of information and not
+to forget about matters already decided and settled.
+
+_All this meta-work takes a considerable amount of effort,_ for sure. +
+Yet the question remains, how can I ``keep track'' without keeping track?
+How can I judge and decide, without actually performing the judgement to arrive at a decision?
+Would it make any difference to this dilemma, if ``someone else'' were to perform that work??
+
+Can this kind of immaterial mental work be conditioned and commodified into an industrial process,
+so that the individual person might side-step the effort, yet sill remain a sovereign?
+
+[purple]#I do not know the answer to this question.#
+
+Ichthyostega:: '2025-09-18'
+
+
+''''
 Back to link:/x/DesignProcess.html[Lumiera Design Process overview]