|
|
| (94 intermediate revisions by 20 users not shown) |
| Line 1: |
Line 1: |
| [[Image:MoodleTracker_logo.JPG]]
| | #redirect [[:dev:Tracker introduction]] |
| | |
| Bug tracking is a very important part of a continuous quality control process. Unlike most proprietary software programs, Moodle bug reporting and bug tracking information is open to everyone. Moodle's bug tracking system is called '''[http://tracker.moodle.org Tracker]'''. Tracker is a slightly customised version of Atlassian's product [http://www.atlassian.com/software/jira/ Jira].
| |
| | |
| 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. If your Tracker login account doesn't work, try recovering the password.
| |
| | |
| "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!
| |
| | |
| == General reporting guidelines ==
| |
| | |
| Good bug reports address these elements (in the field Description):
| |
| | |
| #'''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 accelerator)
| |
| **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 judgment. 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.
| |
| | |
| == How to report a bug, improvement, or new feature request ==
| |
| NB See the section 'Tracker fields' below for a full description of every field.
| |
| *Login to [http://tracker.moodle.org Tracker]
| |
| *Select "Create New Issue" from the menu under the Moodle Tracker logo
| |
| *From the dropdown menu select the "Issue type": Bug, New Feature, Task or Improvement
| |
| *You will see a series of dropdown and free text fields. Complete as many as you can. Some fields are required while others are optional.
| |
| *Press the 'Create' button at the bottom of the page to create the bug.
| |
| | |
| ==Resolving bugs in Tracker==
| |
| NB Only Moodle core developers and testers are permitted to change the status of bugs in Tracker to "resolved" or "closed".
| |
| *Bugs are assigned by developers or Component Leads.
| |
| *Developers modify or add code and check into CVS.
| |
| *Appropriate comments are added in Tracker. The bug's status is changed to '''Resolved''' by using the "Resolve Issue" button.
| |
| *You must indicate the version of Moodle in which the change has been made. Do this by selecting the appropriate Moodle version in '''Fix Version/s'''.
| |
| *The only exception to not moving a bug to Resolved is if a developer believes there is no value in testing the issue, in which case the bug status can be changed to Closed.
| |
| | |
| ==Testing bugs==
| |
| All users are encouraged to be active participants when it comes to testing Moodle. Anyone with a Tracker user account can log, view, comment on, vote, and watch bugs. If you find bugs or problems, have ideas for improvements, or want additional functionality added to Moodle, please log a bug in Tracker.
| |
| | |
| We've formalised a group of testers in Tracker who are responsible of verifying the accuracy of changes made by developers. These testers have responsibilities and authority in Tracker beyond that of standard users. Testers normally have a good understanding of Moodle, and are active in the Moodle community. If you are interested in becoming a member of the Moodle Testing team make yourself known by logging a request through Tracker. We'd love to have you join the team. Log your request at the [http://tracker.moodle.org/secure/project/ViewProject.jspa?pid=10020 Moodle.org Sites] Tracker project.
| |
| | |
| Testers responsibility in Tracker:
| |
| *Testers test bugs with Status=Resolved. Global filters have been created based on upcoming releases (eg 1.7 Resolved) to make identification simple.
| |
| *Use the '''QA Assignee''' field to identify yourself as the tester of a particular bug. Obviously you should have the skills and knowledge to sufficiently test the issue. Experience is important, but don't forget there are others in the community that may be able to help you.
| |
| *It's a good idea to add your name to the watch list for all bugs you test. (see "Tracker watch list", below.)
| |
| *If the bug passes testing, close the bug using the "Close Issue" button. You must add appropriate '''comments''' describing your testing methods, any issues that were found, etc.
| |
| *If the bug fails testing or if you feel the fix is incomplete, '''reopen''' the bug using the "Reopen Issue" button. Ensure the bug is assigned to the correct developer. Work with the developer to find a mutually agreeable resolution to the bug.
| |
| *A release will be deemed ready when all bugs fixed for a particular version have been closed.
| |
| | |
| ==Tracker fields==
| |
| '''Project''' - Required field. Tracker is made of of multiple projects. At present there are 2: 'moodle' and 'moodle.org sites'. Specify 'moodle' for issues/bugs related to moodle software; specify 'moodle.org sites' for issues/bugs related to tracker.moodle.org, docs.moodle.org, demo.moodle.org, download.moodle.org, or moodle.org.
| |
| | |
| '''Issue Type''' - Required field. Bugs are classified as 1 of the following:
| |
| :''Bug'' - A problem which impairs or prevents Moodle from functioning correctly.
| |
| :''Improvement'' - An enhancement to an existing Moodle feature.
| |
| :''New Feature'' - A new Moodle feature which has yet to be developed.
| |
| :''Task'' - A task that needs to be completed. Tasks usually refer to work that must be done outside the product.
| |
| :''Sub-Task'' - Issues are sometimes broken into multiple sub-tasks.
| |
| | |
| '''Summary''' - Required field. A brief, concise description of the problem.
| |
| | |
| '''Security Level''' - Optional field. Specify if this bug or change has security implications for Moodle.
| |
| | |
| '''Priority''' - Bugs are prioritised using one of the following:
| |
| :''Blocker'' - Blocks development and/or testing work, production could not run.
| |
| :''Critical'' - Crashes, loss of data, severe memory leak.
| |
| :''Major'' - Major loss of function.
| |
| :''Minor'' - Minor loss of function, or other problem where easy workaround is available.
| |
| :''Trivial'' - Cosmetic problem like misspelled words or misaligned text.
| |
| | |
| '''Component/s''' - Required field. Select the area in Moodle which is affected by this bug. Select 'Unknown' if you are unsure.
| |
| | |
| '''Affects Version/s''' - this is the version in which the bug has been found. It is normally entered by the person logging the bug, and typically only 1 version is specified.. This information will help developers and testers identify where the problem is occurring.
| |
| | |
| '''Assigned To''' - This is the person who will fix (code) the problem. This field is completed by developers or Component Leads.
| |
| | |
| '''Reporter''' - The person who logs the bug. This field is automatically filled by Tracker.
| |
| | |
| '''Environment''' - Specify the operating system, software platform and/or hardware specifications if applicable to this bug.
| |
| | |
| '''Description''' - A full and complete yet concise description of the problem or improvement.
| |
| | |
| '''Database''' - Optional field. If applicable to the bug, identify the database type.
| |
| | |
| '''URL''' - Optional field. If possible, provide a URL address that demonstrates an example of this bug.
| |
| | |
| '''QA Assignee''' - Used to designate the person who will test this bug.
| |
| | |
| '''Fixed Version/s''' - this is the version the bug was or will be fixed in. This field is completed by the developer when the bug has been resolved. Normally only one version is specified in this field. It identifies the ''first'' version of Moodle where the change will be seen. For instance, the bug affecting 1.6 and 1.6.1 might be fixed in 1.7.
| |
| | |
| '''Attachment''' - Optional. Attach a file that will help developers and testers better understand the bug.
| |
| | |
| '''Comment''' - The comment field is a detailed register of all changes that relate to this bug.
| |
| | |
| '''Resolution''' - This field is only displayed when resolving or closing a bug. Specify a code that best describes how this bug was resolved.
| |
| :''Fixed'' - Bug has been fixed; a code change will be checked into CVS.
| |
| :''Won't Fix'' - The problem described is an issue which will never be fixed.
| |
| :''Not a bug'' - System behaves as expected. This issue is not a bug, it may be a feature :-)
| |
| :''Duplicate'' - The problem is a duplicate of an existing issue.
| |
| :''Incomplete'' - More information is needed to understand this bug.
| |
| :''Can't Reproduce'' - All attempts at reproducing this issue failed, or not enough information was available to reproduce the issue. Reading the code produces no clues as to why this behavior would occur. If more information appears later, please reopen the issue.
| |
| :''Deferred'' - The resolution to this bug will be deferred to a later release.
| |
| | |
| ==More about Tracker functionality==
| |
| *Tracker provides a facility to '''Link''' bugs. Any user logged onto Tracker may link issues. Multiple link types are defined in the system; you will be required to select one when linking bugs. The following link types are available:
| |
| ::duplicates - duplicates are inevitable in a project the size of Moodle. They occur when a logger is unaware of an existing bug that describes the same problem. Use ''duplicates'' to link to the first or most comprehensively described instance of the problem. All duplicates should be linked together.
| |
| ::blockers - use this to identify bugs that block others from being fixed.
| |
| ::cloners - in some instances a duplicate bug is intentionally created in order to track the fix in another branch of the code - this almost never is used in the Moodle project.
| |
| ::dependency - often a fix is dependent on another bug being resolved first, on in a specific order.
| |
| ::relates - used to identify a bug that is somehow related to another bug.
| |
| :Links are bi-directional meaning that there's a concept of 'inward' and 'outward' - it affects how linked bugs are displayed. This is why you'll see "blocks/is blocked by" or "duplicates/is duplicated by" in the drop down list of the ''Link Issue'' dialog. Don't become too concerned about using the "correct" link type - all link types work similarly.
| |
| | |
| *'''Vote''' for bugs you want to see addressed in Moodle. Any user can vote. To vote for a specific bug, browse to the bug, then select "Vote for it" from the left-hand navigation panel. Developers may consider the number of votes a bug has when weighing the merits of two or more bugs.
| |
| | |
| *The Tracker '''Dashboard''' is flexible and customisable depending on your area of interest. For instructions on configuring the Tracker dashboard click [http://www.atlassian.com/software/jira/docs/v3.6.3/dashboard.html here].
| |
| | |
| *The Tracker '''Issue Navigator''' is used to find and filter bugs. For instructions on configuring the Issue Navigator click [http://www.atlassian.com/software/jira/docs/v3.6.4/navigatorcolumns.html here].
| |
| | |
| *Tracker's '''Quick Search''' function is explained [http://www.atlassian.com/software/jira/docs/v3.6.4/quicksearch.html here]
| |
| | |
| == Tracker groups and permissions ==
| |
| '''Standard Users''' [groupname=jira-user] - This is the default group. New user accounts are placed in this group at the time of creation, and users must be a member of this group in order to log into Tracker. Members of this group can browse bugs, create new bugs, comment on bugs, create attachments, create sub-tasks, create filters, watch bugs, and vote for bugs. Members of this group can also resolve bugs, which is primarily a way of closing bugs that are no longer relevant (eg duplicates, or logged in error). Standard Users can configure their Tracker workspace by using the "Configure your Issue Navigator" button. This feature allows users to view watch and voting lists and to manage preferences, profile, and password.
| |
|
| |
| '''Developers''' [groupname=jira-developer] - Developers can do everything Standard Users can do. In addition they can clone bugs, close bugs, edit bugs, link bugs, and assign bugs. Members of this group can also use the Bulk Edit function which allows bulk updated to multiple bugs.
| |
| | |
| '''Testers''' [groupname=moodle-testers] - Testers can do everything a Developer can do.
| |
| | |
| NB You can browse a project while not logged in to Tracker, however you will be unable change/edit/comment on bugs.
| |
| | |
| | |
| ==Tracking progress of bugs you have reported==
| |
| | |
| You will receive email reports of updates to bugs you report.
| |
| | |
| ==Tracker watch lists==
| |
| | |
| 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 receive 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
| |
| *Wikipedia [http://en.wikipedia.org/wiki/Software_bug Definition of a bug]
| |
| *[[Tracker development]]
| |
| *[[Getting Started with the Tracker]]
| |
| [[Category:Teacher]]
| |
| [[Category:Administrator]]
| |
| [[Category:Developer]]
| |
| [[Category:Developer tools]]
| |
| | |
| [[es:Sistema de bugs]]
| |
