Re: Everblue Standards :D

On 6/16/2019 6:26 PM, fantasai wrote:
> 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

So, maybe we should introduce it as an experiment? :)

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

But, isn't it what CR is about in Process 2019? I still don't understand 
how your review period will be different from a CR review period. Is it 
that you simply don't want to call it a CR? Or is it that you're finding 
publishing a CR too cumbersome and we should focus instead of fixing that?

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

Ah, so maybe you're trying to reduce the scope of the review to only the 
bits you're trying to change? Since experience tells us that, even if 
one says that comments are only accepted for a small set of paragraph, 
people do tend to comment on everything anyway, especially when they 
disagree. Neither 6.7.2 nor 6.4 mention anything about that.

> What Evergreen lacks, and the REC track does have, is check points to 
> verify that this review has happened.

Agreed, but that was meant to be a design feature. Comments may be 
addressed at
anytime and maybe be pushed for later versions. If someone disagrees 
with a comment being pushed, they could raise their concern to the Group 
chair.

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

But wouldn't those cases fall under your "clear-cut" proposal [1]? For 
example, we recently had a Working Group who believed that asking for 
TAG review was enough to cover for their privacy review. Unsurprisingly, 
the privacy folks disagree.

Simply checking transition requests is pretty much what the Director is 
doing every week, checking transition requests to make sure it's fine, 
without needing to get folks on a call most of the time. It does take 
time to understand a transition request, when jumping from documents 
like Web of Things to WebAssembly or CSS <insert-your-favorite-name-here 
:)> . Frankly, I won't even try to pretend Ralph and I understand all of 
the details of every specification going through our desks. We do catch 
things and/or ask questions but I'm sure we're missing things as well.

In addition, some of those transition requests heavily rely on judgment 
calls, like the normative references guidelines or the adequacy or 
completion of CR exit criteria.

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

And yet, some would say it should not get in the way of acknowledging 
reality of implementations nor getting patent commitments early.

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

I'll need to understand how your clear-cut proposal differs then. If the 
editor/WG assert everything is fine, how and who is supposed to check 
that if nobody objected?

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

I don't think that the Evergreen proposal is proposing to change the 
Recommendation track yet, so we're not proposing to change how a WG 
works today if they don't want to. We're proposing to experiment with a 
different workmode, one which isn't allowed by the Process today.

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

[[
W3C Recommendations are well-suited for traditional specifications whose 
implementation is largely independent of platform-specific, 
non-web-related technologies. W3C Notes are well-suited for 
best-practices documents related to Recommendations. But I believe 
neither are fully compatible with specifications with normative 
requirements that depend upon technologies which are platform-specific 
and/or non-web related.
[...]
Unfortunately (for W3C Process), what is specified in AAMs is outside of 
W3C governance. Accessibility APIs are tied to the needs (and release 
cycles) of the platforms on which they are used. If a given platform 
adds or removes accessibility API, it can render the AAM technically 
incorrect even though nothing has changed in the W3C-governed technologies.
]]
https://github.com/w3c/w3process/issues/79

I didn't write this down. A Working Chair did. How does Everblue 
addresses her use case?

Philippe

Received on Monday, 17 June 2019 10:54:41 UTC