Re: Review of Process 2020

Thanks (F&F).  Additional comments inline.

On 12/2/2019 2:20 AM, Florian Rivoal wrote:
>
>
>> On Nov 28, 2019, at 6:34, Jeff Jaffe <jeff@w3.org 
>> <mailto: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.

As PLH said in a separate email, it would be good if this could be done 
before we send this to PSIG this week.


>> 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.

Thanks.  I agree with Carine that "Elastic" is a nice new word. But I'm 
ok with Expandable.


>> 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 providesthe 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.

I'll drop this issue.  I believe that Mike was expressing the opposite 
point of view.  But in the informal call last Wednesday he also said 
that his side was not a hill to die on.


>> 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.

Thanks.


>> 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, WGapproval, 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.

OK for now.


>> 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.

Fair enough.


>  I suggest you file a separate issue (and suspect we might not get to 
> it in 2020).

Done.


>> 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 Idon't think we should change or drop this.
ok
>>
>> 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 
> itmandatory), but dragging this into P2020 feels like a distraction.
ok
>>
>> 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 
> hasevaluated 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 
> eithersupposed 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.

OK, I've raised a separate issue for the Process, unrelated to ET.


>> 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/

Thanks.


>> 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.
ok
>>
>> 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>

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.

>
>> 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 
> reviewersnotice the scope of the changes. (See response to point 
> 13-14,above.)

See my response to point 13-14 above.  I'm trying to remove needless 
complexity from the process.


>> 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.

>
> 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 
> thattransitions 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
>>
>> [2] https://patent-policy.rivoal.net/
>>
>