GUI improvements suggestions: reported bugs

[mozeq]

Opened '20110331T09:03:00' by elad as https://fedorahosted.org/abrt/ticket/183

When a reported bug is clicked on, it should do one of the following:

1. Open a web browser window with the bug. (Less work)
2. Open a dialog that will show the bug status, links, comments and more info. (Better UX)

Other nice to have improvements:

• Bug status icon (more then just reported/not reported) should be added to each bug (fixed, invalid and so on).
• Bug status change notification/bug comments notification should be added.
  • When a bug is closed (and such feature implemented), ask the user if the bug still persists. If it does, the user should have an option to add a comment (or send a new backtrace), if it doesn't, the bug should be deleted from the list.
• Add an option to add comments to the bug directly trough ABRT (will require some work, but really improves UX)

If I will come up with more ideas, I'll add them to this ticket.

[mozeq]

Added '20110411T14:01:36' by 'jmoskovc'

Replying to [ticket:183 elad]:

When a reported bug is clicked on, it should do one of the following:

1. Open a web browser window with the bug. (Less work)
   Be able to configure in the application what to send with a report #265
2. Open a dialog that will show the bug status, links, comments and more info. (Better UX)
   document abrt-action-analyze-backtrace abrt#209
   Other nice to have improvements:

• Bug status icon (more then just reported/not reported) should be added to each bug (fixed, invalid and so on).
  • quite impossible to do given the fact we have different reporters with different states
• Bug status change notification/bug comments notification should be added.
  • When a bug is closed (and such feature implemented), ask the user if the bug still persists. If it does, the user should have an option to add a comment (or send a new backtrace), if it doesn't, the bug should be deleted from the list.

• the main idea of ABRT is to help user to create the initial report and gather as much relevant data as it can for this initial report. the rest of the bug fixing process should be (imho) done using the tools that were designed for it (trac web, bz web, etc..) So our primary focus is to implement support for various problems that users can run into and help them create a good report of such problem and provide some solutions available at the time when the problem occured(like finding an updated package, searching for similar bugzillas, etc), but the further interaction between the reporter and whoever will provide the solution is out of ABRT scope

• Add an option to add comments to the bug directly trough ABRT (will require some work, but really improves UX)
  • that's something I really like to avoid as I wrote in document abrt-action-analyze-backtrace abrt#209

[ilippert]

the main idea of ABRT is to help user to create the initial report and gather as much relevant data as it can for this initial report. the rest of the bug fixing process should be (imho) done using the tools that were designed for it (trac web, bz web, etc..) So our primary focus is to implement support for various problems that users can run into and help them create a good report of such problem and provide some solutions available at the time when the problem occured(like finding an updated package, searching for similar bugzillas, etc), but the further interaction between the reporter and whoever will provide the solution is out of ABRT scope

I like the main idea of ABRT to get the user to make explicit what happened around the occasion of the problem to be reported.

However, I like to argue that some users (at least I) would be able to provide better reports when I am made aware of similar, or at least, the duplicate reports. That is the case because occasionally, in the duplicate reports, I can find relevant ideas what to check in my system and therefore can provide more relevant descriptions.

[ilippert]

This issue is related to #267