OpenSocial Specification Definition Process

...

• OpenSocial Foundation's Contribution Licensing Agreement Submissions
• OpenSocial Foundation's Corporate Contribution Licensing Agreement Submissions
• OpenSocial Foundation's Non-Assert Agreement Submissions

Process Details

For each versionA 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 CLA for any specification they are changing.

For each feature release, there are 5 phases:

1. Propose and agree on timeline
2. Scope: submit proposals and vote for inclusion
3. Submit a pull request with proposed specification changes
4. Prototype proposals and vote on their specifications
5. Acceptance of proposed changes by Release Manager
6. Review full specification draft
7. Final publication

For each maintenance release, we follow an abbreviated process:

1. Scope: submit specification bugs that require normative changes for inclusion in current maintenance release
2. Submit pull requests with proposed specification changes
3. Acceptance of proposed changes by Release Manager
4. Review full specification draft
5. Final publication

...

1. The contributor/author must have already submitted the OpenSocial Foundation's Contribution Licensing Agreement which licenses his/her contributions and indicates his/her intent to non-assert the final resultant specification. In the case of corporate contributions, the proper document is the OpenSocial Foundation's Corporate Contribution Licensing Agreement.
2. The proposal must be listed on the "current proposals" page of http://docs.opensocial.org and have a corresponding page on the doc with the proposal details.
3. For clarity, the subject line for the forum thread should clearly indicate the area of the specification impacted as well as the type of change being proposed.
   • Areas of the specification: OpenSocial JavaScript, gadget JavaScript, gadget XSD, markup, templates, REST, etc.
   • Types of changes: addition, clarification, breaking change

   • NOTE: Given the issues associated with introducing breaking changes, any proposals that involve a breaking change to an API that existed in the prior version MUST indicate "Breaking Change" in the subject as well.

     Panel
     A few examples:

     • New Feature Proposal: OpenSocial Templates
     • Clarification Proposal - gadget XSD - lifecycle events
     • OpenSocial REST Proposal - alignment with Portable Contacts schema - Breaking Change

...