Did you know that MODX Revolution began in 2006? Didn’t think so. And honestly, I had forgotten until I pulled up the contributor graph below in our recently-completed Github issue migration for MODX Revolution
While we didn’t catch all the contributors to date—we had no way to do so and complete this in 2014—it’s fun to see who’s done what and when. We’d like to especially thank Raphael Sofaer who created the original script we modified to get our data out of Redmine, Ivan Žužak at Github for coordinating the import and testing it repeatedly for us, and Elizabeth S, a friend that helped script the formatting and merging of data points so we could migrate into Github.
Github Issues come without a lot of things that some people think are OMG-important for tracking bugs and planning software. We think it’s a relief and are embracing the simplicity as it aligns with what we’re doing as a company and with our vision for the software overall.
Github also comes with a ton of integrations, which opens up the doors for all sorts of cool things to happen including more sophisticated build and testing tools, and notification systems. This is a very good thing.
What’s Really Important
We distilled down things to what we thought was most important to building great software without needless complexity or having to think too much. We wanted to capture the type of issue, the part of the software it affects and the priority. Here’s the conventions we adopted:
Type is a broad category. We got rid of task, leaving three.
- bug—something that’s broken
- feature—something someone wants to see as new
- enhancement—making something better or refactoring it
This is a hybridization of importance and urgency. We got rid of a “medium” between high and low priority, because we wanted to force ourselves to choose between and issue being something that is important, and something that can be a nice-to-have for a release.
- urgent—very important or absolutely mandatory to address … maybe even a blocker. There should be few of these.
- high—important and virtually guaranteed to make the cut
- low—nice to haves for release
This describes which part of the software an issue affects. We debated including areas at all, but we had a lot of existing data here. As we get more contributors on board, this should allow people to focus on areas in which they have expertise. We merged our previous overly-granular breakdowns into a few broad categories.
- core—anything that has to do with the core of how MODX works
- i18n/l10n—translations and features dealing with multi-lingual sites
- security—’nuff said
- setup—the installer and distribution specifics
- ux/ui—things that affect the backend Manager
Using Color to Improve Scanability
We want to make our issue tracker scannable for things that are important to address as we work on planning and cranking out releases. Urgent priority issues are bright red, and low priority are faded back. Bugs are Cheez-Whiz orange to really stand out, and features and enhancements get slightly faded green and blue colors. Areas don’t need a color as they’re meta information, don’t need to stand out, and it would only add visual clutter.
In Redmine, each release was assigned to a “version”. In Github, they’re “milestones”. It’s easy to see what has been completed and what remains for release, for example our next 2.3 release. You can also click the “Milestones” tab next to “Browse Isues” to see the overall Revo project plan. We’re eager to resume steady progress and push 2.3 out the door.
Time to Get Busy
We hope our transition to Github for issue tracking will make it easier and more attractive for the Community to contribute. Up next we’ll migrate the Evo issues over in the same manner, and we’ll work on getting the legacy issues from the MODX-maintained Add-ons migrated over as well.