Re: Obsoleting a Recommendation, round two

On 2016-04-29 08:43, David Singer wrote:
>> On Apr 27, 2016, at 9:43 , Wayne Carr <wayne.carr@linux.intel.com> wrote:
>>
>> I removed the AB from my response to avoid posting to public and private lists.  Someone on the AB forward it to that list.
>>
>> On 2016-04-25 11:08, Stephen Zilles wrote:
>>> David, just one small suggestion inline below.
>>>
>>> Steve Z
>>>
>>> -----Original Message-----
>>> From:
>>> singer@apple.com [mailto:singer@apple.com
>>> ]
>>> Sent: Monday, April 25, 2016 10:52 AM
>>> To:
>>> public-w3process@w3.org
>>>
>>> Cc: Advisory Board
>>> <ab@w3.org>
>>>
>>> Subject: Obsoleting a Recommendation, round two
>>>
>>> After offline discussion with some AB members, and the call today, I offer the following.
>>>
>>> 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.
>>>
>> Why is this explanation repeated in two places in the Process doc (6.x below and this one)?
> Because we need a page that explains what an obsoleted Recommendation is (this text) and we need a definition in the Process document itself.
>
>
>>> 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.
>>>
>>
>> It should be clear that when there are multiple revisions of recommendations, older ones can be obsoleted.  e.g.  a perfectly good, in its time, REC can be obsoleted when the W3C membership thinks implementers should be implementing a new version of the spec.
> I don’t think we’ll use Obsoleted for that, just that there is a newer version (so, superseded in a sense).
>
>>> The TAG SHOULD consult with any pertinent working groups, especially the Working Group that developed the Recommendation, or any obvious successor WG. The TAG MUST make the decision to proceed, by formal decision of the TAG.
>>>
>> The TAG is an advisory group.  I do not think we should allow the small number of people in the TAG to decide for the W3C membership whether a REC can be obsoleted.  The TAG should make a recommendation.  There should be a way for the AC to force an AC Review in any case.
>>
>> So I'd make this:
>> The TAG MUST make a recommendation on whether to proceed, by formal decision of the TAG.  The Director decides whether to proceed and that decision (either positive or negative) is subject to AC Appeal.
> I have a hard time seeing why we should proceed to Obsolete if the TAG actively disagrees. Surely we err on the side of NOT obsoleting?

Because the TAG is a particular group of people.  It isn't the W3C 
Membership.  There should be a way that if the Membership (the AC) wants 
a REC obsoleted, it gets obsoleted.

>
>>
>>
>>> SZ: I suggest the above sentence be, "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, or any obvious successor WG. The TAG MUST make the decision to proceed, by formal decision of the TAG."
>>> SZ: I based the announcement requirement on the announcement requirement for First Public Working Drafts, Section 6.3.1 of the current Process Document:
>>> https://dvcs.w3.org/hg/AB/raw-file/default/cover.html#first-wd
>>>   
>>>
>>> On the TAG’s decision to proceed, an Obsoleted 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.
>>>
>> With the change I suggested above, this becomes "On the Director's decision to proceed”
> Well, as usual, the Director gets the final say AFTER the AC vote. Does he really need to be in the loop twice?
>
>
>>> 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. 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.
>>>
>> Add: The Director's decision is subject to AC Appeal, unless the decision was to approve and there were no formal objections.
>>
>> (Note: I'm explicitly allowing an AC Appeal if the director rejects - some other Director decisions are cannot be appealed if the Director rejects the proposal and I think we should not create any more of those.)
> Yes, agreed, we should document what is Appeal-able. Thanks
>
>>>
>>> David Singer
>>> Manager, Software Standards, Apple Inc.
>>>
>>>
>>>
> David Singer
> Manager, Software Standards, Apple Inc.
>
>

Received on Friday, 29 April 2016 21:47:57 UTC