svn commit: r1415614 - /stanbol/site/trunk/content/development/index.mdtext

[bd...@apache.org]

Author: bdelacretaz
Date: Fri Nov 30 13:05:51 2012
New Revision: 1415614

URL: http://svn.apache.org/viewvc?rev=1415614&view=rev
Log:
discussions, decisions and tracking

Modified:
    stanbol/site/trunk/content/development/index.mdtext

Modified: stanbol/site/trunk/content/development/index.mdtext
URL: http://svn.apache.org/viewvc/stanbol/site/trunk/content/development/index.mdtext?rev=1415614&r1=1415613&r2=1415614&view=diff
==============================================================================
--- stanbol/site/trunk/content/development/index.mdtext (original)
+++ stanbol/site/trunk/content/development/index.mdtext Fri Nov 30 13:05:51 2012
@@ -35,10 +35,25 @@ followed by the Apache Stanbol project.
   * [Coding Standards](coding.html)
   * [Release Management](release-management.html)
 
-## Documentation
+## Discussions, decisions and tracking new features
+Everything has to be discussed on the dev mailing list prior to any
+implementation action. If it is not on the list, it did not happen.
+
+New features should be backed by JIRA issues that describe the goals,
+use cases and software design decisions, which are usually the result 
+of dev list discussions. It is much easier to refer to JIRA issues describing 
+the implementation details for further discussions and later reference. 
 
-A good documentation is nearly as important as the software itself. Here you
-can find information how to contribute to it.
+The dev list is not a good place for persistent information, but JIRA issues 
+can also be used as an initial form of documentation for new 
+features: add usage and test instructions to the JIRA issues once your features
+reaches a usable state, so that others can test them. This is a good way of
+evolving the features documentation, as you work on the implementation.
 
-  * [Website Development](website.html)
+## Documentation
+As mentioned below, starting with JIRA issues that describe what you're doing and 
+how to use and test it is often good enough, and it's a good way to document things
+as you go.
 
+Once new features reach a somewhat stable state, it's good to document them on 
+the website. See [Website Development](website.html) for more info.