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

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.

Hi. We’re MODX.

We’re here to help you fix, build and grow fantastic sites. How can we help?




How can we help?

Tell us the general reason for reaching out so we can connect you with the right team.

MODX Diagnostics

MODX’s Open Source software is 100% free for anyone to download and use. As the team behind it for more than a decade, we know it inside, out, and then some.

Like any software, sometimes things break; we can usually fix them very fast. But, we do have to charge for our time to support our families and fund its ongoing development. There are almost an unlimited variety of things that can cause problems, including server upgrades, corrupt files, accidental changes, outdated software, database hiccups and more. We will save you a lot of time and frustration, and get you back in action.

With our MODX Diagnostic service, we determine the source of issues, and often fix them on the spot. For more extensive problems needing more time, like hacked sites or overdue upgrades, we provide additional estimates and guidance. MODX Diagnostics cost $99 for standard business hours support (US Central Time), or $500 for priority, rush or after-hours emergencies.

If you don’t have budget for professional support from the source, you look for answers in the MODX Forums or Documentation, or seek help from MODXers in the Community Slack, or from MODX Professionals near you.

  I’m not ready to pay, let’s talk…

After submitting this form and completing payment, we will collect your access credentials in a secure support ticket. We look forward to helping restore your site back to full health.

Hi! We’d love to work together.

If you have a simple problem that needs our assistance, please request quick fix help here.

What should we keep in mind?

The project involves:
(select all that apply)
What are you planning?
(select all that apply)

Some other considerations

Specific project information

Commercial Support Customers

Customers with a current Commercial Support agreeement can get help using this form. Learn more about MODX Preferred Support.

Let’s get started

What seems to be the issue?

Contact MODX

We welcome conversations, ideas, inquiries and even the occassional cold sales call, but support and requests about how to use MODX software sent via this form cannot be guaranteed a response. That said, we try to respond to everyone that reaches out to us within two business days.

To report a security issue or file a bug for MODX software, please email security [at] modx.com to reach our security team. If you are looking for help with MODX, many times you can find an answer in the MODX Forums or MODX Documentation, from MODXers in realtime at the MODX Community Slack Channel, or from a MODX Professional near you.

How can we help?