38

I've just sent a bug to the KDE-team and isn't impressed of the tool for doing so. My suggested improvements is:

1. No login for sending the report - I don't want to be forced to create a user just to send a bug report. I imagine a lot of people just don't send them, because they don't care enough to create the user. And as a sidenote, it's a completely redundant annoyance for the user.
2. Don't show technical details - I don't want to see the dumps from the debugging system unless I'm the one programming on the system. Therefore these belong in the final bug report, but should be hidden by the tool and just included.
3. An example of a userfriendly bug reporter
- "XXX has crashed. To help fix this you can report the error. Do you wish to send an error report?" yes/no
- "It would help us a lot if you can tell what you were doing when the error occured. Do you want to use 5 minutes to describe what you were doing?" yes/no
- If yes, then give a textbox to write the text (I suggest that the report tool should also deside the title to make the work easier for the user).
- If no or after writing the text, let the tool collect all the info, send it to whatever bug tracker you use and then confirm that the report has been sent successfully.

How are the developers going to contact you for any additional information if you don't have a login account?

More automatic bug reporting tools are being worked on andd/or tested, but in the end, if you aren't willing to give some time to describe what you were doing, install debug packages, and generally make an effort to gather the relevant information, it's likely that the bug report will have little meaning.

If I were writing the application you describe I'd simply refuse to accept any report where the user had said he was unwilling to describe the situation. I believe one application being tested does exactly that.

I mostly agree with your idea, I just think that login of some kind is necessary. Maybe not the bugs.kde.org, but still...

But this is another idea, so yeah...

annew wrote:How are the developers going to contact you for any additional information if you don't have a login account?

More automatic bug reporting tools are being worked on andd/or tested, but in the end, if you aren't willing to give some time to describe what you were doing, install debug packages, and generally make an effort to gather the relevant information, it's likely that the bug report will have little meaning.

If I were writing the application you describe I'd simply refuse to accept any report where the user had said he was unwilling to describe the situation. I believe one application being tested does exactly that.

Firstly I have to disagree with not accepting bugs where the user don't want to provide more info. The reason for that is that there is a lot of bugs where the only info I can give is: "It just crashed", which is as useful as no info. This goes for almost all background proccesses for instance.

How to contact on the other hand is a good question, what about a voluntarily field for an email? I don't want to force it, since some users isn't interested in answering or might not be able to anyway.

Primoz wrote:I mostly agree with your idea, I just think that login of some kind is necessary. Maybe not the bugs.kde.org, but still...

But this is another idea, so yeah...

Point is, when there is a login there's 90% chance that I drop sending the bug. I think this goes for a lot of other people.

As an example of how stupid the idea with the forced logins is: Try buying something online. Most shops forces you to create a login, but what are the odds of you coming back? What are the odds, if you come back, that you actually remember that you have a login?

Forcing logins here, for shops, to access downloads and a lot of other places is just an annoyance for no real reason.


Lastly, if there really has to be a login, use some kind of openID like gmail. But I can't stress it enough, logins for things like this is plain stupid (unless someone is able to provide me with a really good reason that is).

I would suggest using http://stackoverflow.com/ as a example on how to handle un-registered posting.
Stackoverflow is a perfect example on how to do it, plus it's also a perfect example on how to use OpenID.

OpenID itself should also be supported. It's silly not to.

Unity3D also uses the Stackoverflow Model (the same software actually), at http://answers.unity3d.com/ , which is their bug-reporting "forum".

Firstly I have to disagree with not accepting bugs where the user don't want to provide more info. The reason for that is that there is a lot of bugs where the only info I can give is: "It just crashed", which is as useful as no info. This goes for almost all background proccesses for instance.

On that amount of information, how are the developers going to begin tracking it down? Using debuginfo packages it is almost always possible to get more information, background processes or not.

How to contact on the other hand is a good question, what about a voluntarily field for an email? I don't want to force it, since some users isn't interested in answering or might not be able to anyway.{/quote]

Then I see no point in them posting the bug report in the first place. The whole point of the reports is to help the developers to find the cause of the problem. If the report does not, and the reporter will not respond, the whole process is pointless.

Point is, when there is a login there's 90% chance that I drop sending the bug. I think this goes for a lot of other people.

The only result of that would be fewer useless reports for the bugsquad to triage. Useful bug reports are what is needed.

As an example of how stupid the idea with the forced logins is: Try buying something online. Most shops forces you to create a login, but what are the odds of you coming back? What are the odds, if you come back, that you actually remember that you have a login?

Forcing logins here, for shops, to access downloads and a lot of other places is just an annoyance for no real reason.

That's a very silly argument. Traders of all sorts have to keep legal records of transactions. If you do not create an account, and therefore login, they could not do that.

Lastly, if there really has to be a login, use some kind of openID like gmail. But I can't stress it enough, logins for things like this is plain stupid (unless someone is able to provide me with a really good reason that is).

From what I've seen on userbase, OpenID accounts are next to useless in contacting users by email. Wikis can use them, because they use Private Messages instead of emails for contact, but that is not an option for a bug tracking database, as far as I can see. As far as I know, Private Messages only work on the application that created them. You would have to be continually logged in to the bugzilla site to see them.

I completely agree with this idea. Leave an email field (that can be saved), and a field that asks what you were doing at the time, both optional. I don't know much about this, but why can't debugging tools be installed by default so that it can make a solid, detailed report, and send it to the devs without nagging you to install more software on your computer while you're trying to figure out what crashed in the first place?

Because not everyone can spare 4GB of disk space, to say nothing of the download bandwidth. If you are prompted to download the files relevant to the problem it's much easier for users than having to install the lot, from the start.

Okay, that makes more sense. I was not aware debugging files took up that much space. There really isn't a way to simply log 5 seconds of what you were doing beforehand and send the log and the crash report? Again, I'm not a coder, so I don't how/what needs to be implemented, but I agree entirely that bug reports are way too complex right now.

annew wrote:Because not everyone can spare 4GB of disk space, to say nothing of the download bandwidth. If you are prompted to download the files relevant to the problem it's much easier for users than having to install the lot, from the start.

Sounds like a lot of overhead, but for the record. Who? Come on, were in 2010, a lot of the people I talk to started dealing in tera bytes. Even among the Asus eee most has 80 gb or more. Most new computers (not netbooks) usually don't deal in less than 160 gb (usually way more). Both Windows and Mac don't work in CDs any more but DVDs.

Unless you suggest that we should work accordingly to year 2000 I believe the 4 gb (although aren't that a bit of an overestimation?) won't hurt much.

annew wrote:On that amount of information, how are the developers going to begin tracking it down? Using debuginfo packages it is almost always possible to get more information, background processes or not.

I should actually say that it's not my department. But apart from that, it's true that getting details on what the user what doing at the time can help a lot. What should I tell if Nepomuk crashed and I didn't know what it is? It's not realistic that the user can provide details in all situations.

Now I'm not used to C/C++ but stacktraces from eg. Java and C# is actually enough in a lot of situations. Although it takes a lot of work, agreed, but a lot of problems is solvable without any user details at all.

If the details collected by the bug-tool isn't enough then I suggest taking a deep look on how to heavily improve this. Admitted in can never be perfect, but that isn't a reason not to try.

As much as I hate the reporting in Windows, this seems like the way to go. Only changes to it that I would make, mostly because KDE is in a development cycle, is that the email field and "what you were doing" fields be optional to provide a little more info.

rohdef wrote:

annew wrote:Because not everyone can spare 4GB of disk space, to say nothing of the download bandwidth.

Sounds like a lot of overhead, but for the record. Who?

It's apparent from the forum and mailing lists that we have many users who do not live in the affluent west, or for other reasons have to use less modern hardware than you have. I'm just in the process of retiring a laptop where I recently had to delete over 3GB of debuginfo files because the disk space was running out. And capped bandwidth, over which you pay a hefty penalty, is not unusual in many countries.

annew wrote:On that amount of information, how are the developers going to begin tracking it down? Using debuginfo packages it is almost always possible to get more information, background processes or not.

I should actually say that it's not my department. But apart from that, it's true that getting details on what the user what doing at the time can help a lot. What should I tell if Nepomuk crashed and I didn't know what it is? It's not realistic that the user can provide details in all situations.

That's why debuginfo packages are supplied - to get the information for you.

annew wrote:It's apparent from the forum and mailing lists that we have many users who do not live in the affluent west, or for other reasons have to use less modern hardware than you have. I'm just in the process of retiring a laptop where I recently had to delete over 3GB of debuginfo files because the disk space was running out. And capped bandwidth, over which you pay a hefty penalty, is not unusual in many countries.

There is a lot of complicated parts in this, since this is closing in on what the distros should do and not and not a pure KDE debate.

But when it comes to solving these problems I simply don't know enough about KDEs internal structures, the programming languages you use and so on to provide the perfect idea for a solution. But what I know is that it should be possible.

On a farfetched guess, would it be possible to make a kind of light weight debugging system that don't collect every tiny bit of info?

I don't know why but I sort of have the feeling that the debug tools collect 80% useless things and 20% useful (the numbers is guesses). Although some of the useless still need to be there because of the different natures of bugs, but would it be possible to cut some of the overhead, so it's maybe 50/50? Or is that a sort of dream scenario?

annew wrote:That's why debuginfo packages are supplied - to get the information for you.

True, but this is complementary to the problem of space and all that. Of course as the good boy I am I have installed them.

But the space debate aside, how would you get any more info from the user than you get by politely asking them to descripe what happened and ask for contact information? I believe more users would actually do the reports if the process is done like that. And then you don't force users to provide idiotic informations like "It just crashed" because they don't have the faintest idea on what the cause is.

I disagree with this idea. I don't think the quantity of bug reports should be increased if it means decreasing the quality of each bug report. It would mean harder work simply sorting through the greater number of bugs, managing duplicates (which I'm sure there would be a lot of) and using less time actually fixing them. A lack of information on reproducing the bug would simply mean it would be harder to find the cause and therefore fix the bug.

Conclusion: if each bug is very high-quality (in other words: the user WANTS to be contacted and tries to give as much information as possible), it will result in more fixes than if more low-quality bug reports are reported.

Madman wrote:I disagree with this idea. I don't think the quantity of bug reports should be increased if it means decreasing the quality of each bug report. It would mean harder work simply sorting through the greater number of bugs, managing duplicates (which I'm sure there would be a lot of) and using less time actually fixing them. A lack of information on reproducing the bug would simply mean it would be harder to find the cause and therefore fix the bug.

Conclusion: if each bug is very high-quality (in other words: the user WANTS to be contacted and tries to give as much information as possible), it will result in more fixes than if more low-quality bug reports are reported.

I halfway agree with you, since quantity in itself is never to be desired. But I think you are losing a lot of bugs since the current system is to tedious.

For example I often drop reporting because I'm asked a lot of stupid questions before I can get to the relevant part. And I'm one of those who's able to make good reports. I don't want to think of how many other reports like the ones I could have produced is lost due to tedious systems.

Only positive thing I can think of is that it hides bugzilla, which would have caused med to not report at all.

So I think this is more about making it easier to do, so people actually do it and so bugs get caught in the net and fixed. On a lot of systems I've seen bugs stay for ages because noone wants to report them, often this is due tools like bugzilla or other tools that makes the work tedious to the user.

If you really insist on more info, then maybe do it like this:

Aften agreeing to send the bug, then have the next window with a text-box asking the user to describe what he was doing and a checkbox with something like "I can't/won't specify this information".

Also another detail in your reply is, if bugs are solved faster, due to them arriving earlier, since people actually care to send them, then the fix is done sooner, and the amount of duplicates and such would be as problematic as you describe.