Re: EverTeal

Thanks for the responses.  Selected additional comments.

On 11/4/2019 1:08 AM, Florian Rivoal wrote:
>
>
>> On Nov 4, 2019, at 9:09, Jeff Jaffe <jeff@w3.org 
>> <mailto:jeff@w3.org>> wrote:
>>
>>> 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.
Animated, dynamic, expanding, stretchable, augmentable
>>
>>> 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?

Looks OK for now.  I may need to relook at it once some of the other 
pieces (e.g. PP) fall into place.


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

Yes, I was making comments about this one.

In the third paragraph of the definition of Extensible REC, it should 
say that before becoming an Extensible REC it first becomes a Proposed 
Extensible REC (rather than saying it gets an AC review.  That's point 
#13 below.

And yes, I think you need it in 6.7.5 as well.  It is true that no other 
section mentions the previous step.  But the entire "Last Call" of 6.7.5 
is a mention of the previous step.  See comment #25.

>
> * 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?
>
>
>> 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.
>>
Did you comment on this one?
>
>> 13. Extensible REC.  See point #8 above.
>>
> See answer to 8.

See comment to answer on point 8.


>> 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 absenceof 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 strikethe 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 wbsas we work that out.

Maybe we should be proactive with HRG communities starting now (or after 
the AB F2F) so that when the document goes to AC Review, they are not 
seeing this for the first time.  It would be good to build a better set 
of joint expectations with them in the next month or two.


>> 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 fantasaifiled a separate issue about 
> thisathttps://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.

Good to hear!  Given the overall time pressure now for Process 2020, any 
ETA?


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

As with point #18, perhaps there is an opportunity for some broader cleanup.

Instead of living with a structure that assumes that you go from one 
maturity to a later maturity; and then we have a complicated graft onto 
that of a case where you remain in the same maturity - perhaps a broader 
cleanup can talk about going from a maturity to either a republication 
at the same maturity OR a later maturity. I suspect it will end up 
cleaner.  But then, of course, I would ask for the ETA:).


> 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 wereduplicatedin an earlier draft. Instead of duplicating 
> that text, we pulled it into a sharedsection, 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

I'm not convinced that this is the right answer.  This is a great deal 
of spectext and I'm not convinced it will ever be used.

Fantasai gives a good example, however, of CSS2.  Why can't we fix that 
by making CSS2 an extensible spec?

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

As above, I'd like to understand better the use cases.  You need a spec 
that (a) wants fixed scope, (b) feels they can't get it from Extensible, 
(c) still has substantive changes, and (d) does not feel that just 
getting to .next is an adequate solution.  I'm not saying they don't 
exist, but I'm not convinced they are pervasive.


>
> 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.
>>
>> 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 updaterequest, 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 aCall 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).

Actually, Last Call was removed because people didn't like it- so I'm 
not sure that reusing the old name is helpful.

But the more fundamental issue that I have, which I tried to explain 
above, is that the sequence seems confused.  Here is how I see it.

To go from proposed corrections / additions to inlined normative 
changes, it seems to me that two things need to happen:

  * The WG needs to convince itself using normal WG processes that it is
    ready to move forward towards REC.  That involves lots of stuff;
    wide review, implementation experience, addressing all issues, etc. 
    That is a standard part of WG processing and does not involve the AC
    or a formal "Last Call" phase.  The Process Document should merely
    say that these are the things that the WG must do.  When the WG has
    done these things and the Director is convinced, (or these are done
    in a streamlined fashion) then the document becomes a Proposed
    Extensible REC.
  * Once it is a Proposed Extensible REC, it automatically gets AC review.

It seems to me that this achieves the same thing as you are achieving 
without creating as much process machinery.

>
>> 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/
>>>
>>> * 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
>>>
>>> Feedback very much welcome, especially in the form of specific issues raised inhttps://github.com/w3c/w3process/issues  with label "Everblue/teal".
>>>
>