Request: export my own posts — one year on

Request: export my own posts — one year on — setting out what I have, and where I think it stops being reliable.

Nominating something for promotion into the documentation commons.

The topic in question keeps being re-asked, has a good marked solution, and contains a worked example that would be more useful on a page with a review date than buried in a reply. That is exactly the promotion criterion as written.

Objections welcome and genuinely wanted — the whole point of discussing promotions in public is that a bad promotion is harder to undo than a bad reply.

This follows the opening post rather than contradicting it.

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

Worth separating two things that the opening post runs together.

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.

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

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

Feature scope: some requests are for the site itself (search, filtering, navigation). Some are for the documentation (new topics, different formats). Scope helps prioritise.

Picking up post #3: 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.

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.

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.

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

Use case: explain why you think the feature would help. "I would use this to..." makes the request concrete.

I read post #10 twice before replying, because I had assumed the opposite.

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.

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

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

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