Process supporting "Living Standards"?

[joanmarie]

W3C Recommendations are well-suited for traditional specifications whose implementation is largely independent of platform-specific, non-web-related technologies. W3C Notes are well-suited for best-practices documents related to Recommendations. But I believe neither are fully compatible with specifications with normative requirements that depend upon technologies which are platform-specific and/or non-web related.

My particular use case is accessibility "mapping" specifications, such as:

• HTML Accessibility API Mappings 1.0
• Core Accessibility API Mappings 1.1
• Digital Publishing Accessibility API Mappings
• SVG Accessibility API Mappings
• Graphics Accessibility API Mappings

Each of the above W3C specifications "maps" W3C-specified elements and attributes to platform accessibility APIs such as NSAccessibility (macOS and iOS); ATK (GNU/Linux); IAccessible2 and UIAutomation (Windows). These "AAM" specifications are not best practice: There is a "right way" for user agents to expose the aforementioned elements and attributes to assistive technologies as part of their implementations. The failure of a user agent implementation to do what is specified in an AAM negatively impacts the accessibility of the associated content.

Unfortunately (for W3C Process), what is specified in AAMs is outside of W3C governance. Accessibility APIs are tied to the needs (and release cycles) of the platforms on which they are used. If a given platform adds or removes accessibility API, it can render the AAM technically incorrect even though nothing has changed in the W3C-governed technologies. When this occurs, W3C Process doesn't seem to give us many options:

• Adding errata: Not a great fit IMHO because it requires implementors to look in multiple places in order to know the correct implementation. Besides, the AAM was presumably correct at the time it went to Rec.
• Following the Rec-track process, starting at CR: Potentially a non-trivial amount of work. And it is work which must be repeated every time one of the four mapped platforms makes a change which user agent implementations must support.
• Making the change in the user agents without updating the AAM: Can lead to the view that the AAM is not a reliable specification, and also to user agents getting out of sync with one another which impacts the web as a consistent platform.

Furthermore, it is worth noting that the above issue and available courses of action provided by Process are not limited to a single AAM: If a platform changes its accessibility API, odds are that at least the HTML AAM and the Core AAM will each have at least one mapping which has been rendered outdated/inaccurate.

Having said all that, I do believe that all stakeholders benefit from there being normative specifications which clearly state the accessibility mappings for W3C specifications. Thus I don't think we should abandon the AAM approach. Instead, I think we need some new middle ground between Recommendations and Notes which allows for the AAMs to remain up-to-date, reliable, normative specifications that live under the same umbrella (W3C) as the specifications whose features they "map" -- and to do so without the need for frequent repeated trips through the Rec-track.

[michaelchampion]

Following the Rec-track process, starting at CR: Potentially a non-trivial amount of work. And it is work which must be repeated every time one of the four mapped platforms makes a change which user agent implementations must support.

What makes the Rec track so burdensome for this use case? Some WGs (e.g. Web Platform) have established 12-month rhythm for updating key Recommendations to adapt to changing external reality. The new Web Assembly WG aspires to ship updates on a 6-month rhythm.

I agree that the Rec-track process is potentially a lot of work, and certainly is if there are patent disclosures to work around, political controversies to try to resolve, or major changes that have to be implemented and tested. But those don't seem likely to apply to AAM -- it's authoritative guidance for how to map the standard APIs to real-world ones, so patent concerns are unlikely, it seems politically uncontroversial, and the changes are driven by already-implemented reality.

I'm not opposed to a middle-track that is faster and easier than the Rec Track but more authoritative than CG Reports or WG Notes, but I'd like to see the Rec Track continue to evolve to be more lightweight and agile. We've already combined Last Call and Candidate Recommendation. I could imagine allowing specs that are expected to change regularly to go through CR and PR simultaneously with the understanding that review feedback will be applied to the next iteration. (I'm not sure that's forbidden in the current process, but it's not explicitly allowed).

Anyway, thanks for bringing this use case to our attention, we need to make sure some track of the W3C Process works for it!

[dwsinger]

On Sep 8, 2017, at 11:54 , Michael Champion notifications@github.com wrote:

Following the Rec-track process, starting at CR: Potentially a non-trivial amount of work. And it is work which must be repeated every time one of the four mapped platforms makes a change which user agent implementations must support.

What makes the Rec track so burdensome for this use case? Some WGs (e.g. Web Platform) have established 12-month rhythm for updating key Recommendations to adapt to changing external reality. The new Web Assembly WG aspires to ship updates on a 6-month rhythm.

I think you’re imagining a case where the snapshots are useful, which is true for some specs. For some kinds of things, they’d be busy work to get the IPR commitments, and yet we’d want the outside world to treat them as having less status in every other respect. Want the latest database? Use the latest WG-approved document, not the older snapshot, and so on.

I agree that the Rec-track process is potentially a lot of work, and certainly is if there are patent disclosures to work around, political controversies to try to resolve, or major changes that have to be implemented and tested. But those don't seem likely to apply to AAM -- it's authoritative guidance for how to map the standard APIs to real-world ones, so patent concerns are unlikely, it seems politically uncontroversial, and the changes are driven by already-implemented reality.

Controversy doesn’t go away with a change in process….dream on…

David Singer Manager, Software Standards, Apple Inc.

[michaelchampion]

@dwsinger wrote

For some kinds of things, they’d be busy work to get the IPR commitments, and yet we’d want the outside world to treat them as having less status in every other respect. Want the latest database? Use the latest WG-approved document, not the older snapshot, and so on.

I see, maybe the AAM use case is for something more like a registry than a standard. It would be the product of a group of experts and a community that generally treats the document as authoritative, but it would not need / be burdened by patent commitments, review by the entire W3C, proof of implementability, etc.

I can envision adding to the process something like a "W3C Database" (for lack of a better term off the top of my head) that has just enough process to ensure that a WG has reviewed and put its credibility behind updates, but doesn't require all the busy work to get wide review, patent exclusion opportunities, etc.

[joanmarie]

What makes the Rec track so burdensome for this use case?

TL;DR: What you've subsequently stated, namely: "patent commitments, review by the entire W3C, proof of implementability, etc."

DETAILED EXAMPLE: To add some context about the sorts of changes we're talking about, on my platform (GNU/Linux, ATK), the following mappings are about to become obsolete/incorrect:

• aria-valuemax
• aria-valuemin
• aria-valuenow
• aria-valuetext

The reason why is the deprecation of the specified AtkValue methods. While we know the new API, user agents MUST NOT implement that new API yet because if they do, it will break accessibility of the aforementioned ARIA features. The reason why things will break is because we also need to make some changes in the client-side AT-SPI2, changes which we cannot currently make due to code and API freezes in GNOME. But once user agents are able to implement it without breaking accessibility, user agents really, really SHOULD (and I would say MUST) do that implementation because the new API offers platform assistive technologies a more efficient way to accomplish presentation of these ARIA features.

The changes will be:

• atk_value_get_maximum_value() -> atk_value_get_range()
• atk_value_get_minimum_value() -> atk_value_get_range()
• atk_value_get_current_value() -> atk_value_get_value_and_text()
• object-attribute: valuetext:<value> -> atk_value_get_value_and_text()

Why does the above need a 60-days exclusion opportunity, or Advisory Committee Review? One month for comments even seems unnecessary: Authors have nothing to do differently, and only one platform (GNU/Linux) is impacted. Getting the implementations done will be quick and easy and simple to prove. In fact I can have the implementations for all (currently two) accessible user agents on my platform in place prior to asking for the transition to CR, in which case what exactly is the benefit of getting Working Group consensus to transition to CR (it would almost certainly be a rubber stamp), having the Team Contact do multiple transition requests, getting the Director to approve each transition, etc., etc.?

As a related aside, there is also some AtkValue API which will improve the accessibility of the HTML meter element. So HTML-AAM will need to be changed. Just not quite yet.

Getting back to the original question, it's not so much that the Process is burdensome for the average spec, or even for going from something like Core AAM 1.0 to Core AAM 1.1. But the amount of people and steps involved, along with the ~2 months needed to go from CR to TR, strike me as an unnecessary price to pay for maintaining the technical accuracy of these specifications.

[cookiecrook]

To be clear, I do not believe anyone is suggesting ARIA should move to a living standard. The general ARIA spec is a good candidate for remaining on Rec Track b/c it's a cross-platform Web API with requirements for two implementations per feature. However the ARIA-related Accessibility API Mapping documents (AAMs) are effectively platform glue: how does feature X of ARIA map to each non-Web platform API.

I support (and have previously suggested) that all the AAMs be moved to a "living" process. If our options remain limited to Note or Rec, I'd vote for Note, but as Joanie eloquently pointed out, these are normative documents, albeit ones that need more frequent updates than the standard W3C specification.

Because the AAMs simultaneously reconcile a single Web API with four or more platform APIs, there will always be something out-of-date, no matter how often the group publishes. By design, the AAMs document implementation details of each platform, which makes them unlike any any other W3C Rec, and worthy of a process reconsideration. Furthermore, each edit usually only affects a single platform, and the source of the edits is usually the API owner, so these changes have almost no risk of "breaking" another implementation. A "living" document process would allow the editors to make necessary changes without unnecessary bureaucratic overhead.

[jeffjaffe]

I believe that there are a collection of items that do require standardization, need a consensus process, but also need to evolve in a very flexible and lightweight fashion (aka Living Standard).

I think that W3C would benefit if we had a formal lightweight process that had several pieces to it:

The nth version of the standard is stable.
It is easy to add a few branches to this version and call it the n+1st version.
Initially there are no patent commitments to the deltas in version n+1.
At some point in time (maybe after n+2, or n+3, etc.) there is enough change that we formally take it through a REC process to finalize patent commitments.
Even while doing (4) we are already branching out to the next version.

My favorite application for such a living standards process has been to standardize Vocabularies. It would fit this model very nicely. Another application would be for Maintenance. My guess is that it would fit AAM as well.

I have not formally proposed such a process because I think creating a new process path within W3C is expensive and potentially confusing. I'm not sure if it would pay to introduce it just for AAM. So as Mike said, we kinda can get it done already.

My favorite application was going to be schema.org. Schema.org (imho) deserves more attention than just a mere CG. It is important enough to have greater status as a standard, but it is a poor fit for the REC process. Unfortunately, I was never able to convince the schema.org organizers of this plan. So I never proposed this mechanism.

[michael-n-cooper]

In line with the above, I had put thought into characteristics of content that seem to have more pains than benefits from the Rec track process, yet is not necessarily something we want to demote to the Note track:

• So simple that it's not likely to have valid copyright or patent claims;
• Not of great interest to the majority of the AC, even while it's at least supported in principle;
• Requires strong technical knowledge of a very particular area in order to have an opinion about the technical decisions made;
• Should have more consensus behind features than just that of an editor or two;
• Needs to be documented and used but perhaps not having a major implementation base compared to other W3C implementation targets.

We've seen accessibility API mappings and schema vocabularies as examples of content potentially with these characteristics; there are probably other examples we could find.

The goal of describing these characteristics is to help focus on what problem we seek to solve, and identify a solution that actually addresses that problem. I don't think "living standards" as I understand the concept is the right solution but recognize there is a problem and intend to continue working on it with my WGs and the Process. I hope to be able to put more thoughts on the subject here soon.

[jeffjaffe]

There are different definitions about what a Living Standard is, and different use cases. For Process 2019, we might take a broad look at these: API mapping, schema vocabularies, regular specifications, maintenance all present different use cases.

[michaelchampion]

Strawman proposal (more a thought experiment than a serious proposal at this stage): Create a Living Standards Track in the W3C process similar to the new WHATWG IPR process, but retaining the traditional W3C concern for broad, formal consensus with the Director as the ultimate arbiter. See https://whatwg.org/ipr-policy and https://blog.whatwg.org/working-mode-changes for a summary of the new WHATWG process, which is itself a mashup of the W3C Community Group and Standards Track processes.

Briefly:

• Those joining a Living Standards Track Working Group (LSTWG) would have to agree to a CLA similar to that for Community Groups offering royalty-free patent commitments on their own contributions to specs.
• The group would operate day to day like any WG, with a charter, chairs, editors, making decisions by consensus, to draft and update specs.
• The LSTWG would publish Living Standards, roughly equivalent to regular Working Drafts, when there is consensus to do so. The LSTWG would continue to update the Living Standard as long as its charter lasts and there is energy to keep working on the spec, on whatever rhythm it chooses.
• Periodically (yearly?) the LSTWG would prepare a Proposed Snapshot Recommendation. This would trigger a patent exclusion period; LSTWG members who do not exclude a specific patent during that period incur a binding patent commitment just like when a regular WG publishes a Recommendation.
• The Advisory Committee is informed of the Proposed Snapshot Recommendation and members have an opportunity to formally object to it being published as Snapshot Recommendation. I envision this as a "silence means assent" ballot rather than a regular AC ballot, but it could be run just like a PR ballot if others prefer.
• If there are no objections, or the Director over-rides objections, the Proposed Snapshot Recommendation becomes a Snapshot Recommendation. This term would clarify that the WG does not consider it a completed product, but just a snapshot to describe those features at a particular point in time that have broad, binding patent commitments.
• Other specs would be strongly encouraged to normatively reference the Living Standard, not the Snapshot Recommendation since that is where the most recent updates and bug fixes would reside.

This addresses a few challenges with regular WGs and Recommendations:

• Patent commitments from contributors are triggered as soon as the contribution is made, not years later when the spec gets to Recommendation. This is a feature of the Community Group IPR policy that is lacking in the Rec Track IPR policy.
• Broad patent commitments are locked in on a regular schedule, they aren't delayed until a WG thinks a spec is "done" and all the comments and objections are resolved.
• It appears to address the use cases / problems with the rec track process noted in this issue -- it can create authoritative specs for things like mappings to system APIs that change on an unpredictable schedule.
• It should encourage specs to be maintained by making continual updating the normal activity of a LSTWG. SInce a spec is never "done", all involved should expect it to need ongoing attention.

It does create new challenges:

• The LSTWG would have to impose a discipline on itself to minimize "breaking changes" during the ongoing development/maintenance process.
• Those making normative references to the spec would need to do extra diligence to reference those features in a spec that are least likely to change in ways that would break the referring spec.
• Determining the right rhythm for snapshots/patent exclusion periods could be tricky, and likely to generate concerns from overworked lawyers. The LSTWG would probably need to take extra care to create accurate but usable-by-lawyers change logs describing the delta between one snapshot and another.
• Probably more challenges I haven't thought of....but I envision this as an experimental supplement to the existing Rec Track process, much like CGs were an experiment when launched in 2010 or so. If LSTWG's turn out to be successful, perhaps that would inspire changes to the Patent Policy in the future.

[jeffjaffe]

I wonder whether we need two different issues here.

Joanmarie's original post looked for a LS model for AAM's; and I posted that having such a model would help not only AAM's; but also vocabularies.

Mike's proposal would apply to a much broader set of specs.

It is probably the case that both use cases are worth addressing, but we might address them on different time scales.

[chaals]

@michaelchampion wrote:

Strawman proposal (more a thought experiment than a serious proposal at this stage)

This seems a lot like the approach used by the Web Platform Grop for HTML. The biggest difference I can see is no requirement for FPWD for specs that are being revised, and the addition of a contributor license.

Not requiring a FPWD to revise a Recommendation seems in principle useful. One impact would be that there is no exclusion period, and therefore no commitment, to anything until the CR (or Mike's equivalent). For a spec that is going to Rec/snapshot stage more than every three months, this makes no difference, for every six months it is probably not that significant, but for a spec stabilised once per year that seems easier on the lawyers but more likely to induce frustration if someone does want to exclude something.

Having a CLA seems useful. In practice I think it is less valuable than it seems, since a significant proportion of features are not contributed to the specification by the people or even company that developed them but instead by someone else who figured out how it worked - but who almost certainly doesn't hold the relevant IPR in the first place.

It doesn't seem to address the use case raised at the beginning of this, which is IMHO for a registry that is relatively straightforward to update but has a formal status like a Recommendation - and for which there is a need in various groups (I know of at least HTML and WCAG as likely users, before I try to think).

[chaals]

@jeffjaffe wrote:

I wonder whether we need two different issues here.

Yes, I think "streamline the Rec track process", and "allow registries to be created that support Recs" are pretty different issues.

[dwsinger]

On Jan 6, 2018, at 8:47 , jeffjaffe notifications@github.com wrote:

I wonder whether we need two different issues here.

Yes. I think we do need two questions. She asked for Living Standards, which is what we are running with. But she talks about registries, and I think they are quite different. What admission criteria are there for the registry? When a spec. incorporates a registry by reference, what status does each entry have? Are developers required to recognize and support all values, or can they choose? and so on./

David Singer Manager, Software Standards, Apple Inc.

[dwsinger]

@joanmarie could you look at #168 and see whether the linked Wiki and this issue are heading towards addressing your original request?

[dwsinger]

see https://www.w3.org/wiki/Living_Standards

[dwsinger]

AB input and any more team input by Apr 19th

[joanmarie]

@dwsinger: Sorry for the delay. Been traveling. I'll take a look today or tomorrow.

@cookiecrook: Your input would also be helpful as you also had voiced this need.

[johnfoliot]

Jeff wrote:

I posted that having such a model would help not only AAM's; but also vocabularies.

FWIW, we have an emergent situation with WCAG and a newly proposed SC that lists a fixed list of form inputs that will require attaching metadata to them (for personalization). Currently the CR Spec points to the token value list associated to @ autocomplete in HTML5, but there is a concern about ensuring the list remains fixed (and self-contained with the spec. See: https://github.com/w3c/wcag21/issues/803).

While the autocomplete values have a specific browser function, AG WG sees this list as a rudimentary taxonomy (terms and definitions), which also meets some basic needs for personalization. The AG WG had debated including these values as an Appendix to WCAG 2.1, but because it needs to be a machine-referenceable taxonomy there were some concerns going forward that way, and the current 'solution' still introduces some brittleness into the situation.

Having a repository as Jeff suggests would be a great solution to this issue, and so a vote of support for further exploration in that direction.

(See also: https://w3c.github.io/personalization-semantics/#vocabulary-implementations for a related and similar use-case. I believe an official "W3C Repository" would be extremely useful there as well.)

[dwsinger]

please see https://www.w3.org/wiki/Living_Standards for comments

[chaals]

from the draft in the wiki:

Your licensing commitment is to any essential IPR in an agreed draft when there is a period of continuous essentiality that includes that agreed draft and lasts for 225 days or more, with no agreed drafts in that 225-day interval in which the IPR was not essential. (“could have excluded and did not”).

Does this introduce a motive for periodically removing a feature from a draft so it does not become essential? Using e.g. Echidna this is pretty easy to do, and tempting for lawyers to request, but the consequences seem unclear.

It clearly runs counter to the motivating idea that engineers don't worry (much) about IPR issues - but being easy to implement there may be a temptation to do it as a way to avoid issues.

Or it may be a theroetical possibility that isn't worth much real time because it won't really happen.

[dwsinger]

Yes, both a snapshot and this continuous model have this. I have to assume that getting the consensus of the WG to remove a feature periodically "in order to avoid licensing commitments" ought to be hard.

[dwsinger]

I propose putting the Evergreen standards into a 'sandbox' with their own experimental process and IPR policy. These would be developed and approved in the usual way for these documents, viz; (a) the process CG, AB, and team and AC approval for the process and (b) PSIG, team and AC approval for the patent policy.

To enable this, I think we should insert one line into the current process, in 6.0. "Recommendations and Registries may also be developed or maintained using a formally approved experimental Evergreen Standards process."

[nigelmegitt]

Seems like a slightly scary door to open, but if we're going to, then we need to require that whatever process is being followed is documented on a permanent space (e.g. the process itself can't be on a wiki page) and linked to from the document being developed or maintained.

[dwsinger]

I don't think this opens a door; I agree, the documents should be as stable as the process and patent policy. I'm trying to confine such experimental documents to a small sandbox, so that if we fiddle mid-year, such fiddling can't affect the general process or the stable patent policy.

[jeffjaffe]

@dwsinger I'm not sure that this insert is necessary - and I'm not sure that I agree with it as it is written.

Necessity: I envision that when we go through the exercise of "formally approving an experimental ES process" - then that is plenty of time to also amend the process document as needed.

Agree as written? In the ES wiki, I listed several use cases; registries is only one of them. It is not obvious to me that this is the highest priority use case. So I don't see why we would provide a stub in the Process Document for registries, and not for the other use cases.

[dwsinger]

Hi. On adequacy I said “Recommendations AND Registries” so I am unsure why you think only registries.

On necessity, this would simply mean we don’t need to ‘open for editing’ the formal process document if and when we put ES documents out for approval. Takes temptation out of our way (to change anything else).

It is not major, but I do think we need a separate sandbox for ES for a while.

Sent from my iPhone

On Oct 2, 2018, at 5:05 PM, jeffjaffe notifications@github.com wrote:

@dwsinger I'm not sure that this insert is necessary - and I'm not sure that I agree with it as it is written.

Necessity: I envision that when we go through the exercise of "formally approving an experimental ES process" - then that is plenty of time to also amend the process document as needed.

Agree as written? In the ES wiki, I listed several use cases; registries is only one of them. It is not obvious to me that this is the highest priority use case. So I don't see why we would provide a stub in the Process Document for registries, and not for the other use cases.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[frivoal]

@dwsinger As this topic seems unlikely to make it to the process 2019, and we're trying to wrap that up, I suggest removing the Agenda+ label for now.

[dwsinger]

removed

[jeffjaffe]

The AB discussed [1] as an approach to addressing this issue and is forwarding it to the Process CG for consideration as a candidate for Process 2020.

[1] https://www.w3.org/wiki/Evergreen_Standards

[css-meeting-bot]

The Revising W3C Process CG just discussed Living Standards.

The full IRC log of that discussion

<florian> topic: Living Standards
<florian> github: https://github.com/w3c/w3process/issues/79
<jeff> https://www.w3.org/wiki/Evergreen_Standards
<florian> jeff: At the last AB meeting, the AB approved to move the discussion about living standards to the process cg on the basis of the document linked above
<florian> jeff: this proposes creating a new track for specs
<florian> jeff: the document mixes explanation, motivation, process, etc
<florian> jeff: the document is poorly suited to being a pull request
<florian> jeff: but we need a strategy to socialize this
<florian> jeff: and we need to think of a way to turn this conceptual document into process text that could be proposed as a pull request
<florian> q+
<jeff> ack fl
<dsinger> q+
<jeff> FR: The AB agreed to push this into Process CG space
<jeff> ... worthy of discussion
<mchampion> q+ to ask whether we see the Evergreen standards process as part of the Process Document or akin to the Community Group process that lives outside it
<jeff> ... not unanimity that this was a good idea to do
<jeff> ... but at least a good idea to explore
<jeff> ... some like myself and Chaals are not yet sold
<dsinger> ack mch
<Zakim> mchampion, you wanted to ask whether we see the Evergreen standards process as part of the Process Document or akin to the Community Group process that lives outside it
<jeff> MC: ^^
<jeff> q+ to respond to Mike
<jeff> MC: Is it like CGs
<jeff> ... but in that case we never integrated them
<jeff> ... no strong feeling, but at least a question
<jeff> DS: For CGs we needed to keep separate because open to public
<jeff> ... Process for Member stuff
<jeff> ... on ways ahead:
<jeff> ... PSIG for IPR
<jeff> ... Process CG folks should read the wiki
<jeff> ack ds
<mchampion> q+ to talk about patent policy
<jeff> ... Socialize it at AC meeting
<jeff> ... assess AC support
<jeff> ... for document structure; this is an alternative to section 6.
<jeff> ... should be an annex while experimental
<jeff> ... PSIG should do the same
<mchampion> +1 keeping it as an annex to the process and PP
<jeff> ... so I and Jeff need to convert this discursive discussion into actual process text
<florian> florian: we did discuss this in the AB, and agree to move the disucssion to the process cg on the basis on that document, but I want to note that there was not unanimity on whether it was a good idea. Notably, at least chaals and myself though that adding this alternative track was a bad idea, but we did agree that it should be discussed in the open.
<dsinger> q?
<dsinger> ack je
<Zakim> jeff, you wanted to respond to Mike
<dsinger> q?
<dsinger> q+ to talk about Registries
<jeff> Jeff: +1 to Dave on experimental
<tzviya> +1 jeff
<jeff> ... needs to be in Process doc since we are conferring status
<jeff> ... need much wider review than just AC - not clear how to get that done
<dsinger> ack mch
<Zakim> mchampion, you wanted to talk about patent policy
<mchampion> The most efficient way to get patent policy language is by having W3C attorney(s) work with member attorneys offline, then take a concrete proposal to PSIG for thumbs up/down
<jeff> Jeff: +1
<dsinger> q?
<jeff> ack ds
<Zakim> dsinger, you wanted to talk about Registries
<jeff> DS: Please also read the related topic of "registries"
<jeff> ... matches GH issue
<mchampion> q+ to ask how we come to consensus on whether this is actually a good idea
<dsinger> ack mcha
<Zakim> mchampion, you wanted to ask how we come to consensus on whether this is actually a good idea
<tzviya> q+
<jeff> MC: ^^^
<jeff> DS: We need a plusses and minuses doc
<jeff> MC: What you said
<jeff> ... an explainer
<jeff> ... elevator pitches
<jeff> DS: Good idea
<florian> wfm
<dsinger> q?
<dsinger> ack tz
<jeff> ... Jeff and my action
<jeff> TS: Broader communication
<jeff> ... explainer is a great idea
<jeff> ... could send to AC and chairs
<jeff> ... blog post
<jeff> ... explicitly ask people (e.g. chairs) to forward
<jeff> ... needs explainer first
<jeff> DS: Need 1. Motivation
<jeff> ... Explainer
<jeff> ... 3. Plusses and minusses
<jeff> ... 4. Lawyers
<jeff> ... 5. Ready to talk at AC meeting

[littledan]

One possible use case for a Evergreen Standard/Registry process could be WebIDL.

WebIDL defines notation and algorithms for hooking up various standards to each other (especially ECMAScript and Web APIs which are exposed to it). Things can be added to WebIDL when they are needed by other specifications. There's no way to implement or test all of WebIDL directly; instead, specifications which use it are tested (even if there is common infrastructure under the hood on both the implementation and test side).

The needs for WebIDL from other specifications evolve, and their Rec schedules differ (as they should), but there is a benefit to align on common notation for many specifications. It seems like a continually updated "Registry" of the shared notation could help. That's effectively what we have today with the WebIDL Editor's Draft, but it could be nice to include more proper handling within W3C IPR and review processes.

[plehegar]

Here is a proposal to amend the W3C Process with an Evergreen Recommendation track: https://www.w3.org/2019/03/Evergreen.html

[dwsinger]

This is stunning, great work, thank you. Detailed initial comments

• In https://www.w3.org/wiki/Evergreen_Standards#Charter.2C_Repository.2C_Document.2C_Testing.2C_and_Implementation_Requirements we detail that the charter MUST list the repo locations for documents on the evergreen track. we seem to have lost that
• and in there we also ask that the document header always have a perma-link to this version, under the "latest version" link

in 5.2.6 we will only get expected dates of traditional recs for dual-track documents, so this needs to be a conditionally required supply of date

I think it impractical to have in-line tagging for whether a feature has passed either 180 days review or been in a snapshot. I suggest dropping these two. Those concerned only to implement mature, licensed, features will need to use a snapshot that's 180 days old or older (and compare it to the current version in case anything in there has been deleted).

what's this 24-months and where did it come from and what does it do?

[jeffjaffe]

@dwsinger

1. Repo location - great catch!
2. Perma-link - Indeed!
3. Not sure what you mean by conditionally required. Could you propose a specific edit?
4. In-line tagging. I'll leave that to the tooling experts. I agree that your solution is acceptable if indeed we cannot get the tooling.
5. 24 months. It's a bit arbitrary. Today, a formal objection has meaning because a spec cannot go to REC without processing a formal objection. In Evergreen, one can have an Evergreen REC without the processing of a formal objection. So we felt we needed to have some arbitrary time to assure objectors that their issues are getting a hearing. 24 months is the opening proposal.

[dwsinger]

3. change "For each technical report being developed on the Evergreen track, an expected date when the document will also be reviewed on the W3C Recommendation track. Note: This date often will be later than the end date of the WG." to "For each technical report being developed on the Evergreen track that will also be published on the Recommendation track, an expected date when the document will also be reviewed on the W3C Recommendation track. Note: This date often will be later than the end date of the WG.

The wiki said that for formal objections etc., they must be noted in the document header until resolved...2 years is an awful long time...

[michaelchampion]

Thanks for putting this into Process-speak, it makes it easier to grok what's being proposed! My first impression is that there's more new terminology than needed. For example, what's the distinction between a Working Draft and a Preliminary Draft other than one is a step toward Recommendation and one is a step toward Evergreen Recommendation?

More generally, seeing this all in the Process Document context leads me to think that Evergreen should not be a separate track so much as a possibly permanent CR-like phase. Could all the 6.11 text be made into CR requirements, e.g. the feature level tagging and the requirement to renew snapshots and re-open exclusion opportunities on some rhythm? This would address a bug in the traditional process, that patent commitments only lock in once a spec gets to Recommendation, and things can get stuck in CR for years for various reasons. That would compose better with the WHATWG process -- Living Standards are roughly equivalent to Evergreen Standards, but a snapshot of either can move through the PR-> Rec process if there is broad enough review, consensus, and "Director" signoff. I also think it could address the maintenance problem: the norm is that ALL W3C specs are actively maintained because the implemented web is evergreen; declaring "we're done" and walking away is a sign that the spec is no longer really a viable part of the web.

What would we lose by equating CR and ER? It would raise the CR bar a bit (insisting on the feature-level tagging, cleaning up pending formal objections). Yes, it would require a Patent Policy update, but that has to be done for the current Evergreen proposal. It would create more work for lawyers because failing to respond to ER/CR exclusion opportunities really does trigger a binding patent commitment. It might decrease the motivation of a WG to get "done" by getting to Rec (but that could be a success criteria for charters that really do need to get to Rec status to be successful, e.g. WCAG or other specs that other SDOs or governments want to take a normative dependency on).

[jeffjaffe]

Thanks @michaelchampion those are all good and provocative thoughts.

I have the following pragmatic approach to your idea of equating CR and ER. I believe it will be nontrivial to get a W3C consensus for the ER track, even as a separate experimental track - without requiring all that are on the REC track to consider whether this helps or hinders them. Equating CR and ER now would force a very complicated debate and slow us down.

Could you live with (a) introducing ER now as an experimental option (b) getting some years of experience with it; and then (c) coming back to the potential merge of REC and ER at some point in the future?

[michaelchampion]

Could you live with (a) introducing ER now as an experimental option

I could live with that, and I'm not implying that Microsoft would object to the current proposal. For the moment, this is a personal proposal just to stimulate discussion, and I may retract it if colleagues point out horrible flaws.

That said, I'm not sure I agree that it would be easier to get broader consensus on a two-track approach than a "fix the Rec track" approach. (The "bugs" this would fix in the Rec track are a) little motivation to maintain Recs; b) binding patent commitments very late in the process; c) the overhead of getting from CR to Rec implying that it is a stale snapshot of what is actually used on the web; ...) I think the cost in confusion about having two tracks may outweigh the cost of building consensus that a tweaked CR definintion is essentially equivalent to a Living/Evergreen Recommendation.

A less confusing compromise might be language that would allow CR's to be treated as ER's if they meet the optional additional criteria now in 6.11 and if their charter allows it. In other words, the ER "track" would be identical to rather than parallel to the Rec track up to the CR phase, and at that point they diverge into an ER path and a PR->Rec path... with the possibility of an ER going to PR once the update cycles slow down, and a Rec going to ER once it needs maintenance.

And if we are going to re-open the Patent Policy, I will argue for a binding patent commitment when the CR exclusion period expires. I think we need to fix that bug whether or not we do any flavor of the Evergreen proposal.

[plehegar]

I added the need to have the URL of the repo in the proposal: https://www.w3.org/2019/03/Evergreen.html For the Perma-link, good catch, but we'll need to put this into our publication requirements imho.

[swickr]

@dwsinger commented

in 5.2.6 we will only get expected dates of traditional recs for dual-track documents, so this needs to be a conditionally required supply of date

and subsequently suggested

1. change "For each technical report being developed on the Evergreen track, an expected date when the document will also be reviewed on the W3C Recommendation track. Note: This date often will be later than the end date of the WG." to "For each technical report being developed on the Evergreen track that will also be published on the Recommendation track, an expected date when the document will also be reviewed on the W3C Recommendation track. Note: This date often will be later than the end date of the WG.

👎 to this change. We should start with the expectation that all W3C Evergreen Recommendations will eventually also become W3C Recommendations. In practice getting to Rec may take a long time and expected milestones in a charter might not be met; W3C can diagnose such failures as part of our regular WG progress review.

A clarification in this same sentence is in order, however; the intent was "end date of the charter", not "... of the WG". That is, part of the expectation can be that the WG will need to be rechartered or the (current) charter extended before reaching Rec.

[plehegar]

Note also the sentence in section "6.2.3.1.2 Wide Review for the Evergreen Track" in the proposal that reinforces the desire to publish a REC at some point: "Yet it is still expected that those documents will ultimate move to the Recommendation track to achieve a more complete wide review, horizontal review, AC review, and Director approval."

[swickr]

In Re Formal Objections, @dwsinger commented

The wiki said that for formal objections etc., they must be noted in the document header until resolved...2 years is an awful long time...

Two years felt awfully long to me as well. "Until resolved" can be even longer. In current Process the WG has incentive to avoid Formal Objections and, when any are raised, to participate in their resolution. Deleting a notation from a document header is not as much incentive. More ideas certainly welcome.

[dwsinger]

Note also the sentence in section "6.2.3.1.2 Wide Review for the Evergreen Track" in the proposal that reinforces the desire to publish a REC at some point: "Yet it is still expected that those documents will ultimate move to the Recommendation track to achieve a more complete wide review, horizontal review, AC review, and Director approval."

FWIW, (and partially channeling the Living Standards people I have heard) I think this is not and should not be an expectation; some specs will live permanently Evergreen. I think that WG are notoriously bad at predicting dates, and this one in particular will usually, and maybe always, be completely fictional.

[plehegar]

The expectation of moving to the Rec track doesn't preclude the expectation of keeping it on the ER track. In "6.1.1.1 Transitions between the Evergreen track and W3C Recommendation track", we have the following "Transition to the REC track does not necessarily mean that specification development as an ER stops because the work is entirely completed. [...] There could still be an ER version that is further developed." Regarding predicting dates, I see that as the same as predicting milestones for a REC-track-only document. Yes, it's hard to predict but having a goal helps keeping things on track.

[dwsinger]

so, we'll be OK with charters that say "no prediction" or "sometime in the late 2020s"?

[plehegar]

imho, any date that would go beyond the end date of the current charter will be speculation, but will make it clear that there is no intent to produce a REC under that charter.

[frivoal]

• I largely agree with Mike Champion about trying to fuse the REC track and the ER track more. The differences between WD and PD are minor, so we should merge them. WD have, but PD don't have:

  must record the group's decision to request publication. Consensus is not required, as this is a procedural step,

  As Groups can have blanket resolutions allowing the editor to do it at will, this is not a costly thing to have, and it's the only difference, so they should just merge.

  Side note: the PD acronym for Preliminary Draft is unfortunate: in French it is a common spelling of a homophobic slur. We cannot avoid all negative connotations in all languges, but French is common enough, and calling it a Working Draft avoids the problem altogether.

• I also agree that merging ER and CR, or making ER a maturity level >= CR would be good. In particular, I think the content of the Note inside the definition of CR should apply to ER as well. ERs should never be inferior to CRs in that respect. Most of the actual overhead of the process is between CR and REC, so that would be eliminated by the ER track, and most of what is sometimes characterized as overhead before CR is about listening and responding to other people's feedback, so that's good to keep. If we were to ensure that, that would resolve quite a few of the concerns I have with the overall concept of the evergreen track.

• From the patent policy point of view, I think we need two adjustments, both applying to the REC track and to the ER track:

  • The patent regime of CGs, where patent license is granted immediately for the contributor's own contribution, should apply to WGs as well, and cover all drafts from (FP)WD and PD and up, and possibly EDs as well.
  • We should move the full patent commitment from REC to CR/ER (+ appropriate delay for review). I think making full patent commitment available more easily on the ER track than on the REC track would actively discourage people from using the REC track even if they otherwise prefer it, which would be unfortunate.

[jeffjaffe]

@dwsinger We should define a class of documents called Registries (using your definition in the Registry wiki https://www.w3.org/wiki/Continuous_Publications ). We should say that Registries may use the ER process for the most part. But Registries may be excluded from the requirements of Snapshot and articulating a future date to go to REC.

[plehegar]

Merging CR and ER wouldn't work imho. I'm sympathetic with the point on having patent commitments on CR rather than REC. But CR also has a requirement for horizontal reviews before publication, which we don't have for ER (it's a 180 days floating window instead). That's a substantial difference between the two.

[michaelchampion]

@plehegar makes a good point that "wide review" has different status for CR and ER. But https://www.w3.org/2019/Process-20190301/#wide-review is not very specific about what the criteria needed to claim that wide review has happened, and there's an open AB issue about improving the horizontal review process. So I don't see this is a fatal flaw in the proposal to have the Rec and Evergreen tracks be the same up to the point of CR.

I must say I find the floating window idea confusing; I don't necessarily object to it if it gets support and works out in experiments, but I'm skeptical. In general, I suggest the best way forward for both ER and PR is to annotate spec features with links to data on their implementation and review status. For ER it's "buyer beware" -- spec consumers decide how much implementation and review they need to see completed before making a judgment about referencing, using, documenting, etc. a spec. For PR, it's a "Director" judgment of whether the Recommendation criteria have been met.