Note:

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

Tracker issue labels

From MoodleDocs
Revision as of 14:21, 17 April 2014 by Eloy Lafuente (stronk7) (talk | contribs) (clarification about mdlqa labels. Both are deletable once the work is done.)

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

Note: Labels can only be added by a user with permission to edit an issue i.e. the issue reporter, members of the developers group, or members of certain other groups.

Labels

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. Once all the related MDLQA tests are passing the label can be deleted.
mdlqa_conversion
Used to flag MDL issues that are converting MDLQA issues to behat features. The bug should also be LINKED to the MDLQA test being converted. Useful to know what's going and exclude some issues from manual QA. Once the MDL issue has been closed and the MDLQA has been moved to MDLQA-5249 the label can be deleted.
unit_test_required
Used to flag issues that should have their own unit tests.
acceptance_test_required
Used to flag issues that should be regularly tested using the behat framework (https://docs.moodle.org/dev/Acceptance_testing). Before a major release these issues will be reviewed and new feature files will be added.
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, removing the label once documentation has been written.
dev_docs_required (all | yours)
Used to flag issues that need to be noted in the dev docs. The responsibility of creating/updating Dev docs falls to the developer assigned to each relevant issue. When the issue is resolved, documentation should be created/updated, an appropriate URL should be added to the Documentation link field of the issue and the dev_docs_required label should be removed from the issue.
integration_held
Used to flag issues already sent to integration that, for any cause, have been postponed to next cycles. Used only by integrators when there is some dependency or time-period causing one issue not being immediately integrable. Must be cleaned when the held is over.
security_held
Used to flag security issues that have been reviewed by integrators already but held from integration repository. These issues must be cleared during point releases.
partner
Moodle Partners apply this label to flag issues that are important to their clients. The Moodle HQ dev team takes this label into consideration when setting roadmap and bug fixing priorities.
patch
This label indicates that a solution (patch) has been attached to the issue. However, if you can, it may be better to submit the issue for peer review, rather than using this label. This is useful to component leads and Moodle HQ when deciding what to work on next.
performance
Used to flag any issues that developers think may affect Moodle's performance in some way (positively or negatively)
ui_change
Used to identify issues that affect the interface presented to users. This label will usually be added together with the docs_required label, but the ui_change will remain permanently with the issue, while the docs_required label is removed after docs are created. This label is searched for during the preparation of release notes.
api_change
Used to identify API changes. This label will usually be added together with the dev_docs_required label, but the api_change will remain permanently with the issue, while the dev_docs_required label is removed after docs are created. This label is searched for during the preparation of release notes.
lost_functionality
Used to identify issues describing functionality which was available in an earlier version but which is no longer available in the latest version.
test_server_required
Use this label for QA tests which need special testing infrastructure like (dropbox, alfresco etc.) and can't be tested on http://qa.moodle.net

See also