UCL Moodle Customisation process outline

The purpose of this document is to provide an overview of the procedure for the addition of new functionality to Moodle outside of the Moodle core code released by Moodle.org. These additions include: -

3^rd Party Plugins (Opensource)
3^rd Party Plugins (Commercial)
Learning Tools Interoperability (LTI) integrations with 3^rd party tools (commercial)
UCL developed Moodle plugins
UCL developed Integrations with other UCL systems (e.g. SITS, CMIS etc)

If you identify any additional functionality that you would like to see added to UCL Moodle please email digi-ed@ucl.ac.uk with the title Plugin Request.

3rd Party Plugins with a Purchase and or License Cost

Please note that any requests for plugins/LTI’s that have an associated purchase/licensing cost must be accompanied by a sustainable funding stream, agreed with ISD.

An overview of our process for Customisation

Adding functionality to Moodle can be highly complex and there are several processes that we (ISD) have to follow to ensure that any addition to Moodle meets strict criteria. These main criteria are

Initial Review – The Moodle Service Owner and Moodle Operation Manager will conduct a brief high-level review of the request and communicate back to the requester for any additional information if required. The initial high-level review of the customisation may result in the request being declined; however, this will be communicated with the requester.

Prioritisation – All requests after initial review will be prioritised against the existing Backlog of work by the Moodle Service Owner and the Moodle Operational Manager to assign an initial priority. They are then placed in the backlog queue based upon that priority and are actioned when resource becomes available. The customisation will be added to the Moodle roadmap listed here where its status will be updated as it passes thought our workflows.

Technical Review – The Learning Application team and Moodle Operations Manager will review the request from technical aspects including but not limited to:-

Code Review
Trusted maintainer review
Confirm that product is actively maintained
Automated testing
Data Transfer Protection
Review any known issues
Load testing
Review any third-party code requirements
Accessibility test
Mobile device review
Technical Documentation review and creation if required
Review for Data Protection Impact Assessment requirements

If at any stage during the technical review an issue is encountered with the customisation the Moodle Service Owner and Moodle Operations will decide if that issue can resolved or if the customisation has to be declined. Information will be feedback directly to the user and the Moodle Roadmap entry for the customisation will be updated.

Functional Review – Once the Learning Application team have completed the technical review the customisation will be installed and added on a Moodle instance for a functional review by the Digital Education teams. This review will include but not be limited to: -

Ensuring the customisation provides the intended user journey and outcomes
Feedback any issues to the technical team that are encountered during the intended user journey

If functional testing completes without issue, then the Moodle Service Owner and the Service Operations Manager will schedule its release into Moodle.

Release - This release of the customisation will be agreed by the Service Operations Manager and the Service Operations Manager dependant on the following: -

Creation of end user documentation and support documentation
Specific resource effort required by the customisation

Next available release date