Improve wide review handling

[plehegar]

This clarifies further how to get wide review (#12).

• clarify that publishing an updated technical report is expected as part of getting wide review, to discourage Groups to use their editor's drafts for that purpose (and it amplifies the reach to the public).
• our tooling will pick up if a publication is interested in wide review.
• as a tip, Groups should consider creating a GitHub issue to track the state of an ongoing wide review.

Hopefully this helps.

cc @nigelmegitt @frivoal @fantasai

---

Preview, HTML diff

---

Preview | Diff

[plehegar]

(with #15 merged, the tip could even be more easily fullfilled)

[nigelmegitt]

Looks like a good improvement. Made a bunch of mainly language-based suggestions to get away from using US-centric colloquialisms like "gotten" and "reach out" in the hope of reaching more geographically neutral English language, and being clearer about the intent.

[nigelmegitt]

All my changes incorporated, thanks @plehegar - it looks like @r12a 's comments have also been incorporated, but I'm not clear because the comment is not shown as resolved. Changing my review to a "Comment" so it doesn't block merging, happy to mark as Approved after seeing it when it seems to be stable with respect to other reviewers' comments.

[plehegar]

Alright, I believe I folded everything in. Next step are to rebase with the main branch, tweak to integrate the recent github template changes, get a +1 from @swickr , give it a few days in case other comments are coming, merge, and finally announce the update to the Chairs list.
big kuddos to @r12a @nigelmegitt for the quick turn-around!

[plehegar]

HTML diff with main

[swickr]

Great work on the text. Big improvement. Thanks @plehegar, @nigelmegitt , @r12a.

[samuelweiler]

This is starting to get long enough that it gets some things muddled. For example, there's this new section on when to ask for wide review as well as the existing verbiage in the HR section re: when to ask for HR review.

If we're breaking out the "when", perhaps we need to pull it out of the HR section, also? And, in case, this is getting long enough that we need some combination of TL;DR version or at least an early-in-the-doc clarification of what we mean by wide v. horizontal review. Or we need to see if we can clarify with a net reduction in words.

[r12a]

If we're breaking out the "when", perhaps we need to pull it out of the HR section, also?

I'd prefer to leave it, as it's worth saying twice, and more likely to be noticed by those who just jump to the 'How to get horizontal review' section. But actually, i think it contains some additional information that is HR specific.

Or we need to see if we can clarify with a net reduction in words.

I suggest zapping the "Terminology & abbreviations" and "Enhancement Requests" sections. The former is a hangover from the original document that we never looked at closely. The second is about a link that doesn't actually work anyway.

I'd also be happy to drop the FAQ section. That, too, is very old text that we never examined during the rewrite.

That would produce a good net reduction of words on the page.

[plehegar]

(waiting on a review from @frivoal )

[plehegar]

Some updates deserve announcement, and others do not. It is good to
differentiate this, and make announcements appropriately. But it's not
appropriate to put that information in the SOTD, because how people
should treat the document published 2 days later shouldn't differ when
it's essentially the same with some minor fixes.

People don't know that the nature of changes. They see 2 documents with 2 different dates. Whatever dated version they picked needs to be clear to the Director. The Director needs to precisely review changes done to a specification since that spec was sent to wide review. Here is yet another messy instance in
w3c/transitions#373 (comment)

I would advise to not make this part of the SOTD, and use some other
flag or tracker or whatever if you want tooling around it. (Fwiw, CSSWG
has been doing these things manually for years.)

The SOTD marker is meant to help us diffuse the information and draw extract attention. I guess, once I finally get around to finish the tooling on wide review, the marker would not be needed. I'm ok with removing/relaxing the requirement in this pull request.

[fantasai]

Let me paste the full contents of my comment to which @plehegar was replying:

• Our documents are always open for wide review, and we shouldn't be marking certain publications as requesting wide review. In particular, if Miriam pushes an update to css-cascade-5 and because it has significant changes wants to trigger a wide review, me updating the draft 2 days later to fix some minor errors shouldn't mean that it is no longer under wide review, or that the 2-days-earlier version should be the basis of wide review.

• Indeed, we shouldn't be pushing out public signals for review on every update to /TR, that would create a very low signal-to-noise ratio. Some updates deserve announcement, and others do not. It is good to differentiate this, and make announcements appropriately.

But it's not appropriate to put that information in the SOTD, because how people should treat the document published 2 days later shouldn't differ when it's essentially the same with some additional fixes.

And now my reply to #21 (comment) is as follows:

When we send a request for wide review -- to the public or to an HRG -- we want to be linking to the Latest Version URL so that the reviewers, on the day they are reviewing, see our latest work. We do not want to be linking to a dated copy, because we don't want the reviewers to be working off of stale documents.

If the Director wants to know what version was reviewed by an HRG, then that information should be requested from the HRG in their response to the review: please link to the dated URL of the version that you reviewed. Alternately the Director could use the date of the HRG response to identify the dated version that was reviewed. As long as Horizontal Review is requested against /TR (as it should be), there should be no problem identifying the version of the document that was reviewed.

[fantasai]

Split the sentence after "and" here. :)

[fantasai]

All of our publications are inviting review, that is why we publish them. Let's not add more junk to the SOTD.

[plehegar]

Except that the other groups need a clearer signal that wide review is expected before moving to CR. It's not junk, it gets picked up by our tools for the past few years.

[samuelweiler]

We should also update the HR request templates to encourage working drafts

[plehegar]

Merging this pull request since it encodes current practices. Additional issues are welcome separately.