Open sideshowbarker opened 2 weeks ago
@sideshowbarker, to facilitate discussions, could you explain the rationale(s) behind this proposal?
to facilitate discussions, could you explain the rationale(s) behind this proposal?
Sure. Here it is:
Last week, I had the fun experience of once again being on a WG call — and at 1am or 2am (or whatever) my time, which is also usually the case with these things… — attempting to explain CR transition to some members and chairs of a working group, some of whom had actually read some parts of Process document about transitions, some not.
And for the Nth time, I found myself needing to answer questions from WG members about things like:
Is a “CR” some different stage of publication than the very-similar-sounding “TR” in https://www.w3.org/TR/ and that they’ve heard me make reference to when I talk to them about “TR space”?
What exactly is a “Technical Report”, really? Why does that term exist? And how’s it different from the Working Draft publications the group has already done, or the Candidate Recommendation publication the group is planning to do?
At what point is a W3C publication actually considered a standard? If publications follow the “Recommendation Track”, than must a publication reach Recommendation status in order become a standard?
How can they publish a “living standard” or “evergreen standard” as a CR if the W3C Process says standards are published on the “Recommendation Track”?
It was extremely frustrating to see the confusion and consternation on their faces — and for this to be the Nth time in 17 years where I’ve found myself needing to do this — while I struggled to explain:
Why the Process doc doesn’t just use “publications” or something to refer to what it currently calls “Technical Reports” — since nobody, us included, ever otherwise calls our publications “Technical Reports”.
Why the Process doc seems to go so far out of its way to avoid just using the term “standard” — since we otherwise talk so much about “standardization” and the “standardization process”, etc.
For better or worse, I ended up telling them that they might be better of not trying to read the Process document itself — since, as currently written, it seems to just be causing them to become even more confused rather than less confused.
But I feel pretty foolish telling people not to read the Process doc, and would very much prefer to instead be able to tell them they can safely read it without it confusing them even more than might already be confused.
So the “Technical Report → W3C Publication” change and the “Recommendation Track → Standards Track” changes suggested in the patch in this PR are mitigations that could help eliminate a couple of key sources for the repeated confusion I’ve seen, and significantly alleviate some of the repeated confusion.
Preview | Diff