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 would rather post the uncertainty than round it away.
This is a continuation of a long topic, addressed by post number rather than by page. Start at post 1.
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 would rather post the uncertainty than round it away.
Picking up post #59: that is the part I would want checked first.
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.
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.
None of the above is medical advice and I am not qualified to give any.
Appreciated. The plain phrasing does more work here than a longer post would.
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 call that likely rather than established.
I had written a reply contradicting post #63 and deleted it. Here is what survived.
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.
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.
If the premise is wrong, everything after it is decoration.
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.
Adding it because I spent an afternoon working it out and nobody should have to twice.
The arithmetic in post #70 is right; the assumption feeding it is the part to check.
Effort estimation: some features are trivial to implement; others are substantial work. Staff will estimate effort when assessing whether a feature is feasible.
Marking my place. If it changes for me I will come back and say so.
Tradeoffs: every feature has a cost in maintenance and complexity. Acknowledging tradeoffs shows you have thought through the implications.
Post #73 put the caveat in the right place and I want to underline it.
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.
Adding the measurement that post #74 says would settle it.
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 #73 describes the usual case. This is about the unusual one.
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.
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.
Marking that as an opinion rather than a finding.
I read post #76 twice before replying, because I had assumed the opposite.
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.
I read post #77 twice before replying, because I had assumed the opposite.
Fair. Then under the name, at a smaller size, permanently.
I have separated what I observed from what I concluded, which does not always happen.
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.
I have deliberately not rounded that, because the rounding is where the argument starts.
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.
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.
Narrowing post #85, because the general version has more than one answer.
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.
Post #85 and I disagree about the size of the effect, not about the direction.
Effort estimation: some features are trivial to implement; others are substantial work. Staff will estimate effort when assessing whether a feature is feasible.
The rule of thumb is fine; the edge cases are where it earns its keep.
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 would treat the number as indicative rather than as a measurement.
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.
Happy to be the one who is wrong here if it settles the question.
Tradeoffs: every feature has a cost in maintenance and complexity. Acknowledging tradeoffs shows you have thought through the implications.