W3C 2020: Living Standards and Reviews
Facilitator: Philippe Le Hégaret
This session will decrypt the new W3C Process to helps editors and participants find their ways. It will also give the latest information on how to do wide reviews and transitions.Minutes (including discussions that were not audio-recorded)
Transcript
Good morning, afternoon, evening, everyone.
So in 2020, W3C, after two or three years of conversations finally published a new process which supports living standards.
Which is a significant change for W3C.
So, I wanted to come back to that.
If you participating in a Working Group, what does it mean for you?
But I also wanted to talk about reviews.
We've been increasing our offices on wide reviews and our understanding of how those are getting done.
So, what was wrong with the previous process?
And nothing really was wrong with it, it was just that it was just too limitating for us.
We have a lot of Working Groups and they come from different horizons.
They have different, they addressing the needs of different communities, and we wanted to expand what the process allowing Working Groups to do on the recommendation track.
So with the previous process, if you wanted to make a substantive change or addition to Recommendation, you were required to go back in time," in the sense that you were required to go back into the previous stages. Either Candidate Recommendation known as CR or First public Working Draft all the way to the beginning of the right track D. What is known as FPWD. Another problem was we have a lot of long running specifications, specifications that could take years to bring to recommendation. CSS has a long list of those, another well-known one has been WebRTC, where WebRTC started seven or eight years ago, and it is still not a Recommendation.
And with the previews Patent Policy, the Royalty-Free commitments were only settled, once you were becoming a Recommendation, meaning you are guaranteed to have a warranty free license, only the document was a Recommendation, but not before then. So for a document that was being developed over the times, and we had multiple implementation that was not great at all.
Then we, we changed our understanding, our approach to specification. And there was a time we, I would say we moved away for a bit, from writing the specifications, just for users in general, but more writings of specifications for implementers. And it's always a balance we never get it right and we'll probably never get it right either. But the fact he is nowadays, if you read a lot of specifications that are deep into the web platform stack, you will see a lot of algorithm and those need constant maintenance and updates, consequently. And it was very important that people look at the latest version of this to make sure that they were looking at the latest version of this. So any delay in publishing and updating the document in /TR, wasn't desired. It led to a lot of confusion, "which document do I need to to look at?" and so on.
And, plus on top of that, you know, some groups are good at maintaining building consensus and testing into their editors draft. By construction, they only merge changes to their editors draft if it has a consensus of the Working Group. So they fulfill a lot of the requirements that are on the Rec track. But they were not updating /TR on because it can take months. And again, it was creating confusions as well. You probably have heard and still hearing, unfortunately, a lot of "don't look at the documents on w3.org, look at what's on the GitHub instead in w3c.github.io, because that's where all the editors drafts are nowadays. Most of the editors draft nowadays are.
So, today we have 37 Working Groups and they all have different standard stories. If you go and talk to them, which I do, you will hear different needs and different stories. They won't hear the word Recommendation in the same way.
Some will say we don't need Recommendation because we're doing a pure living standards, our spec is changing all the time. And yes, some part of the spec are stable, some parts are unstable, and it's very difficult to pinpoint a point in time where the spec is actually stable as a whole. A good example of that has been the Service Worker specification that we've been struggling for the past two or three years to pinpoint a point where in time where we can say, "Okay, this is a spec now, let's make it a Recommendation." Despite the fact that we have all of the testing and everything, SVG has been long running - SVG 2, we'll probably - with the level of resources we unfortunately have in the Working Group - we probably won't have, won't issue a Recommendation of it at the moment.
So if you take you as another spectrum, we have groups like the Accessibility Guidelines Working Group, that is, where the document is being referenced in regulation. So they cannot simply update the document at all time, because this is not how regulation work. So they need to have Recommendation settled in stone, stable and long running. So for example, we are in the progress of superseding WCAG 1.0, we have two Recommendation on our website in addition to that 2.0 and 2.1. And despite the fact that 2.0 was published several years before 2.1, we are still not going to supersede 2.0 because it is still being used out there, and linked to.
So those, I would say the two extreme cases between like service worker and the WCAG documents.
And then you have, documents that are in between, they are like happy to publish Recommendation, but they also keep working on the specific issue on the side. So they always ever the next version in the pipeline as they are finishing their Recommendation of the first one as well.
And if you even look at the level of implementation, it varies quite a lot as well.
Some draft, like Working Draft will have no tests or implementation commitment.So, they are just pure working in progress.
Some on the other hand, has tests and implementation commitments. So they are much advanced on those (indistinct)clear. So they may again fulfill criteria that are expected later on in the Recommendation track, where they are fulfilling them much earlier and no one asserted that, at least not the director.
So, nowadays what we do, is we do obsolete automatically and supersede once a Recommendation is produced anyway, if the Working Group tells us to do so, but we still have a lot of... The story could be confusing for the outside participant.
So when we look at all of those issues, we had to make a bunch of trade-off with the values. At the end of the day, if you compare an editors draft, which hasn't been published on /TR, or document in a Community Group for what it's worth, compared to a Recommendation, the set of qualities are substantially different:
- we expect adequate implementation experience for Recommendation, we don't expect that for a Community Group; and we expect to have some way to actually check this are the adequate implementation experience using tests and so on;
- And so it has been reviewed by the director, the director checks that indeed the Working Group fulfills the criteria, the AC had a chance to review it as well as a well as a whole;
- we've been securing their one Royalty-Free on a regular basis and therefore once it's Recommendation, it's Royalty-Free and so on.
So going through all that list of values, which again some of the Working Drafts or even committee group reports already fulfilling - it's just that they were not checked on - we had to make some trade-off.
And these bring us to the Process 2020 Recommendation Track.
So the new process is in effect since mid September and all of the Working Group as of today are operating under this new process. They were switched automatically to this new process. We do not have Working Group operating under the old process anymore.
So one of the goals is to basically allow the Working Group to map what I would call their standard stories , to which they want to fulfill for their community, to the new Recommendation track.
So if their community expects to have the latest and greatest and the living standards model is what they would like, like the service worker Working Group, they can do so.
And on the end of the spectrum, if they still want to add the well-established standards, very in fact what was done in the previous process, they can still do so, they don't have to change anything.
And one of the big advantage of this is we updated the Patent Policy as well and we can secure the Royalty-Free commitments a lot earlier in the Recommendation track and just at Recommendation time - and I'll come back to that.
And so we need some subtle balancing of what was the values from the previous process to embracing the new values.
But one important thing to remember, is if the previous Recommendation track was working for you, you can still do it. You can, that's still an option. You do not have to change anything. And we do expect some groups to not change anything.
So as I just mentioned in the previous slide, we had to secure the pattern Royalty-Free commitments earlier , which required for the first time a major revision of the Patent policy, which we achieved.
As of today, we haven't switched all of the working groups to the new Patent policy, because it requires an explicit acknowledgment from the organizations participating in the Working Group. Only the new charters that are approved by the director since mid-September are under the new new Patent Policy.
For the other ones, we have a transition plans, where either they are about to get rechartered anyways, therefore they will be switched to the new Patent Policy as part of their rechartering or if they are beyond the March, 2021, what we are going to do starting next week is to query the team contact and chairs of working groups to ask them if they are interested to switch to the new Patent policy.
And assuming they are, we will switch them to do so on December 1st, asking the organization to rejoin; if they are not interested, they will stay under the old Patent policy until their current charter expires. And at that time, the new charter will be required to use a new Patent policy.
So I expect, for example, the Payments Working Group to stay under the old Patent Policy for the time being because the process for rejoining is quite costly for them. And they probably may not be the only one.
We do wanted to keep enforcing the checks on wide and horizontal reviews - wide review is a fundamental value of our process. And I'll come back to on more details on that.
But when we issue those Royalty-Free commitment request during the call for exclusions and at the end of the call for exclusion, this is where they are set in stone. But before doing so, the director gets to check to see if there was proper wide and horizontal review done.
It does not mean that all of the issues would have been resolved, but depending, like if you are still, for example, in First Public Working Draft or Candidate Recommendation Snapshot, but it does mean that we are looking into that.
So we can fairly enable the living standards model without preventing today's workflow for the Working Groups that are still relying on Recommendation.
And another advantage of those changes has been that we're no longer forcing specifications to go back in the previous stages and they can update the recommendation directly. And again I'll come back to that.
So all in all, this allows us to actually be a lot more agile and answer the needs of the Web.
So, if you look at the recommendation track of 2020, this is what now it looks like:
- Where you have at the top, you have the five known stages, the First Public Working Draft, the first time they're working to publish it;
- then you have a series of Working Drafts that are being published, which could be zero or more;
and, then you have what we call the Candidate Recommendation Snapshot - so the first Candidate Recommendation being published is automatically a snapshot, and this is reviewed and approved by the director, this publication.
And then the Working Group may update this snapshot, may publish interim phases, by the way, called Candidate Recommendation Draft at their will. There is no check, so they can maintain the document in /TR by just simply deciding to do so on their own.
We do expect those group to publish a snapshot between six months to two years, in terms of frequency. Less than six months is not desired because we do not want to flood the IP lawyers with call for exclusion request.
Every time we publish a Candidate Recommendation snapshot, we do issues with calls for exclusions, securing the Royalty-Free commitment at that time.
- And if the Working Group is interested in publishing Recommendations, they can move to Proposed Recommendation as long as they haven't made any substantive changes since their previous publication in /TR or otherwise, they would be required to produce a new snapshot before doing so, so we can actually issue the call for exclusion properly.
- Then they are in the normal cycle, Proposed Recommendation → Recommendation.
Now on the right side of that graph, you have the other side of the equations in Process 2020, which is how to update Recommendations.
So, as I said, previously, we were forced to go back in previous stages in the past, if you were making substantive changes; this is no longer the case.
You can actually update your recommendation by making Candidate Changes into the document through annotations, where you are basically exposing the type of changes you would like to do to the rest of the world.
And when you believe that those candidate changes are actually ready to be integrated into the Recommendation, you republish the document again, but this time you make them to be Proposed Changes.
When we see a Recommendation published with Proposed Changes, we will issue a call for exclusio n and an AC Review of those proposed changes.
So we are merging into one single operation, everything, every requirements that were required by CR and Proposed Recommendation, meaning we're going to expect at the end to see adequate implementation experience, that the call for exclusion was done properly, and that AC review was also done properly.
If everything goes well, the Director allows the Recommendation to be republished yet again, but this time, they're no longer Proposed Changes, they are folded as part of the normative part of the specification. And, you can go through this cycle endlessly, so you can have, what I call Living Recommendation if you want to.
One note however when you do that, if you do have new features, The process is clear that you can only do so if you were allowed to do so by your own Proposed Recommendation. So now when you switch to Proposed Recommendation, we will make sure that you understand that if you want to update later on the Recommendation with new features, you should say so when you reach Proposed Recommendation and like that, it gives a chance to the AC to comment on it as well.
But if you were allowed to do that, by your own Proposed Recommendation, then your proposed changes can include new features. If this is not the case, you're going to be requested to go back in previous stages, to go back to First Public Working Draft.
So at the end, what you have is different models and keep in that can be combined. One model does not necessarily mean that you cannot use the other one.
So the Living Standards models, what I would call the Candidate Recommendation forever, you publish your First Public Working Draft, and you may publish a series of Working Groups in between. And then at some point you're going to produce your Candidate Recommendations Snapshot, and you keep updating it through a series of Candidate Recommendation Draft and Candidate Recommendations forever.
So this is very similar to ,of course, to the, WHATWG model, which publishes snapshot every six months of the documents for what they call the patent review draft, and otherwise, the spec is kept, is being kept updated at all time. And so that's what this model is based on.
The old model, which is: We need to have a stable reference and we want versionings for the 2.0 and the 2.1 are two different versions, and they need to live in their own space and they cannot be superseded just like that, is still available, where you basically again, you go from First Public Working Draft to Recommendation.
And if you want to add a new version, you will go back, you basically go and publish a new document, starting from First Public Working Draft again, which is what will happen in the W3C Content Accessibility Guidelines 3.0, in this case.
But if you do want to be able to, if you want do want to update your Recommendation, instead of because you you're making some fixes or because really you want all of the value of the Recommendation, you want all of the assertion that the Director and the AC gods to review the changes and so on, you can do that by having a living Recommendation where you move to Recommendation and you stay in Recommendation forever.
And on /TR, you will always use the latest version of the Recommendation, consequently on that.
So as I said, it's possible to for example, to have living standards, and then from time to time, you want to publish a version. And so it's certainly possible to do that. Once you are in Recommendation, you can make substantive changes into your Living Recommendation if you want to - you can only again, introduce new features if you allowed yourself to do so at the Proposed Recommendation time.
But you can also decide to "no, we will go back and publish a First Public Working Draft for an entire new version".
So I want to talk a little bit about the versioning: first a reminder, the first bullet is we do have a document that talks about version management, where she reports to give some direction on how do we do that.
Every time we publish a new dated version of a given version, we automatically update in /TR nowadays, the previous, the old date, we use those warnings to say "watch out, you're not looking at the latest dated version of this document".
When you do publisher new versions, we may obsolete or supersede older versions, it's up to the Working Group to do so.
What we recommend the groups is that they actually write into their document, what is the relationship between this new version and the old ones. And if they do so, they do indicate that the new version is superseding the old one, we will highlight that fact with the AC; if they don't, then it's going to be up to them in the future to do so.
So right now, for example, we are running an AC Review to obsolete WCAG 1.0. because the Working Group asked us to do so, but we are not doing so for WCAG 2.0, because the Working Group still keep want to keep that version alive.
As a matter of fact, by the way, for the past three to four months our API, the underlying API that manages all of those data about those technical reports, understand versioning and knows that, for example, the pointer event specification has several versions. If you're clicking on that link by the way, it will provide a view of that information as exposed through our data. And we hope that the data is correct, but since we haven't exposed it very widely yet, you may still find some errors in those data and feel free to do so.
I provided a link at the end to where you can access the boards of follow-ups the Working Groups and you actually can check all of those information in those boards.
So on updating Recommendation, the process basically categorize more than three categories:
- The first one which has always been there is like if you have to make a markup change in your spec, the change can be done in place, we don't expect a new dated version. And all the thing that the Working Group has to do is to send the request to the webmaster.
- If you do make any editorial changes, we do expect a new updated version of the Recommendation, we will update automatically the previous one. But again, the Working Group can decide to do so, reach out to the webmaster to do so. It's relatively easy to do.
If you make substantive changes however, is that when it comes down to a little bit more trickier, because, we would expect, we would not expect you to make substantive changes directly into the Recommendation, of course, nor into a new dated version of the Recommendation, we expect them to be validated.
So we would expect you to publish, first, a new dated version of the recommendation with content a,notation for candidate and/ or proposed changes.
The candidate changes are changes that the Working Group is thinking about, but they are not ready yet to request, to be folded into officially as part as the normative part of the specification.
But the proposed changes are, they are ready and the Working Group would like the review. So for those, we would issue a call for exclusions. We would send an open AC review, asking the AC opinion about those proposed changes and would expect at the end all of that to see all of those results, and including if we have adequate implementation experience, like we would expect for a Candidate Recommendation, t the end of Candidate Recommendation.
And if everything is fine, after approval of the Director, you can basically incorporate the proposed changes that were approved directly into your new dated version of the Recommendation.
And you can imagine that the cycle is ending. In fact, as far as I know, nothing prevents Working Group to already include a set of candidate changes on the day they publish first Recommendation, ironically.
So a lot of the changes were driven with the need to, we need to make sure that the document in /TR are up to date. So we wanted a process and a tooling that basically allows us to do so very easily.
So as a reminder, we have a system called Echidna, which allow you to publish your document in /TR. And it could be, we have even a script to do so automatically on GitHub when you are merging changes into the main branch of your repository, if you want to do so. So we have a few documents that are, if you look at the editors draft and the version in /TR, they are pretty much exactly the same, except for the headers basically.
If you're not quite sure what to do, we have a step finder, where are you open it, you look for your document in there, assuming it has been published in /TR before, and it will tell you, depending on the stage you are at in the Recommendation track, it will tell you all of the options that you had available to update your document: either while staying in the same maturity level, or moving back and forth in the Recommendation track.
And again we would encourage the groups to update the Recommendation at all, pretty much the whole time using the Candidate Recommendation draft to not let /TR gets rotten.
So that's it for the introduction of what was introducing in the new Process and new Patent Policy on that.
Talking about reviews. So review is not new in the process. Nothing changed in the process when it comes down to review, really.
But on the other hand, the ways that we've been practicing the process has changed substantially in the past, I would say in the past two to three years.
Historically speaking, we have two groups who have been doing, for at least 20 years, Horizontal review quite a lot: those are the internationalization Working Group and the Web Accessibility, the Architecture and Platform, the Accessibility and platform architecture group, APA. So they have been doing what we call horizontal review.
And we stepped up our game substantially, thanks to Sam, on doing privacy and security reviews, we stepped up our game to do architectural review as well when the TAG was created several years ago, then they also have a proper workflow to do those reviews as well.
The first link on the first bullet, by the way, is a presentation done by Ralph Swick and Sam Weiler for the AC meeting. And I encourage you to look at that presentation as well.
It's very important for us to do reviews because the Web is for All and we want to make sure that it actually can work for everyone as well.
And everything has to be reviewed: any technical specification has to be reviewed first and foremost, all of the Working Drafts have to be reviewed and Richard Ishida and Sam Weiler have updated the wide review guide last month or so. And again, you'll find a link on how to do Wide Review there as well, but I weill come back to that.
I also encourage Community Group to request Wide Review. Not all of the horizontal groups will necessarily have the ability to do the review of the reports, but I know that the privacy interest group and the TAG are both more than willing to do reviews of Community Group reports when they see them.
So when do you do Wide Review? The thing to remember is the earlier the better. And the perfect is always the enemy of the good enough.
I've seen too many engineers, telling me that, "I still have one chance to do", "I still have one chance to do." And from months they are not going to request review, when I know very well that, if they do, they're gonna get to a bunch of issues.
And so do not wait to be perfect for your specification, because if you do so, you are guaranteed to be late. Because if you are getting a comment that is impacting your architecture, this is going to be painful for you to change, and this is going to be painful for the horizontal group to get you to change it as well.
So the earlier the better, do not wait. Again Community Groups may also request reviews: we've seen Community Group reports where some of the browser vendors are implementing alread, it's not even in under standard track yet or inside the Working Group, it hasn't been adopted by a Working Group. So I encourage those to review sooner rather than later.
If you made any substantive changes, since the last time you had a review, request it again. We will have ask you, the Director will ask you to make sure that any substantive changes to your specification got a chance to get reviewed. And if you didn't have a review in the past two years, even if your document did not change, request again. In the best case scenario, the horizontal groups and the community is gonna tell you, "Well, nothing is changed, there is nothing to redo." That's fine. In the worst case scenario, you may be told, "well, our understanding of this scope, of this space has changed substantially in the past two years, and you're gonna have to make some changes because what you're doing is no longer acceptable, or no longer the norm", I would say.
A good example of that is in the privacy space where our understanding of privacy has evolved substantially, in the past two years, and our expectations have been evolving again as well.
So how do you do a Wide Review? So again you to look at the presentation that Sam Weiler and Ralph Swick did for the AC meeting on that, but the short summary here is, first make sure that your Status of This Document does says that your document is ready for Wide Review. We do pick that up, in our tooling down the line, and we advertise those documents in the proper space to get the attention of the community and the horizontal groups on that. So that's why it's important to mention that in your document, even if it is only a Working Draft.
Another good way, by the way, additionally: you should look at your charter. Very often charters will contain dependencies either with W3C groups or with all groups like for example, if you are touching or expanding HTML, we're going to list the WHATWG inin the external group.
If you are working on WebRTC, it's very likely that you will see one or more IETF groups being listed in your charter as well.
And again, the expectation would be here that you actually reached out to those groups to make sure that they had a chance to review your document. And we would be looking for those things.
And more specifically, we always expect you to reach out to the horizontal groups: whether you are working on web assembly or Pointer Events, we will expect you to reach out to the Internationalization Working Group, to the accessibility, to APA as well, to the TAG and so on. Whether or not your document is necessarily touching on UI, or contain strings, we will expect you to reach to all of them.
Best case scenario, those group will tell you, "Yeah, we are concurred with you, there is nothing to review here, you're fine." And the check doesn't cost a lot of time as well. Most of those groups, by the way, horizontal groups, will have questionnaires to help you to self assess your specification as well, or the set of changes you want to be looked at. And so you can already provide those self-assessment to the horizontal groups to help them process your request faster.
In any case you must expect the Director when you need direct approval to move along the Recommendation track to make sure you offered a reasonable opportunity to the world to review your document. If not, we're going to tell you, "Yeah, you need to do a bit more work on that."
We are nowadays tracking horizontal issues: we have a board for that, which is actually we're using, underneath, we are basically using GitHub and GitHub labels to do that. So the board is only exposing information which exists into the GitHub repositories, so just a view of those information.
And we've been spreading for the past, I would say, eight to nine months, labels across the 285 repositories we know, as of today have, on the list to associate issues based on the horizontal dimension: whether it's I18N, privacy, TAG and so on.
So basically when you have an issue being open on your specification that you believe can be touching on internationalization, you should put a tracker label called i18n-tracker, and that will automatically show up in the radar, of the I18N Working Group, just to alert them that this issue was flagged for their attention.
The horizontal groups, however, they have a way to say that, "No, no, an issue is very important and it really needs a resolution." And that's where the "needs-resolution" version of those labels come into. So those are meant to be used by the horizontal groups, not by the other groups instead. So we would expect the horizontal group to set up the needs-horizontal-resolution. And that basically tell the Working Group, the specification impacted that, "yes, the horizontal group believe this is a very important issue that needs resolution." And that also tells the director as well - that also alerts the Director that, when you try to move forward, a specific issue is important, has been flagged by the horizontal group as important, and the documents should not be moving to Proposed Recommendation without a proper resolution.
So as of today, by the way, we are tracking almost 500 horizontal issues that have been made, are flagged on the specification. And the fun fact is yes, as of today, we have, we are tracking almost 13,000 open issues on our specification. If you don't know what to do over the weekends, we have a lot of open issues on a specifications for you to go through.
So facilitating transitions: so the transition requests are still unfortunately being tracked on GitHub, actually, no, fortunately they are still being tracked on GitHub.
We do not have yet, unfortunately, the proper form to submit transition request, nor Wide Review as of today. And consequently, we do not have yet the automatic transition way to be able to facilitate Director's approval, consequently.
But again, it's kind of like, unless you have formal objection, or needs-resolution, it's very likely that we would basically allow you, the automatic system will allow you to produce your Candidate Recommendations Snapshot without human intervention pretty much.
So finally, on more information, you always have the guides, please look at it, the "how to do a wide view" is linked to from it. There are a lot of links happening in the guide - I apologize about that because there is a lot of information.
We as a series of tools and boards and so on to basically keep track of our Working Groups, and you have the link to that. This is what the project management team, what I'm using as well.
When you're in doubt, always go to your team contact and ask or come and ask me as well instead of staying in your corner, we will always be happy to help you on that front.
And on that, it concludes the presentation part of this breakout session.
