What (Also) Happened Next Was We Migrated Issues To Github

by Jay Stephen Gilmore

Published on January 31, 2014

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.

Streamlining Things

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

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

Priority

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

Area

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.

Tracking Progress

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.

We hope you find this as great a move, and likewise hope you’ll get involved. Go star the MODX Revolution project to show some MODX love—and to keep abreast of the code as it’s updated in real time.

Millions Rely on MODX

In 2005, MODX could power a fully mobile-responsive website using HTML5 and CSS3, even though those technologies weren’t invented yet. And with MODX today, you’re ready not only for what you need now but also what comes next.

Try MODX Right Now