Category / Sub Project - Which will be the better approach ?

[manjeet]

Hello Guys,

I am thinking about mantis for our projects as bug tracking system. During the thought process around it, I came across one question in my mind. In our project, there are three components Android App, iOS app and web portal. All these three components have there own separate lifecycle of release management. I tried to create three categories in a project for the above three components so that according to the category raise bug can be assigned to the particular programmer. but in this approach, I could not manage the versions of each category. And if goes with the subproject approach, I could not have the summarised statistics of all the projects at one place in the summary. Please suggest. Thanks for the help in advance.

[atrol]

All these three components have there own separate lifecycle of release management.

I would create 3 independent projects in such a scenario. So each project has it's own versioning, change log and roadmap.

And if goes with the subproject approach

I can't recommend subproject as there is a questionable concept behind it, see https://www.mantisbt.org/bugs/view.php?id=20585 for some more details.

[Starbuck]

Are sub-projects really still "questionable" given the popular use of the feature? I think the solution to that problem is to define in documentation where sub-projects fit and not. Then something that doesn't work won't be "questionable", it will actually be documented.

I would create 3 independent projects in such a scenario. So each project has it's own versioning, change log and roadmap.

I agree, though I have a similar scenario with sub-projects.

It seems the only problem in the current scenario is that ( I believe ) the summary stats don't understand issue relationships. I'd think that could be addressed with custom code, probably a separate stats page ratjer than changes to the current page. That means a new plugin...

My thought here is that we need to describe views on the data. For a parent product where there are different platform-specific implementations, we want to understand the effort for a project regardless of where tickets are in other projects. That could include Marketing and training.

So we're not just summarizing sub-project data up to the parent. We need to be able to report where issues have dependencies that are in sub-projects or other projects. For example, a "core" product change needs to be implemented in both the iOS and Android versions. The task is not completed until both of its dependencies have been completed. Each of those sub-tasks need to be reported too: The Android version might require tickets for UI, database, and communications - and so would the iOS version. This specific scenario includes at least 7 tickets. What if changes to communications are applied to a completely separate project? A manager would want to understand data like the total turnaround time for communications components in relation to a product, not simply all communications time - and possibly compare communications turnaround time to database time. For ETA planning it's helpful to know that for an average ticket communications may inflate task time by a factor of 2+.

Note that such reporting doesn't need sub-projects. Since tickets manage the dependency relationships, the reporting should be based on following tickets for a project, no matter where the dependencies are, in sub-projects or other projects. That's the new calculation here.

Does that fit the current use-case? If so then the evaluation of Mantis here should include the potential of Mantis to be adapted to a specific use-case scenario, rather than just what's available in a default installation.

HTH