5

I'm helping to reogranize several redmine projects; although I have a lot of experience with issue tracking systems, I've never worked with redmine before.

What is the best way to organize Issues in Redmine so that they can be easily grouped by:

  • feature (e.g. "Upload a file", "Login to site", "Send message")
  • system component (e.g. front-end, back-end, database), and
  • target version ("beta 1", "beta 2" "GA")

Right now, most "Bugs" are child issues of "Features"; unfortunately, this means that the Target Version of each bug is automatically populated with the Target Version of the parent feature. Is there some way to fix this?

loseeka
  • 51
  • 2
  • Why are bugs sub issues of features? –  Dec 21 '12 at 21:09
  • No idea. I've inherited this project; I think that my predecessor's idea was to do it this way so that it was easy to generate lists of bugs for each feature. – loseeka Dec 27 '12 at 14:03
  • 1
    I would strongly consider using the 'related to' of one issue to another to relate the feature itself and any bugs against the feature. –  Dec 27 '12 at 14:27

1 Answers1

3

Assuming that one can move bugs to their own item (not sub features), the way to relate bugs and features is to relate them to each other. This will fix the target version being populated correctly and allow you to use the roadmap with its intended functionality.

The next consideration is "are features actually things to do? or are they general areas of the site?"

If you look at how Redmine organizes itself you will see "Category" being used. These are what I believe your 'features' really are. This becomes even easier to work with - you set up the categories in your project and the category becomes a drop down on the issues page. The roadmap can then show what categories are going out in the next target version very cleanly. Reports can easily be generated against categories.

The system component I believe would be best served with a custom field that allows a list (possibly the multiple, though you might also consider separate sub-tasks under an issue with one for each task - "modify database" and "modify back-end" for a single bug could be assigned to different people).

If in doubt, Redmine issue tracking for itself is likely the best example of how to organize Redmine.