Note:

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

Tracker issue labels: Difference between revisions

From MoodleDocs
(patch and partner added)
No edit summary
Line 1: Line 1:
Please use the following labels to identify tracker issues requiring further attention:
The Moodle Tracker allows issues to be "labelled" with tags.  This page lists common labels that we use to flag aspects about our MDL issues (bugs and feature requests about Moodle itself).
 
;triaged: Generally this is only set by the [[Bug triage|triaging team]].  It indicated that the issue has been confirmed, with basic fields like "Severity" checked and is now ready for a developer to look at.
;mdlqa:  Used to flag that an issue is a direct result of a Moodle QA test, conducted just before major releases.  The bug should also be LINKED to the original MDLQA test, so that developers/integrators can reset the original MDLQA test (for re-testing) when the MDL issue is fixed.
;qa_test_required: Used to flag issues that should be regularly tested in future MDLQA tests.  QA people will look for issues with this label periodically when creating new tests.
;docs_required:  Used to flag issues that have created a need for documentation work, such as new pages, changes, or even being added to upcoming release notes.  Docs people will look for these issues periodically when working on documentation.
;partner: This issue is very important to a Moodle Partner (and their clients).  The Moodle HQ stable team uses this to give Partner issues some priority attention when choosing what bug to work on.
;patch: This label is usually added during triage and just indicates that a solution (patch) has already been submitted for the issue.  This is useful to component leads and Moodle HQ when deciding what to work on next.


;triaged: When something has been analyzed and adjusted / prepared for  development / printable. Usually done by the [[Bug triage|triaging team]].
;patch: When a suggested bug fix is provided. The development manager will look for them periodically.
;partner: When an issue is of particular importance to clients of a Moodle Partner. The development manager will look for them periodically.
;mdlqa: When one issue is caused by some MDLQA. Devs/testers/integrators should add it, because reset or MDLQA is  needed on close of the MDL.
;mdlqa_required: When one issue is considered to need covering by one MDLQA. QA people will look for them periodically.
;docs_required: When one issue is considered to need work in documentation, such as changes, creation, add to release notes. Docs people will look for them periodically.


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


*[[Tracker]]
*[[Tracker]]

Revision as of 09:27, 17 November 2011

The Moodle Tracker allows issues to be "labelled" with tags. This page lists common labels that we use to flag aspects about our MDL issues (bugs and feature requests about Moodle itself).

triaged
Generally this is only set by the triaging team. It indicated that the issue has been confirmed, with basic fields like "Severity" checked and is now ready for a developer to look at.
mdlqa
Used to flag that an issue is a direct result of a Moodle QA test, conducted just before major releases. The bug should also be LINKED to the original MDLQA test, so that developers/integrators can reset the original MDLQA test (for re-testing) when the MDL issue is fixed.
qa_test_required
Used to flag issues that should be regularly tested in future MDLQA tests. QA people will look for issues with this label periodically when creating new tests.
docs_required
Used to flag issues that have created a need for documentation work, such as new pages, changes, or even being added to upcoming release notes. Docs people will look for these issues periodically when working on documentation.
partner
This issue is very important to a Moodle Partner (and their clients). The Moodle HQ stable team uses this to give Partner issues some priority attention when choosing what bug to work on.
patch
This label is usually added during triage and just indicates that a solution (patch) has already been submitted for the issue. This is useful to component leads and Moodle HQ when deciding what to work on next.


See also