09 Feb 2015
This bugs me
6.4. Exercise - Find the Oldest Bug
The oldest issue that is still open in Mopidy is #45. It is a request for adding more powerful search capabilities opened by Jodal (the project leader) on January 19, 2011. This is not labeled as a bug, but as an enhancement:
Currently, the search capabilities in the local backend is quite naive and simplistic. It would be nice to have more powerful search capabilities, maybe using an existing search solution.
I’m unsure why this hasn’t been added, it’s probably not seen as important or vital to the project. I have seen several other search-related issues though, so it might be a good project in the future to try and solve several of those issues in one swoop.
The oldest bug is #312, opened by Jodal on January 6, 2013. It is an issue with the time position not becoming zeroed immediately when changing tracks. This was actually added to the two milestones: v0.21 - Audio cleanup part 2 and v0.20 - Audio cleanup part 1 on December 28, 2014. And it was referenced in the Audio cleanups checklist 5 days ago. From what I’ve read it was not clear if it’s been solved or not.
6.5. Exercise - Create Your Bug Tracker Account
Given that I’ve already had a github account for quite a while and Mopidy utilizes the github issue tracker there’s not much for me to figure out. I think that github’s tracker is great, very intuitive and organized.
6.6.1. Exercise - Reproduce a Bug
Most of the bugs were specific to certain operating systems or certain clients used in conjunction with Mopidy. Some examples are #933 and #916. Most of them seemed easy enough to reproduce, and the people that were able always commented such.
The issue that I was able to reproduce was #341. It was easy enough to reproduce following the steps provided in the comment. It seems however that this is no longer a primary concern/no longer relevant after reading #645. Might be something for my team to revisit.
6.7.1. Exercise - Bug Triage
I think it’s a bit silly to ask for us to triage five bugs at this early stage in the project (even though I’m usually all for the trial by fire). For OSS I’m of the belief that it’s better to take it slow and learn the community, style and practices of a project than to just burst in guns blazing.
So instead I’ll talk about how the style of main project contributers in handling bugs and issues reports.
The contributers to the project are very organized. They have milestones, goals, checklists, clear labels and much more. Almost every issue I’ve seen on github has some sort of progress made on it, whether it is clarification on an issues, instructions on reproducing or just some kind of discussion. There are even those who seek to make it more organized. For example in issue #830 someone is requesting detailed documentation on when exactly someone should be reporting an issue. They do have a discussion forum that seems pretty active, but I’m not certain that everyone knows its there. A lot of times people will be eager to report an issue without exhausting all other avenues first (I know I’ve fallen victim to that several times, it’s a bad habit).
Rules of Triage from TOS
- Letting the user know that someone has looked at it
- Looking for other similar bugs
- Guaranteeing proper severity and/or priority
- Ensuring that the bug is sensible and helpful to developers
- Ensuring that the bug is filed against the correct component, with the correct version
Mopidy certainly follows most of these rules:
- I’ve seen great to most issues and proposed solutions. The two main contributors, Jodal and Adamcik, are very quick to reply and discuss anything.
- It’s harder to see if this practice is followed, but often in discussion of one issue, people will seek out other related issues or pull requests and reference them.
- This is generally covered. The practice of using milestones seems to also prioritize bugs and enhancements.
- This is the responsibility of the one reporting the bug. It’s important to determine that you’re not reporting a bug that’s specific only to you, and if you’re unsure discuss it.
- This is generally covered by the use of tags in Mopdiy. They categorize issues based on their topic, approachability and sometimes will add labels such as “in progress” to show any activity.
One final note on Mopidy’s issue handling. While it looks like most bugs are usually closed upon their completion or on the merging of a relevant pull request, sometimes they’re left open. Discussion surrounding certain issues within the issue tracker on github lead me to believe there was a solution found, but it’s not always obvious if that’s true or not (given that the issue is sometimes left open). I wish it could be a bit clearer on this. The newer issues generally follow a pattern of open -> assigned/in progress/milestone –> closed. But in a lot of the older issues I see some ambiguity.
Laura Barber at 6:03PM