Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Process supporting "Living Standards"? #79

Closed
joanmarie opened this issue Sep 8, 2017 · 80 comments
Closed

Process supporting "Living Standards"? #79

joanmarie opened this issue Sep 8, 2017 · 80 comments
Assignees
@dwsinger
Labels
Closed: Accepted The issue has been addressed, though not necessarily based on the initial suggestion DoC This has been referenced from a Disposition of Comments (or predates the use of DoCs)
Milestone
Process 2020

Comments

@joanmarie
Copy link

joanmarie commented Sep 8, 2017 •
edited
Loading

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:

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
Copy link

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
Copy link
Contributor

dwsinger commented Sep 8, 2017 via email

@michaelchampion
Copy link

@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
Copy link
Author

joanmarie commented Sep 9, 2017 •
edited
Loading

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:

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
Copy link

cookiecrook commented Sep 12, 2017 •
edited
Loading

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
Copy link

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
Copy link
Member

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
Copy link

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
Copy link

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
Copy link

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
Copy link
Contributor

chaals commented Jan 7, 2018

@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
Copy link
Contributor

chaals commented Jan 7, 2018

@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
Copy link
Contributor

dwsinger commented Jan 8, 2018 via email

@dwsinger dwsinger self-assigned this Feb 14, 2018
@dwsinger dwsinger mentioned this issue Feb 21, 2018
Closed
@dwsinger
Copy link
Contributor

dwsinger commented Mar 2, 2018

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

@dwsinger dwsinger added the Needs AB Feedback Advisory Board Input needed label Mar 9, 2018
@dwsinger
Copy link
Contributor

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

@dwsinger
Copy link
Contributor

AB input and any more team input by Apr 19th

@joanmarie
Copy link
Author

@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
Copy link

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: w3c/wcag21#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
Copy link
Contributor

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

@chaals
Copy link
Contributor

chaals commented Jun 14, 2018

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
Copy link
Contributor

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
Copy link
Contributor

dwsinger commented Oct 1, 2018

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
Copy link
Contributor

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 dwsinger added the Agenda+ Marks issues that are ready for discussion on the call label Oct 2, 2018
@dwsinger
Copy link
Contributor

dwsinger commented Oct 2, 2018

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.

@wseltzer wseltzer changed the title Process supporting "Living Standards"? Process supporting "Living Standards"? (Evergreen) Apr 8, 2019
@evanp
Copy link

evanp commented Apr 8, 2019

I'd like to pipe in with support for this as a feature. Especially for newer standards, implementation experience is going to grow significantly after the first recommendation. An evergreen recommendation can effectively capture that learning.

For registries, this seems like the only way the process can work well.

I also agree that as we explore the process, an experimental attitude towards evergreen recs is a good idea. I'd expect as we get a few years into the process, that "experimental" aspect will mature into standard procedure.

@wseltzer
Copy link
Member

Some comments from discussion in the Patents and Standards Interest Group (PSIG). minutes member-only

  • Will there be a regular cadence for publication of snapshot review drafts? Given the potential number of W3C specs that could be using this process, lawyers might like to have a schedule to anticipate reviews.

  • Is there any exclusion period for a contribution commitment?

  • When a participant leaves a group, what happens? (Do they get an exclusion opportunity on the things added since the last RD?)

  • Notifications. It's important to ensure good notice (email) of exclusion opportunities and commitments.

  • How would the experimental Process be rolled out?

Some of these are questions for the associated Patent Policy I'm drafting, but the cadence and roll-out are probably good questions for this group.

@dret
Copy link
Member

dret commented Apr 23, 2019 •
edited
Loading

this may be just a part of what this issue discusses (which is related to #168, i guess?), but in case anybody is interested: i just posted an updated draft of my "the use of registries" document, and i have added a list of w3c specifications that currently are using some shape or form of a "registry", but are doing so in a rather ad-hoc session because there is no process or even guidance (afaict). here is a direct link to the section listing W3C specifications: https://tools.ietf.org/html/draft-wilde-registries-02#appendix-A

@jeffjaffe
Copy link

@dret Thanks, Erik, this is really helpful.

@dret
Copy link
Member

dret commented Apr 23, 2019 via email

@css-meeting-bot
Copy link
Member

The Revising W3C Process CG just discussed github: https://github.com/w3c/w3process/issues/79.

The full IRC log of that discussion <natasha> topic: github: https://github.com//issues/79
<natasha> plh: no significant alerts at AC, now refining the process?
<natasha> dsinger: understand that plh has made a branch and will tell us where
<florian> https://github.com/w3c/w3process/tree/evergreen
<natasha> plh: new branch of evergreen process in github, have some bikeshed issues which will discuss with florian
<plh> https://github.com/w3c/w3process/blob/evergreen/index.bs
<natasha> ... should reflect the proposal on the w3c website
<natasha> ... one clarification was made following the AC session
<natasha> ... please raise issues against this
<natasha> ... evergreen is trying to do a lot of changes, and doing these for Process 2020 will be difficult
<natasha> ... we have a higher chance to propose a experimentation, and then move this onto the recommendation track for 2021
<natasha> s/a/an
<mchampion> q+
<natasha> plh: people are asking for this evergreen mode
<natasha> ... so we should move forward with this experimentation
<florian> github: https://github.com//issues/79
<natasha> plh: an example - it took a long time to adopt license for our documents
<dsinger> ack mch
<natasha> ... we may not be able to adopt this on the rec track so easily, given this experience
<natasha> mchampion: I'm not sure how to tag with "evergreen"
<natasha> dsinger: we can make a label for "evergreen"
<dsinger> we have a label Evergreen
<natasha> mchampion: what would be the normative status of the evergreen track in this experimental version?
<natasha> ... community groups were to be an experimental track which would get wrapped into the process, but this never happened
<jeff> q+ to provide a different view of CG history
<natasha> q?
<dsinger> q+ to explain why the CG process is separate
<natasha> plh: good question. CGs don't have a defined process; no charters etc.
<natasha> ... the way this would be done is to run in parallel with the rec track
<dsinger> q?
<natasha> ... after the end of the experiment we will decide whether to keep as parallel or learn whether to make a major modification to the rec track
<natasha> ... e.g. if we get the patent policy approve in the experiment, it will be easier to get that approved when adding to the rec track
<dsinger> ack fant
<natasha> ... we need to raise the confidence level first
<natasha> fantasai: agree we should try to fold this into the rec track as much as possible
<cwilso> q+
<natasha> ... and find out what the patent policy changes are and present these to the AC
<florian> q+
<dsinger> ack jeff
<Zakim> jeff, you wanted to provide a different view of CG history
<natasha> ... we should try to merge together
<natasha> jeff: I agree with plh 's conclusion
<fantasai> s/fold this/merge this/
<dsinger> q?
<dsinger> ack ds
<Zakim> dsinger, you wanted to explain why the CG process is separate
<natasha> jeff: the evergreen proposal is that it should be experimental part of the process and these specifications will be called "Evergreen" recs
<natasha> dsinger: we discussed adding CGs to the process doc last year, decided process document is more focused on member only
<dsinger> q?
<dsinger> ack cwi
<fantasai> s/we should try to merge together/We need maintainable RECs, and if this is what's giving us maintainable RECs, then we should align the two tracks as much as possible so that this does give us editable RECs/
<natasha> ... we discussed having a separate document for Evergreen, but realised evergreen track will become entangled with the process so working on it within the process document was the decision
<natasha> cwilso: the more we can bind this together with the rec process the better
<jeff> q+ to talk about use cases
<natasha> ... I'm not sure whether a year would be enough experience
<natasha> plh: I agree. Most groups will start on rec track and move to evergreen
<fantasai> cwilso++
<dsinger> q?
<dsinger> ack flo
<natasha> cwilso: until you have a recommendation, there's nothing there. After you have a recommendation you may decide to maintain it in an everygreen way
<natasha> s/everygreen/evergreen
<natasha> florian: evergreen as drafted makes it possible to be on evergreen before reaching rec. If you start on evergreen reaching rec is a lower bar
<natasha> ... if we think the bar is too high for rec we should fix that
<natasha> ... maintenance after CR is harder than it should be
<natasha> ... before CR most WDs can be evergreen
<natasha> ... other things can be done with tooling
<plh> q+
<fantasai> s/we should fix that/we should fix that; otherwise you're asking "do you want a REC that's hard to maintain or one that's easy to maintain, which is a silly question to have to ask/
<dsinger> ack jeff
<Zakim> jeff, you wanted to talk about use cases
<natasha> florian: we should draft that; I have been wanting to do this
<dsinger> q+ to mention registries and urge a use-case check, and to suggest that we try to settle the question of what ES track can be used for, at the next call
<natasha> jeff: WGs have been asking for an evergreen track now, so we have a responsibility to do this asap
<natasha> ... fixing rec track can happen at the same time
<florian> q+
<dsinger> q?
<natasha> scribenick: fantasai
<fantasai> ScribeNick: fantasai
<dsinger> ack plh
<fantasai> plh: I'm worried about restricting experiment to docs that are only RECs
<fantasai> plh: We have some cases, e.g. Manifest spec
<fantasai> plh: I'd be concerned about restricting the experiment
<fantasai> plh: Not being able to move from CG to Evergreen Track, I'd have to consider it
<dsinger> q?
<dsinger> ack ds
<Zakim> dsinger, you wanted to mention registries and urge a use-case check, and to suggest that we try to settle the question of what ES track can be used for, at the next call
<fantasai> plh: Would want to check any use cases that move directly Evergreen
<fantasai> fantasai: What would it mean to move directly to Evegreen, why would that be different from REC?
<fantasai> plh: A lot of cases would be shifting from REC track to Evergreen track, they're all existing specs
<fantasai> plh: People would prefer to do piecemeal updates
<fantasai> plh: To add one specific mapping to ARIA mapping because this API got updated, e.g.
<fantasai> plh: Two other cases
<fantasai> plh: One is WD like Manifest. Would we want to allow ppl to move them on the Evergreen track as part of experimentation?
<fantasai> plh: proposal allows that if charter updated
<fantasai> plh: Last case is CG report
<dsinger> q?
<fantasai> plh: Would like to adopt it into Evergree Track directly
<fantasai> plh: Proposal allows either
<jeff> [WebAppSec has said they want Evergreen to track HTML. So any new specs from WebAppSec would also be examples.]
<fantasai> dsinger: Don't forget registries
<fantasai> dsinger: Next call, we should settle what use cases and purposes and restrictions are we using Evergreen Standards
<fantasai> dsinger: Do you have to start from REC? Can you start as Evergreen?
<fantasai> dsinger: Where do we think it should be introduced or not?
<fantasai> dsinger: Let's write into issue and think about it, make concrete proposals
<dsinger> q?
<cwilso> use cases are just scattered in https://github.com//issues/79?
<dsinger> ack flo
<fantasai> florian: Clarify, for ppl who want to be on Evergree from the start
<fantasai> florian: REC track up to CR does the same thing already
<fantasai> florian: So I don't buy argument that pre-CR needs to be different than REC-track
<jeff> q+ to respond to Florian
<fantasai> florian: post-CR is heavyweight to update
<fantasai> florian: ...
<dsinger> https://github.com//issues/79#issuecomment-485566190
<fantasai> florian: Bar to enter CR is heavy, ppl might want to make it easier. But I think it's a feature that requirement is high for CR.
<dsinger> and see https://www.w3.org/wiki/Evergreen_Standards#Licensing
<fantasai> jeff: WebIDL said he'd consider keeping his work in W3C on Evergreen Track but not on REC track
<fantasai> jeff: How does Florian's comment address that use case at all?
<plh> --> https://www.w3.org/wiki/Evergreen_Standards#Use_Cases Use Cases
<fantasai> dsinger: So want to point to questions about licensing.
<dsinger> psig: Will there be a regular cadence for publication of snapshot review drafts? Given the potential number of W3C specs that could be using this process, lawyers might like to have a schedule to anticipate reviews.

@css-meeting-bot
Copy link
Member

The Revising W3C Process CG just discussed IPR of Evergreen.

The full IRC log of that discussion <fantasai> Topic: IPR of Evergreen
<fantasai> github: https://github.com//issues/79#issuecomment-485566190
<fantasai> dsinger: first question, rate of adoption is controlled by charter change
<fantasai> dsinger: We currently don't document when snapshots happen
<fantasai> dsinger: Might be good to put htat in charter, e.g. this group publishing snapshots in Feb and Oct
<mchampion> q+
<fantasai> dsinger: Lawyers can object to schedule in charter review, e.g. if too many groups pick Feb
<jeff> [/me agrees that if needed we can come up with practical solutions to the first attorney's concern.]
<fantasai> dsinger: Would it be good ot put that in the draft?
<fantasai> fantasai: wfm
<jeff> q-
<fantasai> dsinger: OK, so we'll put those dates in the charter
<fantasai> mchampion: ...
<fantasai> mchampion: Seems the lawyers would be happier with modeling patent policy on WHATWG policy as much as possible
<fantasai> mchampion: Except for cases which are not covered by WHATWG patent policy
<dsinger> psig: Is there any exclusion period for a contribution commitment?
<fantasai> mchampion: roughly same set of attorneys are asking these questions as drafted WHATWG policy
<fantasai> dsinger: Anyone explain this question?
<fantasai> dsinger: Why would you contribute something and immediately say you're not licensing it?
<fantasai> dsinger: I must be misunderstanding
<fantasai> annamweinberg: This is not my quesiton, but have context
<fantasai> annamweinberg: If someone makes a contribution, and draft evolving as it goes, is there any opportunity as it evolves for them to exclude
<fantasai> dsinger: You'd file an exclusion at the next snapshot
<fantasai> dsinger: "You took my contribution in ways that entangle patents that I'm not happy to contribute, so I'm not happy"
<fantasai> dsinger: But I don't see why you would exclude your original contribution
<fantasai> annamweinberg: ...
<dsinger> psig: When a participant leaves a group, what happens? (Do they get an exclusion opportunity on the things added since the last RD?)
<fantasai> dsinger: Answer is you file an exclusion at the next snapshot if things go in a direction you don't like
<fantasai> dsinger: We wrote in wiki that there needs to be an exclusion period on ...
<fantasai> dsinger: Lots of discussion, significant anxiety around gap that allows newbie to join group
<fantasai> dsinger: describes verbally a feature, someone else commits, and they leave before the next snapshot
<mchampion> Contributions commitments are on patents relevant to the original contribution, I agree that if the draft evolves to encumber more patents than the contribution did, those patents can be excluded at a later opportunity
<fantasai> dsinger: Can cause all the problems of patent exclusion, or just leave quietly
<fantasai> dsinger: think we should close this gap, anyone disagre?
<fantasai> dsinger: OK, we'll ask psig for exclusion opportunity triggered by leaving the WG, against state of draft at time of leaving
<jeff> q+
<dsinger> psig: Notifications. It's important to ensure good notice (email) of exclusion opportunities and commitments.
<fantasai> florian: I approximately agree, what psig's opinion as well
<jeff> ack mch
<mchampion> q-
<plh> q+
<fantasai> dsinger (reads)
<fantasai> dsinger: Creation of snapshot must result in formal exclusion opportunity email just like today
<fantasai> plh: Document that describes patent policy for evergreen doesn't exist today
<fantasai> plh: Is it an external document or is it part?
<fantasai> plh: Caution against integrating into Process
<fantasai> plh: If PSIG was to give more input based on what we do for REC track
<fantasai> plh: if it's not good enough
<fantasai> plh: if we can improve how we do notifications
<plh> q-
<dsinger> ack jef
<fantasai> dsinger: Integrating patent policy with process is tbd, but somewhere need snapshot defind
<fantasai> jeff: I don't disagree with any of the things you propose
<fantasai> jeff: I think more generally, I'd be interested if PSIG would provide two sides of the arguments
<fantasai> jeff: PSIG is expert on exclusion periods etc.
<fantasai> jeff: Pushing question into less expert group such as Process, asking us for recommendations
<fantasai> jeff: dsinger sounded really convincing. Saying opposite might be convincing. Would like to hear more about their thoughts
<fantasai> dsinger: On next call, Wendy will be available.
<fantasai> dsinger: As Wendy to definitely be available and prepared to help us understand all sides of this question?
<fantasai> dsinger: Said that exclusion filing must result in message to community lists ...
<fantasai> dsinger: so everyone knows and can take action appropriately
<fantasai> dsinger: but also need to put that info in the header
<fantasai> dsinger: IPR question that's unresolved needs to be noted in the REC, as it's still published
<fantasai> dsinger: Anything to say on notification question?
<dsinger> psig: How would the experimental Process be rolled out?
<fantasai> dsinger: I think we should settle this next meeting
<fantasai> dsinger: We should do a Process doc that defines REC track and Evergreen
<fantasai> dsinger: And roll it out as experimental, and what that means is TBD
<jeff> q+
<fantasai> dsinger: It would be a process revision
<fantasai> dsinger: and patent policy revision or separate patent policy
<fantasai> jeff: I would agree we can figure that out more at the next meeting
<fantasai> jeff: To me what we mean by experimental process
<fantasai> jeff: First, we say explicitly in the Process document that this is experimental
<dsinger> PLH notes that adoption of Evergreen track currently requires a charter revision, as documents on the ES must be so documented in the charter
<plh> plh: groups wishing to adopt evergreen would need an AC review of the charter to adopt it
<fantasai> jeff: and if successful, would be full alternate track
<fantasai> jeff: or might be merged with REC track in time
<fantasai> jeff: or after some years we decide not to do that anymore
<fantasai> jeff: notice about merging or cancelling in time
<fantasai> jeff: We may want to also provide more specific limitations of AC review and Director proposing charters
<fantasai> jeff: mabye we only do a few of them a quarter
<fantasai> jeff: so not too many ppl using while it's still experimental
<fantasai> dsinger: Anything else on 79?
<fantasai> jeff: Decision made about merging into main branch of Process 2020 ?
<fantasai> dsinger: Florian, plh, preference?
<fantasai> florian: Either way we need previewable long-lived branches
<fantasai> florian: We need that as a mechanism anyway, so I'll be starting to set that up
<fantasai> florian: After that maybe merge
<fantasai> florian: I'd prefer to not merge it, prefer to propose an alternative. But group decides, I'm just the editor
<fantasai> dsinger: I think it's easier if we keep it separate, rather than muddling with all the other things we're considering
<fantasai> dsinger: Would want to be able to see diff of just evergreen changes, not all other changes going into 2020
<fantasai> +1
<jeff> q+
<dsinger> https://github.com/w3c/w3process/labels/Agenda%2B

@plehegar
Copy link
Member

Here is the list of candidates mentioned at the AC meeting:
[[
ARIA: ARIA Mappings
SVG: Beyond SVG 2
WebAppSec: CSP
Web Performance: performance timeline, …
Web Platform: WebIDL
Dataset Exchange: Beyond DCat 1.1
Timed Text: TTML Profile registry
Distributed Tracing: Trace Contact Protocol Registry
WebRTC: registries
WebApps: Manifest, etc.
]]

To this list, we can also add Web Assembly and Service Workers. Imho, it would be best to limit the experiment to registries and specifications that were published as W3C Recommendations in the past.

@nigelmegitt
Copy link
Contributor

The TTML Profile registry might be suitable but this has not been discussed in the TTWG. I think the reason it ended up on this list was from a query about existing registries; that's not an indication by itself that the TTWG would choose the LS approach. It may or may not, we don't know yet.

@dwsinger
Copy link
Contributor

with apologies to Mike for being slow.

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?

I think we should have a uniform name across the tracks for darfts that precede formal status (before FPWD for Rec track, before Evergreen for that track).

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.

I agree that
a) in time we may well want to do all maintenance evergreen-style. I am hesitant to disrupt the Rec track with an experiment, though, and feel safer merging later
b) many of the tricks and tools and techniques here are broadly applicable across both tracks (notably, improved tooling so that review groups can and should comment on issues, and on PRs before they are taken, and more rarely on stuff that's happened).

@dret
Copy link
Member

dret commented May 17, 2019 via email

@dret
Copy link
Member

dret commented May 17, 2019 via email

@nigelmegitt
Copy link
Contributor

@dret re #79 (comment) I don't think that is an extreme position at all. From what I've seen that is the usual position.

@dret
Copy link
Member

dret commented May 20, 2019 via email

@fantasai
Copy link
Collaborator

fantasai commented May 21, 2019 •
edited
Loading

I support @frivoal and @michaelchampion's position that we should merge the proposed Evergreen Recommendation track and the current Recommendation Track as much as possible--even if there remains some divergence, it should be absolutely minimized. This will reduce confusion, ensure that improvements required by ER are incorporated into the REC track, and ensure that the ER track does not regress from the REC track or diverge from it unnecessarily. If tackling this properly requires more time, I would rather delay the implementation of Process 2020 to get it right than deploy an entire new standards track prematurely and have to deal with untangling the resulting snarl of processes in 2021+.

a) in time we may well want to do all maintenance evergreen-style. I am hesitant to disrupt the Rec track with an experiment, though, and feel safer merging later

The REC track is currently seriously problematic wrt REC maintenance, and it needs to be fixed. I consider its current state to be a disruption. https://lists.w3.org/Archives/Public/public-w3process/2019Mar/0076.html

@jeffjaffe
Copy link

@fantasai I also agree that we should merge the proposed Evergreen Recommendation track and the current Recommendation track as much as possible.

However, I don't support delaying the ER track until we accomplish the merge. At the moment the ER proposal has been in the Process CG for several months with not a large number of issues against it. There is also progress in PSIG to define an Evergreen PP.

For the REC track, on the other hand, we have barely scratched the surface of raising the issues and proposing solutions. And to my knowledge work has not even started in PSIG.

My preference would be that those that want the Evergreen Track aggressively push to get it defined. Those that want fixes to the REC track aggressively push to get it defined. Once there is more progress we see whether they are close enough to merge and do at the same time.

@michaelchampion
Copy link

I propose that we focus on what is common to the "ER Track" and "and ER state in the Rec track". I believe that's roughly:

  • The definition of the ER entrance criteria
  • A clear understanding of how wide review of ER specs would work (as part of the ER entrance criteria and/or as changes to an ER are made)
  • An agreement on how to move from the ER track/state to PR/Rec
  • An IPR policy update that meets the "ER track" requirements (and IMHO could be applied to the Rec track as well, but that's another question)

@dwsinger dwsinger removed the Agenda+ Marks issues that are ready for discussion on the call label Aug 14, 2019
@dwsinger
Copy link
Contributor

On Registries,

Here are the use-cases, collated:

from @joanmarie mentions Aria API mappings. @dret mentions https://tools.ietf.org/html/draft-wilde-registries-02#appendix-A
@plehegar mentions:
Here is the list of candidates mentioned at the AC meeting:
[[
ARIA: ARIA Mappings
SVG: Beyond SVG 2
WebAppSec: CSP
Web Performance: performance timeline, …
Web Platform: WebIDL
Dataset Exchange: Beyond DCat 1.1
Timed Text: TTML Profile registry
Distributed Tracing: Trace Contact Protocol Registry
WebRTC: registries
WebApps: Manifest, etc.
]]
add Web Assembly and Service Workers.
@nigelmegitt also mentions The TTML Profile registry

In the #168 I mentioned:
https://www.w3.org/2011/07/regreq.html

TTML uses:

https://www.w3.org/wiki/TTML/RoleRegistry
https://www.w3.org/wiki/TTML/ItemNameRegistry

And perhaps more importantly the media type registry with short form
profile designators for TTML is at:

https://www.w3.org/TR/ttml-profile-registry/

there is an XPointer registry:
https://www.w3.org/2005/04/xpointer-schemes/
It has an ad-hoc script for adding entries:
https://www.w3.org/2005/04/xpointer-schemes/0register
We don't know if that is just supposed to deposit email in someone's mbox
and whether that person knows of their mandate.

vdbrink mentions the EPSG registry, but neither link supplied now works
kcoyle mentions the Open Metadata Registry,

The document https://www.w3.org/2011/07/regreq.html mentions

alvestrand mentions stats registry in https://w3.github.io/webrtc-stats/

webauth may have need, see w3c/webauthn#1177

It would be helpful if people involved with W3C 'proto registries' could comment on https://www.w3.org/wiki/Registries#Proposed_Process_Text_.E2.80.93_Registries

(This message duplicated from #168 in order to catch all authors)

@plehegar plehegar changed the title Process supporting "Living Standards"? (Evergreen) Process supporting "Living Standards"? Jan 29, 2020
@dwsinger dwsinger removed the Needs AB Feedback Advisory Board Input needed label Feb 25, 2020
@dwsinger
Copy link
Contributor

This issue was forked into Ever* and Registries. Registries have other issues such as #168 , and Ever* is handled in P2020. Closing.

@frivoal frivoal added the Closed: Accepted The issue has been addressed, though not necessarily based on the initial suggestion label Mar 11, 2020
@jeffjaffe jeffjaffe mentioned this issue Jun 10, 2020
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@dwsinger dwsinger

Labels
Closed: Accepted The issue has been addressed, though not necessarily based on the initial suggestion DoC This has been referenced from a Disposition of Comments (or predates the use of DoCs)
Projects
None yet
Milestone
Process 2020
Development

No branches or pull requests