Non-reviewer thumbs-up.

But along with this change, I think the Process document should ideally also have — just after that numbered list — a specific normative definition for the term “REC-track document” too. Something like this:

A <dfn lt="W3C Recommendation Track document | REC Track document | Recommendation Track document | Recommendation-track document">W3C Recommendation Track document</dfn> is any document that has ever in its history been published as a [=First Public Working Draft=] — including any document which has been transitioned beyond [=First Public Working Draft=] to any of the later stages in the numbered list above.

That to me would seem to make it unambiguous what a “REC-track document” is.

This PR makes it clear that a document that uses the various publication types and transitions of the REC-track is indeed on the REC-track, even if it isn't planning to go all the way to the end.

Not to beat this into the ground, but I think the patch as-is in the existing PR doesn’t actually make anything about documents as completely clear as it could.

As-is it definitely does clarifies what “REC-track” means — and by doing that, helps people to then deduce what a “REC-track document” most likely means.

But what I am proposing my earlier comment is to make it explicit what “REC-track document” means exactly — by precisely and separately normatively defining it as its own term.

@sideshowbarker Interestingly, I think your proposal for an explicit definition of "REC track document" in addition to "REC track" is actually subtly wrong. This might be making the point about needing an explicit definition.

• Based on https://www.w3.org/2023/Process-20231103/#switching-tracks, it is possible (in some cases) to switch tracks, and in particular (through some terminology indirection), REC track documents that haven't made it as far as CR can switch tracks, and for instance become Notes. Due to "any document that has ever in its history been published as a [=First Public Working Draft=]" your definition would define them as still being on the REC track, but I think the Process means that in the cases where you can change tracks, you leave the track you once were on to become part of the other one, and so such documents would not be considered REC track after the switch

• This is no longer the case, but FPWD used to be a shared as the first stage both for the REC track and for Notes. Prior to the introduction of Draft Notes in Process 2021, FPWD and WD were sometimes used to for early versions of Notes, and a distinct Note track wasn't identified. With your definition, a few documents that were always meant to be Notes in the making would be treated as being on the REC track.

@frivoal I’m not wedded at all to the particular wording of my definition — I doubt I would feel strongly either way about whatever wording the editors would end up deciding on.

But I do think it’s necessary for the document to provide some precise, unambiguous normative definition for exactly what a “REC-track document”. I don’t think it’s adequate to have only a normative definition for “REC-track”, and to expect that readers will be able to deduce from that what a “REC-track document” is.

Your comment at #831 (comment) suggests to me that the evaluation of whether or not a particular document is a “REC-track document” is actually complex enough that it might benefit from having the definition be an actual algorithm with a least a couple of branches/steps.

Or actually, on further reflection, it seems to me that maybe it could just be defined with something like this:

A <dfn lt="W3C Recommendation Track document | REC Track document | Recommendation Track document | Recommendation-track document">W3C Recommendation Track document</dfn> is any document whose current status is one of the five in the numbered list above.

I like @sideshowbarker's updated idea. I think there is an expectation for many that a Rec-track document will advance along that track. This is not a generally shared understanding - a significant number of people think that permanent-CR is an expected end state.

I think the proposal doesn't resolve that disagreement, but nor does it make it worse.

I'd like something that says where there is an intention not to advance a document further, it is no longer a Rec-track document. In my mind it is somethng like a frozen status that hasn't been resolved but there are probably quite different perspectives around too.

I don't think that this thing I would like is a reason not to update the explanation as a combination of @frivoal's PR here with @sideshowbarker's additional proposal.

I disagree with Chaals; I think that if your document status is one of the five named, you're on the Rec Track. You may be stopped on the track, and not expecting to move further. But you could change your mind. Unless explicitly refuted, there is also an expectation of eventual advancement, too. "Though this document is on the Rec-Track, it is not currently expected to advance beyond CR."

Added a commit adopting on #831 (comment)

Agree with @dwsinger. If you're on Highway 80 from New York to SF and only intend to go as far as Chicago, that doesn't change the fact that Highway 80 consists of both the NYC->Chicago segment and the Chicago->SF segment.

I think I'd take the PR without the s/consists of/contains/ change. The proposed wording feels very weird.

The Revising W3C Process CG just discussed What's a "REC track document"?, and agreed to the following:

• RESOLVED: Merge second part of PR 831