w3c / process

W3C Process Document
https://www.w3.org/policies/process/drafts/
196 stars 130 forks source link

Switching tracks **and back** #864

Closed frivoal closed 6 months ago

frivoal commented 6 months ago

What happens to a document which switches away from the REC track (e.g., to Note), and then back to the REC track?

Typically, nowadays, you're not really supposed to do that, and instead if you want to discontinue a REC track document, you should use https://www.w3.org/2023/Process-20231103/#abandon-draft and publish a Discontinued Draft without switching tracks. But that provision is new, so there are already a number of documents that have been parked as Notes, some of which could be switching back. There's now a should against switching away from the REC track that, but (1) it's only a should, and (2) this should is pretty new. So we still need to consider the case.

We have:

Interestingly, FPWD is not identified as a maturity stage, but is simply the name given to the first Working Draft of a technical report. This view is further strengthened by https://www.w3.org/2023/Process-20231103/#transition-reqs: advancing to a new maturity stage involves a Transition Request, and there's no Transition Request between FPWD and WD, so they are the same stage.

So, if a document switches to the REC track (for example, from Note):

I think that's what the Process means. And from the point of view of the Patent Policy, I think that's what makes the most sense: The provisions of the Patent Policy make no exception for a document being temporarily published off the REC track. The only things it concerns it self are: documents being published as FPWD, documents being published as Patent Review Drafts, Members joining and leaving the group, so it doesn't have an expectation that a document would be an FPWD more than once.

So, all in all, I think the Patent Policy and Process are coherent and that the way they are set up is good.

However, I think this interpretation is not entirely obvious when reading some sections out of context. Regrettably, it is easy, if you're only reading https://www.w3.org/2023/Process-20231103/#switching-tracks to assume that "FPWD" is the REC track's initial maturity stage, which could lead us to publish multiple "First" Public Working Drafts of a same technical report. This is undesirable, as that would trigger unnecessary Calls for Exclusion.

Therefore, I suggest adding a Note to https://www.w3.org/2023/Process-20231103/#switching-tracks, saying something like:

Note: The initial maturity stage of the Recommendation track is Working Draft. First Public Working Draft is not a separate maturity stage. A document which switches to the Recommendation track is only published as a FPWD if it was never previously published as such, other wise, it is simply a WD.

dwsinger commented 6 months ago

I suspect that there are some wrinkles for depending on whether there were changes while the document was off the Rec. Track. One might argue that the second FPWD is actually a new document, starting its own progression, for example. There may also be wrinkles depending on whether it's the same WG with the same composition.

frivoal commented 6 months ago

I suspect that there are some wrinkles for depending on whether there were changes while the document was off the Rec. Track.

The specific downside of doing that, which is why it's a bad idea, is that any company who has left the working group while the document was off the rec track isn't made to commit to any material introduced into the Note, since it was not at that point a Working Draft, and therefore the provisions of the 3rd paragraph and bullet list in https://www.w3.org/Consortium/Patent-Policy-20200915/#sec-exclusion-resign don't kick in on that latest draft (they apply to the latest thing that was called a WD).

So this is indeed not an ideal thing to do, as iterations as a Note could leave a window for people to participate but not commit. So don't do that. Fortunately, most of the time when something is switched to a Note, that's not to iterate on it, but to park it, especially because discontinued draft used not to be a thing, and the only way we had to park REC track documents was to turn them into Notes.

One might argue that the second FPWD is actually a new document, starting its own progression, for example.

Well, the Process is explicit that identity is preserved, so that argument would not be according to process:

Technical reports that switch tracks […] [retain] any established identity (url, shortname, etc.).

The Patent policy handles the instantiation case just fine (because it just ignores the intermediate off-rec track publication). People who have left the group before the document was reinstated don't get committed to stuff that is added after they left, which is also what would happen if nothing out of ordinary had happened.

Breaking the continuity between the two parts would cause more problems, as it could be seen as extinguishing the patent commitments from earlier participants, without reinstituting them on the new draft if they have since left the working group, even though from a normative point of view, the spec still covers the exact same things.

So I think the Process is fine as it is from a normative point of view, and works well with the Patent Policy (because they were deliberately designed with that intent, and the effect is the same as following the provisions of https://www.w3.org/2023/Process-20231103/#abandon-draft). But an editorial clarification would be welcome.

caribouW3 commented 6 months ago

"A technical report that is or was a W3C Recommendation, W3C Statement, or Patent Review Draft cannot switch tracks."

In my understanding, a FPWD is a patent review draft, therefore the new publication when returning on a REC track can't be a FPWD (moreover, a "Second First Public WD" sounds broken).

frivoal commented 6 months ago

In my understanding, a FPWD is a patent review draft

It's not. CRS are Patent Review drafts, as stated in https://www.w3.org/2023/Process-20231103/#candidate-recommendation-snapshot, and so is the combination of the existing Recommendation with the proposed amendments, as stated in https://www.w3.org/2023/Process-20231103/#change-review. But other stages are not. FPWD is relevant to the Patent Policy, but differently so, not as a PRD.

css-meeting-bot commented 6 months ago

The Revising W3C Process CG just discussed #877, and agreed to the following:

The full IRC log of that discussion <plh> Topic: #877
<plh> Github: https://github.com/w3c/w3process/issues/864
<plh> --> https://github.com/w3c/w3process/pull/877/files Add note reminding that the first stage of REC track is WD
<plh> Florian: the REC track a few maturity levels, that's WD, CR, PR, REC
<plh> .... FPWD is not a maturity level
<plh> ... so, you go from Note->WD, not WD->FPWD
<plh> .... I looked at the Patent Policy and Process, I believe this is what was meant
<plh> ... so this is a clarification
<plh> ... this case shouldn't arise most of the time. In the past, we turned REC-track to Note, because we did not have discontinued draft
<plh> ... the recent case was Ruby
<plh> plh: should we consult PSIG for that?
<plh> ... since FPWD has a call for exclusion
<plh> florian: while the document is a Note, it's ok. Once it's a WD, you get committed once you join
<plh> ... if you republish a FPWD, then what happened to the previous commitment? It's a new document.
<plh> plh: I'd feel more comfortable if we were asking for PSIG confirmation
<plh> Florian: the patent policy doesn't care if it's outside the REC-track. Once it's back on the REC track
<plh> .... if you make normative changes to a Note, that could be a problem but the patent policy doesn't address that
<plh> fantasai: I think this is the correct thing to do. If you join the Group when it's a Note, you might not realize that you will have an opportunity later
<plh> plh: joining a WG with documents in Note state (or editor's draft state) doesn't create an exclusion opportunity
<plh> Florian: it's not obvious how things work around rechartering
<plh> plh: I'm fine with making the change and notifying PSIG
<cwilso> +1
<plh> Resolved: Let's merge #877 and notify PSIG
<plh> ACTION: fantasai to notify PSIG