20 open spec issues - let's extend the deadline

[Cassie]

If you haven't already noticed I haven't really enforced this last deadline we had for the spec. All issues were supposed to be resolved by Friday, April 25 but we didn't really quite make it. I think that perhaps a week wasn't enough time to wrap all of this stuff up. We still have 20 open issues, many of which seem important to get into the next set of spec changes (or at least resolve in one way or another).

I'm going to propose that we try very hard to wrap this last set of stuff up. I've been closing off the threads where we obviously weren't agreeing or the consensus on a proposal seemed to be overly negative. I will hopefully continue to both approve and close threads until we get down to 0 issues.

As we haven't done this before I'm not sure how long this is going to take but perhaps we can just take this on a day by day basis. I will commit to providing daily updates on where we stand and what the open issues are if all of you will commit to providing more opinions to work with :)

If you disagree with this please just let me know.
(We of course always have the option of just delaying all 20 issues that haven't made it until the next round.)

Thanks for your help.

- Cassie


ps - i'll try to provide a summary of all issues at some point today so that there is a clearer window into what is still on the table. for me at least, the spreadsheet gets a little unwieldy at times.

[David Glazer]

Thanks Cassie for your ongoing heroic spec-herding efforts.  A few comments:

• I think a summary of the remaining open issues is a great idea - that will definitely make it easier for people to see and vote.
• Yes, let's push hard to wrap this up -- I think it's fine to roll many things over to the 0.9 process if they don't converge quickly.  Taking it day-by-day seems okay for a couple of days, but I doubt anything not resolved by late this week is worth waiting for.
• Am I remembering right that the next step after the 4/25 deadline was to produce a single consolidated spec with all approved changes, so people could do a sanity check on the whole?  If so, I wonder if we can do that in parallel -- having a spec with highlighted approved diffs might make it easier to vote on the remaining open proposals.
  

  - dG

[Cassie]

Summary of all open issues:
(down to 19 :)

== opensocial ==

REQUEST_SHARE_APP-001 - give gadgets the ability to control which context of a gadget users go to after accepting an app invite and after sending one
http://groups.google.com/group/opensocial-and-gadgets-spec/browse_frm/thread/3f257fa792254f4c


REQUEST_SHARE_APP-002, -003, -004 - give gadgets more information on what the result of request* methods are.
http://groups.google.com/group/opensocial-and-gadgets-spec/browse_frm/thread/04d654c18fc52c06#


PERSON-002 - Add presence as an enum field to the person object.
status update: this thread almost has consensus.
http://groups.google.com/group/opensocial-and-gadgets-spec/browse_frm/thread/75303d2a347ea9f5#


DATA_STORE-001 - What do we do about data types in the data store? Do we treat everything as json or add explicit types?
status update: lots of responses, no consensus yet
http://groups.google.com/group/opensocial-and-gadgets-spec/browse_frm/thread/4ed634f97029f0cd#


FETCH_ACTIVITIES-001 - do we remove the legacy "activities" pointer from the fetchActivities response? do we add paging support to fetch activities?
status update: this thread has not received any responses yet
http://groups.google.com/group/opensocial-and-gadgets-spec/browse_thread/thread/bfba9d321b5be7d1


URL_TEMPLATES-001 - adding a method for retrieving a url template. this allows gadgets to construct concrete urls for the container without having to use requestNavigateTo. They can also create urls ahead of time
status update: people seem to like the idea but we don't have any syntax consensus yet
http://groups.google.com/group/opensocial-and-gadgets-spec/browse_thread/thread/bfb8c9aaee0ef762


POP_UP-001 - add a method for gadget developers to call which will create a pop up that the container designs
status update: people seem to like the idea but we don't have any syntax consensus yet
http://groups.google.com/group/opensocial-and-gadgets-spec/browse_frm/thread/4056cc17dc9c4499


REQUEST_SEND_MESSAGE-002 - change request send message to take in person objects as well as an idSpec
status update: waiting for myspace to respond with their thoughts
http://groups.google.com/group/opensocial-and-gadgets-spec/browse_thread/thread/32a59645ba83c8c6


APP_DATA-001 - the app data store should allow paging
http://groups.google.com/group/opensocial-and-gadgets-spec/browse_frm/thread/62c760430bd15e79


FETCH_ACTIVITIES-002 - add ability to modify activities shortly after they are created
status update: this thread has not received any responses yet
http://groups.google.com/group/opensocial-and-gadgets-spec/browse_frm/thread/2c3a051477efdc28


FEATURE_PARAMS-001 - add the ability to query for things like max activity length on the getFeatureParams method
http://groups.google.com/group/opensocial-and-gadgets-spec/browse_frm/thread/d9bae579dde365f9/


ACTIVITY_TEMPLATES-001 - add <em>, <i>, <strong> as accepted tags for activity templates.
http://groups.google.com/group/opensocial-and-gadgets-spec/browse_thread/thread/1ca194a76732abe0


== gadgets ==

QUIRKS_MODE-001 - how do we handle quirks vs standards gadget rendering in the spec?
http://groups.google.com/group/opensocial-and-gadgets-spec/browse_frm/thread/fa8e8863f91b6333#


CONTENT-001 - add the ability to refer to content sections by url
http://groups.google.com/group/opensocial-and-gadgets-spec/browse_frm/thread/237c992b35c6ce15


ESCAPE_STRING-001 - clearing up the exact definition of unescapeString and escapeString
status update: we haven't found the right brilliant answer yet. please chime in.
http://groups.google.com/group/opensocial-and-gadgets-spec/browse_frm/thread/61f07a27560e78c8


VIEWS_ATTRIBUTE-004 - the very large views threads which includes possibly defining "all" as a view type, changing the definition of "default", concatenation (pr not) of views, allowing (or not) comma delimited lists of views
status update: we don't have consensus on many parts. this thread needs opinions in order for us to get anywhere.
http://groups.google.com/group/opensocial-and-gadgets-spec/browse_frm/thread/1845cdb2f3d17777


VIEW_TYPES-001 - we should fix our spec defined view types to reflect reality
http://groups.google.com/group/opensocial-and-gadgets-spec/browse_frm/thread/e58410c6054eec7a

On Mon, Apr 28, 2008 at 4:11 PM, David Glazer <dgl...@google.com> wrote:

Thanks Cassie for your ongoing heroic spec-herding efforts.  A few comments:

of course :)

• I think a summary of the remaining open issues is a great idea - that will definitely make it easier for people to see and vote.
  

above.

• 
  
• Yes, let's push hard to wrap this up -- I think it's fine to roll many things over to the 0.9 process if they don't converge quickly.  Taking it day-by-day seems okay for a couple of days, but I doubt anything not resolved by late this week is worth waiting for.

Just so you know, I'm hoping, and I think the rest of Europe is too, that we get this wrapped up before Wed. Thurs and Fri over here are holidays for many people :)
 

• 
  
• Am I remembering right that the next step after the 4/25 deadline was to produce a single consolidated spec with all approved changes, so people could do a sanity check on the whole?  If so, I wonder if we can do that in parallel -- having a spec with highlighted approved diffs might make it easier to vote on the remaining open proposals.
  

This sounds like a good plan.
 

[Dan Peterson]

I like the idea of allowing a bit more time for feedback, as we seem to be nearing consensus on a few more items.

 

-Dan
 

[Robert Evans]

Hey Dan,

What is the time frame for shipping 0.8?

Thanks,
Bob

[Robert Evans]

The spec that is..

[Dan Peterson]

Hi,

 

The high-level idea is to have 0.8 published for implementation when "it's ready." The goal is to get enough input from everyone that what is being proposed is ready for implementation. Cassie had originally proposed a that we'd move on to the next phase of 0.8, the draft phase, on May 2nd [1], but as she had mentioned earlier in this thread, if we move the April 25th technical consensus deadline out a bit, she is hoping we'll be able to get to consensus on a few more issues.

 

The next step will be to pull all the changes together from the tracking spreadsheet into a single place and have a draft version of what 0.8 would look like, so we can see everything in context. Once the spec changes come together, I'd expect that it'll take about a week for that draft to get produced, and then we'd want a week to give everyone a chance to weigh in on how it has all come out, which also lets us make sure there aren't any conflicts among the changes themselves.

 

In summary, the latest timeline as I see it:

• Now - finalize changes for the topics proposed for 0.8
• Next week (week of May 5) - prepare a draft version of 0.8 for review
• The following week (week of May 12) - review that draft prior to making it "golden"

-Dan

 

[1] - http://groups.google.com/group/opensocial-and-gadgets-spec/browse_thread/thread/d76ea214a445a840/28ac4e9c20d244b0?lnk=gst&q=warning+this+is+long#28ac4e9c20d244b0