Overview

All changes to the OpenSocial spec are proposed, discussed, and voted on in the spec list.

To look at changes in the previous iterations, please look at:

• 0.9 archive
• 1.0 archive
• 1.1 archive
• 2.0 archive
• 2.0.1 archive

Spec Process

Adding proposals to the OpenSocial specification may follow many paths, but below is the basic overview.

1. Come up with a bright idea.
2. Create a functioning implementation or extension (preferably in Apache Shindig) that embodies the ideas and can be evaluated by other people.
3. Write up a page in this wiki that describes the proposal and outlines some use cases
4. Start a discussion thread on the OpenSocial and Gadgets Spec group (link with proposal wiki page).
5. Iterate on prototype and proposal to include community feedback
6. Create a new Issue on OpenSocial-Resources project.  (link with proposal wiki page and in discussion thread)
7. Add a link to the specification-scope document in svn specification-scope in svn.
8. Modify the spec document(s) to include your proposal.  Surround all changes with <x:draft> tags.
9. Create a patch file with svn diff and attach to the Issue
10. Check in the changes to the spec.  Comment must include the issue number and identify proposal - ex: Issue NNN
11. Designate that revision as the voting revision and link with the Issue.  Make an announcement on the discussion thread and link from the wiki proposal.

For information about the spec process itself, please see the Specification Process. The process for voting on proposals is here documented on the Voting on Proposals page.

Proposed Timeline

In accordance with the OpenSocial development process, this is the timeline that is proposed for OpenSocial 2.0. Because we would like to ensure we have time for the required prototypes to "bake", we will try to plan for current iteration plus one. For this reason, you will see proposals and a plan for OpenSocial 2.0. and "v.Next". Further, Shindig is a crucial part of most of the implementations of OpenSocial. To this end, we believe it makes sense to include and propose a time line for Shindig as well. It is our hope that this will encourage increased involvement in both projects.

The section below details this plan. Emphasis will be placed on iterating over working prototypes as well as the "patches" to the specification. One thing that happened during the creation of the 1.0 version of the specification is that the last phase of this process became much more drawn out. There was still considerable design work happening in what was intended to be a review of the final specification to be published. We are taking the following steps in an attempt to avoid this:

• Prototyping of proposals should begin as early as possible. No proposal voted on without a prototype in place (ideally in the Shindig sandbox)
• Draft versions of the specification will be produced on a regular basis. Sections that have been modified will be annotated to indicate, as best as possible, the changes (e.g. include a line with the code fix number in the document)
• No code changes during final review and publication

Note: OpenSocial "v.Next" dates are tentative.

OpenSocial 2.0 Timeline

Overview: January 6, 2011 - June 9, 2011

• Jan 6 - Jan 27: Define Scope
• Jan 28 - May 12: Define proposals
• May 12th - June 3rd: Voting on proposals and spec patches attached to tracking issue.  In parallel prototypes should be worked on.
• June 3rd - June 24th: Apply/Back-out patches
• June 30th: Specification complete and prototypes complete for each proposal

Themes for OpenSocial 2.0

The following areas are our focus for OpenSocial 2.0

• A Clean Consistent Specification
• Stronger Interoperability
• Ease of Implementation for Containers and Clients

A Clean Consistent Specification

Unnecessary complexity makes it difficult to implement gadgets and containers.  The v2 version gives us a chance to break with the past and wipe the slate clean.  This means removing deprecated features and fixing a bunch of small problems that stand in the way of easy implementations.

Stronger Interoperability

OpenSocial has always formed an umbrella over other standards.  Over time the set of useful standards evolves.  In v2 we should align with existing standards where it makes sense and eliminate OpenSocial specific technologies when others will do. Examples of this include ActivityStreams integrate 

Ease of Implementation for Containers and Clients

There are a number things that can make developing gadgets and Opensocial difficult.  Integrating into social and enterprise sites is difficult.  Client and REST API libraries require a large amount of configuration to work with multiple providers.   There are a number of efforts that will improve this situation.  A stable container API will make it much easier to add gadgets and OpenSocial to an existing site.  Consistent enterprise extensions will mean that client/server interoperability will be maintained.

Scope: OpenSocial 2.0

Prototype proposals and vote on their specifications

Once the set of proposals for a given iteration is approved, the proposals need to be prototyped. All the wiki pages will be tagged with Needs Prototype (vX.X). If you are implementing a prototype for a proposal, you should update the proposal's wiki page with information about your prototype and add a Prototype in progress (vX.X) tag to the wiki source. Once your prototype is complete, and any necessary modifications to the spec have been discussed and incorporated into the current draft, the proposal page should be tagged with Has Prototype (vX.X).

Final review and publication

Once all proposals have been implemented and any necessary changes made to the draft specification, the community reviews the draft and conducts a final vote to promote the current draft to an official spec. At that time we'll reset this page to start focusing on the next iteration.

Proposals

Add pages here for proposals that are just starting our or are not yet slated for a version.

Add Resources to Social Data Models