- From: Ian Jacobs <ij@w3.org>
- Date: Fri, 6 Dec 2013 07:12:55 -0600
- To: Arthur Barstow <art.barstow@nokia.com>
- Cc: Revising W3C Process Community Group <public-w3process@w3.org>
On Dec 6, 2013, at 7:05 AM, Arthur Barstow <art.barstow@nokia.com> wrote: > Ian - I see that you closed this Issue without any discussion. I don't think that is appropriate since neither the list or I were automatically notified that you closed this bug. That was a mistake. (I had been thinking about it but meant only to comment.) > > I reopened it. Thanks. > > If you think some other Issues list is a better place to raise Publication Rules issues, then please let me know the location of that service. I agree that this is not the right forum. I will find a better one but I'll leave this open here for now. Ian > > -Thanks, AB > > On 12/6/13 3:36 AM, ext Revising W3C Process Community Group Issue Tracker wrote: >> w3process-ISSUE-72 (change types): Rationalising the definition of different types of change [Document life cycle (ch 7)] >> >> http://www.w3.org/community/w3process/track/issues/72 >> >> Raised by: Charles McCathie Nevile >> On product: Document life cycle (ch 7) >> >> I already attempted, earlier, to clarify the definition of types of changes and the requirements they imply at various transitions, or for in-place editing. >> >> Fantasai raised the question again, in ISSUE-59, of consolidating the definitions. >> >> Currently "Substantive changes" are defined in 7.2.1, and in 7.6.2 there are types of changes defined to explain what kind of update is needed to make them. >> >> I propose to redefine the changes. Note that I have once again picked up the term "substantive corrections" and these along with "new features" are what the current spec calls "substantive changes" earlier, and splits into two later without labeling them. I propose to put the definitions in the section on revising recommendations a link to them in the general requirements for transition >> >> Here is a rough cut at the content that would be in the section on revising recommendations (replacing the current 7.6.2): >> >> Simple correction: >> Changes to markup, updating links where the original destination is broken, style changes which do not affect the visibility of content (e.g. fonts, colours and borders). >> >> These are allowed to be made in place, including to a Recommendation. >> >> Editorial correction: >> Changes which do not affect conformance, including simple grammatical corrections, substantial style changes, changing references, reordering of existing content. >> >> These do not require a technical review, but when applied to a Recommendation a new Edited Recommendation must be published by the Team or requested by the Working Group and approved by the director. >> >> Substantive Corrections >> Changes which clarify conformance, so that for an implementation where conformance was not possible to determine it becomes possible to determine that it is conforming or non-conforming. Changes that would make a non-conforming implementation conforming, or vice versa, without introducing any new features. >> >> Making these changes to a Recommendation requires technical review, by publishing as a Candidate Recommendation prior to producing a Proposed Edited Recommendation >> >> New features >> Changes that require the implementation of an additional, or significantly modified algorithm. >> >> These changes SHOULD only be made through a complete process from First Public Working Draft. >> >> Some explanation: >> It is impossible to be entirely accurate in definitions of changes. For the earlier point where they are introduced in the document, the requirement is that substantive changes MUST and significant editorial changes SHOULD be identified between Public Working Drafts. For changes to Recommendation it gets trickier. Allowing substantive corrections to be made by an Edited Rec is intended to meet some of the goals of the "Living Standard" idea, that it is important to correct the actual document, while not losing the earlier references. >> >> I'm not big on the idea of allowing grammatical corrections - these can seem trivial at the time, but in fact change conformance. And different people read english grammar differently. At the same time, requiring a full director's call because someone wanted to remove split infinitives while correcting trivial markup seems a serious bureaucratic overkill. >> >> Where "substantive corrections" are made, requiring a Candidate Recommendation seems like a balance between giving members the opportunity to check that there are not patent implications to the change (since in the new process CR provides an exclusion opportunity on the delta from what has already been through a patent review), and not complicating the process of publishing too much. >> >> This proposal allows "Substantive Changes" to be made without a complete revision, *in principle*. It still requires director's approval (the transition to CR). The idea is that fixing something reasonably serious or adding something relatively simple and uncontroversial *could* be done in a more lightweight manner. This would in particular support mature specs, that really need substantive maintenance fixes but really don't need to begin from scratch. >> >> In general I would expect the Director to send work back to FPWD if a group wanted to make significant changes. In addition, having the charter set the scope of a group, and the time it is allowed to work without being checked, provides a further opportunity to test whether the group is going too far on its own. >> >> >> > > -- Ian Jacobs <ij@w3.org> http://www.w3.org/People/Jacobs Tel: +1 718 260 9447
Received on Friday, 6 December 2013 13:13:07 UTC