Moving the MJML roadmap from Trello to Github Projects and making it public 🤗

As you might have seen online or in San Francisco if you were lucky enough to attend Github Universe, Github released great new features such as Github Projects.

Having everything in one place, without any integration needed

Until now, we were using Trello to manage our product roadmap and plan new fixes, features and more generally new releases. Trello was great, enabling us to quickly move around cards, organise boards with labels and collaborate with comments, checklists, due dates and more.

Though, despite integrations, it was really constraining to create and update Trello cards, including the descriptions, labels and Github links that were already logged in Github. This could also lead to some differences between the state of the cards in Trello and issues in Github if one was up to date but not the other.

Moreover, moving to Github forces us to keep everything in one place while we could have some Trello cards not logged as Github issues.

Opening the roadmap in a snap

We’ve been thinking about opening our roadmap for a while and we’re really excited to finally do it! Now, MJML users know what they can expect from the next releases and when their issues or feature requests will be solved. Hosting the roadmap on Github makes it really easy for new users to know about it while they might not have discovered the Trello roadmap so easily.

Now, as it’s straight out from Github, users have two ways to follow what is going on in MJML:

  1. Directly from the issue they created, in the Projects section

2. From the projects section, in the column where their issue is logged

You can see that the MJML product roadmap is right now organised according to a timeline, from “Long Term” (projects that can take up to several months) to “Soon to be released” (projects that will be released in the following days). Here, you’ll see exciting stuff such as MJML validation and inline styling in the “Near Term” column, meaning it’s only a matter of weeks! If you add Projects to Milestones, provided we use those correctly, users should always know what we’re up to.

Last but not least, users can leverage Github’s features directly on the roadmap, including Github’s advanced search, filtering and sorting features.

Getting people involved

When reviewing the options to open the roadmap, we liked the possibility to let users vote and comment on Trello. Obviously, it now comes natively with the issues and we hope it will incentivise people to get more involved and make their voice heard on issues and pull requests.


Interested in making the move?

Before moving away from your management tool, it’s important noting that if Github Projects works well for us as a small open source team, it’s not a perfect solution. Those limitations are especially worth noting:

  • Less features: being the new kid in town, some features (such as checklists) you might be used to are missing. Figure out if you’ll miss those.
  • Projects tied to a repository: if you have a project split into various repositories, this might be an issue. Luckily for us, as we were inspired by projects such as Babel and React, we chose a monorepo approach.

What do you think about Github Projects or public roadmaps? Feel free to leave a comment to share your opinion! If you’re interested in MJML, join us on Slack, Twitter and subscribe to the newsletter on mjml.io.