I notice there are various issues marked "completed" that actually got rejected, for reasons like
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.
I notice there are various issues marked "completed" that actually got rejected, for reasons like
duplicate(e. g. tabs are only showing as short spaces #239)out of scopeof this app (e. g. [feature request] large font sizes for banners #241, Option to change URLs to clickable hyperlinks #242)upstreamimprovements (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.