Re: Everblue Standards :D

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://www.w3.org/2019/Process-20190301/#doc-reviews
[2] https://www.w3.org/2018/Talks/TPAC-2018/ceo-update/#gh-commits-groups

~fantasai and Florian

Received on Sunday, 16 June 2019 22:27:18 UTC