Title is about Wide Review, contents are about Horizontal Review

[nigelmegitt]

I'd like to see more clarity about the requirements for Wide Review here: the title is about wide review but almost all the content is only about the subset of Wide Review that is Horizontal Review.

As a general point, as per w3c/process#130 it would be good to document the process for handling review comments, and what kinds of responses are likely to result in a transition request being declined.

For example, if a responder says "I don't like the colour of the text in this document" and the WG ignores the comment, not even sending a response, is that okay? Or at the other end of the scale, if a commenter raises a detailed technical point, the WG considers and responds, and then the commenter remains unhappy with that response, is that okay?

What level of tracking of responses is required and what is merely good practice?

[fantasai]

the title is about wide review but almost all the content is only about the subset of Wide Review that is Horizontal Review.

Just came here to file the same issue. My suggestion is we simply retitle this document to be about Horizontal Review, and clarify that it is a subset of Wide Review.

[nigelmegitt]

My suggestion is we simply retitle this document to be about Horizontal Review, and clarify that it is a subset of Wide Review.

Okay, but then we need a Wide Review document too!

[r12a]

Okay, but then we need a Wide Review document too!

Which begins to splinter the information again. Maybe better to clearly signpost within the document what the difference is between wide and horizontal review (which may come down to only a couple of sentences, strategically placed).

[nigelmegitt]

Maybe better to clearly signpost within the document what the difference is between wide and horizontal review

That would be my preference too

[r12a]

I proposed some changes at #16 to address this.

[fantasai]

@r12a I think the changes are good, but don't quite go far enough to show that horizontal review is a subset of wide review. And also there's no serious mention of reaching out to the public, which is part of wide review.

[r12a]

See the proposed changes at #19

[r12a]

As a general point, as per w3c/process#130 it would be good to document the process for handling review comments, and what kinds of responses are likely to result in a transition request being declined.

For example, if a responder says "I don't like the colour of the text in this document" and the WG ignores the comment, not even sending a response, is that okay? Or at the other end of the scale, if a commenter raises a detailed technical point, the WG considers and responds, and then the commenter remains unhappy with that response, is that okay?

What level of tracking of responses is required and what is merely good practice?

@nigelmegitt this stuff doesn't really relate to the issue title or much of the discussion. Could we raise it as a separate issue, so that this one can be closed when we have resolved the discussion about wide vs horizontal?

[nigelmegitt]

this stuff doesn't really relate to the issue title or much of the discussion.

Sigh, there's only so much you can get into a title.

Please do go ahead and raise it as a break-out issue.

[frivoal]

I don't know. We need a document that explains how to do horizontal review, since we're quite specific about how this must be done.

We also need to stop conflating wide and horizontal review, because it's annoyingly common that people say things like "I'll start wide review", ping the HR groups, and call it done. So, a document whose title is about wide review, makes a passing mention of things other than HR groups, and focuses almost entirely on horizontal review is in my opinion a bad idea. We can certainly call out the fact that wide review is broader than horizontal review in a document about horizontal review, but claiming the document is about the whole topic and then only going into depth about part of it seems wrong.

I support #16 and #19, but I still think the title should be changed anyway

[r12a]

We also need to stop conflating wide and horizontal review, because it's annoyingly common that people say things like "I'll start wide review", ping the HR groups, and call it done

The problem here imo is not that wide and horizontal review are conflated (because actually horizontal is part of wide review, and we don't want one to be done without the other, or to describe them as if they are separate things – because that has in the past caused precisely the problem you are concerned with and that we're trying to solve here). The problem is that people are only doing the part of the wide review for which there are more clear procedural aspects.

One solution for this is to spell out additional procedural aspects for the non-horizontal part of the wide review. I'm not sure what those would be, but you're welcome to suggest some (concise and non-repetitive) text.

However i think people can learn easily enough that there is more to wide review than HR, especially since we've now changed the page to make that clearer. A bigger problem we see is that people who get things wrong simply haven't read anything at all.

[nigelmegitt]

We need a document that explains how to do horizontal review, since we're quite specific about how this must be done.

We also need to stop conflating wide and horizontal review,

@frivoal it kinda looks like you just did exactly that though, across these two sentences! In my view we need a document that explains how to do wide review, including horizontal review.

it's annoyingly common that people say things like "I'll start wide review", ping the HR groups, and call it done

agree, that's not doing what's required.

We can certainly call out the fact that wide review is broader than horizontal review in a document about horizontal review, but claiming the document is about the whole topic and then only going into depth about part of it seems wrong.

No, in my view that's the wrong solution. We should be describing Wide Review and its requirements properly, and including Horizontal Review as a subset, not renaming the document and then leaving a gap where Wide Review should be.

[frivoal]

I think a key difference is that horizontal groups are specific sets of people with know preferences about how their review should be sought, and those preferences are strong enough that they need to be documented, because if you don't follow them, typically you'll get no review from them. The general public imposes no such thing on WGs seeking to get their work reviewed.

So we need a document about how to seek Horizontal Review, as a process to be followed, while we don't for the rest of wide review. Documenting best practices might be interesting too, but that's not the same thing as the very specific expectations from HR groups, and besides, how to do it is going to vary significantly per topic. Getting good feedback on smart-cities, on CSS text layout, or on High Dynamic Range color operations is going to require engaging with groups of people that are so different that the way to engage with the is going to be different too.

The Process calls for wide review to happen, and sets its expectations about it. These can probably be clarified to some degree, as the Process can always be improved, and that particular section isn't the clearest one. But the reason to need a document specific to HR is because the HR groups themselves require to be approached in a particular way.

[plehegar]

I provided #21 to improve our wide review guidance.