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.

[dwsinger]

I think it's fascinating to think of merging the two, and great to take good ideas and tooling improvements from the ES track into the classic Rec track -- but I think we should not disrupt the process for Rec track in the course of designing ES. Let's do them in parallel, and merge/inform later?

[cwilso]

As I firmly believe that over time the Rec track will quickly become overgrown with weeds (much as the non-royalty-free PP usage did) in favor of living standards (aka Evergreen Standards), I think it would be a good idea to do as close to a merge as possible.

[michaelchampion]

I don’t understand the argument that the Rec track would be disrupted if the ES and Rec track were the same until the CR phase. Maybe its too constraining for the ES track to have an up front wide review requirement but that’s not an issue for the Rec track.

One change would be the IPR policy for both tracks would require a CG-like or WHATWG-like patent commitment to ones own contributions. I don’t see that as disruptive to the Rec process.

I see a couple problems with doing a whole ES process in parallel with the Rec track. One is having to choose a track at the beginning rather than once there is enough experience to know whether a stable Rec is in sight or whether it will take a long time to get feature complete and interoperable. Deferring that decision until CR makes a lot of sense to me. Another problem is the complexity of having to design a full ES track, selling the idea to the AC, explaining which to use for specs exiting incubation, etc.

Anyway for whatevwr it’s worth, I got a lot more enthusiastic about the ES discussion once I thought of it as a post-CR alternative to PR (or cycling through WD and CR a few times before finally getting to PR) rather than as a whole separate track.

[jeffjaffe]

I don’t understand the argument that the Rec track would be disrupted if the ES and Rec track were the same until the CR phase. Maybe its too constraining for the ES track to have an up front wide review requirement but that’s not an issue for the Rec track.

@michaelchampion I agree that it would be cool to have an Evergreen track and REC track that were identical until CR. The issue in my mind is how we get there.

If we simultaneously try to introduce the Evergreen track and modify the REC track, then we need to get the entire community bought in simultaneously. Each group that currently uses the REC track will need to weigh in that we are not doing damage to them. This can take a long time to sort out; and meanwhile we will not have the Evergreen track.

I would rather introduce Evergreen as an experimental track quickly (Process 2020) and get experience with it. If we like it, and it makes sense to partially merge with REC - we can do it afterwards.

(In parallel, if there are specific enhancement to the REC track that get consensus in time for Process 2020, I'm OK with those as well.)

[michaelchampion]

Trying to re-unify some disparate discussions back in GitHub: Sorry, but my opposition is hardening to having a separate ES track that is chosen at charter time, advances by something different than Working Drafts, has different formal objection rules and wide review criteria, etc. etc. The discussions we're having on the CG list and in the AB focus on these details, and obscure the value of having easily maintained evergreen standards come out the other end of the process.

There are lots of good ideas in the ES proposal, but many of them would apply to the Rec track just as well.

• Requiring RF patent commitment on one's own contributions when joining a WG (just as one does when joining a CG or a WHATWG workstream)
• Clarifying that the workmode to achieve procedural consensus may be in the charter, or the charter may delegate it to the WG. This is rooted in current practice, I believe.
• For all deliverables, the description of that deliverable in the proposed charter must provide the URL of the W3C GitHub repository for that document.

Also, the Rec track process should evolve to downplay the role of Formal Objections, since we have to accommodate the fact there is no longer a Director who is engaged full-time and who has the expertise and credibility to make binding technical judgments about spec details. Any consensus we can build on how this should work in the Evergreen track probably applies to the Rec track.

I'm open-minded about exactly where in the traditional process the Evergreen track would branch off. I've been thinking it happens at the CR phase -- once the CR criteria are met, a WG chooses whether to stabilize and go to Rec or evolve in an Evergreen world. Maybe the CR criteria are too restrictive and the branch is earlier, I don't strongly care. Or maybe some CR criteria should move to being PR criteria (e.g., the completion of wide review).

I understand in principle the concern that this will disrupt the Rec track, but the specific changes I've noted above don't seem any more disruptive than the normal Process maintenance. Certainly no more disruptive than removing Last Call a few years ago.

On a personal note, this concern was something we wrestled with when crafting a more formal process, governance, and patent policy model for WHATWG -- the informal system was working well, would we kill it by making it more lawyer-friendly? The resulting changes were much more fundamental than those being discussed now in W3C, but caused no serious disruption. Yes there have been delays, inconveniences, and lingering (minor) controversies, but general acceptance.

[jeffjaffe]

@michaelchampion I embrace many of the suggestions that you have for the Rec track. I don't know which would get consensus - or how quickly that would happen.

Why don't you raise new issues and propose PRs for each of your issues. Then we can have an organized discussion around each of them. I suppose these might be issues for both the Process and the Patent policy.

If we get quick consensus around them and that results in a logical design that has some integration between the Rec track and Evergreen - that would be terrific. But let's make the merge after we have the consensus on the individual tracks.

[nigelmegitt]

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.

I see this as high risk. Having a review date after the end of the WG means that there is no realistic prospect of reaching Rec, which is a situation we should bias against through the process. At the least, this maybe could be updated to say "end date of the WG's currently active Charter".

For each technical report being developed on the Evergreen track, the workmode to achieve procedural consensus may be in the charter, or the charter may delegate it to the WG.

We need to create a situation where a Decision Policy always applies, be it a default W3C one or one specified in the WG's Charter. Here, we also need to define "workmode" - it is not clear where decision policy ends and workmode begins, and it needs to be clear. I am not sure there is general agreement about what workmode means.

Using the abbreviation "ER" in that section 6.1.1.1 in place of "Evergreen Recommendation" could be construed as an attempt to mislead the reader, because it doesn't repeat the word "recommendation" clearly. Looking at the transition requirements for going from "Evergreen Recommendation" to "Recommendation" in that section it is clear that an Evergreen Recommendation is very far from being a Recommendation from a Process perspective. The term "Evergreen Recommendation" is therefore itself highly misleading - it should be called something like "Evergreen Draft" instead to avoid giving the impression that it has the same status as a Recommendation but is somehow everlasting.

(this is an aside, but I've heard it said both that specifications unchanged for years are "dead" and that they are the only truly evergreen ones, in that they have stayed correct for a long time, and are therefore the most reliable! From that perspective, an ER might be considered to be "not finished yet"...)

§6.11 says that publishing an ER requires that the general transition requirements have been met. This in turn says that all issues raised since the previous maturity level must be addressed. When going from ER to ER, this rule should apply too.

This has come up separately in discussion threads, but I would register also that the text about documenting the consensus of the WG is specifying a broken requirement. Publication must in and of itself require consensus. Adding further documentation of that consensus is unimportant - I see no problem doing so, but also it is fine not to, as long as the consensus is documented somewhere. The note making a distinction between CfCs and procedural consensus is out of place here and should be removed in its entirety including the part about "work-mode", as per my comment above about lack of definition.

The requirement:

• should report which, if any, of the Working Group's requirements for this document have changed since the last publication.

is problematic: there needs to be a longer-lived trace of requirements changes over time; otherwise a group could change requirements and publish an ER one day including those requirements changes, then make some minor change the next day, and publish a new ER with apparently no requirements changes. Then the notice that requirements have changed could be very short-lived and therefore go unreviewed.

§6.11.1 says:

If 24 months elapse with significant changes to an Evergreen Recommendation, a Working Group must publish a revised Evergreen Recommendation Snapshot to ensure they get a thorough IPR review as per the @@@ER patent policy.

Should this be without significant changes?

[nigelmegitt]

Just to tie two threads together, when I referred in https://github.com/w3c/w3process/issues/79#issuecomment-473471203 to "separately in discussion threads" I meant https://lists.w3.org/Archives/Public/public-w3process/2019Mar/0047.html .

[plehegar]

I revised the proposal at https://www.w3.org/2019/03/Evergreen.html It includes more emphasis on consensus and adds the concept of registries (as a subset of Evergreen recommendation, allowing those to be excluded from some Evergreen requirements). In my mind, we still have a bunch of potential issues to go back to after the AC meeting: Preliminary Draft acronym, Using transition requests for Evergreen, Use of the Director, Comparing CR with ER. Those could potentially lead to major simplification in the proposal.

[wseltzer]

WebAppSec has expressed interest in using an evergreen process, especially for specifications that integrate closely with Fetch or HTML, as for example CSP or Fetch-metadata do, W3C's royalty-free patent policy, with continuous commitments, is seen as valuable. See https://github.com/w3c/webappsec/blob/master/meetings/2019/2019-03-20.minutes.md

[michaelchampion]

Thanks @wseltzer . It sounds like there use case is to keep W3C specs updated in parallel with WHATWG specs, so keeping the Evergreen process as similar as possible to the WHATWG process would be desirable.

[evanp]

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]

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]

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]

@dret Thanks, Erik, this is really helpful.

[dret]

On 2019-04-23 15:42, jeffjaffe wrote:

@dret https://github.com/dret Thanks, Erik, this is really helpful.

thanks, it's great if this seems useful! it may be more fitting for addressing #168. it seems that a more disciplined way of deciding when a standard needs to evolve or when a properly managed value set is all it takes might be helpful.

if there is any way i can help, please let me know. to me it seems that there is an opportunity here to improve the standards process, the work specifications writers have to do, and the way standards are designed. it would be exciting to be a part of such an improvement.

[css-meeting-bot]

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/w3c/w3process/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/w3c/w3process/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/w3c/w3process/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/w3c/w3process/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]

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/w3c/w3process/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]

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]

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]

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]

On 2019-05-17 05:00, Nigel Megitt wrote:

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.

just as a remark: registries and living standards are related, but different.

one might take an extreme position and say that registries are a pattern spec writers choose because they want a stable standard, but do understand that certain value spaces will evolve, and want to support this. in this case, the explicit goal of registries is to decouple the stable spec itself, and the dynamic ways in which some value spaces used in the spec are allowed to evolve.

[dret]

On 2019-05-17 04:52, Philippe Le Hegaret wrote:

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.

adding on to this, here is another (and very likely incomplete) attempt to list the W3C specs that may be interesting to look at as candidates for using registries:

https://tools.ietf.org/html/draft-wilde-registries-02#appendix-A

if this list misses specs, please just let me know, or ideally raise an issue at https://github.com/dret/I-D/issues. thanks!

[nigelmegitt]

@dret re https://github.com/w3c/w3process/issues/79#issuecomment-493578419 I don't think that is an extreme position at all. From what I've seen that is the usual position.

[dret]

On May 20, 2019, at 10:27, Nigel Megitt notifications@github.com wrote:

@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.

same here. i just did not want to sound too dismissive. i think it would be useful to explore the spectrum of solutions, and when which one may be appropriate.

• registries are one useful pattern.
• living standards are another useful pattern.

[fantasai]

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]

@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]

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]

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

• xpointer registry http://www.w3.org/2005/04/xpointer-schemes/
• RDFa URL prefix / not really a registration, a shared space/community
• SSML pronunciation alphabet http://www.w3.org/2001/10/synthesis
• old micropayment names http://www.w3.org/TR/1999/WD-Micropayment-Markup-19990825/#Appendix%206
• webapp clipboard data type (sub mime?)

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

webauth may have need, see https://github.com/w3c/webauthn/pull/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)

[dwsinger]

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