when to create or close issues

source/handbook/product/index.html.md

@@ -839,23 +839,32 @@ description always reflects the latest decisions at any given moment.
 previous content, as long as it reflects the latest decisions.
 * It's not shipped until it's documented, no matter what the change is.
-#### When to create an issue
-Issues are free, and inspiration perishable. So in doubt, always create an issue.
-
-In particular you should always create an issue if (assuming there isn't already an issue for it):
+#### When to create or close an issue
+You should create an issue if:
+- There isn't already an issue for what you're intending to write. Search first
 - a feature is mentioned in chat channels like #product, #competition or elsewhere
 - a customer requests a particular feature
 You should consider **not** creating an issue when:
+- It's an iteration on what we haven't built yet.
 - you're planning ahead very far and it's something specific. The further away something is,
 the more vague or encompassing the issue should be. This will reduce the total amount of issues. E.g.
 create one issue for a new feature, rather than several issues that will follow each other.
 - there is an existing issue. Even if the quality is low, people might link to it. Consider rewriting the 
 description and leaving a comment that you did so. Closing issues to reopen the same issue is generally not a good idea.
+Close issues that are:
+
+- an iteration on something we haven't built yet and are unlikely to ship in the near future
+- duplicated elsewhere
+- no longer relevant due to other reasons.
+
+When closing an issue, leave a comment with why you're closing the issue and link
+to anything of relevance (the other duplicate, the original feature that this is an iteration on).
+
 ### Where should you look when you need help?

[🚄 Job van der Voort 🚀]

cc @gl-product