|
|
| (29 intermediate revisions by 6 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:
| |
| | |
| #'''Steps to reproduce'''. That is, a detailed sequence of steps the developer canfollow to see the problem on their own server. It is very hard to fix a bug that is not reproducable. If possible, give us a URL so we can see the problem with one click.
| |
| #'''What I expected to 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). | |
| | |
| Here is an example of [http://moodle.org/bugs/bug.php?op=show&bugid=6030 a good bug report], [http://moodle.org/bugs/bug.php?op=show&bugid=5688 and another].
| |
| | |
| *If you have an error message, or information in your PHP or web server logs, copy and paste it exactly into the bug report. If you can, turn on "debug" in your Admin configuration page and reprodoce the problem to get the best possible error message.
| |
| *Screen shots are very helpful for some bugs, but please write a textual description of the problem too.
| |
| *Make sure we know everything we need to know about your setup. The OS, Database, etc. fields at the top right of the form give some of the information, but if in doubt add more in the description. The full set of information that might be relevant is:
| |
| **Server operating system type and version number
| |
| **Web server type and version number
| |
| **PHP version number (and whether you are using an accellerator)
| |
| **Database type and version number
| |
| **Moodle version (this is probably covered by the dropdown at the top of the form.)
| |
| **Client-side operating system type and version number
| |
| **Web browser type and version number
| |
| | |
| You don't need to give all those details all the time. For example, for a layout rendering problem, you need to give only the client-side OS and browser info, and if it is a server-side problem you only need to describe the setup there. Use your judgement. Here are some examples:
| |
| | |
| ::I see this bug with the latest Moodle HEAD running on PHP5.1.2/Apache 2.2.3 on Linux. My database is Postgres 8.1.
| |
| | |
| ::This rendering problem happens on IE5.0 on Windows 98.
| |
| | |
| In summary stick with facts and present enough facts so someone else can try to duplicate the problem.
| |
| | |
| ==Tracking progress of bugs you have reported==
| |
| You will receive email reports of updates to bugs you report unless you un-tick "Receive notifications of issue changes via email" on your personal page in the Bug Tracker.
| |
| | |
| However, this is a stupid thing to do if you want you bug fixed. It is very likely that the person who sits down to fix the bug will need to contact you for more information. They will add a comment to the bug with their question, and expect you to respond. If you don't respond, your bug is unlikely to get fixed. None of us want that.
| |
| | |
| ==Tracking bugs reported by others==
| |
| Enter your Bug Tracker user name (this may be different to your Moodle.org user name) in the "Add CC" field for the bug you wish to track and click the "Save changes" button. You will receive email updates on the bug.
| |
| | |
| == 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]]
| |
