W3C home > Mailing lists > Public > public-w3process@w3.org > October 2014

Re: Proposal for Publishing REC Errata

From: David (Standards) Singer <singer@apple.com>
Date: Wed, 15 Oct 2014 14:25:48 -0700
Cc: Jeff Jaffe <jeff@w3.org>, Stephen Zilles <szilles@adobe.com>, "chaals@yandex-team.ru" <chaals@yandex-team.ru>, fantasai <fantasai.lists@inkedblade.net>, W3C Process Community Group <public-w3process@w3.org>
Message-Id: <41768242-8591-4B69-AFFD-AE1278BE0C6D@apple.com>
To: Wayne Carr <wayne.carr@linux.intel.com>

On Oct 15, 2014, at 14:10 , Wayne Carr <wayne.carr@linux.intel.com> wrote:

> But if some WG decided to have a moderated issues list that only contained a clear description of the errata and it's resolution by the WG (not the entire history of all discussion of it) that sounds like an "errata page" as defined in the Process document.
> It has to be a clear list of problems the WG agrees are problems and resolutions the WG agrees with.  And then it should move into the REC as soon as possible.
> I think having a WG Note that shows what it would look like if it turns out OK to do could help motivate people to do the parts that need to be done - like convince the Director it can be implemented compatibly.
> Frequent publications of Edited RECs for the easy cases would be good.

Pretty much what I am thinking.

1) WG consensus that a bug/issue is an error.  Tag it appropriately.  Reflect it in a page (database query)…
2) that also refers to a document (which probably won’t have the same status) that has the fix contained (once the fix is identified, but something can be a mistake well before we know how to fix it)
3) when the fix is known, fix the bleeding edge and document the fix in the bug/issue as well.

David Singer
Manager, Software Standards, Apple Inc.
Received on Wednesday, 15 October 2014 21:26:40 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:51:22 UTC