With the release of Moodle 3.3 just moments away, it is worth taking a look at what is going on at Moodle HQ right now. We have plenty of information to piece together an informed picture thanks to the developer documentation and a couple of talks given by HQ members at past MoodleMoots.
What makes the process interesting is a couple of differences from what an ordinary pipeline may look like. But another—perhaps more interesting—difference is the way that practical feedback, in the form of actual code submitted by the Moodleverse, influences each step.
For a “major release” or “1-point release”, such as Moodle 3.2 last December or the upcoming 3.3, the process generally follows the following phases:
Roadmap Definition: The “Product Owner,” usually “Moodler in Chief” Martin Dougiamas, outlines the potential new features. Dougiamas has always conducted long consultations with the team and the community. MoodleMoots around this time tend to be critical opportunities for Dougiamas to define and contrast his thinking about the immediate future of the Open Source LMS.
Planning and Development: The team splits into “Front End” and “Back End” roles and spends weeks deciding which features to work on and outlining every detail. Both teams take a look at the issues submitted to the Moodle Tracker by users, identifying bugs to fix and solutions to incorporate.
Community Consultations: When larger features or makeovers are in order, HQ leaders produce project pages and gather ideas from the community about what they would like to find and how they would like Moodle to behave.
Sprints: This is where the magic happens. Usually over the course of three weeks, Moodle HQ developers focus on the features already agreed upon. Caffeine goes in; code comes out. During sprints, full-time developers get a “break,” or time to work on their personal projects. The developers use GitHub, an open repository that allows anyone to follow the work almost in real time, as well as the Prototype Moodle site to show their progress.
At the end of the sprint, a “code freeze” is decreed. After this point, no further feature development is allowed until the final release.
QA Testing: A set of tests is developed for the new release, which is conducted by the in-house team and the community. Any bugs detected during this period follow “continuous integration,” which means they are addressed immediately so they are solved in time for the release. Larger features undergo internal Peer Reviews.
Release Candidate Testing: A few days early, a “release candidate” is launched for developers and administrators to try out in real life.
And after six months, a new Moodle is born.
See slides by Dan Poltawski on “How to guarantee your change is integrated into the Moodle core.” (Spoiler alert: You can’t.)