Playing Field

Coding Standard

The coding standard at Qi4j 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://scm.ops4j.org/repos/ops4j/projects/community/resources/

Design and Implementation work

We want all discussions around the design and implementation to happen on the development mailing list, qi4j-dev@lists.ops4j.org. 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 mailing list only.

Committers

The term "committer" is often used in open development efforts, and in Qi4j it refers to the individuals who has commit rights to a particular part of the codebase. Some subprojects in Qi4j are open to everyone, others are based on meritocracy where individuals who has been contributing to the subproject are invited by the existing committers. People who has not contributed to a subproject over the last 12 months are no longer considered committers, although the commit rights will not be revoked.

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 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 mailto:infra@lists.ops4j.org, except for the http://www.qi4j.org website, which Qi4j operate by itself.

Trademarks, Patents and Licenses

Qi4J is licensed under the Apache License version 2.0. All committers agree that all their contributions are licensed under this license to Qi4j, 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 Qi4j, other committers and the general public.
Qi4j is not trademarked anywhere in the world. If Qi4j is trademarked by anyone and not freely licensed to Qi4j, other committers and the general public, the person or organization that make such trademark looses all stakes in the Qi4j community, looses the license to the codebase and risk legal actions.
Qi4j is a community effort and is currently no organization. This may change into a non-profit, membership organization at some later point in time.