CLOSED: BUG Report GUI

[Geert Janssens]

On donderdag 30 maart 2017 21:27:27 CEST ppssupport at hotmail.com wrote:
>    Hi everybody,
>    It seems that mailing list or bug tracker definition is very vague.

In a way it is.

Perhaps we have different notions of what is a "bug". Rereading what you wrote 
so far it looks like you are talking of any user problem as a "bug" (let's 
call it a "support issue" for distinction), where I as a developer only 
consider something a bug if the code doesn't do what it was intended to do. 

>    While saying that the mailing list is not for bug, why then
>    installation problem appears in the mailing list?

Two reasons immediately come to mind:

1. Many people don't think of a bug first when hitting a problem. They are 
stuck and ask for help. They don't care whether their problem is caused by a 
bug or due to something they did wrong. Often they don't have enough knowledge 
to assess this either. So as Mike already suggested it's good to first ask on 
the mailing list. Otherwise our bug tracker would be flooded with support 
requests instead of bugs. As the bug tracker is only used by developers the 
support bandwidth available would be severely reduced in that case. As  would 
the time available to really improve the code.

2. Secondly it's also the nature of people to ask others for their experience. 
Searching the list history or the bug tracker requires some skill. Not 
everybody is equally comfortable with this. We experienced computer users 
sometimes forget this. Particularly since we don't have a direct search 
interface any more for the mailing list archives.

Note by the way one of the mails in the installation thread did mention the 
corresponding bug report.

>    Like I said, I want to help. But I can not effort to read lot of emails
>    to see if the mail is answer or not.

I'm happy you want to help.

I think though we have different expectations of our support channels. If I 
understand you correctly you are looking for a more structured support channel 
where users can register any problem they encounter (bug or not) and these 
support tickets then require more formal resolution (be it help the user do 
things the right way or convert it into a bug report).

This goes way beyond having a mailing list where people can ask whatever and 
(usually) get answers.

>    Therefore I did suggests  a feature to avoid repeatably topics or at
>    least tell someone that the issue is answered.

A fair suggestion. It seems however you're disappointed it was not embraced 
with open arms. I was pretty brief in my first mail so let me expand a bit on 
why I think it can't work as proposed.

1. The basis is a mailing list. Someone sends a mail to it, the list manager 
ensures the same mail is sent to every list subscriber. The important part to 
keep in mind here is you can't alter past messages. It's a write once system. 
So you can't add or alter annotations on messages once they were processed by 
the list manager.

2. Suppose you implement the bug reporting interface in gnucash. What it will 
do is send mails to the same mailing list, but this time annotated (with 
component, status NEW, things like that). So far so good.

3. And then what ? I suppose you expect the person answering the problem to 
alter the annotations (like status SOLVED) ? You didn't describe an interface 
for this, so everybody has to do this manually and deliberately. This is 
*very* unlikely to happen.
Avoiding this would require writing much more than one simple dialog. It would 
require additional dialogs to allow users to answer to support questions, 
which means you also need something to query existing questions and so on. 
Should we consider something like that I think we'd better search for a 
dedicated system rather than implementing this in gnucash. We're talking about 
efforts of several man-years.

4. Next people are currently not finding their issues while searching the net 
for it (like your installation example, it has been reported independently a 
couple of times). Either they didn't manage to come up with the right search 
magic (which I have all respect for) or they just didn't bother searching 
(which is very human). How will your proposal improve this ? I don't see how 
searching or searching habits would improve by only adding a few annotations 
to the mails.

5. Next we have a fairly large group of subscribers to the mailing lists, be 
it via nabble (because they prefer a forum-like interface) or directly 
subscribed to receive mails. Many of these people have their habits of 
contacting the list (again, write a post on nabble or just send a mail 
directly). A number of those would probably try your proposed interface. Lots 
of others on the other hand will just continue to use the mailing lists as 
they always have. So this will give you a mix of traditional mails and 
annotated mails. And you will still have to search all the traditional mails 
in search for answers. If you don't bother and just choose to use the support 
interface, you're probably asking questions that have been answered before. 
Not very respectful to those who spent their time answering the first time.

6. Then to be effective it should be used by everybody. Without it not all 
messages would be properly annotated. This has several consequences:
a. Support requests could only be entered and followed up from within Gnucash 
using your proposed interface (largely expanded as I suggested before). 
Gnucash is only available on desktop platforms. So people would no longer be 
able to use their tablets or phones to ask for help.
b. The mailing list tracking the support requests should only accept messages 
coming from the support interface in gnucash. (I'm still assuming a mailing 
lists as backend for ease of searching and archiving.) The easiest to 
accomplish this would be to make it a separate mailing list. And tell 
everybody that's still asking questions on gnucash-user to instead ask again 
via the support interface in gnucash. At the same time tell everybody that's 
still answering questions on gnucash-user to answer again via the new support 
interface. Wer're talking about creating a lot of friction here. And this also 
brings me to the next point:

7. By creating this support interface you are increasing the number of 
channels to monitor. There is one more now in addition to the ones we already 
have. So you are asking people that are currently subscribed to gnucash-user 
to *also* subscribe to let's say gnucash-support. gnucash-user for interesting 
new stuff and general communication and gnucash-support for their questions 
and for helping other people out. How many are willing to do that you think ?

Finally I think there are software packages that do solve these problems and 
they do it much better than we ever could from inside gnucash.
Some examples
- the software behind https://ask.fedoraproject.org (open source)
- the Uservoice ticketing system (gratis, but commercial) https://
gnucash.uservoice.com
At this point I'm still reluctant to implement any of these simply because of 
argument 7. I'm not  convinced our community is big enough to effectively 
manage more support channels than we currently do.

>    I do not want to create more confusion about my topic and therefore
>    consider this topic closed.

I've bothered to write a long reply just because I felt there was still 
confusion about the topic. That's not a good moment to stop a conversation.

I hope I managed to express my view more clearly this time.

If you feel like adding something to it, by all means do.

Regards,

Geert