Closed joanmarie closed 4 years ago
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?
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.
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.
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.)
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.
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.
@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.
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?
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 .
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.
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
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.
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.
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.
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
@dret Thanks, Erik, this is really helpful.
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.
The Revising W3C Process CG just discussed github: https://github.com/w3c/w3process/issues/79
.
The Revising W3C Process CG just discussed IPR of Evergreen
.
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.
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.
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).
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.
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!
@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.
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.
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
@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.
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:
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 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)
This issue was forked into Ever and Registries. Registries have other issues such as #168 , and Ever is handled in P2020. Closing.
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:
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.