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.
Request: show the solution author in the topic list — what changed since posts 31–60
This is a continuation of a long topic, addressed by post number rather than by page. Start at post 1.
Post #28 describes the usual case. This is about the unusual one.
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.
Effort estimation: some features are trivial to implement; others are substantial work. Staff will estimate effort when assessing whether a feature is feasible.
I am reporting what happened, not recommending it.
The arithmetic in post #34 is right; the assumption feeding it is the part to check.
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.
Collapsed as off-topic by two members at trust level 3 or above
Answering the question post #32 raises rather than the one it answers.
I would use that constantly. The objection is presumably that it is data the site then has to hold and protect for no benefit to anyone else.
One case, stated as one case.
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.
I would want the raw data before agreeing with my own summary of it.
Narrowing post #37, because the general version has more than one answer.
Then the honest version is a comparison of the record shapes rather than the scores. How many results, over how long, from which services. That I would use.
The short answer was in the first line; everything after is the working.
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.
I have seen it go both ways, which is why I hedge.
Coming back to post #41, 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 treat that as a working assumption and revisit it.
Picking up post #44: that is the part I would want checked first.
Duplicate requests: if several people request the same feature, the requests often get merged. Check whether your feature has already been suggested before posting.
Filing this under things that are true until someone shows me otherwise.
I had written a reply contradicting post #46 and deleted it. Here is what survived.
That is exactly the objection, and it is not a refusal on principle. Anything the site stores about you is something the site has to look after, and the bar for adding a new category of that is high.
Fair. Then under the name, at a smaller size, permanently.
Post #46 put the caveat in the right place and I want to underline it.
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.
The general case is well covered; this is the awkward specific one.
That is exactly the objection, and it is not a refusal on principle. Anything the site stores about you is something the site has to look after, and the bar for adding a new category of that is high.
Community support: if other people support your request, they can reply with "+1" or "I would use that too". Widely-requested features are prioritised.
I have kept the units in throughout, for the obvious reason.
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.
That is a description of practice, not a recommendation of it.
Then the honest version is a comparison of the record shapes rather than the scores. How many results, over how long, from which services. That I would use.
It is one reading of the data and not the only reasonable one.
I had read the opposite somewhere and cannot now find where, which tells me something.
Picking up post #52: that is the part I would want checked first.
Fair. Then under the name, at a smaller size, permanently.
Use case: explain why you think the feature would help. "I would use this to..." makes the request concrete.
Tradeoffs: every feature has a cost in maintenance and complexity. Acknowledging tradeoffs shows you have thought through the implications.
Adding a source would improve this post and I do not have one to hand.
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.
Not the answer, but possibly the question that gets there.
Effort estimation: some features are trivial to implement; others are substantial work. Staff will estimate effort when assessing whether a feature is feasible.
If that reads as pedantic, it is, and it has saved me twice.
Post #58 put the caveat in the right place and I want to underline it.
I would use that constantly. The objection is presumably that it is data the site then has to hold and protect for no benefit to anyone else.