An innocent pull request sends me on a multi-day adventure through Mudlet’s issue tracker.
In an effort to level up my coding knowledge and gain experience in Mudlet’s core application I decided to pick an open issue on Github, the platform Mudlet uses to track code, bugs and feature requests. A bit of code spelunking and following existing patterns I submitted a pull request to add a new event. I was met with the question, “What’s the use case?” “I have no idea.”, was my response. I was simply using the issue as a learning tool. We decided that the PR was of no use and was simply feature creep so it was discarded. No problem, my quest was complete as I had gained coding knowledge but it begged the question; why was this issue still in the database when it was no longer of use and, more importantly, how many more issues were there like that?
I decided to answer these questions and announced an audit through all existing 1000 issues. Some were as old as 2017, actually older, because that was when the Mudlet moved from Launchpad to Github, migrating all issues over. The goal here was to eliminate stale issues and reduce feature requests that had not had any traction or pickup from the community over the years.
Several trends started to emerge as I poured through the pages, both in the actual issues posted (more on that later), but also in the way the Github issue tracker was being utilised.
Issues weren’t being closed. While Github does a pretty good job of matching up PR’s to issues and closing them upon merge it is not foolproof. Tens of years old issues were closed that had been fixed in early releases. Developers also weren’t searching through the issue tracker to mark off fixes, which led to the next finding.
Issues weren’t being linked. Relevant issues weren’t being linked with one another. A GUI correction and bug fix in one PR could fix two or more issues, but the developer wouldn’t know because they weren’t linked. Github provides a handy linking system by using hashtags which link relevant issues together and puts a note on the linked issue too.
Feature requests lay dormant. This was a bit of a hot topic and the decision to close particular feature requests was not done lightly. I went with the method of closing ones that were gathering dust in the corner. i.e. they had not had a single comment nor had I heard of anyone else requesting a similar thing. I also opted to ease off on closing features as I drew nearer to the current year to give them time to see the light. A year or two without a “great idea” comment just means that developers will not choose to implement it and will work on something that has more traction and that the community will appreciate more.
Labels system not fully utilised. Labels allow developers to categorise issues. Mudlet has decided on labels such as: bug (high, medium, low), wishlist, wiki, Lua only. This allow contributors to see what is important, what is in their field of expertise and help to decide on what to work on next. Many older issues suffered from not being labelled which also meant they didn’t come up when new contributors filtered for a particular topic. An effort to recategorise will be undertaken and a ‘tag as it comes in’ approach will help maintain a better standard.
After working through all the issues it was also quite clear what the community was asking from the developers of Mudlet. A few recurring themes had developed in the issue tracker that would have been impossible to spot without starting this adventure. Common problems were mentioned multiple times, duplicated, worded differently or the bug displaying itself in a subtlety different way.
Copy and Paste. The MUD gaming genre of course deals with copious amounts of text and users rely on manipulating that text either in Mudlet itself or when moving blocks of text outside to their favourite editor. Multiple issues were noted when users tried to perform this common everyday task.
Indentation and word wrap. These are not large problems when mentioned individually but when added together can make your game play feel less fluid. Proper indentation and word wrapping makes reading large volumes of text easier and helps readers skim quickly if required.
Dark Theme interface problems. Dark themes have been around for quite a number of years now and many users prefer them over the traditional blinding white interfaces. A single issue on being unable to see a small widget correctly when using the Dark Theme of Mudlet might rank it as a low priority bug. But when you link together several Dark Theme issues the trend starts to become clearer and shows that the interface may need some further work. The number of issues related to the Dark Theme itself may push this up to a medium level bug as a whole. This is why linking related issues together is important; it helps developers see the larger scope of the problem.
Mapper user interface. One of Mudlet’s star features is the excellent mapping system available. Issues and feature requests on the mapper are frequent and show the developers that this heavily used feature is at the forefront of many Mudlet users minds. They want it to be intuitive, easy to setup and just plain work.
After spending the time going over Mudlet’s issues, I can say that it has been an enlightening process and very much worth doing. With approximately 400 stale issues closed the issue tracker is leaner and easier to navigate. Couple that with some further label tagging to help contributors drill down into relevant problems. Being able to report my findings back to the community and core developers will help decide future progress and polish into the client we all love to use.
Happy MUDding!
Want more info or wish to collaborate? Find me as Zooka on Mudlet’s Discord server.
