Roadmapping Foreman and Katello through Redmine Trackers

My long lasting wish is to have a roadmap communicating features that we plan to deliver in upcoming releases.

In the past we’ve tried to do so through stand alone document, that has big issue of maintainability, as it puts either pressure on one person responsible for it to keep track of everything and update it (that’s very hard and near to impossible) or put the responsibility to everyone to maintain this document, what would be fine, but there would have to be a process, that everyone need to follow, but that is hard to establish.

I think that easiest solution to this would be if everyone who plans to work on a feature (has clear idea what the feature would look like and plans to work on it) would create a redmine tracker and assign it either to the next release, or some special redmine version tracker (‘future release’).

We then can have this query and similar for plugins as roadmap, that can even be automatically published (maybe on theforeman.org).

This would be much easier for each developer, but it would give us quite nice roadmap and maybe even possibility to vote for features, join efforts on them and so on.

Do you see it as something:

  1. managable for all of us to do?
  2. valuable for the project to have?

Do you have any suggestions how to make it possible, easier, or better?

8 Likes

From a release perspective this is good. We’ve had summaries on Discourse but that’s hard to maintain. Since Redmine is driven by a database, I’d expect it to be much better. I’d welcome this.

1 Like

I think the two tricky bits are ensuring everyone is using Redmine, with clear guidelines on when Redmine usage should be enforced for a project. And aligning the version usage. Most non-Foreman projects look at things from their release version not the coming Foreman version. As you point out, using a field to align to Foreman version since that is the major release vector to build a Roadmap is a good idea.

I believe you’re so right with this point, but I want to replace Redmine with a state of the art ticketing system here. I actually believe Redmine, or the lack of functionality, is causing a lot of communication problems inside the project. And I strongly believe we should switch to the functionality that Github offers. My reasoning is, that I gain the impression, that developers just open Redmine tickets because they have to. It’s not possible to properly label issues, group issus, @-mention other devs, easily embed screenshots, …
I think we can do a lot better here with less effort. I also believe this would help a lot when we open RFCs as stories that we can comment, collaborate and work on then link the individual issues that implement the features to the story.

3 Likes

While generally I agree, our GH org has 190 repositories. What works for a single or few repositories can be little bit more tough at scale.