OpenSocial and gadgets Specification Definition Process (Draft) Background OpenSocial is a community product, which isn’t owned by any one company or individual, and it is important that the technical specification is driven by that community. This document outlines the steps by which that community operates to make changes to the OpenSocial and underlying gadgets specification. The basic idea is to treat the specification as an open source project, and thus we can borrow many of the tenants from the Apache Software Foundation, which is well-known to help foster high-quality communities (and software):
This document describes the process for the OpenSocial and gadgets specification discussion group, located at: http://groups.google.com/group/opensocial-and-gadgets-spec/topics Process Overview The process is laid out to require positive agreement from at least 5 members of the community. In addition, if any negative “vote(s)” are cast, then a given proposal will not be included unless the negative vote(s) are rescinded. Since a new version of the specification does require work by a lot of parties, it is not desirable to iterate too quickly. However, since OpenSocial is still evolving, a quarterly iteration seems reasonable to enable the specification to be responsive to needs of the community. Process Details For each version, there are 5 steps:
Step 1: Propose timeline The default cycle for a new specification version is one quarter (~12 weeks). Once a timeline for a new version is proposed, after 5 days, it becomes the plan of record with at least 5 positive votes and no negative votes. Step 2: Topic ideas During this phase, suggestions and ideas can be presented to the list to get agreement on what features should be developed. Please note that all official specification proposals must be submitted as patches (to the JS, HTML, etc). Certainly, discussions leading to a proposal on the list are very appropriate, but, to ensure concise and comprehensive proposals, a change cannot be included until after it has been specified in a .patch file. Step 3: Proposals & technical discussions During this phase, a given proposal will be included in the next specification version once it has achieved 5 positive votes and no negative votes. Step 4: Full draft review This phase allows for the near-final review of all specification changes that have been accepted. For any discrepancies, the typical 5 votes (and no negative votes) will be required to resolve any differences. Step 4.1: Implement Prototype Bundling an implementation with the full draft review would be a good way to ensure the defined specification is of high quality, and allows it be tested against real use cases. The group is still discussing the exact requirements for this phase. Step 5: Final publication Once the full draft review has been completed, the new version is ready for publication OpenSocial.org (and likely implementation by Apache Shindig). Additional Notes Managing the timeline Alterations from the plan of record require at least 5 positive votes and no negative votes throughout a 5 day period. Default timeline: This is the expected timeline for a given iteration, but the specifics will come as part of a roadmap proposal as in step 1:
Handling errata Once a specification has been published, in the event that an issue is discovered, a .patch file should be sent to the list proposing the clarification/fix, and can become official after 5 days of review and 5 votes (with no negative votes). Backwards compatibility Given that there are many applications and containers in production, introducing non-backwards compatible changes is very painful. As a general suggestion for good hygiene, proposals should make every effort to maintain backwards compatibility. If breaking changes become a problem, perhaps a limit may be introduced on the number allowed per version. |
|
|
|
Technical Resources >
OpenSocial Spec Process |