It does not really make sense to close feature requests. At least not to me. Not even bug reports should be auto closed. Maybe labelled with “missing version info” plus a comment added that asks for the version info would be a better idea (we do not want to discourage users too much, closing an issue because of a minor oversight just feels like a step to far to me).
The bot helps to put an impersonal face on the requirements. Otherwise, it is up to our bug squad and developers to try to get reporters to include version information. For some, it is an oversight. They are easy and will add the version information and life goes on.
But then there are the 1-2% who just want to argue about whether they really need to include the information that we ask for. This invariably sets up an argument that we need to have over and over and over again. This takes time that could be spent productively improving KiCad. And it accelerates burnout as the same people have to deal with this behavior every time.
Because the bot will not allow reports without this information, we avoid the arguments and thus gain the lost time and lessen the burnout.
But why close instead of just marking? Because open issues still require human attention to handle. By closing, it notifies the reporter but does not require additional interaction from the team. The reporter can always re-open the issue once they add the required information.
This also helps to keep us honest. We (the lead development team) sometimes would take shortcuts in reporting issues that we encounter. We don’t really want to correct each other on our reports as this doesn’t set up a good team dynamic. But the bot can.
Lastly, moving to GitLab has increased the number of reporters and issues we have by at least 10 fold. This is good news because we have a larger pool of testers and will be able to correct more issues. But if we don’t automate as much of the reporting process as we can, this is cease to be a net positive as we don’t have 10x as many volunteers to handle/reproduce and classify the reports.
10 Likes
This all is true (I know it firsthand because I have been janitoring the issue database) but it doesn’t take away the fact that letting the user create an issue and then closing it feels impolite.
The underlying technical problem is that the default issue system of gitlab isn’t a full blown issue system – or it hasn’t been configured properly. To meet more complicated needs it would need for example a list of versions and platforms to choose from. It’s much more user friendly to add “required field” and not let the user continue further, just like in most web interfaces, than to first open the door and then slam it on their face, so to speak.
1 Like
Perhaps adding Absolutely required! Get your act together! to the version part of the issue template is a first step?
If people still don’t read it, well, let the bot slam the door.
Isn’t there a way to specify in the template that a field is mandatory, like how payment screens on shopping sites will bounce the submission if a field like the card expiry date is not filled in?
Really what does it matter if issues are kept open? I can tell you that i stopped contributing to a few open source projects because of exactly such an automatism. In the end the label is the same as closing but just feels less harsh if you are on the receiving end of it.
Remember one can filter by “is open AND is not labelled requires more details”. I did this routinely on the pull requests for library assets. (There i filtered for the label “still needs review” but the same can be applied to any label)
By the way closing issues at any chance is ones typical experience with outsourced IT services so this also reminds me of that (who ever has good experiences with these services?). But there it is at least explained by the strange incentive system where the employees are ranked by how many issues they closed.
I think that’s exactly what’s lacking in the gitlab interface. There’s only the title textfield and the description text field. Even doing the automated checks before submitting would be better. One moderately easy compromise solution could be to have the ability to add more named text fields and mark them as required so that they would be checked on the fly and other text fields would be disabled until the input has been accepted. I don’t know how much customizable the gitlab interface is.
Gitlab does not really have fields, it just has one big textbox. (not that it is alone here, one big textbox seems to be kind of the standard for all the major issue trackers)
I don’t know how much customizable the gitlab interface is.
We can’t add specific fields like you are asking for (but again, this isn’t unique to gitlab, I’m not aware of any public bug tracker that lets you set up this kind of custom form with custom validation)
If the issue remains open, contributors generally do not go back and add their version information until prodded.
I am working on making the bot more “friendly” but experience has shown that closing is the best way to get the required information. Back at Launchpad, we used to mark the issues “need-info” when they were missing version information. The bot would close the issue after 30 days. But people did not add the version information. Or, they would respond with the filename or just say “5.1.2”. None of this was helpful and took more maintainer time.
I am far more worried about losing developers and bug squad members than losing new issue contributors who don’t read the instructions (the only people this affects). And I am optimizing for exactly this.
Additionally, this may become mostly moot in v6 thanks to @craftyjon’s addition of the “Report Bug” menu option that will report an issue and populate the needed fields
4 Likes
Perhaps adding
Absolutely required! Get your act together!to the version part of the issue template is a first step?
If people still don’t read it, well, let the bot slam the door.
The instructions in the issue template are already pretty explicit. Anymore explicit and we get accused of being impolite/bossy 
.
1 Like
Hey, while all this conversation about the bot’s actions is interesting and all, can anyone give me a version string that I can put in the issue. I could put my version string in there (from 5.1.7), but I don’t think that is applicable for the idea that I’m spitballing because the prerequisites of what I’m asking for don’t exist in my version.
Pinging @eelik to remind him if it isn’t there today… 
You can just put in 5.1.7, it doesn’t matter (this feature doesn’t exist in any version yet)
Mandatory adding of version info for bugs seems a good compromise to me, as I care more for lowering the work pressure for developers so they can focus on more productive tasks then for babysitting people who can not read. The message from the KiCad bot may be considered “rude”, but it’s short and clear.
@SembazuruCDE
I’d think that adding somebody else’s version info to your feature request only generates confusion.
How can you be sure that your feature request is not (partially) implemented, or another but similar, or overlapping feature, etc, for a future version of KiCad version you do not even use yourself?
1 Like
I think we need special handling for wishlist items then. Or at least make it clear via the bot what to do in that case.
The way we want people to handle this is to just use their own version, even if it’s old. The bug squad / dev team can take care of closing issues if they are already taken care of in master (which the one that started this thread is not) or marking them as duplicates.
It doesn’t work perfectly because it doesn’t accept older bug fix versions (5.1.6). Not everyone has a possibility to update to the latest.
Ok. Updated with my version info and re-opened. Thanx all.
I already had guilty conscience.
Hopefully “new issue contributors” and “potential customers” are orthogonal items…