Concerns with moving to living standard model

[pes10k]

Hi all, my understanding is that the WG is considering moving to a "living standard" model for several specs. If this is correct, I'm wondering if the group has discussed some of the downsides / things that'll be lost when moving from the typical rec-track model. Specifically, I'm worried about the following:

1. Living standard specs move things towards a "the standard is whatever ships" and away from a process of deliberation across vendors and other web-stakeholders (especially if the result is lots of small changes, spread over time, instead of less frequent, large updates to specs).
2. How would Horizontal Review work for the living standards? What would trigger HR?

I'd be grateful for any discussion or thoughts the group has. Thanks!

[marcoscaceres]

Living standard specs move things towards a "the standard is whatever ships" and away from a process of deliberation across vendors and other web-stakeholders (especially if the result is lots of small changes, spread over time, instead of less frequent, large updates to specs).

There is nothing inherent in the living standards model that leads to this. This is a culture issue, whereby implementers feel it is more effective to just update implementations than update the spec. However, if the working group is responsive, and implementers feel they can bring changes to the WG, then this is not an issue.

However, if the Process becomes overly bureaucratic, or the WG is non-responsive, or the process drags painfully, then it's easier to sidestep the Process and just coordinate behind the scenes (or reverse engineer things).

How would Horizontal Review work for the living standards? What would trigger HR?

That's in the Process [1]. Adding new significant features (if the spec allows it), and aiming to republish to TR would trigger a HR.

https://www.w3.org/2020/Process-20200915/#revised-rec-substantive

[wseltzer]

Thanks for the comment @pes10k. Speaking as a team contact for the group, but not speaking for the group, I'll try to reflect some of the discussions I've heard. According to the Process, a group operating in a living standard mode should publish Candidate Recommendation Snapshots periodically (6-24 months, depending on pace of changes), with update requests. (Adding to @marcoscaceres reference, these update requests may be at the Candidate Recommendation or Revised Recommendation status.)

1. The WG retains change control over the spec, and should set criteria that things get deliberation and consensus before they go into the WD or Snapshot. Those criteria can be spelled out in the charter.
2. Horizontal and wide review are required before each update request, just as they are now before Candidate Recommendation. Objections must be addressed before publication. If a reviewer says they need to see more of a package of changes before supporting an update, that could be a meaningful review comment.

I think the group's thinking was that security specs want to be pointing developers and implementers to the latest recommended practices, and so the charter should make it easy to keep those specs current.

Any thoughts on safeguards you'd like to see in the charter to ensure living standards work gets appropriate review and consensus?

[mozfreddyb]

In my experience when working on other Living Standards in WHATWG, substantial changes (e.g., non-editorial changes to normative tests) can be gated by certain requirements. E.g., positive feedback from at least two implementations and a change in the relevant web platform tests. That means, even if standards change incrementally due to a lot of minor changes, the tests will provide a coherent and interoperable perspective.

I understand that this may not directly solve @pes10k's issue, so I'd be curious to hear more.

[jgrisham]

In reference to how Living standard seems to be used in practice at the WHATWG, at least, it seems the result is less of a ‘standard’ (in the traditional sense) and more of ‘group consensus-sourced documentation’ of current practices.

There are advantages and disadvantages to both methods, of course.

If the result here is to become the latter, perhaps less euphemistic language should be used in the title.

---

Even a distinction between, say, Best Current Practice or Standard Practice (i.e. present-looking; effectively documentation), Recommendation (i.e. present or future-looking), and Proposed Standard (i.e. future-looking / RFC) might be more useful.

As has elsewhere been mentioned, these documents are commonly referenced by non-technical users as well, both in contracts (e.g. SLAs) and by governments.