View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0020585 | mantisbt | sub-projects | public | 2016-02-08 22:47 | 2019-12-22 15:24 |
Reporter | vboctor | Assigned To | |||
Priority | normal | Severity | minor | Reproducibility | N/A |
Status | new | Resolution | open | ||
Product Version | 1.2.19 | ||||
Summary | 0020585: 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:
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. | ||||
Tags | No tags attached. | ||||
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) 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. |
|
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. |
|
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:
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. |
|
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) 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. |
|
Some of aspects to consider:
-- A. I don't understand how categories could be used to reproduce the functions of sub-projects. I'd need an example use case.
-- 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.
-- A. For us, 1 level (Parent and 1 level of child) has been enough.
-- 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)
-- A. The option to inherit them is nice. Same answer as inherited versions above.
-- 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. |
|
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. |
|
Hi, just find it. We are new to Mantis here, but we started to sing Mantis with sub-projects. It just seemed right.
Today I just hit a sub-project bug: 0022823 (https://www.mantisbt.org/bugs/view.php?id=22823) |
|
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. |
|
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:
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!)
|
|
This PR explains some of the complexities with sub-projects model |
|
Related discussion |
|