Note:

If you want to create a new page for developers, you should create it on the Moodle Developer Resource site.

Tracker guide: Difference between revisions

From MoodleDocs
(Created page with "{{Moodle community}} <p class="note">'''Please refer to these notes before editing this page.'''</p> Issue tracking is an important part of a ...")
 
(42 intermediate revisions by 6 users not shown)
Line 1: Line 1:
{{Moodle community}}
The [http://tracker.moodle.org/ Moodle Tracker] is our database for recording and managing all Moodle development issues - bugs, improvements and feature requests.
<p class="note">'''Please refer to [[TOC_with_notes#Moodle community|these notes]] before editing this page.'''</p>
Issue tracking is an important part of a continuous quality control process.  It involves the reporting of problems (bugs), [[New feature ideas|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]!
''For an intro guide to the tracker, see [[Tracker introduction]].''


==Basics==
To do anything more than browsing and searching in the tracker, you'll need to [http://tracker.moodle.org/secure/Signup%21default.jspa create an account] and then login.
===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 '<u>forgot password</u>' which is just under the 'log in' button.  Follow the prompts.


=== Summary: How to report a bug, improvement, or new feature request ===
==Integration workflow==
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===
The following diagram illustrates the integration workflow in the tracker and lists the different statuses of an issue.
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:
[[File:Workflow.jpg]]
*[[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, enable [[Debugging|debugging]] 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.
**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:
==Tracker fields==
**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.
===When creating an issue===


Here are some examples of good bug reports: MDL-6030, MDL-5688, MDL-12505
{| class="nicetable"
! Field
! Values
! Notes
|-
| valign=top | '''Project'''
| valign=top |
; Moodle
: For an issue relating to the Moodle codebase
; Moodle Community Sites
: For an issue on tracker.moodle.org, docs.moodle.org, demo.moodle.org, download.moodle.org, moodle.org, etc..
; Non-core contributed modules
: For an issue with a contributed plugin
(There are a few more projects, but these are the main ones.)
| valign=top |
* Tracker is used for multiple projects.
|-
| valign=top | '''Issue Type'''
| valign=top |
; 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, usually apart from coding.
; Sub-Task
: Part of a greater task
|-
| valign=top | '''Summary'''
| valign=top | A brief, concise description of the problem.
| valign=top |
* When the issue is about applying an existing solution to another, usually older, branch (namely "backport"), please use the summary of the existing solution plus its issue number (i.e. "Fix forum alignment (backport of MDL-99999)").
|-
| valign=top | '''Description'''
| valign=top |
A full and complete description of the issue including:
* replication steps,
* the expected result,
* the actual result,
* any error messages shown with [[:en:Debugging|Debugging]] turned on, and
* any other relevant information.
| valign=top |
* Please provide as much detail as possible.
* More detail means an issue will be easier to resolve.
|-
| valign=top | '''Affects Version/s'''
|
* For bugs: the latest ''released'' version in which the bug is found
* For improvements: the latest ''released'' version
* For new features: Use 'Future dev'
|
|-
| valign=top | '''Component/s'''
| valign=top | The area(s) in Moodle which is affected by the issue.
| valign=top |
* Select 'Unknown' if you are unsure.
|-
| valign=top | '''Security Level'''
| valign=top |
; None
: Viewable by everyone, including non-logged-in users
; Could be a security issue
: Viewable by members of the jira-developers group
; Minor security issue
: Viewable by members of the security team only
; Serious security issue
: Viewable by members of the security team only
| valign=top |
* The reporter can view the issue they reported, regardless of the security level set.
* The higher the security level, the fewer people who can view the issue.
* The 'Could be a security issue' should only be used temporarily when the issue is reported. A decision should be made as soon as possible to set another level.
|}


*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].
===When editing an issue===


"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!
Once an issue has been created, the following additional fields are able to be changed/set by editing the issue. Not all users can edit all fields.


Good bug reports contain as much detail as possible and are specific. Don't generalise or leap to conclusions.
{| class="nicetable"
! Field
! Values
! Notes
|-
| valign=top | '''Fixed Version/s'''
| valign=top |
* Prior to integration, this will be set to a backlog (a queue of development work), for example STABLE Backlog, Dev Sprint 2.
* After integration, this will be set to the Moodle version the bug was fixed in, for example 2.4.1.
|
* This is usually set during triage, or later by a developer or integrator.
* If you resolve the bug as anything but "Fixed" (Cannot Reproduce, Won't Fix, etc.) leave Fix Version/s blank.
* Fix version/s are used to automatically build release notes (see the tabs on http://tracker.moodle.org/browse/MDL).
|-
| valign=top | '''Priority'''
| valign=top |
; Blocker
: Blocks development and/or testing, prevents Moodle from running
: Applicable to bugs only
; Critical
: Crashes server, loss of data, severe memory leak
; Major
: Major loss of function, incorrect output
; Minor
: Minor loss of function where workaround is possible
; Trivial
: Cosmetic problem like misspelt words or misaligned text
| valign=top |
* When it is reported, the priority level represents the severity of an bug.
* After being reported, the priority may be promoted by HQ developers and component leads as an issue escalates.
* Other users wishing to influence the priority of issues should do so by voting for the issue.
* The priority of new features and improvements should generally remain at the default (Minor) level.
|-
| valign=top | '''Reporter'''
| valign=top | The person who logs the bug.  This field is automatically filled by Tracker.
|
|-
| valign=top | '''Assignee'''
| valign=top | The person who will fix the issue. Prior to May 2013, developers were [[Changes to issue assignment|automatically assigned]]. Currently, the assignee should be set when there is a definite intention to complete the issue.
|
* Developers or QA Testers can reassign issues.
* Please note that even though a person may be assigned to an issue, this does not mean they are currently working on the issue, although they are likely to in future.
|-
| valign=top | '''Peer reviewer'''
| valign=top | The person who will check the fix at the code level.
|
|-
| valign=top | '''Integrator'''
| valign=top | The person who will integrate the code into the Moodle codebase.
|
|-
| valign=top | '''Tester'''
| valign=top | The person who will test the solution at a functional level, according to the test instructions provided.
|
|-
| valign=top | '''Environment'''
| valign=top | The operating system, server and/or browser specifications if applicable to this bug.
|
* Note that the database is specified separately in the database field below.
|-
| valign=top | '''Database'''
| valign=top | If applicable to the bug, identify the database type.
|
|-
| valign=top | '''Testing instructions'''
| valign=top | The steps that a tester should follow to achieve the expected behaviour after the issue has been resolved.
| valign=top |
* This may be different to the replication steps reported in the description.
* These instructions are written by the developer working on the issue.
|-
| valign=top | '''Workaround'''
| valign=top | A way to achieve the desired functionality by other means.
| valign=top |
* This will be very useful to other Moodle users who have the same problem, until the issue is resolved.
* If the issue can be resolved by a simple code change, say one line, then you can give that as a workaround, although patches and Git branches are preferred.
|-
| '''Attachment'''
| valign=top | Patch files, Screenshots, example backups or other related files
| valign=top |
* Attaching a file will help developers and testers better understand the bug.
* Maximum attachment size is 512Kb.
|-
| valign=top | '''URL'''
| valign=top | If possible, provide a URL address that demonstrates an example of this bug.
|
|-
| valign=top | '''Epic Name'''
| valign=top | A short name given to an issue of type Epic so that linked issues can be grouped by this name. It should only be a few words at most.
| valign=top | Only applies to issues of type Epic.
|-
| valign=top | '''Epic Link'''
| valign=top | A link to an Epic issue. This can be added by providing the issue ID or Epic name. It is a way of organising related issues as part of a project.
| valign=top | Only applies to issues that need to be collected together for a project.
|-
| valign=top | '''Labels'''
| valign=top | See [[Tracker issue labels]]
|
* Labels should be specific values used in filters and searches.
* This is not a field for including generic keywords.
|-
| valign=top | '''Pull...'''
| valign=top | Links to a code solution in a Git repository.
|
* These fields are used by developers.
* There may be multiple solutions if the problem affects multiple Moodle versions.
|-
| valign=top | '''Documentation link'''
| valign=top | URL of related documentation.
| valign=top |
* When changes require documentation to be updated, this field should be filled.
|-
| valign=top | '''Comment'''
| valign=top |
* Notes made by all interested parties.
* A detailed register of all changes that relate to this bug.
|
|}


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.
===When closing an issue===


Consider a bug report which says that the descriptions for the specific RSS feed XYZ@abc shows unrecognisable characters rather than expected characters.
{| class="nicetable"
! Field
! Values
! Notes
|-
| valign=top | '''Resolution'''
| valign=top |
; Fixed
: Bug has been fixed; a code change has been integrated into Moodle code.
; Won't Fix
: The problem described is an issue which will never be fixed. Specific reasons should be given.
; Not a bug
: This issue is not a bug. The issue may have been 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 was needed to understand this bug, but it was not provided.
; Can't Reproduce
: Attempts at reproduce the issue failed. If more information appears later, please open a new issue.
; Deferred
: The resolution to this bug will be deferred to a later release or to a fix in a third-party plugin used in Moodle.
| valign=top |
* This field is only displayed when resolving or closing a bug.
|}


==Tracker process==
== Tracker groups and permissions ==
===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.
There are a number of groups used to define the potential of users in Tracker. Here are some important ones.


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.
{| class="nicetable"
! Name
! Jira group
! Potential
! How to become one
|-
| valign=top | '''Users'''
| valign=top | jira-users
| valign=top | Users can create new issues, comment on issues, vote for issues, link issues, attach files, create sub-tasks and watch issues.
| valign=top | Anyone who creates a tracker account becomes a member of the Users group.
|-
| valign=top | '''Testers'''
| valign=top | moodle-testers
| valign=top | Testers are able to work on (pass and fail) QA tests prior to a major Moodle release.
| valign=top | People wishing join the Testers group and help with [[QA testing]] should email [mailto:helen@moodle.org helen@moodle.org].
|-
| valign=top | '''Moodle Security'''
| valign=top | moodle-security
| valign=top | Trusted developers and administrators who need to work on security issues that are hidden from normal users. (See [[Moodle security procedures]].)
| valign=top | This is generally limited to developers at Moodle HQ and Partner organisations. People wishing join the Moodle Security group should email [mailto:security@moodle.org security@moodle.org] with the reasons for your request.
|-
| valign=top | '''Developers'''
| valign=top | jira-developers
| valign=top | Developers can edit issues and assign issues to themselves. They are also able to request peer reviews from HQ staff and component leads. They cannot submit code directly for integration review, but an HQ staff member or component lead can do this after a satisfactory peer review. (See [[Process]].)
| valign=top | People wishing to join the Developers group should be able to demonstrate a history of contributing patches to issues.


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.
When a developer's first patch is integrated, tested and the issue is closed, they are added to the group and set as issue assignee.


'''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.
If that doesn't happen automatically, please send an email to [mailto:integration@moodle.com integration@moodle.com] with your tracker username and links to issues where you have contributed patches.
|-
| valign=top | '''Integration requesters'''
| valign=top | pull-requesters
| valign=top | Developers can send issues for integration review. (See [[Process]].)
| valign=top | This role is reserved for Moodle HQ developers and component leads.
|}


 
Note that you can browse a project without being logged in to Tracker, however you will be unable edit or comment on 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===
 
<p class="note">(This section should be reviewed.)</p>
 
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 resolution 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===
 
'''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 one 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''' - The higher the security level, the fewer people who can view the issue.
:''None'' - Viewable by everyone, including non-logged-in users
:''Could be a security issue'' - Viewable by all logged-in users
:''Minor security issue'' - Viewable by developers and testers only
:''Serious security issue'' - Viewable by members of the security team only
 
'''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.
 
 
<p class="note">
'''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.
</p>
 
=== How to see what code was changed  ===
If exists any code change related to a tracker issue, you can see what code was changed by clicking on version control tab. The codes are listed with the MODIFY label and the changes can be seen clicking on the +- signs wich indicate how many lines have changed.   


==See also==
==See also==


*[[Tracker introduction]] - less scary version of this page for new users.
*[[Process]]
*[[Bug triage]]
*[[Bug triage]]
*[[Weekly Code Review]]
*[[Tracker issue labels]]
*[http://www.atlassian.com/software/jira/ Jira] Tracker is a slightly customised version of Atlassian's product 
*[[Testing of integrated issues]]
*Using Moodle [http://moodle.org/mod/forum/discuss.php?d=43952 How to manipulate Moodle developers] forum discussion
*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]
*Wikipedia [http://en.wikipedia.org/wiki/Software_bug Definition of a bug]


[[Category:Developer tools]]
[[Category:Tracker]]
[[Category:Quality Assurance]]
[[Category:Quality Assurance]]

Revision as of 10:21, 14 October 2020

The Moodle Tracker is our database for recording and managing all Moodle development issues - bugs, improvements and feature requests.

For an intro guide to the tracker, see Tracker introduction.

To do anything more than browsing and searching in the tracker, you'll need to create an account and then login.

Integration workflow

The following diagram illustrates the integration workflow in the tracker and lists the different statuses of an issue.

Workflow.jpg

Tracker fields

When creating an issue

Field Values Notes
Project
Moodle
For an issue relating to the Moodle codebase
Moodle Community Sites
For an issue on tracker.moodle.org, docs.moodle.org, demo.moodle.org, download.moodle.org, moodle.org, etc..
Non-core contributed modules
For an issue with a contributed plugin

(There are a few more projects, but these are the main ones.)

  • Tracker is used for multiple projects.
Issue Type
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, usually apart from coding.
Sub-Task
Part of a greater task
Summary A brief, concise description of the problem.
  • When the issue is about applying an existing solution to another, usually older, branch (namely "backport"), please use the summary of the existing solution plus its issue number (i.e. "Fix forum alignment (backport of MDL-99999)").
Description

A full and complete description of the issue including:

  • replication steps,
  • the expected result,
  • the actual result,
  • any error messages shown with Debugging turned on, and
  • any other relevant information.
  • Please provide as much detail as possible.
  • More detail means an issue will be easier to resolve.
Affects Version/s
  • For bugs: the latest released version in which the bug is found
  • For improvements: the latest released version
  • For new features: Use 'Future dev'
Component/s The area(s) in Moodle which is affected by the issue.
  • Select 'Unknown' if you are unsure.
Security Level
None
Viewable by everyone, including non-logged-in users
Could be a security issue
Viewable by members of the jira-developers group
Minor security issue
Viewable by members of the security team only
Serious security issue
Viewable by members of the security team only
  • The reporter can view the issue they reported, regardless of the security level set.
  • The higher the security level, the fewer people who can view the issue.
  • The 'Could be a security issue' should only be used temporarily when the issue is reported. A decision should be made as soon as possible to set another level.

When editing an issue

Once an issue has been created, the following additional fields are able to be changed/set by editing the issue. Not all users can edit all fields.

Field Values Notes
Fixed Version/s
  • Prior to integration, this will be set to a backlog (a queue of development work), for example STABLE Backlog, Dev Sprint 2.
  • After integration, this will be set to the Moodle version the bug was fixed in, for example 2.4.1.
  • This is usually set during triage, or later by a developer or integrator.
  • If you resolve the bug as anything but "Fixed" (Cannot Reproduce, Won't Fix, etc.) leave Fix Version/s blank.
  • Fix version/s are used to automatically build release notes (see the tabs on http://tracker.moodle.org/browse/MDL).
Priority
Blocker
Blocks development and/or testing, prevents Moodle from running
Applicable to bugs only
Critical
Crashes server, loss of data, severe memory leak
Major
Major loss of function, incorrect output
Minor
Minor loss of function where workaround is possible
Trivial
Cosmetic problem like misspelt words or misaligned text
  • When it is reported, the priority level represents the severity of an bug.
  • After being reported, the priority may be promoted by HQ developers and component leads as an issue escalates.
  • Other users wishing to influence the priority of issues should do so by voting for the issue.
  • The priority of new features and improvements should generally remain at the default (Minor) level.
Reporter The person who logs the bug. This field is automatically filled by Tracker.
Assignee The person who will fix the issue. Prior to May 2013, developers were automatically assigned. Currently, the assignee should be set when there is a definite intention to complete the issue.
  • Developers or QA Testers can reassign issues.
  • Please note that even though a person may be assigned to an issue, this does not mean they are currently working on the issue, although they are likely to in future.
Peer reviewer The person who will check the fix at the code level.
Integrator The person who will integrate the code into the Moodle codebase.
Tester The person who will test the solution at a functional level, according to the test instructions provided.
Environment The operating system, server and/or browser specifications if applicable to this bug.
  • Note that the database is specified separately in the database field below.
Database If applicable to the bug, identify the database type.
Testing instructions The steps that a tester should follow to achieve the expected behaviour after the issue has been resolved.
  • This may be different to the replication steps reported in the description.
  • These instructions are written by the developer working on the issue.
Workaround A way to achieve the desired functionality by other means.
  • This will be very useful to other Moodle users who have the same problem, until the issue is resolved.
  • If the issue can be resolved by a simple code change, say one line, then you can give that as a workaround, although patches and Git branches are preferred.
Attachment Patch files, Screenshots, example backups or other related files
  • Attaching a file will help developers and testers better understand the bug.
  • Maximum attachment size is 512Kb.
URL If possible, provide a URL address that demonstrates an example of this bug.
Epic Name A short name given to an issue of type Epic so that linked issues can be grouped by this name. It should only be a few words at most. Only applies to issues of type Epic.
Epic Link A link to an Epic issue. This can be added by providing the issue ID or Epic name. It is a way of organising related issues as part of a project. Only applies to issues that need to be collected together for a project.
Labels See Tracker issue labels
  • Labels should be specific values used in filters and searches.
  • This is not a field for including generic keywords.
Pull... Links to a code solution in a Git repository.
  • These fields are used by developers.
  • There may be multiple solutions if the problem affects multiple Moodle versions.
Documentation link URL of related documentation.
  • When changes require documentation to be updated, this field should be filled.
Comment
  • Notes made by all interested parties.
  • A detailed register of all changes that relate to this bug.

When closing an issue

Field Values Notes
Resolution
Fixed
Bug has been fixed; a code change has been integrated into Moodle code.
Won't Fix
The problem described is an issue which will never be fixed. Specific reasons should be given.
Not a bug
This issue is not a bug. The issue may have been 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 was needed to understand this bug, but it was not provided.
Can't Reproduce
Attempts at reproduce the issue failed. If more information appears later, please open a new issue.
Deferred
The resolution to this bug will be deferred to a later release or to a fix in a third-party plugin used in Moodle.
  • This field is only displayed when resolving or closing a bug.

Tracker groups and permissions

There are a number of groups used to define the potential of users in Tracker. Here are some important ones.

Name Jira group Potential How to become one
Users jira-users Users can create new issues, comment on issues, vote for issues, link issues, attach files, create sub-tasks and watch issues. Anyone who creates a tracker account becomes a member of the Users group.
Testers moodle-testers Testers are able to work on (pass and fail) QA tests prior to a major Moodle release. People wishing join the Testers group and help with QA testing should email helen@moodle.org.
Moodle Security moodle-security Trusted developers and administrators who need to work on security issues that are hidden from normal users. (See Moodle security procedures.) This is generally limited to developers at Moodle HQ and Partner organisations. People wishing join the Moodle Security group should email security@moodle.org with the reasons for your request.
Developers jira-developers Developers can edit issues and assign issues to themselves. They are also able to request peer reviews from HQ staff and component leads. They cannot submit code directly for integration review, but an HQ staff member or component lead can do this after a satisfactory peer review. (See Process.) People wishing to join the Developers group should be able to demonstrate a history of contributing patches to issues.

When a developer's first patch is integrated, tested and the issue is closed, they are added to the group and set as issue assignee.

If that doesn't happen automatically, please send an email to integration@moodle.com with your tracker username and links to issues where you have contributed patches.

Integration requesters pull-requesters Developers can send issues for integration review. (See Process.) This role is reserved for Moodle HQ developers and component leads.

Note that you can browse a project without being logged in to Tracker, however you will be unable edit or comment on bugs.

See also

Retrieved from "https://docs.moodle.org/dev/index.php?title=Tracker_guide&oldid=57932"
Powered by MediaWiki