Re: EverTeal

> On Nov 5, 2019, at 1:07, Jeff Jaffe <jeff@w3.org> wrote:
> 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

"Augmentable" maybe? I don't really like the rest, but between that one and Extensible, it's a coin toss for me.

The again, Extensible Recommendation can be shortened into XREC, which is nifty.

Alternatively, "ever-eXtending REC"? (This usage of X has precedent: https://en.wikipedia.org/wiki/XMDF_(E-book_format)) <https://en.wikipedia.org/wiki/XMDF_(E-book_format))> ;-)

Anyone else have an opinion?

>>> 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.
> 
So that paragraph *isn't* about advancing from CR to Extensible REC (through PR), it is talking about switching from (non extensible) REC to Extensible REC. And in that case, there is no need for a PR in between: the content of the document isn't changing, only the right to add features to it (or not) is.

However, that would probably be a lot more clear if this conversion process was pulled out of the definition, into its own section. So I just did that.
> 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.
> 
As mentioned in previous mails and the AB call, section 6 badly needed refactoring. With your encouragement, we have done so. Hopefully this clears up the confusion. Please have a look and let us know.

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

Oops, no, missed it.

No, there are no differences between RECs and XRECs except for the fact that XRECs can accept new features in addition to substantive corrections (i.e. XRECs can accept Class 1-4 changes, wherease RECs can only accept Class 1-3, see [1]). The process and requirements are exactly the same.

[1] https://www.w3.org/2019/Process-20190301/#correction-classes <https://www.w3.org/2019/Process-20190301/#correction-classes>

The "streamline" thing is about REC-to-REC and XREC-to-XREC *updates*, and doesn't come into play until you've already transitioned to REC.

>>> 16. 6.2.3.1.  For Streamline, I have several concerns about some details of the HRG approach:
>>> 
> [...]
> 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.
> 
Agreed. Btw, there's some text in the explainer about that: https://www.w3.org/wiki/Process2020#Managing_Horizontal_Reviews

>>> 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.
> Good to hear!  Given the overall time pressure now for Process 2020, any ETA?
> 
ETA = 2 hours ago :) 

As I mentioned in the follow up to your point 8, this is now done on the everblue branch.

What I haven't done (yet?) is port the equivalent refactoring to the main branch so that we can easily diff master-vs-refactor and refactor-vs-everblue if we want to review both separately.

>>> 21. [...]
>>> 
> 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:).
> 
The refactoring already mentioned should have done a lot to clean this up. Can you have a look? One thing we didn't do is merge the subsections about transition requests and about update requests. I suppose it could be done, as they are fairly similar, but they do have some differences, so that would create an additional level of indirection.

Also, having two separate sections helps highlight the distinction between transitions vs updates, which is useful since since they are conceptually (and process wise) different things.

>>> 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 <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.
> 
Just to make it clear: under the new process, a REC and an XREC are almost the exactly the same thing: both can accept substantive corrections, it's just that XRECs can also accept new features, while RECs are limited to corrections on existing features.

See the refactoring. Does that help?
> Fantasai gives a good example, however, of CSS2.  Why can't we fix that by making CSS2 an extensible spec?
> 
We could make CSS2 an extensible REC, and that wouldn't change anything for the CSSWG (as we don't intent to add new features to it anyway). However, other organizations that want to normatively reference CSS2 would lose the promise that no new features will be added.

If XRECs exist, the point of also keeping RECs is to be able, for groups who do not intend to add features, to be able to make that an enforceable promise that can be relied upon by the communities that reference and depend on that specification.

>>> 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.
> 
See above. Fixes to specifications that are otherwise complete are a common need. Addressing that need does not require giving up on the notion of 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 <https://github.com/w3c/w3process/issues/341> for that.

Done as part of the refactoring.
>>> 25.
>>> 
>>> [...]
>>> 
> 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.
> 
It seems there's some confusion here.

This "Last call" process is not about moving from one maturity to a different one.
In order to get to REC (extensible or not), we follow the same process as always.

However, once a specification is in REC, changes to it need to get reviewed--by Members' lawyers, by the AC, by the Director, etc. That's what this “Last Call” process is for.

This process allows a subset of the proposed changes to the spec to be reviewed, and ultimately incorporated, without dragging the entire spec backwards through the Process. This is useful because:
    * The quality of the spec is improving, not degrading, so switching even temporarily to a less mature status is misleading and confusing to the broader community (and editors/WGs don't like doing it)
    * When there's more than a trivially low number of corrections to make, there's never an opportune time to move the whole document. (Not all the corrections progress at the same rate, and in a large enough specification, new errors are discovered continuously.) Thus, it never gets updated. 
    
Anyway, let us know if this is now clearer after the refactoring?

—Florian and Elika

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