organization of Redmine projects?
I'm the sole developer working on a couple of webapp sites. I have them in subversion, but I'm not using a project management tool.
I recently got redmine up and going, and I want to set up the projects in there. What I'm looking for is a recommendation as to how to structure these two projects in Redmine. From what I can glean, the structure is Project->subproject . So I'm trying to map this to my to-do list structure. From my to-do list, there are three kinds of tasks: new features, bug fixes, and maintenance ( not quite bug fixes but things that really need cleanup ).
Should I make each webapp a top-level project, with Features, Bugs, and Maintenance as subprojects? What other ways of organizing projects are there? For instance, in the subversion manual, they recommend having project/trunk, project/branches, project/testing, project/releases, etc. Are there similar guidelines for working in Redmine?
Answer
As usual, when you configure a system you need to customise it as much as possible to try and meet your own needs. I personally don't know of any guidelines or recommendations for Redmine per-se, however I can relate what we do here and I hope that will help you! :-)
Features/Bugs/Maintenance are just ways to label your tasks so that you can filter them. These are a specific label known as a "tracker" in Redmine. You can define your own trackers for additional types of task.
Project and Sub-Project are also effectively a way of labelling your tasks, but grouping them under a broader umbrella category. When you create 'projects', you assign the trackers you will need to them. In our case, we create an API, and have distinct trackers to identify bugs, features & modifications with (effectively) duplicated tracker names so that we can identify if the tasks are for desktop or dsp programmers. The sub-projects are used to identify product lines or customisations that our customers require specific support for. We also use version labels to identify specific releases in each subproject so that we can get a nice roadmap view of all of the tasks we are tracking. We have multiple projects in our Redmine system, each configured in a similar manner, with some project tasks linked across projects as "related" issues so that we can identify dependencies.
This is just one way to configure Redmine, but is the simplest we could manage given the complex relationships between some of our projects. It is the second configuration that we have tried and we find it works well. FYI, the first configuration was on a test system to allow us to work out what we needed from the system after migrating from Trac, a couple of years ago. The current configuration has been in use for about 2 years and seems to suit our needs nicely.
As I said earlier, you need to decide what you need from the system, but the simplest approach is to think about how you view a project from the top down, configure your system to match your processes, and not change your processes to match the tool - always the more 'disastrous' option IMHO. I wouldn't recommend tracking bugs and features etc in separate projects, as getting your roadmaps together is usually harder, and it also makes it harder to visualise the total task load for a given project. Even dividing task types into subprojects could be problematic, as it complicates things if you find you need to support multiple product release cycles, adding to your workload in terms of managing your Redmine system.
That's about all I can think of for now. I hope that helps you. :-)