Re: Everblue Standards :D

Still coming up to speed on Everblue...

... and it is hard since many of these threads discuss multiple issues 
together and include both crisp use cases interspersed with philosophy.

So for this post, I want to focus on only one aspect of Everblue which I 
believe I understand (and discussed with Florian and Fantasai this evening).

As I understand it, in Everblue, if you take an existing REC and modify 
one part of it (let's say Chapter 1), you can ask that review be 
performed only on Chapter 1.  If there are no new objections on Chapter 
1, then the group can publish a new REC with these changes.  If during 
this time frame someone raised objections on some other chapter (let's 
say 10), the WG does not need to address those new changes, that will 
wait until the next time the whole spec goes through the entire REC process.

This concerns me because it could create a series of RECs which continue 
to ignore the Chapter 10 objections indefinitely.

Let's say that in Year 1 the WG updates Chapter 1; Chapter 2 in Year 2, 
C3, in Y3, ... C6 in Y6.  Then the WG will have published 6 RECs in 6 
years and continue to ignore the Chapter 10 objections.  This seems 
unreasonable.

I was told that we have that problem today - that due to the 
difficulties of maintenance we just wouldn't update anything for 6 
years, and the Chapter 10 objections would still be unaddressed.

But I think the new proposal is worse.  First, it allows a spec to go 
out under the banner of W3C REC even with never addressing the new 
objection.  Our process seems to condone ignoring objections.  Second, 
the new process actually provides no motivation to ever address the 
Chapter 10 objections.  At least today, groups know they are totally 
blocked if they ignore Chapter 10 objections forever.

(Btw, I am also not convinced that for some system level review issues 
(e.g security, privacy) that we can neatly segregate issues between 
Chapter 1 and 10).

I have a counterproposal, which I doubt will satisfy Everblue proponents 
- but here it is.

 1. I see nothing wrong in marking the spec in a way that shows that
    only certain chapters have changed.
 2. I see nothing wrong in sending the spec out for wide review and
    opining with wide reviewers that the WG believes that they only need
    to review those chapters that have changed.
 3. If a horizontal review group sees the logic of why they only need to
    review certain chapters; they provide that limited review; and
    conclude that the spec has no issues (even though they chose not to
    look at "Chapter 10"), then I think W3C should accept that as a
    completed horizontal review.  But, if an objection arises
    nonetheless, the objection still needs to be addressed.

Jeff


On 6/17/2019 4:52 PM, fantasai wrote:
> On 6/17/19 9:48 PM, Michael Champion wrote:
>>
>> 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.
>
> There are many aspects of quality, and the ones for which we have 
> horizontal review groups do not cover all of them.
>
>> 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.
>
> I don't understand what your definition of wide review is. Mine is
>   https://www.w3.org/2019/Process-20190301/#wide-review
> specifically “The objective is to ensure that the entire set of 
> stakeholders of the Web community, including the general public, have 
> had adequate notice of the progress of the Working Group and were able 
> to actually perform reviews of and provide comments on the 
> specification... early enough that comments and suggested changes can 
> still be reasonably incorporated in response to the review.”
>
> Shipping code and testcases does not satisfy these requirements, 
> because by the time a feature ships, feedback on its design can rarely 
> be incorporated.
>
> One of the goals of the W3C Process, and the reason we began to 
> publish public Working Drafts from the very beginning, is to allow the 
> general public Web community the opportunity to comment on things *and 
> to have those comments have an impact on how the Web is developed*. 
> This is what wide review means. It has been extended to include more 
> rigorous review from horizontal topic expert groups, but that is not 
> the entirety of wide review.
>
> You are right that the software industry as a whole has moved away 
> from Waterfall models to Agile methods and “move fast and break 
> things” methodology.
>
> But we, who work on Web standards, are not allowed to break things.
> “Don't break the Web” is a motto that we must abide by.
>
> We cannot iterate on the Web platform in the same way that a software 
> vendor can iterate on its software, pushing a feature in one release, 
> and then substantially changing its design in the next. We can 
> experiment in artificially-restricted environments, as the Chrome team 
> does for limited experiments, but we cannot just ship code for a 
> poorly-designed API to the world and make it better in response to 
> their feedback next year.
>
> This restriction on revising shipped software means any substantial 
> reviews need to happen up front, since they cannot otherwise happen at 
> all. As long as we value the feedback of the wider Web community, 
> "up-front automated tests and a mechanism for continuous improvement" 
> are not enough to serve the same function as a "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.
>
> No argument there.
>
> ~fantasai
>
>