Playing field
dev@polygene.apache.org mailing list is a collaborative effort of open development, and we need to have some rules in place to make that work.
Below is an evolving list of rules and guidelines that we try to follow.
Coding Standard
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 https://github.com/apache/polygene-java/tree/develop/etc.
Design and Implementation work
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.
Community Structure
Committers
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. )
Project Management Committee
Apache has a concept called Project Management Committee (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.
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.
PMC Chair & VP of Apache Polygene™
The PMC Chair is an appointment by the Board, and acts as the link between the project and the Board, primarily for so called oversight, i.e. that the Board has knowledge of any community issues in a project. The PMC Chair is an Officer 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.Votes on releases
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.
Incompatibility is not a reason within the 0.x series and not a reason between major versions, such as 1.3 -> 2.0.
Reverts of commits
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.
Infrastructure issues
Any infrastructure requests or problems, should be directed to the dev@polygene.apache.org mailing list.
Trademarks, Patents and Licenses
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.
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.
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.