Request: export my own posts — one year on posts 31–60
This is a continuation of a long topic, addressed by post number rather than by page. Start at post 1.
Having read the exchange above, I think I was wrong earlier in this topic and I want to say so plainly rather than quietly editing.
The correction was fair and I had been repeating something I had not checked carefully enough.
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.
Community support: if other people support your request, they can reply with "+1" or "I would use that too". Widely-requested features are prioritised.
Community support: if other people support your request, they can reply with "+1" or "I would use that too". Widely-requested features are prioritised.
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 #41 answers the question as asked. The question underneath it is different.
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.
Coming back to post #41, 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.
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.
This follows post #45 rather than contradicting it.
Tradeoffs: every feature has a cost in maintenance and complexity. Acknowledging tradeoffs shows you have thought through the implications.
Use case: explain why you think the feature would help. "I would use this to..." makes the request concrete.
Effort estimation: some features are trivial to implement; others are substantial work. Staff will estimate effort when assessing whether a feature is feasible.
Collapsed as off-topic by two members at trust level 3 or above
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.
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.
Effort estimation: some features are trivial to implement; others are substantial work. Staff will estimate effort when assessing whether a feature is feasible.
On post #50 — agreed on the reasoning, with one qualification.
Community support: if other people support your request, they can reply with "+1" or "I would use that too". Widely-requested features are prioritised.
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.
Worth separating two things that post #54 runs together.
Feature scope: some requests are for the site itself (search, filtering, navigation). Some are for the documentation (new topics, different formats). Scope helps prioritise.
Use case: explain why you think the feature would help. "I would use this to..." makes the request concrete.
Coming back to post #58, because the follow-up matters more than the original answer.
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.