Re: Review of Process 2020

On 12/2/19 3:08 PM, Jeff Jaffe wrote:
> 
> As PLH said in a separate email, it would be good if this could be done before 
> we send this to PSIG this week.

Done.

>>> 13. 6.2.3.  Not clear to me why class 3 and class 4 changes are treated 
>>> separately.  I think they should be the same.
>>>
>>> 14. 6.2.4.  Same question why class 3 and class 4 is treated differently.
>>>
>> The Horizontal Review Groups felt that feature additions were particularly 
>> noteworthy for them, and wanted them called out. You can see traces of this 
>> sentiment in the minutes at https://www.w3.org/2019/09/16-i18n-minutes.html 
>> <https://www.w3.org/2019/09/16-i18n-minutes.html>
> 
> I guess I didn't make my question clear.
> 
> We require a bit more processing for class 4 changes than we do for class 3 
> changes.  The cost of doing that in terms of process complexity is that we 
> have a more complex process.  I don't understand why we would not do the same 
> processing for class 3 changes as well: (a) It seems appropriate since class 3 
> is substantive, and (b) it simplifies the process.

While I'm personally happy to do this kind of documentation for my specs, one 
of the main points of concern we got from other spec editors a TPAC was that 
the Process not require spending so much effort on documenting changes.

So since HRGs felt strongly about documenting new features, and editors felt 
strongly about reducing the documentation requirements for changes, we ended 
up defining the requirements for documenting class 4 changes (new features) to 
be stronger than for class 3 changes (other substantive changes). ¯\_(ツ)_/¯

>>> 17. 6.2.11.5 Last Call for Review of Proposed Additions/Corrections.  In my 
>>> previous review, I expressed that this LCRPA/C was an unnecessary 
>>> introduction of a new type of review.  I had proposed that instead, the 
>>> document should enter the Proposed Extensible REC state, which should 
>>> automatically trigger an AC review.  Here again, I could not find a 
>>> response in our previous thread.
>>>
>> One of the design goals of the Call for Review process was to not trigger a 
>> change in status on the entire document. This is for three reasons:
>>     1. To highlight that we are reviewing the changes, not the whole 
>> document, which is already a REC.
>>     2. To maintain the signal to the public that the document they are 
>> looking at remains a REC, with the full endorsement of the W3C.
>>     3. To avoid unnecessary, possibly fairly frequent, status-change 
>> republications, which wastes staff time.
> 
> I had not previously made the connection - that the reason for the special 
> LCRPA/C process - rather than the usual progress of CR-PR-REC was to emphasize 
> that we are only reviewing changes. Thanks for the explanation.  Now I 
> understand it.
> 
> But I'm not sure yet that I like it.
> 
> I guess the alternative is to move the document into the Expandable PR state, 
> but add that Expandable PR does trigger an exclusion period.  But then leave 
> the AC review, etc., to be the same as for any PR.  That would still be 
> simpler (imho) then introducing LCRPA/C.
> 
> To address your three points above:
> 
> 1. We can mention in the guide that AC reviewers might want to only review 
> changes.  I'm not sure we should disallow them from providing a review of the 
> entire document.
> 
> 2. I'm not sure that calling it LCRPA/C achieves the signal anything better 
> than the rest of the process doc which already makes the point.
> 
> 3. I don't understand this point.

1. Sure. And of course everyone is always allowed to review the whole 
document, but pre-existing concerns about the document should not block the 
specific fixes being proposed. They should be filed and handled separately.

2. The document is still published as a Recommendation. Its status doesn't 
change. The LCRPA/A is a call for review, not a publication, in the same way 
that a Call for Exclusions is a call for review, not a document status.

3. If we're changing the status of the entire document from Recommendation to 
Proposed Whatever and then later back to Recommendation, then that's several 
manual publications with accompanying Comm team announcements. We don't want 
to incur this much overhead for folding minor fixes into a Recommendation.

Another point is that some amount of time may ellapse between the Call for 
Review / Proposed whatever, which is issued when the group has CR-level 
consensus on the proposed change, and the time they get folded in normatively 
(after having sufficient implementation experience). If we had to republish 
the REC as a Proposed-someting during that time, then RECs undergoing 
maintenance would spend most of their time not actually being a REC. (This is 
one of the key problems we're trying to solve with by introducing a 
change-based amendment process to replace the currently required transit 
through CR+PR.)

Doing this through a Call for Review that's not an actual publication allows 
the changes to be reviewed (and exclusion opportuities to kick in) without 
pulling back the REC to some other status while we get implementation experience.

~fantasai (and Florian)

Received on Thursday, 5 December 2019 04:33:08 UTC