Description of problem:
Every new version of abrt seems to bring its own stupidness, and hinderences to report a bug in a sane way, and with Fedora 16 it even got worse!
Nowdays you ALWAYS have to type something into the comment field BEFORE you know anything about the bug or even do NOT HAVE TO!

In this case see the following scenario:
My kernel gives a BUG_ON/WARNING_ON. ABRT picks it up. I want to report it to kerneloops.org.
Now to send it in I have to:
1. Write a comment
2. choose if I want to generate/update a smolt profile
3. choose to report to kerneloops.org
4. choose what to report to kerneloops.org.

Now here comes the questions: how much of these things do kerneloops.org even accept? Last time I checked only the stacktrace. So why do I have to enter a comment and choose to not generate a smolt profile?

It gets even more funny if I crash empathy.
Now I have been hit by a long standing crash with empathy time and time over, which is already reported. You can recognize it in the backtrace.
So nowdays to analyze if this is the same bug I hit again (and maybe able to write a comment in the right bug, or a more informative comment in a new bug) I have to jump the following hoops:
1. Write a arbitrary comment
2. choose to generate a backtrace
3. choose to not generate a smolt profile
4. choose to report the bug (to logger or bugzilla)
5. analyze the backtrace
6. back out to step 1 and repeat but with more informed information.


So how could this be done better?

1. Do things in the right order and have them depend on each other!

1.1 Start with what reporting plugin!

1.2 Then backtrace ASAP!!!
 - This will make sure that people who actually can analyze it do not have to jump too many hoops to be able to do it
 - If you think it that it is more userfriendly to start with the comment you are wrong. As a new user to have to come up with a comment and then be presented with a backtrace wall of text is a no-go. It would be better to have a button called "Help!" with a textbox saying "just look so that it does not contain any passwords , names or other personal information".

1.3 Present the user with dialogs based on the choose reporting plugin (i.e. NO COMMENT-step if the target does not support comments, NO smolt if the target does not support )


2. Do as much as possible in one go!
 - for example, with smolt, why do we have to stop the guide to generate the profile? I think it would be better to have everything that generates output the user do not approve in one go, last with the actual send. the user should have to wait as little as possible to provide new data.




So with other words, the flow should go:

1. Choose plugin so abrt know what it needs to generate.
2. generate all output the report plugin wants and that the user need to approve. If possible give the user the choice to background it.
3. collect all the information needed from the user the plugin wants and the user needs to enter and approve, in order of what may create the best user-written comments from an informed user, and with a layout less confusing for a novice.
4. generate and send anything else. With the possibility to background it.