On Fri, 17 Mar 2006, Zeljko Filipin wrote: > I think we should put something like this at some visited place:
People who don't bother to provide full information are probably "too busy" to read such a document. However: > We would like to help you, but we are very busy. We answer e-mails > inour free time, so please help us help you. We will first > answere-mails that follow this simple rules. > From The Basics of Bug Tracking (FogBugz Documentation): (presumably that isn't on line? It would be useful to know...) > Every good bug report needs exactly three things.1. Steps to > reproduce,2. What you expected to see, and3. What you saw instead. > We should also add: > 4. Please provide your script and html. Please make it as short Could Watir have a --bug-report option that collected this information? It should have access to the script and the HTML, should be able to record it's own version number, and extract RUBY_PLATFORM so we know what this is running on (OK, only Windows works for now, but there's native and cygwin). > aspossible. Remove all code and html that is not necessary to > reproducethe problem.5. Please search mail archive and faq. Your The --bug-report option could possibly fail for cases bigger than 5kB. Or something. > problem may be alreadysolved. Wa are very sad when we see a question > that is alreadyanswered (and we can not answer your question with > eyes full oftears). If you find an answer in mail archive and not in > faq, pleaseadd it to faq. It would not hurt to remind people of where the FAQ is when the prototype report is generated. Adding an automatic search is probably overkill. For those searching the archives, at present the FAQ is here: http://wiki.openqa.org/display/WTR/FAQ > We should also link to http://www.catb.org/~esr/faqs/smart-questions.html > I am not a native speaker. I tried to use style that is friendly, butI am not > shure if I did a good job. The tone of ESR's document is felt to be harsh by some people. I don't know if my document http://www.eng.cse.dmu.ac.uk/~hgs/support.html is more useful in that respect, but the context is narrower -- it is designed for where I work. Feel free to adapt it. As to why this is happening: many people have testing thrust upon them, and are inexperienced in what makes a good report and what doesn't. People assume that developers will be so familiar with the code base that even a sketchy report will suffice. And familiarity with an area means it can be hard to understand why other people don't see things the same way: "I thought that was obvious". HTH Hugh _______________________________________________ Wtr-general mailing list [email protected] http://rubyforge.org/mailman/listinfo/wtr-general
