Re: Obsoleting a Recommendation, round two

Is it reasonable to reach out to the authors of the REC? (as distinct
from the WG)

On Wed, Apr 27, 2016 at 12:43 PM, 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)?
>
>
> 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.
>
>
> 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.
>
>
>
>
>
> 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"
>
> 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.)
>
>
>
> David Singer
> Manager, Software Standards, Apple Inc.
>
>
>

Received on Thursday, 28 April 2016 03:49:17 UTC