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

Re: Obsoleting

From: GALINDO Virginie <Virginie.Galindo@gemalto.com>
Date: Thu, 12 May 2016 18:44:53 +0000
To: "public-w3process@w3.org" <public-w3process@w3.org>, David Singer <singer@apple.com>
Message-ID: <fom5sq9ibnnhc60i2u3aioou.1463077523095@email.android.com>
Great work. The wording shared still use rescind, obsolete and retire qualifications. As a non english native speaker, it seems very complex and I can not catch the subtility of ut. Cant we use only one of them, explaining the different reasons for doing so (error,  not state of the art,  not used,  partial or complete.).
What do you think ?

---- David Singer a écrit ----

> On May 12, 2016, at 6:40 , Jeff Jaffe <jeff@w3.org> wrote:
> In general part of our objective for the past several years has been a reduction of the length of the process document.
> It is hard to get enthusiastic to add so much text for something so rarely used.
> I confess I don't have an immediate fix to my issue.
> Jeff

well, the version that has one section for both rescinding and obsoleting doesn’t add so much,  and it fixes a number of bugs in the Rescind process at the time (not that we ever use it). But agreed, it still seems awfully heavy and formal.

New versions attached, dealing with comments received.

a) clarify that the group has to *agree* to the request when an individual makes a request of the WG or TAG
b) clarify that the Director doesn’t just announce, but also starts a formal AC review
c) clarify that the publication depends on the Director’s final decision (“before *any* publication…”
d) clarify that contacting all W3C groups means using at least the all-chairs mailing list

here is the combined text inline for those for whom Word tracked-change documents are unreadable:

I also assume that this

Once W3C has published a Rescinded Recommendation, future W3C technical reports must not include normative references to that technical report.

is a typo for

Once W3C has published a Rescinded Recommendation, future W3C technical reports must not include normative references to it. [[i.e. to the Recommendation]]

(and why is it limited to Technical Reports?)

* * * *

6.9 Obsoleting or Rescinding a W3C Recommendation

W3C may rescind a Recommendation, for example if the Recommendation contains many errors that conflict with a later version or if W3C discovers burdensome patent claims that affect implementers and cannot be resolved; see the W3C Patent Policy [PUB33] and in particular section 5 (bullet 10) and section 7.5.

W3C may obsolete a Recommendation, for example if the W3C Community feels that the Recommendation no longer represents best practices, or is not adopted and unlikely to be adopted.
In this clause, the word 'retire' is used to refer to either obsoleting or rescinding. W3C only retires entire specifications. To retire some part of a Recommendation, W3C follows the process for modifying a Recommendation.

The process to retire a specification may be initiated:
a)      By anyone on request to the relevant Working Group (if it exists), or the TAG, and that group agrees;
b)      By the Director;
c)      On the request of anyone if their request to the WG or TAG is not acted on in 90 days;
d)      By 5% of the Advisory Committee.

The Director must announce the proposal to retire a W3C Recommendation to other W3C groups using at least the mailing list for all chairs, the public, and by starting an Advisory Committee review. The announcement:
•       must include the rationale for retiring the Recommendation;
•       should document known implementation;
•       must indicate that this is a Proposal to Rescind, or a proposal to Obsolete, a Recommendation;
•       must specify the deadline for review comments, which must be at least four weeks after announcing the proposal;
•       must identify known dependencies and solicit review from all dependent Working Groups;
•       must solicit public review.

If there was any dissent in the Advisory Committee review, the Director must publish the substantive content of the dissent to W3C and the public, and must formally address the comment at least 14 days before any publication as a Retired Recommendation. The Advisory Committee may appeal the decision.

A retired Recommendation must be published with up to date status. The status 'Rescinded' or 'Obsoleted' should link to a page explaining the term.

In the case of a Rescinded Recommendation, the updated version may remove the rescinded content (i.e. the main body of the document).

Once W3C has published a Rescinded Recommendation, future W3C technical reports must not include normative references to it.

Note: the original Recommendation document will continue to be available at its version-specific URL.

> On 5/11/2016 6:11 PM, David Singer wrote:
>> OK
>> here are two draft texts
>> 1) add a new section, closely modeled on Rescinding, that deals only with Obsoleting.
>> 2) A combined section, where 90%+ of the text is common, dealing with both Obsoleting and Rescinding.
>> I note that there are confusing aspects of the current Rescinding process.  For example, one has to show that the request has had Wide Review, and then we ask again for Public Review and review by the W3C. Why both?  I deleted the Wide Review clause.
>> Similarly, the Director has to show he’s starting the process because of public comment, but then any initiation has to include rationale. Why the Director can’t simply supply Rationale (including, if he has it, public comment) is not clear. So I removed this unique requirement on only the Director.
>> Some of the paragraphs were in a funny place; e.g. the requirement that you shouldn’t refer to a Rescinded recommendation was in the middle of the process, whereas logically it follows at the end of the process, once Rescinsion has happened.
>> I was in two minds as to whether the TAG can only be used if the WG doesn’t exist, but this opens the whole question of whether this is the ‘same’ WG; I think it safer always to allow the TAG to do it.
>> I can’t say I am enthused about fixing the Rescind process, as we have never (?) used it. On the other hand, I am not enthused about having two similar steps with slightly different processes, nor of having odd bits of the process with bugs (e.g. you can’t appeal a decision if it’s bizarre but there wasn’t preceding dissent), so on balance I think the combined clause makes more sense.
>> Drafts enclosed, change-tracked in Word.  Let me know if you cannot open them.
>>> On May 10, 2016, at 16:30 , Wayne Carr <wayne.carr@linux.intel.com>
>>>  wrote:
>>> On 2016-05-09 16:42, David Singer wrote:
>>>>> On May 9, 2016, at 9:14 , L. David Baron <dbaron@dbaron.org>
>>>>>  wrote:
>>>>> (The one other thing I was worried about with this obsoletion
>>>>> discussion was that it might be creating a process that's hard
>>>>> enough to complete that it will never be used successfully.)
>>>> It does seem very heavy, but only because of the fail-safe valves in some places.  Those valves are actually missing from the Rescind process as well, so we could make it all much easier and adjust the section on Rescinding to cover both cases. (For example, we have no way to Rescind a document if the WG no longer exists; there is no way for the AC to over-ride a bad WG decision, or to proceed in the absence of a decision.)
>>>> * Anyone suggest to the owning Working Group (if it exists) or the TAG (otherwise) that a document be Obsoleted or Rescinded.
>>>> * That group does the technical sanity check etc.
>>>> * The AC votes
>>>> * The Director approves
>>>> * The team does the appropriate marking/editing.
>>>> Safety valves: AC can override the WG/TAG ’no' if someone can find 5% of the AC wanting to force a ballot. If the WG/TAG doesn’t act in 90 days, anyone can force it to the AC by saying “timeout!”. The AC can appeal the final Director decision.
>>> +1
>>> combining them is good, as is listing the safety valve exceptional case separately.  that makes it clear it almost always is very simple.  i think its a good model for a lot of decisions.
>>>> Dave Singer
>>>> singer@mac.com
>> Dave Singer
>> singer@mac.com

David Singer
Manager, Software Standards, Apple Inc.

This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited.
E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender.
Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus.
Received on Thursday, 12 May 2016 18:45:24 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 12 May 2016 18:45:25 UTC