Should whether new features are allowed into RECs be distinguished?

[fantasai]

The current Process allows RECs to accept changes by pulling them back into CR and going back through PR. However it does not allow (and historically has not allowed) adding new features in this way: to create an updated REC with new features compared to the old one, a WG has to restart the Process with a new FPWD.

The current Process 2020 proposal for updating the REC allows new features in addition to other changes, but distinguishes between RECs that can only make corrections and to existing features and those that can accept new features.

There are several questions tied in with this:

1. Should we allow new features into RECs at all?
   • It's clear that some communities want a single continuously-evolving specification, and it's clear that some communities want a specification that has full endorsement from W3C through its Recommendation status. It's not clear whether there's an intersection of these two communities.
   • Yes means that a Living Standard model can be run on a Recommendation level specification, and can operate even under the current Patent Policy.
   • No means that a Living Standard model within W3C can never become a Recommendation; such specifications will either need to live in CR forever or be split into separate REC-level revisions under different shortnames (e.g. HTML5.0, HTML 5.1, HTML 5.2, etc.)
   • It's a fairly minor Process adjustment on top of EverTeal, since it re-uses the mechanism for amending RECs to incorporate substantive corrections.
2. If we allow new features, should we have RECs which are not allowed to accept new features (and are clearly and formally labelled as such)?
   • I think yes, since there are some communities that expect a fixed feature set for the specifications they want to reference. This is could be particularly appropriate for specifications referenced by certain national standards bodies, by legal codes, by firmware or hardware requirements, or other use cases that require fixed scope but might want to still (ideally) allow error corrections.
3. If we distinguish between RECs which allow new features and those that don't, should this be defined in the charter?
   • Some Working Groups may want to agree up front about this, and to communicate such intentions to Horizontal Working Groups and to the broader community; the charter is an appropriate place for this.
   • It's been argued that the AC shouldn't be caring / determining whether the REC can accept new features, it should be entirely up to the WG, and putting in the charter makes it an AC issue.
   • Even if we want to allow defining it in the charter, we can allow the charter to specify (or even define the default behavior if left unspecified to be) leaving the decision up to the Working Group.
4. If we don't allow new features into amended RECs, would we want to adopt an alternative proposal of re-using the amendment process to shortcut the creation of a new REC N+1—by, essentially, publishing the changes into a new REC-level specification with a new shortname, instead of republishing the changes into the same REC-level specification with a new date?
   • This preserves the fixed-feature-scope quality of existing RECs.
   • Is this a sufficiently useful “optimization”, compared to republishing that REC as FPWD and moving from there? Or is it just more confusing?

[jeffjaffe]

1. Definitely. Our community demands a "living" approach to our standards. 2/3. Certainly it should be possible to have WGs that do not support a "living" approach to their standard. Part of the question here is, who should decide.

I'm not sure that we need to decide this before Process 2020 goes to AC review. When we take Process 2020 to AC review, we can share with them two options - that the charter decides (and then it is part of AC review of the Charter) or that any WG can decide whether or not specs should be "living". The rest of the Process 2020 changes shouldn't care about that bit. Whichever option gets majority support from the AC can be what we put into our final Process 2020 edition.

[michaelchampion]

Thanks for opening this issue @fantasai because there has been a bunch of un-archived discussion about this topic.

On question 1, I agree with @jeffjaffe -- We need a "living standards" option, although the option of producing stable standards should be preserved.

On question 2, I'm not at all persuaded that Recommendations presumed to be stable need to be labelled as such. For example, a "stable" Recommendation might need changes to address a security/privacy exploit in implementations, or to be normatively referenced by regulations to prevent a jurisdiction from forking off their own variation of a standard. Or for that matter, Recommendations that are allowed to be "living" may prove to be stable in practice. In short, the process overhead and perceived complexity of the stable/living distinction doesn't seem worth the gains.

On question 3, I disagree with putting the stable/living distinction in charters even if it is exposed as a label. As I argued for question 2, there could be need to update a Recommendation faster than the re-charter process allows. And i can't see a justification for adding this complexity to the process. I wouldn't mind if a charter stated the intention to create only stable standards, or to a WG declining to use the new mechanisms in "Everteal" because they prefer Classic Recommendations, but I don't see any significant value in having the Process require such a decision at charter time.

I don't have a strong opinion on Question 4. Conceptually, I suggest allowing class 4 Amendments under some well-defined circumstances and with appropriate checks/balances. It would be "un-W3C-like" to allow WGs to make such changes without any opportunity for AC review. But I'd hope this review opportunity is a reasonably lightweight process. For example, there could be a mechanism by which the AC is informed about Recommendation updates and given an opportunity to object. But if there is more than (perhaps one?) objection raised, the matter is presented to the AC as a formal ballot much like a PR->Rec transition. OASIS has adopted a similar mechanism to allow broad member oversight without annoying members with frequent ballots on topics few know much about.

[nigelmegitt]

3. If we distinguish between RECs which allow new features and those that don't, should this be defined in the charter?

No, I don't think so. If there's a Process provision for a publication path, that should be available for all WGs to adopt or not depending on the local conditions, which may change during the duration of the Charter. I don't mind a Charter explicitly excluding the option if that's considered useful, but a Charter should not have to actively include it.

[nigelmegitt]

2. If we allow new features, should we have RECs which are not allowed to accept new features (and are clearly and formally labelled as such)?

I'm neutral on this, I think overall it's better from an external-to-W3C point of view if things are simpler and all RECs have the same update rules. So I'd come down on the "no" side unless there's a compelling argument for needing this.

[nigelmegitt]

1. Should we allow new features into RECs at all?

Yes, this is a great idea, as long as each version of the REC is clearly labelled and reference-able, plus the "whatever the latest one is" version should be reference-able. There is a clear use case for external standards that reference W3 RECs to be able to point to a clear feature set at some point in time, for example to derive a finite set of tests, and in my view W3 must support that use case.

We may need some policy for what to do if a new feature in some way conflicts with an existing feature, so that a deprecation scenario exists. Concrete example:

A spec allows a rectangle to be defined relative to another rectangle by specifying top left coordinate and horizontal and vertical size. Later, there's a feature request to define a position anchoring system of alignment instead of the top left coordinate. The WG decides to adopt the new feature, but now there's a potential conflict in processors if both the old and the new way are used. What to do?

Conclusion: WGs need to be able to deprecate old features as well as add new ones, at least occasionally.

[nigelmegitt]

4. If we don't allow new features into amended RECs ...

There's a high chance that I don't understand the question - it seems very complicated.

If I've understood it right, you're asking if it should ever be possible to a) not allow new features in RECs AND b) allow new RECs with new shortnames to be published that are the same as previous RECs but with additional features, but bypassing FPWD and CR.

This appears to be the situation we have today except bypassing the FPWD -> CR stage. I would say yes we should allow it, as long as the new features have demonstrable WR and pass something equivalent to CR exit criteria. This would be a worthwhile optimisation and reduce the REC cycle time.

[dwsinger]

• Should we allow new features into RECs at all?

Yes. That's what Living Standards are.

• If we allow new features, should we have RECs which are not allowed to accept new features (and are clearly and formally labelled as such)?

Yes. We shouldn't cut off the old process.

• If we distinguish between RECs which allow new features and those that don't, should this be defined in the charter?

Yes. The wide-review and IPR tracking of trad. recs and Living Standards are quite different. The lawyers need to know that they've seen a charter that approved a LS, and be able to 'harvest' the Github repo URL in order to watch for snapshots. Similarly, horizontal groups need to know how review is being managed.

• If we don't allow new features into amended RECs, would we want to adopt an alternative proposal of re-using the amendment process to shortcut the creation of a new REC N+1—by, essentially, publishing the changes into a new REC-level specification with a new shortname, instead of republishing the changes into the same REC-level specification with a new date?

Don't think I get the question.

[dwsinger]

The Revising W3C Process CG just discussed Extendable REC vs non-extendable REC.

The full IRC log of that discussion

<fantasai> Topic: Extendable REC vs non-extendable REC
<fantasai> github: https://github.com//issues/345
<fantasai> florian: mchampion gave a useful distinction between producers and consumers of RECs
<fantasai> florian: Labelling RECs that can accept new features those that can't differently was a feature not for producers of RECs, but rather consumers RECs.
<fantasai> florian: Historically RECs have not been able to accept new features
<plh> q+
<fantasai> florian: could accept corrections, but not new features
<fantasai> florian: so current proposal does not change this
<fantasai> florian: so that ppl who want scope of feature-set fixed are not surprised and can continue to have that
<jeff> q+ to provide a pointer to the email discussion
<fantasai> florian: Separately we have ERECs, which are exactly the same as RECs, except that changes can include new features
<fantasai> florian: suggestion was to have this distinction listed in the charter, so that AC can review this distinction
<fantasai> florian: For awhile it wasn't clear if people understood the motivations for this distinction
<fantasai> florian: but now that seems to be the case
<fantasai> florian: Seems nobody except fantasai and I think this is a useful distinction to have
<dsinger> q+
<fantasai> florian: most others feel that it's not useful
<fantasai> s/fee/seem to feel/
<fantasai> mchampion: jeff suggested just putting this info in the Status of the Document, whether certian paths in PRocess were used
<dsinger> ack jeff
<Zakim> jeff, you wanted to comment on the new topic and to provide a pointer to the email discussion
<fantasai> florian: The distinction isn't so much which *was* used, but which *will* be used
<fantasai> florian: but yes, could put it in Status of the Document
<jeff> https://lists.w3.org/Archives/Public/public-w3process/2019Dec/0026.html
<fantasai> jeff: mchampion's suggestion to simplify got +1 from a number of people
<fantasai> jeff: Florian said willing to fold
<fantasai> jeff: Main point here is to simplify document, think that has pretty wide support
<dsinger> q?
<fantasai> fantasai: ...
<jeff> q+ to say that Elika's concerns are the reason to put something in the SotD; not needed in the process
<fantasai> plh: In practice, we do supersede RECs
<fantasai> fantasai: That's different
<fantasai> fantasai: It's a new document that supersedes
<fantasai> fantasai: It doesn't change what has been referenced by other documents
<fantasai> plh: But if you accept fixes, you're making changes anyway
<fantasai> dsinger: Differences in referencing. Referring dated versions vs referencing "top of tree"
<fantasai> florian: ISO is not a problem, they used dated drafts
<fantasai> florian: but Bluetooth or HPTV are better examples, they don't republish our stuff, they reference
<mchampion> q+
<dsinger> s/HPTV/HbbTV/
<fantasai> dsinger: Most groups use dated versions, WHATWG asks to not do that
<dsinger> q?
<plh> q-
<dsinger> ack plh
<fantasai> plh: People can reference whatever they want, let's simplify the Process
<dsinger> ack dsi
<fantasai> dsinger: I'm all in favor of simplifying Process as long as two communities understand it
<fantasai> dsinger: One is lawyers
<fantasai> dsinger: the other is the outside world, and we need to be clear with them how to refer to this thing
<fantasai> dsinger: and refering to top-of-tree
<florian> q+
<dsinger> q?
<mchampion> q-
<fantasai> dsinger: if that's covered by Status of the Document rather than formal Process or whtaever, fine, but I do want it to be clear to those two communities
<dsinger> ack jeff
<Zakim> jeff, you wanted to say that Elika's concerns are the reason to put something in the SotD; not needed in the process
<dsinger> q?
<fantasai> jeff: Want to say briefly that I embrace Elika's concerns, but in the balance, as discussed on ML, is that including it in the status of the document was sufficient clarity to base decisions on
<dsinger> ack flo
<fantasai> jeff: cleaning up the Process was more improtant
<fantasai> florian: With 2 audiences concerned, I'm not concerned about lawyers, because RECs that don't acquire new features still acquire fixes
<fantasai> florian: and from patent PoV any change is relevant
<fantasai> florian: Other audience ...
<fantasai> florian: At this point I think better to simplify Process because there seems to be a lot of confusion
<jeff> +1 to Florian's FAQ idea.
<fantasai> florian: but that when we present to the AC we explain this situation, in case they want something different
<fantasai> fantasai: ...
<fantasai> dsinger: does this mean we can make such changes to any REC?
<fantasai> fantasai: Yes, any REC, including ones already published
<fantasai> dsinger: but can do that already right?
<fantasai> florian: No, you can make fixes, but you cannot add new features without starting a new document
<fantasai> florian: This changes that
<fantasai> dsinger: You could make that change even to an old REC, already published?
<fantasai> florian, fantasai: yes
<fantasai> mchampion: Why do that instead of revving the version number?
<fantasai> florian: If we don't ban the functionality, we shouldn't be surprised that people use it?
<fantasai> dsinger: It's likely lots of small changes that people want to make, but haven't because it was painful in the past, so by no means unlikely
<fantasai> dsinger: I think we need to think through this
<fantasai> fantasai: Should I change the title of the issue to be more general? discussion in issue is broader
<fantasai> jeff: Lots of ML discussion
<fantasai> dsinger: link issue to thread
<fantasai> florian: So what are we trying to do, are we asking AC?
<fantasai> dsinger: I think with next Process call, we decide on whether to act on 345 or not
<fantasai> florian: but are we pinging AC?
<jeff> q+
<fantasai> mchampion: Is there any other questions to put to the AC?
<dsinger> q?
<fantasai> fantasai: I don't think so... this is the only one that changes something about our output, and that we aren't clear that we want (like CR stuff). It changes what a REC means, which might be relevant to people who don't care so much about details of PRocess
<fantasai> dsinger: Changes meaning of existing RECs as well which is significant
<fantasai> jeff: I'd like the chair to find a way for the CG to collaborate on how we present this to the AC
<fantasai> jeff: I think depending on how it is phrased to AC, could change outcome of AC feedback
<fantasai> dsinger: Suggestion was to bring the question up to the AC until we present the Process
<fantasai> dsinger: ...
<jeff> +1 to the three decisions
<jeff> q+
<fantasai> dsinger: Three things we need to decide are * merging clean-up branch * merging Everblue branch * folding EREC and REC

[css-meeting-bot]

The Revising W3C Process CG just discussed REC vs Extensible REC, and agreed to the following:

• RESOLVED: Move next call to 29th to avoid various conflicts

The full IRC log of that discussion

<fantasai> Topic: REC vs Extensible REC
<fantasai> github: https://github.com/w3c/w3process/issues/345
<fantasai> florian: There was a vague but broad consensus that having the distinction was nice for consumers, but slightly more confusing for producers
<fantasai> florian: But some concerns raised
<fantasai> florian: One was whether declarations in a Status section about intentions constrain a WG?
<fantasai> florian: and also what about existing RECs?
<fantasai> florian: I don't think we have a conclusion for this
<fantasai> florian: Various paths possible:
<fantasai> florian: 1. Keep proposal as-is
<fantasai> florian: 2. Erase the distinction entirely
<fantasai> florian: 3. Say that by default REC can't accept new features, unless Status section says they can
<fantasai> florian: 4. Say that by default REC can accept new features, unless Status section says they can't
<fantasai> florian: If other alternatives proposed, don't know of it
<fantasai> florian: Last time ended discussion as an open question
<jeff> q+
<dsinger> q+ to comment on reverting in place
<jeff> q- later
<wseltzer> q+
<jeff> q- later
<florian> q+
<fantasai> fantasai: if we make any distinction, even in Status section, would need to hook into Process to make it binding
<wseltzer> q-
<wseltzer> ack ds
<Zakim> dsinger, you wanted to comment on reverting in place
<fantasai> fantasai: ...
<fantasai> dsinger: Reverting REC to CR can be done, but deeply confusing, should never do that
<dsinger> ack ds
<dsinger> ack jeff
<fantasai> dsinger: Also, should not do these major revisions to something that's currently a REC, not expected
<fantasai> jeff: I think there are two fundamental issues
<fantasai> jeff: One is what do we call different amalgam of RECs?
<wseltzer> [I think any Rec should be able to version itself]
<fantasai> jeff: Other is how do we distinguish amogn them?
<wseltzer> [and the way you distinguish, if you care, is by a datestamp]
<fantasai> jeff: I think we're best off to have a single designation which is Recommendation
<fantasai> jeff: whether came through Process cleanly, or whatever
<fantasai> jeff: all of them should be Recommendation
<fantasai> jeff: I think it's helpful by past history, and SOTD is very convenient, to have all sorts of metadata about history etc.
<fantasai> jeff: we can stuff anything we want into SOTD
<fantasai> jeff: that may not even need to be done in the Process document, can move all to pubrules
<dsinger> ack flo
<wseltzer> +1 to Jeff
<fantasai> florian: I think what fantasai and Jeff said appear to be contradicting, but isn't
<fantasai> florian: I strongly agree with Jeff that documented where a spec came from can be documented in the Status section
<fantasai> florian: also having just one name for all Recommendations is good
<fantasai> florian: But issue here wasn't where something came from, but where it's allowed to go
<fantasai> jeff: Put that in the status
<fantasai> florian: There's nothing in the Process that binds you to respect that
<fantasai> jeff: You can put a throwaway comment into Status that "you must put such and such in SOTD"
<fantasai> jeff: Just don't want to be overly prescriptive about it
<dsinger> q+ to state the need to formally differentiate
<fantasai> florian: If you need a comment in the Status section when you want to allow new features, or when to disallow it?
<fantasai> florian: Opt-in means we don't automatically get new features on all existing RECs
<dsinger> zakim, q?
<Zakim> I see dsinger, fantasai on the speaker queue
<fantasai> florian: What I propose based on what I hear now, is to replace existing distinction of XREC and REC with note in Status
<fantasai> dsinger: I'm not sure I agree
<fantasai> dsinger: I tihnk outside world needs to know, formally this document is immutable, and formally this document is immutable
<florian> q+
<wseltzer> q+
<fantasai> dsinger: Other standards orgs need to know, if the document is stable or if it changeable
<wseltzer> [they already have that immutability through the dated version]
<fantasai> dsinger: Perception of outside world
<wseltzer> q-
<fantasai> florian: Note that we don't have immutable RECs, can always take changes that aren't new features
<fantasai> dsinger: ...
<fantasai> florian: Are you saying that the distinction of REC and XREC is something we need to maintain?
<plh> q+
<fantasai> dsinger: "Is this going to change out under my feet, or is this something that is essentiall stable?" is an important distinction
<fantasai> wseltzer: We have always and always will have dated versions, they don't change
<fantasai> wseltzer: but document at tip-of-tree would reflect the group's latest thinking
<fantasai> plh: I agree with that
<fantasai> dsinger: We make it very clear that if you want an immutable document you use dated version URL
<fantasai> dsinger: I'd like to continue to study this
<fantasai> florian: I will still make a PR, so we can compare the two versions
<fantasai> dsinger: Out of time, anything else?
<fantasai> florian: you and I need to discuss registries
<fantasai> [discussion of scheduling conflicts]
<fantasai> [various people have conflicts]
<fantasai> [discussing moving to 29th]
<fantasai> i/dsinger/Topic: Scheduling
<fantasai> RESOLVED: Move next call to 29th to avoid various conflicts
<fantasai> dsinger: plan is to resolve registries
<fantasai> Meeting closed.
<wseltzer> rrsagent, draft minutes
<RRSAgent> I have made the request to generate https://www.w3.org/2020/01/08-w3process-minutes.html wseltzer
<wseltzer> rrsagent, make logs public
<RRSAgent> I have made the request, wseltzer
<wseltzer> regrets+ cwilso
<wseltzer> rrsagent, make logs public
<RRSAgent> I have made the request, wseltzer
<wseltzer> rrsagent, draft minutes
<RRSAgent> I have made the request to generate https://www.w3.org/2020/01/08-w3process-minutes.html wseltzer
<tantek> RRSAgent, pointer?
<RRSAgent> See https://www.w3.org/2020/01/08-w3process-irc#T17-11-38

[frivoal]

Created a Pull Request (https://github.com/w3c/w3process/pull/365) based on the discussions during the last teleconf, to eliminate the separate X-REC status, while maintaining the fact that old RECs won't start gaining new features, and still allowing people to opt into creating RECs that can.