Clarify definition of the REC-track

[frivoal]

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.

Some groups for instance have a declared intention of only going as far as CR. That doesn't make the documents on the "CR track", as there's no such thing.

See https://github.com/w3c/strategy/issues/438#issuecomment-1997685426

---

Preview | Diff

[sideshowbarker]

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.

[sideshowbarker]

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.

[frivoal]

@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.

[sideshowbarker]

@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 https://github.com/w3c/w3process/pull/831#issuecomment-2019351794 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.

[sideshowbarker]

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.

[chaals]

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.

[dwsinger]

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."

[frivoal]

Added a commit adopting on https://github.com/w3c/w3process/pull/831#issuecomment-2019397254

[fantasai]

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.

[css-meeting-bot]

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

The full IRC log of that discussion

<plh> Topic: What's a "REC track document"?
<plh> GH: https://github.com/w3c/w3process/pull/831
<plh> Github: https://github.com/w3c/w3process/pull/831
<plh> florian: some groups don't intend all the way to REC
<plh> ... but it is confusing to call it "REC-track"
<plh> ... we changed the definition of REC-track, but needs some refinements
<plh> ... we should take only the second part of the pull request only
<fantasai> Agenda: https://lists.w3.org/Archives/Public/public-w3process/2024Mar/0002.html
<fantasai> scribe+
<fantasai> florian: I don't want to merge the PR as-sis
<fantasai> s/sis/is
<fantasai> ... first part replaces "consists of" with "contains"
<fantasai> ... second part adds definition of "Recommendation-track document"
<fantasai> ... second part is sufficient to solve the problem
<fantasai> ... and first part isn't quite wrong but is awkward, and unnecessary given second part
<fantasai> ... so preference to merge only the second part
<fantasai> <fantasai> +1
<cwilso> +1
<TallTed> +1 "consists of". There's still the question of "this WG's work will stop at CR".
<fantasai> plh: objections to merging 2nd part?
<fantasai> TallTed: Open question of alerting people to the fact that this is the plan
<fantasai> plh: That's part of the charter
<fantasai> ... that's in the charter templtae
<fantasai> s/tae/ate/
<fantasai> ... in the "success criteria" section
<plh> --> https://w3c.github.io/charter-drafts/charter-template.html#success-criteria Success Criteria
<fantasai> florian: From Process point of view, nothing special about stopping at CR
<fantasai> ... it might be convenient
<fantasai> ... but if a subsequent charter says "we'll go further now", that's fine
<fantasai> TallTed: Currently a misunderstanding that REC-track can't be converted to NOTE-track
<fantasai> florian: If you've reached CR or beyond that is true
<fantasai> ... WD can switch
<fantasai> ... reason is for patent reasons
<fantasai> TallTed: some confusion in various groups
<plh> "A technical report that is or was a W3C Recommendation, W3C Statement, or Patent Review Draft cannot switch tracks."
<plh> https://www.w3.org/2023/Process-20231103/#switching-tracks
<fantasai> fantasai: It's a recent change, so that's probably the source of the confusion
<plh> "A technical report should not switch away from the Recommendation Track without due consideration of the Patent Policy implications and approval of W3C’s legal counsel if the Working Group envisions a likelihood of returning to it later.'
<fantasai> ... added restriction when we untangled the REC and NOTE tracks in 2021
<fantasai> TallTed: ok, I'll go read that section
<fantasai> RESOLVED: Merge second part of PR 831
<fantasai> i/Topic: What's/Topic: Pull Requests to Review/
<fantasai> s/Topic: What's a/Subtopic: What's a/