This is a continuation of a long topic, addressed by post number rather than by page. Start at post 1.
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.
I would want the raw data before agreeing with my own summary of it.
Confirming post #32 from a second method, which matters more than confirming it from a second person.
Offering a way to settle per-category review queue rather than another opinion about it. Two measurements, taken the same way, a fortnight apart. If the difference is within the noise, the question was not answerable at this precision.
Counter-request, gently: please do not add anything on hover. It does not exist on a phone and half the readers here are on one.
Stating my assumptions rather than smuggling them in.
Post #36 is right about the mechanism and I think understates the practical bit.
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.
The short answer was in the first line; everything after is the working.
Coming back to post #34, because the follow-up matters more than the original answer.
Reframing per-category review queue slightly, because I think the disagreement is about the question rather than the answer. If the question is "does it happen", yes. If it is "how often", nobody here knows.
This follows post #36 rather than contradicting it.
My understanding of per-category review queue is a few years old and may have been superseded. If it has been, I would genuinely like to know rather than keep repeating it.
Tradeoffs: every feature has a cost in maintenance and complexity. Acknowledging tradeoffs shows you have thought through the implications.
This is where my knowledge stops and I would rather mark the edge than blur it.
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.
On reflection I would soften that slightly.
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.
Where I part company with post #39, and it is a narrow parting.
Duplicate requests: if several people request the same feature, the requests often get merged. Check whether your feature has already been suggested before posting.
It is the sort of thing that seems obvious in retrospect and was not at the time.
Both of these are in the same family and staff would rather do one thing well than two things partly. If the range link exists, the citation relationship gets much easier to record, so the order matters.
The evidence for this is thinner than the way I have phrased it suggests.
A definition problem is doing most of the work in this per-category review queue discussion. Once the term is pinned down I suspect the disagreement mostly goes away and what is left is small.
That is clearer than the version I had in my head. Thank you.
Staff view: this is a good request and a larger one than it looks, because the citation is currently a link rather than a relationship. Recording it properly is the work, displaying it is trivial.
Post #47 describes the usual case. This is about the unusual one.
Per-category review queue was covered in the wiki last year and the page has a review date on it, which is a better starting point than my memory of a thread.
Everything in post #48 holds. The case it does not cover is the one I have.
Use case: explain why you think the feature would help. "I would use this to..." makes the request concrete.
Adding this to the thread rather than to the wiki, because I am not confident enough for the wiki.
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.
I have said this before in a thread nobody could find, so it is worth repeating.
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.
The arithmetic in post #54 is right; the assumption feeding it is the part to check.
Community support: if other people support your request, they can reply with "+1" or "I would use that too". Widely-requested features are prioritised.
The short version is the first sentence; the rest is why.
Answering the question post #52 raises rather than the one it answers.
That would also make review dates far more meaningful. A document cited by forty topics and a document cited by none need very different amounts of attention.
The uncertainty is in the assumption, not in the calculation.
Where the per-category review queue reasoning breaks down for me is the step from the group result to the individual case. That step is almost never argued for.
Adding the measurement that post #58 says would settle it.
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.
The rule of thumb is fine; the edge cases are where it earns its keep.