Revising a Recommendation: Substantive Changes or New Features.

[jeffjaffe]

In https://w3c.github.io/w3process/#revised-rec-substantive there are different processes for updating a REC for substantive changes (6.2.11.3) and updating a REC for new features (6.2.11.4). I don't see a strong reason for these processes to be different and I would prefer that we use a single process. By consolidating the changes into 6.2.11.4 we will also simplify the process - eliminating 6.2.11.3.

In addition, even if we keep these processes separate, I find the sections confusing. For example, 6.2.11.3 does not even mention how to introduce substantive changes into an Expandable REC - something which presumably we should allow - just as we allow this for new features (6.2.11.4).

The latest email discussion on this issue is at: https://lists.w3.org/Archives/Public/public-w3process/2019Dec/0016.html - points 13 and 14.

I don't think this is a blocking issue. But since I believe this will simplify the process, I believe it deserves more eyes on the topic than has been achieved in the email discussion.

[fantasai]

The processes are essentially identical. There are two reasons they are separated out into two subsections:

• Currently, new features can only be added to ERECs, not to RECs, so some wording needs to be there to make that limitation clear.
• The Call for Review of Proposed Changes is announced differently (“Review of Proposed Corrections” vs “Review of Proposed Additions”) depending whether there are new features or not, so that reviewers can more easily tell if the changes are just corrections or include additions.

For example, 6.2.11.3 does not even mention how to introduce substantive changes into an Expandable REC - something which presumably we should allow - just as we allow this for new features (6.2.11.4).

I think you're maybe confused... Expandable REC is a subclass of REC, the same way Edited REC and Amended REC are subclasses of REC. Every unqualified reference to “Recommendation” throughout the document refers to all of these types of RECs.

Therefore “Revising a Recommendation” including all its sub-sections (“Revising a Recommendation: Markup Changes”, “ Revising a Recommendation: Editorial Changes”, “Revising a Recommendation: Substantive Changes”, and “Revising a Recommendation: New Features”) all apply to Expandable RECs.

[jeffjaffe]

Thanks for the clarifications, Elika.

Given that the processes are essentially identical, and given that there is a trend to eliminate the EREC designation, perhaps with some good editing we can collapse 6.2.11.3 and 6.2.11.4 with short phrases indicating where new features and substantive changes are treated differently.

I'm also unconvinced that there should be a distinction between “Review of Proposed Corrections” and “Review of Proposed Additions”. It seems that one key difference is that we do not cause an AC review for substantive corrections. Given that such corrections affect conformance, it is not obvious why the AC does not review them. And if there is an AC review - then these two cases come closer together.

If we could bring those two together, we would further simplify the process by not needed to talk about “Review of Proposed Corrections”, “Review of Proposed Additions”, and "Review of Proposed Additions and Corrections".

[frivoal]

“Review of Proposed Corrections” and “Review of Proposed Additions” are exactly the same thing, except for the title, to help wake up the people who only really want to pay attention when something is new, and don't care as much about the fixes.

[frivoal]

Another thing I'll note here: Process 2019 already distinguished different ways to revise a REC depending on the 4 classes of change. It was a little less visible, because we've added (a while back, on the master branch of P2020) headings to the relevant paragraphs, for ease of referencing.

Since P2020/ever* is additive and does not remove any of the previously existing mechanisms, the these pre-existing dispositions will stay, and continue to offer different paths to handling class 3 (fixes) and class 4 (new features).

To this, we add the ever* dispositions to make substantive changes to RECs.

Based on #345, there may be some changes to how that works, but other than that, the only ways to simplify here would be to:

• drop the pre-existing mechanisms. I don't think that's acceptable.
• Eliminate/reduce differences between the pre-existing mechanisms for different classes. For instance, in the absence of a Working Group, the team can do fixes, which leads to an Amended REC, but they cannot do new features. We could abolish that difference, and allow the team to add new features. I don't think that's acceptable, and even if it were, that's a change that needs dedicated discussion.
• drop the sub-headings. I don't think that's useful.
• drop the requirement to name the "Call for Review of Proposed *" differently depending on whether it contains new features or not. That's doable, it doesn't seem desirable, especially given that Horizontal Review groups have expressed that reviewing new features required more attention than reviewing fixes. Calling attention to the fact that there are new features sounds relevant.

All in all, I propose to close this issue as won't fix. Depending on the result of #345, there may be some simplification (both procedural and editorial) to this part of the spec, but I don't think there are other simplifications to be made to 6.2.11.3 and 6.2.11.4.

[jeffjaffe]

All in all, I propose to close this issue as won't fix.

I would counter-propose that instead of closing with "won't fix" we label this issue with "Defer to Process 2021".

I accept that we cannot make such major changes for P2020 this late in the cycle.

In P2021 there has been discussion that we use that as a "bug fix", "streamlining" rev of the process - so we can take up this issue then.

[frivoal]

I would counter-propose that instead of closing with "won't fix" we label this issue with "Defer to Process 2021".

Sounds reasonable.

[frivoal]

I consider this bug to be fixed based on having merged #365

Agenda+ to either confirm that this is the case, or to defer to process 2021 as per #358 (comment)

[dwsinger]

The general case of adopting simplifications and streamlining in 2021, after (we hope) some experience, would seem to stand, so I think I'd put this into the 'defer' category as something to think about next (well, this) year. Slight preference to defer over close.

[css-meeting-bot]

The Revising W3C Process CG just discussed Revising a REC.

The full IRC log of that discussion

<florian> topic: Revising a REC
<florian> github: https://github.com//issues/358
<dsinger> issues tagged agenda+ https://github.com/w3c/w3process/labels/Agenda%2B
<fantasai> florian: My feeling is we made some simplifications already
<fantasai> florian: Either this is already addressed, or whatever bits not addressed, should address in next round of editorial fies
<fantasai> s/fies/fixes/
<fantasai> jeff: I definitely feel this should be deferred
<fantasai> jeff: my original comment was to make clear that you can have CR=FPWD
<fantasai> florian: that's a different issue
<fantasai> dsinger: you found this section confusing in Dec
<fantasai> florian: there's been changes, in the direction you wanted
<fantasai> florian: hopefully fixed, if not defer remainder of fix?
<fantasai> jeff: I proposed to defer to 2021 already, and Florian agreed
<fantasai> dsinger: OK, then we're removing Agenda+ and deferring
<fantasai> dsinger: any other opinion?
<fantasai> jeff: We'll go through AC review, I can reraise it in 2021 depending how things go
<fantasai> jeff: I think we can close this for now
<fantasai> fantasai: so close or defer?
<fantasai> jeff: Have to discuss what we're planning to do in 2021, so maybe can leave it open

[frivoal]

In #356, speaking of possible Process simplifications, @jeffjaffe said:

In terms of a concrete section, 6.2.11.5 is a great place to start. I'm unconvinced that we need three different processes called Last Call for Review of Proposed Corrections, Last Call for Review of Proposed Additions, and Last Call for Review of Proposed Corrections and Additions. To avoid that, requires some rethinking of the options that we have - we may need to drop process features to get some simplification. I had raised this with the editors prior to P2020 going to the membership but we ran out of time so I accepted an approach that I believe to be overly complex.

This part of the Process has evolved and been simplified since Jeff first raised this issue, but some complexity remains, and @jeffjaffe would like to do something about it, so we should discuss it.

Section 6.2.11.5 doesn't have 3 different processes, but it has 3 different terms for the same process applied to different things (bug fixes / new features / a blend of both). The terminology is introduced not because the process itself needs it, but because people involved in that part of the process may find it useful to discuss what is happening.

For instance, lawyers may want to pay more attention to new features than to bug fixes during exclusion periods. If we issue differentiated mails for "Call for Review of Proposed Corrections" and "Call for Review of Proposed Additions", they can easily look at those they care about and overlook the rest if they want to. The team can also call them just that, instead of coming up with ad-hoc (and possibly varying) paraphrases to describe them. E.g.:

This email is a Last Call for Review of Proposed Corrections.

vs

This email is a Last Call for Review of Proposed Changes. The document it refers to contain proposed changes of class 3 according to he classification established in https://w3c.github.io/w3process/#correction-classes.

Nothing is broken if we lose terminology, but it just gets harder to speak about the things these terms referred to. Whether that's a good idea probably depends on how important/frequent it is to talk about those things. We could shorten the process by a few lines by dropping these definitions, but that's not much, and as mentioned, it has downsides.

We could shorten the Process some more by either disallowing new features in RECs altogether (making Living Standards at REC impossible), or by eliminating the difference between class 3 and 4 of changes and allowing new features in all RECs (breaking the historical promise that RECs can't gain new features and denying WG who wish to make that promise the ability to do so). I don't think either is acceptable, though opinions may differ.

One thing we can probably do in this general area is in section 6.2.11.4. Except for the first sentence, its first paragraph is extremely similar to the first paragraph of 6.2.11.3, so we could probably replace this repetition with a reference to the previous section.

[frivoal]

My position on this issue is that the discussion it has generated has helped drive some amount of editorial simplifications to the relevant part of the Process. This is good, and so I'm glad we've had it. On the other hand, it is not somewhat stalled, and as expressed earlier, I am unconvinced that any of the possible remaining simplifications are actually good things. My proposal would be to close this issue as done, since it did drive simplifications, and if we find new simplifications, open them as new issues and discuss them individually.

[jeffjaffe]

As the one who raised this issue, I'm OK with closing it.

I continue to believe that further simplifications are possible and needed, but I believe that we should get some experience with how we use these features and then open a new issue after we have that experience.