Fluid Standards

[work in progress, not ready for discussion]

The W3C Rec Track Process has a number of inherent problems, especially:

• The need for formal review at each phase by the limited pool of "horizontal" experts and groups creates bottlenecks, which slows the pace of standards development
• The slow pace and complexity of the formal process doesn't align well with the "evergreen web" in which browsers are continually updated to fix bugs and introduce new features.
• Maintenance of Recommendations often doesn't happen, in part because the Process is so unwieldy as to prevent continuous maintenance.

In part because of these problems, the developers who need web technology standards are increasingly voting with their feet and working at WHATWG or another SDO, or in open source projects such as Blink/Chromium, to build consensus on how the web platform should work. We can expect this trend to continue unless W3C's process becomes more "fluid," a neutral term that subsumes WHATWG "living" standard and the proposal for an "Evergreen" standards track.

Rationale for Living/Evergreen/Fluid standards

https://whatwg.org/workstream-policy#living-standard

""Living Standard" means a single, unified technical specification, published by the WHATWG as a Living Standard, as modified from time to time by the Editor of the associated Workstream. Living Standards are intended to include only those features that are likely to be implemented in major browser engines and are suitable for adoption and implementation by other browser engine developers and integrators."

[note the MoU language about

Wide Review of Fluid Standards

Support Tables

Fluid processes do not draw a sharp distinction between features that are in progress and features that are stable enough to be considered “standards.” Thus there are no gates or gatekeepers … What there is is *evidence* as notes in the document… support tables showing implementation status, pointers to issues raised against the current text, status of patent commitments, and the status of requests for review by “horizontal” specialists in architecture, accessibility, internationalization, security, and privacy.

• Who should review what?
  • Standards geeks and bleeding edge implementers look at pull requests
  • Implementers read the Fluid Standard
  • Site builders read the Fluid Standard, paying particular attention to the Support Tables to make a judgment on whether to assume at feature is a standard or not
  • Lawyers, regulators, conservative enterprises use snapshots to see what has patent commitments ...
  • Reviewers look at anything and everything, including implementations, to find and report things that don't work for some audience or scenario.

Proposal

1. Require RF patent commitment on one's own contributions and triggers broad patent commitments on snapshots produced either on a rhythm or at transition phases before Recommendation
2. Create a "Fluid Standard" [a placeholder term] process phase before CR (or parallel to CR) that is available to all WGs without needing special provisions in their charters.
3. Commit to tooling improvements and team procedures to automate / simplify / drive with data the process phase transitions

Principles

• Standards describe that which users can reasonably expect to work in a well-documented way

• How standards come to be is less important than their alignment with reality. Standards may come from paving cowpaths, committee decisions, or authoritative decree; the usefulness of a specification is determined by people accepting and using it. ZIP is a "standard", as is (the subset of PDF used on the web?); Flash was once effectively a standard even though it is Adobe proprietary technology because website developers could assume it was supported in a user's browser, but it is not a web standard anymore because browsers have disabled it or hidden it behind settings. WHATWG's description of an error-correcting HTML parser was a standard immediately, because it described the common behavior of most browsers, even though it wasn't incorporated into the HTML Recommendation in 2014.

• This doesn't mean "anything goes", but "anything that browsers implement in a way website developers can count on" is effectively a web standard.

• The only voters that matter are the builders and consumers of web technology, who vote with their feet. XML was designed to be simple to implement, with "halt and catch fire" as the error handling mechanism. Its proponents as a web technology assumed that users would report "broken" sites to their developers, who would be motivated to quickly fix syntax issues. In reality, users considered browsers that didn't render their desired content to be broken, and switched to a browser that did.

Similarities with the other proposals:

• As with all three approaches, there are IPR policy changes to require a royalty-free patent commitment on one's own contributions and periodic broad patent commitments; the WHATWG IPR Policy is a good model that was developed by attorneys with long experience in W3C.

• As in the WHATWG-W3C MoU, there is a clear distinction between a continuously updated document reflecting technical community thinking and a snapshot that has clear IPR commitments, wide review by experts in various "horizontal" disciplines, and buy-in by a broader community of stakeholders.

• As in the Evergreen Track proposal, there is continuous development of reasonably mature specs, improved tooling to facilitate ongoing review.

• As in the Maintainable Standards proposal, there are various process changes to streamline transitions from one maturity state to another in non-controversial cases.

Differences between this proposal and the others:

• WHATWG's working mode gives much authority to the editor of a living standard and requires support mainly from implementers of the standard, essentially "rough consensus and running code". The Fluid Standards proposal assumes the traditional W3C model of specs getting formal consensus from a working group before advancing, with chairs facilitating consensus within the group and coordinating review by groups of horizontal experts, with guidance but not authority by editors.

-

If the necessary changes to the Patent Policy and Process Document can't be done quickly enough to relieve pressure on W3C for a Living/Evergreen/Fluid process, a WG could organize to approximate this proposal:

1. Create a parallel CG and WG, and charter them to have a working mode where the CG develops a Fluid Specification that the WG periodically snapshots (or cherrypicks) to create Rec Track versions 2. New contributions would to to the CG and thus be covered by the Community Group Contribution License, ensuring the contributor can't subsequently ask for royalties on any patents covered by the contribution. 3. The CG would adopt decision criteria similar to the Evergreen Recommendations proposal 4. The WG would take snapshots periodically (on some rhythm, or when a critical mass of changes has accrued that deserve to become ratified standards.