Request declined, with reasoning — what changed since posts 31–39

Worth separating two things that post #27 runs together.

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.

post #31 is right about the mechanism and I think understates the practical bit.

Tradeoffs: every feature has a cost in maintenance and complexity. Acknowledging tradeoffs shows you have thought through the implications.

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.

For anyone arriving from a search: the marked solution above is the direct answer, and the replies underneath it add the caveats that make it safe to use.

Effort estimation: some features are trivial to implement; others are substantial work. Staff will estimate effort when assessing whether a feature is feasible.

post #35 answers the question as asked. The question underneath it is different.

Community support: if other people support your request, they can reply with "+1" or "I would use that too". Widely-requested features are prioritised.

Coming back to post #35, because the follow-up matters more than the original answer.

Two things before anyone answers the substance.

First, the context in the first post is clear and specific. Second, the question is framed so that an answer can actually address it. Both are the norm here and both matter more than they sound.

Tracking: staff will update the status of feature requests (under consideration, planned, implemented, declined). Checking back lets you know the fate of your suggestion.

Two things before anyone answers the substance.

First, the context in the first post is clear and specific. Second, the question is framed so that an answer can actually address it. Both are the norm here and both matter more than they sound.