|
|
|
|
|
|
by laurent123456
1703 days ago
|
|
|
> Why do they need to be closed? Likewise, why do they need to be open? Closed or open is just a state anyway, since the issue is still there. The fact that it's closed at least makes it clear that we won't deal with that issue (why we won't is explained in the template when the user creates the issue). If it stays open, we also won't dealt with it, but it will give the wrong impression that we might, some day. |
|
|
Closing does not send the same signal as flagging, tagging or simply ignoring. Closing implies finality. It implies it's gone; and in fact it will be gone from most searches.
Edit: to be clear: I don't mind someone closing my PR with a short explanation. Say "thanks for your Makefile, but since we have a lot of developers on Windows, we fear that switching to makefiles for our automation only adds to confusion. So I am closing this". this is very different from a bot coming in and closing such a PR. The latter signals to me "we are so overwhelmed that your help is not welcome so we sent a bot to keep you away from us. No-one even looked at the work you did for us. Now shut up"
Tagging something as "backlog", "someday" or "low-prio" is a far different signal than closed.
Maybe the root of the entire problem lies in the github-issues being too simple for large open source workflows. A lack or additional statuses, a lack of dimensions maybe. open/closed is one-dimensional, tags add a second dimension, and swimlanes when using GH projects a third. Maybe we need "read"/"ignored", or "team assignments" or such as additional dimension. Or maybe we need worked out templates for tagging-structures and workflows? (without it becoming another jira mess)
Because clearly there is a need for workflows on top of Github, as can be seen by people pulling in bots that clearly piss off a lot of other people.