Who publishes Technical Reports?

[jeffjaffe]

Section 6.2.1 states:

"Every Technical Report published as part of the Technical Report development process is edited by one or more editors appointed by a Group Chair."

Since it is now the case that Errata can be done elsewhere (e.g. in a CG), and if there is no WG, the team can take such a document, get Director approval, and generate a new REC, this section should be clarified to more explicitly allow this case.

[frivoal]

As per https://www.w3.org/2020/01/29-w3process-minutes.html and https://www.w3.org/2020/02/12-w3process-minutes.html, this issue is deferred to a subsequent cycle of the Process.

[fantasai]

Since it is now the case that Errata can be done elsewhere (e.g. in a CG), and if there is no WG, the team can take such a document, get Director approval, and generate a new REC, this section should be clarified to more explicitly allow this case.

If there is no Working Group, then there cannot be changes to the REC. If there is a desire to maintain the REC, there needs to be a Working Group. CGs are not bound by the Patent Policy, and they cannot publish technical material into a REC.

CGs (or the Team) can create a list of errata and suggested corrections and publish it as a CG report, but these cannot be normatively incorporated into the REC without a WG.

[frivoal]

Since #428, we have in https://w3c.github.io/w3process/#revised-rec-editorial:

If there is no Working Group chartered to maintain a Recommendation, the Team may republish the Recommendation with such changes incorporated, including errata and candidate corrections.

So the team can maintain errata and candidate corrections directly inline. This is very much a stop-gap measure, and should not be the normal mode of operation, but it is now an explicit possibility. We'll still need a proper working group if we want to normatively and officially fold these corrections in (and get the patent policy to apply and all that), but as far as maintaining errata and possible solutions to them, it seems that this has now been addressed.

I believe this closes this issue. @jeffjaffe can you confirm?

[jeffjaffe]

Thanks, @frivoal.

As I understand it, in the previous version of the process the Team was empowered to generate a new REC, and the way that you fixed the inconsistency in the process language document was to remove that empowerment from the Team.

If that is correct, then I agree that your fix makes the process document consistent.

But the empowerment was given to the Team for a reason. My recollection was that in a previous iteration of the Process, some were concerned that if a REC that was orphaned from a WG there was no method to ever revise its REC. The team empowerment was included to cure that problem.

Are we proposing a different cure for this problem? Are we no longer concerned about this problem?

[dwsinger]

I agree, we wanted a way to revise a Rec. when the WG was closed. Spinning up a new WG that almost no-one would join would fix almost nothing, as if we'd get piddling numbers of orgs joining, the patent policy impact would also be piddling.

[frivoal]

The team was never able to update a REC in a way that engages the patent policy, and there's no path towards that: without a WG, there's nobody to get IP commitments from other than the Team itself, and we know that committing the hosts's IP isn't a realistic proposition.

So all we can hope to get is for the Team to be able to publish a document where the old REC was, which includes the changes that are felt to necessary. And ideally, communicate somehow that these changes do not have Patent Policy protection.

The old process achieved that by having a separate class of document called Amended REC. Readers could then just diff it against the previous REC version to see exactly what had been introduced by the Team and what was prior material. (Note: in practice, we have never issued any Amended REC)

This version of the process does away with the separate class of document, while continuing to empower the team to indicate in the document what they think needs to change to to publish that. These changes now appear in the REC, and are marked as candidate amendments (or Team amendments, see #493).

So the Team is just as empowered as it's always been, and we've just changed how such changes are presented.

I thought this issue was just about the fact that it wasn't terribly clear whether that was possible, and since another issue/pull request has clarified that since, there's nothing left to do here.

Am I missing something?

[jeffjaffe]

Am I missing something?

You would need to ask the people who wanted the class of documents called Amended REC.

[jeffjaffe]

Am I missing something?

You would need to ask the people who wanted the class of documents called Amended REC.

[chaals]

I'm going off my memory of discussions from a while ago - as an AB member you could go look up the history of the meeting agenda and read the relevant minutes. (Here ends the lesson on drawbacks of the AB discussing process stuff in their meetings, instead of being clear about using this group).

As I recall, the point of the Amended Rec was to enable the Team to fix up something urgently, that seemed important enough to skip the patent protection and minimal enough that it would pass review. As I understand your changes, that's still feasible, so for what it's worth I don't think you are missing anything.

[frivoal]

I am not asking whether we should remove amended REC, as we've already resolved on that and did it. Follow up questions about whether that was a good idea belong in another issue. The question here is, given the current state of the Process, is there anything left to do in this issue.

The sentence you quoted in the original comment is still there, unchanged. I think this sentence is mostly introductory, to give a sense of how things work in general, and therefore doesn't need to have sub-clauses to worry about all the exceptions as long as the details are later well described, which they are.

Based on that, I suggest closing. Alternatively, if you think that sentence really ought to be precise, we could do:

Every Technical Report published as part of the Technical Report development process is edited by one or more editors appointed by a Group Chair, except in cases where it is published by the Team (see §x.y.z and §α.β.γ).

I don't think that's necessary and that it makes the text longer for no clear benefit, but I wouldn't oppose this addition if you and/or others insisted.

[chaals]

The full paragraph:

Every Technical Report published as part of the Technical Report development process is edited by one or more editors appointed by a Group Chair. It is the responsibility of these editors to ensure that the decisions of the Group are correctly reflected in subsequent drafts of the technical report. An editor must be a participant, per § 5.2.1 Working Group and Interest Group Participation Requirements in the Group responsible for the document(s) they are editing.

I think we could happily trim it instead to

Technical Report editors are appointed by the chair(s), and must be a participant in the Group responsible for the document.

I think the responsibility to ensure the spec reflects what the group asked for obviously belongs to the editor, but changes can be mandated by group decisions which (the process ought to say) are those declared by the chair, and there are numerous checks on whether that happens in the process, including a whole vague waffle about decision making in groups.

[chaals]

I would be happy if this issue were just closed with no action.

[frivoal]

Based on the discussion above, I'm happy to close either with no (further) change, or with the change suggested by @chaals in #351 (comment)

[jeffjaffe]

A question for @frivoal:

As I understand it, the use case where we can update a REC without a WG is removed from P2021.

When we send P2021 for AC review, will we make clear that we are removing that capability? If the answer is "yes", and we get no pushback from the AC, then I think my concerns in #351 (comment) are addressed. And therefore, when P2021 is approved, we can close this issue.

[frivoal]

We're not removing the ability of the Team to update a REC with text that doesn't get patent coverage. The name of the resulting object is different, but the ability to do it remains there. More details in #351 (comment)

And yes, I will (attempt to) make that clear in the yet to be written change log

[dwsinger]

Prior to LS, we had Amended Recommendations that wasn't well defined. We now have the team ability to publish errata and candidate corrections; to my eye, this is clearer and allows the reader to understand what has PP coverage (the base text) and what doesn't (the errata and candidate corrections). Can we close?

[frivoal]

Btw, this is now described in the changes section (first bullet under Recommendation Track)