Skip

Continuous Specification Development Process for W3C

See meeting agenda

Video

slides - minutes

Video hosted by Web Castor on their StreamFizz platform.

Transcript

Philippe Le Hégaret: Thank you for surviving TPAC so far.

So yes, there has been a lot of talks about modifying the process and improving how we do things and this is what we're going to talk about today.

So there is a lot of materials. Those slides are going to be presented as well to the AC in more depth tomorrow.

There is also a breakout session at 4:30 this afternoon about process 2020 that this is part of one of the proposal as well circulating.

But if you have questions, don't hesitate to come to us as well.

So in terms of background, we've been talking about improving the Recommendation track for quite some time already.

Maintaining technologies, web technologies is quite difficult. It's a never-ending task: we can always find one more bug in our specifications.

And also shipping Recommendation by itself, where you need to have all of the features in the Recommendation at a stable state is quite difficult to pinpoint in time because you keep working on it.

Fixing bugs while you produce your Recommendation afterwards is also bothersome. Multiple transition requests and TR publications triggers a lot of overheads that we're looking to avoid.

Patent commitments has been an issue for some time in the consortium because even though we send a call for exclusion along the right tracks to make sure that the technology remains royalty-free, the commitments get only settled in once you publish your Recommendation, which means for groups who work for years on a document, they have no guarantees that it would become a Recommendation. So we need to provide our guarantee in the process.

And several of the working groups have been handling registries as well, and so the Process CG has been spending some cycles on that.

To guide us in those thoughts by the way, or at least this year, the W3C and the WHATWG reached an MOU: Memorandum of Understanding which has provided some of the thoughts in our discussion on how we can approach the concept of continuous standard development consequently.

Our use cases are quite wide: we have vocabularies in some of the groups, like, I can think of DCAT for example, we have mappings in the ARIA working group that they would like to also be able to update with a more flexible way, registries, profiles.

A lot of groups are struggling with maintenance, continuous enhancements, and rapid development of their specification and tracking all of those changes as well, including with all their standard organizations and organizations involved in developing web technologies as well.

We have plenty of working groups interested in this. I listed 11 of them here - I wouldn't be surprised if I'm missing five or six of them that are also thinking about this - going from ARIA, SVG, Web Application Security, all the way down to potentially CSS.

Fantasai and I had been talking to some of them earlier this week, by the way, the Service Worker Working Group, Web Performance, Web Applications Security, if you're a working group Chair and you want us to stop by your room later on, don't hesitate to ask as well.

So on the goals of the exercise has been really:

In terms of design, the Advisory Board of W3C has resolved to attempt to include this continuous development as part of Process 2020, so we are on an accelerated timeline on this.

The overall thinking right now, as far as I, and I can change opinion tomorrow for sure, is that the preference is towards fixing the Recommendation track rather than doing a parallel one, and continuously do a set of incremental improvement to the Recommendation.

And on that, I will let Fantasai present you the proposals.

fantasai: Hi, I'm Fantasai, and I'm a 15 years editor in the CSS working group.

We're gonna talk about what we're proposing for fixes to the Recommendation track.

What we're proposing is a set of fixes, so it's about, let's see, six separate things that can be taken either separately or all together as a package.

I would recommend taking it as a package that gets us the most benefits, but we can go through each one to understand how it improves the Recommendation track.

The first one is we would like to improve the Patent Policy for W3C.

As Philippe mentioned, the licenses for our royalty-free specifications are not actually available even if they have been committed to, until the specification reaches Recommendation status.

What we want to do is to pull that earlier into the process, because at that point, you already have implementations, you may have had implementations for, in some cases, 10 years, and none of these are really covered by any royalty-free licensing until the specification reaches Recommendation which requires implementations.

So the proposal that is to adopt more of a WHATWG style licensing policy, also similar to the community groups at W3C, where each contribution comes with a license for that contribution, and we sign off on the full specification by all working group participants, which is what currently happens, but the license becomes active at the end of the exclusion period, right now, at the end of the exclusion period, all you get is a promise of a license.

So some of the key questions we have are largely to the AC:

So there's an active AC survey open on the patent policy, there's been a handful of replies, we could definitely use some more.

And then, another question is also that we haven't asked formally yet but should think about is: when do we apply full specification licenses? Do we want to do that only at CR or do we actually want to do this on working drafts as well?

The next fix is streamlining routine Candidate Recommendation update approvals: so in order to get a Candidate Recommendation from working draft, you go through a transition discussion with the Director to get the Director's approval to demonstrate that you have addressed your issues, that there are no formal objections, that you have solicited and received review from a wide community of people and not just the handful of people in your own working group.

That transition is also repeated: every time you update the Candidate Recommendation, we check your work.

So there's a fair amount of work involved into preparing for a transition and also executing it. It takes a few weeks because this involves people to take a look at things.

Having oversight is not necessarily bad, but there's a lot of cases where it's very straightforward: all the issues were addressed, everybody, all of the commenters were satisfied and there were no new features added. Like the easy cases, we want to make those more automatic so it's really just if you satisfy the easy case box, then the Director doesn't really need to look at it because there would be nothing to look at anyways.

So one proposal is to streamline that by making it a little bit more automatic, and then that will make it easier to publish an update to a Candidate Recommendation.

Another proposed fix for improving Candidate Recommendation phase is to decouple the concept of updating with the kind of transition process and patent review commitments process.

So we would split Candidate Recommendation into two types of publication:

That would basically correspond to the way a lot of working groups are working today in Candidate Recommendations status where you have the Candidate Recommendation on the TR page which is the official legal draft, but then the actual work is happening in an editor's draft and the implementers are all looking at the editor's draft.

We would like to eliminate this dichotomy of drafts that have the draft that W3C says you should look at be the same one that the working group thinks the implementers should look at, and by allowing easier updates to the Candidate Recommendation, that would make that possible.

Another problem we've run into is that modifying Recommendations to fix problems in them is quite onerous: you have to take the specification all the way back to Candidate Recommendation and redo the entire process from there.

This results in poorly maintained Recommendations and a lot of work for the staff and the working groups.

So the proposal we have is to allow working groups to inline their errata.

So if I have an error in the definition of the current color, keyword in CSS, then I can add a box or something, some annotation that says we're proposing to change this definition to the following, and that can just be updated in place on the Recommendation.

Well, you get a new date on it, but there's no approval process to publish those annotations and that allows a broader review of the proposed changes because they're now inline in the specification, and it also allows anybody who's implementing to see that that change has been there. And then once you have the two implementations and you have gotten some review on it, then you would issue a call for review of the proposed changes.

You can do all of your proposed changes or some subset of them, send that for review by the advisory committee, by the lawyers and everyone else to just to kick of the CR and PR, all of those processes together on the changes in the context of the specification. And once that review period is over and everybody says yes, it looks good, then you can fold that into the Recommendation and update the Recommendation.

And then for groups that want to be able to keep a Recommendation that adds features, one thing we can do is to reuse this process for proposed additions where you would annotate the proposed addition and use the same process essentially to make an addition to a Recommendation.

For clarity's sake, we are saying that if you would like to be able to do this to your Recommendation, your charter needs to allow that and it needs to be explicitly noted on your Recommendation that this isn't some kind of extensible Recommendation, we can pick what we wanna call that, so that people know that this is not the typical Recommendation where the feature set is stable.

Because there are some communities which need stable feature sets for their Recommendations and others which want a continuously evolving feature set, so in order to make sure that both people know what they're getting, we want to make sure that that's clear in the status section of the document.

Then the last fix we're proposing is to actually add a dedicated process for registries.

The registry would have a definition that defines the types of information that go on the registry, and what the process is to add or modify or delete them, and any other policies that are required for each edit to a registry to follow.

That definition will go through review and approval and the registry tables which hold the actual data in the registry, those can be updated continuously by the working group or by a custodian that's designated by the working group, so long as they follow the process that's defined in the registry, so then that would allow continuous updating of the registry tables without any extra overhead by W3C to check what's happening there.

We just assume that if the process in the registry definition has been followed, then that's adequate for whatever that registry is, Since different registries have different levels of checking and different process and different restrictions, we can't really make that an official process.

And so the registries would be published on the TR pages just like any other technical report.

You will not get IPR commitments on the actual updates to the contents of the registry tables because they're not going through any kind of exclusion period or any kind of patent review so that you can update them immediately but you can publish them instantly just like a working draft otherwise.

So that's the proposal for registries and this is a summary of what we are proposing as fixes to the Recommendation track for Process 2020.

Philippe Le Hégaret: Thank you, Fantasai. So in terms of what it means for folks, the impact on working group is that it should provide them an easier path to maintain their Recommendation for changes and addition of new features in their Recommendation.

It allow us to basically keep Candidate Recommendation in full sync with the latest thinking from the working group without having to jump hoops with the director.

And last but not least is securing the patent commitments earlier than the Recommendation status which is most important.

There are some implication for legal and the AC which I'm not going to go here today, but we'll certainly go tomorrow.

The implication for the horizontal groups is the horizontal groups are already under heavy loads for reviewing documents.

This has a potential of increasing the frequency of review requests they receive even though it doesn't increase the number of changes they have to look at. But context switching is quite costly for horizontal groups.

And here, the key is gonna be to improve all toolings, to help them focus on what's important and not be too distracted as well. There is a separate conversation with the horizontal groups to improve how we do it without having to modify the process.

And impact on implementers and users overall is that it gives guarantees to implementers for all the implementation because they get the royalty-free commitments. For their point of view and the user point of view is you get related to working groups seeking published on W3C website as well and if we can keep our Recommendation up-to-date and closer to reality, that's also appreciated as well.

The alternatives to changing Rec track and potentially going further is to provide an alternative track which has been known for some of you as Evergreen. This is a proposal which has been worked as well as part of the CG.

And part of the concern to do this alternative track was, well, can we change the patent policy for the Recommendation track?

Are we willing to change the Recommendation track and make those substantive changes?

And also, as well, can we streamline horizontal reviews more by allowing for continuous developments and continuous review?

At this point, there are two main reasons to adopt this alternate track.

Of course, the devil is sometimes in the details, including the idea of those TR dates is quite a new idea which was proposed, what, three or four weeks ago, so it hasn't been fully discussed and reviewed by the Process CG as such.

But this is a proposed addition to do Evergreen Recommendation which is an alternate track which could be confusing for some.

I am not going to go into the details of this alternate track, assuming that if we are able to change the Recommendation track and it satisfies everyone, we may not need to provide an alternate track at this point.

But it also certainly has benefits, alternate benefits as well compared to changing the main Recommendation track. In terms of next steps, so we've been going around working groups asking them, are we fulfilling your needs, including going to the horizontal groups as well which are more concerned about the tooling aspect more than anything else.

Can we get editors to provide meaningful change log so that when you produce a snapshot for the IP lawyers to look at, they can actually understand the implication of your document as well and would those proposal lead to easier ways to maintain the registries on that?

We also have questions for the AC as well.

There is an ongoing survey happening until the end of this month: tell your AC rep to actually answer it if that hasn't been the case already.

The proposal right now is to commit, to get commitments as early as CR: do we need to go even beyond that and get those commitments during working draft? That's certainly one of the open questions.

I should stop here. We don't really have time for questions but as I said, there is a break-out and later on, feel free to come or come and talk to us as well.

Oh, we can take some questions, maybe one or two questions, if people have questions at this point. I apologize, we went fast with those materials. I realize it could be very easily overwhelming for everyone. We didn't even scratch the surface, we just barely scratched the surface here.

Fantasai: I wanna talk a bit about what the thinking was to bring this all together.

One of it, briefly, is that we wanted to have the continuous, the ability of the working group to do continuous updates, but we also wanted to make sure that there are points at which their work is being checked to make sure that they're not forgetting anything, that people aren't being overlooked or ignored.

For Recommendation status, we wanted to make sure that any changes were super clear that they get the wide review and implementation experience that are required.

And the Recommendation status is formally recognized by other organizations, it's adopted by national standards, some Recommendations are incorporated into legal codes.

So we need to make sure that whatever stability requirements they have gets maintained.

With Candidate Recommendation, we have a bit more flexibility for these kind of things.

We're trying to bring together all of these requirements and try to make a process that makes it easier for working groups to operate that maintains the kind of reviews that need to happen to make sure that we maintain the quality of our specifications, and to provide a framework for development that is flexible enough that working groups can operate in different ways, but also has enough structure to it that working groups who are new or inexperienced or who have a lot of conflict have some ways to hold everything together and make sure that it all moves forward together consistently.

Skip

Sponsors

Platinum sponsors

Rakuten Institute of Technology, Coil
														    Technologies, NTT

Gold sponsor

Panasonic

Silver sponsor

Yahoo! Japan WebCastor

Gift sponsor

JCB

Bronze sponsors

Newphoria, JPRS, Kodansha, Hitachi, Shueisha, Media Do, Sony, Igalia

Friday Coffee sponsor

SoftBank

Network sponsors

NTT West, Cisco, NTT Communications

Support TPAC 2019 and get great benefits from our Sponsorship packages.

For further details, contact sponsorship@w3.org