Moodle Feature or Functionality Criteria

Moodle Updates

The purpose of the New Feature Request Form is to provide the Queen's community with a teaching and learning system that has the widest breadth of functionality as is reasonably possible.

Regular updates to Moodle are scheduled three times a year: April, August, and December.

Feature Request Process

 

Please note that we are planning to upgrade to version 2 of Moodle for May, 2012.  New features will not be implemented until this upgrade has been completed.

 

Requests are accepted and regularly reviewed throughout the year.

 

To submit a feature request, please complete the Moodle Change Request form and select "Feature Request" from the "Please select an option" drop-down menu.

Development Philosophy

To retain continuity with versions developed at Moodle.org, it is important for Queen's to maintain the base build. For this reason, customizations will be developed as plug-ins whenever possible. They can then be delivered to one course/space or to the entire campus.

Criteria for Reviewing New Feature Requests

Requests for new features or functionalities will be reviewed and ranked according to the following criteria:

Compatibility - is it a good "fit" with the Queen's environment and mission?

Scalability - does this solve an individual problem or is it scalable and able to serve a broader base?

Supportability - is it reasonably incorporated into the Queen's infrastructure and service offerings?

Sustainability - can the technology be supported in a business-viable manner?

Development

While the review criteria may impact development by ITServices, it is not intended to limit departmental development. Departments are welcome to develop features with very specific requirements that may be unique to a particular discipline. Once a module has been developed, tested and deployed, there are three options for ongoing maintenance:

1. Department maintains in isolation - this could include testing against any patches, upgrades or additional functionality to the base build over time.
2. Departments contribute the code back to the Moodle.org community with the hope that it will be adopted and considered in future versions.
3. Departments contribute the code back to ITServices. In turn, ITServices may reserve the right to attach financial or resource requirements in order to include the module in the maintenance schedule.

Return to Request page.