The following list is at present just a an example and a suggestion to get the
discussion going.


This textfile should currently be considered level 4 below if we were 
using something like this process. // Erik Sundvall, 5 Sep 2001


--------------

Possible example of current situation...

1. Decision (compare to W3C Recommendation):


 * The design track that is based on code from Jive 1.2.4 will continue to use the existing licence, completely unmodified, see parts of note: LicenceChoice
 * Webwork is one possible way to access the datamodel in 1.2.x (already implemented by Maurice) (No note available yet)
 * ...


2. Draft - notes have reached some consensus (compare to W3C Working Draft):

 * The new version should not require EJB to run. (No note available yet)
 * The new version should use Apache/BSD style licence or possibly Mozilla (MPL 1.1) (A majority seems to prefer Apache/BSD.) see parts of note: LicenceChoice
 * Webwork as one possible way to access the datamodel in the new version. (No note available yet)
 * ...


3. Somewhat formalized suggestions that are under consideration/debate (compare to W3C Note):

 * The data model in the new version could be based on RDF and the Prototype design pattern, see note: RdfInMeinds
 * Use/support OSCache for JSP-generated information, see note: CacheIntro
 * For storage/persistance, use plugin arcitecture with possible chaining, see note: RdfStorage
 * ...


4. Other suggestions/questions from the mailing list (compare to W3C Note):

 * Use JDO for persistance handling (it's current licence is a problem though)
 * Jini for backend scalability/stability? http://www.sun.com/jini/
 * Support JMX for administration. http://java.sun.com/products/JavaManagement/index.html
 * Reuse the idea of "filters" and "skins"
 * Use the "factory" design pattern for object creation.
 * Use Lucene as search engine http://www.lucene.com/
 * Use the process described in this file to make decisions.


---------------

Compare the list to phases in the creation of a W3C Recommendation:
http://www.w3.org/Consortium/Process-20010719/tr.html
This is a suggestion for levels in a lightweigt process inspired by W3C.

The main point of the process is to reach _consensus_
http://www.w3.org/Consortium/Process-20010719/groups.html#def-Consensus

----------------

Level 3 and 4 do not need consensus. The difference between them is that
level 3 is automatically reached when a couple of persons seriously start
discussing the issue and formalize the suggestion by writing a little note
in the notebook (or some equivalent publically accesible place).
Level 4 really does not need to be formally listed like above, I have just
done it in order to remember interesting things from the list.


To go from level 3 to 2 or from 2 to 1, inform the list that you want some 
feedback on the suggestion (either privately, through the list, or by CVS editions).
Then when you think it is ready for prime time, tell the list you want to promote 
it to next level and allow one week for final comments and consensus building.
If the week passes without any major protests/change requests consider the 
sugestion promoted one step.
If there are major protests, try to rewrite, and then start the "final week" 
procedure again. (In some cases majority voting might have to be done.)


Regarding coding I believe that we could follow the same levels. There is no
need to await consensus in order to start prototyping or other implementation. 
Consensus is more important when it comes to what we want to include in a 
official public release. For example:
1. Decision = Public file release
2. Draft = Beta version