A proposal for a new Recommendation Track

W3C gave their permission to publish a derivative of chapter 7 – the chapter that defines the recommendation track.

I wrote a proposal as a heavily edited version. it fails to identify what is removed (sorry – I’ll try to find time for that) but it does show to try what has changed or been added. Since we apparently can’t publish plain files HTML in the Community Group (or I haven’t worked out how to do that), I’ve put it where you can download it (with a bonus Russian lessson: “Скачать” means “Download”).

The main changes are

• Last Call and Candidate Recommendation are merged into a single step
• Proposed Recommendation is automated (effectively it is still there, but not as a seperate stage, and it begins at the same time as LCCR)
• There are some clearer obligations for W3C to address dissent, before publishing a Recommendation
• There are some changes to the requirements for editing a Recommendation – it no longer suggests that errata can somehow just be incorporated by reference.
• Some MUSTS are now SHOULDS (e.g. identifying editorial changes), and vice versa
• Requirements for explaining testing are a little stricter

The new Last Call Candidate Recommendation stage was the main motivation to develop this draft. It tries to achieve several goals:

Make the transitions matter

Last Call is very important in terms of Patent Policy, and used to be a vital step in the Process, when CR didn’t exist. But it is a trivial step for a Working Group, and there is a sense that making multiple last calls is an easy way to get review. Review should happen as bits of the spec are solidified, in what I have called Heartbeat Working Drafts.
Meanwhile, Candidate Recommendation was a serious step process-wise, yet shouldn’t change as much as it does – people should be building test implementations earlier, so their last call comments can be backed by reality instead of imagination.

Focus on interoperability

The requirement for exiting LCCR has changed. It seems somewhat wishy-washy as written “must show that independent implementations of the specification are extremely likely to be highly interoperable”. The idea is to avoid cases where two implementations is clearly not going to produce the desired result (e.g. WebSQL), or where there is good reason to believe the specs will be implemented increasingly better (e.g. because there is an active process of making a next one and the one after…)

Don’t depend on changing the Patent Policy

Actually, I would like to change the Patent Policy. I just think don’t want to depend on that in order to make a useful improvement.

Other considerations

I also tried to frame it in terms of requirements on who does what. It is currently about half the size it was. But some things that were good advice have been removed and perhaps should be re-added.

The Advisory Board saw a slightly different draft already, and have made a couple of comments. They suggested this draft be published to gather wider input for their work of revising the Process.

Comments, criticisms, and suggestions are very welcome on the mailing list.