Request: a per-category review queue Writing it up because I had to work it out twice and would rather nobody else did.
Per-category review queue — I have the observation and I do not trust my interpretation of it, so I am posting the observation and holding the interpretation back.
Numbers, method and the conditions under which they were collected are below. Interpret them however they warrant.
Small request: let me filter Latest by whether I have read the topic. Unread exists as a tab and does not combine with anything else, so a busy category is either all of it or none.
Coming back to the opening post, because the follow-up matters more than the original answer.
Request that would help newcomers more than regulars: show the subcategory description on hover in the category list. The names are terse and the descriptions are good.
The number is defensible. The precision I gave it is not.
Seconded. It reads as careful rather than confident, which is the right register.
Clear enough that I do not think I have a follow-up, which is unusual.
Request from the analytics side: allow a table in a post to be marked as data rather than layout, so it can be copied without the formatting. Half the tables here are worth pasting into a spreadsheet.
I read post #6 twice before replying, because I had assumed the opposite.
The reason per-category review queue is hard to answer is that the obvious measurement and the relevant quantity are not the same thing, and substituting one for the other is silent.
Per-category review queue: I would want to see the raw numbers rather than the summary before agreeing. Summaries lose exactly the information that would settle this.
That reframing is better than the original request and staff would consider it. Which is a good illustration of why these belong in public: the first version would have been declined and the third is worth building.
Post #9 answers the question as asked. The question underneath it is different.
Fair. Then under the name, at a smaller size, permanently.
The step people skip is the one I have spelled out.
Request: an export of my own posts. Not for any dramatic reason — I want to search my own history offline, and site search is optimised for finding other people's material.
Feature request I expect to be refused, stated anyway: a private notes field on a topic, visible only to me. I keep those in a text file and the text file loses the link.
Filing this under things that are true until someone shows me otherwise.
This follows post #10 rather than contradicting it.
The practical version of per-category review queue is three sentences long. The rigorous version is three pages and reaches the same conclusion with the conditions attached.
I read post #12 twice before replying, because I had assumed the opposite.
I would keep per-category review queue and the decision it usually gets used for separate in this thread. They are related and they are not the same question, and merging them is why the last one went badly.
Post #14 answers the question as asked. The question underneath it is different.
Deprecation requests: if you think a feature should be removed or changed, that is also a request. Explain why you think it would improve the site.
Good question, well framed, and I would like to see it answered properly.
Coming back to post #17, because the follow-up matters more than the original answer.
Careful with the language on per-category review queue. "Not detected" and "not present" are different findings and the first is a statement about the method.
Reading rather than contributing, but this is the most useful thread I have found on it.
Worth separating two things that post #17 runs together.
Duplicate requests: if several people request the same feature, the requests often get merged. Check whether your feature has already been suggested before posting.
Modest request: remember my sort preference per category rather than globally. I want newest in announcements and most-replies in analytics, permanently.
That is what the documentation says. What happens in practice is usually close.
Request with a caveat attached: a compare view for two vendor pages side by side. The caveat is that it would encourage exactly the ranking-by-number reading the pages are written to discourage.
Marking that as an opinion rather than a finding.
Useful. I have added it to my own notes with the date on it.
Post #25 is right about the mechanism and I think understates the practical bit.
Request with the use case rather than the feature. I frequently want every topic that cites a particular maintained document. At the moment I can find the document from the topic and not the reverse.
I checked the source rather than the summary, and they differ.
I read post #25 twice before replying, because I had assumed the opposite.
Reading back through the per-category review queue threads from last year, the same three questions come up every time and only one of them has ever been answered properly. That seems like a documentation gap rather than a knowledge gap.
Sensible. I would want the same detail before I acted on it either.
The version of per-category review queue that circulates here is a simplification of a simplification. It is not wrong, but it has lost the conditions under which it holds, and those conditions are where the interesting cases live.