ISSUE-72: Rationalising the definition of different types of change

change types

Rationalising the definition of different types of change

Document life cycle (pre 2014 chapter 7, now chapter 6)
Raised by:
Charles 'chaals' (McCathie) Nevile
Opened on:
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.
Related Actions Items:
No related actions
Related emails:
  1. Minutes and summary of 3 February 2014 Chapter 7 Revision Task Force teleconference (from on 2014-02-04)
  2. [minutes] and summary of 27 January 2014 Revising W3C Process Community Group Teleconference (from on 2014-01-27)
  3. Re: Suggested and Adopted updates to the Dec 11 Process Document Draft (from on 2014-01-20)
  4. Re: New chapter 7 draft (from on 2013-12-12)
  5. New chapter 7 draft (from on 2013-12-12)
  6. Re: w3process-ISSUE-72 (change types): Rationalising the definition of different types of change [Document life cycle (ch 7)] (from on 2013-12-06)
  7. Re: w3process-ISSUE-72 (change types): Rationalising the definition of different types of change [Document life cycle (ch 7)] (from on 2013-12-06)
  8. Re: w3process-ISSUE-72 (change types): Rationalising the definition of different types of change [Document life cycle (ch 7)] (from on 2013-12-06)
  9. w3process-ISSUE-72 (change types): Rationalising the definition of different types of change [Document life cycle (ch 7)] (from on 2013-12-06)

Related notes:

In current drafts this has been done

Charles 'chaals' (McCathie) Nevile, 22 Jan 2014, 12:38:44

[koalie]: suggestion to move the combined thing up to 7.2 where other definitions are and reference it back in 7.8

27 Jan 2014, 16:14:52

Changes are implemented in section 7.8 of the 22 Jan 2014 editor's draft. The defintions will be moved up to section 7.2 with the other defintions and be referenced from section 7.8

Steve Zilles, 27 Jan 2014, 16:15:25

[koalie]: see action-27

27 Jan 2014, 17:26:11

Change was fully implemented in 2 February editor's draft

Steve Zilles, 3 Feb 2014, 16:12:20

[koalie]: chaals: 72: I moved the section defining changes to the earlier definitions section, as agreed

4 Feb 2014, 07:49:35

Display change log ATOM feed

David Singer <>, Chair, Dominique Hazaƫl-Massieux <>, Staff Contact
Tracker: documentation, (configuration for this group), originally developed by Dean Jackson, is developed and maintained by the Systems Team <>.
$Id: 72.html,v 1.1 2020/03/09 13:50:15 carcone Exp $