svn commit: r872417 - in /websites/staging/maven/trunk/content: ./ maven-site-1.0-site.jar project-roles.html

[bu...@apache.org]

Author: buildbot
Date: Fri Aug  2 09:53:57 2013
New Revision: 872417

Log:
Staging update by buildbot for maven

Modified:
    websites/staging/maven/trunk/content/   (props changed)
    websites/staging/maven/trunk/content/maven-site-1.0-site.jar
    websites/staging/maven/trunk/content/project-roles.html

Propchange: websites/staging/maven/trunk/content/
------------------------------------------------------------------------------
--- cms:source-revision (original)
+++ cms:source-revision Fri Aug  2 09:53:57 2013
@@ -1 +1 @@
-1509583
+1509594

Modified: websites/staging/maven/trunk/content/maven-site-1.0-site.jar
==============================================================================
Binary files - no diff available.

Modified: websites/staging/maven/trunk/content/project-roles.html
==============================================================================
--- websites/staging/maven/trunk/content/project-roles.html (original)
+++ websites/staging/maven/trunk/content/project-roles.html Fri Aug  2 09:53:57 2013
@@ -306,27 +306,68 @@ under the License. --><h1>Apache Maven P
 
 <ul>
   
-<li>Proposing active contributors for committership,</li>
+<li>Active management of those projects identified by the resolution of the Board  of Directors of the Apache Foundation;</li>
   
-<li>Binding votes in project decisions,</li>
+<li>Ensure the project remains a healthy top-level project of the Apache Foundation  (if a PMC member wants the project to be hosted elsewhere they should resign  from the PMC stating their reason - if the PMC shrinks beyond the minimal viable  size then as a result of a desire by the bulk of the PMC to move the project  elsewhere, the Board of the Apache Foundation will take that into account  when moving the project into the Foundation&#x2019;s Attic)</li>
   
-<li>Voting on release artifacts,</li>
+<li>Prepare reports as required by the Board of the Apache Foundation and  ensure those reports are ready for presentation by the PMC Chair in a timely  manner;</li>
   
-<li>Ensure <a href="/developers/index.html#Developers_Conventions">Developers Conventions</a> are followed, or updated/improved if necessary,</li>
+<li>Defend the trademarks belonging to the project;</li>
   
-<li>
-  <!-- TODO: get the rest of these --></li>
+<li>Proposing active contributors for committership;</li>
+  
+<li>Ensure that votes in the community are used as a tool to establish consensus  and not a weapon to disenfranchise or alienate a minority of the community;</li>
+  
+<li>Binding votes in project decisions;</li>
+  
+<li>Ensure that code committed to the project is either committed under a valid CLA  or is code that was contributed with a clear indication that the Apache License  applied (i.e. small patches submitted to the issue tracker or to the mailing list  are assumed to be submitted with the intent of being covered by the Apache  License unless the submitter clearly marks those patches as not being covered)</li>
+  
+<li>Ensure that third part dependencies shipped as part of the project&#x2019;s releases  are covered by a compatible license.</li>
+  
+<li>Voting on release artifacts;</li>
+  
+<li>Ensure <a href="/developers/index.html#Developers_Conventions">Developers Conventions</a> are followed, or updated/improved if necessary;</li>
 </ul>
 <div class="section">
 <h4>Standards for Community Commitment<a name="Standards_for_Community_Commitment"></a></h4>
-<p>In the spirit of supporting the health of our community, Project Management Committee members refrain from actions that subvert the functioning of the committee itself.</p>
-<p>First, Project Management Committee members should not maintain long-running forks of Maven code outside of the project itself. Making significant changes to Maven code outside of the project displays a lack of investment in the community. Additionally, attempting to re-integrate a large number of code changes in bulk overwhelms the ability of volunteers in the community to review (and potentially veto) the changes. This effectively thwarts the policing function of the PMC.</p>
-<p>Second, Project Management Committee members should not divert work on redesigning, reimplementing, or improving Maven code to alternative projects outside of this community for the purposes of reintroducing them as replacement for existing Maven code. While there is a danger here of falling into a Not Invented Here mentality, new projects created by Maven PMC members strictly to replace Maven code should not be allowed.</p></div></div>
+<p>In the spirit of supporting the health of our community, Project Management Committee members refrain from actions that subvert the functioning of the committee itself.</p></div>
+<div class="section">
+<h4>Promotion of other projects<a name="Promotion_of_other_projects"></a></h4>
+<p>The Apache Foundation currently does not have a policy requiring projects to cross-promote. For example Subversion is an Apache project, yet projects are free to choose from Subversion and GIT (a non-Apache project) for source control.</p>
+<p>When considering integration of technologies within Maven, there is thus no requirement that other Apache projects be picked over non-Apache projects.</p>
+<p>The primary requirements for picking technologies to integrate with Maven are thus:</p>
+
+<ul>
+  
+<li>A compatible license, i.e. Category A or Category B</li>
+  
+<li>A good technical fit</li>
+  
+<li>A strong preference on behalf of the portion of the community that  will be doing the integration.</li>
+</ul>
+<p>Where a PMC member is advocating a specific technology, they should declare any interest / involvement that they have in that technology or a competing technology - irrespective of whether the project is an Apache project or a project hosted elsewhere.</p>
+<p>PMC members with a stated interest / involvement should try to abstain from making binding votes in either direction with respect to the relevant technology choices.</p></div>
+<div class="section">
+<h4>Forks of the project codebase<a name="Forks_of_the_project_codebase"></a></h4>
+<p>All code that gets released by the community should have sufficient opertunity for review both:</p>
+
+<ul>
+  
+<li>By the PMC, to check the legal responsibilities delegated by  the Board; and</li>
+  
+<li>By the committers (which includes the PMC), to check that the technical  direction and quality is in line with the consensus roadmap.</li>
+</ul>
+<p>It is self evident that the opertunity for review is much greater if the code is committed to the project&#x2019;s source control as early as possible. Similarly small commits are easier to review than large commits.</p>
+<p>There is nothing inherently wrong with maintaining a fork of the Maven codebase outside of the Apache Foundation. Individual developers can have their own style of working and may prefer to work in a fork so that they can throw away failed experiments with less visibility (though it could be argued that the visibility of such failed experiments can be valuable documentation for others). As soon as changes in that fork are identified which should be brought back to the project those changes should be introduced into at least a branch hosted on the Apache Maven source control in order to facilitate the easier review by the community.</p>
+<p>The PMC should encourage by example the early committing of changes from a fork back to Apache Maven source control. </p>
+<p>Similarly, if a fork is being hosted elsewhere in order to get contributions from other talented individuals, the PMC members should endevour to bring those individuals and their tallent to the project as committers.</p>
+<p>Finally, where a fork is hosted outside of Apache hardware, there is less traceability of the code provenance, for example GIT commits can be squashed and history re-written to mask or otherwise hide the source of contributions. This does not mean that code coming from an external fork inherently has such issues, instead it means that the requirements for review and verification of provenance grow exponentially when dealing with large sets of changes originating from a long running fork hosted outside of Apache foundation source control. Anybody maintaining a long running fork should be aware of the risk that review obligations may grow above the time capabilities of the PMC and committers such that when they eventually decide to try and bring the changes in their fork back to the Apache Maven project their contribution may end up being rejected on the basis of the review of a large set of changes being too difficult/timeconsuming.</p></div></div>
 <div class="section">
 <h3><a class="externalLink" href="http://www.apache.org/foundation/how-it-works.html#pmc-chair">Project Management Chair</a><a name="Project_Management_Chair"></a></h3>
 <p>For various legal reasons, there are certain things that the Apache Software Foundation can only delegate to an officer of the foundation.</p>
 <p>The Project Management Committee is responsible for nominating the lucky victim who gets made an officer of the foundation (subject to the approval of the board).</p>
-<p>This person then becomes the interface between the board and the project management committee. They do not have any other additional gravitas in the project, it is the Project Management Committee as a whole that is responsible for the direction of the project.</p></div></div>
+<p>This person then becomes the interface between the board and the project management committee. They do not have any other additional gravitas in the project, it is the Project Management Committee as a whole that is responsible for the direction of the project.</p>
+<p>If things break down and there is no consensus and there is no clear ability to reach any conclusion <i>and</i> it is in the interest of the foundation because damage is done and the board expects the chair to act as an officier of the foundation and clean things up, then the chair can act as an ultimate decision maker, however, by this point the board of the foundation must already be well aware of the situation and should be actively monitoring the chair.</p></div></div>
       </div>
     </div>
     <div class="clear">