Re: Everblue Standards :D

On 6/17/19 12:54 PM, Philippe Le Hégaret wrote:
> 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? :)

Sure!

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

No. CR is about transitioning an entire Working Draft to a Recommendation
through the lens of implementation experience. It's not about fixing
specific problems found in a Recommendation.

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

There are three benefits
1. Reducing the scope of the review. This focuses the review effort,
    and scopes the transition to the delta.
2. Keeps the main spec at Recommendation status, clearly preserving its
    patent protections and its status as a Recommendation of the W3C.
    This avoids confusion and the appearance of regression--updates to a
    Recommendation need to be clearly understood as forwards progress.
3. Reduces the amount of work necessary to incorporate a change, which
    currently requires multiple transitions and their associated publications:
    to CR, to PR, and to REC.

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

It's not the responsibility of the commenter to track the status of the 
comments with respect to the status of the spec and ensure that they have been 
addressed. It is the responsibility of the *Working Group* to ensure that they 
have been addressed.

Comments are frequently ignored, sometimes for years. Unless the editor 
replies clearly rejecting the comment, and inviting a response, there is no 
reasonable way for a commenter to know that their concerns are being dismissed.

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

Indeed. Which is why I didn't agree with a proposal for "clear-cut" 
transitions, only for spec updates. :) And also why automating these 
"clear-cut" cases needs us to provide an explicit checklist -- the current 
transition templates are clearly insufficient for a self-check.

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

Which is why we're not proposing to remove the "slower track" of having a 
transition approved by you and Ralph. We think it's a good thing to have that 
option for the more nuanced cases.

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

Agreed.

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

There's two aspects to a workmode: one is what you're allowed to publish, the 
other is how you're allowed to make decisions. You're tying the 1st to the 
2nd, and this neither necessary nor, imho, desirable.

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

AAM requested the use of a lightweight process such as for updating 
registries. Everblue defines a process specifically for registries, in which 
the standard review requirements and IPR commitments don't apply to the 
individual entries, they go through a WG-defined process which can be as 
lightweight or heavyweight as that particular registry use case needs. See
   https://www.w3.org/wiki/Maintainable_Standards#Registries
   https://github.com/w3c/w3process/issues/168

If IPR commitments need to be made to the individual entries, then it can
be handled the same as substantive edits to a REC, which passes them
through an appropriate review/exclusion period. However, AAM does not want 
that, they just want to update the spec asap. See
   https://github.com/w3c/w3process/issues/79#issuecomment-328299677

~fantasai

Received on Monday, 17 June 2019 20:53:28 UTC