Note:

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

User talk:Marina Glancy

From MoodleDocs
Revision as of 08:14, 13 January 2015 by Marina Glancy (talk | contribs)

Moodle features / hooks

Hooks spec

I attempt to create all options how courses and categories lists are displayed in Moodle: Courses and Categories Lists Overview in 2.4

Spec for refactoring View all courses

Developers quick ref Moodle Developers Quick Reference

Draft of rewriting the triage page:

alt Triage image

Triage is medical term referring to the process of prioritising patients based on the severity of their condition so as to maximise benefit (help as many as possible) when resources are limited.

Bug triage is a process where tracker issues are screened and prioritised. Triage should help ensure we appropriately manage all reported issues - bugs as well as improvements and feature requests.

Triage initially happens shortly after the issue was reported but it can be repeated later if the initial assumptions were wrong, issue was resolved otherwise, affected versions need updating or other there are other reasons to review the issue.

Who can do the triage

Anybody can do triage in form of correcting the components and/or affected versions, linking to related issues, and of course commenting asking for clarification, confirming bug, redirecting to forum, etc. Users in jira-developers and moodle-triage groups can edit any issue, jira-users can comment on any issue or edit issues they reported. Please see MDLSITE-3592 if you are not a developer but would like to help with triage process.

Adding "triaged" label and placing the issue on the backlog should only be done by component lead or HQ developer. At the same time other users can remove "triaged" label from the old issues or replace it with "triaging_in_progress" if they want to request an additional triage.

The triage process

Initial screening

First of all, identify the issues that should be closed or placed under investigation. Ask the following questions:

  • Is the issue a request for support/help?. Such issues need to be redirected to forum. Although sometimes improvement requests can be phrased as a question; if this is the case, ask the reporter to reword the description to describe an improvement.
  • Have the reporter mistaken the Moodle Tracker with their own support desk?
  • Has the issue been reported previously? - see [Tracker tips] for help with effective search of tracker
  • Does the problem affect only unsupported versions? - this may be issues that were recently resolved or functionality that was completely re-written in the currently supported versions making old bug not applicable. See [Releases] for the supported versions
  • Is the problem a language string change?
  • Was the problem caused by additional code or 3rd party plugins?
  • Does the problem seem rational?
  • Can the problem be replicated?

As a result of initial screening up to 20% of new issues may be closed. When closing the issues make sure to set the correct resolution and write a polite comment with explanation, refer to the templates below. If you have doubts, ask the questions and always add label "triaging_in_progress". Subscribe to the filter [My old issues in triage] and you will receive notifications after 30 days of inactivity on such issues. Very often the reporter never follows up on their own issues and this is a good way to find such issues and ping reporter again or make a final decision about closing.