Re: Everblue Standards :D


This thread touches on some very key points

> Wide review and consensus are the two cornerstones of the W3C Process: its
> entire purpose is to provide the scaffolding for these two principles to be
> consistently respected, by new and inexperienced groups as well as old and
> practiced ones. It should not be so onerous as to impede work, but it should
> be rigorous enough to guard against inexperience, brashness, and simple
> carelessness.

I don't disagree that the process DOCUMENT goes into great detail about review and wide review, but saying that wide review per se is one of the cornerstone principles of W3C is an overstatement.  Making the *web itself* usable by people with different languages, cultures, and varying sensitivity to privacy and security is a key principle, but wide review is a means to that end,  not an end itself. The Process should focus on ensuring that implementations of the specs are accessible, internationalizeable, secure, privacy-aware, etc. but allow different WGs  and "tracks" to find different ways of assuring this.

The W3C Process as practices today evolved at a time when the https://en.wikipedia.org/wiki/Waterfall_model was dogma in the software industry, assuming that  "progress flows in largely one direction ("downwards" like a waterfall) through the phases of conception, initiation, analysis, design, construction, testing, deployment and maintenance."  Wide Review fits neatly into the waterfall framework as gates controlling the downward flow.  Web technologies, however, haven't evolved this way, leading to a mismatch between the formal process and reality, While the Process has evolved to have fewer formal phases and more acknowledgement that the flow often goes "upwards", it still has problems, especially:
* The need for formal review at each phase by the limited pool of "horizontal" experts and groups creates bottlenecks, which slows the pace of standards development
* The slow pace and complexity of the formal process doesn't align well with the [https://www.w3.org/2001/tag/doc/evergreen-web/ "evergreen web"] in which browsers are continually updated to fix bugs and introduce new features.
* Maintenance of Recommendations often doesn't happen,  in part because the Process is, as the Maintainable Standards proposal put it, "so unwieldy as to prevent continuous maintenance."

This combination of "bureaucratic" overhead, slowness, and lack of maintenance has driven key contributors several web platform standards (HTML, URL, DOM) to work at WHATWG.  We can expect this trend to continue unless W3C's process becomes more "fluid",  which I'm using as a neutral term that covers WHATWG "living" standards, the proposal for an "Evergreen" standards track, and the "Everblue" / "Maintainable Standards" proposal.

So in my mind, traditional wide review is just one mechanism that WGs -- especially those whose customers can live with a waterfall-ish working mode and pace -- can use.   If WGs that have customers that require a faster-moving approach to inform their "evergreen" products AND can demonstrate that they have a combination of up-front automated tests and a mechanism for continuous improvement when problems are found, that can serve the same function as traditional wide review.

 Likewise WGs can use different divisions of labor across the chairs, editors, and pariticipants as far as determining how much up-front consensus is needed before a spec is considered a standard (fluid or otherwise).  Some will be more comfortable with the traditional "WG comes to consensus as determined by the chair, and the editor implements the consensus" and others will be more comfortable with the "editors writes down what think has rough consensus and running code, participants either object and propose concrete alternatives or as assumed to concur, the chair facilitates productive and professional collaboration, and nothing is considered stable until there are tests that pass."  Or some combination of the traditional and more WHATWG-ish style that works for some community.

All this needs to be made more explicit and rigorous in the Process Document (at least the description of how Continuous Development https://www.w3.org/wiki/Evergreen_Standards#Continuous_Development would work), but let's not insist that Fluid approaches follow the same mechanisms for achieving the *goals* of wide review that the traditional process does.


-----Original Message-----
From: fantasai <fantasai.lists@inkedblade.net>
Date: Sunday, June 16, 2019 at 3:27 PM
To: Philippe Le Hegaret <plh@w3.org>, W3C Process Community Group <public-w3process@w3.org>
Subject: Re: Everblue Standards :D
Resent-From: <public-w3process@w3.org>
Resent-Date: Sunday, June 16, 2019 at 3:27 PM

    On 6/14/19 8:35 PM, Philippe Le Hégaret wrote:
    > Here is a summary of the issues that I see in Everblue:
    > 
    > 1. there is no way to create a snapshot of a draft *before* it reaches 
    > Recommendation in order to secure licensing commitments over the entire 
    > document. This is a significant flaw of the W3C Patent Policy and was fixed in 
    > the Evergreen proposal with the ERS proposal.  While getting contributions 
    > commitment is a good step forward, Everblue is incomplete.
    
    We have no problem including such a system; as I told cwilso it sounds great. 
    Just weren't sure how doable it was for Process 2020, since the current Patent 
    Policy does not have such a facility and it seemed harder to get agreement on. 
    But if there's agreement that this is something to work on (and there does 
    seem to be), then we would be glad to include that in the proposal.
    
    > 2. Process 2005 was broken with regards to substantive changes in order to fix 
    > Recommendation:
    >   a. It required a Working Group to make those changes (think Web Crypto, XML, 
    > WSDL, XPath, etc.)
    >   b. It didn't allow for those substantive changes of third class to get 
    > proper call for exclusions.
    > 
    > Everblue proposes to reestablish Process 2005, without addressing the problem 
    > of the Patent Policy. That simply doesn't work. You must not be allowed to 
    > publish an Edited Recommendation without due patent policy process. Process 
    > 2019 forces you to go back to CR, thus triggering the 60 days period.
    
    Process 2005 required changes to go through a review period before being 
    incorporated into the Recommendation. The Process could have been updated to 
    extend that review period to 60 days and make it an exclusion period, but 
    instead RECs were made unmaintainable.
    
    The proposal here is to recreate a process for reviewing and approving direct 
    changes to a REC. Whatever reviews need to happen can happen during the review 
    period of those changes--if it needs to be 60 days long so be it--but there's 
    only one formal review phase and the spec itself remains REC during this review.
    
    > All of the other requirements for CRs would have to be justified in *any* case (wide 
    > review, implementation, etc.). So, I don't understand what you gain by 
    > republishing directly (besides avoiding republications of a CR and a PR 
    > document). 
    
    You don't have to drag the entire spec back down to CR with you.
    It's only the delta that is being reviewed. This is an important distinction.
    
    > You keep shooting down the Evergreen proposal because of its continuous wide 
    > review aspect. The current Process and Everblue identify a specific point in 
    > time in the Process where a check is made. The current trends are to do 
    > reviews often and early, rather than once and last minute. Evergreen, 
    > Everblue, or others, we'll need to promote a system that facilitate those 
    > often and early reviews imo.
    
    This is a critical misunderstanding. The current REC track process **DOES NOT 
    SAY** that wide review should happen at CR, and in fact explicitly encourages 
    it to happen earlier. (The tendencies of groups to review late in the past is 
    one of the key reasons the LCWD stage was dropped: to encourage reviews to 
    happen earlier by removing a clear opportunity to be late.) We are not 
    suggesting that this be changed. We wholeheartedly support continuous 
    horizontal and wide review, and believe that it should be a process that 
    starts early on, as described in the 2019 Process. [1]
    
    What Evergreen lacks, and the REC track does have, is check points to verify 
    that this review has happened.
    
    Under the REC track, you should have early and continuous wide review. 
    However, if the Editor+WG fail to solicit review, or fail to respond to the 
    comments sent their way, this should be caught when trying to enter CR.
    
    Under the Evergreen proposal, you should also have early and continuous wide 
    review. However, if the Editor+WG fail to solicit review, or fail to respond 
    to the comments sent their way, there is no point when this failure will be 
    caught.
    
    Wide review and consensus are the two cornerstones of the W3C Process: its 
    entire purpose is to provide the scaffolding for these two principles to be 
    consistently respected, by new and inexperienced groups as well as old and 
    practiced ones. It should not be so onerous as to impede work, but it should 
    be rigorous enough to guard against inexperience, brashness, and simple 
    carelessness.
    
    > You're also uncomfortable with a model with a strong editor (even when
    > there is oversight by a Chair), yet several of our  Groups already working
    > like that nowadays and are happy to delegate a lot of their
    > decisions/implementation details to the editor(s). The Web Performance 
    > Working Group is one of those examples.
    
    We're not uncomfortable with a strong-editor model existing. We're 
    uncomfortable with a Process that restricts work modes more than they are 
    restricted in the current Process. Some WGs work as you describe, sure. They 
    do so *under the current Process*. Other WGs don't, they use other work 
    modes--and are not ineffective for doing so [2]. And that's also fine. The 
    Process creates a loose enough framework that variation and experimentation in 
    work modes is possible. This is a good thing.
    
    Having a maintainable specification should not be a privilege afforded to 
    groups with certain work modes and not others, not without some actual 
    justification for why this distinction is made. You have not provided any 
    compelling justification for why the Evergreen Process should have different 
    work mode requirements than the current REC Process. We believe the current 
    guidelines and constraints on achieving consensus are sufficient, and that 
    creating an alternative definition in the Process is unnecessary and harmful.
    
    [1] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2F2019%2FProcess-20190301%2F%23doc-reviews&amp;data=02%7C01%7Cmichael.champion%40microsoft.com%7C7e2f620642ec4af6792108d6f2a9d629%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636963208588193265&amp;sdata=Sy8%2BboIoUUgHUCWUnc9mtyDTkkbtn3k86p4HIOTrZyw%3D&amp;reserved=0

    [2] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2F2018%2FTalks%2FTPAC-2018%2Fceo-update%2F%23gh-commits-groups&amp;data=02%7C01%7Cmichael.champion%40microsoft.com%7C7e2f620642ec4af6792108d6f2a9d629%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636963208588193265&amp;sdata=M5%2FHWg4F%2FikyDW7D%2B7tuvwUzJ31cXVCv89a6on8rmAM%3D&amp;reserved=0

    
    ~fantasai and Florian

Received on Monday, 17 June 2019 19:48:57 UTC