TRU has implemented automatic course shell creation and student enrollment for spring/summer semesters. We are assessing and revising code, and will be creating course shells for Fall 2020 as soon as possible.
BigBlueButton system upgrades have improved performance and functionality. We have also introduced a stand-alone interface which allows any TRU faculty, staff or students to host their own videoconferences: https://bigblue1.tru.ca/
The BCNET Moodle Shared Service runs Moodle for 10 institutions in total.
Moodle 3.5.x is in use at: College of the Rockies, College of New Caledonia, Emily Carr University of Art and Design, Kwantlen Polytechnic University, NVIT, Okanagan College, Thompson Rivers University, Trinity Western University, University of Northern BC.
Moodle 3.6.x is in use at: Vancouver Community College (they just came onboard BCNet in February, and were already on 3.6).
Nobody is running Moodle 3.7. Moodle 3.8 has been deployed to development servers at COTR and TRU.
COTR, KPU and TRU all run Kaltura integrated with Moodle. COTR has been testing Kaltura with Moodle 3.8 and has reported failures (though a new plugin for Kalture/Moodle 3.8 has just been released).
Moodle 3.9 (the next Long Term Support release) is scheduled for release on June 8th. Though generally, it is preferred to allow time for bug fixes and other stability enhancements that emerge after a major release.
Regarding plugins: not all plugins are created (or updated) equally. Many are poorly supported, and build in dependencies that can be highly challenging over time.
To cite one example, Bootstrap Elements was abandoned in 2018. It looks like someone released one final update for it in 2019 and it only purports to support up to Moodle 3.6. Going to Moodle 3.8 will mean either updating every Open Learning course to remove the Bootstra Elements content, or “forking” our own copy of Bootstrap Elements, updating it to work with 3.8, and maintaining it going forward. If we don’t do this, many OL courses will break. There are 76936 activities in courses across multiple programs that make use of Bootstrap Elements. In addition to OL, courses in NRS, CS, SOBE, MBA, Tourism, Arts, Social Work activities would see their materials/activities break in some way if an incompatibility were introduced.
Other plugin/code dependencies:
- The auto enrollment and course category code must be upgraded and tested with 3.8+.
- The grade book photos plugin must be upgraded and tested with 3.8+.
- The custom “mootools” utilities (used to deploy OL courses) must be upgraded to work with 3.8+.
- All other plugins, blocks and modules on the server will also need to be confirmed to work with 3.8+.
When unsupported code or plugins are run in a large, highly diverse heavily-used course environment, we invite course malfunctions, security breaches, loss of data, and corruption of data.
We welcome plugin queries, and take them seriously. In many cases, the plugin is either poorly documented, not updated, or raises other issues. In other instances, testing on a dev server (which is a significant investment of staff time) raises other issues, such as with Office Grader.
- Scheduler — installed for more than a year.
- Quickmail: no updates in two years, no compatibility after 3.5
- Formulas Question Type: no updates in 18 months, no compatibility after 3.6
- Word File Import: this is maintained, and well adopted. We can assess. In the past, MS plugins have been difficult to integrate with our environment, a huge drain on CPU, etc…
- Office 365: this one is on our roadmap, as is a plugin for Microsoft Teams. These plugins require integration with Microsoft Azure and uploading/syncronization of user information with Azure. This is more involved than a simple “flip the switch”. We’re evaluating them, but it will require significant time.
- Turnitin: and plagiarism software is primarily a matter of academic policy, as well as privacy policies. The workflows specified on UBC and SFU pages are quite labyrinthine. See also Brenna Clarke Gray on data, algorithms, and a case study of suck.
The TRU user community has also made it clear that functional upgrades introduce confusion and learning curves. We have learned not to do them during active semesters, which greatly constrains our ability to schedule upgrades and changes. The recent tight time-frame for automatic course creation/student enrollment meant curtailing testing, and introduced bugs which we are still working to fix.
We are not standing still:
We have scoped out an ambitious set of upgrades, but resourcing and time is always a challenge. At present, the Moodle Support team is fully taxed answering help tickets (which we have been doing, promptly) and staffing drop-ins and workshops (which we staff every day). We have identified several months worth of development work to meet expressed needs, but have huge challenges to free up staff time to address them. We very much wish to find the time to address long-desired goals, such as a new Moodle cluster, a BigBlueButton cluster, and a Badgr server.
There is no date set for the upgrade to 3.8/3.9 as we haven’t begun formal testing. (It is on a Sandbox server.) That was originally going to be the plan for late March/April, but the pandemic intervened. Next week we plan to upgrade the sandbox and development environments to begin proper testing of Moodle 3.8.
Not-so-humble brag: since moving to “alternate modes of delivery”, TRU has had 100% Moodle uptime, no reported issues with system stability or functionality. This is despite our Moodle instance encountering loads far in excess of anything we’ve experienced. At least part of this reliability is due to TRU’s practice of running long-term support release versions of Moodle, and prioritizing stability and support for plugins.