Call for Vote on OpenSocial Incubating Process

[Matthew Marum]

We discussed this quite a bit last summer so I think we're overdue on approving the formalized process where incubating features added to the OpenSocial specification become permanent.

The proposed incubating process has been documented on the OpenSocial documentation wiki since last August.  We are looking for 5 +1 votes.

http://docs.opensocial.org/display/OSD/OpenSocial+Incubating+process

Incubating Process (Proposed)

The purpose of incubating specification changes is to allow new features to be entered into the specification with the flexibility to change them over time as we gain implementation experience in using them. 

Currently, new normative specification changes are added as incubating sections to the OpenSocial specification.  Incubating sections in the specification can become finalized sections of the OpenSocial specification once the following requirements have been met.

1. The incubating feature MUST have three different adoptions (or implementations) of the incubating specification that have seen active use.  Adoption by a product would count.  A prototype implementation that lies dormant does not count.  Adopters SHOULD provide feedback to be incorporated into incubating feature.
2. The incubating feature MUST have an open source implementation so the community has an option they can freely adopt.  It is preferable that the open source implementation be done in Apache Shindig or Apache Rave but this is not required.

At any time that an incubating specification change has met these requirements, a vote may be called on the specification mailing list for the purpose of accepting the incubating specification change as finalized specification in an upcoming release of the OpenSocial specification.  The voting period will be one week and will require 5 +1 votes and no -1 votes during that time in order to pass.

[Ryan Baxter]

+1

[Henry Saputra]

+1

--
You received this message because you are subscribed to the Google Groups "OpenSocial and Gadgets Specification Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to opensocial-and-gadg...@googlegroups.com.
To post to this group, send email to opensocial-an...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msg/opensocial-and-gadgets-spec/-/xIW5GLRDXWsJ.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Matt Franklin]

+1

--

[Babar Pirzada]

+1

[Evgeny Bogdanov]

+1

[Dan Dumont]

+1

From:        Matthew Marum <mgm...@gmail.com>
To:        opensocial-an...@googlegroups.com
Date:        02/15/2013 09:40 AM
Subject:        [osgs] Call for Vote on OpenSocial Incubating Process
Sent by:        opensocial-an...@googlegroups.com

---

We discussed this quite a bit last summer so I think we're overdue on approving the formalized process where incubating features added to the OpenSocial specification become permanent.

The proposed incubating process has been documented on the OpenSocial documentation wiki since last August.  We are looking for 5 +1 votes.

http://docs.opensocial.org/display/OSD/OpenSocial+Incubating+process

Incubating Process (Proposed)
The purpose of incubating specification changes is to allow new features to be entered into the specification with the flexibility to change them over time as we gain implementation experience in using them.
Currently, new normative specification changes are added as incubating sections to the OpenSocial specification.  Incubating sections in the specification can become finalized sections of the OpenSocial specification once the following requirements have been met.

1.        The incubating feature MUST have three different adoptions (or implementations) of the incubating specification that have seen active use.  Adoption by a product would count.  A prototype implementation that lies dormant does not count.  Adopters SHOULD provide feedback to be incorporated into incubating feature.
2.        The incubating feature MUST have an open source implementation so the community has an option they can freely adopt.  It is preferable that the open source implementation be done in Apache Shindig or Apache Rave but this is not required.

At any time that an incubating specification change has met these requirements, a vote may be called on the specification mailing list for the purpose of accepting the incubating specification change as finalized specification in an upcoming release of the OpenSocial specification.  The voting period will be one week and will require 5 +1 votes and no -1 votes during that time in order to pass.

--

You received this message because you are subscribed to the Google Groups "OpenSocial and Gadgets Specification Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to opensocial-and-gadg...@googlegroups.com.
To post to this group, send email to opensocial-an...@googlegroups.com.
To view this discussion on the web visit

https://groups.google.com/d/msg/opensocial-and-gadgets-spec/-/xIW5GLRDXWsJ.
For more options, visit https://groups.google.com/groups/opt_out.

[Matthew Marum]

+1

Lets keep voting open for another 24 hours and then we can call it.

Matt

[Matthew Marum]

I talked with Mark W. and he's travelling this week.  Lets hold off calling this to make sure we have his public blessing on this.

[Mark W.]

I think overall I'm +-0 on this, leaning towards -1. Here are my thoughts. 

-1 on three different adoptions

Let's look at the common container. Right now, we've got Jive and IBM implementing the CC in product. I'm not sure of anyone else that's doing this. So one question that comes up is.... How do we know we've got the three? This is in Shindig, so, if we know, for example that SAP is using shindig, does that count? And how do we ensure 100% compliance? As much as I'd love to say that we use all of the common container, the fact is we don't. So... I'm concerned that adding the three different adoptions as a requirement, i.e. MUST, could put us in a very untenable position. Perhaps another question is this: Is it unreasonable for someone to vote -1 on graduating from incubation b/c there is not enough demonstrated adoption? If we were more vigilant and self policing (mia culpa), woud there be a need for this language?

+1 on open source

One caveat: Are there any circumstances where someone could not contribute something to open source that we wanted in the spec? I can't think of any, but figured it would be worth asking, again, b/c MUST is pretty strong language. 

On Friday, February 15, 2013 9:38:11 AM UTC-5, Matthew Marum wrote:

[Matthew Marum]

So for OASIS, they require implementors to provide a Statement of Use.

https://www.oasis-open.org/policies-guidelines/tc-process#standApprovProcess

An example of a Statement of Use is here.

https://lists.oasis-open.org/archives/dita/201010/msg00070.html

How about we ask that implementors provide a Statement of Use for a feature on the mailing list?  So in this case change the language to not require '3 adopters' just '3 statements of use'.  I think that also bypasses arguments about 100% compliance, etc.

Matt

--

You received this message because you are subscribed to the Google Groups "OpenSocial and Gadgets Specification Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to opensocial-and-gadg...@googlegroups.com.
To post to this group, send email to opensocial-an...@googlegroups.com.

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

[Ryan Baxter]

I like the statement of use language better than saying implementors.  Most containers just consume features out of Shindig and don't necessarily need to implement anything.  

Would we ask for these "statements of use" before each release to graduate incubating features?

To unsubscribe from this group and stop receiving emails from it, send an email to opensocial-and-gadgets-spec+unsub...@googlegroups.com.

To post to this group, send email to opensocial-an...@googlegroups.com.