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

2024-01-29 Thread Emma Hain via QGIS-Developer 
HI All
I think we need to be kind here so I support a new label 'solution
proposed' with the added automations in closing it. Whilst I agree with
some sentiments in that users need to understand how a lot of info can get
unmanageable and taxing on resources, we need to educate users on how this
stuff works and how we need them to keep on bringing their input to the
project.

So I think on the side of the developer (I am assuming here - please
correct if wrong), when researching the issue, you have found a solution
already and thus it's not too taxing to paste a link to the solution and
label it 'solution proposed' - therefore no more work done.

On the side of the user reporting the issue (which I identify with more),
you are providing an education on how to contribute to the project through
this feedback. Once it is closed, an automatic message could include some
of the following guidelines:

> ...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.
>
>   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.



Cheers
Em

On Fri, 19 Jan 2024 at 18:43, Thomas Larsen Wessel via QGIS-Developer <
qgis-developer@lists.osgeo.org> wrote:

> Nyall wrote: " It seems wrong to just close that issue without giving the
> reporter time to reply  "
>
> If a user spends a long time (for me it sometimes takes as much as a few
> hours, believe it or not) to write an issue, believing it actually is a bug
> or at least an issue with the docs that ought to be corrected, it will like
> seem unappreciated if the issue is closed in the very first
> response, specially if that response is very brief and does not contain any
> appreciation. Even if that is not how it is intended.
>
> When I report issues it's not always because its a real problem for me; it
> is often simply because I believe it's in the interest of the project, and
> it's my tiny contribution to that project.
>
> Tickets that are obviously just questions, should IMO be closed
> immediately, with advice on where to ask such questions. But when people
> report what to them seems like a bug, I would encourage a friendly response
> that signals that even if their effort was in vain because it was not a
> bug, it actually is appreciated. Especially if it's a well written issue.
> I'm afraid that "closed" signals very little appreciation; a lot less
> appreciation than "not a bug" and then closing a few days later. Having an
> issue closed like that seems/feels almost like having a forum thread
> deleted, does it not?
>
> Apropos of appreciation, I really appreciate the work that all of you are
> doing for QGIS and other FOSS. Have a nice weekend :)
>
> Sincerely, Thomas
>
>
> On Thu, Jan 18, 2024 at 10:01 PM Sandro Santilli via QGIS-Developer <
> qgis-developer@lists.osgeo.org> wrote:
>
>> On Wed, Jan 17, 2024 at 08:57:33AM -0500, Greg Troxel via QGIS-Developer
>> wrote:
>>
>> > So I would say:
>> >
>> >   Establish a policy that questions are not allowed in the issue
>> >   tracker.  Follow it strictly.
>>
>> +1 and there's now an experimental Discourse service of OSGeo that
>> could be used for questions: https://discourse.osgeo.org
>> (an appropriate category could be added, on request)
>>
>> --strk;
>> ___
>> 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
>>
> ___
> 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
>


-- 
Emma Hain — Product Manager/Senior GIS Analyst
e...@north-road.com
[image: https://north-road.com]
*North Road*
Cartography • Development • Spatial Analysis
--
*north-road.com* 



___
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

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

2024-01-19 Thread Thomas Larsen Wessel via QGIS-Developer 
Nyall wrote: " It seems wrong to just close that issue without giving the
reporter time to reply  "

If a user spends a long time (for me it sometimes takes as much as a few
hours, believe it or not) to write an issue, believing it actually is a bug
or at least an issue with the docs that ought to be corrected, it will like
seem unappreciated if the issue is closed in the very first
response, specially if that response is very brief and does not contain any
appreciation. Even if that is not how it is intended.

When I report issues it's not always because its a real problem for me; it
is often simply because I believe it's in the interest of the project, and
it's my tiny contribution to that project.

Tickets that are obviously just questions, should IMO be closed
immediately, with advice on where to ask such questions. But when people
report what to them seems like a bug, I would encourage a friendly response
that signals that even if their effort was in vain because it was not a
bug, it actually is appreciated. Especially if it's a well written issue.
I'm afraid that "closed" signals very little appreciation; a lot less
appreciation than "not a bug" and then closing a few days later. Having an
issue closed like that seems/feels almost like having a forum thread
deleted, does it not?

Apropos of appreciation, I really appreciate the work that all of you are
doing for QGIS and other FOSS. Have a nice weekend :)

Sincerely, Thomas


On Thu, Jan 18, 2024 at 10:01 PM Sandro Santilli via QGIS-Developer <
qgis-developer@lists.osgeo.org> wrote:

> On Wed, Jan 17, 2024 at 08:57:33AM -0500, Greg Troxel via QGIS-Developer
> wrote:
>
> > So I would say:
> >
> >   Establish a policy that questions are not allowed in the issue
> >   tracker.  Follow it strictly.
>
> +1 and there's now an experimental Discourse service of OSGeo that
> could be used for questions: https://discourse.osgeo.org
> (an appropriate category could be added, on request)
>
> --strk;
> ___
> 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
>
___
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

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

2024-01-18 Thread Sandro Santilli via QGIS-Developer 
On Wed, Jan 17, 2024 at 08:57:33AM -0500, Greg Troxel via QGIS-Developer wrote:

> So I would say:
> 
>   Establish a policy that questions are not allowed in the issue
>   tracker.  Follow it strictly.

+1 and there's now an experimental Discourse service of OSGeo that
could be used for questions: https://discourse.osgeo.org
(an appropriate category could be added, on request)

--strk;


signature.asc
Description: PGP signature
___
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

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

2024-01-17 Thread Greg Troxel via QGIS-Developer 
Nyall Dawson via QGIS-Developer  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

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

2024-01-17 Thread Julien Cabieces via QGIS-Developer 


Hi,

Why not using simply "Feedback" label in this kind of situation ?

Regards,
Julien

> Hey all,
>
> 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...
>
> Nyall
>
> ___
> 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


-- 

Julien Cabieces
Senior Developer at Oslandia
julien.cabie...@oslandia.com
___
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

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

2024-01-17 Thread Stefanos Natsis via QGIS-Developer 
Hi Nyall,

How about a 'Not a bug' one instead? 'Solution proposed' kind of implies a
way to avoid a valid bug.

Stefanos
___
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

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

2024-01-17 Thread Nyall Dawson via QGIS-Developer 
Hey all,

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...

Nyall
___
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