...
- Participation is open to anyone
- Decisions are made on the public lists and repositories (not behind closed doors)
- All proceedings are captured in a public archive
- Individuals represent themselves, not companies
The discussion forum for new contributions and archive of past discussions is located in the OpenSocial Specification List.
...
Since participation is open to anyone, to help ensure OpenSocial remains freely implementable by all, the OpenSocial Foundation has created an intellectual property rights management structure to enable a broad range of contributions while still helping protect implementers of the spec. This means that, prior to contributing to the specification, individuals must sign the OpenSocial IPR agreementthe individuals must sign the CLA which incorporates the IPR Agreement and this Specification Development Process.
As an aside, in the interest of transparency and ease of shepherding, the list of IPR signees and corresponding issues are included in our public repository.
...
A specification release that changes the Major or Minor version number is considered a feature release. A maintenance release is for the inclusion of normative changes to the specification that clarify or remove design errors or flaws in the specification. Non-normative changes (editorial) do not need a formal process though contributors still need to sign the OpenSocial IPRCLA.
For each feature release, there are 6 phases:
...
For each maintenance release, we follow an abbreviated process:
- Scope: submit Specification bugs or Pull Requests for that fix that fix specification bugs for inclusion in current maintenance release
- A specification bug is any issue that requires normative changes to remove design flaws or add clarity to the specification
- Submit Specification bugs using the OpenSocial Spec repository Issue Tracker
- Acceptance of proposed changes by OSF WG Administrator
- Review full specification draft
- Final publication
...
During this phase, a given idea should be prototyped and fully specified (with an open spec pull request) for a vote. A prototype implementation is an important milestone to help ensure the specification can be well-defined, and allows more testing against expected use cases. The submitter of the Github pull request will also need to make sure they have digitally signed the OpenSocial IPR agreementCLA or their changes are ineligible for inclusion.
...
Each release will have a designated OSF WG Administrator. The Administrator for the release will accept pull requests for features that have 5 +1 votes and no -1 votes. Bugs do not require a vote. Authors must also have signed the OpenSocial IPR agreementCLA. The Administrator may also make non-normative edits to proposals as they are included into specification.
...
At the end of phase, a vote is called by OSF WG Administrator to make this an official specification will be taken (it will become official with the typical 5 +1's with no negative votes).
...
Once the group has voted to make a specification official, the OSF WG Administrator will then make the new version is ready for official publication on OpenSocial.org.
...