Re: [Issue 72] Coalescing Subtantive Change and the Classes of Changes

On Jan 5, 2014, at 6:21 PM, Stephen Zilles <szilles@adobe.com> wrote:

> Ian,
> Thank you for clarifying (once again) the essence of your concern about the two definitions. See comments inline below
> 
> Steve Z
> -----Original Message-----
> From: Ian Jacobs [mailto:ij@w3.org] 
> Sent: Sunday, January 05, 2014 3:29 PM
> To: Stephen Zilles
> Cc: 'public-w3process@w3.org'
> Subject: Re: [Issue 72] Coalescing Subtantive Change and the Classes of Changes
> 
> 
> On Jan 4, 2014, at 8:41 PM, Stephen Zilles <szilles@adobe.com> wrote:
> 
>> Ian,
>> You objected to Charles McCathie-Neviles' combination of Change Classes and Substantive Change. Could you accept the change outlined below:
> 
> I believe we have discussed the difference between "substantive" definitions in the current (operative) Process:
> 
> - Before Rec we define substantive in terms of people's reviews.
> SZ: This is not quite true. The relevant sentence says, "A substantive change (whether deletion, inclusion, or other modification) is one where someone could reasonably expect that making the change would invalidate an individual's review or implementation experience". That is, implementation experience is included. 

Ok.

> 
> - After Rec we define substantive in terms of conformance/implementation.
> 
> SZ: The topic was re-raised by Elika Etemad (and supported by Charles McC). Their point is that the distinction (between review or implementation invalidation and conformance or implementation invalidation) is too subtle a distinction for the people that must implement the decision. In addition, there is some (probably) informative text in the current definition of substantive change, "Other changes (e.g., clarifications, bug fixes, editorial repairs, and minor error corrections) are minor changes.", that implies that "bug fixes" are not substantive. This could be fixed by using the same examples as used in Change Classes 1 and 2, but then what is the difference between the two definitions. 
> 
> SZ: I think you need to be more specific on what is important to you in distinguishing the two definitions.

(I'm not sure I agree with that characterization, but I won't spend time on that.)

One observation is that section 7.6.2 has the title "classes of changes to a RECOMMENDATION." If the proposal is to add a definition of "substantive change" to that section, and that definition applies to other types of document than Recommendations, the title (and probably other text) will need to be adjusted.

Another observation: the definition for changes to a Recommendation use the phrase "correction." (That is because the specification is done and thus changes that people want to make later are easy to think of as corrections to the original text.) But if the definition of "substantive change" is to apply both pre- and post-Rec, I suggest dropping the word "correction" in favor of "change." People may debate whether something is a "correction"; they are less likely to debate whether something is a change. That would give something like:

 1. No changes to text content
 2. Changes that do not affect conformance
 3. Changes that affect conformance but do not add new features
     [Note: I've added "that affect conformance" to make 3. more clearly mutually exclusive of 2.]
 4. New features

I agree that 3. and 4. defined that way should "cover" most of the changes that might invalidate a review. 

However, there might be scenarios that do not fall under 3. where we want to consider a change substantive. These scenarios would
be much more likely to relate to "broken agreements" than to "changes conformance." However, I do not have any concrete use cases to illustrate this point. I can make one up:

        Suppose the Foo WG asked that the spec include an informative appendix with a grammar definition in some formalism. The group first 
        included the appendix to resolve the dependency with the Foo WG. Later, the group decides the spec is too long and they decide to   
        remove the appendix. According to the new definition, this is not a substantive change. (Other parts of the process might catch this since  
        this relates to changes in dependencies.)

If others in the AB do not feel it is important to consider this sort of "broken agreement" scenario (unrelated to conformance), I'll withdraw my objection.

Ian

> The AB reconfirmed that distinction, I believe at the Tokyo face-to-face meeting.
> 
> SZ: True
> 
> The current proposal drops the distinction, redefining "substantive" only in terms of conformance. 
> 
> SZ: First "substantive" is defined in terms of "changing conformance or implementation", not just conformance. So, is your concern that we are not considering a change that would "change a review"?
> 
> I have not seen rationale for why there is a new proposal related to an issue we've already closed. What is the rationale?
> 
> SZ: rationale was given above.

> Ian
> 
> 
> 
> 
>> 
>> Section 7.6.2 Classes of Changes to a Recommendation says
>> 
>> This document distinguishes the following classes of changes to a Recommendation.
>> 
>> 1. No changes to text content
>> These changes include fixing broken links, style sheets or invalid markup.
>> 2. Corrections that do not affect conformance Editorial changes or 
>> clarifications that do not change the technical content of the specification.
>> 3. Corrections that do not add new features These changes may affect 
>> conformance to the Recommendation. A change that affects conformance is one that:
>> turns conforming data, processors, or other conforming agents into 
>> non-conforming agents, or turns non-conforming agents into conforming 
>> ones, or clears up an ambiguity or under-specified part of the specification in such a way that an agent whose conformance was once unclear becomes clearly conforming or non-conforming.
>> 4. New features
>> The first two classes of change require no technical review of the proposed changes. A Working Group may request republication of a Recommendation for these classes of change, or W3C may republish a Recommendation with this class of change. The modified Recommendation is published according to the Team's requirements, including Publication Rules [PUB31] and the Requirements for modification of W3C Technical Reports [PUB@@].
>> 
>> It is suggested that the definition of "Substantive Change" be moved to this section and be changed to say that a Substantive Change is either a class 3 or class 4 change. This removes some of the vagueness ("bug fixes") in the current Substantive Change definition.
>> 
>> Steve Zilles
> 
> --
> Ian Jacobs <ij@w3.org>      http://www.w3.org/People/Jacobs
> Tel:                       +1 718 260 9447
> 
> 
> 
> 

--
Ian Jacobs <ij@w3.org>      http://www.w3.org/People/Jacobs
Tel:                       +1 718 260 9447

Received on Monday, 6 January 2014 02:56:00 UTC