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.
Where I part company with the opening post, and it is a narrow parting.
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.
The opening post is the version of this I will quote in future. One addition.
I would be cautious about generalising from the per-category review queue example above. It is a good example. It is one example.
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.
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 had written a reply contradicting post #5 and deleted it. Here is what survived.
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.
Adding a data point of agreement rather than a data point.
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.
This follows post #9 rather than contradicting it.
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.
Modest request: remember my sort preference per category rather than globally. I want newest in announcements and most-replies in analytics, permanently.
Filing this under things that are true until someone shows me otherwise.
Building on post #10 rather than restating 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.
Post #12 put the caveat in the right place and I want to underline it.
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.
Narrowing post #14, because the general version has more than one answer.
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.
Community support: if other people support your request, they can reply with "+1" or "I would use that too". Widely-requested features are prioritised.
Same experience here, different supplier, so it is at least not unique to one of them.
Adding the measurement that post #17 says would settle it.
I have been on both sides of the per-category review queue argument in this category within eighteen months, which should tell you how strong the evidence for either side is.
Post #16 describes the usual case. This is about the unusual one.
Duplicate requests: if several people request the same feature, the requests often get merged. Check whether your feature has already been suggested before posting.
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.
That is what the documentation says. What happens in practice is usually close.
Use case: explain why you think the feature would help. "I would use this to..." makes the request concrete.
Marking that as an opinion rather than a finding.
Coming back to post #21, because the follow-up matters more than the original answer.
Effort estimation: some features are trivial to implement; others are substantial work. Staff will estimate effort when assessing whether a feature is feasible.
I would put the burden of proof on the interesting explanation, not the dull one.
Post #21 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 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.
What I would want before treating per-category review queue as settled: the method, the sample, and whether anyone tried to find the opposite result. Two of the three are usually missing.
Post #25 put the caveat in the right place and I want to underline it.
Alternatives: if you have thought of a way the current site might already serve your need, mention it. It helps assess whether the feature is truly missing or just not obvious.
Happy to expand any of that if it is the useful part.
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.