Just to be extra cautious: In no way do I want to complain or demand changes with the following. I want to express my personal opinion and make a suggestion.
Lots of bugs that are feature requests get closed as out of scope or sometimes even just because there is probably nobody around who wants to implement it. I get that it is nicer to diminish the number of issues instead of having it grow. Is this the reason for this “policy” or is there more to it?
A recent example is #3908, which I completely agree is not important, but neither would it hurt. The use case was given (small change in huge folder resulting in binary indication: 99%->100%). Something like this could just be tagged as “Enhancement” and maybe some new tag like “Unplanned” (and in this case “easy”). Maybe someone who knows javascript would like to contribute this eventually.
I want to stress that I am talking about a small subset of issues, which are legitimate but minor/peripheral/… I am not talking about unclear, duplicate or clearly unrelated proposals.
In the end it’s a matter of opinion and hence subjective. To the extent that we have a policy it is documented here. The difference between enhancement, unplanned and being closed is essentially “We might not implement this” vs “We don’t want this”.
(For the specific issue mentioned it could probably have gone either way. I’m inclined to leave it as is because the byte counter is also a bit vague and might not mean what the user thinks it means…)
I never looked at that document, thanks for pointing it out.
I don’t actually want to make this about this particular issue. I looked at this more from the perspective that engaging users is a good thing. Sure it can get annoying, but still you want users to report bugs and wishes. If an issue is closed quickly with the explanation “We don’t want this” this is rather deterring.
I actually intended to find more examples of this, but can hardly find any. Apparently this is not a very common thing and I am a bit over-sensitive xD The general point still holds.
I recommend subscribing to all notifications on the Syncthing GitHub project, reading each and every one of them, and imagining drafting an engaging response. Keep that up for 6 months or more.
After that, I can guarantee that you’ll have a bit of perspective.
Indeed there are multiple sides to this. Ideally every issue should get a kind, useful and human response. In practice I think most do, but I myself err in the direction of not saying much at all and sometimes just adding a label to indicate something has been accepted as a potential feature request. I try to avoid doing that, because as you say someone has put in some effort into filing it and they deserve a human response. On the other hand, many issues (i.e. the bug reports, not necessarily feature requests) are difficult to understand and sometimes poorly researched and it gets tiring to respond to them all. Audrius puts in a huge amount of work here, but on the other hand errs in being too terse sometimes as well. Nobody’s infallible.
Anyone can help out here, by the way. Especially with vetting the bug reports.
The things that we genuinely do not want should of course be closed, but accompanied with an explanation of why.
I can’t say I know the position @canton7 describes, but I can imagine. That’s why I would never take the liberty to criticize and demand anything, I just wanted to understand the particular reasons and maybe start a constructive discussion (which it did).
Regarding vetting bug reports: I have subscribed to the syncthing (core) repo, but usually by the time I notice a new issue, Audrius has already taken care of it
And I don’t think Audrius is too terse, especially considering the mentioned bad reports and often not nearly as factual and decent reactions from users. I think many reporters get upset because they feel that by closing they are shut down, which some examples showed is not the case. When there is ample reasons, issue are reopened. That’s why I thought more tagging instead of closing would help to mitigate (potentially outrageous) negative reactions from reporters.
Please excuse the double post, I just reread my post and I sounded not nearly as positive as it should:
From my small experience bug reporters to Syncthing get an above average human reaction. Even the smallest and most insignificant of request potentially poorly expressed gets a written response. Reactions to “real” requests are handled extremely fast and good assistance is given.
That can also be seen in this topic: I got to realize myself, that my original request is more or less moot, I still got a nice reaction and even explanation.
Enough of this now, lets get back to important stuff
I know this isn’t what you refer to, but I think it’s hilarious that GitHub ships the invalid and wontfix tags by default on new repos. As far as I can tell, the only purpose of those tags is to bitchslap the poor reporting user once and then once more before closing the issue. You’ll note we don’t have those.
But yeah. Sometimes we’re too quick on closing and come to back to “erh, yeah, that is in fact a bug” *reopen*. I often let things stew for a while to see if more info comes in and come by to close later. To the point where I even have a script to flag issues that are without milestone and not touched in x weeks for triaging…
However I think we’re fairly generous on feature requests, accepting most things that might be reasonable as enhancement/unplanned, to the point that enhancement/unplanned often in reality feels like “it’s on the bottom of the todo list, probably will never ever be resolved” which is also a bit sad.
And I don’t think Audrius is too terse, especially considering the mentioned bad reports and often not nearly as factual and decent reactions from users. I think many reporters get upset because they feel that by closing they are shut down, which some examples showed is not the case. When there is ample reasons, issue are reopened. That’s why I thought more tagging instead of closing would help to mitigate (potentially outrageous) negative reactions from reporters.
