MoodleDocs - User contributions [en]

Tracker

2009-02-19T02:43:33Z

Mblake: /* Logging new issues or improvements */

[[Image:Tracker.jpg]] '''is Moodle's''' [[Image:Issue Tracker MoodleOrg link.JPG]]

Issue tracking is an important part of a continuous quality control process. It involves the reporting of problems (bugs), ideas for improvement and new features. Unlike most proprietary software programs, Moodle issue reporting and tracking information is open to everyone. Moodle's issue tracking system is called '''[http://tracker.moodle.org Moodle Tracker]'''. We welcome your requests for new features, improvements, or even constructive criticism of existing features.

The beauty of open source is that anyone can participate and help to create a better product for all of us to enjoy. Please help us by using [http://tracker.moodle.org Moodle Tracker]!

==Basics==
===Logging in to 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.
*If you've forgotten your password, go [http://tracker.moodle.org here] and select 'forgot password' which is just under the 'log in' button. Follow the prompts.

=== Summary: 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.

=== How to write a good Tracker entry===
A good report will include:
*Summary (describe the issue in 1 or 2 sentences)
*Description (a concise yet complete summary of the problem or improvement)
*'''Steps to Reproduce''': A detailed, easy-to-follow sequence of steps a developer can follow to reproduce the problem. If possible, provide a URL so a developer can see the problem with one click.
*'''Actual Results''': What the application did after performing the above steps.
*'''Expected Results''': What the application should have done, were the bug not present. Provide as much detail as possible. Your expectation might mean that help instructions need to be improved or interface changed.

If possible, include additional information that may be helpful to the developer:
*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)
* 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.
* Provide details 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
**Client-side operating system type and version number
**Web browser type and version number

* You don't need to provide 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.

Here are some examples of good bug reports: MDL-6030, MDL-5688, MDL-12505

*A good external reference to help write a tracker entry can be found at [http://developer.mozilla.org/en/docs/Bug_writing_guidelines mozilla bug writing guidelines].

"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.

==Tracker process==
===Logging new issues or improvements===
Anyone with a Tracker account can log issues. See instructions above for writing good quality bug reports. It is important that you search Tracker to determine if your problem or suggestion for improvement has already been reported. If it has you are encouraged to add more information (use the "comment" function), vote for the issue, or watch it (more on this later).

You will receive an email when you log a new bug or make updates to bugs you've reported. You'll also receive notification when updates are made to bugs you're watching.

You can monitor, or '''watch''' issues reported by others. To do this, open the issue, then select "Watch it" from the left hand navigation panel. To add others to the watchlist for your issue, open the issue, select the option "Watching" from the left hand navigation panel. These people will receive email notification when the issue is updated. To view all the issues you are watching, go to the Dashboard (see below) and look for the "My Watches" filter.

Tracker provides a facility to '''Link''' issues. 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. See [insert section name] for detailed list of link types.

'''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. To view all the issues you've voted for, go to the Dashboard (see below) and look for the "My Votes" filter.

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]

===Resolving issues===
(this section should be reviewed)
Issues are resolved in Tracker to show that they've been actioned. Only Moodle core developers and testers are permitted to change the status of bugs in Tracker to "resolved" or "closed".

This is the general process a developer will follow when actioning a Tracker issue:

# Issues are automatically assigned at the time they're created based on component type; they may be reassigned by developers or Component Leads.
# Developers fix, modify or add code and check into CVS. The Tracker issue number is included which automatically links the CVS change to Tracker.
# Patches are attached to Tracker issues so that they may be verified and possibly included in CVS.
# Appropriate comments should be added in Tracker describing the fix. The bug's status is changed to '''Resolved'''.
# The developer should indicate which version of Moodle the change will be included in using the '''Fix Version/s'''. You should use this to indicate which branch(es) you checked the fix into (example below).
# The only exception to not moving a bug to Resolved is if a developer believes there is no value in testing the resolved issue, in which case the bug status can be changed to Closed.

===Testing issues===
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 for 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. Obviously testers should have the skills and knowledge to sufficiently test the issue - experience is important - but don't forget there are others in the Moodle community who may be willing to lend a hand. 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.

Testing a bug in Tracker

NB This is the process members of the moodle-testers group should follow to move bugs from 'resolved' to 'closed'.
*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.

*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.
*All resolved bugs should be tested. Bugs with a resolution code of "fixed" represent bugs where code has been updated, and probably represent more of a challenge than bugs with resoluton codes of duplicate, won't fix, and not a bug, and can't reproduce. Please ensure bugs have been closed with a proper resolution code. Unfortunately it's not easy to change a resolution code in Tracker once the bug has been resolved (the only way is to reopen, then re-resolve).
*Don't be afraid to discuss your testing with the developer assigned to the bug. Simply adding a comment should get the attention of the developer as they are notified of all changes.

==Detailed description of Tracker fields and groups ==
===Tracker fields===
NB A short explanation appears under each field in Tracker.

'''Project''' - Required field. Tracker is a collection of multiple projects. At present there are 3: 'moodle', 'moodle.org sites' and 'Non-core contributed modules'. 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; specify 'Non-core contributed modules' for issues/bugs related to contributed modules.

'''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. Bugs with serious security implications are restricted so that only members of the moodle-security group can see them.

'''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''' - Required field. This is the Moodle version in which the bug has been found. It is entered by the person logging the bug, and typically only 1 version is specified. Enter your current version when logging an 'improvement', 'task', or 'new feature' as this will help assess the state of the product when the request was made.

'''Assigned To''' - This is the person who will fix (code) the issue. Tracker automatically assigns issues to Component Leads. Developers or QA Testers can reassign issues.

'''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 issue.

'''Fixed Version/s''' - This is the Moodle version the bug was or will be fixed in. Basically you should think '''Which release notes should this appear in?''' This field is normally completed by the developer when the bug has been resolved or by lead developers allocating bugs for a specific release. Normally only one version is specified in this field. It symbolises the ''first'' version of Moodle where the change will be seen.
:Example: after Moodle 1.9 has been released, if you fix a bug on the MOODLE_19_STABLE and HEAD branches, mark it as fixed in 1.9.1. If you also backported to MOODLE_18_STABLE, then add the version of the next 1.8.x release too.

:If you resolve the bug as anything but "Fixed" (Cannot Reproduce, Won't Fix, etc.) leave Fix Version/s blank.
:If you resolve the bug as Duplicate, then create a link to the duplicate issue.
:These Fix version/s are used to automatically build release notes (see the tabs on http://tracker.moodle.org/browse/MDL).

'''Attachment''' - Optional. Attach a file that will help developers and testers better understand the bug. Maximum attachement size is 512Kb.

'''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. Use this resolution code only when actual changes were made to Moodle code.
:''Won't Fix'' - The problem described is an issue which will never be fixed.
:''Not a bug'' - This issue is not a bug; was logged in error. Use this code if the bug was fixed by another bug report or in some earlier Moodle version.
:''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.

=== 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.

'''Moodle Security groups''' [groupname=moodle-security] - Trusted developers and administrators who need to work on and learn about security issues.

"Nobody" is a Tracker user created to alert users to the fact that an issue hasn't been assigned to a developer. These issues are regularly reviewed by the team at Moodle HQ.

NB You can browse a project while not logged in to Tracker, however you will be unable change/edit/comment on bugs.

=== Link types ===
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.
'''Don't be afraid to link bugs. ''' 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.

==See also==

*[[Development:Weekly Code Review]]
*[http://www.atlassian.com/software/jira/ Jira] Tracker is a slightly customised version of Atlassian's product
*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]

[[Category:Teacher]]
[[Category:Administrator]]
[[Category:Developer]]
[[Category:Developer tools]]
[[Category:Quality Assurance]]

[[pt:Tracker]]
[[es:Sistema de bugs]]
[[fr:Traqueur de bogues]]

Development:Site registration

2008-10-30T05:03:01Z

Mblake:

===Guidelines for reviewing new Moodle sites===

How site authorisation works
*New Moodle site registrations are reviewed by a team of volunteers. If you're interested in helping, send a request to the Moodle helpdesk (support@moodle.com). Only those with access will be able to access the approval site.
*Go to http://moodle.org/sites/ Click the "Check new registrations" button in the upper right corner of the screen.
*Select a site from the list on the the left side panel (opening several, each in its own tab, works well.) The site and statistics at the time it was registered are displayed in the upper pane. Either accept or reject the site using the guidelines below. There's a text box to enter a brief reason for rejecting (e.g. can’t find server or no courses).
*Large sites are automatically registered - only smaller sites appear on this list.
*There's a button to “confirm as cool” if you find one.
*Site admins receive notification of the action taken. They can easily re-register at a later date.

Guidelines for accepting a site
*Site must be accessible and active
*Site must have at least 1 active course
*Site must look legitimate (look at graphics, text, domain name, etc)

Guidelines for rejecting a site

Reject site:
*if it appears to be a test site or contains only test courses
*if redirected to another site (e.g. a commercial site selling something)
*if no courses are available
*if authentication is required to enter the site
*if authorisation is required to enter site
*if it appears the site is spam related
*if you receive any of the following messages:
**address not found
**page not found
**not found
**index of/
**connection timed out
**secure connection failed
**forbidden - you do not have permission to enter this site
**failed to connect

Fast and easy way to review sites:
*use the "open in a separate tab" function in your browser to open approximately 10 sites, each in its own tab. This method is quicker because you don't have to wait for each site to load. After accepting or rejecting the site close the tab. The job is much quicker this way!

Development talk:Site registration

2008-09-26T08:24:23Z

Mblake:

Michael, thanks for writing up the guidelines for reviewing new Moodle sites :-) I just came across [[Verification of sites on moodle.org]] and wondered whether the information could be added to [[Development:Site registration]] and then the page deleted. What do you think? --[[User:Helen Foster|Helen Foster]] 06:48, 25 September 2008 (CDT)

Helen, I've updated/merged the instructions that appear on the "check new registrations page" so [[Verification of sites on moodle.org]] can be deleted.

Development:Site registration

2008-09-26T08:21:36Z

Mblake:

===Guidelines for reviewing new Moodle sites===

How site authorisation works
*New Moodle site registrations are reviewed by a team of volunteers. If you're interested in helping, send a request to the Moodle helpdesk (support@moodle.com). Only those with access will be able to access the approval site.
*Go to http://moodle.org/sites/ Click the "Check new registrations" button in the upper right corner of the screen.
*Select a site from the list on the the left side panel (opening several, each in its own tab, works well.) The site and statistics at the time it was registered are displayed in the upper pane. Either accept or reject the site using the guidelines below. There's a text box to enter a brief reason for rejecting (e.g. can’t find server or no courses).
*Large sites are automatically registered - only smaller sites appear on this list.
*There's a button to “confirm as cool” if you find one.
*Site admins receive notification of the action taken. They can easily re-register at a later date.

Guidelines for accepting a site
*Site must be accessible and active
*Site must have at least 1 active course
*Site must look legitimate (look at graphics, text, domain name, etc)

Guidelines for rejecting a site

Reject site:
*if it appears to be a test site or contains only test courses
*if redirected to another site (e.g. a commercial site selling something)
*if no courses are available
*if authentication is required to to enter the site
*if authorisation is required to enter site
*if it appears the site is spam related
*if you receive any of the following messages:
**address not found
**page not found
**not found
**index of/
**connection timed out
**secure connection failed
**forbidden - you do not have permission to enter this site
**failed to connect

Development:Site registration

2008-09-25T07:06:35Z

Mblake:

===Guidelines for reviewing new Moodle sites===

How site authorisation works
*New Moodle site registrations are reviewed by a team of volunteers. If you're interested in helping, send a request to the Moodle helpdesk (support@moodle.com). Only those with access will be able to access the approval site.
*Go to http://moodle.org/sites/ Click the "Check new registrations" button in the upper right corner of the screen
*Select a site from the list on the the left side panel (opening several, each in its own tab, works well.) The site and statistics at the time it was registered are displayed in the upper pane. Either accept or reject the site using the guidelines below
*Large sites are automatically registered - only smaller sites appear on this list
*Site admins receive notification of the action taken. They can easily re-register at a later date.

Guidelines for accepting a site
*Site must be accessible and active
*Site must have at least 1 active course
*Site must look legitimate (look at graphics, text, domain name, etc)

Guidelines for rejecting a site

Reject site:
*if it appears to be a test site or contains only test courses
*if redirected to another site (e.g. a commercial site selling something)
*if no courses are available
*if authentication is required to to enter the site
*if authorisation is required to enter site
*if it appears the site is spam related
*if you receive any of the following messages:
**address not found
**page not found
**not found
**index of/
**connection timed out
**secure connection failed
**forbidden - you do not have permission to enter this site
**failed to connect

Development:Site registration

2008-09-25T07:04:50Z

Mblake: /* Guidelines for reviewing new Moodle sites */

===Guidelines for reviewing new Moodle sites===

How site authorisation works
*New Moodle site registrations are reviewed by a team of volunteers. If you're interested in helping, send a request to the Moodle helpdesk (support@moodle.com). Only those with access will be able to access the approval site.
*Go to http://moodle.org/sites/ Click the "Check new registrations" button in the upper right corner of the screen
*Select a site from the list on the the left side panel (opening several, each in its own tab, works well.) The site and statistics at the time it was registered are displayed in the upper pane. Either accept or reject the site using the guidelines below
*Large sites are automatically registered - only smaller sites appear on this list
*Site admins receive notification of the action taken. They can easily re-register at a later date.

Guidelines for accepting a site
*Site must be accessible and active
*Site must have at least 1 active course
*Site must look legitimate (look at graphics, text, domain name, etc)

Guidelines for rejecting a site

Reject site:
*if it appears to be a test site or contains only test courses
*if redirected to another site (e.g. a commercial site selling something)
*if no courses are available
*if authentication is required to to enter the site
*if authorisation is required to enter site
*if it appears the site is spam related
*if you receive any of the following messages: address not found
**page not found
**not found
**index of/
**connection timed out
**secure connection failed
**forbidden - you do not have permission to enter this site
**failed to connect

Development:Site registration

2008-09-25T07:00:13Z

Mblake:

===Guidelines for reviewing new Moodle sites===

How site authorisation works

*Select a site from the list on the the left side panel (opening several, each in its own tab, works well.) The site and statistics at the time it was registered are displayed in the upper pane. Either accept or reject the site using the guidelines below
*Large sites are automatically registered - only smaller sites appear on this list
*Site admins receive notification of the action taken. They can easily re-register at a later date.

Guidelines for accepting a site
*Site must be accessible and active
*Site must have at least 1 active course
*Site must look legitimate (look at graphics, text, domain name, etc)

Guidelines for rejecting a site

Reject site:
*if it appears to be a test site or contains only test courses
*if redirected to another site (e.g. a commercial site selling something)
*if no courses are available
*if authentication is required to to enter the site
*if authorisation is required to enter site
*if it appears the site is spam related
*if you receive any of the following messages: address not found
**page not found
**not found
**index of/
**connection timed out
**secure connection failed
**forbidden - you do not have permission to enter this site
**failed to connect

Development:Site registration

2008-09-25T06:58:37Z

Mblake:

===Guidelines for reviewing new Moodle sites===

How site authorisation works

*Select a site from the list on the the left side panel (opening several, each in its own tab, works well.) The site and statistics at the time it was registered are displayed in the upper pane. Either accept or reject the site using the guidelines below
*Large sites are automatically registered - only smaller sites appear on this list
*Site admins receive notification of the action taken. They can easily re-register at a later date.

Guidelines for accepting a site
*Site must be accessible and active
*Site must have at least 1 active course
*Site must look legitimate (look at graphics, text, domain name, etc)

Guidelines for rejecting a site

Reject site:

if it appears to be a test site or contains only test courses

if redirected to another site (e.g. a commercial site selling something)

if no courses are available

if authentication is required to to enter the site

if authorisation is required to enter site

if it appears the site is spam related

if you receive any of the following messages: address not found

page not found

not found

index of/

connection timed out

secure connection failed

forbidden - you do not have permission to enter this site

failed to connect

Development:Site registration

2008-09-25T06:54:39Z

Mblake: /* Guidelines for approving new Moodle sites */

Tracker

2008-04-24T07:10:27Z

Mblake: /* Tracker fields */

[[Image:Tracker.jpg]] '''is Moodle's''' [[Image:Issue Tracker MoodleOrg link.JPG]]

Issue tracking is an important part of a continuous quality control process. It involves the reporting of problems (bugs), ideas for improvement and new features. Unlike most proprietary software programs, Moodle issue reporting and tracking information is open to everyone. Moodle's issue tracking system is called '''[http://tracker.moodle.org Moodle Tracker]'''. We welcome your requests for new features, improvements, or even constructive criticism of existing features.

The beauty of open source is that anyone can participate and help to create a better product for all of us to enjoy. Please help us by using [http://tracker.moodle.org Moodle Tracker]!

==Basics==
===Logging in to 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.
*If you've forgotten your password, go [http://tracker.moodle.org here] and select 'forgot password' which is just under the 'log in' button. Follow the prompts.

=== Summary: 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.

=== How to write a good Tracker entry===
A good report will include:
*Summary (describe the issue in 1 or 2 sentences)
*Description (a concise yet complete summary of the problem or improvement)
*Steps to Reproduce: A detailed, easy-to-follow sequence of steps a developer can follow to reproduce the problem. If possible, provide a URL so a developer can see the problem with one click.
*Actual Results: What the application did after performing the above steps.
*Expected Results: What the application should have done, were the bug not present. Provide as much detail as possible. Your expectation might mean that help instructions need to be improved or interface changed.

If possible, include additional information that may be helpful to the developer:
*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)
* 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.
* Provide details 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
**Client-side operating system type and version number
**Web browser type and version number

* You don't need to provide 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.

Here are some examples of good bug reports: MDL-6030, MDL-5688, MDL-12505

*A good external reference to help write a tracker entry can be found at [http://developer.mozilla.org/en/docs/Bug_writing_guidelines mozilla bug writing guidelines].

"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.

==Tracker process==
===Logging new issues or improvements===
Anyone with a Tracker account can log issues. See instructions above for writing good quality bug reports. It is important that you search Tracker to determine if your problem or suggestion for improvement has already been reported. If it has you are encouraged to add more information (use the "comment" function), vote for the issue, or watch it (more on this later).

You will receive an email when you log a new bug or make updates to bugs you've reported. You'll also receive notification when updates are made to bugs you're watching.

You can monitor, or '''watch''' issues reported by others. To do this, open the issue, then select "Watch it" from the left hand navigation panel. To add others to the watchlist for your issue, open the issue, select the option "Watching" from the left hand navigation panel. These people will receive email notification when the issue is updated.

Tracker provides a facility to '''Link''' issues. 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. See [insert section name] for detailed list of link types.

'''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]

===Resolving issues=== (this section should be reviewed)
Issues are resolved in Tracker to show that they've been actioned. Only Moodle core developers and testers are permitted to change the status of bugs in Tracker to "resolved" or "closed".

This is the general process a developer will follow when actioning a Tracker issue:

# Issues are automatically assigned at the time they're created based on component type; they may be reassigned by developers or Component Leads.
# Developers fix, modify or add code and check into CVS. The Tracker issue number is included which automatically links the CVS change to Tracker.
# Patches are attached to Tracker issues so that they may be verified and possibly included in CVS.
# Appropriate comments should be added in Tracker describing the fix. The bug's status is changed to '''Resolved'''.
# The developer should indicate which version of Moodle the change will be included in using the '''Fix Version/s'''. You should use this to indicate which branch(es) you checked the fix into (example below).
# The only exception to not moving a bug to Resolved is if a developer believes there is no value in testing the resolved issue, in which case the bug status can be changed to Closed.

===Testing issues===
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 for 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. Obviously testers should have the skills and knowledge to sufficiently test the issue - experience is important - but don't forget there are others in the Moodle community who may be willing to lend a hand. 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.

Testing a bug in Tracker

NB This is the process members of the moodle-testers group should follow to move bugs from 'resolved' to 'closed'.
*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.

*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.
*All resolved bugs should be tested. Bugs with a resolution code of "fixed" represent bugs where code has been updated, and probably represent more of a challenge than bugs with resoluton codes of duplicate, won't fix, and not a bug, and can't reproduce. Please ensure bugs have been closed with a proper resolution code. Unfortunately it's not easy to change a resolution code in Tracker once the bug has been resolved (the only way is to reopen, then re-resolve).
*Don't be afraid to discuss your testing with the developer assigned to the bug. Simply adding a comment should get the attention of the developer as they are notified of all changes.

==Detailed description of Tracker fields and groups ==
===Tracker fields===
NB A short explanation appears under each field in Tracker.

'''Project''' - Required field. Tracker is a collection of multiple projects. At present there are 3: 'moodle', 'moodle.org sites' and 'Non-core contributed modules'. 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; specify 'Non-core contributed modules' for issues/bugs related to contributed modules.

'''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. Bugs with serious security implications are restricted so that only members of the moodle-security group can see them.

'''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''' - Required field. This is the Moodle version in which the bug has been found. It is entered by the person logging the bug, and typically only 1 version is specified. Enter your current version when logging an 'improvement', 'task', or 'new feature' as this will help assess the state of the product when the request was made.

'''Assigned To''' - This is the person who will fix (code) the issue. Tracker automatically assigns issues to Component Leads. Developers or QA Testers can reassign issues.

'''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 issue.

'''Fixed Version/s''' - This is the Moodle version the bug was or will be fixed in. Basically you should think '''Which release notes should this appear in?''' This field is normally completed by the developer when the bug has been resolved or by lead developers allocating bugs for a specific release. Normally only one version is specified in this field. It symbolises the ''first'' version of Moodle where the change will be seen.
:Example: after Moodle 1.9 has been released, if you fix a bug on the MOODLE_19_STABLE and HEAD branches, mark it as fixed in 1.9.1. If you also backported to MOODLE_18_STABLE, then add the version of the next 1.8.x release too.

:If you resolve the bug as anything but "Fixed" (Cannot Reproduce, Won't Fix, etc.) leave Fix Version/s blank.
:If you resolve the bug as Duplicate, then create a link to the duplicate issue.
:These Fix version/s are used to automatically build release notes (see the tabs on http://tracker.moodle.org/browse/MDL).

'''Attachment''' - Optional. Attach a file that will help developers and testers better understand the bug. Maximum attachement size is 512Kb.

'''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. Use this resolution code only when actual changes were made to Moodle code.
:''Won't Fix'' - The problem described is an issue which will never be fixed.
:''Not a bug'' - This issue is not a bug; was logged in error. Use this code if the bug was fixed by another bug report or in some earlier Moodle version.
:''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.

=== 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.

'''Moodle Security groups''' [groupname=moodle-security] - Trusted developers and administrators who need to work on and learn about security issues.

"Nobody" is a Tracker user created to alert users to the fact that an issue hasn't been assigned to a developer. These issues are regularly reviewed by the team at Moodle HQ.

NB You can browse a project while not logged in to Tracker, however you will be unable change/edit/comment on bugs.

=== Link types ===
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.
'''Don't be afraid to link bugs. ''' 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.

==See also==

*[[Development:Weekly Code Review]]
*[http://www.atlassian.com/software/jira/ Jira] Tracker is a slightly customised version of Atlassian's product
*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]

[[Category:Teacher]]
[[Category:Administrator]]
[[Category:Developer]]
[[Category:Developer tools]]

[[es:Sistema de bugs]]
[[fr:Traqueur de bogues]]

Tracker

2008-04-24T07:09:34Z

Mblake: /* Tracker fields */

[[Image:Tracker.jpg]] '''is Moodle's''' [[Image:Issue Tracker MoodleOrg link.JPG]]

Issue tracking is an important part of a continuous quality control process. It involves the reporting of problems (bugs), ideas for improvement and new features. Unlike most proprietary software programs, Moodle issue reporting and tracking information is open to everyone. Moodle's issue tracking system is called '''[http://tracker.moodle.org Moodle Tracker]'''. We welcome your requests for new features, improvements, or even constructive criticism of existing features.

The beauty of open source is that anyone can participate and help to create a better product for all of us to enjoy. Please help us by using [http://tracker.moodle.org Moodle Tracker]!

==Basics==
===Logging in to 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.
*If you've forgotten your password, go [http://tracker.moodle.org here] and select 'forgot password' which is just under the 'log in' button. Follow the prompts.

=== Summary: 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.

=== How to write a good Tracker entry===
A good report will include:
*Summary (describe the issue in 1 or 2 sentences)
*Description (a concise yet complete summary of the problem or improvement)
*Steps to Reproduce: A detailed, easy-to-follow sequence of steps a developer can follow to reproduce the problem. If possible, provide a URL so a developer can see the problem with one click.
*Actual Results: What the application did after performing the above steps.
*Expected Results: What the application should have done, were the bug not present. Provide as much detail as possible. Your expectation might mean that help instructions need to be improved or interface changed.

If possible, include additional information that may be helpful to the developer:
*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)
* 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.
* Provide details 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
**Client-side operating system type and version number
**Web browser type and version number

* You don't need to provide 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.

Here are some examples of good bug reports: MDL-6030, MDL-5688, MDL-12505

*A good external reference to help write a tracker entry can be found at [http://developer.mozilla.org/en/docs/Bug_writing_guidelines mozilla bug writing guidelines].

"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.

==Tracker process==
===Logging new issues or improvements===
Anyone with a Tracker account can log issues. See instructions above for writing good quality bug reports. It is important that you search Tracker to determine if your problem or suggestion for improvement has already been reported. If it has you are encouraged to add more information (use the "comment" function), vote for the issue, or watch it (more on this later).

You will receive an email when you log a new bug or make updates to bugs you've reported. You'll also receive notification when updates are made to bugs you're watching.

You can monitor, or '''watch''' issues reported by others. To do this, open the issue, then select "Watch it" from the left hand navigation panel. To add others to the watchlist for your issue, open the issue, select the option "Watching" from the left hand navigation panel. These people will receive email notification when the issue is updated.

Tracker provides a facility to '''Link''' issues. 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. See [insert section name] for detailed list of link types.

'''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]

===Resolving issues=== (this section should be reviewed)
Issues are resolved in Tracker to show that they've been actioned. Only Moodle core developers and testers are permitted to change the status of bugs in Tracker to "resolved" or "closed".

This is the general process a developer will follow when actioning a Tracker issue:

# Issues are automatically assigned at the time they're created based on component type; they may be reassigned by developers or Component Leads.
# Developers fix, modify or add code and check into CVS. The Tracker issue number is included which automatically links the CVS change to Tracker.
# Patches are attached to Tracker issues so that they may be verified and possibly included in CVS.
# Appropriate comments should be added in Tracker describing the fix. The bug's status is changed to '''Resolved'''.
# The developer should indicate which version of Moodle the change will be included in using the '''Fix Version/s'''. You should use this to indicate which branch(es) you checked the fix into (example below).
# The only exception to not moving a bug to Resolved is if a developer believes there is no value in testing the resolved issue, in which case the bug status can be changed to Closed.

===Testing issues===
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 for 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. Obviously testers should have the skills and knowledge to sufficiently test the issue - experience is important - but don't forget there are others in the Moodle community who may be willing to lend a hand. 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.

Testing a bug in Tracker

NB This is the process members of the moodle-testers group should follow to move bugs from 'resolved' to 'closed'.
*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.

*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.
*All resolved bugs should be tested. Bugs with a resolution code of "fixed" represent bugs where code has been updated, and probably represent more of a challenge than bugs with resoluton codes of duplicate, won't fix, and not a bug, and can't reproduce. Please ensure bugs have been closed with a proper resolution code. Unfortunately it's not easy to change a resolution code in Tracker once the bug has been resolved (the only way is to reopen, then re-resolve).
*Don't be afraid to discuss your testing with the developer assigned to the bug. Simply adding a comment should get the attention of the developer as they are notified of all changes.

==Detailed description of Tracker fields and groups ==
===Tracker fields===
NB A short explanation appears under each field in Tracker.

'''Project''' - Required field. Tracker is made of multiple projects. At present there are 3: 'moodle', 'moodle.org sites' and 'Non-core contributed modules'. 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; specify 'Non-core contributed modules' for issues/bugs related to contributed modules.

'''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. Bugs with serious security implications are restricted so that only members of the moodle-security group can see them.

'''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''' - Required field. This is the Moodle version in which the bug has been found. It is entered by the person logging the bug, and typically only 1 version is specified. Enter your current version when logging an 'improvement', 'task', or 'new feature' as this will help assess the state of the product when the request was made.

'''Assigned To''' - This is the person who will fix (code) the issue. Tracker automatically assigns issues to Component Leads. Developers or QA Testers can reassign issues.

'''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 issue.

'''Fixed Version/s''' - This is the Moodle version the bug was or will be fixed in. Basically you should think '''Which release notes should this appear in?''' This field is normally completed by the developer when the bug has been resolved or by lead developers allocating bugs for a specific release. Normally only one version is specified in this field. It symbolises the ''first'' version of Moodle where the change will be seen.
:Example: after Moodle 1.9 has been released, if you fix a bug on the MOODLE_19_STABLE and HEAD branches, mark it as fixed in 1.9.1. If you also backported to MOODLE_18_STABLE, then add the version of the next 1.8.x release too.

:If you resolve the bug as anything but "Fixed" (Cannot Reproduce, Won't Fix, etc.) leave Fix Version/s blank.
:If you resolve the bug as Duplicate, then create a link to the duplicate issue.
:These Fix version/s are used to automatically build release notes (see the tabs on http://tracker.moodle.org/browse/MDL).

'''Attachment''' - Optional. Attach a file that will help developers and testers better understand the bug. Maximum attachement size is 512Kb.

'''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. Use this resolution code only when actual changes were made to Moodle code.
:''Won't Fix'' - The problem described is an issue which will never be fixed.
:''Not a bug'' - This issue is not a bug; was logged in error. Use this code if the bug was fixed by another bug report or in some earlier Moodle version.
:''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.

=== 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.

'''Moodle Security groups''' [groupname=moodle-security] - Trusted developers and administrators who need to work on and learn about security issues.

"Nobody" is a Tracker user created to alert users to the fact that an issue hasn't been assigned to a developer. These issues are regularly reviewed by the team at Moodle HQ.

NB You can browse a project while not logged in to Tracker, however you will be unable change/edit/comment on bugs.

=== Link types ===
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.
'''Don't be afraid to link bugs. ''' 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.

==See also==

*[[Development:Weekly Code Review]]
*[http://www.atlassian.com/software/jira/ Jira] Tracker is a slightly customised version of Atlassian's product
*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]

[[Category:Teacher]]
[[Category:Administrator]]
[[Category:Developer]]
[[Category:Developer tools]]

[[es:Sistema de bugs]]
[[fr:Traqueur de bogues]]

Tracker

2008-04-23T08:38:55Z

Mblake: /* Tracker groups and permissions */

[[Image:Tracker.jpg]] '''is Moodle's''' [[Image:Issue Tracker MoodleOrg link.JPG]]

Issue tracking is an important part of a continuous quality control process. It involves the reporting of problems (bugs), ideas for improvement and new features. Unlike most proprietary software programs, Moodle issue reporting and tracking information is open to everyone. Moodle's issue tracking system is called '''[http://tracker.moodle.org Moodle Tracker]'''. We welcome your requests for new features, improvements, or even constructive criticism of existing features.

The beauty of open source is that anyone can participate and help to create a better product for all of us to enjoy. Please help us by using [http://tracker.moodle.org Moodle Tracker]!

==Basics==
===Logging in to 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.
*If you've forgotten your password, go [http://tracker.moodle.org here] and select 'forgot password' which is just under the 'log in' button. Follow the prompts.

=== Summary: 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.

=== How to write a good Tracker entry===
A good report will include:
*Summary (describe the issue in 1 or 2 sentences)
*Description (a concise yet complete summary of the problem or improvement)
*Steps to Reproduce: A detailed, easy-to-follow sequence of steps a developer can follow to reproduce the problem. If possible, provide a URL so a developer can see the problem with one click.
*Actual Results: What the application did after performing the above steps.
*Expected Results: What the application should have done, were the bug not present. Provide as much detail as possible. Your expectation might mean that help instructions need to be improved or interface changed.

If possible, include additional information that may be helpful to the developer:
*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)
* 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.
* Provide details 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
**Client-side operating system type and version number
**Web browser type and version number

* You don't need to provide 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.

Here are some examples of good bug reports: MDL-6030, MDL-5688, MDL-12505

*A good external reference to help write a tracker entry can be found at [http://developer.mozilla.org/en/docs/Bug_writing_guidelines mozilla bug writing guidelines].

"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.

==Tracker process==
===Logging new issues or improvements===
Anyone with a Tracker account can log issues. See instructions above for writing good quality bug reports. It is important that you search Tracker to determine if your problem or suggestion for improvement has already been reported. If it has you are encouraged to add more information (use the "comment" function), vote for the issue, or watch it (more on this later).

You will receive an email when you log a new bug or make updates to bugs you've reported. You'll also receive notification when updates are made to bugs you're watching.

You can monitor, or '''watch''' issues reported by others. To do this, open the issue, then select "Watch it" from the left hand navigation panel. To add others to the watchlist for your issue, open the issue, select the option "Watching" from the left hand navigation panel. These people will receive email notification when the issue is updated.

Tracker provides a facility to '''Link''' issues. 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. See [insert section name] for detailed list of link types.

'''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]

===Resolving issues=== (this section should be reviewed)
Issues are resolved in Tracker to show that they've been actioned. Only Moodle core developers and testers are permitted to change the status of bugs in Tracker to "resolved" or "closed".

This is the general process a developer will follow when actioning a Tracker issue:

# Issues are automatically assigned at the time they're created based on component type; they may be reassigned by developers or Component Leads.
# Developers fix, modify or add code and check into CVS. The Tracker issue number is included which automatically links the CVS change to Tracker.
# Patches are attached to Tracker issues so that they may be verified and possibly included in CVS.
# Appropriate comments should be added in Tracker describing the fix. The bug's status is changed to '''Resolved'''.
# The developer should indicate which version of Moodle the change will be included in using the '''Fix Version/s'''. You should use this to indicate which branch(es) you checked the fix into (example below).
# The only exception to not moving a bug to Resolved is if a developer believes there is no value in testing the resolved issue, in which case the bug status can be changed to Closed.

===Testing issues===
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 for 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. Obviously testers should have the skills and knowledge to sufficiently test the issue - experience is important - but don't forget there are others in the Moodle community who may be willing to lend a hand. 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.

Testing a bug in Tracker

NB This is the process members of the moodle-testers group should follow to move bugs from 'resolved' to 'closed'.
*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.

*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.
*All resolved bugs should be tested. Bugs with a resolution code of "fixed" represent bugs where code has been updated, and probably represent more of a challenge than bugs with resoluton codes of duplicate, won't fix, and not a bug, and can't reproduce. Please ensure bugs have been closed with a proper resolution code. Unfortunately it's not easy to change a resolution code in Tracker once the bug has been resolved (the only way is to reopen, then re-resolve).
*Don't be afraid to discuss your testing with the developer assigned to the bug. Simply adding a comment should get the attention of the developer as they are notified of all changes.

==Detailed description of Tracker fields and groups ==
===Tracker fields===
NB A short explanation appears under each field in Tracker.

'''Project''' - Required field. Tracker is made of multiple projects. At present there are 3: 'moodle', 'moodle.org sites' and 'Non-core contributed modules'. 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; specify 'Non-core contributed modules' for issues/bugs related to contributed modules.

'''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. Bugs with serious security implications are restricted so that only members of the moodle-security group can see them.

'''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''' - Required field. This is the Moodle version in which the bug has been found. It is entered by the person logging the bug, and typically only 1 version is specified. Enter your current version when logging an 'improvement', 'task', or 'new feature' as this will help assess the state of the product when the request was made.

'''Assigned To''' - This is the person who will fix (code) the problem. Tracker automatically assigns bugs to Component Leads. Developers or QA Testers can reassign issues.

'''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 issue.

'''Fixed Version/s''' - This is the Moodle version the bug was or will be fixed in. Basically you should think '''Which release notes should this appear in?''' This field is normally completed by the developer when the bug has been resolved or by lead developers allocating bugs for a specific release. Normally only one version is specified in this field. It symbolises the ''first'' version of Moodle where the change will be seen.
:Example: after Moodle 1.9 has been released, if you fix a bug on the MOODLE_19_STABLE and HEAD branches, mark it as fixed in 1.9.1. If you also backported to MOODLE_18_STABLE, then add the version of the next 1.8.x release too.

:If you resolve the bug as anything but "Fixed" (Cannot Reproduce, Won't Fix, etc.) leave Fix Version/s blank.
:If you resolve the bug as Duplicate, then create a link to the duplicate issue.
:These Fix version/s are used to automatically build release notes (see the tabs on http://tracker.moodle.org/browse/MDL).

'''Attachment''' - Optional. Attach a file that will help developers and testers better understand the bug. Maximum attachement size is 512Kb.

'''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. Use this resolution code only when actual changes were made to Moodle code.
:''Won't Fix'' - The problem described is an issue which will never be fixed.
:''Not a bug'' - This issue is not a bug; was logged in error. Use this code if the bug was fixed by another bug report or in some earlier Moodle version.
:''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.

=== 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.

'''Moodle Security groups''' [groupname=moodle-security] - Trusted developers and administrators who need to work on and learn about security issues.

"Nobody" is a Tracker user created to alert users to the fact that an issue hasn't been assigned to a developer. These issues are regularly reviewed by the team at Moodle HQ.

NB You can browse a project while not logged in to Tracker, however you will be unable change/edit/comment on bugs.

=== Link types ===
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.
'''Don't be afraid to link bugs. ''' 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.

==See also==

*[[Development:Weekly Code Review]]
*[http://www.atlassian.com/software/jira/ Jira] Tracker is a slightly customised version of Atlassian's product
*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]

[[Category:Teacher]]
[[Category:Administrator]]
[[Category:Developer]]
[[Category:Developer tools]]

[[es:Sistema de bugs]]
[[fr:Traqueur de bogues]]

Tracker

2008-04-23T08:32:33Z

Mblake: /* Tracker fields */

[[Image:Tracker.jpg]] '''is Moodle's''' [[Image:Issue Tracker MoodleOrg link.JPG]]

Issue tracking is an important part of a continuous quality control process. It involves the reporting of problems (bugs), ideas for improvement and new features. Unlike most proprietary software programs, Moodle issue reporting and tracking information is open to everyone. Moodle's issue tracking system is called '''[http://tracker.moodle.org Moodle Tracker]'''. We welcome your requests for new features, improvements, or even constructive criticism of existing features.

The beauty of open source is that anyone can participate and help to create a better product for all of us to enjoy. Please help us by using [http://tracker.moodle.org Moodle Tracker]!

==Basics==
===Logging in to 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.
*If you've forgotten your password, go [http://tracker.moodle.org here] and select 'forgot password' which is just under the 'log in' button. Follow the prompts.

=== Summary: 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.

=== How to write a good Tracker entry===
A good report will include:
*Summary (describe the issue in 1 or 2 sentences)
*Description (a concise yet complete summary of the problem or improvement)
*Steps to Reproduce: A detailed, easy-to-follow sequence of steps a developer can follow to reproduce the problem. If possible, provide a URL so a developer can see the problem with one click.
*Actual Results: What the application did after performing the above steps.
*Expected Results: What the application should have done, were the bug not present. Provide as much detail as possible. Your expectation might mean that help instructions need to be improved or interface changed.

If possible, include additional information that may be helpful to the developer:
*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)
* 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.
* Provide details 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
**Client-side operating system type and version number
**Web browser type and version number

* You don't need to provide 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.

Here are some examples of good bug reports: MDL-6030, MDL-5688, MDL-12505

*A good external reference to help write a tracker entry can be found at [http://developer.mozilla.org/en/docs/Bug_writing_guidelines mozilla bug writing guidelines].

"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.

==Tracker process==
===Logging new issues or improvements===
Anyone with a Tracker account can log issues. See instructions above for writing good quality bug reports. It is important that you search Tracker to determine if your problem or suggestion for improvement has already been reported. If it has you are encouraged to add more information (use the "comment" function), vote for the issue, or watch it (more on this later).

You will receive an email when you log a new bug or make updates to bugs you've reported. You'll also receive notification when updates are made to bugs you're watching.

You can monitor, or '''watch''' issues reported by others. To do this, open the issue, then select "Watch it" from the left hand navigation panel. To add others to the watchlist for your issue, open the issue, select the option "Watching" from the left hand navigation panel. These people will receive email notification when the issue is updated.

Tracker provides a facility to '''Link''' issues. 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. See [insert section name] for detailed list of link types.

'''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]

===Resolving issues=== (this section should be reviewed)
Issues are resolved in Tracker to show that they've been actioned. Only Moodle core developers and testers are permitted to change the status of bugs in Tracker to "resolved" or "closed".

This is the general process a developer will follow when actioning a Tracker issue:

# Issues are automatically assigned at the time they're created based on component type; they may be reassigned by developers or Component Leads.
# Developers fix, modify or add code and check into CVS. The Tracker issue number is included which automatically links the CVS change to Tracker.
# Patches are attached to Tracker issues so that they may be verified and possibly included in CVS.
# Appropriate comments should be added in Tracker describing the fix. The bug's status is changed to '''Resolved'''.
# The developer should indicate which version of Moodle the change will be included in using the '''Fix Version/s'''. You should use this to indicate which branch(es) you checked the fix into (example below).
# The only exception to not moving a bug to Resolved is if a developer believes there is no value in testing the resolved issue, in which case the bug status can be changed to Closed.

===Testing issues===
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 for 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. Obviously testers should have the skills and knowledge to sufficiently test the issue - experience is important - but don't forget there are others in the Moodle community who may be willing to lend a hand. 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.

Testing a bug in Tracker

NB This is the process members of the moodle-testers group should follow to move bugs from 'resolved' to 'closed'.
*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.

*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.
*All resolved bugs should be tested. Bugs with a resolution code of "fixed" represent bugs where code has been updated, and probably represent more of a challenge than bugs with resoluton codes of duplicate, won't fix, and not a bug, and can't reproduce. Please ensure bugs have been closed with a proper resolution code. Unfortunately it's not easy to change a resolution code in Tracker once the bug has been resolved (the only way is to reopen, then re-resolve).
*Don't be afraid to discuss your testing with the developer assigned to the bug. Simply adding a comment should get the attention of the developer as they are notified of all changes.

==Detailed description of Tracker fields and groups ==
===Tracker fields===
NB A short explanation appears under each field in Tracker.

'''Project''' - Required field. Tracker is made of multiple projects. At present there are 3: 'moodle', 'moodle.org sites' and 'Non-core contributed modules'. 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; specify 'Non-core contributed modules' for issues/bugs related to contributed modules.

'''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. Bugs with serious security implications are restricted so that only members of the moodle-security group can see them.

'''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''' - Required field. This is the Moodle version in which the bug has been found. It is entered by the person logging the bug, and typically only 1 version is specified. Enter your current version when logging an 'improvement', 'task', or 'new feature' as this will help assess the state of the product when the request was made.

'''Assigned To''' - This is the person who will fix (code) the problem. Tracker automatically assigns bugs to Component Leads. Developers or QA Testers can reassign issues.

'''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 issue.

'''Fixed Version/s''' - This is the Moodle version the bug was or will be fixed in. Basically you should think '''Which release notes should this appear in?''' This field is normally completed by the developer when the bug has been resolved or by lead developers allocating bugs for a specific release. Normally only one version is specified in this field. It symbolises the ''first'' version of Moodle where the change will be seen.
:Example: after Moodle 1.9 has been released, if you fix a bug on the MOODLE_19_STABLE and HEAD branches, mark it as fixed in 1.9.1. If you also backported to MOODLE_18_STABLE, then add the version of the next 1.8.x release too.

:If you resolve the bug as anything but "Fixed" (Cannot Reproduce, Won't Fix, etc.) leave Fix Version/s blank.
:If you resolve the bug as Duplicate, then create a link to the duplicate issue.
:These Fix version/s are used to automatically build release notes (see the tabs on http://tracker.moodle.org/browse/MDL).

'''Attachment''' - Optional. Attach a file that will help developers and testers better understand the bug. Maximum attachement size is 512Kb.

'''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. Use this resolution code only when actual changes were made to Moodle code.
:''Won't Fix'' - The problem described is an issue which will never be fixed.
:''Not a bug'' - This issue is not a bug; was logged in error. Use this code if the bug was fixed by another bug report or in some earlier Moodle version.
:''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.

=== 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.

'''Moodle Security groups''' [groupname=moodle-security] - Trusted developers and administrators who need to work on and learn about security issues.

NB You can browse a project while not logged in to Tracker, however you will be unable change/edit/comment on bugs.

=== Link types ===
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.
'''Don't be afraid to link bugs. ''' 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.

==See also==

*[[Development:Weekly Code Review]]
*[http://www.atlassian.com/software/jira/ Jira] Tracker is a slightly customised version of Atlassian's product
*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]

[[Category:Teacher]]
[[Category:Administrator]]
[[Category:Developer]]
[[Category:Developer tools]]

[[es:Sistema de bugs]]
[[fr:Traqueur de bogues]]

Development:Bug triage

2008-03-20T07:46:24Z

Mblake:

This page is for analysing and developing a Moodle issue triage process. This process is STILL UNDER CONSTRUCTION.

Triage is medical term referring to the process of prioritizing patients based on the severity of their condition so as to maximise benefit (help as many as possible) when resources are limited.

Moodle issue triage is a process where issues are sorted and categorised with the intent of maximising benefit to Moodle given limited resources. It should help us act on those issues that require immediate attention (e.g. high priority, affects most users, is a security issue) while relegating issues deemed less critical to a lessor status, to be actioned at a later date.

Triaging issues should help ensure we appropriately manage all reported issues (bugs as well as feature requests).

--> The following white paper assumes a 2 step process: (1) quality review of information in Tracker, and (2) triage
**the primary benefit of a 2 step process is to allocate resources appropriately: team members with greater product knowledge can focus on triage while those with less knowledge can focus on Tracker quality assurance (while hopefully building product knowledge).

==Tracker Quality Review==
Each Tracker issue must be in a "fit state", so that an informed decision can be made about it. This is a quality review of the information entered into Tracker. Every new issue entered into the Tracker should be reviewed.

Here is a starting point for Tracker QA:

**Does the Summary accurately reflect the issue?
**Is there enough information for a developer or a tester to reproduce the problem.
**Are fields completed adequately?
**Has it been categorised correctly (priority is an obvious example)
**Has it been assigned to the appropriate tester/developer?

Action item: identify a filter to ensure every new issue is reviewed on a periodic basis. Is the nightly? Weekly?
Action item: identify a person/team to review new issues for quality.
Action item: identify a way to know that each issue has been reviewed.

==Triage process==
Triage should take place against issues that have been verified.

Action item: identify a person/team with sufficient product knowledge to make and informed call on newly logged issues.

==Triage filters==

*[http://tracker.moodle.org/secure/IssueNavigator.jspa?mode=hide&requestId=10544 1.9.x Reported (Need Triage)] - These are bugs that are reported as being in 1.9 stable branch but appear not to be fixed yet. They need to be looked at and given a fix version or closed. Note that many of these may not be relevant, or may be miscategorised, so they need to be processed.

*[http://tracker.moodle.org/secure/IssueNavigator.jspa?mode=hide&requestId=10231 Recent unresolved bugs that need triage] - These bugs need checking to make sure they are assigned to the right person, category etc.

==Fix versions==

Bugs are removed from the triage list by giving them a fix version or closing them. Confirmed bugs should be given the next unreleased version as the fix version, for example a confirmed bug in 1.9 should have a 1.9.1 fix version.

==Adding watchers==

If assistance is required with a bug, additional watchers may be added then a comment added. If documentation is required, Helen should be added as a watcher, then a comment saying "this requires documentation" added.

Development:Bug triage

2008-03-20T07:37:21Z

Mblake:

This page is for analysing and developing a Moodle issue triage process. This process is STILL UNDER CONSTRUCTION.

Triage is medical term referring to the process of prioritizing patients based on the severity of their condition so as to maximise benefit (help as many as possible) when resources are limited.

Moodle issue triage is a process where issues are sorted and categorised with the intent of maximising benefit to Moodle given limited resources. It should help us act on those issues that require immediate attention (e.g. high priority, affects most users, is a security issue) while relegating issues deemed less critical to a lessor status, to be actioned at a later date.

Triaging issues should help ensure we are appropriately manage all reported issues (bugs as well as feature requests).

--> The following white paper assumes a 2 step process: (1) quality review of information in Tracker, and (2) triage
**the primary benefit of this 2 step process is to allocate resources appropriately: team members with greater product knowledge can focus on triage while those with less knowledge can focus on Tracker quality assurance (while hopefully building product knowledge).

==Before triage can take place==
Each tracker issues must be in a "fit state", so that an informed decision can be made about it. This is a quality review of the information entered into Tracker. Every new issue entered into the Tracker should be reviewed.

Here is a starting point for Tracker QA:

**Does the Summary accurately reflect the issue?
**Is there enough information for a developer or a tester to reproduce the problem.
**Are fields completed adequately?
**Has it been categorised correctly (priority is an obvious example)
**Has it been assigned to the appropriate tester/developer?

Action item: identify a filter to ensure every new issue is reviewed on a periodic basis. Is the nightly? Weekly?
Action item: identify a person/team to review new issues for quality.
Action item: identify a way to know that each issue has been reviewed.

==Triage process==
The actual triage process should take place against issues that have already been verified as fit.

Action item: identify a person/team with sufficient product knowledge to make and informed call on newly logged issues.

==Triage filters==

*[http://tracker.moodle.org/secure/IssueNavigator.jspa?mode=hide&requestId=10544 1.9.x Reported (Need Triage)] - These are bugs that are reported as being in 1.9 stable branch but appear not to be fixed yet. They need to be looked at and given a fix version or closed. Note that many of these may not be relevant, or may be miscategorised, so they need to be processed.

*[http://tracker.moodle.org/secure/IssueNavigator.jspa?mode=hide&requestId=10231 Recent unresolved bugs that need triage] - These bugs need checking to make sure they are assigned to the right person, category etc.

==Fix versions==

Bugs are removed from the triage list by giving them a fix version or closing them. Confirmed bugs should be given the next unreleased version as the fix version, for example a confirmed bug in 1.9 should have a 1.9.1 fix version.

==Adding watchers==

If assistance is required with a bug, additional watchers may be added then a comment added. If documentation is required, Helen should be added as a watcher, then a comment saying "this requires documentation" added.

Tracker

2008-03-14T06:00:49Z

Mblake: /* Tracker fields */

[[Image:Tracker.jpg]] '''is Moodle's''' [[Image:Issue Tracker MoodleOrg link.JPG]]

Issue tracking is an important part of a continuous quality control process. It involves reporting of problems (bugs), ideas for improvement and new features. Unlike most proprietary software programs, Moodle issue reporting and tracking information is open to everyone. Moodle's issue tracking system is called '''[http://tracker.moodle.org Moodle Tracker]'''. We welcome your requests for new features, improvements, or even constructive criticism of existing features.

The beauty of open source is that anyone can participate and help to create a better product for all of us to enjoy. Please help us by using [http://tracker.moodle.org Moodle Tracker]!

==Basics==
===Logging in to 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.
*If you've forgotten your password, go [http://tracker.moodle.org here] and select 'forgot password' which is just under the 'log in' button. Follow the prompts.

=== Summary: 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.

=== How to write a good Tracker entry===
A good report will include:
*Summary (describe the issue in 1 or 2 sentences)
*Description (a concise yet complete summary of the problem or improvement)
*Steps to Reproduce: A detailed, easy-to-follow sequence of steps a developer can follow to reproduce the problem. If possible, provide a URL so a developer can see the problem with one click.
*Actual Results: What the application did after performing the above steps.
*Expected Results: What the application should have done, were the bug not present. Provide as much detail as possible. Your expectation might mean that help instructions need to be improved or interface changed.

If possible, include additional information that may be helpful to the developer:
*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)
* 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.
* Provide details 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
**Client-side operating system type and version number
**Web browser type and version number

* You don't need to provide 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.

Here are some examples of good bug reports: MDL-6030, MDL-5688, MDL-12505

*A good external reference to help write a tracker entry can be found at [http://developer.mozilla.org/en/docs/Bug_writing_guidelines mozilla bug writing guidelines].

"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.

==Tracker process==
===Logging new issues or improvements===
Anyone with a Tracker account can log issues. See instructions above for writing good quality bug reports. It is important that you search Tracker to determine if your problem or suggestion for improvement has already been reported. If it has you are encouraged to add more information (use the "comment" function), vote for the issue, or watch it (more on this later).

You will receive an email when you log a new bug or make updates to bugs you've reported. You'll also receive notification when updates are made to bugs you're watching.

You can monitor, or '''watch''' issues reported by others. To do this, open the issue, then select "Watch it" from the left hand navigation panel. To add others to the watchlist for your issue, open the issue, select the option "Watching" from the left hand navigation panel. These people will receive email notification when the issue is updated.

Tracker provides a facility to '''Link''' issues. 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. See [insert section name] for detailed list of link types.

'''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]

===Resolving issues=== (this section should be reviewed)
Issues are resolved in Tracker to show that they've been actioned. Only Moodle core developers and testers are permitted to change the status of bugs in Tracker to "resolved" or "closed".

This is the general process a developer will follow when actioning a Tracker issue:

# Issues are automatically assigned at the time they're created based on component type; they may be reassigned by developers or Component Leads.
# Developers fix, modify or add code and check into CVS. The Tracker issue number is included which automatically links the CVS change to Tracker.
# Patches are attached to Tracker issues so that they may be verified and possibly included in CVS.
# Appropriate comments should be added in Tracker describing the fix. The bug's status is changed to '''Resolved'''.
# The developer should indicate which version of Moodle the change will be included in using the '''Fix Version/s'''. You should use this to indicate which branch(es) you checked the fix into (example below).
# The only exception to not moving a bug to Resolved is if a developer believes there is no value in testing the resolved issue, in which case the bug status can be changed to Closed.

===Testing issues===
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 for 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. Obviously testers should have the skills and knowledge to sufficiently test the issue - experience is important - but don't forget there are others in the Moodle community who may be willing to lend a hand. 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.

Testing a bug in Tracker

NB This is the process members of the moodle-testers group should follow to move bugs from 'resolved' to 'closed'.
*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.

*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.
*All resolved bugs should be tested. Bugs with a resolution code of "fixed" represent bugs where code has been updated, and probably represent more of a challenge than bugs with resoluton codes of duplicate, won't fix, and not a bug, and can't reproduce. Please ensure bugs have been closed with a proper resolution code. Unfortunately it's not easy to change a resolution code in Tracker once the bug has been resolved (the only way is to reopen, then re-resolve).
*Don't be afraid to discuss your testing with the developer assigned to the bug. Simply adding a comment should get the attention of the developer as they are notified of all changes.

==Detailed description of Tracker fields and groups ==
===Tracker fields===
NB A short explanation appears under each field in Tracker.

'''Project''' - Required field. Tracker is made of multiple projects. At present there are 3: 'moodle', 'moodle.org sites' and 'Non-core contributed modules'. 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; specify 'Non-core contributed modules' for issues/bugs related to contributed modules.

'''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. Bugs with serious security implications are restricted so that only members of the moodle-security group can see them.

'''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''' - Required field. This is the Moodle version in which the bug has been found. It is entered by the person logging the bug, and typically only 1 version is specified. Enter your current version when logging an 'improvement', 'task', or 'new feature' as this will help assess the state of the product when the request was made.

'''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 issue.

'''Fixed Version/s''' - This is the Moodle version the bug was or will be fixed in. This field is normally completed by the developer when the bug has been resolved or by lead developers allocating bugs for a specific release. Normally only one version is specified in this field. It symbolises the ''first'' version of Moodle where the change will be seen.
:Example: after Moodle 1.9 has been released, if you fix a bug on the MOODLE_19_STABLE and HEAD branches, mark it as fixed in 1.9.1.

:If you resolve the bug as anything but "Fixed" (Cannot Reproduce, Won't Fix, etc.) leave Fix Version/s blank.
:If you resolve the bug as Duplicate, then create a link to the duplicate issue.
:These Fix version/s are used to automatically build release notes (see the tabs on http://tracker.moodle.org/browse/MDL).

'''Attachment''' - Optional. Attach a file that will help developers and testers better understand the bug. Maximum attachement size is 512Kb.

'''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. Use this resolution code only when actual changes were made to Moodle code.
:''Won't Fix'' - The problem described is an issue which will never be fixed.
:''Not a bug'' - This issue is not a bug; was logged in error. Use this code if the bug was fixed by another bug report or in some earlier Moodle version.
:''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.

=== 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.

'''Moodle Security groups''' [groupname=moodle-security] - Trusted developers and administrators who need to work on and learn about security issues.

NB You can browse a project while not logged in to Tracker, however you will be unable change/edit/comment on bugs.

=== Link types ===
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.
'''Don't be afraid to link bugs. ''' 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.

==See also==

*[http://www.atlassian.com/software/jira/ Jira] Tracker is a slightly customised version of Atlassian's product
*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]

[[Category:Teacher]]
[[Category:Administrator]]
[[Category:Developer]]
[[Category:Developer tools]]

[[es:Sistema de bugs]]
[[fr:Traqueur de bogues]]

Tracker

2008-03-13T08:11:28Z

Mblake: /* Link types */

[[Image:Tracker.jpg]] '''is Moodle's''' [[Image:Issue Tracker MoodleOrg link.JPG]]

Issue tracking is an important part of a continuous quality control process. It involves reporting of problems (bugs), ideas for improvement and new features. Unlike most proprietary software programs, Moodle issue reporting and tracking information is open to everyone. Moodle's issue tracking system is called '''[http://tracker.moodle.org Moodle Tracker]'''. We welcome your requests for new features, improvements, or even constructive criticism of existing features.

The beauty of open source is that anyone can participate and help to create a better product for all of us to enjoy. Please help us by using [http://tracker.moodle.org Moodle Tracker]!

==Basics==
===Logging in to 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.
*If you've forgotten your password, go [http://tracker.moodle.org here] and select 'forgot password' which is just under the 'log in' button. Follow the prompts.

=== Summary: 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.

=== How to write a good Tracker entry===
A good report will include:
*Summary (describe the issue in 1 or 2 sentences)
*Description (a concise yet complete summary of the problem or improvement)
*Steps to Reproduce: A detailed, easy-to-follow sequence of steps a developer can follow to reproduce the problem. If possible, provide a URL so a developer can see the problem with one click.
*Actual Results: What the application did after performing the above steps.
*Expected Results: What the application should have done, were the bug not present. Provide as much detail as possible. Your expectation might mean that help instructions need to be improved or interface changed.

If possible, include additional information that may be helpful to the developer:
*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)
* 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.
* Provide details 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
**Client-side operating system type and version number
**Web browser type and version number

* You don't need to provide 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.

Here are some examples of good bug reports: MDL-6030, MDL-5688, MDL-12505

*A good external reference to help write a tracker entry can be found at [http://developer.mozilla.org/en/docs/Bug_writing_guidelines mozilla bug writing guidelines].

"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.

==Tracker process==
===Logging new issues or improvements===
Anyone with a Tracker account can log issues. See instructions above for writing good quality bug reports. It is important that you search Tracker to determine if your problem or suggestion for improvement has already been reported. If it has you are encouraged to add more information (use the "comment" function), vote for the issue, or watch it (more on this later).

You will receive an email when you log a new bug or make updates to bugs you've reported. You'll also receive notification when updates are made to bugs you're watching.

You can monitor, or '''watch''' issues reported by others. To do this, open the issue, then select "Watch it" from the left hand navigation panel. To add others to the watchlist for your issue, open the issue, select the option "Watching" from the left hand navigation panel. These people will receive email notification when the issue is updated.

Tracker provides a facility to '''Link''' issues. 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. See [insert section name] for detailed list of link types.

'''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]

===Resolving issues=== (this section should be reviewed)
Issues are resolved in Tracker to show that they've been actioned. Only Moodle core developers and testers are permitted to change the status of bugs in Tracker to "resolved" or "closed".

This is the general process a developer will follow when actioning a Tracker issue:

# Issues are automatically assigned at the time they're created based on component type; they may be reassigned by developers or Component Leads.
# Developers fix, modify or add code and check into CVS. The Tracker issue number is included which automatically links the CVS change to Tracker.
# Patches are attached to Tracker issues so that they may be verified and possibly included in CVS.
# Appropriate comments should be added in Tracker describing the fix. The bug's status is changed to '''Resolved'''.
# The developer should indicate which version of Moodle the change will be included in using the '''Fix Version/s'''. You should use this to indicate which branch(es) you checked the fix into (example below).
# The only exception to not moving a bug to Resolved is if a developer believes there is no value in testing the resolved issue, in which case the bug status can be changed to Closed.

===Testing issues===
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 for 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. Obviously testers should have the skills and knowledge to sufficiently test the issue - experience is important - but don't forget there are others in the Moodle community who may be willing to lend a hand. 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.

Testing a bug in Tracker

NB This is the process members of the moodle-testers group should follow to move bugs from 'resolved' to 'closed'.
*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.

*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.
*All resolved bugs should be tested. Bugs with a resolution code of "fixed" represent bugs where code has been updated, and probably represent more of a challenge than bugs with resoluton codes of duplicate, won't fix, and not a bug, and can't reproduce. Please ensure bugs have been closed with a proper resolution code. Unfortunately it's not easy to change a resolution code in Tracker once the bug has been resolved (the only way is to reopen, then re-resolve).
*Don't be afraid to discuss your testing with the developer assigned to the bug. Simply adding a comment should get the attention of the developer as they are notified of all changes.

==Detailed description of Tracker fields and groups ==
===Tracker fields===
NB A short explanation appears under each field in Tracker.

'''Project''' - Required field. Tracker is made of multiple projects. At present there are 3: 'moodle', 'moodle.org sites' and 'Non-core contributed modules'. 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; specify 'Non-core contributed modules' for issues/bugs related to contributed modules.

'''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. Bugs with serious security implications are restricted so that only members of the moodle-security group can see them.

'''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''' - Required field. This is the Moodle version in which the bug has been found. It is entered by the person logging the bug, and typically only 1 version is specified. Enter your current version when logging an 'improvement', 'task', or 'new feature' as this will help assess the state of the product when the request was made.

'''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 Moodle version the bug was or will be fixed in. This field is normally completed by the developer when the bug has been resolved or by lead developers allocating bugs for a specific release. Normally only one version is specified in this field. It symbolises the ''first'' version of Moodle where the change will be seen.

:More information about setting the Fix Version/s field

:Suppose that the current stable releases are 1.8.3, 1.7.3, 1.6.5 and that 1.9 has branched so we have 1.9 beta+ and 2.0 dev. Suppose you fix a bug on the MOODLE_17_STABLE, MOODLE_18_STABLE, MOODLE_19_STABLE and HEAD. Then mark the bug as fixed in 1.7.4, 1.8.4 and 1.9.

:After Moodle 1.9 has been released, if you fix a bug on the MOODLE_19_STABLE and HEAD branches, mark it as fixed in 1.9.1 and 2.0.

:If you resolved the bug as Cannot reproduce, or Won't fix, etc. Then leave the Fix version blank.

:If you resolve the bug as Duplicate, then create a link to the duplicate issue.

:These Fix version/s are used to automatically build release notes (see the tabs on http://tracker.moodle.org/browse/MDL).

'''Attachment''' - Optional. Attach a file that will help developers and testers better understand the bug. Maximum attachement size is 512Kb.

'''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. Use this resolution code only when actual changes were made to Moodle code.
:''Won't Fix'' - The problem described is an issue which will never be fixed.
:''Not a bug'' - This issue is not a bug; was logged in error. Use this code if the bug was fixed by another bug report or in some earlier Moodle version.
:''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.

=== 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.

'''Moodle Security groups''' [groupname=moodle-security] - Trusted developers and administrators who need to work on and learn about security issues.

NB You can browse a project while not logged in to Tracker, however you will be unable change/edit/comment on bugs.

=== Link types ===
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.
'''Don't be afraid to link bugs. ''' 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.

==See also==

*[http://www.atlassian.com/software/jira/ Jira] Tracker is a slightly customised version of Atlassian's product
*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]

[[Category:Teacher]]
[[Category:Administrator]]
[[Category:Developer]]
[[Category:Developer tools]]

[[es:Sistema de bugs]]
[[fr:Traqueur de bogues]]

Tracker

2008-03-13T08:09:56Z

Mblake: /* Link types */

[[Image:Tracker.jpg]] '''is Moodle's''' [[Image:Issue Tracker MoodleOrg link.JPG]]

Issue tracking is an important part of a continuous quality control process. It involves reporting of problems (bugs), ideas for improvement and new features. Unlike most proprietary software programs, Moodle issue reporting and tracking information is open to everyone. Moodle's issue tracking system is called '''[http://tracker.moodle.org Moodle Tracker]'''. We welcome your requests for new features, improvements, or even constructive criticism of existing features.

The beauty of open source is that anyone can participate and help to create a better product for all of us to enjoy. Please help us by using [http://tracker.moodle.org Moodle Tracker]!

==Basics==
===Logging in to 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.
*If you've forgotten your password, go [http://tracker.moodle.org here] and select 'forgot password' which is just under the 'log in' button. Follow the prompts.

=== Summary: 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.

=== How to write a good Tracker entry===
A good report will include:
*Summary (describe the issue in 1 or 2 sentences)
*Description (a concise yet complete summary of the problem or improvement)
*Steps to Reproduce: A detailed, easy-to-follow sequence of steps a developer can follow to reproduce the problem. If possible, provide a URL so a developer can see the problem with one click.
*Actual Results: What the application did after performing the above steps.
*Expected Results: What the application should have done, were the bug not present. Provide as much detail as possible. Your expectation might mean that help instructions need to be improved or interface changed.

If possible, include additional information that may be helpful to the developer:
*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)
* 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.
* Provide details 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
**Client-side operating system type and version number
**Web browser type and version number

* You don't need to provide 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.

Here are some examples of good bug reports: MDL-6030, MDL-5688, MDL-12505

*A good external reference to help write a tracker entry can be found at [http://developer.mozilla.org/en/docs/Bug_writing_guidelines mozilla bug writing guidelines].

"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.

==Tracker process==
===Logging new issues or improvements===
Anyone with a Tracker account can log issues. See instructions above for writing good quality bug reports. It is important that you search Tracker to determine if your problem or suggestion for improvement has already been reported. If it has you are encouraged to add more information (use the "comment" function), vote for the issue, or watch it (more on this later).

You will receive an email when you log a new bug or make updates to bugs you've reported. You'll also receive notification when updates are made to bugs you're watching.

You can monitor, or '''watch''' issues reported by others. To do this, open the issue, then select "Watch it" from the left hand navigation panel. To add others to the watchlist for your issue, open the issue, select the option "Watching" from the left hand navigation panel. These people will receive email notification when the issue is updated.

Tracker provides a facility to '''Link''' issues. 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. See [insert section name] for detailed list of link types.

'''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]

===Resolving issues=== (this section should be reviewed)
Issues are resolved in Tracker to show that they've been actioned. Only Moodle core developers and testers are permitted to change the status of bugs in Tracker to "resolved" or "closed".

This is the general process a developer will follow when actioning a Tracker issue:

# Issues are automatically assigned at the time they're created based on component type; they may be reassigned by developers or Component Leads.
# Developers fix, modify or add code and check into CVS. The Tracker issue number is included which automatically links the CVS change to Tracker.
# Patches are attached to Tracker issues so that they may be verified and possibly included in CVS.
# Appropriate comments should be added in Tracker describing the fix. The bug's status is changed to '''Resolved'''.
# The developer should indicate which version of Moodle the change will be included in using the '''Fix Version/s'''. You should use this to indicate which branch(es) you checked the fix into (example below).
# The only exception to not moving a bug to Resolved is if a developer believes there is no value in testing the resolved issue, in which case the bug status can be changed to Closed.

===Testing issues===
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 for 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. Obviously testers should have the skills and knowledge to sufficiently test the issue - experience is important - but don't forget there are others in the Moodle community who may be willing to lend a hand. 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.

Testing a bug in Tracker

NB This is the process members of the moodle-testers group should follow to move bugs from 'resolved' to 'closed'.
*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.

*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.
*All resolved bugs should be tested. Bugs with a resolution code of "fixed" represent bugs where code has been updated, and probably represent more of a challenge than bugs with resoluton codes of duplicate, won't fix, and not a bug, and can't reproduce. Please ensure bugs have been closed with a proper resolution code. Unfortunately it's not easy to change a resolution code in Tracker once the bug has been resolved (the only way is to reopen, then re-resolve).
*Don't be afraid to discuss your testing with the developer assigned to the bug. Simply adding a comment should get the attention of the developer as they are notified of all changes.

==Detailed description of Tracker fields and groups ==
===Tracker fields===
NB A short explanation appears under each field in Tracker.

'''Project''' - Required field. Tracker is made of multiple projects. At present there are 3: 'moodle', 'moodle.org sites' and 'Non-core contributed modules'. 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; specify 'Non-core contributed modules' for issues/bugs related to contributed modules.

'''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. Bugs with serious security implications are restricted so that only members of the moodle-security group can see them.

'''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''' - Required field. This is the Moodle version in which the bug has been found. It is entered by the person logging the bug, and typically only 1 version is specified. Enter your current version when logging an 'improvement', 'task', or 'new feature' as this will help assess the state of the product when the request was made.

'''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 Moodle version the bug was or will be fixed in. This field is normally completed by the developer when the bug has been resolved or by lead developers allocating bugs for a specific release. Normally only one version is specified in this field. It symbolises the ''first'' version of Moodle where the change will be seen.

:More information about setting the Fix Version/s field

:Suppose that the current stable releases are 1.8.3, 1.7.3, 1.6.5 and that 1.9 has branched so we have 1.9 beta+ and 2.0 dev. Suppose you fix a bug on the MOODLE_17_STABLE, MOODLE_18_STABLE, MOODLE_19_STABLE and HEAD. Then mark the bug as fixed in 1.7.4, 1.8.4 and 1.9.

:After Moodle 1.9 has been released, if you fix a bug on the MOODLE_19_STABLE and HEAD branches, mark it as fixed in 1.9.1 and 2.0.

:If you resolved the bug as Cannot reproduce, or Won't fix, etc. Then leave the Fix version blank.

:If you resolve the bug as Duplicate, then create a link to the duplicate issue.

:These Fix version/s are used to automatically build release notes (see the tabs on http://tracker.moodle.org/browse/MDL).

'''Attachment''' - Optional. Attach a file that will help developers and testers better understand the bug. Maximum attachement size is 512Kb.

'''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. Use this resolution code only when actual changes were made to Moodle code.
:''Won't Fix'' - The problem described is an issue which will never be fixed.
:''Not a bug'' - This issue is not a bug; was logged in error. Use this code if the bug was fixed by another bug report or in some earlier Moodle version.
:''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.

=== 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.

'''Moodle Security groups''' [groupname=moodle-security] - Trusted developers and administrators who need to work on and learn about security issues.

NB You can browse a project while not logged in to Tracker, however you will be unable change/edit/comment on bugs.

=== Link types ===
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.
Don't be afraid to link bugs. It's very helpful to developers and testers to get a complete picture of a problem.

==See also==

*[http://www.atlassian.com/software/jira/ Jira] Tracker is a slightly customised version of Atlassian's product
*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]

[[Category:Teacher]]
[[Category:Administrator]]
[[Category:Developer]]
[[Category:Developer tools]]

[[es:Sistema de bugs]]
[[fr:Traqueur de bogues]]

Tracker

2008-03-13T08:08:45Z

Mblake: /* Miscellaneous (temporary title) */

[[Image:Tracker.jpg]] '''is Moodle's''' [[Image:Issue Tracker MoodleOrg link.JPG]]

Issue tracking is an important part of a continuous quality control process. It involves reporting of problems (bugs), ideas for improvement and new features. Unlike most proprietary software programs, Moodle issue reporting and tracking information is open to everyone. Moodle's issue tracking system is called '''[http://tracker.moodle.org Moodle Tracker]'''. We welcome your requests for new features, improvements, or even constructive criticism of existing features.

The beauty of open source is that anyone can participate and help to create a better product for all of us to enjoy. Please help us by using [http://tracker.moodle.org Moodle Tracker]!

==Basics==
===Logging in to 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.
*If you've forgotten your password, go [http://tracker.moodle.org here] and select 'forgot password' which is just under the 'log in' button. Follow the prompts.

=== Summary: 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.

=== How to write a good Tracker entry===
A good report will include:
*Summary (describe the issue in 1 or 2 sentences)
*Description (a concise yet complete summary of the problem or improvement)
*Steps to Reproduce: A detailed, easy-to-follow sequence of steps a developer can follow to reproduce the problem. If possible, provide a URL so a developer can see the problem with one click.
*Actual Results: What the application did after performing the above steps.
*Expected Results: What the application should have done, were the bug not present. Provide as much detail as possible. Your expectation might mean that help instructions need to be improved or interface changed.

If possible, include additional information that may be helpful to the developer:
*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)
* 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.
* Provide details 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
**Client-side operating system type and version number
**Web browser type and version number

* You don't need to provide 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.

Here are some examples of good bug reports: MDL-6030, MDL-5688, MDL-12505

*A good external reference to help write a tracker entry can be found at [http://developer.mozilla.org/en/docs/Bug_writing_guidelines mozilla bug writing guidelines].

"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.

==Tracker process==
===Logging new issues or improvements===
Anyone with a Tracker account can log issues. See instructions above for writing good quality bug reports. It is important that you search Tracker to determine if your problem or suggestion for improvement has already been reported. If it has you are encouraged to add more information (use the "comment" function), vote for the issue, or watch it (more on this later).

You will receive an email when you log a new bug or make updates to bugs you've reported. You'll also receive notification when updates are made to bugs you're watching.

You can monitor, or '''watch''' issues reported by others. To do this, open the issue, then select "Watch it" from the left hand navigation panel. To add others to the watchlist for your issue, open the issue, select the option "Watching" from the left hand navigation panel. These people will receive email notification when the issue is updated.

Tracker provides a facility to '''Link''' issues. 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. See [insert section name] for detailed list of link types.

'''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]

===Resolving issues=== (this section should be reviewed)
Issues are resolved in Tracker to show that they've been actioned. Only Moodle core developers and testers are permitted to change the status of bugs in Tracker to "resolved" or "closed".

This is the general process a developer will follow when actioning a Tracker issue:

# Issues are automatically assigned at the time they're created based on component type; they may be reassigned by developers or Component Leads.
# Developers fix, modify or add code and check into CVS. The Tracker issue number is included which automatically links the CVS change to Tracker.
# Patches are attached to Tracker issues so that they may be verified and possibly included in CVS.
# Appropriate comments should be added in Tracker describing the fix. The bug's status is changed to '''Resolved'''.
# The developer should indicate which version of Moodle the change will be included in using the '''Fix Version/s'''. You should use this to indicate which branch(es) you checked the fix into (example below).
# The only exception to not moving a bug to Resolved is if a developer believes there is no value in testing the resolved issue, in which case the bug status can be changed to Closed.

===Testing issues===
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 for 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. Obviously testers should have the skills and knowledge to sufficiently test the issue - experience is important - but don't forget there are others in the Moodle community who may be willing to lend a hand. 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.

Testing a bug in Tracker

NB This is the process members of the moodle-testers group should follow to move bugs from 'resolved' to 'closed'.
*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.

*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.
*All resolved bugs should be tested. Bugs with a resolution code of "fixed" represent bugs where code has been updated, and probably represent more of a challenge than bugs with resoluton codes of duplicate, won't fix, and not a bug, and can't reproduce. Please ensure bugs have been closed with a proper resolution code. Unfortunately it's not easy to change a resolution code in Tracker once the bug has been resolved (the only way is to reopen, then re-resolve).
*Don't be afraid to discuss your testing with the developer assigned to the bug. Simply adding a comment should get the attention of the developer as they are notified of all changes.

==Detailed description of Tracker fields and groups ==
===Tracker fields===
NB A short explanation appears under each field in Tracker.

'''Project''' - Required field. Tracker is made of multiple projects. At present there are 3: 'moodle', 'moodle.org sites' and 'Non-core contributed modules'. 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; specify 'Non-core contributed modules' for issues/bugs related to contributed modules.

'''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. Bugs with serious security implications are restricted so that only members of the moodle-security group can see them.

'''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''' - Required field. This is the Moodle version in which the bug has been found. It is entered by the person logging the bug, and typically only 1 version is specified. Enter your current version when logging an 'improvement', 'task', or 'new feature' as this will help assess the state of the product when the request was made.

'''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 Moodle version the bug was or will be fixed in. This field is normally completed by the developer when the bug has been resolved or by lead developers allocating bugs for a specific release. Normally only one version is specified in this field. It symbolises the ''first'' version of Moodle where the change will be seen.

:More information about setting the Fix Version/s field

:Suppose that the current stable releases are 1.8.3, 1.7.3, 1.6.5 and that 1.9 has branched so we have 1.9 beta+ and 2.0 dev. Suppose you fix a bug on the MOODLE_17_STABLE, MOODLE_18_STABLE, MOODLE_19_STABLE and HEAD. Then mark the bug as fixed in 1.7.4, 1.8.4 and 1.9.

:After Moodle 1.9 has been released, if you fix a bug on the MOODLE_19_STABLE and HEAD branches, mark it as fixed in 1.9.1 and 2.0.

:If you resolved the bug as Cannot reproduce, or Won't fix, etc. Then leave the Fix version blank.

:If you resolve the bug as Duplicate, then create a link to the duplicate issue.

:These Fix version/s are used to automatically build release notes (see the tabs on http://tracker.moodle.org/browse/MDL).

'''Attachment''' - Optional. Attach a file that will help developers and testers better understand the bug. Maximum attachement size is 512Kb.

'''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. Use this resolution code only when actual changes were made to Moodle code.
:''Won't Fix'' - The problem described is an issue which will never be fixed.
:''Not a bug'' - This issue is not a bug; was logged in error. Use this code if the bug was fixed by another bug report or in some earlier Moodle version.
:''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.

=== 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.

'''Moodle Security groups''' [groupname=moodle-security] - Trusted developers and administrators who need to work on and learn about security issues.

NB You can browse a project while not logged in to Tracker, however you will be unable change/edit/comment on bugs.

=== Link types ===
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.

:'''Don't be afraid to link bugs.''' It's very helpful to developers and testers to get a complete picture of a problem.

==See also==

*[http://www.atlassian.com/software/jira/ Jira] Tracker is a slightly customised version of Atlassian's product
*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]

[[Category:Teacher]]
[[Category:Administrator]]
[[Category:Developer]]
[[Category:Developer tools]]

[[es:Sistema de bugs]]
[[fr:Traqueur de bogues]]

Tracker

2008-03-13T08:08:28Z

Mblake: /* Developer comments */

[[Image:Tracker.jpg]] '''is Moodle's''' [[Image:Issue Tracker MoodleOrg link.JPG]]

Issue tracking is an important part of a continuous quality control process. It involves reporting of problems (bugs), ideas for improvement and new features. Unlike most proprietary software programs, Moodle issue reporting and tracking information is open to everyone. Moodle's issue tracking system is called '''[http://tracker.moodle.org Moodle Tracker]'''. We welcome your requests for new features, improvements, or even constructive criticism of existing features.

The beauty of open source is that anyone can participate and help to create a better product for all of us to enjoy. Please help us by using [http://tracker.moodle.org Moodle Tracker]!

==Basics==
===Logging in to 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.
*If you've forgotten your password, go [http://tracker.moodle.org here] and select 'forgot password' which is just under the 'log in' button. Follow the prompts.

=== Summary: 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.

=== How to write a good Tracker entry===
A good report will include:
*Summary (describe the issue in 1 or 2 sentences)
*Description (a concise yet complete summary of the problem or improvement)
*Steps to Reproduce: A detailed, easy-to-follow sequence of steps a developer can follow to reproduce the problem. If possible, provide a URL so a developer can see the problem with one click.
*Actual Results: What the application did after performing the above steps.
*Expected Results: What the application should have done, were the bug not present. Provide as much detail as possible. Your expectation might mean that help instructions need to be improved or interface changed.

If possible, include additional information that may be helpful to the developer:
*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)
* 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.
* Provide details 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
**Client-side operating system type and version number
**Web browser type and version number

* You don't need to provide 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.

Here are some examples of good bug reports: MDL-6030, MDL-5688, MDL-12505

*A good external reference to help write a tracker entry can be found at [http://developer.mozilla.org/en/docs/Bug_writing_guidelines mozilla bug writing guidelines].

"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.

==Tracker process==
===Logging new issues or improvements===
Anyone with a Tracker account can log issues. See instructions above for writing good quality bug reports. It is important that you search Tracker to determine if your problem or suggestion for improvement has already been reported. If it has you are encouraged to add more information (use the "comment" function), vote for the issue, or watch it (more on this later).

You will receive an email when you log a new bug or make updates to bugs you've reported. You'll also receive notification when updates are made to bugs you're watching.

You can monitor, or '''watch''' issues reported by others. To do this, open the issue, then select "Watch it" from the left hand navigation panel. To add others to the watchlist for your issue, open the issue, select the option "Watching" from the left hand navigation panel. These people will receive email notification when the issue is updated.

Tracker provides a facility to '''Link''' issues. 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. See [insert section name] for detailed list of link types.

'''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]

===Resolving issues=== (this section should be reviewed)
Issues are resolved in Tracker to show that they've been actioned. Only Moodle core developers and testers are permitted to change the status of bugs in Tracker to "resolved" or "closed".

This is the general process a developer will follow when actioning a Tracker issue:

# Issues are automatically assigned at the time they're created based on component type; they may be reassigned by developers or Component Leads.
# Developers fix, modify or add code and check into CVS. The Tracker issue number is included which automatically links the CVS change to Tracker.
# Patches are attached to Tracker issues so that they may be verified and possibly included in CVS.
# Appropriate comments should be added in Tracker describing the fix. The bug's status is changed to '''Resolved'''.
# The developer should indicate which version of Moodle the change will be included in using the '''Fix Version/s'''. You should use this to indicate which branch(es) you checked the fix into (example below).
# The only exception to not moving a bug to Resolved is if a developer believes there is no value in testing the resolved issue, in which case the bug status can be changed to Closed.

===Testing issues===
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 for 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. Obviously testers should have the skills and knowledge to sufficiently test the issue - experience is important - but don't forget there are others in the Moodle community who may be willing to lend a hand. 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.

Testing a bug in Tracker

NB This is the process members of the moodle-testers group should follow to move bugs from 'resolved' to 'closed'.
*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.

*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.
*All resolved bugs should be tested. Bugs with a resolution code of "fixed" represent bugs where code has been updated, and probably represent more of a challenge than bugs with resoluton codes of duplicate, won't fix, and not a bug, and can't reproduce. Please ensure bugs have been closed with a proper resolution code. Unfortunately it's not easy to change a resolution code in Tracker once the bug has been resolved (the only way is to reopen, then re-resolve).
*Don't be afraid to discuss your testing with the developer assigned to the bug. Simply adding a comment should get the attention of the developer as they are notified of all changes.

==Detailed description of Tracker fields and groups ==
===Tracker fields===
NB A short explanation appears under each field in Tracker.

'''Project''' - Required field. Tracker is made of multiple projects. At present there are 3: 'moodle', 'moodle.org sites' and 'Non-core contributed modules'. 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; specify 'Non-core contributed modules' for issues/bugs related to contributed modules.

'''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. Bugs with serious security implications are restricted so that only members of the moodle-security group can see them.

'''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''' - Required field. This is the Moodle version in which the bug has been found. It is entered by the person logging the bug, and typically only 1 version is specified. Enter your current version when logging an 'improvement', 'task', or 'new feature' as this will help assess the state of the product when the request was made.

'''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 Moodle version the bug was or will be fixed in. This field is normally completed by the developer when the bug has been resolved or by lead developers allocating bugs for a specific release. Normally only one version is specified in this field. It symbolises the ''first'' version of Moodle where the change will be seen.

:More information about setting the Fix Version/s field

:Suppose that the current stable releases are 1.8.3, 1.7.3, 1.6.5 and that 1.9 has branched so we have 1.9 beta+ and 2.0 dev. Suppose you fix a bug on the MOODLE_17_STABLE, MOODLE_18_STABLE, MOODLE_19_STABLE and HEAD. Then mark the bug as fixed in 1.7.4, 1.8.4 and 1.9.

:After Moodle 1.9 has been released, if you fix a bug on the MOODLE_19_STABLE and HEAD branches, mark it as fixed in 1.9.1 and 2.0.

:If you resolved the bug as Cannot reproduce, or Won't fix, etc. Then leave the Fix version blank.

:If you resolve the bug as Duplicate, then create a link to the duplicate issue.

:These Fix version/s are used to automatically build release notes (see the tabs on http://tracker.moodle.org/browse/MDL).

'''Attachment''' - Optional. Attach a file that will help developers and testers better understand the bug. Maximum attachement size is 512Kb.

'''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. Use this resolution code only when actual changes were made to Moodle code.
:''Won't Fix'' - The problem described is an issue which will never be fixed.
:''Not a bug'' - This issue is not a bug; was logged in error. Use this code if the bug was fixed by another bug report or in some earlier Moodle version.
:''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.

=== 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.

'''Moodle Security groups''' [groupname=moodle-security] - Trusted developers and administrators who need to work on and learn about security issues.

NB You can browse a project while not logged in to Tracker, however you will be unable change/edit/comment on bugs.

=== Link types ===
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.

:'''Don't be afraid to link bugs.''' It's very helpful to developers and testers to get a complete picture of a problem.

===Miscellaneous (temporary title)===

*'''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]

==See also==

*[http://www.atlassian.com/software/jira/ Jira] Tracker is a slightly customised version of Atlassian's product
*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]

[[Category:Teacher]]
[[Category:Administrator]]
[[Category:Developer]]
[[Category:Developer tools]]

[[es:Sistema de bugs]]
[[fr:Traqueur de bogues]]

Tracker

2008-03-13T08:08:09Z

Mblake: /* How to write a good Tracker entry */

[[Image:Tracker.jpg]] '''is Moodle's''' [[Image:Issue Tracker MoodleOrg link.JPG]]

Issue tracking is an important part of a continuous quality control process. It involves reporting of problems (bugs), ideas for improvement and new features. Unlike most proprietary software programs, Moodle issue reporting and tracking information is open to everyone. Moodle's issue tracking system is called '''[http://tracker.moodle.org Moodle Tracker]'''. We welcome your requests for new features, improvements, or even constructive criticism of existing features.

The beauty of open source is that anyone can participate and help to create a better product for all of us to enjoy. Please help us by using [http://tracker.moodle.org Moodle Tracker]!

==Basics==
===Logging in to 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.
*If you've forgotten your password, go [http://tracker.moodle.org here] and select 'forgot password' which is just under the 'log in' button. Follow the prompts.

=== Summary: 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.

=== How to write a good Tracker entry===
A good report will include:
*Summary (describe the issue in 1 or 2 sentences)
*Description (a concise yet complete summary of the problem or improvement)
*Steps to Reproduce: A detailed, easy-to-follow sequence of steps a developer can follow to reproduce the problem. If possible, provide a URL so a developer can see the problem with one click.
*Actual Results: What the application did after performing the above steps.
*Expected Results: What the application should have done, were the bug not present. Provide as much detail as possible. Your expectation might mean that help instructions need to be improved or interface changed.

If possible, include additional information that may be helpful to the developer:
*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)
* 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.
* Provide details 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
**Client-side operating system type and version number
**Web browser type and version number

* You don't need to provide 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.

Here are some examples of good bug reports: MDL-6030, MDL-5688, MDL-12505

*A good external reference to help write a tracker entry can be found at [http://developer.mozilla.org/en/docs/Bug_writing_guidelines mozilla bug writing guidelines].

"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.

==Tracker process==
===Logging new issues or improvements===
Anyone with a Tracker account can log issues. See instructions above for writing good quality bug reports. It is important that you search Tracker to determine if your problem or suggestion for improvement has already been reported. If it has you are encouraged to add more information (use the "comment" function), vote for the issue, or watch it (more on this later).

You will receive an email when you log a new bug or make updates to bugs you've reported. You'll also receive notification when updates are made to bugs you're watching.

You can monitor, or '''watch''' issues reported by others. To do this, open the issue, then select "Watch it" from the left hand navigation panel. To add others to the watchlist for your issue, open the issue, select the option "Watching" from the left hand navigation panel. These people will receive email notification when the issue is updated.

Tracker provides a facility to '''Link''' issues. 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. See [insert section name] for detailed list of link types.

'''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]

===Resolving issues=== (this section should be reviewed)
Issues are resolved in Tracker to show that they've been actioned. Only Moodle core developers and testers are permitted to change the status of bugs in Tracker to "resolved" or "closed".

This is the general process a developer will follow when actioning a Tracker issue:

# Issues are automatically assigned at the time they're created based on component type; they may be reassigned by developers or Component Leads.
# Developers fix, modify or add code and check into CVS. The Tracker issue number is included which automatically links the CVS change to Tracker.
# Patches are attached to Tracker issues so that they may be verified and possibly included in CVS.
# Appropriate comments should be added in Tracker describing the fix. The bug's status is changed to '''Resolved'''.
# The developer should indicate which version of Moodle the change will be included in using the '''Fix Version/s'''. You should use this to indicate which branch(es) you checked the fix into (example below).
# The only exception to not moving a bug to Resolved is if a developer believes there is no value in testing the resolved issue, in which case the bug status can be changed to Closed.

===Testing issues===
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 for 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. Obviously testers should have the skills and knowledge to sufficiently test the issue - experience is important - but don't forget there are others in the Moodle community who may be willing to lend a hand. 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.

Testing a bug in Tracker

NB This is the process members of the moodle-testers group should follow to move bugs from 'resolved' to 'closed'.
*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.

*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.
*All resolved bugs should be tested. Bugs with a resolution code of "fixed" represent bugs where code has been updated, and probably represent more of a challenge than bugs with resoluton codes of duplicate, won't fix, and not a bug, and can't reproduce. Please ensure bugs have been closed with a proper resolution code. Unfortunately it's not easy to change a resolution code in Tracker once the bug has been resolved (the only way is to reopen, then re-resolve).
*Don't be afraid to discuss your testing with the developer assigned to the bug. Simply adding a comment should get the attention of the developer as they are notified of all changes.

==Detailed description of Tracker fields and groups ==
===Tracker fields===
NB A short explanation appears under each field in Tracker.

'''Project''' - Required field. Tracker is made of multiple projects. At present there are 3: 'moodle', 'moodle.org sites' and 'Non-core contributed modules'. 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; specify 'Non-core contributed modules' for issues/bugs related to contributed modules.

'''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. Bugs with serious security implications are restricted so that only members of the moodle-security group can see them.

'''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''' - Required field. This is the Moodle version in which the bug has been found. It is entered by the person logging the bug, and typically only 1 version is specified. Enter your current version when logging an 'improvement', 'task', or 'new feature' as this will help assess the state of the product when the request was made.

'''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 Moodle version the bug was or will be fixed in. This field is normally completed by the developer when the bug has been resolved or by lead developers allocating bugs for a specific release. Normally only one version is specified in this field. It symbolises the ''first'' version of Moodle where the change will be seen.

:More information about setting the Fix Version/s field

:Suppose that the current stable releases are 1.8.3, 1.7.3, 1.6.5 and that 1.9 has branched so we have 1.9 beta+ and 2.0 dev. Suppose you fix a bug on the MOODLE_17_STABLE, MOODLE_18_STABLE, MOODLE_19_STABLE and HEAD. Then mark the bug as fixed in 1.7.4, 1.8.4 and 1.9.

:After Moodle 1.9 has been released, if you fix a bug on the MOODLE_19_STABLE and HEAD branches, mark it as fixed in 1.9.1 and 2.0.

:If you resolved the bug as Cannot reproduce, or Won't fix, etc. Then leave the Fix version blank.

:If you resolve the bug as Duplicate, then create a link to the duplicate issue.

:These Fix version/s are used to automatically build release notes (see the tabs on http://tracker.moodle.org/browse/MDL).

'''Attachment''' - Optional. Attach a file that will help developers and testers better understand the bug. Maximum attachement size is 512Kb.

'''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. Use this resolution code only when actual changes were made to Moodle code.
:''Won't Fix'' - The problem described is an issue which will never be fixed.
:''Not a bug'' - This issue is not a bug; was logged in error. Use this code if the bug was fixed by another bug report or in some earlier Moodle version.
:''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.

=== 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.

'''Moodle Security groups''' [groupname=moodle-security] - Trusted developers and administrators who need to work on and learn about security issues.

NB You can browse a project while not logged in to Tracker, however you will be unable change/edit/comment on bugs.

=== Link types ===
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.

:'''Don't be afraid to link bugs.''' It's very helpful to developers and testers to get a complete picture of a problem.

===Miscellaneous (temporary title)===

*'''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]

=== 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==

*[http://www.atlassian.com/software/jira/ Jira] Tracker is a slightly customised version of Atlassian's product
*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]

[[Category:Teacher]]
[[Category:Administrator]]
[[Category:Developer]]
[[Category:Developer tools]]

[[es:Sistema de bugs]]
[[fr:Traqueur de bogues]]

Tracker

2008-03-13T08:03:28Z

Mblake: /* Tracker process */

[[Image:Tracker.jpg]] '''is Moodle's''' [[Image:Issue Tracker MoodleOrg link.JPG]]

Issue tracking is an important part of a continuous quality control process. It involves reporting of problems (bugs), ideas for improvement and new features. Unlike most proprietary software programs, Moodle issue reporting and tracking information is open to everyone. Moodle's issue tracking system is called '''[http://tracker.moodle.org Moodle Tracker]'''. We welcome your requests for new features, improvements, or even constructive criticism of existing features.

The beauty of open source is that anyone can participate and help to create a better product for all of us to enjoy. Please help us by using [http://tracker.moodle.org Moodle Tracker]!

==Basics==
===Logging in to 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.
*If you've forgotten your password, go [http://tracker.moodle.org here] and select 'forgot password' which is just under the 'log in' button. Follow the prompts.

=== Summary: 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.

=== How to write a good Tracker entry===
A good report will include:
*Summary (describe the issue in 1 or 2 sentences)
*Description (a concise yet complete summary of the problem or improvement)
*Steps to Reproduce: A detailed, easy-to-follow sequence of steps a developer can follow to reproduce the problem. If possible, provide a URL so a developer can see the problem with one click.
*Actual Results: What the application did after performing the above steps.
*Expected Results: What the application should have done, were the bug not present. Provide as much detail as possible. Your expectation might mean that help instructions need to be improved or interface changed.

If possible, include additional information that may be helpful to the developer:
*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)
* 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.
* Provide details 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
**Client-side operating system type and version number
**Web browser type and version number

* You don't need to provide 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.

Here are some examples of good bug reports: MDL-6030, MDL-5688, MDL-12505

*A good external reference to help write a tracker entry can be found at [http://developer.mozilla.org/en/docs/Bug_writing_guidelines mozilla bug writing guidelines].

==Tracker process==
===Logging new issues or improvements===
Anyone with a Tracker account can log issues. See instructions above for writing good quality bug reports. It is important that you search Tracker to determine if your problem or suggestion for improvement has already been reported. If it has you are encouraged to add more information (use the "comment" function), vote for the issue, or watch it (more on this later).

You will receive an email when you log a new bug or make updates to bugs you've reported. You'll also receive notification when updates are made to bugs you're watching.

You can monitor, or '''watch''' issues reported by others. To do this, open the issue, then select "Watch it" from the left hand navigation panel. To add others to the watchlist for your issue, open the issue, select the option "Watching" from the left hand navigation panel. These people will receive email notification when the issue is updated.

Tracker provides a facility to '''Link''' issues. 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. See [insert section name] for detailed list of link types.

'''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]

===Resolving issues=== (this section should be reviewed)
Issues are resolved in Tracker to show that they've been actioned. Only Moodle core developers and testers are permitted to change the status of bugs in Tracker to "resolved" or "closed".

This is the general process a developer will follow when actioning a Tracker issue:

# Issues are automatically assigned at the time they're created based on component type; they may be reassigned by developers or Component Leads.
# Developers fix, modify or add code and check into CVS. The Tracker issue number is included which automatically links the CVS change to Tracker.
# Patches are attached to Tracker issues so that they may be verified and possibly included in CVS.
# Appropriate comments should be added in Tracker describing the fix. The bug's status is changed to '''Resolved'''.
# The developer should indicate which version of Moodle the change will be included in using the '''Fix Version/s'''. You should use this to indicate which branch(es) you checked the fix into (example below).
# The only exception to not moving a bug to Resolved is if a developer believes there is no value in testing the resolved issue, in which case the bug status can be changed to Closed.

===Testing issues===
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 for 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. Obviously testers should have the skills and knowledge to sufficiently test the issue - experience is important - but don't forget there are others in the Moodle community who may be willing to lend a hand. 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.

Testing a bug in Tracker

NB This is the process members of the moodle-testers group should follow to move bugs from 'resolved' to 'closed'.
*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.

*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.
*All resolved bugs should be tested. Bugs with a resolution code of "fixed" represent bugs where code has been updated, and probably represent more of a challenge than bugs with resoluton codes of duplicate, won't fix, and not a bug, and can't reproduce. Please ensure bugs have been closed with a proper resolution code. Unfortunately it's not easy to change a resolution code in Tracker once the bug has been resolved (the only way is to reopen, then re-resolve).
*Don't be afraid to discuss your testing with the developer assigned to the bug. Simply adding a comment should get the attention of the developer as they are notified of all changes.

==Detailed description of Tracker fields and groups ==
===Tracker fields===
NB A short explanation appears under each field in Tracker.

'''Project''' - Required field. Tracker is made of multiple projects. At present there are 3: 'moodle', 'moodle.org sites' and 'Non-core contributed modules'. 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; specify 'Non-core contributed modules' for issues/bugs related to contributed modules.

'''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. Bugs with serious security implications are restricted so that only members of the moodle-security group can see them.

'''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''' - Required field. This is the Moodle version in which the bug has been found. It is entered by the person logging the bug, and typically only 1 version is specified. Enter your current version when logging an 'improvement', 'task', or 'new feature' as this will help assess the state of the product when the request was made.

'''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 Moodle version the bug was or will be fixed in. This field is normally completed by the developer when the bug has been resolved or by lead developers allocating bugs for a specific release. Normally only one version is specified in this field. It symbolises the ''first'' version of Moodle where the change will be seen.

:More information about setting the Fix Version/s field

:Suppose that the current stable releases are 1.8.3, 1.7.3, 1.6.5 and that 1.9 has branched so we have 1.9 beta+ and 2.0 dev. Suppose you fix a bug on the MOODLE_17_STABLE, MOODLE_18_STABLE, MOODLE_19_STABLE and HEAD. Then mark the bug as fixed in 1.7.4, 1.8.4 and 1.9.

:After Moodle 1.9 has been released, if you fix a bug on the MOODLE_19_STABLE and HEAD branches, mark it as fixed in 1.9.1 and 2.0.

:If you resolved the bug as Cannot reproduce, or Won't fix, etc. Then leave the Fix version blank.

:If you resolve the bug as Duplicate, then create a link to the duplicate issue.

:These Fix version/s are used to automatically build release notes (see the tabs on http://tracker.moodle.org/browse/MDL).

'''Attachment''' - Optional. Attach a file that will help developers and testers better understand the bug. Maximum attachement size is 512Kb.

'''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. Use this resolution code only when actual changes were made to Moodle code.
:''Won't Fix'' - The problem described is an issue which will never be fixed.
:''Not a bug'' - This issue is not a bug; was logged in error. Use this code if the bug was fixed by another bug report or in some earlier Moodle version.
:''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.

=== 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.

'''Moodle Security groups''' [groupname=moodle-security] - Trusted developers and administrators who need to work on and learn about security issues.

NB You can browse a project while not logged in to Tracker, however you will be unable change/edit/comment on bugs.

=== Link types ===
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.

:'''Don't be afraid to link bugs.''' It's very helpful to developers and testers to get a complete picture of a problem.

===Miscellaneous (temporary title)===

*'''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]

=== 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==

*[http://www.atlassian.com/software/jira/ Jira] Tracker is a slightly customised version of Atlassian's product
*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]

[[Category:Teacher]]
[[Category:Administrator]]
[[Category:Developer]]
[[Category:Developer tools]]

[[es:Sistema de bugs]]
[[fr:Traqueur de bogues]]

Tracker

2008-03-13T07:58:35Z

Mblake: /* More information about setting the Fix Version/s field */

[[Image:Tracker.jpg]] '''is Moodle's''' [[Image:Issue Tracker MoodleOrg link.JPG]]

Issue tracking is an important part of a continuous quality control process. It involves reporting of problems (bugs), ideas for improvement and new features. Unlike most proprietary software programs, Moodle issue reporting and tracking information is open to everyone. Moodle's issue tracking system is called '''[http://tracker.moodle.org Moodle Tracker]'''. We welcome your requests for new features, improvements, or even constructive criticism of existing features.

The beauty of open source is that anyone can participate and help to create a better product for all of us to enjoy. Please help us by using [http://tracker.moodle.org Moodle Tracker]!

==Basics==
===Logging in to 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.
*If you've forgotten your password, go [http://tracker.moodle.org here] and select 'forgot password' which is just under the 'log in' button. Follow the prompts.

=== Summary: 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.

=== How to write a good Tracker entry===
A good report will include:
*Summary (describe the issue in 1 or 2 sentences)
*Description (a concise yet complete summary of the problem or improvement)
*Steps to Reproduce: A detailed, easy-to-follow sequence of steps a developer can follow to reproduce the problem. If possible, provide a URL so a developer can see the problem with one click.
*Actual Results: What the application did after performing the above steps.
*Expected Results: What the application should have done, were the bug not present. Provide as much detail as possible. Your expectation might mean that help instructions need to be improved or interface changed.

If possible, include additional information that may be helpful to the developer:
*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)
* 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.
* Provide details 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
**Client-side operating system type and version number
**Web browser type and version number

* You don't need to provide 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.

Here are some examples of good bug reports: MDL-6030, MDL-5688, MDL-12505

*A good external reference to help write a tracker entry can be found at [http://developer.mozilla.org/en/docs/Bug_writing_guidelines mozilla bug writing guidelines].

==Tracker process==
===Logging new issues or improvements===
Anyone with a Tracker account can log issues. See instructions above for writing good quality bug reports. It is important that you search Tracker to determine if your problem or suggestion for improvement has already been reported. If it has you are encouraged to add more information (use the "comment" function), vote for the issue, or watch it (more on this later).

You will receive an email when you log a new bug or make updates to bugs you've reported. You'll also receive notification when updates are made to bugs you're watching.

You can monitor, or "watch" issues reported by others. To do this, open the issue, then select "Watch it" from the left hand navigation panel. To add others to the watchlist for your issue, open the issue, select the option "Watching" from the left hand navigation panel. These people will receive email notification when the issue is updated.

Tracker provides a facility to '''Link''' issues. 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. See [insert section name] for detailed list of link types:

===Resolving issues=== (this section should be reviewed)
Issues are resolved in Tracker to show that they've been actioned. Only Moodle core developers and testers are permitted to change the status of bugs in Tracker to "resolved" or "closed".

This is the general process a developer will follow when actioning a Tracker issue:

# Issues are automatically assigned at the time they're created based on component type; they may be reassigned by developers or Component Leads.
# Developers fix, modify or add code and check into CVS. The Tracker issue number is included which automatically links the CVS change to Tracker.
# Patches are attached to Tracker issues so that they may be verified and possibly included in CVS.
# Appropriate comments should be added in Tracker describing the fix. The bug's status is changed to '''Resolved'''.
# The developer should indicate which version of Moodle the change will be included in using the '''Fix Version/s'''. You should use this to indicate which branch(es) you checked the fix into (example below).
# The only exception to not moving a bug to Resolved is if a developer believes there is no value in testing the resolved issue, in which case the bug status can be changed to Closed.

===Testing issues===
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 for 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. Obviously testers should have the skills and knowledge to sufficiently test the issue - experience is important - but don't forget there are others in the Moodle community who may be willing to lend a hand. 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.

Testing a bug in Tracker

NB This is the process members of the moodle-testers group should follow to move bugs from 'resolved' to 'closed'.
*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.

*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.
*All resolved bugs should be tested. Bugs with a resolution code of "fixed" represent bugs where code has been updated, and probably represent more of a challenge than bugs with resoluton codes of duplicate, won't fix, and not a bug, and can't reproduce. Please ensure bugs have been closed with a proper resolution code. Unfortunately it's not easy to change a resolution code in Tracker once the bug has been resolved (the only way is to reopen, then re-resolve).
*Don't be afraid to discuss your testing with the developer assigned to the bug. Simply adding a comment should get the attention of the developer as they are notified of all changes.

==Detailed description of Tracker fields and groups ==
===Tracker fields===
NB A short explanation appears under each field in Tracker.

'''Project''' - Required field. Tracker is made of multiple projects. At present there are 3: 'moodle', 'moodle.org sites' and 'Non-core contributed modules'. 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; specify 'Non-core contributed modules' for issues/bugs related to contributed modules.

'''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. Bugs with serious security implications are restricted so that only members of the moodle-security group can see them.

'''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''' - Required field. This is the Moodle version in which the bug has been found. It is entered by the person logging the bug, and typically only 1 version is specified. Enter your current version when logging an 'improvement', 'task', or 'new feature' as this will help assess the state of the product when the request was made.

'''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 Moodle version the bug was or will be fixed in. This field is normally completed by the developer when the bug has been resolved or by lead developers allocating bugs for a specific release. Normally only one version is specified in this field. It symbolises the ''first'' version of Moodle where the change will be seen.

:More information about setting the Fix Version/s field

:Suppose that the current stable releases are 1.8.3, 1.7.3, 1.6.5 and that 1.9 has branched so we have 1.9 beta+ and 2.0 dev. Suppose you fix a bug on the MOODLE_17_STABLE, MOODLE_18_STABLE, MOODLE_19_STABLE and HEAD. Then mark the bug as fixed in 1.7.4, 1.8.4 and 1.9.

:After Moodle 1.9 has been released, if you fix a bug on the MOODLE_19_STABLE and HEAD branches, mark it as fixed in 1.9.1 and 2.0.

:If you resolved the bug as Cannot reproduce, or Won't fix, etc. Then leave the Fix version blank.

:If you resolve the bug as Duplicate, then create a link to the duplicate issue.

:These Fix version/s are used to automatically build release notes (see the tabs on http://tracker.moodle.org/browse/MDL).

'''Attachment''' - Optional. Attach a file that will help developers and testers better understand the bug. Maximum attachement size is 512Kb.

'''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. Use this resolution code only when actual changes were made to Moodle code.
:''Won't Fix'' - The problem described is an issue which will never be fixed.
:''Not a bug'' - This issue is not a bug; was logged in error. Use this code if the bug was fixed by another bug report or in some earlier Moodle version.
:''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.

=== 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.

'''Moodle Security groups''' [groupname=moodle-security] - Trusted developers and administrators who need to work on and learn about security issues.

NB You can browse a project while not logged in to Tracker, however you will be unable change/edit/comment on bugs.

=== Link types ===
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.

:'''Don't be afraid to link bugs.''' It's very helpful to developers and testers to get a complete picture of a problem.

===Miscellaneous (temporary title)===

*'''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]

=== 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==

*[http://www.atlassian.com/software/jira/ Jira] Tracker is a slightly customised version of Atlassian's product
*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]

[[Category:Teacher]]
[[Category:Administrator]]
[[Category:Developer]]
[[Category:Developer tools]]

[[es:Sistema de bugs]]
[[fr:Traqueur de bogues]]

Tracker

2008-03-13T07:57:42Z

Mblake: /* Tracker fields */

[[Image:Tracker.jpg]] '''is Moodle's''' [[Image:Issue Tracker MoodleOrg link.JPG]]

Issue tracking is an important part of a continuous quality control process. It involves reporting of problems (bugs), ideas for improvement and new features. Unlike most proprietary software programs, Moodle issue reporting and tracking information is open to everyone. Moodle's issue tracking system is called '''[http://tracker.moodle.org Moodle Tracker]'''. We welcome your requests for new features, improvements, or even constructive criticism of existing features.

The beauty of open source is that anyone can participate and help to create a better product for all of us to enjoy. Please help us by using [http://tracker.moodle.org Moodle Tracker]!

==Basics==
===Logging in to 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.
*If you've forgotten your password, go [http://tracker.moodle.org here] and select 'forgot password' which is just under the 'log in' button. Follow the prompts.

=== Summary: 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.

=== How to write a good Tracker entry===
A good report will include:
*Summary (describe the issue in 1 or 2 sentences)
*Description (a concise yet complete summary of the problem or improvement)
*Steps to Reproduce: A detailed, easy-to-follow sequence of steps a developer can follow to reproduce the problem. If possible, provide a URL so a developer can see the problem with one click.
*Actual Results: What the application did after performing the above steps.
*Expected Results: What the application should have done, were the bug not present. Provide as much detail as possible. Your expectation might mean that help instructions need to be improved or interface changed.

If possible, include additional information that may be helpful to the developer:
*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)
* 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.
* Provide details 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
**Client-side operating system type and version number
**Web browser type and version number

* You don't need to provide 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.

Here are some examples of good bug reports: MDL-6030, MDL-5688, MDL-12505

*A good external reference to help write a tracker entry can be found at [http://developer.mozilla.org/en/docs/Bug_writing_guidelines mozilla bug writing guidelines].

==Tracker process==
===Logging new issues or improvements===
Anyone with a Tracker account can log issues. See instructions above for writing good quality bug reports. It is important that you search Tracker to determine if your problem or suggestion for improvement has already been reported. If it has you are encouraged to add more information (use the "comment" function), vote for the issue, or watch it (more on this later).

You will receive an email when you log a new bug or make updates to bugs you've reported. You'll also receive notification when updates are made to bugs you're watching.

You can monitor, or "watch" issues reported by others. To do this, open the issue, then select "Watch it" from the left hand navigation panel. To add others to the watchlist for your issue, open the issue, select the option "Watching" from the left hand navigation panel. These people will receive email notification when the issue is updated.

Tracker provides a facility to '''Link''' issues. 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. See [insert section name] for detailed list of link types:

===Resolving issues=== (this section should be reviewed)
Issues are resolved in Tracker to show that they've been actioned. Only Moodle core developers and testers are permitted to change the status of bugs in Tracker to "resolved" or "closed".

This is the general process a developer will follow when actioning a Tracker issue:

# Issues are automatically assigned at the time they're created based on component type; they may be reassigned by developers or Component Leads.
# Developers fix, modify or add code and check into CVS. The Tracker issue number is included which automatically links the CVS change to Tracker.
# Patches are attached to Tracker issues so that they may be verified and possibly included in CVS.
# Appropriate comments should be added in Tracker describing the fix. The bug's status is changed to '''Resolved'''.
# The developer should indicate which version of Moodle the change will be included in using the '''Fix Version/s'''. You should use this to indicate which branch(es) you checked the fix into (example below).
# The only exception to not moving a bug to Resolved is if a developer believes there is no value in testing the resolved issue, in which case the bug status can be changed to Closed.

===Testing issues===
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 for 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. Obviously testers should have the skills and knowledge to sufficiently test the issue - experience is important - but don't forget there are others in the Moodle community who may be willing to lend a hand. 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.

Testing a bug in Tracker

NB This is the process members of the moodle-testers group should follow to move bugs from 'resolved' to 'closed'.
*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.

*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.
*All resolved bugs should be tested. Bugs with a resolution code of "fixed" represent bugs where code has been updated, and probably represent more of a challenge than bugs with resoluton codes of duplicate, won't fix, and not a bug, and can't reproduce. Please ensure bugs have been closed with a proper resolution code. Unfortunately it's not easy to change a resolution code in Tracker once the bug has been resolved (the only way is to reopen, then re-resolve).
*Don't be afraid to discuss your testing with the developer assigned to the bug. Simply adding a comment should get the attention of the developer as they are notified of all changes.

==Detailed description of Tracker fields and groups ==
===Tracker fields===
NB A short explanation appears under each field in Tracker.

'''Project''' - Required field. Tracker is made of multiple projects. At present there are 3: 'moodle', 'moodle.org sites' and 'Non-core contributed modules'. 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; specify 'Non-core contributed modules' for issues/bugs related to contributed modules.

'''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. Bugs with serious security implications are restricted so that only members of the moodle-security group can see them.

'''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''' - Required field. This is the Moodle version in which the bug has been found. It is entered by the person logging the bug, and typically only 1 version is specified. Enter your current version when logging an 'improvement', 'task', or 'new feature' as this will help assess the state of the product when the request was made.

'''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 Moodle version the bug was or will be fixed in. This field is normally completed by the developer when the bug has been resolved or by lead developers allocating bugs for a specific release. Normally only one version is specified in this field. It symbolises the ''first'' version of Moodle where the change will be seen.

:More information about setting the Fix Version/s field

:Suppose that the current stable releases are 1.8.3, 1.7.3, 1.6.5 and that 1.9 has branched so we have 1.9 beta+ and 2.0 dev. Suppose you fix a bug on the MOODLE_17_STABLE, MOODLE_18_STABLE, MOODLE_19_STABLE and HEAD. Then mark the bug as fixed in 1.7.4, 1.8.4 and 1.9.

:After Moodle 1.9 has been released, if you fix a bug on the MOODLE_19_STABLE and HEAD branches, mark it as fixed in 1.9.1 and 2.0.

:If you resolved the bug as Cannot reproduce, or Won't fix, etc. Then leave the Fix version blank.

:If you resolve the bug as Duplicate, then create a link to the duplicate issue.

:These Fix version/s are used to automatically build release notes (see the tabs on http://tracker.moodle.org/browse/MDL).

'''Attachment''' - Optional. Attach a file that will help developers and testers better understand the bug. Maximum attachement size is 512Kb.

'''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. Use this resolution code only when actual changes were made to Moodle code.
:''Won't Fix'' - The problem described is an issue which will never be fixed.
:''Not a bug'' - This issue is not a bug; was logged in error. Use this code if the bug was fixed by another bug report or in some earlier Moodle version.
:''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.

=== 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.

'''Moodle Security groups''' [groupname=moodle-security] - Trusted developers and administrators who need to work on and learn about security issues.

NB You can browse a project while not logged in to Tracker, however you will be unable change/edit/comment on bugs.

=== Link types ===
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.

:'''Don't be afraid to link bugs.''' It's very helpful to developers and testers to get a complete picture of a problem.

====More information about setting the Fix Version/s field====

Suppose that the current stable releases are 1.8.3, 1.7.3, 1.6.5 and that 1.9 has branched so we have 1.9 beta+ and 2.0dev. Suppose you fix a bug on the MOODLE_17_STABLE, MOODLE_18_STABLE, MOODLE_19_STABLE and HEAD. Then mark the bug as fixed in 1.7.4, 1.8.4 and 1.9.

After Moodle 1.9 has been released, if you fix a bug on the MOODLE_19_STABLE and HEAD branches, mark it as fixed in 1.9.1 and 2.0.

If you resolved the bug as Cannot reproduce, or Won't fix, etc. Then leave the Fix version blank.

If you resolve the bug as Duplicate, then create a link to the duplicate issue.

These Fix version/s are used to automatically build release notes (see the tabs on http://tracker.moodle.org/browse/MDL) so it is helpful if you can get this right, but don't lose sleep over it.

The Fix version/s filed can also be used before the issue is fixed, as a way of planning when you intend to fix the bug. In this case, you can use any future release. For example, in the situation above, if you have a bug that you think should be fixed on the 1.9 stable branch, but is not urgent, you could set the fix version to 1.9.2 - then when the bug is actually fixed, update that field as necessary.

===Miscellaneous (temporary title)===

*'''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]

=== 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==

*[http://www.atlassian.com/software/jira/ Jira] Tracker is a slightly customised version of Atlassian's product
*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]

[[Category:Teacher]]
[[Category:Administrator]]
[[Category:Developer]]
[[Category:Developer tools]]

[[es:Sistema de bugs]]
[[fr:Traqueur de bogues]]

Tracker

2008-03-13T07:31:44Z

Mblake: /* Detailed description of Tracker fields and groups */

[[Image:Tracker.jpg]] '''is Moodle's''' [[Image:Issue Tracker MoodleOrg link.JPG]]

Issue tracking is an important part of a continuous quality control process. It involves reporting of problems (bugs), ideas for improvement and new features. Unlike most proprietary software programs, Moodle issue reporting and tracking information is open to everyone. Moodle's issue tracking system is called '''[http://tracker.moodle.org Moodle Tracker]'''. We welcome your requests for new features, improvements, or even constructive criticism of existing features.

The beauty of open source is that anyone can participate and help to create a better product for all of us to enjoy. Please help us by using [http://tracker.moodle.org Moodle Tracker]!

==Basics==
===Logging in to 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.
*If you've forgotten your password, go [http://tracker.moodle.org here] and select 'forgot password' which is just under the 'log in' button. Follow the prompts.

=== Summary: 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.

=== How to write a good Tracker entry===
A good report will include:
*Summary (describe the issue in 1 or 2 sentences)
*Description (a concise yet complete summary of the problem or improvement)
*Steps to Reproduce: A detailed, easy-to-follow sequence of steps a developer can follow to reproduce the problem. If possible, provide a URL so a developer can see the problem with one click.
*Actual Results: What the application did after performing the above steps.
*Expected Results: What the application should have done, were the bug not present. Provide as much detail as possible. Your expectation might mean that help instructions need to be improved or interface changed.

If possible, include additional information that may be helpful to the developer:
*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)
* 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.
* Provide details 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
**Client-side operating system type and version number
**Web browser type and version number

* You don't need to provide 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.

Here are some examples of good bug reports: MDL-6030, MDL-5688, MDL-12505

*A good external reference to help write a tracker entry can be found at [http://developer.mozilla.org/en/docs/Bug_writing_guidelines mozilla bug writing guidelines].

==Tracker process==
===Logging new issues or improvements===
Anyone with a Tracker account can log issues. See instructions above for writing good quality bug reports. It is important that you search Tracker to determine if your problem or suggestion for improvement has already been reported. If it has you are encouraged to add more information (use the "comment" function), vote for the issue, or watch it (more on this later).

You will receive an email when you log a new bug or make updates to bugs you've reported. You'll also receive notification when updates are made to bugs you're watching.

You can monitor, or "watch" issues reported by others. To do this, open the issue, then select "Watch it" from the left hand navigation panel. To add others to the watchlist for your issue, open the issue, select the option "Watching" from the left hand navigation panel. These people will receive email notification when the issue is updated.

Tracker provides a facility to '''Link''' issues. 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. See [insert section name] for detailed list of link types:

===Resolving issues=== (this section should be reviewed)
Issues are resolved in Tracker to show that they've been actioned. Only Moodle core developers and testers are permitted to change the status of bugs in Tracker to "resolved" or "closed".

This is the general process a developer will follow when actioning a Tracker issue:

# Issues are automatically assigned at the time they're created based on component type; they may be reassigned by developers or Component Leads.
# Developers fix, modify or add code and check into CVS. The Tracker issue number is included which automatically links the CVS change to Tracker.
# Patches are attached to Tracker issues so that they may be verified and possibly included in CVS.
# Appropriate comments should be added in Tracker describing the fix. The bug's status is changed to '''Resolved'''.
# The developer should indicate which version of Moodle the change will be included in using the '''Fix Version/s'''. You should use this to indicate which branch(es) you checked the fix into (example below).
# The only exception to not moving a bug to Resolved is if a developer believes there is no value in testing the resolved issue, in which case the bug status can be changed to Closed.

===Testing issues===
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 for 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. Obviously testers should have the skills and knowledge to sufficiently test the issue - experience is important - but don't forget there are others in the Moodle community who may be willing to lend a hand. 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.

Testing a bug in Tracker

NB This is the process members of the moodle-testers group should follow to move bugs from 'resolved' to 'closed'.
*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.

*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.
*All resolved bugs should be tested. Bugs with a resolution code of "fixed" represent bugs where code has been updated, and probably represent more of a challenge than bugs with resoluton codes of duplicate, won't fix, and not a bug, and can't reproduce. Please ensure bugs have been closed with a proper resolution code. Unfortunately it's not easy to change a resolution code in Tracker once the bug has been resolved (the only way is to reopen, then re-resolve).
*Don't be afraid to discuss your testing with the developer assigned to the bug. Simply adding a comment should get the attention of the developer as they are notified of all changes.

==Detailed description of Tracker fields and groups ==
===Tracker fields===
NB A short explanation appears under each field in Tracker.

'''Project''' - Required field. Tracker is made of multiple projects. At present there are 3: 'moodle', 'moodle.org sites' and 'Non-core contributed modules'. 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; specify 'Non-core contributed modules' for issues/bugs related to contributed modules.

'''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. Bugs with serious security implications are restricted so that only members of the moodle-security group can see them.

'''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''' - Required field. This is the Moodle version in which the bug has been found. It is entered by the person logging the bug, and typically only 1 version is specified. Enter your current version when logging an 'improvement', 'task', or 'new feature' as this will help assess the state of the product when the request was made.

'''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 Moodle version the bug was or will be fixed in. This field is normally completed by the developer when the bug has been resolved or by lead developers allocating bugs for a specific release. Normally only one version is specified in this field. It symbolises the ''first'' version of Moodle where the change will be seen.

::More information about setting the Fix Version/s field

::Suppose that the current stable releases are 1.8.3, 1.7.3, 1.6.5 and that 1.9 has branched so we have 1.9 beta+ and 2.0 dev. Suppose you fix a bug on the MOODLE_17_STABLE, MOODLE_18_STABLE, MOODLE_19_STABLE and HEAD. Then mark the bug as fixed in 1.7.4, 1.8.4 and 1.9.

::After Moodle 1.9 has been released, if you fix a bug on the MOODLE_19_STABLE and HEAD branches, mark it as fixed in 1.9.1 and 2.0.

::If you resolved the bug as Cannot reproduce, or Won't fix, etc. Then leave the Fix version blank.

::If you resolve the bug as Duplicate, then create a link to the duplicate issue.

::These Fix version/s are used to automatically build release notes (see the tabs on http://tracker.moodle.org/browse/MDL) so it is helpful if you can get this right, but don't lose sleep over it.

::The Fix version/s field can also be used before the issue is fixed, as a way of grouping issues for upcoming releases.

'''Attachment''' - Optional. Attach a file that will help developers and testers better understand the bug. Maximum attachement size is 512Kb.

'''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. Use this resolution code only when actual changes were made to Moodle code.
:''Won't Fix'' - The problem described is an issue which will never be fixed.
:''Not a bug'' - This issue is not a bug; was logged in error. Use this code if the bug was fixed by another bug report or in some earlier Moodle version.
:''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.

=== 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.

'''Moodle Security groups''' [groupname=moodle-security] - Trusted developers and administrators who need to work on and learn about security issues.

NB You can browse a project while not logged in to Tracker, however you will be unable change/edit/comment on bugs.

=== Link types ===
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.

:'''Don't be afraid to link bugs.''' It's very helpful to developers and testers to get a complete picture of a problem.

====More information about setting the Fix Version/s field====

Suppose that the current stable releases are 1.8.3, 1.7.3, 1.6.5 and that 1.9 has branched so we have 1.9 beta+ and 2.0dev. Suppose you fix a bug on the MOODLE_17_STABLE, MOODLE_18_STABLE, MOODLE_19_STABLE and HEAD. Then mark the bug as fixed in 1.7.4, 1.8.4 and 1.9.

After Moodle 1.9 has been released, if you fix a bug on the MOODLE_19_STABLE and HEAD branches, mark it as fixed in 1.9.1 and 2.0.

If you resolved the bug as Cannot reproduce, or Won't fix, etc. Then leave the Fix version blank.

If you resolve the bug as Duplicate, then create a link to the duplicate issue.

These Fix version/s are used to automatically build release notes (see the tabs on http://tracker.moodle.org/browse/MDL) so it is helpful if you can get this right, but don't lose sleep over it.

The Fix version/s filed can also be used before the issue is fixed, as a way of planning when you intend to fix the bug. In this case, you can use any future release. For example, in the situation above, if you have a bug that you think should be fixed on the 1.9 stable branch, but is not urgent, you could set the fix version to 1.9.2 - then when the bug is actually fixed, update that field as necessary.

===Miscellaneous (temporary title)===

*'''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]

=== 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==

*[http://www.atlassian.com/software/jira/ Jira] Tracker is a slightly customised version of Atlassian's product
*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]

[[Category:Teacher]]
[[Category:Administrator]]
[[Category:Developer]]
[[Category:Developer tools]]

[[es:Sistema de bugs]]
[[fr:Traqueur de bogues]]

Tracker

2008-03-13T07:15:06Z

Mblake: /* Logging new issues or improvements */

[[Image:Tracker.jpg]] '''is Moodle's''' [[Image:Issue Tracker MoodleOrg link.JPG]]

Issue tracking is an important part of a continuous quality control process. It involves reporting of problems (bugs), ideas for improvement and new features. Unlike most proprietary software programs, Moodle issue reporting and tracking information is open to everyone. Moodle's issue tracking system is called '''[http://tracker.moodle.org Moodle Tracker]'''. We welcome your requests for new features, improvements, or even constructive criticism of existing features.

The beauty of open source is that anyone can participate and help to create a better product for all of us to enjoy. Please help us by using [http://tracker.moodle.org Moodle Tracker]!

==Basics==
===Logging in to 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.
*If you've forgotten your password, go [http://tracker.moodle.org here] and select 'forgot password' which is just under the 'log in' button. Follow the prompts.

=== Summary: 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.

=== How to write a good Tracker entry===
A good report will include:
*Summary (describe the issue in 1 or 2 sentences)
*Description (a concise yet complete summary of the problem or improvement)
*Steps to Reproduce: A detailed, easy-to-follow sequence of steps a developer can follow to reproduce the problem. If possible, provide a URL so a developer can see the problem with one click.
*Actual Results: What the application did after performing the above steps.
*Expected Results: What the application should have done, were the bug not present. Provide as much detail as possible. Your expectation might mean that help instructions need to be improved or interface changed.

If possible, include additional information that may be helpful to the developer:
*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)
* 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.
* Provide details 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
**Client-side operating system type and version number
**Web browser type and version number

* You don't need to provide 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.

Here are some examples of good bug reports: MDL-6030, MDL-5688, MDL-12505

*A good external reference to help write a tracker entry can be found at [http://developer.mozilla.org/en/docs/Bug_writing_guidelines mozilla bug writing guidelines].

==Tracker process==
===Logging new issues or improvements===
Anyone with a Tracker account can log issues. See instructions above for writing good quality bug reports. It is important that you search Tracker to determine if your problem or suggestion for improvement has already been reported. If it has you are encouraged to add more information (use the "comment" function), vote for the issue, or watch it (more on this later).

You will receive an email when you log a new bug or make updates to bugs you've reported. You'll also receive notification when updates are made to bugs you're watching.

You can monitor, or "watch" issues reported by others. To do this, open the issue, then select "Watch it" from the left hand navigation panel. To add others to the watchlist for your issue, open the issue, select the option "Watching" from the left hand navigation panel. These people will receive email notification when the issue is updated.

Tracker provides a facility to '''Link''' issues. 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. See [insert section name] for detailed list of link types:

===Resolving issues=== (this section should be reviewed)
Issues are resolved in Tracker to show that they've been actioned. Only Moodle core developers and testers are permitted to change the status of bugs in Tracker to "resolved" or "closed".

This is the general process a developer will follow when actioning a Tracker issue:

# Issues are automatically assigned at the time they're created based on component type; they may be reassigned by developers or Component Leads.
# Developers fix, modify or add code and check into CVS. The Tracker issue number is included which automatically links the CVS change to Tracker.
# Patches are attached to Tracker issues so that they may be verified and possibly included in CVS.
# Appropriate comments should be added in Tracker describing the fix. The bug's status is changed to '''Resolved'''.
# The developer should indicate which version of Moodle the change will be included in using the '''Fix Version/s'''. You should use this to indicate which branch(es) you checked the fix into (example below).
# The only exception to not moving a bug to Resolved is if a developer believes there is no value in testing the resolved issue, in which case the bug status can be changed to Closed.

===Testing issues===
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 for 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. Obviously testers should have the skills and knowledge to sufficiently test the issue - experience is important - but don't forget there are others in the Moodle community who may be willing to lend a hand. 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.

Testing a bug in Tracker

NB This is the process members of the moodle-testers group should follow to move bugs from 'resolved' to 'closed'.
*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.

*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.
*All resolved bugs should be tested. Bugs with a resolution code of "fixed" represent bugs where code has been updated, and probably represent more of a challenge than bugs with resoluton codes of duplicate, won't fix, and not a bug, and can't reproduce. Please ensure bugs have been closed with a proper resolution code. Unfortunately it's not easy to change a resolution code in Tracker once the bug has been resolved (the only way is to reopen, then re-resolve).
*Don't be afraid to discuss your testing with the developer assigned to the bug. Simply adding a comment should get the attention of the developer as they are notified of all changes.

==Detailed description of Tracker fields and groups ==
===Tracker fields===
NB A short explanation appears under each field in Tracker.

'''Project''' - Required field. Tracker is made of multiple projects. At present there are 3: 'moodle', 'moodle.org sites' and 'Non-core contributed modules'. 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; specify 'Non-core contributed modules' for issues/bugs related to contributed modules.

'''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. Bugs with serious security implications are restricted so that only members of the moodle-security group can see them.

'''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''' - Required field. This is the Moodle version in which the bug has been found. It is entered by the person logging the bug, and typically only 1 version is specified. Enter your current version when logging an 'improvement', 'task', or 'new feature' as this will help assess the state of the product when the request was made.

'''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 Moodle version the bug was or will be fixed in. This field is normally completed by the developer when the bug has been resolved or by lead developers allocating bugs for a specific release. Normally only one version is specified in this field. It symbolises the ''first'' version of Moodle where the change will be seen.

'''Attachment''' - Optional. Attach a file that will help developers and testers better understand the bug. Maximum attachement size is 512Kb.

'''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. Use this resolution code only when actual changes were made to Moodle code.
:''Won't Fix'' - The problem described is an issue which will never be fixed.
:''Not a bug'' - This issue is not a bug; was logged in error. Use this code if the bug was fixed by another bug report or in some earlier Moodle version.
:''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.

=== 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.

'''Moodle Security groups''' [groupname=moodle-security] - Trusted developers and administrators who need to work on and learn about security issues.

NB You can browse a project while not logged in to Tracker, however you will be unable change/edit/comment on bugs.

====More information about setting the Fix Version/s field====

Suppose that the current stable releases are 1.8.3, 1.7.3, 1.6.5 and that 1.9 has branched so we have 1.9 beta+ and 2.0dev. Suppose you fix a bug on the MOODLE_17_STABLE, MOODLE_18_STABLE, MOODLE_19_STABLE and HEAD. Then mark the bug as fixed in 1.7.4, 1.8.4 and 1.9.

After Moodle 1.9 has been released, if you fix a bug on the MOODLE_19_STABLE and HEAD branches, mark it as fixed in 1.9.1 and 2.0.

If you resolved the bug as Cannot reproduce, or Won't fix, etc. Then leave the Fix version blank.

If you resolve the bug as Duplicate, then create a link to the duplicate issue.

These Fix version/s are used to automatically build release notes (see the tabs on http://tracker.moodle.org/browse/MDL) so it is helpful if you can get this right, but don't lose sleep over it.

The Fix version/s filed can also be used before the issue is fixed, as a way of planning when you intend to fix the bug. In this case, you can use any future release. For example, in the situation above, if you have a bug that you think should be fixed on the 1.9 stable branch, but is not urgent, you could set the fix version to 1.9.2 - then when the bug is actually fixed, update that field as necessary.

===Miscellaneous (temporary title)===

*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.
*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.

:'''Don't be afraid to link bugs.''' It's very helpful to developers and testers to get a complete picture of a problem.

*'''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]

=== 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==

*[http://www.atlassian.com/software/jira/ Jira] Tracker is a slightly customised version of Atlassian's product
*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]

[[Category:Teacher]]
[[Category:Administrator]]
[[Category:Developer]]
[[Category:Developer tools]]

[[es:Sistema de bugs]]
[[fr:Traqueur de bogues]]

Tracker

2008-03-13T07:05:11Z

Mblake: /* Tracker process */

[[Image:Tracker.jpg]] '''is Moodle's''' [[Image:Issue Tracker MoodleOrg link.JPG]]

Issue tracking is an important part of a continuous quality control process. It involves reporting of problems (bugs), ideas for improvement and new features. Unlike most proprietary software programs, Moodle issue reporting and tracking information is open to everyone. Moodle's issue tracking system is called '''[http://tracker.moodle.org Moodle Tracker]'''. We welcome your requests for new features, improvements, or even constructive criticism of existing features.

The beauty of open source is that anyone can participate and help to create a better product for all of us to enjoy. Please help us by using [http://tracker.moodle.org Moodle Tracker]!

==Basics==
===Logging in to 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.
*If you've forgotten your password, go [http://tracker.moodle.org here] and select 'forgot password' which is just under the 'log in' button. Follow the prompts.

=== Summary: 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.

=== How to write a good Tracker entry===
A good report will include:
*Summary (describe the issue in 1 or 2 sentences)
*Description (a concise yet complete summary of the problem or improvement)
*Steps to Reproduce: A detailed, easy-to-follow sequence of steps a developer can follow to reproduce the problem. If possible, provide a URL so a developer can see the problem with one click.
*Actual Results: What the application did after performing the above steps.
*Expected Results: What the application should have done, were the bug not present. Provide as much detail as possible. Your expectation might mean that help instructions need to be improved or interface changed.

If possible, include additional information that may be helpful to the developer:
*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)
* 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.
* Provide details 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
**Client-side operating system type and version number
**Web browser type and version number

* You don't need to provide 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.

Here are some examples of good bug reports: MDL-6030, MDL-5688, MDL-12505

*A good external reference to help write a tracker entry can be found at [http://developer.mozilla.org/en/docs/Bug_writing_guidelines mozilla bug writing guidelines].

==Tracker process==
===Logging new issues or improvements===
Anyone with a Tracker account can log issues. See instructions above for writing good quality bug reports. It is important that you search Tracker to determine if your problem or suggestion for improvement has already been reported. If it has you are encouraged to add more information (use the "comment" function), vote for the issue, or watch it (more on this later).

You will receive an email when you log a new bug or make updates to bugs you've reported. You'll also receive notification when updates are made to bugs you're watching.

===Resolving issues=== (this section should be reviewed)
Issues are resolved in Tracker to show that they've been actioned. Only Moodle core developers and testers are permitted to change the status of bugs in Tracker to "resolved" or "closed".

This is the general process a developer will follow when actioning a Tracker issue:

# Issues are automatically assigned at the time they're created based on component type; they may be reassigned by developers or Component Leads.
# Developers fix, modify or add code and check into CVS. The Tracker issue number is included which automatically links the CVS change to Tracker.
# Patches are attached to Tracker issues so that they may be verified and possibly included in CVS.
# Appropriate comments should be added in Tracker describing the fix. The bug's status is changed to '''Resolved'''.
# The developer should indicate which version of Moodle the change will be included in using the '''Fix Version/s'''. You should use this to indicate which branch(es) you checked the fix into (example below).
# The only exception to not moving a bug to Resolved is if a developer believes there is no value in testing the resolved issue, in which case the bug status can be changed to Closed.

===Testing issues===
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 for 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. Obviously testers should have the skills and knowledge to sufficiently test the issue - experience is important - but don't forget there are others in the Moodle community who may be willing to lend a hand. 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.

Testing a bug in Tracker

NB This is the process members of the moodle-testers group should follow to move bugs from 'resolved' to 'closed'.
*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.

*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.
*All resolved bugs should be tested. Bugs with a resolution code of "fixed" represent bugs where code has been updated, and probably represent more of a challenge than bugs with resoluton codes of duplicate, won't fix, and not a bug, and can't reproduce. Please ensure bugs have been closed with a proper resolution code. Unfortunately it's not easy to change a resolution code in Tracker once the bug has been resolved (the only way is to reopen, then re-resolve).
*Don't be afraid to discuss your testing with the developer assigned to the bug. Simply adding a comment should get the attention of the developer as they are notified of all changes.

==Detailed description of Tracker fields and groups ==
===Tracker fields===
NB A short explanation appears under each field in Tracker.

'''Project''' - Required field. Tracker is made of multiple projects. At present there are 3: 'moodle', 'moodle.org sites' and 'Non-core contributed modules'. 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; specify 'Non-core contributed modules' for issues/bugs related to contributed modules.

'''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. Bugs with serious security implications are restricted so that only members of the moodle-security group can see them.

'''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''' - Required field. This is the Moodle version in which the bug has been found. It is entered by the person logging the bug, and typically only 1 version is specified. Enter your current version when logging an 'improvement', 'task', or 'new feature' as this will help assess the state of the product when the request was made.

'''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 Moodle version the bug was or will be fixed in. This field is normally completed by the developer when the bug has been resolved or by lead developers allocating bugs for a specific release. Normally only one version is specified in this field. It symbolises the ''first'' version of Moodle where the change will be seen.

'''Attachment''' - Optional. Attach a file that will help developers and testers better understand the bug. Maximum attachement size is 512Kb.

'''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. Use this resolution code only when actual changes were made to Moodle code.
:''Won't Fix'' - The problem described is an issue which will never be fixed.
:''Not a bug'' - This issue is not a bug; was logged in error. Use this code if the bug was fixed by another bug report or in some earlier Moodle version.
:''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.

=== 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.

'''Moodle Security groups''' [groupname=moodle-security] - Trusted developers and administrators who need to work on and learn about security issues.

NB You can browse a project while not logged in to Tracker, however you will be unable change/edit/comment on bugs.

====More information about setting the Fix Version/s field====

Suppose that the current stable releases are 1.8.3, 1.7.3, 1.6.5 and that 1.9 has branched so we have 1.9 beta+ and 2.0dev. Suppose you fix a bug on the MOODLE_17_STABLE, MOODLE_18_STABLE, MOODLE_19_STABLE and HEAD. Then mark the bug as fixed in 1.7.4, 1.8.4 and 1.9.

After Moodle 1.9 has been released, if you fix a bug on the MOODLE_19_STABLE and HEAD branches, mark it as fixed in 1.9.1 and 2.0.

If you resolved the bug as Cannot reproduce, or Won't fix, etc. Then leave the Fix version blank.

If you resolve the bug as Duplicate, then create a link to the duplicate issue.

These Fix version/s are used to automatically build release notes (see the tabs on http://tracker.moodle.org/browse/MDL) so it is helpful if you can get this right, but don't lose sleep over it.

The Fix version/s filed can also be used before the issue is fixed, as a way of planning when you intend to fix the bug. In this case, you can use any future release. For example, in the situation above, if you have a bug that you think should be fixed on the 1.9 stable branch, but is not urgent, you could set the fix version to 1.9.2 - then when the bug is actually fixed, update that field as necessary.

===Miscellaneous (temporary title)===

*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.
*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.

:'''Don't be afraid to link bugs.''' It's very helpful to developers and testers to get a complete picture of a problem.

*'''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]

=== 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==

*[http://www.atlassian.com/software/jira/ Jira] Tracker is a slightly customised version of Atlassian's product
*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]

[[Category:Teacher]]
[[Category:Administrator]]
[[Category:Developer]]
[[Category:Developer tools]]

[[es:Sistema de bugs]]
[[fr:Traqueur de bogues]]

Tracker

2008-03-13T06:51:21Z

Mblake: /* Resolving issues in Tracker */

[[Image:Tracker.jpg]] '''is Moodle's''' [[Image:Issue Tracker MoodleOrg link.JPG]]

Issue tracking is an important part of a continuous quality control process. It involves reporting of problems (bugs), ideas for improvement and new features. Unlike most proprietary software programs, Moodle issue reporting and tracking information is open to everyone. Moodle's issue tracking system is called '''[http://tracker.moodle.org Moodle Tracker]'''. We welcome your requests for new features, improvements, or even constructive criticism of existing features.

The beauty of open source is that anyone can participate and help to create a better product for all of us to enjoy. Please help us by using [http://tracker.moodle.org Moodle Tracker]!

==Basics==
===Logging in to 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.
*If you've forgotten your password, go [http://tracker.moodle.org here] and select 'forgot password' which is just under the 'log in' button. Follow the prompts.

=== Summary: 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.

=== How to write a good Tracker entry===
A good report will include:
*Summary (describe the issue in 1 or 2 sentences)
*Description (a concise yet complete summary of the problem or improvement)
*Steps to Reproduce: A detailed, easy-to-follow sequence of steps a developer can follow to reproduce the problem. If possible, provide a URL so a developer can see the problem with one click.
*Actual Results: What the application did after performing the above steps.
*Expected Results: What the application should have done, were the bug not present. Provide as much detail as possible. Your expectation might mean that help instructions need to be improved or interface changed.

If possible, include additional information that may be helpful to the developer:
*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)
* 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.
* Provide details 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
**Client-side operating system type and version number
**Web browser type and version number

* You don't need to provide 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.

Here are some examples of good bug reports: MDL-6030, MDL-5688, MDL-12505

*A good external reference to help write a tracker entry can be found at [http://developer.mozilla.org/en/docs/Bug_writing_guidelines mozilla bug writing guidelines].

==Tracker process==
===Logging new issues or improvements===
Anyone with a Tracker account can log issues. See instructions above for writing good quality bug reports. It is important that you search Tracker to determine if your problem or suggestion for improvement has already been reported. If it has you are encouraged to add more information (use the "comment" function), vote for the issue, or watch it (more on this later).

You will receive an email when you log a new bug or make updates to bugs you've reported. You'll also receive notification when updates are made to bugs you're watching.

===Resolving issues in Tracker=== (this section should be reviewed)
Issues are resolved in Tracker to show that they've been actioned. Only Moodle core developers and testers are permitted to change the status of bugs in Tracker to "resolved" or "closed".

This is the general process a developer will follow when actioning a Tracker issue:

# Issues are automatically assigned at the time they're created based on component type; they may be reassigned by developers or Component Leads.
# Developers fix, modify or add code and check into CVS. The Tracker issue number is included which automatically links the CVS change to Tracker.
# Patches are attached to Tracker issues so that they may be verified and possibly included in CVS.
# Appropriate comments should be added in Tracker describing the fix. The bug's status is changed to '''Resolved'''.
# The developer should indicate which version of Moodle the change will be included in using the '''Fix Version/s'''. You should use this to indicate which branch(es) you checked the fix into (example below).
# The only exception to not moving a bug to Resolved is if a developer believes there is no value in testing the resolved issue, in which case the bug status can be changed to Closed.

=== 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.

'''Moodle Security groups''' [groupname=moodle-security] - Trusted developers and administrators who need to work on and learn about security issues.

NB You can browse a project while not logged in to Tracker, however you will be unable change/edit/comment on bugs.
===Tracker fields===
NB A short explanation appears under each field in Tracker.

'''Project''' - Required field. Tracker is made of multiple projects. At present there are 3: 'moodle', 'moodle.org sites' and 'Non-core contributed modules'. 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; specify 'Non-core contributed modules' for issues/bugs related to contributed modules.

'''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. Bugs with serious security implications are restricted so that only members of the moodle-security group can see them.

'''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''' - Required field. This is the Moodle version in which the bug has been found. It is entered by the person logging the bug, and typically only 1 version is specified. Enter your current version when logging an 'improvement', 'task', or 'new feature' as this will help assess the state of the product when the request was made.

'''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 Moodle version the bug was or will be fixed in. This field is normally completed by the developer when the bug has been resolved or by lead developers allocating bugs for a specific release. Normally only one version is specified in this field. It symbolises the ''first'' version of Moodle where the change will be seen.

'''Attachment''' - Optional. Attach a file that will help developers and testers better understand the bug. Maximum attachement size is 512Kb.

'''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. Use this resolution code only when actual changes were made to Moodle code.
:''Won't Fix'' - The problem described is an issue which will never be fixed.
:''Not a bug'' - This issue is not a bug; was logged in error. Use this code if the bug was fixed by another bug report or in some earlier Moodle version.
:''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 information about setting the Fix Version/s field====

Suppose that the current stable releases are 1.8.3, 1.7.3, 1.6.5 and that 1.9 has branched so we have 1.9 beta+ and 2.0dev. Suppose you fix a bug on the MOODLE_17_STABLE, MOODLE_18_STABLE, MOODLE_19_STABLE and HEAD. Then mark the bug as fixed in 1.7.4, 1.8.4 and 1.9.

After Moodle 1.9 has been released, if you fix a bug on the MOODLE_19_STABLE and HEAD branches, mark it as fixed in 1.9.1 and 2.0.

If you resolved the bug as Cannot reproduce, or Won't fix, etc. Then leave the Fix version blank.

If you resolve the bug as Duplicate, then create a link to the duplicate issue.

These Fix version/s are used to automatically build release notes (see the tabs on http://tracker.moodle.org/browse/MDL) so it is helpful if you can get this right, but don't lose sleep over it.

The Fix version/s filed can also be used before the issue is fixed, as a way of planning when you intend to fix the bug. In this case, you can use any future release. For example, in the situation above, if you have a bug that you think should be fixed on the 1.9 stable branch, but is not urgent, you could set the fix version to 1.9.2 - then when the bug is actually fixed, update that field as necessary.

===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 for 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. Obviously testers should have the skills and knowledge to sufficiently test the issue - experience is important - but don't forget there are others in the Moodle community who may be willing to lend a hand. 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.

Testing a bug in Tracker

NB This is the process members of the moodle-testers group should follow to move bugs from 'resolved' to 'closed'.
*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.

*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.
*All resolved bugs should be tested. Bugs with a resolution code of "fixed" represent bugs where code has been updated, and probably represent more of a challenge than bugs with resoluton codes of duplicate, won't fix, and not a bug, and can't reproduce. Please ensure bugs have been closed with a proper resolution code. Unfortunately it's not easy to change a resolution code in Tracker once the bug has been resolved (the only way is to reopen, then re-resolve).
*Don't be afraid to discuss your testing with the developer assigned to the bug. Simply adding a comment should get the attention of the developer as they are notified of all changes.

===Miscellaneous (temporary title)===

*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.
*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.

:'''Don't be afraid to link bugs.''' It's very helpful to developers and testers to get a complete picture of a problem.

*'''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]

=== 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==

*[http://www.atlassian.com/software/jira/ Jira] Tracker is a slightly customised version of Atlassian's product
*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]

[[Category:Teacher]]
[[Category:Administrator]]
[[Category:Developer]]
[[Category:Developer tools]]

[[es:Sistema de bugs]]
[[fr:Traqueur de bogues]]

Tracker

2008-03-12T08:27:22Z

Mblake: /* Tracker process */

[[Image:Tracker.jpg]] '''is Moodle's''' [[Image:Issue Tracker MoodleOrg link.JPG]]

Issue tracking is an important part of a continuous quality control process. It involves reporting of problems (bugs), ideas for improvement and new features. Unlike most proprietary software programs, Moodle issue reporting and tracking information is open to everyone. Moodle's issue tracking system is called '''[http://tracker.moodle.org Moodle Tracker]'''. We welcome your requests for new features, improvements, or even constructive criticism of existing features.

The beauty of open source is that anyone can participate and help to create a better product for all of us to enjoy. Please help us by using [http://tracker.moodle.org Moodle Tracker]!

==Basics==
===Logging in to 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.
*If you've forgotten your password, go [http://tracker.moodle.org here] and select 'forgot password' which is just under the 'log in' button. Follow the prompts.

=== Summary: 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.

=== How to write a good Tracker entry===
A good report will include:
*Summary (describe the issue in 1 or 2 sentences)
*Description (a concise yet complete summary of the problem or improvement)
*Steps to Reproduce: A detailed, easy-to-follow sequence of steps a developer can follow to reproduce the problem. If possible, provide a URL so a developer can see the problem with one click.
*Actual Results: What the application did after performing the above steps.
*Expected Results: What the application should have done, were the bug not present. Provide as much detail as possible. Your expectation might mean that help instructions need to be improved or interface changed.

If possible, include additional information that may be helpful to the developer:
*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)
* 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.
* Provide details 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
**Client-side operating system type and version number
**Web browser type and version number

* You don't need to provide 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.

Here are some examples of good bug reports: MDL-6030, MDL-5688, MDL-12505

*A good external reference to help write a tracker entry can be found at [http://developer.mozilla.org/en/docs/Bug_writing_guidelines mozilla bug writing guidelines].

==Tracker process==
===Logging new issues or improvements===
Anyone with a Tracker account can log issues. See instructions above for writing good quality bug reports. It is important that you search Tracker to determine if your problem or suggestion for improvement has already been reported. If it has you are encouraged to add more information (use the "comment" function), vote for the issue, or watch it (more on this later).

You will receive an email when you log a new bug or make updates to bugs you've reported. You'll also receive notification when updates are made to bugs you're watching.

===Resolving issues in Tracker===
Issues are resolved in Tracker to show that they've been actioned. 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 which version of Moodle the change will be included in using the '''Fix Version/s'''. You should use this to indicate which branch(es) you checked the fix into (example below).
* 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.

=== 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.

'''Moodle Security groups''' [groupname=moodle-security] - Trusted developers and administrators who need to work on and learn about security issues.

NB You can browse a project while not logged in to Tracker, however you will be unable change/edit/comment on bugs.
===Tracker fields===
NB A short explanation appears under each field in Tracker.

'''Project''' - Required field. Tracker is made of multiple projects. At present there are 3: 'moodle', 'moodle.org sites' and 'Non-core contributed modules'. 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; specify 'Non-core contributed modules' for issues/bugs related to contributed modules.

'''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. Bugs with serious security implications are restricted so that only members of the moodle-security group can see them.

'''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''' - Required field. This is the Moodle version in which the bug has been found. It is entered by the person logging the bug, and typically only 1 version is specified. Enter your current version when logging an 'improvement', 'task', or 'new feature' as this will help assess the state of the product when the request was made.

'''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 Moodle version the bug was or will be fixed in. This field is normally completed by the developer when the bug has been resolved or by lead developers allocating bugs for a specific release. Normally only one version is specified in this field. It symbolises the ''first'' version of Moodle where the change will be seen.

'''Attachment''' - Optional. Attach a file that will help developers and testers better understand the bug. Maximum attachement size is 512Kb.

'''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. Use this resolution code only when actual changes were made to Moodle code.
:''Won't Fix'' - The problem described is an issue which will never be fixed.
:''Not a bug'' - This issue is not a bug; was logged in error. Use this code if the bug was fixed by another bug report or in some earlier Moodle version.
:''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 information about setting the Fix Version/s field====

Suppose that the current stable releases are 1.8.3, 1.7.3, 1.6.5 and that 1.9 has branched so we have 1.9 beta+ and 2.0dev. Suppose you fix a bug on the MOODLE_17_STABLE, MOODLE_18_STABLE, MOODLE_19_STABLE and HEAD. Then mark the bug as fixed in 1.7.4, 1.8.4 and 1.9.

After Moodle 1.9 has been released, if you fix a bug on the MOODLE_19_STABLE and HEAD branches, mark it as fixed in 1.9.1 and 2.0.

If you resolved the bug as Cannot reproduce, or Won't fix, etc. Then leave the Fix version blank.

If you resolve the bug as Duplicate, then create a link to the duplicate issue.

These Fix version/s are used to automatically build release notes (see the tabs on http://tracker.moodle.org/browse/MDL) so it is helpful if you can get this right, but don't lose sleep over it.

The Fix version/s filed can also be used before the issue is fixed, as a way of planning when you intend to fix the bug. In this case, you can use any future release. For example, in the situation above, if you have a bug that you think should be fixed on the 1.9 stable branch, but is not urgent, you could set the fix version to 1.9.2 - then when the bug is actually fixed, update that field as necessary.

===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 for 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. Obviously testers should have the skills and knowledge to sufficiently test the issue - experience is important - but don't forget there are others in the Moodle community who may be willing to lend a hand. 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.

Testing a bug in Tracker

NB This is the process members of the moodle-testers group should follow to move bugs from 'resolved' to 'closed'.
*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.

*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.
*All resolved bugs should be tested. Bugs with a resolution code of "fixed" represent bugs where code has been updated, and probably represent more of a challenge than bugs with resoluton codes of duplicate, won't fix, and not a bug, and can't reproduce. Please ensure bugs have been closed with a proper resolution code. Unfortunately it's not easy to change a resolution code in Tracker once the bug has been resolved (the only way is to reopen, then re-resolve).
*Don't be afraid to discuss your testing with the developer assigned to the bug. Simply adding a comment should get the attention of the developer as they are notified of all changes.

===Miscellaneous (temporary title)===

*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.
*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.

:'''Don't be afraid to link bugs.''' It's very helpful to developers and testers to get a complete picture of a problem.

*'''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]

=== 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==

*[http://www.atlassian.com/software/jira/ Jira] Tracker is a slightly customised version of Atlassian's product
*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]

[[Category:Teacher]]
[[Category:Administrator]]
[[Category:Developer]]
[[Category:Developer tools]]

[[es:Sistema de bugs]]
[[fr:Traqueur de bogues]]

Tracker

2008-03-12T08:13:08Z

Mblake: /* Tracker entry best practices */

[[Image:Tracker.jpg]] '''is Moodle's''' [[Image:Issue Tracker MoodleOrg link.JPG]]

Issue tracking is an important part of a continuous quality control process. It involves reporting of problems (bugs), ideas for improvement and new features. Unlike most proprietary software programs, Moodle issue reporting and tracking information is open to everyone. Moodle's issue tracking system is called '''[http://tracker.moodle.org Moodle Tracker]'''. We welcome your requests for new features, improvements, or even constructive criticism of existing features.

The beauty of open source is that anyone can participate and help to create a better product for all of us to enjoy. Please help us by using [http://tracker.moodle.org Moodle Tracker]!

==Basics==
===Logging in to 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.
*If you've forgotten your password, go [http://tracker.moodle.org here] and select 'forgot password' which is just under the 'log in' button. Follow the prompts.

=== Summary: 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.

=== How to write a good Tracker entry===
A good report will include:
*Summary (describe the issue in 1 or 2 sentences)
*Description (a concise yet complete summary of the problem or improvement)
*Steps to Reproduce: A detailed, easy-to-follow sequence of steps a developer can follow to reproduce the problem. If possible, provide a URL so a developer can see the problem with one click.
*Actual Results: What the application did after performing the above steps.
*Expected Results: What the application should have done, were the bug not present. Provide as much detail as possible. Your expectation might mean that help instructions need to be improved or interface changed.

If possible, include additional information that may be helpful to the developer:
*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)
* 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.
* Provide details 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
**Client-side operating system type and version number
**Web browser type and version number

* You don't need to provide 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.

Here are some examples of good bug reports: MDL-6030, MDL-5688, MDL-12505

*A good external reference to help write a tracker entry can be found at [http://developer.mozilla.org/en/docs/Bug_writing_guidelines mozilla bug writing guidelines].

==Tracker process==
===Resolving bugs in Tracker===
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 which version of Moodle the change will be included in using the '''Fix Version/s'''. You should use this to indicate which branch(es) you checked the fix into (example below).
* 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.

=== 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.

'''Moodle Security groups''' [groupname=moodle-security] - Trusted developers and administrators who need to work on and learn about security issues.

NB You can browse a project while not logged in to Tracker, however you will be unable change/edit/comment on bugs.
===Tracker fields===
NB A short explanation appears under each field in Tracker.

'''Project''' - Required field. Tracker is made of multiple projects. At present there are 3: 'moodle', 'moodle.org sites' and 'Non-core contributed modules'. 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; specify 'Non-core contributed modules' for issues/bugs related to contributed modules.

'''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. Bugs with serious security implications are restricted so that only members of the moodle-security group can see them.

'''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''' - Required field. This is the Moodle version in which the bug has been found. It is entered by the person logging the bug, and typically only 1 version is specified. Enter your current version when logging an 'improvement', 'task', or 'new feature' as this will help assess the state of the product when the request was made.

'''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 Moodle version the bug was or will be fixed in. This field is normally completed by the developer when the bug has been resolved or by lead developers allocating bugs for a specific release. Normally only one version is specified in this field. It symbolises the ''first'' version of Moodle where the change will be seen.

'''Attachment''' - Optional. Attach a file that will help developers and testers better understand the bug. Maximum attachement size is 512Kb.

'''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. Use this resolution code only when actual changes were made to Moodle code.
:''Won't Fix'' - The problem described is an issue which will never be fixed.
:''Not a bug'' - This issue is not a bug; was logged in error. Use this code if the bug was fixed by another bug report or in some earlier Moodle version.
:''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 information about setting the Fix Version/s field====

Suppose that the current stable releases are 1.8.3, 1.7.3, 1.6.5 and that 1.9 has branched so we have 1.9 beta+ and 2.0dev. Suppose you fix a bug on the MOODLE_17_STABLE, MOODLE_18_STABLE, MOODLE_19_STABLE and HEAD. Then mark the bug as fixed in 1.7.4, 1.8.4 and 1.9.

After Moodle 1.9 has been released, if you fix a bug on the MOODLE_19_STABLE and HEAD branches, mark it as fixed in 1.9.1 and 2.0.

If you resolved the bug as Cannot reproduce, or Won't fix, etc. Then leave the Fix version blank.

If you resolve the bug as Duplicate, then create a link to the duplicate issue.

These Fix version/s are used to automatically build release notes (see the tabs on http://tracker.moodle.org/browse/MDL) so it is helpful if you can get this right, but don't lose sleep over it.

The Fix version/s filed can also be used before the issue is fixed, as a way of planning when you intend to fix the bug. In this case, you can use any future release. For example, in the situation above, if you have a bug that you think should be fixed on the 1.9 stable branch, but is not urgent, you could set the fix version to 1.9.2 - then when the bug is actually fixed, update that field as necessary.

===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 for 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. Obviously testers should have the skills and knowledge to sufficiently test the issue - experience is important - but don't forget there are others in the Moodle community who may be willing to lend a hand. 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.

Testing a bug in Tracker

NB This is the process members of the moodle-testers group should follow to move bugs from 'resolved' to 'closed'.
*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.

*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.
*All resolved bugs should be tested. Bugs with a resolution code of "fixed" represent bugs where code has been updated, and probably represent more of a challenge than bugs with resoluton codes of duplicate, won't fix, and not a bug, and can't reproduce. Please ensure bugs have been closed with a proper resolution code. Unfortunately it's not easy to change a resolution code in Tracker once the bug has been resolved (the only way is to reopen, then re-resolve).
*Don't be afraid to discuss your testing with the developer assigned to the bug. Simply adding a comment should get the attention of the developer as they are notified of all changes.

===More about the Tracker process===
*You will receive an email when you log a new bug or make updates to bugs you've reported. You'll also receive notification when updates are made to bugs you're watching. Read on for more information on watching a bug.
*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.
*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.

:'''Don't be afraid to link bugs.''' It's very helpful to developers and testers to get a complete picture of a problem.

*'''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]

=== 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==

*[http://www.atlassian.com/software/jira/ Jira] Tracker is a slightly customised version of Atlassian's product
*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]

[[Category:Teacher]]
[[Category:Administrator]]
[[Category:Developer]]
[[Category:Developer tools]]

[[es:Sistema de bugs]]
[[fr:Traqueur de bogues]]

Tracker

2008-03-12T08:11:59Z

Mblake: /* How to write a good Tracker entry */

[[Image:Tracker.jpg]] '''is Moodle's''' [[Image:Issue Tracker MoodleOrg link.JPG]]

Issue tracking is an important part of a continuous quality control process. It involves reporting of problems (bugs), ideas for improvement and new features. Unlike most proprietary software programs, Moodle issue reporting and tracking information is open to everyone. Moodle's issue tracking system is called '''[http://tracker.moodle.org Moodle Tracker]'''. We welcome your requests for new features, improvements, or even constructive criticism of existing features.

The beauty of open source is that anyone can participate and help to create a better product for all of us to enjoy. Please help us by using [http://tracker.moodle.org Moodle Tracker]!

==Basics==
===Logging in to 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.
*If you've forgotten your password, go [http://tracker.moodle.org here] and select 'forgot password' which is just under the 'log in' button. Follow the prompts.

=== Summary: 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.

=== How to write a good Tracker entry===
A good report will include:
*Summary (describe the issue in 1 or 2 sentences)
*Description (a concise yet complete summary of the problem or improvement)
*Steps to Reproduce: A detailed, easy-to-follow sequence of steps a developer can follow to reproduce the problem. If possible, provide a URL so a developer can see the problem with one click.
*Actual Results: What the application did after performing the above steps.
*Expected Results: What the application should have done, were the bug not present. Provide as much detail as possible. Your expectation might mean that help instructions need to be improved or interface changed.

If possible, include additional information that may be helpful to the developer:
*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)
* 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.
* Provide details 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
**Client-side operating system type and version number
**Web browser type and version number

* You don't need to provide 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.

Here are some examples of good bug reports: MDL-6030, MDL-5688, MDL-12505

*A good external reference to help write a tracker entry can be found at [http://developer.mozilla.org/en/docs/Bug_writing_guidelines mozilla bug writing guidelines].

==Tracker process==
===Resolving bugs in Tracker===
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 which version of Moodle the change will be included in using the '''Fix Version/s'''. You should use this to indicate which branch(es) you checked the fix into (example below).
* 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.

=== 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.

'''Moodle Security groups''' [groupname=moodle-security] - Trusted developers and administrators who need to work on and learn about security issues.

NB You can browse a project while not logged in to Tracker, however you will be unable change/edit/comment on bugs.
===Tracker fields===
NB A short explanation appears under each field in Tracker.

'''Project''' - Required field. Tracker is made of multiple projects. At present there are 3: 'moodle', 'moodle.org sites' and 'Non-core contributed modules'. 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; specify 'Non-core contributed modules' for issues/bugs related to contributed modules.

'''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. Bugs with serious security implications are restricted so that only members of the moodle-security group can see them.

'''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''' - Required field. This is the Moodle version in which the bug has been found. It is entered by the person logging the bug, and typically only 1 version is specified. Enter your current version when logging an 'improvement', 'task', or 'new feature' as this will help assess the state of the product when the request was made.

'''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 Moodle version the bug was or will be fixed in. This field is normally completed by the developer when the bug has been resolved or by lead developers allocating bugs for a specific release. Normally only one version is specified in this field. It symbolises the ''first'' version of Moodle where the change will be seen.

'''Attachment''' - Optional. Attach a file that will help developers and testers better understand the bug. Maximum attachement size is 512Kb.

'''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. Use this resolution code only when actual changes were made to Moodle code.
:''Won't Fix'' - The problem described is an issue which will never be fixed.
:''Not a bug'' - This issue is not a bug; was logged in error. Use this code if the bug was fixed by another bug report or in some earlier Moodle version.
:''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 information about setting the Fix Version/s field====

Suppose that the current stable releases are 1.8.3, 1.7.3, 1.6.5 and that 1.9 has branched so we have 1.9 beta+ and 2.0dev. Suppose you fix a bug on the MOODLE_17_STABLE, MOODLE_18_STABLE, MOODLE_19_STABLE and HEAD. Then mark the bug as fixed in 1.7.4, 1.8.4 and 1.9.

After Moodle 1.9 has been released, if you fix a bug on the MOODLE_19_STABLE and HEAD branches, mark it as fixed in 1.9.1 and 2.0.

If you resolved the bug as Cannot reproduce, or Won't fix, etc. Then leave the Fix version blank.

If you resolve the bug as Duplicate, then create a link to the duplicate issue.

These Fix version/s are used to automatically build release notes (see the tabs on http://tracker.moodle.org/browse/MDL) so it is helpful if you can get this right, but don't lose sleep over it.

The Fix version/s filed can also be used before the issue is fixed, as a way of planning when you intend to fix the bug. In this case, you can use any future release. For example, in the situation above, if you have a bug that you think should be fixed on the 1.9 stable branch, but is not urgent, you could set the fix version to 1.9.2 - then when the bug is actually fixed, update that field as necessary.

===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 for 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. Obviously testers should have the skills and knowledge to sufficiently test the issue - experience is important - but don't forget there are others in the Moodle community who may be willing to lend a hand. 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.

Testing a bug in Tracker

NB This is the process members of the moodle-testers group should follow to move bugs from 'resolved' to 'closed'.
*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.

*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.
*All resolved bugs should be tested. Bugs with a resolution code of "fixed" represent bugs where code has been updated, and probably represent more of a challenge than bugs with resoluton codes of duplicate, won't fix, and not a bug, and can't reproduce. Please ensure bugs have been closed with a proper resolution code. Unfortunately it's not easy to change a resolution code in Tracker once the bug has been resolved (the only way is to reopen, then re-resolve).
*Don't be afraid to discuss your testing with the developer assigned to the bug. Simply adding a comment should get the attention of the developer as they are notified of all changes.

===More about the Tracker process===
*You will receive an email when you log a new bug or make updates to bugs you've reported. You'll also receive notification when updates are made to bugs you're watching. Read on for more information on watching a bug.
*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.
*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.

:'''Don't be afraid to link bugs.''' It's very helpful to developers and testers to get a complete picture of a problem.

*'''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 entry best practices ==

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 are some examples of good bug reports: MDL-6030, MDL-5688, MDL-12505

*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.

=== 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==

*[http://www.atlassian.com/software/jira/ Jira] Tracker is a slightly customised version of Atlassian's product
*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]

[[Category:Teacher]]
[[Category:Administrator]]
[[Category:Developer]]
[[Category:Developer tools]]

[[es:Sistema de bugs]]
[[fr:Traqueur de bogues]]

Tracker

2008-03-12T07:49:30Z

Mblake: /* How to write a good tracker entry */

[[Image:Tracker.jpg]] '''is Moodle's''' [[Image:Issue Tracker MoodleOrg link.JPG]]

Issue tracking is an important part of a continuous quality control process. It involves reporting of problems (bugs), ideas for improvement and new features. Unlike most proprietary software programs, Moodle issue reporting and tracking information is open to everyone. Moodle's issue tracking system is called '''[http://tracker.moodle.org Moodle Tracker]'''. We welcome your requests for new features, improvements, or even constructive criticism of existing features.

The beauty of open source is that anyone can participate and help to create a better product for all of us to enjoy. Please help us by using [http://tracker.moodle.org Moodle Tracker]!

==Basics==
===Logging in to 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.
*If you've forgotten your password, go [http://tracker.moodle.org here] and select 'forgot password' which is just under the 'log in' button. Follow the prompts.

=== Summary: 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.

=== How to write a good tracker entry===
**A good report will include:
** Summary (How would you describe the bug, in approximately 60 or fewer characters?)
** Description (The details of your problem report), including
*** Overview: More detailed restatement of summary.
*** Steps to Reproduce: A detailed, easy-to-follow sequence of steps a developer can follow to reproduce the problem. If possible, provide a URL so a developer can see the problem with one click.
*** Actual Results: What the application did after performing the above steps.
*** Expected Results: What the application should have done, were the bug not present. Provide as much detail as possible. Your expectation might mean that help instructions need to be improved or interface changed.

Here are some examples of good bug reports: MDL-6030, MDL-5688, MDL-12505

*A good external reference to help write a tracker entry can be found at [http://developer.mozilla.org/en/docs/Bug_writing_guidelines mozilla bug writing guidelines].

If possible, include additional information that may be helpful to the developer:

* 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:
o Server operating system type and version number
o Web server type and version number
o PHP version number (and whether you are using an accelerator)
o Database type and version number
o 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)
o Client-side operating system type and version number
o Web browser type and version number

* You don't need to provide 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.

==Tracker process==
===Resolving bugs in Tracker===
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 which version of Moodle the change will be included in using the '''Fix Version/s'''. You should use this to indicate which branch(es) you checked the fix into (example below).
* 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.

=== 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.

'''Moodle Security groups''' [groupname=moodle-security] - Trusted developers and administrators who need to work on and learn about security issues.

NB You can browse a project while not logged in to Tracker, however you will be unable change/edit/comment on bugs.
===Tracker fields===
NB A short explanation appears under each field in Tracker.

'''Project''' - Required field. Tracker is made of multiple projects. At present there are 3: 'moodle', 'moodle.org sites' and 'Non-core contributed modules'. 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; specify 'Non-core contributed modules' for issues/bugs related to contributed modules.

'''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. Bugs with serious security implications are restricted so that only members of the moodle-security group can see them.

'''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''' - Required field. This is the Moodle version in which the bug has been found. It is entered by the person logging the bug, and typically only 1 version is specified. Enter your current version when logging an 'improvement', 'task', or 'new feature' as this will help assess the state of the product when the request was made.

'''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 Moodle version the bug was or will be fixed in. This field is normally completed by the developer when the bug has been resolved or by lead developers allocating bugs for a specific release. Normally only one version is specified in this field. It symbolises the ''first'' version of Moodle where the change will be seen.

'''Attachment''' - Optional. Attach a file that will help developers and testers better understand the bug. Maximum attachement size is 512Kb.

'''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. Use this resolution code only when actual changes were made to Moodle code.
:''Won't Fix'' - The problem described is an issue which will never be fixed.
:''Not a bug'' - This issue is not a bug; was logged in error. Use this code if the bug was fixed by another bug report or in some earlier Moodle version.
:''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 information about setting the Fix Version/s field====

Suppose that the current stable releases are 1.8.3, 1.7.3, 1.6.5 and that 1.9 has branched so we have 1.9 beta+ and 2.0dev. Suppose you fix a bug on the MOODLE_17_STABLE, MOODLE_18_STABLE, MOODLE_19_STABLE and HEAD. Then mark the bug as fixed in 1.7.4, 1.8.4 and 1.9.

After Moodle 1.9 has been released, if you fix a bug on the MOODLE_19_STABLE and HEAD branches, mark it as fixed in 1.9.1 and 2.0.

If you resolved the bug as Cannot reproduce, or Won't fix, etc. Then leave the Fix version blank.

If you resolve the bug as Duplicate, then create a link to the duplicate issue.

These Fix version/s are used to automatically build release notes (see the tabs on http://tracker.moodle.org/browse/MDL) so it is helpful if you can get this right, but don't lose sleep over it.

The Fix version/s filed can also be used before the issue is fixed, as a way of planning when you intend to fix the bug. In this case, you can use any future release. For example, in the situation above, if you have a bug that you think should be fixed on the 1.9 stable branch, but is not urgent, you could set the fix version to 1.9.2 - then when the bug is actually fixed, update that field as necessary.

===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 for 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. Obviously testers should have the skills and knowledge to sufficiently test the issue - experience is important - but don't forget there are others in the Moodle community who may be willing to lend a hand. 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.

Testing a bug in Tracker

NB This is the process members of the moodle-testers group should follow to move bugs from 'resolved' to 'closed'.
*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.

*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.
*All resolved bugs should be tested. Bugs with a resolution code of "fixed" represent bugs where code has been updated, and probably represent more of a challenge than bugs with resoluton codes of duplicate, won't fix, and not a bug, and can't reproduce. Please ensure bugs have been closed with a proper resolution code. Unfortunately it's not easy to change a resolution code in Tracker once the bug has been resolved (the only way is to reopen, then re-resolve).
*Don't be afraid to discuss your testing with the developer assigned to the bug. Simply adding a comment should get the attention of the developer as they are notified of all changes.

===More about the Tracker process===
*You will receive an email when you log a new bug or make updates to bugs you've reported. You'll also receive notification when updates are made to bugs you're watching. Read on for more information on watching a bug.
*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.
*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.

:'''Don't be afraid to link bugs.''' It's very helpful to developers and testers to get a complete picture of a problem.

*'''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 entry best practices ==

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 are some examples of good bug reports: MDL-6030, MDL-5688, MDL-12505

*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.

=== 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==

*[http://www.atlassian.com/software/jira/ Jira] Tracker is a slightly customised version of Atlassian's product
*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]

[[Category:Teacher]]
[[Category:Administrator]]
[[Category:Developer]]
[[Category:Developer tools]]

[[es:Sistema de bugs]]
[[fr:Traqueur de bogues]]

Tracker

2008-03-12T07:45:34Z

Mblake: /* How to report a bug, improvement, or new feature request */

[[Image:Tracker.jpg]] '''is Moodle's''' [[Image:Issue Tracker MoodleOrg link.JPG]]

Issue tracking is an important part of a continuous quality control process. It involves reporting of problems (bugs), ideas for improvement and new features. Unlike most proprietary software programs, Moodle issue reporting and tracking information is open to everyone. Moodle's issue tracking system is called '''[http://tracker.moodle.org Moodle Tracker]'''. We welcome your requests for new features, improvements, or even constructive criticism of existing features.

The beauty of open source is that anyone can participate and help to create a better product for all of us to enjoy. Please help us by using [http://tracker.moodle.org Moodle Tracker]!

==Basics==
===Logging in to 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.
*If you've forgotten your password, go [http://tracker.moodle.org here] and select 'forgot password' which is just under the 'log in' button. Follow the prompts.

=== Summary: 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.

=== How to write a good tracker entry===
*A good external reference to help write a tracker entry can be found at [http://developer.mozilla.org/en/docs/Bug_writing_guidelines mozilla bug writing guidelines]. Be sure to include these pieces of information:
** Summary (How would you describe the bug, in approximately 60 or fewer characters?)
** Description (The details of your problem report), including
*** Overview: More detailed restatement of summary.
*** Steps to Reproduce: A detailed, easy-to-follow sequence of steps a developer can follow to reproduce the problem. If possible, provide a URL so a developer can see the problem with one click.
*** Actual Results: What the application did after performing the above steps.
*** Expected Results: What the application should have done, were the bug not present. Provide as much detail as possible. Your expectation might mean that help instructions need to be improved or interface changed.

Here are some examples of good bug reports: MDL-6030, MDL-5688, MDL-12505

If possible, include additional information that may be helpful to the developer:

* 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:
o Server operating system type and version number
o Web server type and version number
o PHP version number (and whether you are using an accelerator)
o Database type and version number
o 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)
o Client-side operating system type and version number
o Web browser type and version number

* You don't need to provide 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.

==Tracker process==
===Resolving bugs in Tracker===
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 which version of Moodle the change will be included in using the '''Fix Version/s'''. You should use this to indicate which branch(es) you checked the fix into (example below).
* 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.

=== 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.

'''Moodle Security groups''' [groupname=moodle-security] - Trusted developers and administrators who need to work on and learn about security issues.

NB You can browse a project while not logged in to Tracker, however you will be unable change/edit/comment on bugs.
===Tracker fields===
NB A short explanation appears under each field in Tracker.

'''Project''' - Required field. Tracker is made of multiple projects. At present there are 3: 'moodle', 'moodle.org sites' and 'Non-core contributed modules'. 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; specify 'Non-core contributed modules' for issues/bugs related to contributed modules.

'''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. Bugs with serious security implications are restricted so that only members of the moodle-security group can see them.

'''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''' - Required field. This is the Moodle version in which the bug has been found. It is entered by the person logging the bug, and typically only 1 version is specified. Enter your current version when logging an 'improvement', 'task', or 'new feature' as this will help assess the state of the product when the request was made.

'''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 Moodle version the bug was or will be fixed in. This field is normally completed by the developer when the bug has been resolved or by lead developers allocating bugs for a specific release. Normally only one version is specified in this field. It symbolises the ''first'' version of Moodle where the change will be seen.

'''Attachment''' - Optional. Attach a file that will help developers and testers better understand the bug. Maximum attachement size is 512Kb.

'''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. Use this resolution code only when actual changes were made to Moodle code.
:''Won't Fix'' - The problem described is an issue which will never be fixed.
:''Not a bug'' - This issue is not a bug; was logged in error. Use this code if the bug was fixed by another bug report or in some earlier Moodle version.
:''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 information about setting the Fix Version/s field====

Suppose that the current stable releases are 1.8.3, 1.7.3, 1.6.5 and that 1.9 has branched so we have 1.9 beta+ and 2.0dev. Suppose you fix a bug on the MOODLE_17_STABLE, MOODLE_18_STABLE, MOODLE_19_STABLE and HEAD. Then mark the bug as fixed in 1.7.4, 1.8.4 and 1.9.

After Moodle 1.9 has been released, if you fix a bug on the MOODLE_19_STABLE and HEAD branches, mark it as fixed in 1.9.1 and 2.0.

If you resolved the bug as Cannot reproduce, or Won't fix, etc. Then leave the Fix version blank.

If you resolve the bug as Duplicate, then create a link to the duplicate issue.

These Fix version/s are used to automatically build release notes (see the tabs on http://tracker.moodle.org/browse/MDL) so it is helpful if you can get this right, but don't lose sleep over it.

The Fix version/s filed can also be used before the issue is fixed, as a way of planning when you intend to fix the bug. In this case, you can use any future release. For example, in the situation above, if you have a bug that you think should be fixed on the 1.9 stable branch, but is not urgent, you could set the fix version to 1.9.2 - then when the bug is actually fixed, update that field as necessary.

===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 for 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. Obviously testers should have the skills and knowledge to sufficiently test the issue - experience is important - but don't forget there are others in the Moodle community who may be willing to lend a hand. 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.

Testing a bug in Tracker

NB This is the process members of the moodle-testers group should follow to move bugs from 'resolved' to 'closed'.
*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.

*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.
*All resolved bugs should be tested. Bugs with a resolution code of "fixed" represent bugs where code has been updated, and probably represent more of a challenge than bugs with resoluton codes of duplicate, won't fix, and not a bug, and can't reproduce. Please ensure bugs have been closed with a proper resolution code. Unfortunately it's not easy to change a resolution code in Tracker once the bug has been resolved (the only way is to reopen, then re-resolve).
*Don't be afraid to discuss your testing with the developer assigned to the bug. Simply adding a comment should get the attention of the developer as they are notified of all changes.

===More about the Tracker process===
*You will receive an email when you log a new bug or make updates to bugs you've reported. You'll also receive notification when updates are made to bugs you're watching. Read on for more information on watching a bug.
*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.
*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.

:'''Don't be afraid to link bugs.''' It's very helpful to developers and testers to get a complete picture of a problem.

*'''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 entry best practices ==

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 are some examples of good bug reports: MDL-6030, MDL-5688, MDL-12505

*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.

=== 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==

*[http://www.atlassian.com/software/jira/ Jira] Tracker is a slightly customised version of Atlassian's product
*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]

[[Category:Teacher]]
[[Category:Administrator]]
[[Category:Developer]]
[[Category:Developer tools]]

[[es:Sistema de bugs]]
[[fr:Traqueur de bogues]]

Tracker

2008-03-12T07:44:05Z

Mblake: /* How to write a good tracker entry */

[[Image:Tracker.jpg]] '''is Moodle's''' [[Image:Issue Tracker MoodleOrg link.JPG]]

Issue tracking is an important part of a continuous quality control process. It involves reporting of problems (bugs), ideas for improvement and new features. Unlike most proprietary software programs, Moodle issue reporting and tracking information is open to everyone. Moodle's issue tracking system is called '''[http://tracker.moodle.org Moodle Tracker]'''. We welcome your requests for new features, improvements, or even constructive criticism of existing features.

The beauty of open source is that anyone can participate and help to create a better product for all of us to enjoy. Please help us by using [http://tracker.moodle.org Moodle Tracker]!

==Basics==
===Logging in to 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.
*If you've forgotten your password, go [http://tracker.moodle.org here] and select 'forgot password' which is just under the 'log in' button. Follow the prompts.

=== 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.

=== How to write a good tracker entry===
*A good external reference to help write a tracker entry can be found at [http://developer.mozilla.org/en/docs/Bug_writing_guidelines mozilla bug writing guidelines]. Be sure to include these pieces of information:
** Summary (How would you describe the bug, in approximately 60 or fewer characters?)
** Description (The details of your problem report), including
*** Overview: More detailed restatement of summary.
*** Steps to Reproduce: A detailed, easy-to-follow sequence of steps a developer can follow to reproduce the problem. If possible, provide a URL so a developer can see the problem with one click.
*** Actual Results: What the application did after performing the above steps.
*** Expected Results: What the application should have done, were the bug not present. Provide as much detail as possible. Your expectation might mean that help instructions need to be improved or interface changed.

Here are some examples of good bug reports: MDL-6030, MDL-5688, MDL-12505

If possible, include additional information that may be helpful to the developer:

* 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:
o Server operating system type and version number
o Web server type and version number
o PHP version number (and whether you are using an accelerator)
o Database type and version number
o 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)
o Client-side operating system type and version number
o Web browser type and version number

* You don't need to provide 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.

==Tracker process==
===Resolving bugs in Tracker===
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 which version of Moodle the change will be included in using the '''Fix Version/s'''. You should use this to indicate which branch(es) you checked the fix into (example below).
* 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.

=== 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.

'''Moodle Security groups''' [groupname=moodle-security] - Trusted developers and administrators who need to work on and learn about security issues.

NB You can browse a project while not logged in to Tracker, however you will be unable change/edit/comment on bugs.
===Tracker fields===
NB A short explanation appears under each field in Tracker.

'''Project''' - Required field. Tracker is made of multiple projects. At present there are 3: 'moodle', 'moodle.org sites' and 'Non-core contributed modules'. 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; specify 'Non-core contributed modules' for issues/bugs related to contributed modules.

'''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. Bugs with serious security implications are restricted so that only members of the moodle-security group can see them.

'''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''' - Required field. This is the Moodle version in which the bug has been found. It is entered by the person logging the bug, and typically only 1 version is specified. Enter your current version when logging an 'improvement', 'task', or 'new feature' as this will help assess the state of the product when the request was made.

'''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 Moodle version the bug was or will be fixed in. This field is normally completed by the developer when the bug has been resolved or by lead developers allocating bugs for a specific release. Normally only one version is specified in this field. It symbolises the ''first'' version of Moodle where the change will be seen.

'''Attachment''' - Optional. Attach a file that will help developers and testers better understand the bug. Maximum attachement size is 512Kb.

'''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. Use this resolution code only when actual changes were made to Moodle code.
:''Won't Fix'' - The problem described is an issue which will never be fixed.
:''Not a bug'' - This issue is not a bug; was logged in error. Use this code if the bug was fixed by another bug report or in some earlier Moodle version.
:''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 information about setting the Fix Version/s field====

Suppose that the current stable releases are 1.8.3, 1.7.3, 1.6.5 and that 1.9 has branched so we have 1.9 beta+ and 2.0dev. Suppose you fix a bug on the MOODLE_17_STABLE, MOODLE_18_STABLE, MOODLE_19_STABLE and HEAD. Then mark the bug as fixed in 1.7.4, 1.8.4 and 1.9.

After Moodle 1.9 has been released, if you fix a bug on the MOODLE_19_STABLE and HEAD branches, mark it as fixed in 1.9.1 and 2.0.

If you resolved the bug as Cannot reproduce, or Won't fix, etc. Then leave the Fix version blank.

If you resolve the bug as Duplicate, then create a link to the duplicate issue.

These Fix version/s are used to automatically build release notes (see the tabs on http://tracker.moodle.org/browse/MDL) so it is helpful if you can get this right, but don't lose sleep over it.

The Fix version/s filed can also be used before the issue is fixed, as a way of planning when you intend to fix the bug. In this case, you can use any future release. For example, in the situation above, if you have a bug that you think should be fixed on the 1.9 stable branch, but is not urgent, you could set the fix version to 1.9.2 - then when the bug is actually fixed, update that field as necessary.

===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 for 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. Obviously testers should have the skills and knowledge to sufficiently test the issue - experience is important - but don't forget there are others in the Moodle community who may be willing to lend a hand. 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.

Testing a bug in Tracker

NB This is the process members of the moodle-testers group should follow to move bugs from 'resolved' to 'closed'.
*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.

*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.
*All resolved bugs should be tested. Bugs with a resolution code of "fixed" represent bugs where code has been updated, and probably represent more of a challenge than bugs with resoluton codes of duplicate, won't fix, and not a bug, and can't reproduce. Please ensure bugs have been closed with a proper resolution code. Unfortunately it's not easy to change a resolution code in Tracker once the bug has been resolved (the only way is to reopen, then re-resolve).
*Don't be afraid to discuss your testing with the developer assigned to the bug. Simply adding a comment should get the attention of the developer as they are notified of all changes.

===More about the Tracker process===
*You will receive an email when you log a new bug or make updates to bugs you've reported. You'll also receive notification when updates are made to bugs you're watching. Read on for more information on watching a bug.
*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.
*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.

:'''Don't be afraid to link bugs.''' It's very helpful to developers and testers to get a complete picture of a problem.

*'''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 entry best practices ==

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 are some examples of good bug reports: MDL-6030, MDL-5688, MDL-12505

*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.

=== 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==

*[http://www.atlassian.com/software/jira/ Jira] Tracker is a slightly customised version of Atlassian's product
*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]

[[Category:Teacher]]
[[Category:Administrator]]
[[Category:Developer]]
[[Category:Developer tools]]

[[es:Sistema de bugs]]
[[fr:Traqueur de bogues]]

Development:CVS for developers

2008-01-28T01:11:03Z

Mblake: /* Joining the project as a developer */

'''CVS''' is the Concurrent Versioning System, a commonly-used way of managing source code for large software projects. CVS keeps all versions of all files so that nothing is ever lost, and usage by different people is tracked. It also provides ways to merge code if two or more people are working on the same file. All code and all versions are stored on a central server (in the case of Moodle, at cvs.moodle.org). The [http://cvsbook.red-bean.com/cvsbook.html CVS book] holds more information about CVS than you need.

If you just want to download Moodle using CVS to run a site, then you probably don't need this page - please see [[CVS for Administrators]] instead.

==Joining the project as a developer==

So, you've been offered CVS write access to help us develop and maintain Moodle! Welcome aboard!

To be able to write changes into [http://cvs.moodle.org/ Moodle's CVS archive], you first need to have an account on the server. Only trusted developers get these accounts. To request access, go to the "Apply for CVS Access" tab on the CVS page on Moodle.org (http://moodle.org/cvs). Tell us what modules you'd like to access (e.g. a language module), and why. You'll receive notification in a day or so.

With that done, you should have all the permissions you need, so you just need to set up your machine and download the current source code so you can start working on it.

For the examples on this page, let's assume your username is '''myusername''' and your password is '''mypassword'''.

==CVS modules==

Within CVS, the word "modules" refers to separate collections of code. In Moodle we have the following modules within our repository:

* '''moodle''' - the main Moodle source code
* '''lang''' - all the language packs
* '''[[Development:contrib|contrib]]''' - user contributions and other assorted code in development
* '''mysql''' - a customised phpMyAdmin to plug into Moodle for database admin
* '''windows-cron''' - a small package that makes cron possible on Windows systems
* '''docs''' - various extra user-contributed documentation

Most people are working on the existing features in the moodle module, but many are also contributing new ideas in the contrib modules. Once code reaches a certain level of maturity in the contrib area, it can be migrated over into the main moodle tree.

==Basic CVS commands==

===CVS on Unix===

Moodle CVS uses ssh as a transport layer for security, so you will have to set a CVS_RSH environment variable in your Unix shell. It's best to put these commands in your .bashrc or .cshrc so you don't have to type it all the time:
setenv CVS_RSH ssh (for csh, tcsh etc)
export CVS_RSH=ssh (for sh, bash etc)

Next, you can check out the latest development version of Moodle using this (all one line). NOTE: Don't try to do run this first CVS command over an existing moodle installation: start fresh with a new directory!:
cvs -z3 -d:ext:myusername@cvs.moodle.org:/cvsroot/moodle co moodle

The command is similar for other CVS modules:
cvs -z3 -d:ext:myusername@cvs.moodle.org:/cvsroot/moodle co contrib

Note that you will be prompted for mypassword for each command unless you set up authorized keys.

Now, you should have a new 'moodle' directory. You can rename it and move it around if you like. Go into it:
cd moodle

All the latest Moodle files should be in there. You can now change files in your copy. To compare your files and directories against the main CVS copy on the server use cvs diff, e.g.:
cvs diff -c config-dist.php
cvs diff -c lang

To fetch the latest updates from the server use:
cvs update -dP

To copy your new files back to the server you would do something like:
cd lang/ca
cvs commit

You will be prompted to add some comments (depends on your default text editor). Please write a meaningful, descriptive comment and '''always include the name of any tracker issues that talk about the issue you are fixing''' (eg '''MDL-XXXX''').

After that your changes will be sent to the CVS server and stored in the repository. Done!

To save more time you can put default arguments into a file called .cvsrc in your home directory. For example, mine contains:
diff -c
update -dP

Try 'cvs help' for more details ...

===CVS on Mac OSX===

You can follow the same instructions as for Unix (above) in a terminal window. However, the cvs command is not installed by default in an OSX. You first need to install the XCode Tools. You should find this on your original installation disk. Failing that it can be downloaded (a fairly hefty download) from the Apple developer web site ([http://developer.apple.com]).

===CVS on Windows===

First, you need to download a completely fresh copy of Moodle using your developer account.

1. Get TortoiseCVS from tortoisecvs.org and install it, then reboot.

2. Find or create a new folder somewhere where you want Moodle to be downloaded to.

3. Right-mouse-click that folder and choose "CVS Checkout" from the menu. You should see a dialog box.

4. Copy this text into the CVSROOT field (using your own username!):

:ext:myusername@cvs.moodle.org:/cvsroot/moodle

5. Under the "Module" field, type "moodle" to get the latest development version of Moodle, "contrib" to get the contributions directory, or "mysql" to get the MySQL Admin module.

6. Press the button: "OK" and everything should be downloaded.

A dialog box should show all the files being downloaded, and after a while you should have a complete copy of Moodle. After this first checkout, you can fetch the latest updated files from the CVS server:

# Right-mouse-click on your Moodle folder (or any file) and select "CVS Update".
# Sit back and watch the logs scroll by. Take note of conflicts that may occur if your local code has changes that conflict with the incoming versions - you will need to edit these files and resolve the conflicts manually.

After modifying files (you will notice their icons change from green to red!), you can commit them back to the CVS server like this:

# Right-mouse-click on your Moodle folder (or any file) and select "CVS Commit...".
# In the dialog box, type a clear description of the changes you are committing. '''Always include the name of any tracker issues related to what you are fixing''' (eg '''MDL-XXXX''').
# Click "OK". Your changes will be sent to the server.
# If you create a folder, BE CAREFUL about using the "CVS Add" option as it will add the folder to CVS without requiring a commit. Once added, the folder cannot be removed from CVS even though it will be pruned so long as it is empty.

==Working with branches==

This diagram shows how the main moodle module branches into different versions over time.

[[Image:Cvstree.png|CVS tree]]

To see all the current tags and branches that are available, use this command on any old file (such as index.php in the top moodle directory):
cvs status -v index.php

Some tagging guidelines:
* Tag and branch names should always be all upper-case.
* Tags and branches should ALWAYS be applied to the entire module (all of Moodle). Don't tag individual files or directories.
* We don't allow renaming of tags because people may be relying on them, so get them right the first time!

===Trunk development===

The Trunk of CVS is the main development version of Moodle. In CVS it is also known as the HEAD, or default branch.

Moodle developers try to keep this stable as possible, but as it usually contains new code it probably has bugs and small instabilities.

Every now and then we decide the product has enough features to make a release. At this time, the trunk is tagged with a MOODLE_XX_BETA tag (in case we ever want to roll back to that point) and a new branch is formed for the release, called MOODLE_XX_STABLE.

A Beta package is also released at this point - it's for testers who don't use CVS but want to test the latest features and report bugs.

===Stable branches for each release===

As soon as the stable branch MOODLE_XX_STABLE is created, development efforts will fork into two streams for a while. Some people may continue working on new features in the trunk for the next release, but most developers should be concentrating on using the current STABLE branch and fixing bugs that are found in it.

You can switch your local copy of Moodle to the STABLE version using the following command in Unix from the root directory:
cvs update -dP -r MOODLE_XX_STABLE

After that, all the commands described above will apply to that stable version. To return to the trunk version just issue:
cvs update -dPA

On Windows clients you should have a menu from which you can choose the branch.

Once the new STABLE branch really stabilises, a release can be declared. Packages are created for distribution and the branch will be tagged (by Martin Dougiamas) with a tag named: MOODLE_XXX

===Merging fixes===

All bug fixes in any STABLE branch should be merged back into the trunk so that they become available in future versions of Moodle. A floating tag called MOODLE_XX_MERGED needs to be maintained to keep track of the last merge. The procedure for such a merge is as follows (I'm using CVS on the Unix command line but the steps are the same for any CVS client):

[[Image:Merging.png|thumb|right|300px|This diagram summarises the process]]
1. I highly recommend keeping one checked out copy of each stable branch and the trunk/head version locally to make it easier to jump between them. Set them all up as virtual web sites on your development machine. I use directories like /moodle/18, /moodle/19 /moodle/dev etc.

2. Update to the latest stable version (I'll use XX in the example but it could be 18, 19 etc) for the relevant files, and do a cvs diff just to double-check exactly what you are checking in. Note you only need to update the files/directories you are working in, but sometimes it help to update everything anyway just to do a final check on the functionality using the web.

cd /moodle/XX/user
cvs update -dPA
cvs diff -c file1.php file2.php

3. If all looks OK, check in the fix to the stable branch. Make sure that the commit message contains the bug tracker ID (eg MDL-1111) and a decent description of your thoughts on the fix. If you don't specify a message in the command line, you'll be put into an editor to type one.

cvs commit -m "MDL-1234 Corrected a small typo in the user name field" file1.php file2.php

4. Go to the very latest trunk version and make sure it's up-to-date.

cd /moodle/dev/user
cvs update -dPA

5. Merge everything into your local copy of the trunk from your stable branch since the last merge. You can use the same sequence of (4) and (5) to merge the changes into other stable branches too (to backport the fix to the previous stable versions).

cvs update -kk -j MOODLE_XX_MERGED -j MOODLE_XX_STABLE file1.php file2.php

6. Carefully watch the update logs for conflicts, and fix every file that you see with a conflict. Afterwards, it may help to just run a diff to make sure the result is what you expected:

cvs diff -c file1.php file2.php

7. Check your merged local copy back into CVS trunk version

cvs commit -m "MDL-1234 Corrected a small typo in the user name field, merged from XX" file1.php file2.php

8. Go back to your branch version

cd /moodle/XX/user

9. Update the floating merge tag for the affected files (so that it matches MOODLE_XX_STABLE) so that this process can be repeated next time

cvs tag -RF MOODLE_XX_MERGED file1.php file2.php

Finally, the values for $version in all the Moodle version.php files within the stable branch should not be updated at all if possible (except the last digit if absolutely necessary). The reason is that someone updating from a very stable version to the next very stable version could miss database upgrades that happened on the trunk.

===Feature branches for large changes===

Occasionally, there may be a very large feature that needs to be checked in so several people can work on it, but it is too unstable to be included in the main development trunk.

In these cases a short-term branch can be created to work on the feature, and then merged back into the main trunk as soon as possible. An example called MOODLE_17_WIDGET branch can be seen in the above diagram.

If you need to do this for your new WIDGET feature, follow these steps:

1. Discuss with other developers to make sure it's necessary!

2. Make a new tag on the trunk (for all of moodle) called MOODLE_XX_WIDGET_PRE

cvs tag -R MOODLE_XX_WIDGET_PRE

3. Create your branch called MOODLE_XX_WIDGET

cvs tag -Rb MOODLE_XX_WIDGET

4. Work in that branch until the feature is reasonably stable. Commit as necessary.

cvs commit

5. When ready, merge the whole branch into the trunk, fix conflicts, commit it to the trunk and then abandon the branch.

cvs update -dPA
cvs update -kk -j MOODLE_XX_WIDGET
cvs commit

Good luck, be careful and have fun!

==Who on earth is ...==

Some of the people committing to the Moodle codebase have non-boring account names on the CVS server. If you are ever looking at a CVS commit, and wondering "who on earth is this purpleblob person?" this list may help:

;diml: [http://moodle.org/user/view.php?id=34826&course=5 Valery Fremaux]
;jmg324: [http://moodle.org/user/view.php?id=93820&course=5 Jenny Gray] (Open University)
;mjollnir_: [http://moodle.org/user/view.php?id=17383&course=5 Penny Leach] (Catalyst)
;moodler: [http://moodle.org/user/view.php?id=1&course=5 Martin Dougiamas] (moodle.com)
;scyrma: [http://moodle.org/user/view.php?id=423027&course=5 Mathieu Petit-Clair] (moodle.com)
;skodak: [http://moodle.org/user/view.php?id=12863&course=5 Petr Škoda] (moodle.com)
;stronk7: [http://moodle.org/user/view.php?id=3176&course=5 Eloy Lafuente]
;thepurpleblob: [http://moodle.org/user/view.php?id=1473&course=5 Howard Miller]
;wildgirl: [http://moodle.org/user/view.php?id=24152&course=5 Helen Foster] (moodle.com)

==Tips and Hints==
* [[Tracking Moodle CVS with git]]
* [http://moodle.org/mod/forum/discuss.php?d=34472 Merging Custom Moodle Code With Stable Releases]
* [[Unmerged files]]: To see if you've forgotten to merge any file.
* [http://ximbiot.com/cvs/manual/ CVS Manual]
* [[Development:contrib|Introduction to the '''contrib''' area of CVS]]

==See Also==

* [http://tracker.moodle.org/browse/MDLSITE-193 "All developers should switch to using the cvs.moodle.org alias"]
* [[CVS_for_Administrators]]
[[Category:Developer|CVS for developers]]
[[Category:Developer tools]]

[[es:CVS para desarrolladores]]
[[fr:CVS pour développeurs]]

Development:CVS for developers

2008-01-28T01:08:58Z

Mblake: /* Joining the project as a developer */

'''CVS''' is the Concurrent Versioning System, a commonly-used way of managing source code for large software projects. CVS keeps all versions of all files so that nothing is ever lost, and usage by different people is tracked. It also provides ways to merge code if two or more people are working on the same file. All code and all versions are stored on a central server (in the case of Moodle, at cvs.moodle.org). The [http://cvsbook.red-bean.com/cvsbook.html CVS book] holds more information about CVS than you need.

If you just want to download Moodle using CVS to run a site, then you probably don't need this page - please see [[CVS for Administrators]] instead.

==Joining the project as a developer==

So, you've been offered CVS write access to help us develop and maintain Moodle! Welcome aboard!

To be able to write changes into [http://cvs.moodle.org/ Moodle's CVS archive], you first need to have an account on the server. Only trusted developers get these accounts. To request access, go to the "Apply for CVS Access" tab on the CVS page on Moodle.org (http://moodle.org/cvs). Tell us what areas you'd like to access (e.g. a language module), and why. You'll receive notification in a day or so.

With that done, you should have all the permissions you need, so you just need to set up your machine and download the current source code so you can start working on it.

For the examples on this page, let's assume your username is '''myusername''' and your password is '''mypassword'''.

==CVS modules==

Within CVS, the word "modules" refers to separate collections of code. In Moodle we have the following modules within our repository:

* '''moodle''' - the main Moodle source code
* '''lang''' - all the language packs
* '''[[Development:contrib|contrib]]''' - user contributions and other assorted code in development
* '''mysql''' - a customised phpMyAdmin to plug into Moodle for database admin
* '''windows-cron''' - a small package that makes cron possible on Windows systems
* '''docs''' - various extra user-contributed documentation

Most people are working on the existing features in the moodle module, but many are also contributing new ideas in the contrib modules. Once code reaches a certain level of maturity in the contrib area, it can be migrated over into the main moodle tree.

==Basic CVS commands==

===CVS on Unix===

Moodle CVS uses ssh as a transport layer for security, so you will have to set a CVS_RSH environment variable in your Unix shell. It's best to put these commands in your .bashrc or .cshrc so you don't have to type it all the time:
setenv CVS_RSH ssh (for csh, tcsh etc)
export CVS_RSH=ssh (for sh, bash etc)

Next, you can check out the latest development version of Moodle using this (all one line). NOTE: Don't try to do run this first CVS command over an existing moodle installation: start fresh with a new directory!:
cvs -z3 -d:ext:myusername@cvs.moodle.org:/cvsroot/moodle co moodle

The command is similar for other CVS modules:
cvs -z3 -d:ext:myusername@cvs.moodle.org:/cvsroot/moodle co contrib

Note that you will be prompted for mypassword for each command unless you set up authorized keys.

Now, you should have a new 'moodle' directory. You can rename it and move it around if you like. Go into it:
cd moodle

All the latest Moodle files should be in there. You can now change files in your copy. To compare your files and directories against the main CVS copy on the server use cvs diff, e.g.:
cvs diff -c config-dist.php
cvs diff -c lang

To fetch the latest updates from the server use:
cvs update -dP

To copy your new files back to the server you would do something like:
cd lang/ca
cvs commit

You will be prompted to add some comments (depends on your default text editor). Please write a meaningful, descriptive comment and '''always include the name of any tracker issues that talk about the issue you are fixing''' (eg '''MDL-XXXX''').

After that your changes will be sent to the CVS server and stored in the repository. Done!

To save more time you can put default arguments into a file called .cvsrc in your home directory. For example, mine contains:
diff -c
update -dP

Try 'cvs help' for more details ...

===CVS on Mac OSX===

You can follow the same instructions as for Unix (above) in a terminal window. However, the cvs command is not installed by default in an OSX. You first need to install the XCode Tools. You should find this on your original installation disk. Failing that it can be downloaded (a fairly hefty download) from the Apple developer web site ([http://developer.apple.com]).

===CVS on Windows===

First, you need to download a completely fresh copy of Moodle using your developer account.

1. Get TortoiseCVS from tortoisecvs.org and install it, then reboot.

2. Find or create a new folder somewhere where you want Moodle to be downloaded to.

3. Right-mouse-click that folder and choose "CVS Checkout" from the menu. You should see a dialog box.

4. Copy this text into the CVSROOT field (using your own username!):

:ext:myusername@cvs.moodle.org:/cvsroot/moodle

5. Under the "Module" field, type "moodle" to get the latest development version of Moodle, "contrib" to get the contributions directory, or "mysql" to get the MySQL Admin module.

6. Press the button: "OK" and everything should be downloaded.

A dialog box should show all the files being downloaded, and after a while you should have a complete copy of Moodle. After this first checkout, you can fetch the latest updated files from the CVS server:

# Right-mouse-click on your Moodle folder (or any file) and select "CVS Update".
# Sit back and watch the logs scroll by. Take note of conflicts that may occur if your local code has changes that conflict with the incoming versions - you will need to edit these files and resolve the conflicts manually.

After modifying files (you will notice their icons change from green to red!), you can commit them back to the CVS server like this:

# Right-mouse-click on your Moodle folder (or any file) and select "CVS Commit...".
# In the dialog box, type a clear description of the changes you are committing. '''Always include the name of any tracker issues related to what you are fixing''' (eg '''MDL-XXXX''').
# Click "OK". Your changes will be sent to the server.
# If you create a folder, BE CAREFUL about using the "CVS Add" option as it will add the folder to CVS without requiring a commit. Once added, the folder cannot be removed from CVS even though it will be pruned so long as it is empty.

==Working with branches==

This diagram shows how the main moodle module branches into different versions over time.

[[Image:Cvstree.png|CVS tree]]

To see all the current tags and branches that are available, use this command on any old file (such as index.php in the top moodle directory):
cvs status -v index.php

Some tagging guidelines:
* Tag and branch names should always be all upper-case.
* Tags and branches should ALWAYS be applied to the entire module (all of Moodle). Don't tag individual files or directories.
* We don't allow renaming of tags because people may be relying on them, so get them right the first time!

===Trunk development===

The Trunk of CVS is the main development version of Moodle. In CVS it is also known as the HEAD, or default branch.

Moodle developers try to keep this stable as possible, but as it usually contains new code it probably has bugs and small instabilities.

Every now and then we decide the product has enough features to make a release. At this time, the trunk is tagged with a MOODLE_XX_BETA tag (in case we ever want to roll back to that point) and a new branch is formed for the release, called MOODLE_XX_STABLE.

A Beta package is also released at this point - it's for testers who don't use CVS but want to test the latest features and report bugs.

===Stable branches for each release===

As soon as the stable branch MOODLE_XX_STABLE is created, development efforts will fork into two streams for a while. Some people may continue working on new features in the trunk for the next release, but most developers should be concentrating on using the current STABLE branch and fixing bugs that are found in it.

You can switch your local copy of Moodle to the STABLE version using the following command in Unix from the root directory:
cvs update -dP -r MOODLE_XX_STABLE

After that, all the commands described above will apply to that stable version. To return to the trunk version just issue:
cvs update -dPA

On Windows clients you should have a menu from which you can choose the branch.

Once the new STABLE branch really stabilises, a release can be declared. Packages are created for distribution and the branch will be tagged (by Martin Dougiamas) with a tag named: MOODLE_XXX

===Merging fixes===

All bug fixes in any STABLE branch should be merged back into the trunk so that they become available in future versions of Moodle. A floating tag called MOODLE_XX_MERGED needs to be maintained to keep track of the last merge. The procedure for such a merge is as follows (I'm using CVS on the Unix command line but the steps are the same for any CVS client):

[[Image:Merging.png|thumb|right|300px|This diagram summarises the process]]
1. I highly recommend keeping one checked out copy of each stable branch and the trunk/head version locally to make it easier to jump between them. Set them all up as virtual web sites on your development machine. I use directories like /moodle/18, /moodle/19 /moodle/dev etc.

2. Update to the latest stable version (I'll use XX in the example but it could be 18, 19 etc) for the relevant files, and do a cvs diff just to double-check exactly what you are checking in. Note you only need to update the files/directories you are working in, but sometimes it help to update everything anyway just to do a final check on the functionality using the web.

cd /moodle/XX/user
cvs update -dPA
cvs diff -c file1.php file2.php

3. If all looks OK, check in the fix to the stable branch. Make sure that the commit message contains the bug tracker ID (eg MDL-1111) and a decent description of your thoughts on the fix. If you don't specify a message in the command line, you'll be put into an editor to type one.

cvs commit -m "MDL-1234 Corrected a small typo in the user name field" file1.php file2.php

4. Go to the very latest trunk version and make sure it's up-to-date.

cd /moodle/dev/user
cvs update -dPA

5. Merge everything into your local copy of the trunk from your stable branch since the last merge. You can use the same sequence of (4) and (5) to merge the changes into other stable branches too (to backport the fix to the previous stable versions).

cvs update -kk -j MOODLE_XX_MERGED -j MOODLE_XX_STABLE file1.php file2.php

6. Carefully watch the update logs for conflicts, and fix every file that you see with a conflict. Afterwards, it may help to just run a diff to make sure the result is what you expected:

cvs diff -c file1.php file2.php

7. Check your merged local copy back into CVS trunk version

cvs commit -m "MDL-1234 Corrected a small typo in the user name field, merged from XX" file1.php file2.php

8. Go back to your branch version

cd /moodle/XX/user

9. Update the floating merge tag for the affected files (so that it matches MOODLE_XX_STABLE) so that this process can be repeated next time

cvs tag -RF MOODLE_XX_MERGED file1.php file2.php

Finally, the values for $version in all the Moodle version.php files within the stable branch should not be updated at all if possible (except the last digit if absolutely necessary). The reason is that someone updating from a very stable version to the next very stable version could miss database upgrades that happened on the trunk.

===Feature branches for large changes===

Occasionally, there may be a very large feature that needs to be checked in so several people can work on it, but it is too unstable to be included in the main development trunk.

In these cases a short-term branch can be created to work on the feature, and then merged back into the main trunk as soon as possible. An example called MOODLE_17_WIDGET branch can be seen in the above diagram.

If you need to do this for your new WIDGET feature, follow these steps:

1. Discuss with other developers to make sure it's necessary!

2. Make a new tag on the trunk (for all of moodle) called MOODLE_XX_WIDGET_PRE

cvs tag -R MOODLE_XX_WIDGET_PRE

3. Create your branch called MOODLE_XX_WIDGET

cvs tag -Rb MOODLE_XX_WIDGET

4. Work in that branch until the feature is reasonably stable. Commit as necessary.

cvs commit

5. When ready, merge the whole branch into the trunk, fix conflicts, commit it to the trunk and then abandon the branch.

cvs update -dPA
cvs update -kk -j MOODLE_XX_WIDGET
cvs commit

Good luck, be careful and have fun!

==Who on earth is ...==

Some of the people committing to the Moodle codebase have non-boring account names on the CVS server. If you are ever looking at a CVS commit, and wondering "who on earth is this purpleblob person?" this list may help:

;diml: [http://moodle.org/user/view.php?id=34826&course=5 Valery Fremaux]
;jmg324: [http://moodle.org/user/view.php?id=93820&course=5 Jenny Gray] (Open University)
;mjollnir_: [http://moodle.org/user/view.php?id=17383&course=5 Penny Leach] (Catalyst)
;moodler: [http://moodle.org/user/view.php?id=1&course=5 Martin Dougiamas] (moodle.com)
;scyrma: [http://moodle.org/user/view.php?id=423027&course=5 Mathieu Petit-Clair] (moodle.com)
;skodak: [http://moodle.org/user/view.php?id=12863&course=5 Petr Škoda] (moodle.com)
;stronk7: [http://moodle.org/user/view.php?id=3176&course=5 Eloy Lafuente]
;thepurpleblob: [http://moodle.org/user/view.php?id=1473&course=5 Howard Miller]
;wildgirl: [http://moodle.org/user/view.php?id=24152&course=5 Helen Foster] (moodle.com)

==Tips and Hints==
* [[Tracking Moodle CVS with git]]
* [http://moodle.org/mod/forum/discuss.php?d=34472 Merging Custom Moodle Code With Stable Releases]
* [[Unmerged files]]: To see if you've forgotten to merge any file.
* [http://ximbiot.com/cvs/manual/ CVS Manual]
* [[Development:contrib|Introduction to the '''contrib''' area of CVS]]

==See Also==

* [http://tracker.moodle.org/browse/MDLSITE-193 "All developers should switch to using the cvs.moodle.org alias"]
* [[CVS_for_Administrators]]
[[Category:Developer|CVS for developers]]
[[Category:Developer tools]]

[[es:CVS para desarrolladores]]
[[fr:CVS pour développeurs]]

Roadmap

2007-09-04T07:07:00Z

Mblake: /* Version 1.9 - Expected August 2007 */

This roadmap collects the best information about upcoming features in Moodle. It is not 100% certain - features may change according to available funding and developers.

== Version 1.9 - Expected September 2007 ==
''1.9 is currently in beta. See [https://docs.moodle.org/en/Release_Notes Release Notes]
* [[Development:Grades|Gradebook development]] - Moodle.com and OU
::The gradebook system will be revamped for performance, switching from our older "pull" model to a "push" model where all modules will now publish grades as necessary into a central table. Support for (local/state) [[Development:Outcomes|outcomes/goals/competencies]] is included!
* [[Development:Events|Events API]] - Moodle.com
::The new Events API provides a way for any code to "hook" into events in a clean, loosely coupled way. It's the foundation of the new Gradebook. A lot of events in Moodle (such as adding a user or a course) now trigger events that developers can hook into.
* [[Tags]] - part of the [[Student_projects/Social_Networking_features|Google SOC Social Networking]] project by Luiz Cruz will make it's way into 1.9, allowing users to tag themselves and create interest pages around those tags, bringing information together from a variety of sources.
* [[Question_Engine_Changes_in_Moodle_1.9|Improved question bank]] - Jamie Pratt funded by [http://www.fun.ac.jp/en/ Future University Hakodate].
** Allows questions to be shared by the whole site, a course category, a singe course, or be kept private to a single module. More control over who can do what to each question.
** [[Questions linking to files|Also improved management of files linked to from questions.]]
** See also the original development plan here :[[Development:Plan_to_Improve_Flexibility_of_Question_Category_Sharing_and_Permissions]]
* Other Quiz/Question improvements:
** A quiz can now [[Quiz submission email notification|send emails when an attempt is finished]] - a confirmation to the student, a notification to all teachers, or both. (Implemented by Graham Miller of [http://www.webenhanced.com.au/ Web Enhanced Solutions]).
** Some slight improvements to quiz layout. See [http://tracker.moodle.org/browse/MDL-10374 MDL-10374] for details. Theme designers please note.
** Gift Import/Export format can now handle Essay and Description question types.
** Third party question types can now implement Moodle XML and other import and export formats (Implemented by Howard Miller).
** Multiple choice questions now show the feedback for all the options to students on the review page after the attempt is over.
* [[Development:Feedback|Integrate Feedback module]]?

== Version 2.0 - Expected Mid 2008 ==

(This list is fluid, depending on available resources)

===Definitely===
* Moodle 2.0 will require PHP 5.2 as a minimum, allowing us to clean up the code in some areas. For more info see: [http://gophp5.org/ gophp5.org]
* [[Development:Portfolio API]] - Enovation.ie
::Interface Moodle activities and repositories to help produce portfolios for internal assessment AND external publication. The first Portfolio plugin implemented will be [http://www.mahara.org/ Mahara].
* [[Conditional activities]] - Moodle.com
::Allowing dependencies and forced paths through the content
* [[Community hub]] interfaces - Moodle.com and others
::Makes it easy for users to find and navigate other systems and external Moodle repositories, leveraging the Moodle Network in various ways.
* [[Repository API]] - Open University, Moodle.com, Humboldt and Warp Networks
::Abstract all file operations to an API that allows plugins for different external repositories
* Old DB install/upgrade system removed
:: The deprecated system for installing or upgrading database entries used in Moodle < 1.7 will be completely removed, while supporting only the new XML based database scheme introduced in 1.7
* [[Development:Groups_documentation_for_module_developers|New groups]] - Open University
::Site-wide groups, reusable groups, and assigning activities to groups are the major improvements being developed

===Hopefully===
* Integrate [[Dfwiki|nwiki]]
* [[IMS Learning Design]] - Moodle.com
::Support for importing/exporting LD, converting Moodle activities and sequences of activities into a standard format for sharing, and importing standard sequences into Moodle courses
* [[Student Information API]]
::API for integrating external systems for managing student information
* [[Development:Voice|Moodle Voice]]
:: Moodle Voice is a project for embedding VoiceXML support into Moodle Core.
* [[Learning Design export]]? - Moodle.com and Open University of The Netherlands
::We plan to have a very simple export for any Moodle course into IMS LD format, as a proof of concept and to help the community start learning about IMS LD.

[[Category:Developer]]
[[Category:Future]]

[[es:Planificación]]
[[fr:Planification]]

Roadmap

2007-03-09T04:27:05Z

Mblake: /* Version 1.8 - Expected February 2007 */

This roadmap collects the best information about upcoming features in Moodle. It is not 100% certain - features may change according to available funding and developers.

== Version 1.8 - Expected March 2007 ==

* [[Accessibility]] - Moodle.com
:: Compliance with all major accessibility standards
* [[Moodle forms library]] - Moodle.com
:: All forms can now use a single API for defining forms consistently and collecting data safely.
* [[Multi Authentication]] - Iñaki Arenaza / Jonathan Harker (Catalyst) / Martin Langhoff (Catalyst)
* [[Development:Customisable user profiles|Customisable User Profiles]] - Pukunui Technology
::Allow fields to be added to the user profile.
* [[Moodle Network]] - Catalyst and Moodle.com
:: Setup peer Moodle installations allowing users to roam across, using comprehensive SSO and transparent remote enrolments. Administrators at the originating Moodle install can see logs of remote activity. You can also run your Moodle in "Hub" mode where any Moodle install can connect and users roam across.
::[[Web Services API]] for Moodle communications. The Moodle Network code includes an XML-RPC call dispatcher that can expose the whole Moodle API to trusted hosts.
* Groups refactor - Juliette White / Nick Freear (OU)
::Groups code will be reorganised to make it more flexible for the future (see 1.9)
* [[Authorize.net Payment Gateway]] enrolment plugin
:: Payment managers can obtain an authorization code over phone from customer's bank if the credit card of the user cannot be captured on the internet directly.

== Version 1.9 - Expected June 2007 ==

* [[Development:Grades|Gradebook development]] - Moodle.com
::The gradebook system will be revamped for performance, switching from our older "pull" model to a "push" model where all modules will now publish grades as necessary into a central table.
* [[Metadata]] - Moodle.com
::Build on the keywords in 1.6 to provide metadata for all activities and courses, linkable to standard lists of metadata such as State-based learning outcomes and curricula
* [[Repository API]] - Open University, Moodle.com and Humboldt
::Abstract all file operations to an API that allows plugins for different external repositories
* [[Learning Design export]] - Moodle.com and Open University of The Netherlands
::We plan to have a very simple export for any Moodle course into IMS LD format, as a proof of concept and to help the community start learning about IMS LD.
* [[Development:Groups_documentation_for_module_developers|New groups]] - Open University
::Site-wide groups, reusable groups, and assigning activities to groups are the major improvements being developed
* Blog commenting
:: You'll be able to make comments on blogs! In time, all comments in Moodle will be merged into the same commenting system.
* SCORM 2004?
* Integrate nwiki?
* Integrate Feedback module?

== Version 2.0 - Expected Late 2007 ==

* [[IMS Learning Design]] - Moodle.com
::Support for importing/exporting LD, converting Moodle activities and sequences of activities into a standard format for sharing, and importing standard sequences into Moodle courses
* [[Conditional activities]] - Moodle.com
::Allowing dependencies and forced paths through the content
* [[Community hub]] interfaces - Moodle.com and others
::Makes it easy for users to find and navigate other systems and external Moodle repositories, leveraging the Moodle Network in various ways.
* [[Student Information API]]
::API for integrating external systems for managing student information
* Old DB install/upgrade system removed
:: The deprecated system for installing or upgrading database entries used in Moodle < 1.7 will be completely removed, while supporting only the new XML based database scheme introduced in 1.7

''Note: Moodle 2.0 will require PHP 5.1 as a minimum, because of certain improvements not available in PHP 4.''

== Version 2.1 ==

* [[Development:Portfolio API]]
::Interface Moodle activities and repositories to help produce portfolios for internal assessment AND external publication

[[Category:Developer]]
[[Category:Future]]

[[es:Planificación]]
[[fr:Planification]]

Verification of sites on moodle.org

2007-02-15T07:23:15Z

Mblake:

'''Background'''
When administrations create a new installation of Moodle they are given the opportunity to register their site on http://moodle.org. When the registration is approved the site will be reported on http://moodle.org/sites. The name of the site appears on a country-by-country list.

To accept or reject a site you must have permission to do so. To request permission contact Michael Blake (via moodle.org or directly at michael@moodle.com).

'''Procedure'''
#Go to http://moodle.org/sites
#Select the button “Check new registrations” in the upper right corner of the screen.
#You be presented with a screen divided into 2 sections. On the left is a listing of unverified sites. On the right are general instructions for verification. Read these instructions, but understand some of this information is out of date.
#Click on a site from the list on the left.
#You are presented with details of this site. The lower half of the screen shows the actual site (it takes a few seconds for the information to appear.)
#Use these guidelines in the verification process:
:*Reject if the url is not valid
:*Reject if it appears to be a temporary or test site.
:*Reject if it appears to have no courses. Courses may have been added since registration, so the info in the upper section may not be reliable, but can be used as an indication.
:*Accept if there are multiple courses and/or users at time of registration.
#Enter a very brief reason if rejecting (e.g. can’t find server or no courses).
#Administrator will receive notification from you when confirming/rejecting.
There is a button to “confirm as cool” if you find one.

Don't be overly concerned about rejecting a site in error as admins can always re-register.

Development:Contracting

2006-11-03T03:50:30Z

Mblake: /* Your own time */

If you really need some changes made to Moodle and can't do the work yourself you have a few ways to pay for it.

===Moodle.com===

One of the major sources of income for the Moodle project is contracting work done by core Moodle developers via Moodle.com. See http://moodle.com/development for details about getting a quote for work done. Work done this way has a very high chance of being included in Moodle core distribution to benefit the community, and will thus be maintained into the future. Not only that, but you are directly supporting the Moodle project in the best possible way!

===Module maintainers===

If your changes involve improvements to an existing module (eg Hotpot, Quiz, Assignments) etc, then think about contracting that developer directly to work on those features. Many of the maintainers work for free on their modules, and really appreciate the chance to get paid for it. And, again, the code is very likely to be included in future versions of Moodle for all to use and help maintain.

===Your own developers===

Possibly you have your own development team, or have found someone else with the skills to develop PHP code. If you do develop extensions to Moodle this way, please try as hard as possible to implement the changes as a module (Moodle has about 20 different types of plugins). Ask for design advice on moodle.org if you need it, and think about publishing the module on the [http://moodle.org/modules Moodle Modules] listing. As a self-contained module your work has the best chance of remaining compatible with future Moodle releases.

===Your own time===

Even if you can't write code, there's a lot you can do in the community to help get things done. Write a detailed functional specification, test new features, create mock screenshots of the final product, engage the community in discussions about the idea, file feature requests in the [http://tracker.moodle.org/ Moodle Tracker]. Things like this maximise the possibility of finding other volunteers to get that feature written.

Roles and permissions

2006-10-17T06:17:06Z

Mblake: adding content

This page is intended to be a quick overview of the Roles functionality that was introduced in Moodle 1.7.

Previous Moodle versions had predefined, fixed roles. There was no easy way to change what a teacher, or student, for instance, could do. While fixed roles are adequate for many users, others require greater flexibility in regulating how users see and interact with the system.

With Roles, authorised users can create any number of customised roles and assign them to users. From 1.7, an organisation can create multiple roles so that, for instance, students assigned Role A could post to forums, while students assigned Role B are prevented from posting.

Definitions
*A role is an identifier of the user's status in some context. For example, teacher, student and fourm moderator are examples of roles.
*A capability is a description of some particular Moodle feature. Capabilities are associated with roles. For example, mod/forum:replypost is a capability.
*A permission is some value that is assigned for a capability for a particular role. For example, allow or prevent.
*A context is a "space" in the Moodle, such as courses, activity modules, blocks etc.

Capabilities are aggregated and controlled via roles. Stated another way, a role consists of a list of capabilities for different possible actions within Moodle (eg delete discussions, add activities etc). With 1.7 it's now possible to have sophisticated yet flexible levels of control over participants and what they can or can't do.

A smooth upgrade will be provided with 1.7. The existing roles (admin, teacher, student, etc), and the existing capabilities will be automatically retained. This is done by creating default roles at site/course levels, and assigning the current users to these roles accordingly. The default roles will have default capabilities associated with them, mirroring what we have in 1.6. With no modifications, Moodle will operate exactly the same before and after the upgrade.

For more in-depth documentation on Roles, see [https://docs.moodle.org/en/Roles this] link.

==See also==

*[http://moodle.org/mod/forum/discuss.php?d=38788 Roles and Permissions architecture]
*[http://moodle.org/mod/forum/discuss.php?d=56302#256313 An example of admin roles as set in the database]
[[Category:Roles]]

Roles and permissions

2006-10-17T03:34:07Z

Mblake:

This page is intended to be a quick overview of the Roles functionality that was introduced in Moodle 1.7.

Previous Moodle versions had predefined, fixed roles. There was no easy way to change what a teacher, or student, for instance, could do. While fixed roles are adequate for many users, others require greater flexibility in regulating how participants see and interact with the system. With Roles, authorised users can create any number of customised roles and assign them to participants. From 1.7, an organisation can create multiple roles so that, for instance, students assigned Role A could post to forums, while students assigned Role B are prevented from posting.

A capability is a description of some particular Moodle feature. Capabilities are aggregated and controlled via roles. Stated another way, a role consists of a list of permissions for different possible actions within Moodle (eg delete discussions, add activities etc). With 1.7 it's now possible to have sophisticated yet flexible levels of control over participants and what they can or can't do.

A smooth upgrade will be provided with 1.7. The existing roles (admin, teacher, student, etc), and the existing capabilities will be automatically retained. This is done by creating default roles at site/course levels, and assigning the current users to these roles accordingly. The default roles will have default capabilities associated with them, mirroring what we have in 1.6. With no modifications, Moodle will operate exactly the same before and after the upgrade.

For more in-depth documentation on Roles, see [https://docs.moodle.org/en/Roles this] link.

==See also==

*[http://moodle.org/mod/forum/discuss.php?d=38788 Roles and Permissions architecture]
*[http://moodle.org/mod/forum/discuss.php?d=56302#256313 An example of admin roles as set in the database]
[[Category:Roles]]

Tracker

2006-10-03T09:12:49Z

Mblake: /* Tracker fields */

[[Image:Tracker.jpg]]

Bug tracking is an 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].

"Bugs" not only include software problems with current versions of Moodle, but we welcome your requests for new features, improvements, or even constructive criticism of existing features.

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!

==Logging in to 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.
*If you've forgotten your password, go [http://tracker.moodle.org here] and select 'forgot password' which is just under the 'log in' button. Follow the prompts.

== 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.

==Tracker fields==
NB A short explanation appears under each field in Jira.

'''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''' - Required field. This is the Moodle version in which the bug has been found. It is entered by the person logging the bug, and typically only 1 version is specified. Enter your current version when logging an 'improvement', 'task', or 'new feature' as this will help assess the state of the product when the request was made.

'''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 Moodle version the bug was or will be fixed in. This field is normally completed by the developer when the bug has been resolved or by lead developers allocating bugs for a specific release. Normally only one version is specified in this field. It symbolises the ''first'' version of Moodle where the change will be seen.

'''Attachment''' - Optional. Attach a file that will help developers and testers better understand the bug. Maximum attachement size is 512Kb.

'''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. Use this resolution code only when actual changes were made to Moodle code.
:''Won't Fix'' - The problem described is an issue which will never be fixed.
:''Not a bug'' - This issue is not a bug; was logged in error. Use this code if the bug was fixed by another bug report or in some earlier Moodle version.
:''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.

==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 for 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. Obviously testers should have the skills and knowledge to sufficiently test the issue - experience is important - but don't forget there are others in the Moodle community who may be willing to lend a hand. 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.

Testing a bug in Tracker

NB This is the process members of the moodle-testers group should follow to move bugs from 'resolved' to 'closed'.
*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.

*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.
*All resolved bugs should be tested. Bugs with a resolution code of "fixed" represent bugs where code has been updated, and probably represent more of a challenge than bugs with resoluton codes of duplicate, won't fix, and not a bug, and can't reproduce. Please ensure bugs have been closed with a proper resolution code. Unfortunately it's not easy to change a resolution code in Tracker once the bug has been resolved (the only way is to reopen, then re-resolve).
*Don't be afraid to discuss your testing with the developer assigned to the bug. Simply adding a comment should get the attention of the developer as they are notified of all changes.

==More about Tracker functionality==
*You will receive an email when you log a new bug or make updates to bugs you've reported. You'll also receive notification when updates are made to bugs you're watching. Read on for more information on watching a bug.
*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.
*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.

:'''Don't be afraid to link bugs.''' It's very helpful to developers and testers to get a complete picture of a problem.

*'''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.

== 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.

== 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]]

Credits

2006-10-03T02:22:18Z

Mblake:

{{About Moodle}}
==Overall guidance==

[http://dougiamas.com/ Martin Dougiamas] is the founder and manager for the whole Moodle project. Since 2005 there is a [http://moodle.com/hq/ team of people] employed over at [http://moodle.com/ Moodle HQ] in Perth, Australia helping him keep on top of things (or at least within sight of the top!).

The Moodle software package is [[License|Copyright © 1999 onwards, Martin Dougiamas under the GNU GPL]].

==Key Moodle Roles==

* Lead Developer - [[User:Martin Dougiamas|Martin Dougiamas]]
* Knight in Shining Armor - [[User:Eloy Lafuente (stronk7)|Eloy Lafuente (stronk7)]]
* Translation Coordinator - [[User:koen roggemans|Koen Roggemans]]
* Security Officer - Petr Škoda (skodak)
* Documentation Steward - [[User:Helen Foster|Helen Foster]]
* Themes Manager - [[User:UrsHunkler|Urs Hunkler]]

==Main developers==

Endless thanks from all of us goes to those who have contributed substantial and ongoing amounts of time to writing Moodle code and helping it grow. These are people who "get" what developing Moodle is all about and without whom Moodle would be a far lesser thing:

'''Eloy Lafuente (stronk7), Ray Kingdon, Williams Castillo, Petri Asikainen, Henrik Kaipe, Zbigniew Fiedorowicz, Gustav Delius, Thomas Robb, Janne Mikkonen, Jon Papaioannou (pj), Scott Elliott, Shane Elliott, Roberto Pinna (Bobo), Mike Churchward, Petr Škoda (skodak), Penny Leach, Martin Langhoff, Urs Hunkler, Michael Penney, Yu Zhang, Helen Foster'''

==Other contributors and developers==

Many other people have contributed (and are still contributing) with constructive discussions, support, testing and various chunks of code and documentation. This list is long and always changing, but some names include (in the order they were added):

'''Peter C. Taylor, Art Lader, Matt Hope, Tom Murdock, Sébastien Namèche, James Miller, Dustin Rue, Holger Schadeck, Giovanni Tummarello, John Windmueller, Sean Keogh, Mitsuhiro Yoshida, Greg Barnett, Mark Kimes, Mary Hunter, Russell Jungwirth, Przemyslaw Stencel, John "Captain" Eyre, Paula Edmiston, Howard Miller, Claudio Tavares, P. Timothy Ervin, Bob Calder, Ursula Raab, David Delgado, Mad Alex, Gaëtan Frenoy, Bernard Boucher, Bryan Williams, Rob Butner, Koen Roggemans, David Scotson, Torsten Anderson, Eamon Costello, Hannes Gassert, Andrew Walker, Antonio Vicent, Ethem Evlice, Chardelle Busch, Miles Berry, Steve Hyndman, Julian Ridden, Ray Lawrence, Jeffery Watkins, Teemu Sumi, Tony Hursh, Andrea Bicciolo, Ralf Hilgenstock, Stuart Mealor, Dan Stowell, Iñaki Arenaza, Bill Burgos, Jonathon Moore, Daryl Hawes'''

Sorry if we've forgotten to include your name here - the Moodle community is large and active so this list is difficult to maintain! Please make your suggestions on the discussion tab for this page.

Thanks also to everyone of you who have
* donated via the [http://moodle.org/donations Donations page],
* contributed to [http://tracker.moodle.org Tracker],
* participated in the [http://moodle.org/community Moodle Community], and
* used our [http://moodle.com commercial Moodle Partner services]

==Translators==

One of Moodle's strengths is the number of translations it has. Each translation takes many hours of work, as there are over 1000 phrases to translate (plus hundreds of help files!) Many of the languages have more than one contributor, sometimes working together and sometimes working serially.

'''[[Translation credits]]''' lists all these wonderful people.

The Translation Coordinator is Koen Roggemans ''translation AT moodle DOT org''.

==Themes==

Themes give Moodle sites some colour and life. Here are all the themes carried as part of the Moodle 1.5 distribution, along with their authors:

* '''standard''' by Martin Dougiamas
* '''orangewhite''' and '''orangewhitepda''' by Urs Hunkler [http://www.unodo.de/ unodo]
* '''oceanblue''' by Mitsuhiro Yoshida http://mitstek.com
* '''cornflower''' by Thomas Murdock http://sand-paper.org
* '''formal_white''' by Andrea Bicciolo
* '''metal''' by A. Chavan (updated for Moodle 1.5 by Martin Dougiamas)
* '''wood''' by Eloy Lafuente

Urs Hunkler is our Themes Manager, providing support and development.

==Moodle libraries==

Some of Moodle's libraries were written by other people, and are being redistributed as part of Moodle under their respective open source licenses that thankfully allow us to do so. My thanks go out to the authors of all these excellent products - without them Moodle would be missing important functionality. Copyright information for each package is included below:

'''ADOdb''' - lib/adodb

Database abstraction library for MySQL, PostgreSQL, MSSQL, Oracle, Interbase, Foxpro, Access, ADO, Sybase, DB2 and ODBC.

Version: 4.71

Copyright © 2000-2006 John Lim (''jlim AT natsoft DOT com DOT my'')

License: Dual LGPL and BSD-style

URL: http://adodb.sourceforge.net

'''FPDF Class''' - lib/fpdf

Class to generate PDF files

Version: 1.53

Copyright Olivier PLATHEY

License: Freeware

'''Graph Class''' - lib/graphlib.php

Class to draw line, point, bar, and area graphs, including numeric x-axis and double y-axis.

Version: 1.6.3 (with modifications)

Copyright © 2000 Herman Veluwenkamp (''hermanV AT mindless DOT com'')

License: LGPL

'''html2text''' - lib/html2text.php

PHP script to convert HTML into an approximate text equivalent

Version: 1.0 (with modifications)

Copyright © 2002 Mark Wilton-Jones

License: HowToCreate script license with written permission

URL: http://www.howtocreate.co.uk/php/

'''htmlArea''' - lib/editor

Javascript/HTML script to put a GUI editor in textareas on Internet Explorer and Mozilla

Version: 3.0 beta (with modifications)

Copyright © 2002 interactivetools.com, inc.

License: htmlArea License (based on BSD license)

'''IP-Atlas''' - lib/ipatlas

PHP scripts to show the location of an IP address on a map.

Version: 1.0 (with modifications)

Copyright © 2002 Ivan Kozik

License: GNU GPL

URL: http://www.xpenguin.com/ip-atlas.php

'''kses''' - lib/kses.php

HTML/XHTML filter that only allows some elements and attributes

Version: 0.2.2

Copyright © 2002, 2003, 2005 Ulf Harnhammar

License: GNU GPL

URL: http://sourceforge.net/projects/kses

'''mimeTeX''' - filter/tex

Compiled C program to convert TeX into GIFs

Version: 1.4

Copyright © 2002-2004 John Forkosh Associates, Inc

License: GNU GPL

URL: http://www.forkosh.com/mimetex.html

URL: http://moodle.org/download/mimetex

'''mp3player''' - lib/mp3player

Flash movie to play streaming MP3s

Copyright © 2005 Andrew Walker

License: GNU GPL

'''overlibmws''' - lib/overlib.js

Javascript library to enable DHTML popups, floating windows, events etc

Version: July 2004

Copyright © 2002-2004 Foteos Macrides

Copyright © 1998-2004 Erik Bosrup

License: Artistic Open Source License

URL: http://www.macridesweb.com/oltest/

'''PclZip''' - lib/pclzip

Class to create, manage and unpack zip files.

Version: 2.4 RC1

Copyright © 2004 Vincent Blavet (''vincent AT phpconcept DOT net'')

License: GNU GPL

URL: http://www.phpconcept.net

'''PEAR OLE Classes''' - lib/pear

Class to write Excel files

Version: 0.5

Copyright © 2004 Xavier Noguer

License: PHP (plus special exemption for Moodle to make it compatible)

URL: http://pear.php.net/package/OLE

'''PEAR Spreadsheet_Excel_Writer''' - lib/pear

Class to write Excel files

Version: 0.9.0

Copyright © 2004 Xavier Noguer and Mika Tuupola

License: LGPL

URL: http://pear.php.net/package/Spreadsheet_Excel_Writer

'''PEAR HTML_Quickform''' - lib/pear

Class to write forms

Version: 3.2.6

Copyright © 2004 Bertrand Mansion, Adam Daniel, Alexey Borzov

License: PHP (plus special exemption for Moodle to make it compatible)

URL: http://pear.php.net/package/HTML_Quickform

'''PEAR HTML_Quickform_Renderer_Tableless''' - lib/pear

Class to render forms without tables

Version: 0.3.4

Copyright © 2005 Mark Wiesemann

License: PHP (plus special exemption for Moodle to make it compatible)

URL: http://pear.php.net/package/HTML_Quickform_Renderer_Tableless

'''PEAR HTML_QuickForm_DHTMLRulesTableless''' - lib/pear

Class to render validation notices with dhtml

Version: 0.1.2

Copyright © 2005 Alexey Borzov, Adam Daniel, Bertrand Mansion, Justin Patrin, Mark Wiesemann

License: PHP (plus special exemption for Moodle to make it compatible)

URL: http://pear.php.net/package/HTML_QuickForm_DHTMLRulesTableless

'''PEAR HTML_Common''' - lib/pear

Class with many common HTML functions (used by HTML Quickform)

Version: 0.3.4

Copyright © 2004 Adam Daniel, Bertrand Mansion, Klaus Guenther, Alexey Borzov

License: PHP (plus special exemption for Moodle to make it compatible)

URL: http://pear.php.net/package/HTML_Common

'''PHP mailer''' - lib/class.phpmailer.php

Class for sending email using either sendmail, PHP mail(), or SMTP. Methods are based upon the standard AspEmail(tm) classes.

Version 1.73

Copyright © 2003 Brent R. Matzelle (''bmatzelle AT yahoo DOT com'')
License: LGPL

URL: http://phpmailer.sourceforge.net

'''PHP Markdown''' - lib/markdown.php

Functions to convert from the Markdown text format into clean XHTML.

Version: 1.0b9 (with modifications)

Copyright © 2003-2004 , John Gruber

Copyright © 2004 , Michel Fortin

License: LGPL

URL: http://www.michelf.com/projects/php-markdown/

'''Snoopy''' - lib/snoopy

A PHP net client

Version: 1.0

Copyright © 1999-2000 Monte Ohrt (''monte AT ispi DOT net'')
License: GNU LGPL

URL: http://snoopy.sourceforge.com

'''SMTP class''' - lib/class.smtp.php

Class that can be used to connect and communicate with any SMTP server. It implements all the SMTP functions defined in RFC821 except TURN.

Version: 03/26/2001

Copyright © 2001 Chris Ryan (''chris AT greatbridge DOT com'')

'''Typo3 Character Set Class''' - lib/typo3

Class for conversion between charsets and multibyte-savy operations with strings.

CVS version: 1.54

Copyright © 2003-2005 Kasper Skaarhoj

Licencia: GNU GPL

URL: http://typo3.org/

[[Category:Core]]
[[Category:Administrator]]
[[Category:Developer]]

[[es:Créditos]]

Tracker

2006-09-29T08:31:48Z

Mblake: /* Testing bugs */ added more detail

[[Image:Tracker.jpg]]

Bug tracking is an 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].

"Bugs" not only include software problems with current versions of Moodle, but requests for new features, imporvements, 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!

==Logging in to 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.
*If you've forgotten your password, go [http://tracker.moodle.org here] and select 'forgot password' which is just under the 'log in' button. Follow the prompts.

== 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.

==Tracker fields==
NB A short explanation appears under each field in Jira.

'''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 Moodle 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. Enter a version in this field when you are logging an 'improvement', 'task', or 'new feature' as this will help assess the state of the product when the request was made.

'''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 Moodle version the bug was or will be fixed in. This field is normally completed by the developer when the bug has been resolved or by lead developers allocating bugs for a specific release. Normally only one version is specified in this field. It symbolises the ''first'' version of Moodle where the change will be seen.

'''Attachment''' - Optional. Attach a file that will help developers and testers better understand the bug. Maximum attachement size is 512Kb.

'''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. Use this resolution code only when actual changes were made to Moodle code.
:''Won't Fix'' - The problem described is an issue which will never be fixed.
:''Not a bug'' - This issue is not a bug; was logged in error. Use this code if the bug was fixed by another bug report or in some earlier Moodle version.
:''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.

==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 for 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. Obviously testers should have the skills and knowledge to sufficiently test the issue - experience is important - but don't forget there are others in the Moodle community who may be willing to lend a hand. 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.

Testing a bug in Tracker

NB This is the process members of the moodle-testers group should follow to move bugs from 'resolved' to 'closed'.
*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.

*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.
*All resolved bugs should be tested. Bugs with a resolution code of "fixed" represent bugs where code has been updated, and probably represent more of a challenge than bugs with resoluton codes of duplicate, won't fix, and not a bug, and can't reproduce. Please ensure bugs have been closed with a proper resolution code. Unfortunately it's not easy to change a resolution code in Tracker once the bug has been resolved (the only way is to reopen, then re-resolve).
*Don't be afraid to discuss your testing with the developer assigned to the bug. Simply adding a comment should get the attention of the developer as they are notified of all changes.

==More about Tracker functionality==
*You will receive an email when you log a new bug or make updates to bugs you've reported. You'll also receive notification when updates are made to bugs you're watching. Read on for more information on watching a bug.
*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.
*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.

:'''Don't be afraid to link bugs.''' It's very helpful to developers and testers to get a complete picture of a problem.

*'''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.

== 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.

== 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]]

Tracker

2006-09-28T09:28:43Z

Mblake: /* Tracker fields */ clarified resolution code "not a bug"

[[Image:Tracker.jpg]]

Bug tracking is an 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].

"Bugs" not only include software problems with current versions of Moodle, but requests for new features, imporvements, 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!

==Logging in to 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.
*If you've forgotten your password, go [http://tracker.moodle.org here] and select 'forgot password' which is just under the 'log in' button. Follow the prompts.

== 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.

==Tracker fields==
NB A short explanation appears under each field in Jira.

'''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 Moodle 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. Enter a version in this field when you are logging an 'improvement', 'task', or 'new feature' as this will help assess the state of the product when the request was made.

'''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 Moodle version the bug was or will be fixed in. This field is normally completed by the developer when the bug has been resolved or by lead developers allocating bugs for a specific release. Normally only one version is specified in this field. It symbolises the ''first'' version of Moodle where the change will be seen.

'''Attachment''' - Optional. Attach a file that will help developers and testers better understand the bug. Maximum attachement size is 512Kb.

'''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. Use this resolution code only when actual changes were made to Moodle code.
:''Won't Fix'' - The problem described is an issue which will never be fixed.
:''Not a bug'' - This issue is not a bug; was logged in error. Use this code if the bug was fixed by another bug report or in some earlier Moodle version.
:''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.

==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.

Testing a bug in Tracker:
NB This process members of the moodle-testers group should follow to move bugs from 'resolved' to 'closed'.
*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.

==More about Tracker functionality==
*You will receive an email when you log a new bug or make updates to bugs you've reported. You'll also receive notification when updates are made to bugs you're watching. Read on for more information on watching a bug.
*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.
*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.

:'''Don't be afraid to link bugs.''' It's very helpful to developers and testers to get a complete picture of a problem.

*'''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.

== 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.

== 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]]

Tracker

2006-09-27T08:53:05Z

Mblake: /* Tracker fields */

[[Image:Tracker.jpg]]

Bug tracking is an 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].

"Bugs" not only include software problems with current versions of Moodle, but requests for new features, imporvements, 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!

==Logging in to 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.
*If you've forgotten your password, go [http://tracker.moodle.org here] and select 'forgot password' which is just under the 'log in' button. Follow the prompts.

== 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.

==Tracker fields==
NB A short explanation appears under each field in Jira.

'''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 Moodle 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. Enter a version in this field when you are logging an 'improvement', 'task', or 'new feature' as this will help assess the state of the product when the request was made.

'''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 Moodle version the bug was or will be fixed in. This field is normally completed by the developer when the bug has been resolved or by lead developers allocating bugs for a specific release. Normally only one version is specified in this field. It symbolises the ''first'' version of Moodle where the change will be seen.

'''Attachment''' - Optional. Attach a file that will help developers and testers better understand the bug. Maximum attachement size is 512Kb.

'''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.

==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.

Testing a bug in Tracker:
NB This process members of the moodle-testers group should follow to move bugs from 'resolved' to 'closed'.
*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.

==More about Tracker functionality==
*You will receive an email when you log a new bug or make updates to bugs you've reported. You'll also receive notification when updates are made to bugs you're watching. Read on for more information on watching a bug.
*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.
*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.

:'''Don't be afraid to link bugs.''' It's very helpful to developers and testers to get a complete picture of a problem.

*'''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.

== 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.

== 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]]

Tracker

2006-09-27T08:52:32Z

Mblake: /* Tracker fields */ added NB

[[Image:Tracker.jpg]]

Bug tracking is an 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].

"Bugs" not only include software problems with current versions of Moodle, but requests for new features, imporvements, 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!

==Logging in to 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.
*If you've forgotten your password, go [http://tracker.moodle.org here] and select 'forgot password' which is just under the 'log in' button. Follow the prompts.

== 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.

==Tracker fields==
NB A short explanation appears under each field in Jira.
'''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 Moodle 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. Enter a version in this field when you are logging an 'improvement', 'task', or 'new feature' as this will help assess the state of the product when the request was made.

'''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 Moodle version the bug was or will be fixed in. This field is normally completed by the developer when the bug has been resolved or by lead developers allocating bugs for a specific release. Normally only one version is specified in this field. It symbolises the ''first'' version of Moodle where the change will be seen.

'''Attachment''' - Optional. Attach a file that will help developers and testers better understand the bug. Maximum attachement size is 512Kb.

'''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.

==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.

Testing a bug in Tracker:
NB This process members of the moodle-testers group should follow to move bugs from 'resolved' to 'closed'.
*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.

==More about Tracker functionality==
*You will receive an email when you log a new bug or make updates to bugs you've reported. You'll also receive notification when updates are made to bugs you're watching. Read on for more information on watching a bug.
*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.
*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.

:'''Don't be afraid to link bugs.''' It's very helpful to developers and testers to get a complete picture of a problem.

*'''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.

== 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.

== 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]]

Tracker

2006-09-27T08:46:08Z

Mblake: /* Tracker fields */ attachement size

[[Image:Tracker.jpg]]

Bug tracking is an 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].

"Bugs" not only include software problems with current versions of Moodle, but requests for new features, imporvements, 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!

==Logging in to 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.
*If you've forgotten your password, go [http://tracker.moodle.org here] and select 'forgot password' which is just under the 'log in' button. Follow the prompts.

== 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.

==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 Moodle 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. Enter a version in this field when you are logging an 'improvement', 'task', or 'new feature' as this will help assess the state of the product when the request was made.

'''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 Moodle version the bug was or will be fixed in. This field is normally completed by the developer when the bug has been resolved or by lead developers allocating bugs for a specific release. Normally only one version is specified in this field. It symbolises the ''first'' version of Moodle where the change will be seen.

'''Attachment''' - Optional. Attach a file that will help developers and testers better understand the bug. Maximum attachement size is 512Kb.

'''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.

==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.

Testing a bug in Tracker:
NB This process members of the moodle-testers group should follow to move bugs from 'resolved' to 'closed'.
*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.

==More about Tracker functionality==
*You will receive an email when you log a new bug or make updates to bugs you've reported. You'll also receive notification when updates are made to bugs you're watching. Read on for more information on watching a bug.
*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.
*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.

:'''Don't be afraid to link bugs.''' It's very helpful to developers and testers to get a complete picture of a problem.

*'''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.

== 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.

== 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]]

Tracker

2006-09-27T08:04:18Z

Mblake: minor edit

[[Image:Tracker.jpg]]

Bug tracking is an 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].

"Bugs" not only include software problems with current versions of Moodle, but requests for new features, imporvements, 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!

==Logging in to 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.
*If you've forgotten your password, go [http://tracker.moodle.org here] and select 'forgot password' which is just under the 'log in' button. Follow the prompts.

== 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.

==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 Moodle 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. Enter a version in this field when you are logging an 'improvement', 'task', or 'new feature' as this will help assess the state of the product when the request was made.

'''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 Moodle version the bug was or will be fixed in. This field is normally completed by the developer when the bug has been resolved or by lead developers allocating bugs for a specific release. Normally only one version is specified in this field. It symbolises the ''first'' version of Moodle where the change will be seen.

'''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.

==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.

Testing a bug in Tracker:
NB This process members of the moodle-testers group should follow to move bugs from 'resolved' to 'closed'.
*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.

==More about Tracker functionality==
*You will receive an email when you log a new bug or make updates to bugs you've reported. You'll also receive notification when updates are made to bugs you're watching. Read on for more information on watching a bug.
*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.
*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.

:'''Don't be afraid to link bugs.''' It's very helpful to developers and testers to get a complete picture of a problem.

*'''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.

== 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.

== 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]]