svn commit: r844738 - in /websites/staging/stanbol/trunk/content: ./ development/index.html

[bu...@apache.org]

Author: buildbot
Date: Thu Jan  3 09:56:35 2013
New Revision: 844738

Log:
Staging update by buildbot for stanbol

Modified:
    websites/staging/stanbol/trunk/content/   (props changed)
    websites/staging/stanbol/trunk/content/development/index.html

Propchange: websites/staging/stanbol/trunk/content/
------------------------------------------------------------------------------
--- cms:source-revision (original)
+++ cms:source-revision Thu Jan  3 09:56:35 2013
@@ -1 +1 @@
-1428248
+1428250

Modified: websites/staging/stanbol/trunk/content/development/index.html
==============================================================================
--- websites/staging/stanbol/trunk/content/development/index.html (original)
+++ websites/staging/stanbol/trunk/content/development/index.html Thu Jan  3 09:56:35 2013
@@ -87,8 +87,18 @@
       <ul> <li><a href="/">Home</a></li> <li class="item"><a href="/development/">Development</a></li> </ul>
     </div>
     <h1 class="title">Development</h1>
-    <p>This site documents development related issues when working with the
-Apache Stanbol source code and contributing to it.</p>
+    <p>This site documents development related issues when working with the Apache Stanbol source code and contributing to it.</p>
+<p>Everything has to be discussed on the developer <a href="#mailing_lists">mailing list</a> prior to any
+implementation action. If it is not on the list, it did not happen.</p>
+<p>New features should be backed by <a href="#issue_tracking">JIRA issues</a> 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. </p>
+<p>The developers list is not a good place for persistent information, but JIRA issues 
+can also be used as an initial form of <a href="#documentation">documentation</a> 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.</p>
 <p><a name="mailing_lists"></a></p>
 <h2 id="mailing-lists">Mailing Lists</h2>
 <p>The Apache Stanbol projects uses mailing lists to exchange all relevant information. If something was not mentioned and discussed on the mailing list it did not happen.</p>
@@ -159,24 +169,13 @@ followed by the Apache Stanbol project.<
 <li><a href="security.html">Security Aware Coding</a></li>
 <li><a href="release-management.html">Release Management</a></li>
 </ul>
-<h2 id="discussions-decisions-and-tracking-new-features">Discussions, Decisions and Tracking new Features</h2>
-<p>Everything has to be discussed on the developer <a href="#mailing_lists">mailing list</a> prior to any
-implementation action. If it is not on the list, it did not happen.</p>
-<p>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. </p>
-<p>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.</p>
+<p><a name="documentation"></a></p>
 <h2 id="documentation">Documentation</h2>
-<p>As mentioned below, starting with JIRA issues that describe what you're doing and 
+<p>For a first documentation 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.</p>
-<p>Once new features reach a somewhat stable state, it's good to document them on 
-the website. See <a href="website.html">Website Development</a> for more info.</p>
+<p>Once new features reach a somewhat stable state, it's good to
+<a href="website.html">document them on the website</a>.</p>
   </div>
   
   <div id="footer">