OS 2.5 vs 3.0

[James Snell]

Just a quick item... I noticed that in the wiki, there is a page for
v3.0 spec changes and the older page for v2.0 changes that includes a
variety of items that have either been completed already or are still
underway. To help keeps things organized and focused for the upcoming
face to face, could we also create a page specifically focused on
priorities for the interim 2.5 spec.. or is there one something
already that I've overlooked? I just don't want the very future
forward looking ideas I've been posting to get to mixed in and
convoluted with the more short term items we absolutely need for 2.5.

[Ryan Baxter]

+1 James, here is the page
http://docs.opensocial.org/display/OSD/Spec+Changes+-+v2.5

[Mark W.]

What we've got in plan so far is really geared towards a major release. The F2F on the 28th is already set to kickoff 3.0, not 2.5. 

[David Robinson]

James,

I agree this needs some more organization.  Thanks for suggesting.
Here are a few suggestions.

1) Is there a better way to correlate the "spec changes" list
in the tree view with the actual specifications listed in the
middle of the page ?  The lists don't match in version numbers
for starters.  Do we need the tree view ?  Can we link the
changes for each spec under each specification in the middle ?

2) What is OpenSocial .next ?  I don't see that in the tree view
at the left.  Can we rename OpenSocial .next to 2.5 in the
center, add an OpenSocial 3.0 in the middle as a place holder,
and add an OpenSocial 2.0.1 in the tree view for completeness ?

3) When I click the "a list of what we need to do" under the
   OpenSocial .next category in the middle of the page, I then
   see a page called "OpenSocial 2.0 Feature Implementation and
   Compliance...."  .    Wouldn't a better title for this page be
   "Spec changes that still need implementing or are underway" ?
   and then a column in the sheet could show which spec version
   describes the change ?  I assume that
   there will be suggested spec changes in 2.5 that we will want
   to add to that list of "things that need doing" list so the title
   will need changing.

4)  The list in the "list of what we need to do"
   doesn't match the entire list under the OpenSocial 2.0 spec
   changes in the tree view...and that leaves me wondering why
   it doesn't match and how we track to see if all spec changes were implemented
   or not.

--
You received this message because you are subscribed to the Google Groups "OpenSocial and Gadgets Specification Discussion" group.
To post to this group, send email to opensocial-an...@googlegroups.com.
To unsubscribe from this group, send email to opensocial-and-gadg...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en.

[Matthew Marum]

Hey David,

Changes that actually happen to the spec are tracked as issues in opensocial-resources project.  That project is the authoritative source.  The wiki is really just a convenient place to capture use cases, reasoning, and justification for proposals.  There are plenty of things that could be done to clean it up.  In fact, most of it should probably just be archived.  A lot of the old proposal wikis are out of date with what was actually implemented.

Also, "OpenSocial .Next" is a euphemism for trunk development on the spec.  I don't think we're yet on the same page yet on what version the next spec is going to be.  Some people want the next version to be 2.5, some want to go straight to 3.0.  Once we start churning on the spec, we can get more specific.

Matt

[James Snell]

Ok, so stepping back a bit on this then, I'd like to make the
following proposal:

There are plenty of implementors who are still working to catch up to
2.x spec and for whom 3.x is still very much a "we might get to
eventually" thought. We owe it to those implementors to produce a
cleaner, easier to understand version of the specification that closes
out many of the more immediate issues. Not to mention the fact that
there are still plenty of things currently in shindig that aren't
fully documented in spec. Let's dedicate some cycles to producing a
2.5 version of the specification that closes out these issues and
addresses basic spec readability. This is a pretty well defined and
limited list of items. We should be able to get 2.5 done in the very
near term.

In parallel, we can move forward with the longer range ideas for 3.0.

- James

[Evgeny Bogdanov]

+1 to James!

[Ryan Baxter]

+1 James

On Feb 8, 5:38 am, Evgeny Bogdanov <evgeny.bogda...@gmail.com> wrote:
> +1 to James!

[Mark W.]

OK... It sounds like we are getting consensus around a 2.5 & 3.0. Let's think about time lines and scope.

2.5 by April 4: Very tightly focused on clean up. 

3.0 by June 29: Target the new stuff, e.g. spaces, updated EE model, incubate rest api, etc...

3.1 by November: Remove container from incubating. Clean up from 3.0.

What do you think??

[James M Snell]

This schedule seems way too aggressive. I would argue that a 2.5 spec
by May is fine, but trying to push for a 3.0 by June is silly. Once
2.5 is published, the focus should turn to making sure we all have the
time to deliver implementations of the 2.5 specification to market,
demonstrate interoperability, etc before we consider pushing out a 3.0
specification. Given that, I would propose that we push the
publication of the first *draft* of 3.0 out to 4Q12 (end of 3Q12 at
the absolute earliest)... especially given the potential scope of the
refactoring that may happen within the specification.

- James

> --
> You received this message because you are subscribed to the Google Groups
> "OpenSocial and Gadgets Specification Discussion" group.

> To view this discussion on the web visit
> https://groups.google.com/d/msg/opensocial-and-gadgets-spec/-/-IGGG_XHsGgJ.

[Mark W.]

James,

4Q12 is way too long. There are some changes that we'd like to work with the community to get in prior to 4Q. 

[MITRE_MattFranklin]

I agree with James.  I think the 3.0 changes will be significant enough that we will need until at least late September to get them all in.

[James M Snell]

Ok... let's see if we can categorize exactly what you mean by "some
changes"... are we talking...

a) largely editorial changes or complete documentation of stuff that's
already in shindig or has been on the table for a while (e.g. spaces
proposal, multipart upload etc)

b) basic new features such as new services, or an updated embedded
experiences model, etc that do not require a fundamental refactoring
of basic core elements of the standard.

c) core refactorizations of the basic spec (e.g. the api changes I've suggested)

I would argue that items falling into category (a) are targets for 2.5
in May. Items falling into category (b) are candidates for
documentation and incubation post 2.5 but should not become part of
the core spec until 3.0, giving us all time to tease them out and get
interoperable implementations going. Items falling into category (c)
would be targeted at 3.0.

Depending on the nature of the individual things falling under
category (b), there would likely be quite a bit of room for working
with the community to deliver some stuff as "incubating" in the
interim between when we publish 2.5 and when we publish 3.0.

The bottom line, tho, is that a June target for 3.0 is WAY too early.

- James

> --
> You received this message because you are subscribed to the Google Groups
> "OpenSocial and Gadgets Specification Discussion" group.
> To view this discussion on the web visit

> https://groups.google.com/d/msg/opensocial-and-gadgets-spec/-/muKXivoFX2wJ.

[Ryan Baxter]

I think having time to adopt a spec and reflect after it is published
is key. Take for example embedded experiences, actions, and
selection. 2.0 was published in August and we still dont have any
production level implementations out there....although we are
close....and we are only now starting to take a look at these new
features and see other use cases and changes we would like to make. I
fear that if we introduce things like spaces in 2.5 and ~2 months
later we publish 3.0 we will not have enough time to reflect on what
was introduced in 2.5 and update them for 3.0.

> >https://groups.google.com/d/msg/opensocial-and-gadgets-spec/-/muKXivo....

[Ate Douma]

On 02/15/2012 01:20 AM, Ryan Baxter wrote:
> I think having time to adopt a spec and reflect after it is published
> is key. Take for example embedded experiences, actions, and
> selection. 2.0 was published in August and we still dont have any
> production level implementations out there....although we are
> close....and we are only now starting to take a look at these new
> features and see other use cases and changes we would like to make. I
> fear that if we introduce things like spaces in 2.5 and ~2 months
> later we publish 3.0 we will not have enough time to reflect on what
> was introduced in 2.5 and update them for 3.0.

I strongly agree with this.

Drafting new specifications is cool stuff. But formalizing them without any
reflection yet on their practicality because the previous version(s) hasn't even
been adopted or even implemented yet doesn't make sense to me.

I've been involved in a few other specification and standardization processes
before, and IMO never will anyone get it 'right' the first time.
Proper feedback and concrete implementation experiences are crucial to ensure
vendors and community will (want to) stick to it. Otherwise the whole purpose of
creating a 'standard' becomes moot.

I honestly think that after the 2.5 spec is finalized it first should be
realized and 'proven' in Apache Shindig say by end of this year (yeah!), before
trying to formalize a 3.0 spec without any 'previous version' baseline to
validate against and build upon.

And yes, I'd love and intend to 'pull' on and help with moving Apache Shindig
forwards in this, and leverage it in Apache Rave as a running implementation :)

Regards, Ate

[Matt F.]

I agree with James, Ate & Ryan about the need to take time to flesh out the spec.  I don't think this stops us from starting (and working heavily) on the 3.0 spec while 2.5 is finalized.  IMO, James has the right idea about 3.0 in the sense that we should really work to revamp the spec end-to-end with a focus on simplicity.  This work is a longer-term engagement and we should be committed to delivering a high-quality spec; not meeting an early deadline.

Ate makes a good point about revving the spec so fast that even the reference implementation can't keep up.  I think the May target is reasonable for the 2.5 spec and I think Apache Shindig could get compliant within a few months of that date.   

[Evgeny Bogdanov]

I m with Mark's position that we should speed up the process.

I thought that 2.5 is just a cleanup and slight improvement of things that already exist (implemented and somehow reflected in the spec). If it is so I don't see a reason to postpone it till the end of the year.

If it is not and 2.5 requires a lot of things, then I don't see a point in separating 2.5 and 3.0

I believe the best way is to put all the things we want on the table and then prioritize and decide.

Guess this is what Mark wants to do in his post:

https://groups.google.com/forum/?fromgroups#!topic/opensocial-and-gadgets-spec/iPHXKVpHr0I

[Evgeny Bogdanov]

Sorry for my ignorance. Found the list of issues for both 2.5 and 3.0.

With those list in mind, I believe 3.0 might take longer ...

[James M Snell]

Evgeny, the proposal is to complete 2.5 by May and take our time on 3.0 after that.

--

You received this message because you are subscribed to the Google Groups "OpenSocial and Gadgets Specification Discussion" group.

To view this discussion on the web visit https://groups.google.com/d/msg/opensocial-and-gadgets-spec/-/JpNFWFEcwBgJ.

[Mark W.]

So I wouldn't say... "take our time". I am, however, in general agreement with the above, although not 100% with the time frame. I think we've learned a lot by incubating the common container and I really like the idea of doing that with significant new "stuff". For example, now that we're up to our waists in EE, we've learned we need a few more things out of it.

I think one of the key things we need to decide is what we can deprecate. If we don't deprecate stuff in 2.5, then it's around until OpenSocial 5.0. (I can't even think that far ahead!)