No direct 2.0 blog post this week, the next one will be discussing the differences between various scanner models, a topic I need more time to write about since its far from easy. Instead, an older entry I had saved as a draft but never published so far, and looking for an excuse to use it in the 2.0 blog posts line, which is kind of important at least for error reporting on the 2.0 beta 
---
Many might have noticed that I set a high value on proper bug reporting, but what exactly is it that I tend to see as proper? Are these universal standards or personal approaches? I decided to blog a few guidelines and my own opinion on them including some reasoning.
1. Versions. If you report an older version, whoever is going to help can first look up the history of changes since that version. Reporting the used version might make it unnecesary to even try to reproduce a bug, saving a lot of time for the developer/supporter, which in the end is to your benefit as well, since you'll get a faster answer. That's universal imho, a detail that belongs into every bug report.
2. Experienced vs. Expected. This might sound obvious, too, but this actually forces the reporter to think a bit more. Reports like "My X stopped working" are highly unlikely if you adhere to this requisite, since everyone would immediately notice that the "Expected" answer "I want it to be working" does not sound like a useful report. Complaining that a product does only support IE does not really help improve the situation, expressing the expectation that it supports HyperBrowser 11.7, but you could not see it listed as supported, does. Since I like maths, it really comes down to these two lines:
You'll notice that I try to enforce this for every single report on our bugtracker. I can't emphasize enough how essential this one is in error reporting!
3. Steps to reproduce. Again, very universal. Explaining your steps might help the person helping you to identify where you've tried something the wrong way (ultimately it would most likely be the fault of the developer who hasn't made it intuitive enough then). And it helps the person trying to fix a bug to easily locate and test it.
Ok, and while this helps both the helper and the helped, I should admit one thing: developers, myself included, are sometimes just too lazy to create well formed error messages, making the whole thing more troublesome than it should be :lip: So here are three points for the other side as well.
1. Error messages should tell that a problem occured - obviously, not much to say about.
2. Error messages should mention likely reasons. Messages like "Could not save file" is just not helping the user in any way, but letting him know that permissions were lacking might.
3. Error messages should suggest alternatives. Not every user is knowledgeable enough to correctly interpret reasons. In the case above, a suggestion to save in a place where he has permissions could do.
You should see those addressed in another blog post about Spybot 2.0
---
Many might have noticed that I set a high value on proper bug reporting, but what exactly is it that I tend to see as proper? Are these universal standards or personal approaches? I decided to blog a few guidelines and my own opinion on them including some reasoning.
1. Versions. If you report an older version, whoever is going to help can first look up the history of changes since that version. Reporting the used version might make it unnecesary to even try to reproduce a bug, saving a lot of time for the developer/supporter, which in the end is to your benefit as well, since you'll get a faster answer. That's universal imho, a detail that belongs into every bug report.
2. Experienced vs. Expected. This might sound obvious, too, but this actually forces the reporter to think a bit more. Reports like "My X stopped working" are highly unlikely if you adhere to this requisite, since everyone would immediately notice that the "Expected" answer "I want it to be working" does not sound like a useful report. Complaining that a product does only support IE does not really help improve the situation, expressing the expectation that it supports HyperBrowser 11.7, but you could not see it listed as supported, does. Since I like maths, it really comes down to these two lines:
Bug/Error/Feature Request = Expectation - Experience
and
Report = Situation + Bug/Error/Feature Request
and
Report = Situation + Bug/Error/Feature Request
You'll notice that I try to enforce this for every single report on our bugtracker. I can't emphasize enough how essential this one is in error reporting!
3. Steps to reproduce. Again, very universal. Explaining your steps might help the person helping you to identify where you've tried something the wrong way (ultimately it would most likely be the fault of the developer who hasn't made it intuitive enough then). And it helps the person trying to fix a bug to easily locate and test it.
Ok, and while this helps both the helper and the helped, I should admit one thing: developers, myself included, are sometimes just too lazy to create well formed error messages, making the whole thing more troublesome than it should be :lip: So here are three points for the other side as well.
1. Error messages should tell that a problem occured - obviously, not much to say about.
2. Error messages should mention likely reasons. Messages like "Could not save file" is just not helping the user in any way, but letting him know that permissions were lacking might.
3. Error messages should suggest alternatives. Not every user is knowledgeable enough to correctly interpret reasons. In the case above, a suggestion to save in a place where he has permissions could do.
You should see those addressed in another blog post about Spybot 2.0