Review of Process 2020

Florian,

Thanks for addressing my previous issues and rewriting Chapter 6.  Here 
are my review comments on the latest revision [1].

1. In several sections (starting with Section 3.1) there is a reference 
to a future version of the Patent Policy.  Since it is not yet written, 
you refer to a draft PP that you wrote [2] that has not yet been 
approved by PSIG which differs from the existing patent policy.  Since 
we have heard that the attorneys have a specialized legal vocabulary in 
terms of how they approach this, I encourage you to work with Wendy to 
see if all of the references to [2] are helpful to PSIG.  For situations 
in which [2] does not differ from the current PP (I'm not sure the 
frequency) we should consider referencing the current PP to reduce how 
much "change" will need to be gronked by PSIG reviewers.

2. I still don't like "Extensible".  Several alternatives were 
proposed.  What is our process to bikeshed the name?

3. 5.2.6.  There has been discussion in the W3Process CG that it might 
make more sense to allow every WG to decide what to designate as an 
Extensible REC rather than having this done in the Charter.  While I 
don't feel strongly, I felt that this opinion was getting greater 
traction from reviewers.  Taking that path might simplify some of the 
Process document text.

4.  My previous (4 November) comment about reference drafts - which you 
acknowledged should be looked at with the new PP.

    /5.2.6.  Reference Drafts.  Just a note. I haven't yet understand
    the full definition of "Patent Review Draft", so I cannot tell if
    its use to replace "Reference Draft or CR" is all-encompassing.  In
    particularly I'm concerned about migration - i.e. adoption of
    documents in new charters produced after Process2020 with the new PP
    - where the Reference Drafts are covered by Process 2019 and the
    current PP./

5. 6.1. I like the new clean definition of Recommendations.  I see that 
the definition incorporates key aspects of the gravitas of a REC: wide 
review, implementation experience, consensus.  It omits (explicit) 
mention of other aspects such as demonstration of interop, AC review, 
etc.  I'm not sure how long to make this definition - I note that PLH 
once documented 18 features of a REC - but we should discuss somewhere 
the right characteristics for this formal definition.

6. 6.1.1 (this might be a nit).  There is a paragraph at the end about 
how every report is edited by editors in a group appointed by a chair.  
I'm not sure this is true anymore since Errata can be done elsewhere 
(e.g. in a CG), and if there is no WG, the team can take such a 
document, get Director approval, and generate a new REC.

7. 6.1.2.  Second paragraph.  Second sentence.  I'm not sure this is 
true.  Even if true, I'm not sure it is needed in the process doc.

8. 6.1.6.  It is not clear to me why there is no MUST get commitments 
for Class 3 changes.  I think that this section of the Process doc 
should also get PSIG review.

9. 6.2.  I think we have a capability now for Documents to come in at CR 
level (i.e. CR = FPWD for those documents).  I don't know if that is 
clear enough in the process doc.  We are using it, for example, for DOM 
and HTML.

10. 6.2. CRUD.  I thought we were going to work on the acronym.

11. 6.2. Rescinded CR.  I'm not clear on why we need that.  We seem to 
have too many states already.  Can we just call it a Note?

12. 6.2.2, 6.2.4, 6.2.4.1 (and maybe some other sections) are hard to 
follow in the diff because the diff is for the particular section 
number, not for the equivalent content.  I'm pretty sure I have not 
given a substantive review.  Is there a way to fix the diff?

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.  Plus, some of the 
differences seem weird (class 4 changes must be public; but not class 3?).

14. 6.2.4.  Same question why class 3 and class 4 is treated differently.

15. 6.2.8.2.  It seems the title of the section should be about a CRUD 
(or whatever better name we come up with) rather than an UD.

16. In my previous review, I expressed that I didn't understand why we 
are treating class 3 changes (6.2.11.3) and class 4 changes (6.2.11.4) 
differently.  I continue to be concerned that we have too many branches 
in the process, with little additional advantage - compared to the 
alternative of using the 6.2.11.4 process for both class 3 and class 4.  
I could not find a compelling response to my previous comments, so I 
restate them here.

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.

Jeff

[1] 
https://services.w3.org/htmldiff?doc1=https://w3c.github.io/w3process/&doc2=https://w3c.github.io/w3process/everblue#Reports

[2] https://patent-policy.rivoal.net/