src/community/playing_field.html - polygene-website - Git at Google

 ---
 title: Playing field
 layout: default
 ---
 <div class="page-header">
     <h1>Playing field</h1>
     <p class="lead">
         <a href="http://mail-archives.apache.org/mod_mbox/polygene-dev/" target="_blank">dev@polygene.apache.org</a> mailing list is a collaborative effort of open development, and we need to have some rules in place to make that work.
         <br/>
         Below is an evolving list of rules and guidelines that we try to follow.
     </p>
 </div>

 <div class="row-fluid">
     <div class="span2"></div>
     <div class="span8">


         <h2>Coding Standard</h2>
         <p>
             The coding standard at Apache Polygene™ promotes whitespace to aid in reading the code. Opening braces are placed on new lines,
             spaces are between operators and so forth. We are following the OPS4J coding standards, as they have IDEA, Eclipse and
             Checkstyle templates prepared or in the works. These are slowly evolving, and it is likely we will evolve with them.
             The coding standards can be found in
             <a href="https://github.com/apache/polygene-java/tree/develop/etc">https://github.com/apache/polygene-java/tree/develop/etc</a>.
         </p>

         <h2>Design and Implementation work</h2>
         <p>
             We want all discussions around the design and implementation to happen on the dev@polygene.apache.org mailing list.
             But we also recognize that instant messaging, voice and face-2-face are important tools to
             increase productivity. The participants are expected to convey in a comprehensible format (not just a copy/paste of
             the IM log) any new development, ideas and progress that occur during those sessions. The decisions for any multiple
             choices should be made on the dev@polygene.apache.org mailing list only.
         </p>
         <h2>Community Structure</h2>
         <h3>Committers</h3>
         <p>
             rights to the codebase. Committers are invited by other committers, typically after some contribution via JIRA (Pull Requests
             The term "committer" is often used in open development efforts, and in Apache Polygene™ it refers to the individuals who has commit
             are not yet fully supported by the Apache infrastructure, but may change in the future. )
         </p>

         <h3>Project Management Committee</h3>
         <p>
             Apache has a concept called <i>Project Management Committee</i> (or PMC for short), which is the stewards of the codebase/project.
             It is up to each PMC to define the rules for the project, who gets invited, the workflow for changes and evrything else
             that is not required from the Foundation itself, such as Licensing, Releases, Branding and source control management.
         </p>
         <p>
             At Apache Polygene™, we want to see all active committers to be part of the PMC. To have a voice of the future of the project.
             Committers that are inactive are encouraged to resign from the PMC, but will retain the committer status and invited back
             to the PMC again, once activity picks up. This will not be enforced, but purely on voluntary basis.
         </p>
         <h3>PMC Chair & VP of Apache Polygene™</h3>
             The PMC Chair is an appointment by the Board, and acts as the link between the project and the Board, primarily for so called
             <i>oversight</i>, i.e. that the Board has knowledge of any community issues in a project. The PMC Chair is an <i>Officer</i>
             of the Foundation, but in reality the Chair is a glorified secretary, responsible for providing a short report once every
             quarter and answer any questions that the Board may have.

         <h2>Votes on releases</h2>
         <p>
             All committers agree that all releases should be voted upon before the release is made. Releases should happen early
             and often, to shorten the feedback loop. All committers of the subproject being released has a binding vote. Everyone
             else has a vote of recommendation. Releases can be vetoed for two reasons; Incompatibility and Legal.
         </p>
         <p>
             Incompatibility is not a reason within the 0.x series and not a reason between major versions, such as 1.3 -> 2.0.
         </p>

         <h2>Reverts of commits</h2>
         <p>
             There are cases when we need to revert commits made by people. Common sense should rule, but the above cases of
             incompatibility and legal reasons are two obvious examples. Sabotage, misunderstandings and mistakes are others.
             When such cause arises, the issue should be brought to the dev@polygene.apache.org mailing list, explained why the
             commit should be reverted, and if noone objects within 48 hours, the commit can be reverted. If the concern results
             in a debate, then the issue is resolved in a simple majority vote among the committers.
         </p>

         <h2>Infrastructure issues</h2>
         <p>
             Any infrastructure requests or problems, should be directed to the dev@polygene.apache.org mailing list.
         </p>

         <h2>Trademarks, Patents and Licenses</h2>
         <p>
             Apache Polygene™ is licensed under the Apache License version 2.0. All committers agree that all their contributions are licensed
             under this license to Apache Polygene™, other committers and the general public. The Copyright of each contribution is held by the
             contributor, and no Copyright assigns are required.
         </p>
         <p>
             All committers assert that no patents are hidden within their contributions or that if such patent exists then such
             patent is freely licensed to Apache Polygene™, other committers and the general public.
         </p>
         <p>
             All contributors agree that the Apache Polygene™ project may change to a later version of the Apache License, if/when such license
             becomes available and the Core Dev Team at that time finds it appropriate.
         </p>

     </div>
     <div class="span2"></div>
 </div>
	---
	title: Playing field
	layout: default
	---
	<div class="page-header">
	<h1>Playing field</h1>
	<p class="lead">
	<a href="http://mail-archives.apache.org/mod_mbox/polygene-dev/" target="_blank">dev@polygene.apache.org</a> mailing list is a collaborative effort of open development, and we need to have some rules in place to make that work.
	<br/>
	Below is an evolving list of rules and guidelines that we try to follow.
	</p>
	</div>

	<div class="row-fluid">
	<div class="span2"></div>
	<div class="span8">


	<h2>Coding Standard</h2>
	<p>
	The coding standard at Apache Polygene™ promotes whitespace to aid in reading the code. Opening braces are placed on new lines,
	spaces are between operators and so forth. We are following the OPS4J coding standards, as they have IDEA, Eclipse and
	Checkstyle templates prepared or in the works. These are slowly evolving, and it is likely we will evolve with them.
	The coding standards can be found in
	<a href="https://github.com/apache/polygene-java/tree/develop/etc">https://github.com/apache/polygene-java/tree/develop/etc</a>.
	</p>

	<h2>Design and Implementation work</h2>
	<p>
	We want all discussions around the design and implementation to happen on the dev@polygene.apache.org mailing list.
	But we also recognize that instant messaging, voice and face-2-face are important tools to
	increase productivity. The participants are expected to convey in a comprehensible format (not just a copy/paste of
	the IM log) any new development, ideas and progress that occur during those sessions. The decisions for any multiple
	choices should be made on the dev@polygene.apache.org mailing list only.
	</p>
	<h2>Community Structure</h2>
	<h3>Committers</h3>
	<p>
	rights to the codebase. Committers are invited by other committers, typically after some contribution via JIRA (Pull Requests
	The term "committer" is often used in open development efforts, and in Apache Polygene™ it refers to the individuals who has commit
	are not yet fully supported by the Apache infrastructure, but may change in the future. )
	</p>

	<h3>Project Management Committee</h3>
	<p>
	Apache has a concept called <i>Project Management Committee</i> (or PMC for short), which is the stewards of the codebase/project.
	It is up to each PMC to define the rules for the project, who gets invited, the workflow for changes and evrything else
	that is not required from the Foundation itself, such as Licensing, Releases, Branding and source control management.
	</p>
	<p>
	At Apache Polygene™, we want to see all active committers to be part of the PMC. To have a voice of the future of the project.
	Committers that are inactive are encouraged to resign from the PMC, but will retain the committer status and invited back
	to the PMC again, once activity picks up. This will not be enforced, but purely on voluntary basis.
	</p>
	<h3>PMC Chair & VP of Apache Polygene™</h3>
	The PMC Chair is an appointment by the Board, and acts as the link between the project and the Board, primarily for so called
	<i>oversight</i>, i.e. that the Board has knowledge of any community issues in a project. The PMC Chair is an <i>Officer</i>
	of the Foundation, but in reality the Chair is a glorified secretary, responsible for providing a short report once every
	quarter and answer any questions that the Board may have.

	<h2>Votes on releases</h2>
	<p>
	All committers agree that all releases should be voted upon before the release is made. Releases should happen early
	and often, to shorten the feedback loop. All committers of the subproject being released has a binding vote. Everyone
	else has a vote of recommendation. Releases can be vetoed for two reasons; Incompatibility and Legal.
	</p>
	<p>
	Incompatibility is not a reason within the 0.x series and not a reason between major versions, such as 1.3 -> 2.0.
	</p>

	<h2>Reverts of commits</h2>
	<p>
	There are cases when we need to revert commits made by people. Common sense should rule, but the above cases of
	incompatibility and legal reasons are two obvious examples. Sabotage, misunderstandings and mistakes are others.
	When such cause arises, the issue should be brought to the dev@polygene.apache.org mailing list, explained why the
	commit should be reverted, and if noone objects within 48 hours, the commit can be reverted. If the concern results
	in a debate, then the issue is resolved in a simple majority vote among the committers.
	</p>

	<h2>Infrastructure issues</h2>
	<p>
	Any infrastructure requests or problems, should be directed to the dev@polygene.apache.org mailing list.
	</p>

	<h2>Trademarks, Patents and Licenses</h2>
	<p>
	Apache Polygene™ is licensed under the Apache License version 2.0. All committers agree that all their contributions are licensed
	under this license to Apache Polygene™, other committers and the general public. The Copyright of each contribution is held by the
	contributor, and no Copyright assigns are required.
	</p>
	<p>
	All committers assert that no patents are hidden within their contributions or that if such patent exists then such
	patent is freely licensed to Apache Polygene™, other committers and the general public.
	</p>
	<p>
	All contributors agree that the Apache Polygene™ project may change to a later version of the Apache License, if/when such license
	becomes available and the Core Dev Team at that time finds it appropriate.
	</p>

	</div>
	<div class="span2"></div>
	</div>