View Issue Details

IDProjectCategoryView StatusLast Update
0020585mantisbtsub-projectspublic2017-05-05 07:54
ReportervboctorAssigned To 
PrioritynormalSeverityminorReproducibilityN/A
Status newResolutionopen 
Product Version1.2.19 
Target VersionFixed in Version 
Summary0020585: Future of sub-projects?
Description

Sub-projects is a major concept that got into MantisBT with no pre-discussions sometime ago, and we haven't really invest much into it after. This feature has no documentation in the manual beyond 3 config options, ON/OFF, inherit versions, and inherit categories options.

If you ask someone about other features, it is very easy to answer the question of what is the expected behavior, but with sub-projects, there I don't think we have the same level of confidence. There hasn't been much investment to make it clearer or more robust.

One option is to deprecate the feature. That doesn't mean necessarily to remove it, but at least to have it disabled by default and have a clear recommendations for users not to use it or to use an alternate feature that we make available.

Another option, is to improve the feature, fix its documentation and maybe do design tweaks to make the behavior more predictable. For now, I feel that if the user uses it in a specific patterns, it will work, otherwise, they are likely to hit complex bugs.

Our APIs is also structured in a way where when you get all projects, you typically only get top level projects, and not sub-projects, which is usually not the intended behavior causing a lot of features to have bugs around excluding data from sub-projects.

Some of aspects to consider:

  • How are sub-projects different from categories and global categories? I know they are different, but I would argue inherited categories and category can cover some of the sub-project behaviors (but not all).
  • Do we really need projects to be sub-projects of multiple projects? What does that mean for inherited versions, categories, etc. Wouldn't there be duplicates? Would it be a message? Even if the versions have the same name, wouldn't they have different definitions?
  • Do we need N levels of sub-projects? or just 1 or 2 levels?
  • What should filters show on the parent project is selected vs. a leaf node project. What versions/categories/custom fields to show?
  • Should custom fields be inherited?
  • When we define "inherit X" where x can be any entity, should this be part of the UI and be per relationship? That is what is done with global categories, but not with sub-projects.
  • What set of columns to show in the column view when viewing a project, but sub-projects may have different fields to show.

I see tons of complexity and a bug farm. I see sub-projects making every feature around it more complex and buggy. I wonder if we should really understand the scenarios that people use this for and try to address them on a cleaner, simpler, or more constrained/predictable way. Then we can recommend the cleaner way (whether it is an evolution of current sub-projects or not) for new users as well as providing a path for users to get to the fixed approach.

So I'm opening this issue to learn more about how sub-projects are used in different environments? What are the expected pre-canned vs. configurable behaviors, etc.

TagsNo tags attached.

Activities

wkarl

wkarl

2016-08-30 09:51

reporter   ~0053909

I accidentally came across this entry. As nobody else has left a note here, I am very pleased to spread our opinion here.

At first I have to state that we are not the average users of Mantis. We use it to track issues in our projects, which are not software projects but industry projects. Among other internal projects, we use it as a general contractor communicating with our customers and our sub-contractors. To do this, we make heavy use of sub-projects. We use this general structure:

Main project (no issues are allowed here, but filters work perfect here including dub-projects)
» Internal communication (only our users see it)
» Customer project (sub-contractors don't see it)
» Sub-contractor 1 project (customer and other sub-contractors don't see it)
» Sub-contractor 2 project (customer and other sub-contractors don't see it)
» ...
» Sub-contractor n project (customer and other sub-contractors don't see it)

As you can see, any communication is always with us. If the customer reports an issue for a sub-contractor, we clone the issue to his sub-project, go into detail, eventually cloning a bugnote back to his original issue. Thus, we can filter what information goes to the customers and avoid direct communication between customer and sub-contractor. The reason for this all is: There is no contract between the customer and the sub-contractor, meaning: the sub-contractor can't make statements to our customer that are legally valid. WE are responsible for the whole project - noone else.

By "cloning" above I mean mechanisms for cloning issues and bugnotes into a different project. We have implemented that in our own plugin - slightly relying on source code modifications which is the reason why it wouldn't work for other mantis users. The modifications however become less as you are implementing more and more hooks to your original source code.

The customer project however can have several levels. The main contract is maybe devided into sub-projects which themselves can conatin several sub-projects. All in all there can be a number of 4 or 5 levels of projects or even more. We find it very convenient that the number of levels is unlimited.

However, we never have one project being the sub-project of 2 or more other projects.

All in all we are rather happy with the current implementation of the sub-projects as they are.

At some points, it seems that the developers are never using sub-projects nor make tests with their features in projects and sub-projects. An example: In the "copy custom fields to other project" dialogs you wont't find the current project in the dropdown field of projects and as a consequence, you won't find its sub-projects. As a workaround, you have to go into a sub-project and copy from above, and from there to the other sub-projects which can be found "down there".

As a summary I have to say: Please don't deprecate the sub-project feature! This feature is the reason why we use Mantis. Mantis suits our requirements best.

I will continue with answers to your dedicated questions in the next bugnote.

atrol

atrol

2016-08-30 10:11

developer   ~0053910

We had an internal discussion about this topic in February.

None of the other developers agreed to remove this feature, at least not without offering a better solution.

wkarl

wkarl

2016-08-30 10:32

reporter   ~0053911

Sorry for the typo above: (appr. line 7:) dub-projects -> sub-projects. (It's a pity you can't edit your own bugnotes here.)

First, we would be very glad to answer questions about complex project set-ups. Please ask us. Now for the questions above:

  • Sub-projects are very different from category inheritance. As stated above, they are essential for our business.
  • For us, one project being the sub-project of two or more other projects doesnt' make sense. Prohibiting this would solve all your questions raised above and would not handicap us.
  • We need at least 5 levels of projects and are very happy that the levels are unlimited. This gives us space for more complex ones...
  • A filter should always show the current project and all levels below. We find it very convenient as it is. We build our project hierarchy exactly in this way. This is also true for versions/categories/custom fields. It is very good as it is.
  • For us, it would be very convenient if custom fields could be inherited. Thus we could avoid the copy orgies ;-)
  • I do not perfectly understand what you mean by the "inherit X" aspect. Could you please explain?
  • Columns to show in column views: Again, some kind of inhertance would be nice. This time bottum-up. Meaning: you should show every column that is shown below, leaving the fields empty in projects where the column is not used. At this time, we make heavy use of database based column configurations blowing up our database. Until now, it doesn't seem to suffer from it.

P.S.: We appreciate very much that you are asking us. However, the bugtracker might not be the perfect place for this question.

OT: The "Email uniqueness" feature has been introduced into Mantis 1.3 (seemingly) without asking in a place that I was aware of before. We became aware of it shortly before the release. I have tried to prevent it from coming, but you seemed to be convinced of your solution. To make it clear, we can't use it, because we need several users for the same email address and our mail system doesn't support other features. Therefore we will need to disable it by configuration. We would be very happy if the configuration switch would never be dropped.

br8kwall

br8kwall

2016-08-31 13:07

reporter   ~0053915

We've used sub-projects heavily in the past as a somewhat elegant approach to record internal issues that we wouldn't share with the client, but then be able to see them alongside client issues in one view. The structure is:

-- Parent Project (for internal issues only. Only seen by internal staff)
--> Sub-project 1 (client facing to hold client-submitted issues)
--> Sub-project x..n (client facing to hold client-submitted issues)

Viewing issues from the level of the Parent Project is a powerful way to see all issues, and viewing the sub-project(s) is an equally powerful filter.

It's too bad this is hard to maintain, because it's one of the killer features of Mantis for us. But, we'd consider other approaches to achieve the same functionality.

br8kwall

br8kwall

2016-08-31 13:22

reporter   ~0053916

Some of aspects to consider:

  • How are sub-projects different from categories and global categories?

-- A. I don't understand how categories could be used to reproduce the functions of sub-projects. I'd need an example use case.

  • Do we really need projects to be sub-projects of multiple projects?

-- A. If I understand correctly, for us, each Project would need 1 or more sub-projects, but each sub-project can only have 1 parent. That parent needs to be at the top level.

What does that mean for inherited versions, categories, etc. Wouldn't there be duplicates? Would it be a message? Even if the versions have the same name, wouldn't they have different definitions?

-- A. The flexibility to let the versions, categories, etc differ between parent and child is a nice flexibility. 99.9% of the time we need them sync'd (manually is OK, but not perfect). A couple times we needed the versions to be different between parent and child.

  • Do we need N levels of sub-projects? or just 1 or 2 levels?

-- A. For us, 1 level (Parent and 1 level of child) has been enough.

  • What should filters show on the parent project is selected vs. a leaf node project. What versions/categories/custom fields to show?

-- A. The core fields have been all we've used. But if we did end up filtering on custom fields, I think we could live with anything that makes sense (union of all possible fields, vesions, etc, or intersection)

  • Should custom fields be inherited?

-- A. The option to inherit them is nice. Same answer as inherited versions above.

  • What set of columns to show in the column view when viewing a project, but sub-projects may have different fields to show.

-- A. Same as filter question above. I think we could live with whatever works. We are willing to incur the added labor of managing sub-projects as essentially independent projects and apply commonalities to the parent where we think it makes sense.

ErikA_NL

ErikA_NL

2016-12-09 09:59

reporter   ~0054719

My 2 cents;

Yes, we also are happy to use subprojects. We order the bugs on the top level for different customers, and within the customer for different projects, and within that for different subprojects. So, we have a three-level nesting tree.

Considering the inheritance of custom fields; yes, it's very desired to have them inherited by default into lower levels. Different customers have their own set of custom fields defined.

ethraza

ethraza

2017-04-28 10:36

reporter   ~0056736

Last edited: 2017-05-05 07:54

View 2 revisions

Hi, just find it. We are new to Mantis here, but we started to sing Mantis with sub-projects. It just seemed right.

MainProject (our framework)

SubProjectA (a system using MainProject)

SubProjectA_App (an App that interates with SubProjectA)

SubProjectB (another system using MainProject but has nothing to do with SubProjectA)

Today I just hit a sub-project bug: 0022823 (https://www.mantisbt.org/bugs/view.php?id=22823)

ethraza

ethraza

2017-04-28 10:38

reporter   ~0056737

Last edited: 2017-05-05 07:54

View 2 revisions

Humm... can't edit my last note!

SubProjectB got in the wrong visual level... it is in the same level of SubProjectA.

EDIT [dregad]: I fixed it.

jolyon.tidmarsh

jolyon.tidmarsh

2017-05-05 07:10

reporter   ~0056778

We've just migrated from 1.2.11 to 2.3 and were happily using sub-projects for the last four years or so. We have lots different sorts of projects:

  • design of industrial machinery which contains:
  • Software, where we track the versions of software (which is what mantis is designed for).
  • Electronics. We track versions of printed circuit board (pcb) revisions; each circuit board needs its own version history and so has its own project
  • Quality issues. use sub-projects more like categories. The sub-projects are things like internal audit actions, external audit actions, concessions, change control items, supplier issues. here we don't need version control so the sub-projects are more like categories, but they have different users and different categories within each.

I'm using projects to group sets of sub-projects. Say we're making a new WonderMachine then that will split up into sub-projects (which need versions) of things like application software, main printed circuit board, secondary printed circuit board, firmware for main pcb, firmware for secondary pcb, mechanical components, documentation and so on. The project manager for WonderMachine project wants to easily keep an eye on all the sub-projects that she's responsible for, but doesn't need access to the SuperWonderMachine project that the other project manager is leading.

To address Victor's questions (I wish you'd numbered them Victor!)

  1. How are sub-projects different from categories and global categories? I know they are different, but I would argue inherited categories and category can cover some of the sub-project behaviors (but not all).
    They have versions attached to them. If your 'group of bugs' needs a version associated with them then it needs to be a project rather than a category.
    Some sub-projects will need a different set of view-columns, these are controlled on a project rather than category basis.

  2. Do we really need projects to be sub-projects of multiple projects? What does that mean for inherited versions, categories, etc. Wouldn't there be duplicates? Would it be a message? Even if the versions have the same name, wouldn't they have different definitions?
    No. For me, sub-projects only need 1 parent.

  3. Do we need N levels of sub-projects? or just 1 or 2 levels?
    For me, 2 levels is fine. i.e. project/sub project, but I can see that more levels would be useful for larger projects.

  4. What should filters show on the parent project is selected vs. a leaf node project. What versions/categories/custom fields to show? Should custom fields be inherited?
    I use the sub-projects to group projects. All the projects that my electronics team work on are sub-projects of the 'electronics' project. I don't really care about project inheritance. The versions/categories/custom field can all be defined by the administrator.

  5. When we define "inherit X" where x can be any entity, should this be part of the UI and be per relationship? That is what is done with global categories, but not with sub-projects.
    What set of columns to show in the column view when viewing a project, but sub-projects may have different fields to show.
    See answer to 4 above. For me the inheritance is unnecessary complexity.

Issue History

Date Modified Username Field Change
2016-02-08 22:47 vboctor New Issue
2016-08-30 09:51 wkarl Note Added: 0053909
2016-08-30 10:11 atrol Note Added: 0053910
2016-08-30 10:32 wkarl Note Added: 0053911
2016-08-31 13:07 br8kwall Note Added: 0053915
2016-08-31 13:22 br8kwall Note Added: 0053916
2016-12-09 09:59 ErikA_NL Note Added: 0054719
2017-04-28 10:36 ethraza Note Added: 0056736
2017-04-28 10:38 ethraza Note Added: 0056737
2017-05-05 07:10 jolyon.tidmarsh Note Added: 0056778
2017-05-05 07:54 dregad Note Edited: 0056736 View Revisions
2017-05-05 07:54 dregad Note Edited: 0056737 View Revisions