Tracker guide: Difference between revisions
(Adding some formatting) |
|||
(15 intermediate revisions by 5 users not shown) | |||
Line 1: | Line 1: | ||
The [http://tracker.moodle.org/ Moodle Tracker] is our database for recording and managing all Moodle development issues - bugs, improvements and feature requests. | The [http://tracker.moodle.org/ Moodle Tracker] is our database for recording and managing all Moodle development issues - bugs, improvements and feature requests. | ||
Line 57: | Line 56: | ||
* the expected result, | * the expected result, | ||
* the actual result, | * the actual result, | ||
* any error messages shown with [[:en:Debugging]] turned on, and | * any error messages shown with [[:en:Debugging|Debugging]] turned on, and | ||
* any other relevant information. | * any other relevant information. | ||
| valign=top | | | valign=top | | ||
Line 80: | Line 79: | ||
: Viewable by everyone, including non-logged-in users | : Viewable by everyone, including non-logged-in users | ||
; Could be a security issue | ; Could be a security issue | ||
: Viewable by | : Viewable by members of the jira-developers group | ||
; Minor security issue | ; Minor security issue | ||
: Viewable by | : Viewable by members of the security team only | ||
; Serious security issue | ; Serious security issue | ||
: Viewable by members of the security team only | : Viewable by members of the security team only | ||
| valign=top | | | 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 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. | * 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. | ||
Line 132: | Line 132: | ||
|- | |- | ||
| valign=top | '''Assignee''' | | valign=top | '''Assignee''' | ||
| valign=top | The person who will fix the issue. | | 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. | * Developers or QA Testers can reassign issues. | ||
Line 179: | Line 179: | ||
| valign=top | If possible, provide a URL address that demonstrates an example of this bug. | | 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 | '''Labels''' | ||
Line 249: | Line 257: | ||
| valign=top | moodle-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 | 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: | | 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 | 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. ([[ | | 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: | | 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 | '''Developers''' | ||
| valign=top | jira-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 | 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. | | valign=top | 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 [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. | |||
|} | |} | ||
Line 266: | Line 283: | ||
==See also== | ==See also== | ||
*[[Tracker introduction]] - less scary version of this page for new users. | |||
*[[Process]] | *[[Process]] | ||
*[[Bug triage]] | *[[Bug triage]] | ||
*[[Tracker issue labels]] | |||
*[[Testing of integrated issues]] | *[[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 | ||
Line 273: | Line 292: | ||
[[Category:Tracker]] | [[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.
Tracker fields
When creating an issue
Field | Values | Notes |
---|---|---|
Project |
(There are a few more projects, but these are the main ones.) |
|
Issue Type |
| |
Summary | A brief, concise description of the problem. |
|
Description |
A full and complete description of the issue including:
|
|
Affects Version/s |
|
|
Component/s | The area(s) in Moodle which is affected by the issue. |
|
Security 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 |
|
|
Priority |
|
|
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. |
|
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. |
|
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. |
|
Workaround | A way to achieve the desired functionality by other means. |
|
Attachment | Patch files, Screenshots, example backups or other related files |
|
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 |
|
Pull... | Links to a code solution in a Git repository. |
|
Documentation link | URL of related documentation. |
|
Comment |
|
When closing an issue
Field | Values | Notes |
---|---|---|
Resolution |
|
|
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
- Tracker introduction - less scary version of this page for new users.
- Process
- Bug triage
- Tracker issue labels
- Testing of integrated issues
- Using Moodle How to manipulate Moodle developers forum discussion
- Wikipedia Definition of a bug