|
|
| (34 intermediate revisions by 7 users not shown) |
| Line 1: |
Line 1: |
| Bug tracking is a very important part of a continous quality control process. Unlike most proprietary software programs, Moodle bug reporting and bug tracking information is open to everyone.
| | #redirect [[dev:Tracker introduction]] |
| | |
| Please register on the [http://moodle.org/bugs Moodle bug tracker] so you can file any bugs that you find and perhaps participate in discussing and fixing them.
| |
| | |
| "Bugs" not only includes software problems with current versions of Moodle, but also new ideas, feature requests and even constructive criticism of existing features.
| |
| | |
| The beauty of open source is that anyone can participate in some way and help to create a better product for all of us to enjoy. In this project, your input is very welcome!
| |
| | |
| == General guidelines ==
| |
| | |
| The best bug reports follow this form:
| |
| | |
| #'''What I did'''. With as much specific detail as possible, including URLs of feeds or URLs of weblogs when appropriate!
| |
| #'''What I expected to have happen'''. Again, with detail. You expectation might mean that our instructions need to improve or our interface should be changed. | |
| #'''What actually happened'''. (With detail.)
| |
| *Screen shots can really help, too—as long as you also use text to explain what’s wrong.
| |
| *Crash logs or error reports if something goes wrong. This can be done by turning on "debug" in your Admin configuration page. Debug is useful because it lets the problem solver know what the software was actually doing.
| |
| | |
| In summary stick with facts and present enough facts so someone else can try to duplicate the problem.
| |
| | |
| == Developer comments ==
| |
| | |
| "What’s the hardest thing about a bug report?" Most of the time fixing the bug is the easiest part. Usually the hard part is reproducing the bug. The developer or problem solver needs to see how it is broke to be able to fix it. And if they can not duplicate the error, then they can not be sure that it is fixed.
| |
| | |
| Good bug reports contain as much detail as possible and are specific. Generalizing and leaping to conclusions in a bug report is not helpful and often incorrect.
| |
| | |
| For example, a bug report that only says "The RSS feed doesn’t support UTF-8" is not helpful. The developer knows that UTF-8 and RSS feeds are compatible. The problem solver has no idea of what the person sees and why they reported this bug. Now there has to be more communication (which is time) to determine what happened.
| |
| | |
| Consider a bug report which says that the descriptions for the specific RSS feed XYZ@abc shows as garbage characters rather than the expected characters.
| |
| | |
| ==See also==
| |
| | |
| *Using Moodle [http://moodle.org/mod/forum/discuss.php?d=43952 How to manipulate Moodle developers] forum discussion
| |
| | |
| *Here is one [http://en.wikipedia.org/wiki/Software_bug definition of a bug.]
| |
| | |
| [[Category:Teacher]]
| |
| [[Category:Administrator]]
| |
| [[Category:Developer]]
| |
| [[Category:Developer tools]]
| |
| | |
| [[es:Sistema de bugs]] | |
