W3C home > Mailing lists > Public > public-webplatform@w3.org > December 2014

Re: double-check

From: Dave Gash <dave@davegash.com>
Date: Thu, 4 Dec 2014 11:53:31 -0800
Message-ID: <0DD9FEB659954AA59890681E16A4C19E@dell257ee54463>
To: "PhistucK" <phistuck@gmail.com>, "Amelia Bellamy-Royds" <amelia.bellamy.royds@gmail.com>
Cc: "List WebPlatform public" <public-webplatform@w3.org>, "Eliot Graff" <eliot.graff@microsoft.com>, "Doug Schepers \(w3c\)" <schepers@w3.org>
Agreed -- an "obsolete" note and spec references are being added, and the pages are not actually deleted. However, my project goal has been to assign proper readiness flags to as many pages as possible, and removing the flag entirely would impede that goal. "Not Ready" seems to be the best setting, given the circumstances.


  ----- Original Message ----- 
  From: PhistucK 
  To: Amelia Bellamy-Royds 
  Cc: Dave Gash ; List WebPlatform public ; Eliot Graff ; Doug Schepers (w3c) 
  Sent: Thursday, December 04, 2014 11:44 AM
  Subject: Re: double-check

  Since most of this API is implemented by Chrome (and Safari as well, I think), I do not think the documentation for it should be deleted.
  A prominent warning of obsoletion, low browser support and unmaintained documentation should be added and the pages are better left as they are. If we can remove any mark from those pages (not "Ready" and not anything else. I think I have seen such pages), I think this should be preferred.

  Once we get to a point where all of the supporting browsers remove this feature, I think we can delete it after some grace period.


  On Thu, Dec 4, 2014 at 9:12 PM, Amelia Bellamy-Royds <amelia.bellamy.royds@gmail.com> wrote:

    It's a good question.

    In general, the WPD policy (as I understand it) is that deprecated/obsolete status is NOT reason to delete a page.  The Docs should be comprehensive, real world documentation of any features someone is likely to come across when studying web page code.  Deprecated and obsolete status should be clearly indicated, and these pages should maybe be filtered out of topic listings and such, but they should still be there for historical record.

    HOWEVER, when it is an entire proposed API that is obsolete because the spec was never completed, the benefit is less clear.  We certainly don't want to waste time "fixing up" these pages.  However, if they are reasonably comprehensive to start out with, it does seem a shame to dump them when they might conceivably be useful as an archival reference.

    My recommendation is that the first priority should be to make sure that the obsolete status (as an abandoned experimental feature) is clearly indicated and that these pages aren't showing up anywhere they would be mistaken for active features.  That said, if the community would prefer to just clear out the clutter, I wouldn't put up too much of a defence.

    Amelia BR

    On 4 December 2014 at 11:43, Dave Gash <dave@davegash.com> wrote:

      Hi all,

      I'm working through the remaining large batch of Almost Ready pages, trying to promote as many as possible to Ready, and have a question. See this search results page.

      I'm down to the filesystem group, some 60+ pages, and they all seem to be obsolete. They reference this 2014 W3C spec, which says "Work on this document is discontinued..."; that discontinued status is also supported by various MDN specs like this one and this one, which say "This feature is non-standard and is not on a standards track..." There is even an old W3C spec from 2012 that references the 2014 "discontinued" document as the latest published version.

      Based on those specs, I've been marking the pages "Not Ready" and including "Non-standard; deletion candidate" in the editorial notes, along with the discontinued spec references. But I'm a bit uneasy about invalidating that many pages at once, and want to make sure I'm reading the specs correctly and taking the right action. 

      List-ers, do you agree that the W3C specs indicate that the whole filesystem page group is kaputski?


      Dave Gash
Received on Thursday, 4 December 2014 19:53:45 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:14:09 UTC