closing issue situations #1510
closing issue situations #1510
Conversation
| - it's a duplicate of another issue | ||
| - it contains a lot of abusive content | ||
|
|
||
| However if an issue is just a stupid feature, it will likely get many 👎but it can be still opened. |
There was a problem hiding this comment.
I think this patch makes sense. Except for this sentence:
However if an issue is just a stupid feature, it will likely get many 👎but it can be still opened.
I would entirely drop it. Why?
- Even mentioning the question if something is "stupid" will likely just open up a can of worms of useless debates.
- The 4 rules already clearly state what is to be closed and what is not.
If you do keep it, I would suggest:
If an issue is not considered a useful feature, it will likely get many downvotes by 👎, but it will not get closed.
(added comma after thumbsdown, used different wording for "stupid" and changed "can be still opened" to "not get closed" because an issue will get opened in any case, so I found that was misleading)
Disclaimer: I am not a maintainer here or native English speaker, it's just my opinion.
There was a problem hiding this comment.
I agree this needs reworded to be less offensive, but the clarification should remain, as stupidity is often more controversial than abuse. 🤷♂️
| or explicitly says WONTFIX, which almost never happens nowadays. | ||
| Issues will only be closed in one of the following situations: | ||
| - once GitHub implements / fixes it | ||
| - GitHub explicitly says it's a WONTFIX, which almost never happens nowadays |
There was a problem hiding this comment.
This certainly almost never happens. However it's also an extremely difficult task. I can't say for certainty that GitHub will never implement a given request. A system that was more flexible would be more possible to work within. For example I could much more easily mark an issue unlikely which may translate to wontfix for some but for myself more accurately represents the situation. At this point in time I can make a call about many features but that won't hold true forever.
I'm not trying to nitpick with semantics here but allow a way for me to represent what I know accurately.
There was a problem hiding this comment.
There was a problem hiding this comment.
I also think I understand that you'd like to implement #472, @ least for this repo & those like it, for such otherwise open issues. 🙇
Wait, what? Are you reading my GitHub emails? 😄
That's likely an ideal solution to this problem. Might be nice if I could set a "GitHub priority" and there could also be a "Community Priority" that wasn't set by me.
There was a problem hiding this comment.
Until y'all do have #472 officially accomplished, such could be kludged in via abusing Milestones or even more Labels, I suppose? 🤷🏾♂️
No description provided.