A Touch of Class

W3C Process Potholes

In my previous post I discussed how the CSSWG operates. I left out any discussion of problems with the W3C Process.

Speaking as an active member of the CSS Working Group, and someone who has driven the REC-track progress of quite a few CSS specs, I see value in many of the practices that we adhere to, and don't feel a need to completely overthrow the existing process. However, while I may have more patience with the W3C Process than the entire WHATWG combined, I do have a couple points of frustration:

• There is no way to edit a Candidate Recommendation in place: applying errata requires dropping down to Working Draft first and re-issuing a Last Call for Comments, even if the module's actual level of stability has not changed. (The CSSWG has been forced to do this many times.)

  A Recommendation can be edited in place (i.e. without falling backwards along the REC track). A Working Draft can be edited in place. It should also be possible for a Candidate Recommendation to be edited in place, rather than requiring it to slide backwards into Working Draft in order to apply errata. Not only is the current process of publishing Yet Another Last Call in order to fix problems ridiculous, it doesn't communicate the true status of the document or the nature of the request for comments.

• Because of the overhead to publishing updates, the official specs hosted at www.w3.org/TR are usually significantly out-of-date and therefore unreliable—to the point that these ostensibly official specs are unused by most people working with the specs: the effectively official version of these specs (according to a their WG's acting policy) are hosted elsewhere than W3C (as “unofficial” Editor’s Drafts).

  W3C needs to accept live updates to its official Technical Reports. I'm not saying snapshots shouldn't be required (that's a separate consideration) or that groups that prefer to work under the current model mustn't do so, but that W3C must accommodate live-edited specs because publishing the actually-used version of these specs in unofficial dress and outside the official W3C specification spaces is totally dysfunctional, and this needs to be fixed.

Solving these problems would increase the fidelity with which the W3C—and thus the CSSWG—communicates the status of its work. It should also reduce the overhead of working within the W3C Process.

Proposed Changes to the W3C Process

Aggregating some of the obvious suggestions to the Process, I would propose:

Reliably Up-to-date Technical Reports

Allow and arrange for automated checkout of a tagged branch of a spec off dvcs.w3.org onto /TR/shortname/. Each WG gets to decide its policy of when to push changes there. For example, a WG could

• Adopt the working policy that only periodic snapshots posted to /TR/ are official. (Some groups still work this way.)
• Allow editors to directly live-edit /TR/ and declare the current live version official. (HTMLWG more or less works this way.)
• Do something in between, like directing straightforward error fixes to a /TR/ live-edit stream, and directing more experimental changes to the spec (or partial rewrite checkins) on an editor's draft branch for further review/revision before pushing to /TR.

Whichever way a WG chooses to operate, the copy on /TR would be able to stand as the official spec in both name and actuality, and the "Editor's Draft" would be freed up to fulfill a more appropriate role as scratch space.

Snapshots as Calls for Comment

Continue to require dated snapshots as necessary and/or useful. Keep a link to the most recent snapshot, at the top of the undated copy. Call these snapshots "Call for Comments" and encourage WGs to use their publication announcement to reach out and solicit reviews from the broader community.

Editable Candidate Recommendations

Allow errata during CR. Create a "Call for Errata Review" phase, initially identical to LC, but with the focus on reviewing the changes. Streamline the process as we gain experience with it.

Earlier Patent Protections

Investigate shifting patent protections from REC to CR, as suggested by Anne at TPAC. This might require tweaking the process; for example, having the previous CR phase split into a 6-month probationary phase and post-probation patent-protected phase, which takes effect once all requisite legal and W3C-oversight reviews are completed.

PR and LC as Transitional Phases

Allow REC to reference CR, treating PR as a transitional phase just like LC, rather than as another level of maturity. See the CSSWG's view of the W3C Process.

An Historical Note on Editing CSS2.1

The inability to make corrections to a Candidate Recommmendation is why CSS2.1 cycled so many times between CR and LC, and why Selectors Level 3 spent so many years as a Last Call Working Draft when it should have been labelled Candidate Recommendation. Due to the excessive overhead of maintaining a CR, the CSSWG finally decided to institute an errata system for handling changes to the CSS2.1 in its Candidate Recommendation phase, even though this is technically not allowed by the W3C Process. We did one last cycle through LC before publishing PR in order to satisfy the W3C Process as we formally incorporated the “unofficial” errata.

Process vs. Publication

Imo, W3C's most dire problem is its publication process. The pages at www.w3.org/TR are supposed to host the official, current W3C specs. In reality, these snapshots aren't current, and the trend is that more and more, everyone is referring to the officially “unofficial” editor's drafts, which are hosted in myriad locations under myriad publishing systems—basically, anywhere that is more convenient than www.w3.org.

The W3C website's authority as the place for W3C standards is almost entirely dead. Not only does this make the standards harder to locate, and their status harder to discern, it subverts the Process. An editor might post a proposal as an Editor's Draft for discussion in the WG, and it might not be approved by the WG for FPWD for good reason, but the public at large will treat it as an official standard, because everything else that is an official standard is also an "Editor's Draft". We already have this problem in the CSSWG: we want to work in public, but we do not have the ability anymore to distinguish official publications and unofficial doodles. As a result, people (implementers!) interpret unofficial doodles as officially-blessed drafts.

This isn't a problem with the W3C Process. It's a problem with the publication process. Some people think it's a problem with pubrules, W3C's publication rules. But pubrules only requires a few things, mainly that the document validate, that it have no broken links, and that it follow the W3C template, all of which are reasonable things to require of a publication. The problem is that it takes (the CSSWG, on average) a week to publish something, due to the multiple handoffs across timezones, limited publication windows, and manual procedures required.

W3C is running out of time to solve this problem, and it must solve it if it wants its website and its Process to remain relevant. I'll posit that if W3C can't reduce the publication overhead of a validated, link-checked document to 5 minutes total with maybe 15 minutes wait time, it's lost the ability for /TR to remain current, and thus the ability for it to remain relevant.

Snapshots vs. Live Specs

W3C's publication process is designed around “snapshots”: each update gets its own dated URL and is accompanied by an announcement. When this process was set up, the expectation was that a Working Group would operate in Member-only space, and publish a single public document for review every 1-3 months. These days most Web technology WGs operate publicly, and many work on multiple specifications simultaneously. The “Latest Version” for these groups is in reality the public editor's draft, which is edited live.

There are some benefits to the occasional-shapshot approach:

• It provides an easily-accessible way to step backwards through time and compare the current version against the last version that one has already reviewed.
• It groups changes into chunks, so that people who are not glued to the CVS ticker can review substantive changes in logical batches.
• It provides the opportunity to create and publish digest announcements about changes to the draft and what the WG would most like comments on.

Breaking the development up into such cycles helps people who aren't following the spec and it's changelog on a daily basis to remain involved and be able to track the spec's development at a coarser level. In the CSSWG, publishing such a snapshot also forces an internal review, which helps keep everyone involved and up-to-date on what's happening in areas they aren't following closely. We have a lot of specs, and this forced internal review is imho very important for keeping CSS self-coherent. I think therefore it's useful to coalesce changes into a periodic "Call for Review", complete with announcement, as we're currently doing. But I don't think the latest "Call for Review" should be called the "Latest Version", because it's almost always not the latest version. And I think the real latest version should be a continuously and definitively up-to-date one served at an undated URL on /TR. (As a side-effect, this would free up the editor's drafts to fulfill their original role as public doodle space.)

I'll note that some groups will still want to review the output of an editor before it goes live onto www.w3.org, and will thus maintain a separate internal editor's draft, under the current process. That's fine. Some groups (e.g. HTMLWG) will want all of the editor's changes to be live immediately. The live /TR copy will thus replace the editor's draft. And some groups (maybe CSSWG?) will leave it to the editor's judgement, with reviewed or obvious edits going live immediately, and speculative edits being posted to the editor's draft first for review. If the system can handle a live spec under the editor's control, everyone can be satisfied.

But if it can't handle live specs, then /TR will die for everyone except lawyers.