In the spec process document, http://www.opensocial.org/Technical-Resources/spec-process, we have a new section that has been added but is not official at this time. Under process details, we have a suggested section 4.1:
Step 4.1: Implement Prototype (Potential addition)
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.
Suggest that we make the final language as follows:
Step 4.1: Implement Prototype
Bundling an implementation with the full draft review helps ensure that the defined specification is of high quality and allows the specification to be tested against real use cases. The full draft review cannot begin until at least one prototype has been built per feature. Person(s) implementing the prototype SHOULD include a document indicating parts of the specification that were unclear and required assumptions to be made. This document SHOULD include the assumptions and a suggested rewording of the applicable specification section(s).
Scott Seely |
architect |
email sse...@myspace.com |
Pass #2: Highlighted parts are new.
Step 4.1: Implement Prototype
Creating an implementation/prototype along with the full draft review helps ensure that the defined specification is of high quality and allows the specification to be tested against real use cases. The full draft review cannot begin until at least one prototype has been built per feature. Person(s) implementing the prototype SHOULD include a document indicating parts of the specification that were unclear and required assumptions to be made. This document SHOULD include the assumptions and a suggested rewording of the applicable specification section(s). A prototype MUST be available to the spec group for testing in order to meet this requirement. The person(s) building the prototype do not have to provide source code and may choose to provide sample code.
Pass #3—changes are highlighted. Please note that not all changes require sample code. For example, we voted to have all callbacks get called async (http://groups.google.com/group/opensocial-and-gadgets-spec/browse_thread/thread/f1e2885939a3a1f1?hl=en#). This notion would be problematic to show with sample code. Sample code demonstrating a call stack would show the delta, but wouldn’t be helpful to demonstrate the feature.
Step 4.1: Implement Prototype
Create a container based implementation/prototype along with the full draft review helps ensure that the defined specification is of high quality and allows the specification to be tested against real use cases. The full draft review cannot begin until at least one prototype has been built per feature. Person(s) implementing the prototype SHOULD include a document indicating parts of the specification that were unclear and required assumptions to be made. This document SHOULD include the assumptions and a suggested rewording of the applicable specification section(s). A prototype MUST be available to the spec group for testing in order to meet this requirement. The person(s) building the prototype do not have to provide source code and SHOULD provide sample code if applicable.
This is 2 votes for this change to procedure (Louis and I). This change was already suggested in the spec process doc (http://www.opensocial.org/Technical-Resources/spec-process), we just need to formalize the decision.