Nyall Dawson via QGIS-Developer <qgis-developer@lists.osgeo.org> writes:
> What do we think about adding a new label for GitHub tickets for "solution > proposed"? This could be used for tickets like > https://github.com/qgis/QGIS/issues/55871 where the issue is likely a user > error and a potential solution has been suggested. > > Stale bot could auto close these like it does with feedback tickets. > > It seems wrong to just close that issue without giving the reporter time to > reply, but at the same time it's highly likely to become just another > invalid open ticket if it's not actively managed in some way... My comments are based on my experience maintaining unison (file sync, not geo), which is also on github. I find that some combination of forum culture and github leads to people treating issue trackers as places to ask for help. This is not how Free Software used to be. I spent a lot of time cleaning up unison issues down to a manageable number (300 to 75ish), and adopted a strict policy that the issue tracker is only for - things that are bugs in the source code, with evidence - well-articulated feature requests that are likely of interest to many (fringe ones I file on a wiki page and close the ticket) That leaves out a lot of what gets put in issues. One of the issues is that new issues are typically seen by maintainers while there is a larger community on a mailinglist. It also leaves out "random packaging system X doesn't have the version I want". Those should of course be filed in X's tracker. Questions and support requests I close with a pointer to the mailinglist. I am entirely ok with hitting close once it is established that there is not a bug. I am especially ok when it was a question. The submitter can read it while it is closed, and even comment. It's just that it doesn't show up in the open ticket list. In the case of the ticket you referenced, it's clearly not a bug. So once that's established, if the user needs help to do what they want, they should seek help in a help channel, from whoever wants to help them, rather than it being the obligation of the maintainers who garden the tracker trying to keep it useful. You were already more than gracious and hitting close when you did seems 100% fine. So I would say: Establish a policy that questions are not allowed in the issue tracker. Follow it strictly. Close tickets as soon as you can tell that they are not a defect in the source code. If you are wrong and the person follows up with evidence, hit reopen - no big deal. Use feedback when it is not clear and you have asked for better testing and more log data, but only when you think there could be a bug. When there isn't feedback, maybe leave it open if you feel that there is a real bug lurking that ought to be addressed, and just close it if you don't feel it's over that line. For feature requests that are fuzzy, ask that they get shaken out on some other forum and then refiled, when they can say with some precision what the new feature should do. _______________________________________________ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
