Re: EverTeal

On 11/8/2019 1:15 AM, Florian Rivoal wrote:
>
>
>> On Nov 5, 2019, at 1:07, Jeff Jaffe <jeff@w3.org 
>> <mailto: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)) ;-)
>
> Anyone else have an opinion?

There is also "elastic".


>
>>>> 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 acceptClass 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
>
> 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 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?
>>
> 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
>>
>> 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 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 allowsa subsetofthe proposedchanges 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 opportunetime to move the whole document. (Not 
> all the corrections progress at the same rate, andin 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/
>>>>>
>>>>> * 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".
>>>>>
>>>
>