Tweaking custom close reason for poorly framed code debugging/writing/improving questions?

Question

In Shortest code to reproduce GIS programming problems I think we made good progress on getting a more useful set of custom close reasons for GIS SE.

However, I think the current wording of our newest custom close reason (borrowed from Stack Overflow):

Questions seeking debugging help ("why isn't this code working?") must include the desired behavior, a specific problem or error and the shortest code necessary to reproduce it in the question itself. Questions without a clear problem statement are not useful to other readers. See: How to create a Minimal, Complete, and Verifiable example.

is overlooking two closely related classes of question which I find problematic because they ask for code to be:

• supplied but show no evidence of having attempted to write any e.g. https://gis.stackexchange.com/questions/156564/how-to-export-coordinate-x-y-system-from-dwg
• reviewed and improved without having reduced it to a code snippet e.g. Request for feedback on python script to increase efficiency with cursors (I don't think we offer a GIS Code Review)

Answer 1

I propose that we tweak the wording above to become something slightly broader:

Questions seeking help to debug/write/improve code must include the desired behavior, a specific problem or error and the shortest code necessary to reproduce it in the question itself. Providing a clear problem statement and evidence of a code attempt will help others to help you. See: How to create a Minimal, Complete, and Verifiable example.