The Mahara project has a vibrant community where users report bugs and also new features. We triage them regularly so that we have an overview of bugs that need fixing and also know what features users would like to see implemented.

However, our feature wish and bug list is quite long, and I’ve had the suspicion that there were items on it that we have already implemented, but not closed the item yet because it was reported a second time or because we implemented it in a slightly different fashion.

Thus, after reading Steve Klabnik‘s “How to be an open source gardener” the other day (hat tip to Hugh for pointing this blog post out), I decided to sit down this weekend and try to go through as many reports as I could to reacquaint myself with the requests and also see how many I could close.

I wanted to focus on the feature requests so as not to get mixed up with bug testing. Besides, there were already plenty reports to look at so that I didn’t need bug reports on top of that. 😉

Altogether, I reviewed 260 reports out of 476 in slightly less than 8 hours (approx. 1.8 minutes per report). I could already mark 28 as having been fixed in previous versions of Mahara. Closing off these almost 6% of triaged feature requests is a win even though it may not seem to be so much. It is great to remove items from the long improvement list and show users that we are making progress.

I was also able to identify feature requests that may not require much work that could be used for getting started to developing for Mahara. A developer is going to look at these items to determine whether they are really small tasks developmentwise or require more knowledge of Mahara. It is always good to have a number of small tasks readily available for people who want to contribute to Mahara so that they can succeed submitting a patch quickly. Our easy-to-fix bugs and features have the tag “bite-sized”. For slightly more experienced developers, the “snack-sized” items are a greater challenge, but still produce results quickly.

I also transferred all reports that I wanted to keep into a spreadsheet so that we can go through them more easily in the team and can filter them, add priorities etc. While I like Launchpad quite a bit, it does not allow for the exporting of bug lists as far as I know so that you can do some analysis around it or get a spreadsheet for further managing of individual items.

Next week, we will have a number of students of the Catalyst Open Source Academy working on Mahara. They will be looking at easy-to-fix bugs or features to leave their mark in an open source project. I already look forward to this year’s group of students working on Mahara. Their contributions will go into Mahara core and become part of the next release, which will be in April 2015.

Latest next weekend, I’ll tackle the remaining reports. Now that I know it is doable in quite an efficient fashion, it’s not such a daunting task anymore and definitely better than pulling weeds. 😉

This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.