Re: Review of Process 2020

> On Nov 28, 2019, at 6:34, Jeff Jaffe <jeff@w3.org> wrote:
> 
> Florian,
> 
> Thanks for addressing my previous issues and rewriting Chapter 6.  Here are my review comments on the latest revision [1].
> 
Thank you for keeping at it.
> 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.
> 
Our (partly executed) plan is to replace section numbers in references to the patent policy with section names, making it more robust to updates. We did switch the reference to the Patent Policy itself to the new draft, but we can switch that back to the old one until the new one gets more traction.
> 2. I still don't like "Extensible".  Several alternatives were proposed.  What is our process to bikeshed the name?
> 
Ideally, I'd like more than 3 people involved... but switched it to Expandable for now.
> 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.
> 
The goal of placing a constraint on non-Expandable RECs is not to better fit the WG's work-mode, but to make a promise to the outside world that a REC will not gain new features.

From that, two points:
- It's not clear to me that the WG itself is the right level to be aware of such outside needs => asking the AC
- For such a promise to be useful, it needs to be enforced => putting it in a charter

Also, it's not much of a simplification (in the Process anyway) to remove this from the charter.

The real simplification would be to drop the distinction between X-RECs and RECs altoghether, but that's only a good idea if there's no value in making a stable-featureset promise to the outside world.

For years, we've complained about people linking to dated drafts, because these are quickly obsolete. A big reason people don't link to the undated one is that it may be changing in scope. A fixed-scope REC provides the in-between: a promise that while the document will get fixes, it will not add new features.

This is not essential to the notion of everteal, so that's not the hill I'll die on if there's too much pushback. But it does seem a simple way to address a problem we've been having.
> 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.
> 
Still pending a completed (or nearly so) Patent Policy (or the decision not to have one) before reviewing that text again. But yes, we will need to add a migration clause to the new Patent Policy.
> 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.
> 
The definition should (and does) operate at a higher level than its detailed requirements, e.g. “endorsement of the W3C and its Members” is just a more abstract way of referring to the AC review, Director's review, WG approval, etc. (I'll also note that most of this definition is unchanged from the current Process, see https://www.w3.org/2019/Process-20190301/#maturity-levels)

I'm going to take this as there being nothing to do for now, since you like the new definition. We can always come back to it if we want to iterate further.
> 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.
> 
This paragraph is unchanged from the current Process, fwiw:
  https://www.w3.org/2019/Process-20190301/#DocumentStatus

So even if you do think this should be addressed, it doesn't seem like it should block everteal. I suggest you file a separate issue (and suspect we might not get to it in 2020).
> 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.
> 
This is not a new sentence, it was in 6.2.3 previously. And while there's some wiggle room in the definition of "timely", this remains true in practice, and is only a should anyway. It's largely orthogonal to everteal, so I don't think we should change or drop this.
> 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.
> 
This is unchanged from the current operative Process. I wouldn't mind tightening this (especially once we have a patent policy that defines contribution commitments, we could reuse that agreement and make it mandatory), but dragging this into P2020 feels like a distraction.
> 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.
> 
Hmmm. Interesting problem. I don't think there's anything in the process that allows for that. FPWD is supposed to come before CR, and the Patent Policy seems to have this as an assumption (not sure anyone has evaluated the consequences of breaking that assumption).

For HTML and DOM specifically, they have been RECs before, and there is a possibility to go from REC to CR, but that's only supposed to be used where there's no new feature. To add new features, you're either supposed to start from FPWD and forward again, or (somewhat abusing the process), go REC->CR->WD->CR... [ See https://www.w3.org/2019/Process-20190301/#rec-modify ]

We could allow for a First Public CR, but we'd need to make tweaks to both the Process and the Patent Policy to make that work.
> 10. 6.2. CRUD.  I thought we were going to work on the acronym.
> 
Lol. Done.
s/CR Update Draft/CR Udate/
s/CR Review Snapshot/CR Snapshot/
> 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?
> 
No, because rescinding something has implications for patent obligations. If we adopt the updated Patent Policy which applies obligations to CRs, we will need to be able to rescind CRs as well as RECs.
> 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?
> 
There are three diffs you can look at:
- master branch vs master branch + refactoring
  https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fw3c.github.io%2Fw3process%2F&doc2=https%3A%2F%2Fw3c.github.io%2Fw3process%2Fsection-6-clean-up
  
- master branch + refactoring vs everblue
  https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fw3c.github.io%2Fw3process%2Fsection-6-clean-up%2F&doc2=https%3A%2F%2Fw3c.github.io%2Fw3process%2Feverblue%2F

- master branch vs everblue (least comprehensible)
  https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fw3c.github.io%2Fw3process%2F&doc2=https%3A%2F%2Fw3c.github.io%2Fw3process%2Feverblue

Hope this helps.
> 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>

> Plus, some of the differences seem weird (class 4 changes must be public; but not class 3?).
> 
Yeah, that's weird. Should be consistent. Fixed.

> 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.
> 
Fixed.
> 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.
> 
1) They are already treated differently in the current process.
2) See answer to your point 3 higher up in this mail.
3) Given an Expendable REC, the process is not just similar, but identical for both classes of changes, except in how they are named.

The differences are a) to allow class 4 changes only to Expandable RECs and b) to call out that the changes are for new features, to help reviewers notice the scope of the changes. (See response to point 13-14, above.)
> 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.

Note, Proposed REC doesn't trigger an exclusion period (it relies on the CR exclusion period and a lack of changes between CR and PR), so this would need to be a distinct status from the Proposed REC that transitions a spec from CR to REC.

—Florian (& fantasai)

> Jeff
> 
> [1] https://services.w3.org/htmldiff?doc1=https://w3c.github.io/w3process/&doc2=https://w3c.github.io/w3process/everblue#Reports <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/ <https://patent-policy.rivoal.net/>