Re: Everblue Standards :D

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.

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. 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). Are you suggesting to skip 
the AC review for example? (which I personally have no problem with). 
Take the example of the Web Crypto spec when one wants to add a new 
required crypto algo. How would that work in Everblue? Or changing the 
time origin algorithm of the High Resolution Time spec to also define it 
within the context of Worker (and not just Window)?

So, until Everblue is able to properly include a patent policy, I cannot 
imagine it being a viable option.

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

Having said this, I do believe we're pursuing similar end goals between 
Everblue and Evergreen. The main argument to pursue Evergreen being that 
time is running short to fix everything the REC track in time of Process 
2020 (cf comment [1]). You propose simplifying Director transitions, 
which I concur is a good thing (and doesn't need significant amount of 
process changes imho).

Philippe

[1] https://github.com/w3c/w3process/issues/271#issuecomment-494969583

On 6/11/2019 8:55 PM, fantasai wrote:
> (Because it's 3am.)
> 
> We were given an action to propose an alternative to the “Evergreen 
> Standards” proposal in https://www.w3.org/wiki/Evergreen_Standards which 
> redefines an entirely new standards track, which is problematic because 
> it forks every aspect of the *entire* process (which is error-prone, to 
> understate the problem), fails to maintain the aspects of the W3C 
> Process that functionally ensure consensus and wide review, and 
> overdefines other aspects, leading to inflexibility where the current 
> Process is more adaptable.
> 
> Here's the initial draft: https://www.w3.org/wiki/Maintainable_Standards
> 
> Looking forward to arguing with you all tomorrow.
> 
> ~fantasai
> 
>

Received on Friday, 14 June 2019 18:35:17 UTC