[Meta] Issue closing / labelling policy

[GfEW]

I notice there are various issues marked "completed" that actually got rejected, for reasons like

• being a duplicate (e. g. tabs are only showing as short spaces #239)
• being out of scope of this app (e. g. [feature request] large font sizes for banners #241, Option to change URLs to clickable hyperlinks #242)
• requiring upstream improvements (e. g. enhancement idea: reverse search #233),

to name a few.

Although marking issues "completed" when they are not (in any factual sense comprehensible by the user) may be a common habit, it is prone to leaving issue creators confused, irritated or demotivated.

I think that taking the moment to choose "reject" when appropriate, best accompanied by a more specific, descriptive label (see below), would communicate your point more clearly, especially when you're not going to implement the suggested feature or solution anyway, for whichever reason. Doing so in a straightforward manner could actually serve understanding and facilitate more relevant user interaction, at little to no extra cost.

[GfEW]

Candidate labels to clearly indicate the "issue" with an issue, include:

• duplicate (--> close)
  already dealt with elsewhere; preferrably provide a reference link in a comment so would-be duplicate creators know where to find the original
• wont fix (--> close)
  indicates dead ends at first glance, e. g. in search results, without the need to read through comments; furthermore, issues labeled wontfix can be conveniently referred to in duplicates to get the message across
• upstream (--> keep open, unless unlikely to be fixed)
  would be nice but depends on upstream improvements
• awaiting user input (--> keep open until answered or getting old, and remove the lable when no more questions are open)
  allows interested users to recognize issues that need further testing, answers to your questions etc.
• help wanted (--> keep open until done, or resolved otherwise)
  guides potential contributors to issues that could use their focus most

Obviously, not every one of them has to make sense for this repo -- use them as inspiration as you see fit.