The Journey Of A Moodle Bug: Dan Powtalski At #mootUS16

2138
The Journey Of A Moodle Bug. Dan Powtalski At #mootUS16

Did you ever stop to wonder how a bug is fixed? Senior Moodle HQ Developer and Integrator Dan Poltawski gave us a peek, during his MoodleMoot US 2016 talk. Dan made his presentation on the 4pm Technical Pico of the Second Day.

WIRIS

Check out the slides below.

In “The Lifecycle Of A Moodle Bug“, Dan shows us the rigor behind fixing issues in Moodle since users report them to the Tracker. The Moodle Tracker is the heart of the operation. It all begins when a user hits “Create” on the top menu.

A reported issue receives a MDL tracking code. Other users can vote for the issue to be fixed sooner. Users can also follow the fixing process or mark it as favorite.

When developers get involved, their first step is triaging it to see possible duplicates and submission errors. Then they will try to reproduce the problem in their Moodle installation.

At this point, the bug receives a priority score to sort the bug into the backlog. This takes into account fours factors, not necessarily in order:

  1. Moodle Partner tags
  2. Relevance to the Moodle Association development roadmap
  3. Severity, and if it affects security in particular
  4. Community activity. Here is where the user votes come into place

Working on the backlog is often led by Moodle HQ developers, Moodle Partners and Community Developers. But anyone can get in on the action! They patch the system by editing the code. To do this they create a branch of the files to edit, this way the original file is untouched and the developer can work on the file freely. Once the changes are complete, the developer submits the patch for review. The branching and submission takes place in GitHub and its version control magic.

Now in the Moodle core, it is time for peer reviews. Reviewers use a checklist that includes aspects like coding styles, documentation and security issues, among many others. They can comment and give feedback to the developer.

Before the fix is integrated in the core, a review applies automated and manual testing, to gather evidence to answer important questions like:

  • Is the change safe?
  • Will it work for all Moodle users?
  • Does it affect previous versions of Moodle (backwards compatibility)?

And thus the bug is officially squashed.

The issue on the Moodle Tracker is updated to “fixed” and documentation is completed. To witness the process is both a lesson in engineering and the might of a purposeful community.

Dan invites you to get involved, by reporting bugs, voting and following up in issues on the tracker. For advance users, offer help by reproducing the bug and give additional background, or by providing insight in the patch making.


Moonami Logo

This Moodle Technology related post is made possible by: Moonami a company that provides a full range of Moodle services that combine the flexibility, scalability, and power of Amazon’s world-leading cloud platform (AWS) with fanatical Moodle support. Click here to learn more.


 

Tell us you #mootUS16 anecdotes in the comments!