Talk:Reporting bug guidelines
Should We Rewrite?
Instead of taking the first two paragraphs and infusing them with negative feelings, that time could have been better spent in fixing the system. The single best way of making sure the system works is to make it goof-proof. Those who don't set the process up correctly are in no position to complain about the way things are reported.
As an example, to make the system work correctly, there is a need to give the reporters the preferred choices and categories to help them sort their report into the right pile. The alternative is an umanageble chaotic mess, with inexperienced people trying to categorize their problem in unfamiliar territory. However, if this is done, the reporter can search more accurately and make sure of reducing duplicates. If you expect people to search thru literally hundreds of hard-to-decipher titles for the one that might have to do with their problem, then make sure there is no complaint when they get tired and give up. It is unrealistic to expect people, who take time out of their busy schedules to report problems that they didn't create, to get their reports to match someone else's unfamiliar expectations.
Along with my first example, I would suggest that the report title creation be made automated by the choice of categorization. A decision-tree process forces reporters into the correct category and creates an appropriate title form.
And a third example would be to make the search work by first sorting into the correct category. That way, should the ability to find a duplicate require a selection among less obvious choices, it will be from a pile of fewer choices, thereby making it quicker and easier for the reporter to comply with the expectations of techies.
With regard to the rest of the article:
- A glossary of only one item is unnecessary. Rather, simply define the term in context.
- Don't send neophytes off to some other place to do research for you. If you need that research done before posting, bring it all together in one place for the reporters. The odds that they will figure out what you hope they will is zero and none.
- Bug or feature? What is something that should have been done but wasn't?
- I also don't understand the next section having to do with differentiating between responsibilities. I'm afraid I find it confusing. To top it off, the last sentence refers to the next section directly after it. That hardly needs a reference and a link.
- But the next section is not thought out very well either. So a bug is not a bug if it is reported elsewhere? That seems silly. The rest of it simple cries out for the obvious need of a decision-tree setup to help make the system goof-proof.
- In the section about providing the necessary information, don't just tell what you want; explain clearly how to obtain it.
I'm really not sure of the reasoning behind this article. If it is as it is titled, then I can help. But the confusing focus makes it difficult to be sure. It is too long, when it should have given simple steps to help users. If it is worth writing, then it is worth simplifing. This issue was brought up recently by Misfit in the Beginners' Guide talk page because if it so important.
In summary, make the system work properly, and only then write a simple guide for using it.
Thank you. - KitchM 21:35, 30 December 2009 (EST)