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
(Clarifying groups and how to join them.)
Line 107: Line 107:
== Tracker groups and permissions ==
== Tracker groups and permissions ==


'''Users''' [groupname=jira-users] - Anyone who creates a tracker account and logs in is a member of the users group. Users can create new issues, comment on issues, watch and vote for issues, link issues, attach files, create sub-tasks, watch bugs, and vote for bugs.
There are a number of groups used to define the potential of users in Tracker. Here are some important ones.
'''Developers''' [groupname=jira-developers] - Developers can edit issues and assign issues to themselves. They are also able to request that their changes be peer reviewed and pushed to integration independent of STABLE sprints.


People wishing to join the jira-developers group should have contributed one or more patches. If you'd like to be added to the developers group in the tracker, please send an email to [mailto:michaeld@moodle.com michaeld@moodle.com] with your tracker username and a link to an issue or issues where you have contributed a patch.
{| 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:timb@moodle.com timb@moodle.com].
|-
| 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. ([[:en:Moodle_security_procedures|Why?]])
| valign=top | This is generally limited to developers at Moodle HQ and Partner organisations. People wishing join the Moodle Security group should email [mailto:michaeld@moodle.com michaeld@moodle.com] 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 push code directly to integration, 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. To be added to the Developers group, please send an email to [mailto:michaeld@moodle.com michaeld@moodle.com] with your tracker username and links to issues where you have contributed patches.
|}


'''Testers''' [groupname=moodle-testers] - Testers can do everything a Developer can do.
Note that you can browse a project without being logged in to Tracker, however you will be unable edit or comment on bugs.
 
'''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.


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

Revision as of 04:52, 30 August 2012

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

Project - Required field. Tracker is a collection of multiple projects. At present these are: 'moodle', 'moodle.org sites' and 'Non-core contributed modules'.

moodle for issues/bugs related to moodle software.
moodle.org sites for issues/bugs related to tracker.moodle.org, docs.moodle.org, demo.moodle.org, download.moodle.org, moodle.org, etc..
Non-core contributed modules for issues/bugs related to contributed plugins.

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. 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 yet concise description of the problem or improvement. Please provide as much detail as possible. The description of bugs should include the steps needed to replicate the bug, including the expected and actual outcomes.

Testing instructions - The steps that a tester should follow to achieve the expected behaviour after the issue has been resolved.

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

Component/s - Required field. Select the area in Moodle which is affected by this bug. Select 'Unknown' if you are unsure.

Database - Optional field. If applicable to the bug, identify the database type.

Environment - Specify the operating system, software platform and/or hardware specifications if applicable to this bug.

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

URL - Optional. If possible, provide a URL address that demonstrates an example of this bug.

Attachment - Optional. Attach a file that will help developers and testers better understand the bug. Maximum attachment size is 512Kb. It is very helpful to attach screenshots of bugs. This really helps developers. Attaching a patch containing a solution is also very helpful.

Workaround - Optional. If there is a way to achieve the desired functionality by other means, please describe it here. 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.

Labels - see Tracker issue labels

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.

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

Priority - Issues are prioritised using one of the following.

Blocker - Blocks development and/or testing work, production could not run (Blocker should not be applied to Improvements or New features)
Critical - Leads to wrong results, 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

The priority of issues may be promoted by HQ developers and component leads as the issue escalates. Others wishing to influence the priority of issues should do so by voting for the issue.

Reporter - The person who logs the bug. This field is automatically filled by Tracker.

Assignee - This is the person who will fix (code) the issue. Tracker automatically assigns issues to Component Leads. 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 working on the issue, although they are likely to in future.

Peer reviewer - This is another person who will test a fix at the code level.

Integrator - This is another person who will integrate the code into the Moodle codebase.

Tester - This is the person who will test the solution at a functional level, according to the test instructions provided.

Pull... fields - These fields are used by developers to link to a code solution in a Git repository. There may be multiple solutions if the problem affects multiple Moodle versions.

Integration date - This indicates when the solution was integrated into the Moodle codebase.

Comment - The comment field is a detailed register of all changes that relate to this bug.

When closing an issue

When closing an issue, the following resolution states can be applied.

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

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 timb@moodle.com.
Moodle Security moodle-security Trusted developers and administrators who need to work on security issues that are hidden from normal users. (Why?) This is generally limited to developers at Moodle HQ and Partner organisations. People wishing join the Moodle Security group should email michaeld@moodle.com 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 push code directly to integration, 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. To be added to the Developers group, please send an email to michaeld@moodle.com with your tracker username and links to issues where you have contributed patches.

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