[Qgis-psc] Changing our default response to requests/bugs?
Nyall Dawson
nyall.dawson at gmail.com
Mon Aug 1 00:33:09 PDT 2016
On 31 July 2016 at 20:54, DelazJ <delazj at gmail.com> wrote:
> Hi,
>
> While I see the points Nyall is raising and understand the underlying
> reasons, I think one important point to be solved - and Jef has pointed it
> out earlier - is when and how will this message be brought to the user.
>
> I'm not sure it's good to have it as automatic first answer for each feature
> request (I exclude bug reports as many already asked). I've personnally made
> many feature requests and I would have found borying, spamming... to
> receive an answer that repeats the same thing for each new request I wrote.
> It may then be counter productive.
> Feature requests, at least for me, are not always features I need but
> features I think could improve the existing behavior. They sound like ideas
> brought to developers or funders.
>
> For me, this kind of message needs to be stated to the user once for all
> (and not every time). If he is not sensitive to it the first time, not sure
> he'll get it the tenth, when he no longer reads it.
> The text needs to be available everytime (without being intrusive) so a
> convenient place could be our website, near (or inside) the bug reporting
> section. I often send people who report issues in french forum to this page
> so that they see/learn the process of bug reporting. Completing this page
> with how requests could be quickly treated makes sense imho. There are many
> people out there ignoring how things are done in an open source project.
> If/When we move to github, then a link to this page can be inserted in the
> issue report template (I don't know if it's possible with the current hub).
> It won't be invasive.
>
Ok, I don't think I got my original intention across very well. Here's
some clarifications:
- I didn't mean that we should discourage reports on hub. Rather, I'm
hoping to give the message that reporting a bug/request on hub is the
*least* that someone can do, and that there's much that they're able
to do to get the bug/feature implemented. The drafted response is
actually intended to *empower* reporters by showing what further steps
they can explore. I see a lot of frustration on the hub along the
lines of "I reported this 12 months ago, it's been reproduced, why
isn't it fixed?". I believe this is because there's a (mistaken)
belief that this is the only way users can get fixes/features into the
project, so they are naturally frustrated when there's no activity on
their bugs. The harsh reality is that it is very rare for a QGIS dev
to proactively fix a bug in which they have no interest (aside from
the pre-release bug fixing sprint). Instead, developers generally only
tackle changes which directly affect them or their clients. We need a
way of informing reporters that they DO have power to influence the
project and make changes happen, and that filing on hub is just the
start of this.
- The draft was also intended to try to entice contributors into the
project. It was partly inspired by this thread -
http://osgeo-org.1560.x6.nabble.com/MS-SQLServer-support-to-DB-manager-td5278151.html#a5278175.
See how quickly the passive "someone should fund this" turned round to
"i'm going to investigate".
- My intention was that the response be used on the mailing lists, not
as a reply on hub. I don't like the idea of spamming hub either.
- Obviously using the response wouldn't be automated, so we'd apply
some common sense about when to use it. I think it's ideal for new
posters who haven't been involved in the project yet, not for people
who are already actively involved.
> Last but not the least, I recall a discussion (raised by Nyall?) about
> writing something (in blog or website) about the different ways to fund a
> feature or bug in QGIS. Haven't seen it yet. Maybe it's time to do it.
Yes - blog posting always gets pushed to the bottom of the todo- list :P
Nyall
>
> Regards,
> Harrissou
>
> 2016-07-31 4:37 GMT+02:00 Mathieu Pellerin <nirvn.asia at gmail.com>:
>>
>> Nyall,
>>
>> I like the idea of coming up with an expanded response to reported issues
>> and feature requests. That said, while I feel your response example is very
>> fitting for feature requests, IMHO it is not proper for issues / bug raised
>> by users.
>>
>> While I agree that a person requesting a yet-to-be feature should be
>> invited to take on the responsibility of seeing it implemented, I don’t
>> think this is right to deliver the same message to QGIS users and testers
>> when it comes to issues they stumble upon and report. Doing so could risk
>> leaving users with the impression that the QGIS community does not welcome
>> issue reporting, which would be harmful to the project.
>>
>> For one, we actually incite issue reporting during the freeze period at
>> the end of each development cycle to insure we ship a stable product. We’re
>> requesting users to donate time and energy to test out the software and
>> report bugs, that’s extremely important and should be encouraged, not
>> dissuaded.
>>
>> This is especially true for new features introduced during a development
>> cycle, whereas a paid / sponsored developer benefits from free user testing
>> and reporting to insure that the feature he / she was financed to code is
>> rock solid.
>>
>> Therefore, I think we should come up with two template responses: one for
>> feature requests (I can’t think of ways to improve your text above), and one
>> for issue reporting. When it comes to the latter, we should:
>> - begin with thanking the user for taking time to report issues, and
>> invite him / her to file an issue on the hub with as much details as
>> possible, stressing need for steps to reproduce issue as a way to ease
>> workload on developers
>> - insure expectations from users reporting issues are managed so that he /
>> she doesn’t expect an overnight response to avoid needlessly frustrating
>> reporters, as well as developers :)
>> - gently invite users to donate to the QGIS project by mentioning that
>> part of the donations go to fixing reported issues in each development cycle
>>
>> Hope those thoughts help out.
>>
>> Math
>>
>> _______________________________________________
>> Qgis-psc mailing list
>> Qgis-psc at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/qgis-psc
>
>
More information about the Qgis-psc
mailing list