One of the things that takes a lot of time on the W3C REC track, and make people wish for some more agile way such as evergreen or living standards is the act of publishing itself.

Thanks to Echidna, publishing a Working Draft is fine, but otherwise it takes a lot of time. Here are a few recent examples, from the W3C’s Github repository for handling transitions, about specifications I had been following or been involved in one way or another:

• The CR transition for CSS Easing Functions took 26 days.
• The FPWD transition for CSS Spatial Navigation, took 18 days.
• The CR update for CSS Containment took 14 days.

My point here isn’t to put blame on anyone, but to highlight that we have a major bottleneck that introduces weeks of latency into the pipeline. This is something we badly need to improve on. Incidentally, this isn’t something that would automatically be improved by the tooling changes that have been discussed for evergreen. In addition to being a regular source of frustration in Working Groups, this puts the REC track at an unnecessary disadvantage compared to the WHATWG process, the proposed evergreen track, or even to keeping things in incubation forever.

The checks that occur at transitions are nonetheless valuable. This is where we verify and enforce the criteria — such as wide review, or implementation experience — that we have collectively deemed necessary for that specific level of maturity. Even if individual specification writers could follow the same practices on their own without the Process forcing them to, these institutional checks are what makes specifications be Standards, and not just someone or some company’s possibly good idea. Nonetheless, the way we currently do these checks is heavy, and that must improve, lest we tempt people into doing away with the checks entirely.

I don’t mean we should try and go from an average 19 days (or whatever the average is now) to 11 days (or some similar better but similar figure) by nagging the W3C Team more insistently. I mean to try and go from many days to 0 days most of the time, by changing the way we approach the problem. I think we can fix this without any change to the Process.

Here’s one possible approach:

1. For each type of transition, document the criteria for automatic approval. This is expected to be stricter than the criteria defined by the Process: there are cases where a judgement call is needed, and where the Director and his delegates will want to exercise judgement as to whether the criteria are fulfilled (e.g. “we don’t have two implementations, but in this case, it’s ok because…”). However, there should be a large enough subset publications that are routine, and that can be approved on the basis of a check-list.

2. Turn the check-lists for each transition into online forms. For each criteria, there should be a checkbox, and a freeform text field to register (for the record) evidence in support of the criteria being fulfilled.

3. Hook these forms into Echidna, so that when you try to publish something that involves a transition, Echidna gives you a link to the relevant form. Some of the criteria (e.g. passes Pubrules) can be determined automatically, so they should be, but the result should still be indicated in the form, with a text field to give an opportunity to explain any anomaly. For the rest, the person requesting the transition ticks the boxes and fills in explanations and supporting evidence.

4. If they cannot tick all the boxes, they can still push a “request evaluation by the Director/Team” button, and we fall back to the same approval process as today, except everything is in structured data fields instead of freeform Github issues, and Echidna is still in the loop to publish instantly if the Director approves, instead of a manual handoff to Team contacts who may not always be instantly available.

5. If the they are able to tick all the boxes, all the information provided is archived somewhere public, and they get to bypass the Director, and publish directly. Possibly, if we want a little bit of verification, we could send automated notifications to the chairs and team contacts of the relevant WG and ask any of them for approval, but the question would merely be to verify that the information is truthful, it wouldn’t need to be the kind of judgement call that the Director makes on actual transition calls.

6. Done! Echidna automatically handles the rest.

For sure, this description is insufficient, and to implement a system along these lines, we’d need to be a lot more specific about what the requirements are; but hopefully the general intent of such a system is clear.