During the last years, I became more and more doubtful and regretted
that decision. In hindsight, the fundamental conflict was present
already in the original discussion.
My own experience showed me again and again: skipping the hard work
of specification for sake of some kind of fluid prototyping rarely
leads to anything solid. If "time to market" counts, this can be
a viable strategy though...
Considering this since some time, since it more and more occurred to me
the existing conventional names are a misfit. And they are dull and clumsy.
This fall, I mentioned it to Benny, and he seemed to be rather favourable towards that idea,
which encourages me just to go ahead. Unfortunately, I am alone on the coding frontier
right now, which has several downsides, but at least it gives me the ability
to pull off radical moves.
initial draft of an RfC to discuss and define the
requirements for other parts of the application to relie on
note: this commit fixes a merge error; the RfC was lost
while combining documentation and code branches
This reverts commit 65bae31de4103abb7d7b6fd004a8315973d3144a.
and reprocessed the wrapping.
Note that the automatic wrapping is not perfect, some manual fixing
by removing some hunks was required.
* new directory structure in doc/devel to take RFC's
rfc/ - Final RFC's
rfc_pending/ - Emerging RFC's
rfc_dropped/ - Rejected or Parked RFC's
* Template directory doc/template/ for just a rfc.txt
for creating new RFC's yet
* admin/rfc.sh a script to maintain RFC's
