Note: You are currently viewing documentation for Moodle 1.9. Up-to-date documentation for the latest stable version is available here: Bug tracker.

Bug tracker: Difference between revisions

From MoodleDocs
No edit summary
m (redirect)
 
(8 intermediate revisions by 3 users not shown)
Line 1: Line 1:
[[Image:MoodleTracker_logo.JPG]]
#redirect [[Tracker]]
 
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.  Moodle's bug tracking sytem is called '''Tracker'''. 
 
If you're a new Tracker user create a user account [http://tracker.moodle.org here].  It is strongly suggested your Tracker username is the same name you use at Moodle.org.
 
"Bugs" not only include software problems with current versions of Moodle, but requests for new features (enhancements), changes in functionality, even constructive criticism of existing features is welcome.
 
The beauty of open source is that anyone can participate and help to create a better product for all of us to enjoy. In this project, your input is very welcome!
 
== Report a bug ==
#Once you have loged in and are at the [http://tracker.moodle.org Moodle Tracker home page]
#Select "Create New Issue" from the menu under the Moodle Tracker logo
#On Step 1, from the dropdown menu select the "Issue type": Bug, New Feature, Task or Improvement
#On Step 2, you will see a series of dropdown and blank content areas.
##Summary: Just the headline. Give the reader some clues "It doesn't work" is not helpful in this area
##Components: Use the Ctrl key with a mouse click to select one or more areas in Moodle.  For example, you might have found an issue with a question that impacts: Lesson, Quiz and Question components
##Select the Version but if it is not listed, put it in the description
##Environment is for Operating Systems and other stuff. See general guidlines below
##Description tells what is the issue.  See general guidelines below for the best description
##Database, if it is not listed put it in environment with its version number
 
== General reporting guidelines ==
 
The best bug reports contain these elements in the form:
 
#'''Steps to reproduce'''. That is, a detailed sequence of steps a developer can follow to see the problem.  It is very hard to fix a bug that is not reproducible. If possible, provide a URL so we can see the problem with one click.
#'''What I expected to happen'''. Again, provide as much detail as possible. Your expectation might mean that our instructions need to be improved or our interface should be changed.
#'''What actually happened''' (with detail).
 
Here is an example of a [http://tracker.moodle.org/browse/MDL-6030 good bug report] in browse view, [http://tracker.moodle.org/browse/MDL-5688 and here is another].
 
*If you have an error message, or information in your PHP or web server logs, copy and paste it into the bug report. If you can, turn on "debug" in your Admin configuration page and reproduce 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 including operating system, database, etc. If you run out of room in the environment section, add more detail 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 (there is a dropdown menu on the top of the form, if that does not have what you want, add it in the description)
**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 using Internet Explorer 6.0 on Windows XP.
 
In summary stick with facts and present enough facts so someone else can duplicate the problem.
 
==What the priority levels mean==
 
Bugs can be assigned to one of five priority levels. Here is some guidance as to which one to use:
 
''I have just made this up, I am hoping Martin or someone similar will review it and then it can have a more official status''--[[User:Tim Hunt|Tim Hunt]] 07:24, 24 August 2006 (CDT)
 
;Blocker
:This bug completely breaks Moodle, so much so that it is makes it impossible to get any useful work done.
;Critical
:This bug is causing dataloss, serious visible errors for uses, or major parts of Moodle to cease to function.
;Major
:Somthing is broken and there is no way round it, although it is not a serious as a Critical bug, we can't live with it for long.
;Minor
:Something is wrong, but it is possible to live with it for a while, maybe because there is a workaround.
;Trivial
:Something is wrong, and should be fixed eventually when someone has the time, but it is not a big deal to live with it.
 
Imagine similar wording for feature requests etc.
 
==Tracking progress of bugs you have reported==
You will receive email reports of updates to bugs you report.
 
==Tracking bugs reported by others==
You can monitor, or "watch" bugs reported by others.  To do this, open the bug, then select "Watch it" from the left hand navigation panel.
To add others to the watchlist for your bug, open the bug, select the option "Watching" from the left hand navigation panel.  These people will recevie email notification when updates are made to this bug.
 
== Developer comments ==
 
"What’s the hardest thing about a bug report?"  Most of the time fixing the problem is the easy part, the hard part is reproducing the bug.  The developer needs to see how it is broke to be able to fix it.  If they can't reproduce the error you can be sure they won't be able to fix it!
 
Good bug reports contain as much detail as possible and are specific.  Don't generalise or leap to conclusions.
 
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 developer has no idea of what the person sees and why they reported this bug.  In this case more time and effort needs to be expended to determine the problem.
 
Consider a bug report which says that the descriptions for the specific RSS feed XYZ@abc shows unrecognisable characters rather than 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]]

Latest revision as of 10:13, 14 September 2006

Redirect to: