A request that was declined, and the reasoning — a second dataset posts 31–60
This is a continuation of a long topic, addressed by post number rather than by page. Start at post 1.
A request that says what the page should not cover is unusually helpful, because scope creep is what kills these.
I have kept the units in throughout, for the obvious reason.
Answering the question post #30 raises rather than the one it answers.
Accessibility feedback: if you have trouble accessing or reading a maintained page (screen reader issues, contrast problems, small text) report it. Accessibility matters.
Adding this to the thread rather than to the wiki, because I am not confident enough for the wiki.
Useful. I have added it to my own notes with the date on it.
Narrowing post #35, because the general version has more than one answer.
Documents that are mostly a worked example age better than documents that are mostly a summary, because the arithmetic does not change.
Not disagreeing with anyone above, just adding the bit I keep having to look up.
Everything in post #34 holds. The case it does not cover is the one I have.
If a request is declined, the reasoning is written down, and it is worth reading because it usually describes a better version of the same idea.
Confirming post #37 from a second method, which matters more than confirming it from a second person.
The most useful requests here identify a specific confusion that keeps recurring rather than a subject that seems important.
Reading it again, the caveat matters more than the finding.
I had written a reply contradicting post #38 and deleted it. Here is what survived.
Format suggestions: if you think a maintained page could be clearer in its presentation (different section structure, different examples, added graphics) suggest the change.
Coming back to post #39, because the follow-up matters more than the original answer.
Say what would make the page wrong. A page whose failure conditions are stated is much easier to review honestly.
Post #39 is right about the mechanism and I think understates the practical bit.
Format suggestions: if you think a maintained page could be clearer in its presentation (different section structure, different examples, added graphics) suggest the change.
Adding thanks rather than a view. I do not have a view worth the space.
Post #43 answers the question as asked. The question underneath it is different.
Requests for a page summarising a supplier are declined, because that is what the vendor documentation set is for and it has its own standards.
Requests for a document covering something the evidence does not support get declined, and the decline usually points at what could be written instead.
Worth reading the earlier posts in this thread before acting on mine.
Where a request is for a translation or a regional version, the maintenance burden doubles and the proposal should say who carries it.
That is the version I use. It may not be the version that is correct.
Scope the request narrowly. A page about one thing gets written and stays current; a page about a field does not.
That holds for the case as described. Change the assumptions and it may not.
Building on post #50 rather than restating it.
Documents that are mostly a worked example age better than documents that are mostly a summary, because the arithmetic does not change.
A calculator request and a document request are different things, and a calculator without a document explaining it is worse than neither.
The most useful requests here identify a specific confusion that keeps recurring rather than a subject that seems important.
Worth saying I have only my own numbers here, and n is small.
Bookmarking this. I will come back when I have something worth adding.
If a request is declined, the reasoning is written down, and it is worth reading because it usually describes a better version of the same idea.
I would want the raw data before agreeing with my own summary of it.
Say what would make the page wrong. A page whose failure conditions are stated is much easier to review honestly.
A weak preference rather than a position.