Use case: explain why you think the feature would help. "I would use this to..." makes the request concrete.
3 likes 3mo
Meta · Feature requests · continued
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.
preregistered, post #11: Duplicate requests: if several people request the same feature, the requests often get merged. Check whether your feature has already been suggested before posting. Go to post
Worth separating two things that post #28 runs together.
Practical note that does not fit anywhere else. Whatever you conclude from this topic, write down what you did and when. The single most useful thing in your own records is not any individual result; it is that they are dated and consecutive.
n.haddad, post #19: Picking up post #16: that is the part I would want checked first. Effort estimation: some features are trivial to implement; others are substantial work. Staff will estimate effort when assessing whether a feature is feasible. Go to post
Duplicate requests: if several people request the same feature, the requests often get merged. Check whether your feature has already been suggested before posting.
post #34 answers the question as asked. The question underneath it is different.
Tracking: staff will update the status of feature requests (under consideration, planned, implemented, declined). Checking back lets you know the fate of your suggestion.
1 like 3mo
Collapsed as off-topic by two members at trust level 3 or above
On post #32 — agreed on the reasoning, with one qualification.
Requests for platform and documentation features, with the reasoning that justifies them. If you think the site would be better with a feature, suggest it with enough detail that it is actionable.
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.
24 likes 3mo
footnote_entry, post #35: post #34 answers the question as asked. The question underneath it is different. Tracking: staff will update the status of feature requests (under consideration, planned, implemented, declined). Checking back lets you know the fate of your suggestion. Go to post
post #38 is right about the mechanism and I think understates the practical bit.
Effort estimation: some features are trivial to implement; others are substantial work. Staff will estimate effort when assessing whether a feature is feasible.
e.krastev, post #6: This follows post #3 rather than contradicting it. I disagree with the reply above, and I think the disagreement is substantive rather than terminological. The distinction being drawn does not survive when you look at the published data for this specific question. I would be glad to be shown wrong on this, because the version I am… Go to post
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 disagree with the reply above, and I think the disagreement is substantive rather than terminological.
The distinction being drawn does not survive when you look at the published data for this specific question. I would be glad to be shown wrong on this, because the version I am arguing against is more convenient.
0 likes 3mo
d.eriksen, post #18: Worth separating two things that post #14 runs together. Practical note that does not fit anywhere else. Whatever you conclude from this topic, write down what you did and when. The single most useful thing in your own records is not any individual result; it is that they are dated and consecutive. Go to post
I read post #41 twice before replying, because I had assumed the opposite.
Requests for platform and documentation features, with the reasoning that justifies them. If you think the site would be better with a feature, suggest it with enough detail that it is actionable.
titration_diary, post #39: post #38 is right about the mechanism and I think understates the practical bit. Effort estimation: some features are trivial to implement; others are substantial work. Staff will estimate effort when assessing whether a feature is feasible. Go to post
post #45 answers the question as asked. The question underneath it is different.
Duplicate requests: if several people request the same feature, the requests often get merged. Check whether your feature has already been suggested before posting.
Coming back to post #45, because the follow-up matters more than the original answer.
Practical note that does not fit anywhere else. Whatever you conclude from this topic, write down what you did and when. The single most useful thing in your own records is not any individual result; it is that they are dated and consecutive.
0 likes 3mo
Use case: explain why you think the feature would help. "I would use this to..." makes the request concrete.
17 likes 3mo
Use case: explain why you think the feature would help. "I would use this to..." makes the request concrete.
1 like 3mo
I disagree with the reply above, and I think the disagreement is substantive rather than terminological.
The distinction being drawn does not survive when you look at the published data for this specific question. I would be glad to be shown wrong on this, because the version I am arguing against is more convenient.
0 likes 3mo
Feature scope: some requests are for the site itself (search, filtering, navigation). Some are for the documentation (new topics, different formats). Scope helps prioritise.
2 likes 3mo
k.kuusela, post #34: Feature scope: some requests are for the site itself (search, filtering, navigation). Some are for the documentation (new topics, different formats). Scope helps prioritise. Go to post
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.
Worth separating two things that post #50 runs together.
Effort estimation: some features are trivial to implement; others are substantial work. Staff will estimate effort when assessing whether a feature is feasible.
20 likes 3mo
Picking up post #52: that is the part I would want checked first.
Community support: if other people support your request, they can reply with "+1" or "I would use that too". Widely-requested features are prioritised.
0 likes 3mo
n.cardoso, post #12: 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. Go to post
Tradeoffs: every feature has a cost in maintenance and complexity. Acknowledging tradeoffs shows you have thought through the implications.
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.
13 likes 3mo
Tracking: staff will update the status of feature requests (under consideration, planned, implemented, declined). Checking back lets you know the fate of your suggestion.
27 likes 3mo
Requests for platform and documentation features, with the reasoning that justifies them. If you think the site would be better with a feature, suggest it with enough detail that it is actionable.
2 likes 3mo
I read post #58 twice before replying, because I had assumed the opposite.
Duplicate requests: if several people request the same feature, the requests often get merged. Check whether your feature has already been suggested before posting.
8 likes 3mo