Redmine

Note the following is based more on my reading of past discussions than extensive experience, others may well contribute more authoritative comments, and of course if any of the below is flat out wrong - someone do please jump in and correct me!

First of all, KISS - if you don't have compelling reasons to use one of Redmine's more complex features, then IMO you shouldn't.

WRT subprojects specifically, my understanding is that they are generally used for large projects when there are clear distinctions between both the groups of people working on different areas (job function, corporate division/departments, employees of different subcontractors), and between those areas - components / functions whatever of the project (design vs production, UI vs back-end code).

If these can be broken out so cleanly that they could go into separate (top level in Redmine) Projects, it probably should be (KISS), but having sub-Projects are useful for managers who need to get the birds-eye view of the overall "big picture".

IMO the biggest benefit seems to be in "filtering" out the irrelevant stuff for each distinct group. To the extent you have people that are doing day-to-day work in areas that have been divided this way, they may be inconvenienced by having to jump from one subP to the other. Or if the type of work they do in each subP is quite different, then this may be helpful!

As Redmine's "cross-Project" capabilities evolve, the need to use sub-projects is reduced, except for very large environments (think NASA 8-) )

Sounds all reasonable to me.

I'm still wondering if the use subprojects for short-term tasks/projects is advicable. Like developer branches in a VCS. Closing a project is then like removing it, which is disadvantageous if you also want to look back what was done. I'm not sure if working with subprojects in this way is very useful. I don't think so. But it would be good to know if others would agree with this.

And I'm still not 100% sure if it makes more sense to have seperate main projects or one main project and several subprojects. As you have stated it is more for a "big picture" view. However, I'm not sure if you get a better view then. Maybe in the Gantt chart or the calender. But that's all, or not?

Robert Schneider wrote:

And I'm still not 100% sure if it makes more sense to have seperate main projects or one main project and several subprojects. As you have stated it is more for a "big picture" view. However, I'm not sure if you get a better view then. Maybe in the Gantt chart or the calender. But that's all, or not?

For bigger projects, it may be convenient to have separate SCM repositories. Par example 'sw' for the software, 'mech' for the mechanics, 'el' for the electronics etc. As far as I know there is 1:1 relation between projects and repositories. So this is a case where subprojects are usable.

I use to put all projects owned by the same client under the main project with the client's name.

Senguttuvan Ganesan wrote:

I use to put all projects owned by the same client under the main project with the client's name.

Same here. A nice feature w.r.t. nesting projects is that you can see (roll-up) all of the issues for that customer in one place AND if you use "inherit" you can control users at the parent project level.