[QGIS-Developer] Adding a "solution proposed" label?

[Greg Troxel]

Nyall Dawson via QGIS-Developer <qgis-developer at 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.