Re: EverTeal

> On Nov 4, 2019, at 9:09, Jeff Jaffe <jeff@w3.org> wrote:
> Florian,
> 
> Some comments.
> 
Hi,

Thanks a lot, I very much appreciate such a thorough review. Detailed answers on your comments inline.

> 1. We need an explainer.  Most particularly I have the following concern.  We would like to encourage stakeholders to utilize the new processes: updating, streamlining, etc. as we will now have a more agile process.  But with all of the options, the reader of the process document will only see that there is much more to read and more apparent complexity.  We need to have an English language description of the possible paths through the document and why this is helpful.
> 
> This is particularly true because the process document text often includes language to handle unlikely corner cases.  An explainer can focus on the usual case.
> 
Agreed. Not done yet, but absolutely on the todo list.
> 2. I'm not sure that Extensible is the best adjective since we use it for the Extensible Web.
> 
Any suggestion? Previously used "Living", which suggested other RECs were dead, and that wasn't great.

> 3. In section 5.2.6 s/discression/discretion/

Fixed.
> 4. In the fifth bullet of 5.2.6 (the new one) there are three paragraphs.  However, only the first one seems actionable.  The other two seem like parenthetical claifying text and so should be treated as such (e.g. by using parenthesis, or starting with the word "Note).
> 
Fixed.
> 5. 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.
> 
This should be revisited when the new Patent Policy settles down. This section had complicated wording to start with, and we think we've made the right edits to accomodate everblue/teal and what we expect the Patent Policy to become, but it'll need a second look. Migration from the current Patent Policy to the new one is also an issue we need to cover as part of working on the new Patent Policy.
> 6. 6.1.2.  In the second bullet after CR, there is a deleted explanatory phrase which says that we publish CRs to provide an exclusion under the PP (which previously was the LCWD).  If I understand this correctly, that motivation still exists; presumably at the first entry into CR (which is always a CRS).  It seems worthwhile to mention that in 6.1.2.
> 
This point is moved and rephrased, not deleted. It's now just a bit further down, the first paragraph under the "Candidate Recommendation Review Snapshot" entry.

The rephrasing is largely because the old sentence used the term "exclusion opportunity", which isn't defined in the Patent Policy, so instead we used "call for exclusion", which is, and adjusted the phrasing around that to keep the sentence grammatical.

Is there any aspect of the old phrasing you'd like to restore, or any other tweak you'd like to see?
> 7. 6.1.2.  There is an immediately following green box which says (among other things) that after CR, no additional changes are expected without implementation and testing.  That, and some other points in that box may not be true with the new CR.  We may want to reswizzle the language.
> 
Good point. Tweaked that note accordingly.
> 8. PR.  It seemed awkward to define Proposed Extensible Rec only as the flavor of PR that shows up before an Extensible Rec, but not talk about it elsewhere in the document.  I believe the fix is that in the definition of Extensible REC - rather than saying that for an Extensible Rec that the team MUST solicit an AC review, we should instead say that to get to Extensible REC, after the WG decision, that the document becomes a Proposed Extensible Rec (which would then automatically create the AC review).  Similarly, I think it would be helpful in 6.7.5, while discussing how to get to Extensible REC, that text is added that describes that after the WG decision that the spec moves into the Proposed Extensible Rec state.  (See related comments below.)
> 
There are two things, and I'm not entirely sure if you're talking about one of them or both:

* Advancing (from CR) to Extensible REC goes through a PR phase that works exactly the same as if you were trying to advance to regular REC. We just decided to call that PR "Proposed Extensible REC" to make it clear what the next step is. This is mentioned in the 6.1.2 definition of PR, and in 6.5 about PR transitions. We could add a mention of that in 6.7.5, but no other section has that kind of "this is what the step before me is".

* Republishing a regular REC as an Extensible REC. This is defined to need an AC review to avoid doing it frivolously, without going through a PR phase, as the thing under review is not the spec itself, but the right to add features to it.

Other than the possible addition to 6.7.5, I'm not 100% clear on what your question is. Does the above answer it, or do you need something else?

> 9. PR.  The PR section starts (and this is true in the REC section as well) that the document has been accepted by the Director.  For documents that reach REC status without formal Director transition review (streamline), I wonder if we need to swizzle the language a bit.  In esssence, the REC (and PR) are achieved because of the Director: the combination of the the W3C Process (approved by the Director), the fact that there was an initial transition request (approved by the Director), and the WG revisions (approved by the Director approved process).  But it is stretching the definition to say that this was actually approved by the Director.
> 

Given that it is defined elsewhere how they are accepted, saying accepted **by the Director** here is indeed not helpful, either it is redundant if that's the only way they can be accepted, or contradicting the rest of the process if it's not. Rephrased by invoking "the W3C" rather than "the W3C Director", leaving the rest of the process to define how that works.

> 10. REC.  You've deleted the statement that RF licenses apply to REC.  I don't see why we should delete that.  It is still true that RF licenses apply to REC.  Perhaps you deleted it because RF licenses will now ALSO apply to other specs.  In that case, I would leave the current statement, but perhaps add a parenthetical "... apply to RECs (as well as other specs for which xyz is true)."
> 
That's indeed why we removed it, but you are right that it's still true regardless. I've restored the sentence, without a parenthetical, as "xyz" would be a too long to phrase, and would distract from the point that sentence is making.
> 11. Extensible REC.  I'm not sure that the first three sentences of this section are helpful.  As I understand it, to advance to REC requires a Director decision, which is not always the case for Extensible REC (streamline).  An alternative might be to talk less about the process, and more about the implications - such as "An Extensible REC is treated with the same importance and gravity as a REC, even though the process to approve an Extensible REC is somewhat different."  And of course, it is good that you point out that an Extensible REC = REC from the pov of the PP.
> 
> 12. Extensible REC.  Second paragraph.  s/explicitely/explicitly/.
> 
Fixed.
> 13. Extensible REC.  See point #8 above.
> 
See answer to 8.
> 14. Extensible REC.  Last sentence. "same process".  Same as what?  Unclear.
> 
Same as the process for going from REC to Extensible REC, in the paragraph before the note preceding that sentence. Clarified by merging the paragraphs before and after the note.
> 15. 6.2.3.  There is a note that says that Update request approval is expected to be fairly simple.  That sounds like "marketing".  It would be more useful to explain WHY it is expected to be fairly simple (e.g. if we assume that most updates will be relatively targeted rather than the size of the usual transition to CR).
> 
This sentence was in the process already, in the CR section[1] before that got refactored into the Update Requests section (see the answer to your point 21). We could refine / rephrase / drop it, but that seemed unnecessary so we left it as-is.

[1] https://www.w3.org/2019/Process-20190301/#revised-cr <https://www.w3.org/2019/Process-20190301/#revised-cr>
> 16. 6.2.3.1.  For Streamline, I have several concerns about some details of the HRG approach:
> 
> We have not had much discussion about "the set of criteria" under which a review is necessary.  Accordingly, I expect that this might reduce to having 5 HRG reviews for each update.
> 5 HRG reviews for each update seems like a large amount of total reviews, unless there are some limitations on the frequency of updates.  6.2.3.1 might be a good place for a Note which says that it is expected that each spec gets updated at most every 6 months (in most cases) to reduce the level of review.
> For the TAG, I am concerned that they might neither have "a set of criteria", nor have the bandwidth for all of these reviews.  Personally, I would be comfortable if we only required a review of an update for 4 HRGs.  I'm hoping that in all cases, the TAG review for the original CR suffices.
A few points:
  * Update requests are only issued for CR Snapshots and REC updates, which are indeed rate-limited to approximately once every six months (because legal demands it, even if HRGs didn't). For CR, rate limiting was missing from the Process when you reviewed it, but PLH caught that, and that's now fixed.
  * Each HRG can set its own criteria, so for example, if the TAG only wants to review the initial CR, then they can state that as their criteria. An HRG can also state that they don't feel the need to be consulted on any updates to that particular spec. a11y, for example, might waive any need to consult on css-syntax-3 after having reviewed the scope of its CR and determined it's unrelated to their concerns.
  * In the absence of explicit criteria, you'd have to ask them and get a "you're good to go" confirmation you can point to. 

I expect this to be a part where the rules are simple, but we'll need to acquire (and document) experience with in before we strike the right balance in practice, and settle on criteria that are both rigorous and lightweight enough. Tooling can also help make this more straightforward and organized, but this process can still be workable with email and/or wbs as we work that out.

> 17. 6.2.7 Contributor License Grants.  I have no intuition why we would make these changes for ET, but perhaps it is related to some other PP change.  But in general, we should be careful about making changes that are not strictly needed for ET.
> 
As Contribution Claims are a thing the new PP intends to define, the idea here was to just reuse that definition. But you're right, this is not strictly necessary. Reverted.
> 18. I find some confusion between Sections 6.4, 6.4.1, and 6.4.2.
> 
> The general approach of Chapter 6 is to define a maturity level and end the section with a description of what is next.
> 
> Here 6.4 defines CR; but at the end describes what happens after a CRS.
> 
> 6.4.1 defines CRS, but does not describe what happens next (it is already listed in 6.4).
> 
> 6.4.2 is the more conventional defining CRU and what comes next.
> 
> At a minimum there is a lack of parallel structure.
> 
I agree that section 6 is overall confusing, as it splits definitions between 6.1.2 and 6.x (x>=3), and intermingles definitions and next steps in the 6.x (x>=3) sections. This problem predates the everblue/teal edits, and fantasai filed a separate issue about this at https://github.com/w3c/w3process/issues/336 <https://github.com/w3c/w3process/issues/336>.

The current text is the best way we could think of structuring that text prior to solving the overall issue.

I was initially thinking we'd fix that in the next Process cycle, but making things understandable is valuable now, so we're going to need to solve this now.

TL;DR: not solved yet, but on the radar.

> 19.  6.4.  In the list of next steps after CR (or CRS actually), I suggest we delete that PR is the expected next step; since often the next step is a CRU.
> 
Fair enough. Deleted.
> 20. Charters and CRS.  When I got to 6.4.1/2 I think I finally understood that all spec can produce CR Updates and snapshots - not only extensible specs.  But, it is not obvious to me why we need Extensible RECs to be allowed by the charters, but not CRUs.
> 
CR have always been a work in progress, and there's no expectation today that their scope would be fixed. The process changes just make that WIP easier to deal with, but don't fundamentally change what can be, and what can change, in a CR.

RECs on the other had are expected today to have a fixed scope. Some industries depend on that. As we're introducing a new animal that has the maturity of a REC, but not the fixed-scope, we need to distinguish.

It is possible that all the people who want a Living Standards alternative (including extensible scope) will be satisfied with the CRS/CRU part of the process, and that Extensible RECs end up not being needed. This is probably something we should ask the AC and WGs about.

> 21. 6.4.1 requires an "update request" which links to 6.2.3.  It is not clear that we need this long section (6.2.3).  Why can't we just say that to publish another CRS we need to meet all requirements of CR; noting the couple of exceptions (e.g. the possibility of using the streamline process)?
> 

Previously, the Process defined in generic terms "transition request", as the thing that happens when you go from one maturity to a later maturity. WD->CR, CR->PR, or PR->REC invoked it, with additional requirements.

The Process did not define in generic terms what happens when you want to go from a maturity to the same maturity. CR->CR already existed, but they're not "transitions", since it's the same maturity, so they did not invoke transition requests, and were defined inline within the CR section. We're also making REC->REC updates possible in 6.7.4/5, and many criteria would be duplicated between that and the CR->CR updates. In fact, they were duplicated in an earlier draft. Instead of duplicating that text, we pulled it into a shared section, and invoked it both from CR->CR and REC->REC updates.

> 22. I'm confused about the scope of Section 6.7.4.  It does not seem to be about Extensible Recommendations.  Which I don't really understand.  I would think that for non Extensible RECs we should not be changing how we handle substantive changes.
> 
It is for regular RECs, not the extensible ones, in order to handle bug fixes without having to take the whole spec back to CR for every single fix. Without this, larger specs are impractical to maintain. Fantasai wrote a detailed explanation of this a while back, so I'll just link rather than paraphrase: https://lists.w3.org/Archives/Public/public-w3process/2019Mar/0076.html

> 23. For Extensible RECs, I'm not sure why we need two different sections, 6.7.4 and 6.7.5.  Can't we design a single process to handle both substantive changes as well as new features?  Indeed, the last paragraph of 6.7.5 combines them - why not combine them at the outset and simplify the process?
> 
6.7.4 allows bugs fixes in RECs, it does not allow new features. As discussed above, some industries depend on RECs having a fixed scope.

6.7.5 allows bug fixes AND new features in extensible RECs. The mechanics are essentially the same, with the difference that it only applies to Extensible RECs, and allows new features.

That said, it is true that other than this difference, the 6.7.5 largely repeats 6.7.4. And editorial refactoring to reduce duplication seems doable. Opened https://github.com/w3c/w3process/issues/341 for that.
> 24. 6.7.5.  Second paragraph.  I don't understand why new features are not class 4 changes.
> 
New features, when added normatively, are class 4 changes. "Proposed Additions" are notes that indicate **intention** to add new features, and as such, they're editorial / class 2.

I made some phrasing tweaks to try and make that clearer.

I think the section about errata (which predates everblue/teal) is also a little messy: it largely defines issue tracking, but artificially ties that with REC, and should be cleaned up. I think editorial work on that area would further clarify the point you raised, and would help with the clean up called for in your issue 23 as well. Filed https://github.com/w3c/w3process/issues/340 about this. I plan to try and address it soon.

> 25. 6.7.5.  I am confused about Last Call Review.  Here is how I see it.  When we create the new Spec we need to of course ensure wide review and HRG review.  Today we simply state the need for review (e.g. at CR) - without create a specific "Last Call Review" AC review.  So this Last Call Review does not seem to be the "wide review" equivalent.  Perhaps this is intended to be the Extensible PR AC review.  But we should just call it that - the Extensible PR AC review!  Surely we don't need to send this to the AC twice.  This relates to point 8 above.
> 
To go from proposed corrections / additions to inlined normative changes, two things need to happen:
    * the Last Call Review, which is not just AC but also Legal review (it triggers a Call for Exclusions)
    * the update request, where other criteria, including wide review, implementation experience, etc, are checked (possibly self-checked using the streamlined path).

We took the familiar term “Last Call” from “Last Call Working Draft” in the Patent Policy, as that's what triggers a Call for Exclusions. Not opposed to a different name if that makes things clearer (but note that the LCWD phase was removed from the Process years ago, so there should be no confusion with it here except historically).

> On 10/24/2019 2:45 AM, Florian Rivoal wrote:
>> Hi Process CG,
>> 
>> Fantasai and I made a first pass at at incorporating everteal into the Everblue branch of the Process document.
>> 
>> * Preview of the result:
>>   https://w3c.github.io/w3process/everblue/ <https://w3c.github.io/w3process/everblue/>
>> 
>> * Diff against current master branch:
>>   https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fw3c.github.io%2Fw3process%2F&doc2=https%3A%2F%2Fw3c.github.io%2Fw3process%2Feverblue <https://services.w3.org/htmldiff?doc1=https://w3c.github.io/w3process/&doc2=https://w3c.github.io/w3process/everblue>
>> 
>> Feedback very much welcome, especially in the form of specific issues raised in https://github.com/w3c/w3process/issues <https://github.com/w3c/w3process/issues> with label "Everblue/teal".
>>