Re: Updated wiki about drafts/specs

Stian 

It is good to think about the process but  I think we should be very careful about rephrasing the process document, especially on the wiki, as there are details in the process/ipr documents we might omit.

That said,  I have some informal comments inline below

regards, Frederick

Frederick Hirsch, Nokia
Co-Chair W3C Web Annotation WG
@fjhirsch



On Nov 13, 2014, at 6:51 PM, Stian Soiland-Reyes <soiland-reyes@cs.manchester.ac.uk> wrote:

> I added:
> 
> https://www.w3.org/annotation/wiki/Main_Page#Editor.27s_Drafts
> 
> to list the drafts and specifications we have/will have.
> 
> 
> I added my take on what is the "FPWD" process etc. as that can be
> overwhelming jargon for many, specially outsiders. W3C staff might
> want to edit the wiki page to correct me where I am wrong:
> 
> 
> Editor's drafts are maintained in the web-annotation Github repository
> - where anyone can submit a pull request or raise an issue for any
> edits/suggestions. An Editor's Draft can be considered the
> "live"/"trunk"/"master" branch of a documentation, and is
> created/maintained/controlled by its listed editors, as agreed by the
> Working Group (WG).
> 
> Documents can then progress to be formally published by W3C at
> different stages according to the charter for the Annotation Working
> Group:
> 
> ED: Editor's Draft - Latest edit of the document - subject to change
> at any time. Similar to a nightly build.

can change whenever needed, no regularity should be assumed

> FPWD: First Public Working Draft - first draft that is in a state to
> be formally reviewed by WG. Similar to a milestone release.

The WG members should be reviewing all work as it is discussed. A published draft makes a stable version visible outside the WG
and makes it easier to share for feedback and to get visibility. There is also an IPR aspect to FPWD that is important. I won’t attempt to 
explicate what is in the IPR policy and Process document.


> WD: Working Draft - zero or more updated working drafts, fleshing out
> all the details, but not yet complete. Similar to a milestone release.

Not necessarily a milestone, but WG can decide at any time to publish a WD. Makes a new stable snapshot of a draft
offering visibility 

> LC: Last Call Working Draft - the WG consider it to be
> feature-complete, last call for fundamental changes.
> Implementers/outsiders invited to review and give feedback. Similar to
> a alpha release.

From the old process, but the idea is feature-complete version ready to implement. 
Assumes a waterfall model.

> CR: Candidate Recommendation - the WG consider it to be finished,
> implementers/outsiders can still give feedback. Similar to a beta
> release.

Call for implementations, ready to implement, but we prefer to engage developers from the beginning and use implementation feedback as we progress the work

The major risk with CR is that unanticipated implementation issues cause a need for changes, going back to LC/CR, adding cycle time.

> PR: Proposed Recommendation - the WG has addressed all feedback. Only
> fixing breaking issues and editorial changes allowed. Similar to a
> release candidate.

Spec done, testing done, implementations demonstrate, feedback included. Ready to publish upon AC review

> Rec: Recommendation the specification is final and released.
> Implementations can rely on no further changes.

a w3c standard

> Erreta (post-publication corrections, e.g. typos in examples)
> 
> 
> 
> 
> 
> 
> -- 
> Stian Soiland-Reyes, myGrid team
> School of Computer Science
> The University of Manchester
> http://soiland-reyes.com/stian/work/ http://orcid.org/0000-0001-9842-9718
>

Received on Friday, 14 November 2014 20:17:53 UTC