Re: Everblue Standards :D

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

Received on Monday, 17 June 2019 20:52:42 UTC