User talk:Marina Glancy

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:

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? If so, the reporter should be directed to the forums to seek help and the issue should be closed as "Not a bug". Sometimes improvement requests can be phrased as a question, though; 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? Sometimes people mistake the Moodle Tracker as a place to request help about their own Moodle instance, often about logging in. We need to refer the user to their instance administrators and close the issue as "Not a bug".
• Has the issue been reported previously? If so, link to a duplicate issue and close the newly reported issue as a "Duplicate" with no fix version set. Encourage the reporter to search before reporting. If a newer issue has a patch or more voters/watchers, consider closing the older issue. Checking for duplicates first will save you having to check the rest of the issue. See [Tracker tips] for help with effective search of tracker.
• Does the problem affect only unsupported versions? If so, the issue should be closed using "Fixed" (preferred as it sounds better) when the issue is resolved in current versions or "Not a bug" when the issue has disappeared due to changes leading to current versions. See [Releases] to find currenlty supported versions
• Is the problem a language string change? Language string problems can be corrected by contributing a translation or by contacting the language pack maintainer as listed in the Translation credits. English language string typo fixes and suggested improvements can be contributed to the English (fixes) (en_fix) language pack or given the component 'Language' for fixing by the Language component lead. Such issues should be closed in the Tracker using "Deferred".
• Was the problem caused by additional code or 3rd party plugins? If you can identify the plugin, move the issue to the respective component of CONTRIB project. Otherwise comment and close as "Not a bug".
• Can this be implemented as a plugin? And maybe the plugin already exists in the plugins directory. Explanation should be given to the reporter that Moodle provides the framework but does not work on any possible plugin. Add label "addon_candidate" but do not close the issue. This can also apply to the requests to significantly redesign existing plugins and it would be more preferrable to create a new alternative plugin.
• Does the problem seem rational? If not, then the problem may simply be an misunderstanding on the part of the reporter. It might be a problem exclusive to the reporter's server setup. If you can replicate the problem quickly, do so. If you can't replicate the problem, ask the reporter to attempt to replicate the problem on http://demo.moodle.net. If the problem seems persistent but strange, consider asking a developer with experience working in the area to consider the problem and determine if it could be a real problem.
• Can the problem be replicated? If not, or information on the issue is insufficient, ask the reporter to add error messages, screenshots, environment information (OS, web server, browser) and exact replication instructions

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.

Confirming the issue

When you confirm that issue is indeed a bug or a reasonable improvement request that was not reported preivously, make sure that the following is accurate:

• Security level. Security level must be set as soon as possible if the reported bug discloses vulnerability in Moodle that can be exploited to access information without appropriate level, create an attack on the site, embed XSS or forge a request. In some rare cases Improvements may be also marked as security
• Summary. Summary of the issue should clearly describe the problem or improvement area, rephrase such summaries as "Some improvements in xxx" or "Error in Moodle", etc.
• Issue Type. The following issue types are used in Moodle:
  • Bug - represents an actual bug and should be fixed in all supported versions. Very often when reporter expects something to be better than it actually is they call it a bug when it's in fact an improvement.
  • Improvement - improvement to existing functionality. If addressed, will be integrated in the following major release only
  • New feature - completely new feature, also will not be applied to the released versions (unless implemented as a plugin and submitted to plugins directory)
  • Task - usually created by developers themselves and can not be classified as Bug or Improvement, for example, adding automated tests, improving documentation, etc.
  • Epic - created by HQ developers or component leads to collect together issues that represents parts of one project. META issues and sub-tasks should not be used any more
• Priority. Some reporters over-state an issue's priority. Some reporters don't know they can set a priority. Priority is used as one of the criteria when sorting issues in the backlog, so it should reflect the position of this issue comparing to the others. Usually Improvements have Minor or Major priority and Bugs can have any priority up to Blocker.
• Component/s. Listing components correctly is important as they are the primary variable used for searching for issues, also adding a component automatically include the component lead as a watcher. Issue may have several components when needed
• Affects version. This field should include one or more released *and supported* versions of Moodle that are affected by the issue, with the following exceptions:
  • The issue is a bug in code that is present in the Master branch only, in which case the next major version should be used. (The next major version should not be used in conjunction with previous released versions, this won't make sense later.)
  • The issue is a new feature and is unrelated to any existing code in Moodle, in which case the 'Future dev' version should be used.
• Labels.
  • Remove functionality tags that some reporters add as labels, only standard labels or partner-specific labels are used in Moodle
  • Issues with proposed fixes are labelled patch so that they can be found easily and given attention. When this is the case, consider whether moving the issue to the 'Waiting for peer review' state in the workflow might be more appropriate
  • Add addon_candidate label if the functionality can be implemented as a plugin;
  • If you are component lead or HQ developer you may also add triaged label to indicate that triage process is completed

Note that "Fix version" is no longer used during triage. If you are in moodle-triage group, you can use the Triage screen to edit only aforementioned fields, see MDLSITE-3592.

When commenting on the issue give more details on replication, environment or testing. Ask questions, add watchers, modify description if needed. Make everything that will make the issues scope more clear and attract opinions, discussions and patches.

Don't forget to show Gratitude and encouragement. After triaging many issues, it's easy to lose sight of the fact that the reporter has contributed their time and energy to report an issue for the benefit of the community.

It is easy to become defensive of Moodle if reports are seen as criticism (and sometimes reporters may use phrasing that suggests this), however the triagers response must always be one of sincere gratitude.

It is also important to encourage reporters to continue being involved with the issue after it is triaged. We must not give the sense that we are taking the issue ownership away from the reporter. Instead the reporter should be encouraged to discover the cause of the problem and present a solution; this is appropriate in an open-source project. It is amazing that such a challenge can lead to a sense of purpose for the reporters.

Comments templates

Redirecting someone with a support request

Thanks for taking the time to create an issue. However, the problem you describe seems to be specific to your site, since I am unable to reproduce it on http://demo.moodle.net/. Thus I suggest you post asking for help in one of our community forums https://moodle.org/community/.

I'm going to close this issue now. If you find that your problem can indeed be reproduced on http://demo.moodle.net/ or you have a suggestion for an improvement, please create a new issue providing as much detail as you can.

=Refer the user to their instance administrators

You have posted an issue on the Moodle Tracker, which relates to the improvement of Moodle code, not the Moodle site you are using at your institution. I recommend you contact the administrators of your Moodle site.

If it appears that the reporter does not understand a particular feature in Moodle and the documentation is lacking, the label docs_required should be added to the issue.

Duplicate

Thanks for your report.

It seems you're not the only one to have come across this bug, as it's been reported previously - see MDL-xyz. I'm going to close this issue now so we can focus on MDL-xyz. Please watch, vote or comment on MDL-xyz if there is any additional information you can provide.

Issue affects only unsupported versions

Thanks for your report. However, it seems that this problem does not affect current versions of Moodle. Thus, you are recommended to upgrade your installation in order to take advantage of recent fixes and improvements. See https://docs.moodle.org/en/Upgrading for details.

Requesting more information

Thanks for reporting this.

Could you please add more information to your report such as replication instructions, error messages and screenshots. If you are able to suggest a workaround, that would be immediately helpful to others experiencing this problem. If you can determine the cause of the problem or even determine a solution, that will be very valuable.

Translations

Thanks for reporting this.

The problem that you are describing refers to the translation in another language. Language string problems can be corrected by contributing a translation or by contacting the language pack maintainer as listed in the Translation credits. I'm going to close this issue because Moodle does not include translations in the product.

=Language strings

Thanks for reporting this.

Please note that English language string typo fixes and suggested improvements can be contributed to the English (fixes) (en_fix) language pack

Triaging a bug request

Thanks for reporting this.

I've put that on the backlog.

In the meantime feel free to help us work on this issue. If you are able to provide a patch or links to your Git repository branch, please add a patch label so we will spot it.

Triaging an improvement or new feature

Thanks for reporting this.

Adding more detail to your suggestion will make it easier to work on.

If you can propose a code solution, that will help others who may have the same need and will increase the chance of this improvement/feature coming about sooner. If you are able to provide a patch or links to your Git repository branch, please add a patch label so we will spot it. Otherwise, how about posting in a forum on moodle.org and encouraging people to vote, comment and/or come up with a patch.