Clarifying the steps from CR to Rec

Hi folks,

this is ISSUE-77 - the big messy bit outstanding. A few things that I  
think will help clean it up:

TL;DR: Bring back Proposed Rec, require W3C approval for a revised CR but  
delegate to the Team Contact in practice.

Reinstate Proposed Rec. Basically this is a transition, where the group
shows the thing is ready for Rec (normally through a transition call),
and it serves as a notice that there are 4 weeks left for AC review and
the document will normally no longer be materially changed.

A negative AC review would be one example of an exceptional case where a  
document may be changed, and thus returned to CR or earlier.

That simplifies half of what's causing confusion.

The other issue is about republishing CR.

As far as we can tell, *any* substantive change made to CR needs to  
restart the Patent Exclusion clock. For a 60 day review.

Note, for example, that if touch events had used ellipses
instead of polygons or circles to cover the region of a touch, they
probably *would* have run foul of a patent that was eventually considered
unlikely to bear on their spec because it only applied to elliptical
regions. Yes, patents turn on tiny trivialities of implementation.

It is not explicit in the Patent Policy whether this exclusion would only  
cover the delta since the last CR (as per differences between "LC" and the  
last Working Draft published within 90 days of FPWD), or would restart the  
exclusion for the entire CR. The relevant text is at  
http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-exclusion-with  
but either way, republishing a CR is a pain point for someone.

If we simply allow Working Groups to republish at will, we introduce the  
possibility for an avalanche of Exclusion Requests. Which I think would  
lead to complaints from AC reps, who don't like going to visit their  
lawyers a lot of times to say "By the way, we changed the thing you have  
to review". (And maybe from the Team, who are obliged to make all the  
requests).

On the other hand, if we make it really hard to republish, we'll also have  
problems, as people complain about the overhead cost of getting work done.

My rough proposal:

We should require W3C approval for republication of CR, but that in  
practice that should be delegated to the Team Contact, who per  
http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-exclude-mech is  
formally responsible for issuing the Call for Exclusion.

We should ask the PSIG whether there is consensus about what the Patent  
Policy text means on the point of what is open for an exclusion claim in  
the event of *republishing* a "Last Call" (as used in the Patent Policy,  
i.e. a CR in the proposed new process).

Rationale:

If there are substantive changes, the Team Contact will have to decide  
whether it is easier to make the CfE, or to negotiate a republishing  
schedule with the editors and the WG. And this increases the incentives to  
get the CR right, which IMHO isn't a bad thing. The risk I see is that we  
end up in the position of people avoiding finishing (a la CSS 2.1) or  
being blocked (a la SVG 1.2) until we deal more thoroughly with ISSUE-6  
(publishing something now and working on a version.next for improvements)

IMHO:

Best practice is to produce a draft when there is something new, that  
provides a pointer to the relevant issue leading to the change, and  
non-normative text describing possible Working Group resolutions, and  
potentially an Editor's draft which actually updates the spec to provide  
an unofficial view of what is likely to be adopted. If the CR is long,  
producing a new CR and making a new call for exclusions seems more  
reasonable.

If a group is making a lot of changes in CR, they should probably consider  
that a signal that they weren't ready for CR in the first place - possibly  
through no fault of their own, e.g. because technological development  
elsewhere changed the circumstances, but possibly because they didn't get  
wide enough review or something - and voluntarily return to WD.

cheers

-- 
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
         chaals@yandex-team.ru         Find more at http://yandex.com

Received on Monday, 3 February 2014 10:33:54 UTC