W3C home > Mailing lists > Public > public-w3process@w3.org > May 2016

Obsoleting a Recommendation, round four

From: Standards <singer@apple.com>
Date: Thu, 05 May 2016 09:14:34 -0700
Message-id: <19C68DB1-F5B7-4FB5-9115-FA153B8AA553@apple.com>
Cc: Daniel Appelquist <appelquist@gmail.com>, Peter Linss <peter.linss@hp.com>
To: public-w3process@w3.org
[4] Added Wayne’s text to allow the AC to override the TAG (using the same threshold, 5%, as an appeal) and appeal the Director’s decision.  Added to say that if there are obvious alternative technologies, they should be documented in a note beside the Obsolete declaration in the document itself. Added to say that anyone can notiuce the TAG has timed out and that we move directly to ballot (i.e. it’s not a specific person’s job to set a timer).

I previously had  "If there was any dissent in Advisory Committee review, the Advisory Committee may appeal the Director’s decision.”, copied from somewhere else in the process. This is wrong.
There is a perverse corner case (which I think affects at least one other appeal); what if the AC votes, without dissent, “yes, obsolete it!” and the Director decides “no”? No dissent, no appeal allowed. Strange.  I removed the condition, it now reads "The Advisory Committee may appeal the Director’s decision.”

We still have pending how the TAG ‘announces to the other groups’ that they are considering this.  AC (not technical).  In their agenda (who reads it?). Chairs list (relies on the chairs forwarding to relevant groups)?  I tend to think both of the last two: put it in their agenda and notify the chairs.  Actually, thinking about it, maybe the TAG agenda should always go to the chairs?

* * * *

[3] Added SZ’s point, and Wayne’s about being clear about Appeals, and added “if it exists” to the need to consult with the WG.  I think we need to be clearer about announcing “to other W3C Groups” — like, which ones? How? Maybe the Chairs list? The AC?

* * * *

[2] After offline discussion with some AB members, and the call today, I offer the following.

* * * *

Accumulated text:

1) A new page, or section of a page, that defines what an Obsoleted Recommendation is.

An Obsoleted Recommendation is a Recommendation that the W3C membership no longer actively recommends be implemented; however, its formal status as a Recommendation (including its licensing status) remains.  (This is in contrast to a Rescinded Recommendation.)

A Recommendation may be considered obsolete if it is neither widely implemented nor expected to be. It may represent a technical direction that was not pursued further, or an architectural direction that is no longer in alignment with best practices in the industry. There may be alternative technologies better aligned with other parts of the Web Platform, or more in line with best practices. There may be technical drawbacks or even flaws associated with the Recommendation, but not so serious as to cause it to be Rescinded.

The W3C marks these as Obsolete to give guidance to the industry that new implementation is not sought or expected.

2) A new section of the Process Document, 6.X (6.10 if existing sections are not re-numbered, but it probably belongs before rescinded in logical order).

6.X Obsoleting a Recommendation

Anyone may request of the TAG that a Recommendation be considered for Obsoletion. The request to the TAG MUST identify the Recommendation and give reasons why it should be considered Obsolete; for example, that the Recommendation has not been implemented, and no new implementations are expected; that there are better alternative specifications; that the Recommendation in question is not in alignment with best design practices, and so on.

The TAG MUST announce its intent to consider the Request to Obsolete the Recommendation [[to other W3C groups]] and to the public and SHOULD consult with any pertinent working groups, especially the Working Group that developed the Recommendation, if it exists, or any obvious successor WG. The TAG MUST make the decision to proceed, by formal decision of the TAG.

The proposal to obsolete a Recommendation follows the process for a Proposed Edited Recommendation as defined in 6.7.2 and 6.5 for changes to a Recommendation that are Editorial only. The proposal is placed before the AC as a ballot if any of the following occur:
a) The TAG decides to proceed;
b) The TAG decides not to proceed, but 5% of the Advisory Committee file a request for the ballot;
c) The TAG makes no decision within 90 days of the receipt of the request; anyone (e.g. the initiator) may then request that the AC ballot proceed.

If there is dissent in the Advisory Committee (votes against, or formal objections) the usual process to find consensus will be followed. Objections SHOULD include evidence that the proposal is flawed; for example, that the Recommendation is widely implemented, or it is reasonably expected that it will soon be widely implemented.

Considering the advice of the Advisory Committee, the Director approves or denies the decision to obsolete. The Advisory Committee may appeal the Director’s decision.

An obsoleted Recommendation is marked as such (a) in the document itself and (b) on the TR page. The status ‘Obsoleted’ links to a standing page which explains the meaning of the term. If there are obvious alternative technologies, they should be documented in a note beside the Obsolete declaration in the document itself.

David Singer
Manager, Software Standards, Apple Inc.
Received on Friday, 6 May 2016 07:14:12 UTC

This archive was generated by hypermail 2.3.1 : Friday, 6 May 2016 07:14:13 UTC