[#JRA-14569] Implement Component and Version Schemes

JIRA

Implement Component and Version Schemes

Created: 28/Feb/08 11:44 PM Updated: 05/Mar/08 01:12 AM

Component/s:

Project Management

Affects Version/s:

None

Fix Version/s:

None

Time Tracking:

Not Specified

Issue Links:

Duplicate

This issue duplicates:

JRA-8663 Ability to share components between projects

JRA-2698 Create versions on multiple projects

Reference

This issue relates to:

JRA-12241 Support for Product Suites / Sub-Projects

Supersession

This issue is superseded by:

JRA-14588 Implement Component and Version Schemes

Participants:	Anton Mazkovoi [Atlassian] and Shawn Walton
Since last comment:	20 weeks ago
Resolution Date:	05/Mar/08 01:12 AM
Labels:

Description

« Hide

Anyways, I understand that companies have multiple product lines that
use different version schemes and components, however, even those
products, I'm assuming, may have more than one project associated to
them, so it makes sense for each product to have a centrally managed
version and component list. Why, you ask? Here's at least two reasons.

1. Because otherwise you are risking inconsistency in the way different
people enter the version and component list, which means your reports
will be off.
2. Also, you are adding extra unnecessary effort to creating a project
if everytime you create one you have to add a version and component
list. That is time people don't want to spend.

I see several options for these two lists:

1. Create one master list for all components and one master list for all
versions, regardless of product. The user creating the project will need
to know what versions and components go with what product. Not the
optimum solution, but certainly the easiest to implement.

2. Allow lists to be hierarchical. Planview works off of unlimited
hierarchically structured lists. This will still allow for one master
list that can have versions and components separated heirarchically -
top node is 'Version', second level is 'Product', third level is the
version or component (depending on list) for that product.

3. Allow for creation of multiple lists. Seems redundant. One master
list that is heirarchical, to me, would be the best answer. You can even
go so far as to provide a way to only show a certain part of the list
based on the product you are creating the project for. We have this
ability in Planview, where, based on the selection of a value in one
lists, values in another list become selectable. In this way, you can
manage all of the same thing in one list, but narrow the end user
picklist to the appropriate values.

Description

The reason I feel we need this functionality probably comes from the fact that in Planview, all lists are managed centrally, as it makes it much easier to maintain and manage, particularly if the lists are used over and over. Anyways, I understand that companies have multiple product lines that use different version schemes and components, however, even those products, I'm assuming, may have more than one project associated to them, so it makes sense for each product to have a centrally managed version and component list. Why, you ask? Here's at least two reasons. 1. Because otherwise you are risking inconsistency in the way different people enter the version and component list, which means your reports will be off. 2. Also, you are adding extra unnecessary effort to creating a project if everytime you create one you have to add a version and component list. That is time people don't want to spend. I see several options for these two lists: 1. Create one master list for all components and one master list for all versions, regardless of product. The user creating the project will need to know what versions and components go with what product. Not the optimum solution, but certainly the easiest to implement. 2. Allow lists to be hierarchical. Planview works off of unlimited hierarchically structured lists. This will still allow for one master list that can have versions and components separated heirarchically - top node is 'Version', second level is 'Product', third level is the version or component (depending on list) for that product. 3. Allow for creation of multiple lists. Seems redundant. One master list that is heirarchical, to me, would be the best answer. You can even go so far as to provide a way to only show a certain part of the list based on the product you are creating the project for. We have this ability in Planview, where, based on the selection of a value in one lists, values in another list become selectable. In this way, you can manage all of the same thing in one list, but narrow the end user picklist to the appropriate values.

Show »

All

Comments

Work Log

Change History

Sort Order:

Ascending order - Click to sort in descending order

[ Permlink | « Hide ]

Anton Mazkovoi [Atlassian] - 02/Mar/08 04:36 PM - edited

Hi Shawn,

Thank you for sumbitting a detailed description of what you are after. May I ask if the linked issues, JRA-12241, JRA-8663 and JRA-2698, are asking for the same functionality?

Cheers,
Anton

[ Permlink | « Hide ]

Shawn Walton - 03/Mar/08 08:26 AM

Anton,

8663 and 2698 are basically asking for the same thing that I am asking for - the ability to have one master list for version and component that can be used across projects. I believe my Option 2 above may be a good implementation.

However, 12241 is looking at a deeper issue, in that the JIRA tracking system is rather flat, and does not contain a lot of functionality for organizing the 'project level' within the system. As well, organization by product is an imporant idea.

This is what I need to do. Currently, I"m trying to use categories to do this, as well as the 'key' in issues, so I may have several categories representing our products:

PPM
EPM
SPM, etc.

The key will then correspond to that, so I can see issues by product:

PPM - 001

However, this is a major workaround.

There may be a few things to consider, such as:

1. Ability to have custom fields on the project itself that allows you not not only filter by issues, but also by project. As many have stated in the other three issues you listed, there may be multiple PROJECTS for a PRODUCT. At least providing a way to filter by attributes on a project could help with this, as you can say, for example, "show me all my projects for this product". You can't do that right now, except through maybe a category, but, again, you can't actually create a filter on that. It only shows up on the dashboard - not very helpful for reporting.

2. The other issue is that there are times when a project itself may need to be broken down into smaller 'sub-projects' that then will collect their own set of issues. This is getting more into actual project management, which Planview does.

My problem I'm having here is that internally we are trying to implement our own tool, and use it in conjunction with JIRA. One of the problems is that the level of detail we want to collect issue information is at a level lower than the project....in our terminology, a 'phase' level, or possibly even the 'task' level.

Project
Phase
Task

The ability to be able to bring more detail into the system would be very helpful. For instance, we could import into JIRA the work breakdown structure for a project down to the level in which we want to collect issue information, and be able to roll that all the way to the project.

In the example above, import down to the Task level. Issues would be attached to the Task.

3. Another problem I see that people may be having is the ability to relate multiple projects to a particular version. Again, this gets back to #1 above, in that projects need to be able to have attributes on their own, outside of issues. So, you can create a filter that show you:

"show me all my projects for Version 10.x".

You can't do that right now because projects don't have attributes, except for category, and you can't create views based on project, only on issue.

[ Show » ]

Shawn Walton - 03/Mar/08 08:26 AM Anton, 8663 and 2698 are basically asking for the same thing that I am asking for - the ability to have one master list for version and component that can be used across projects. I believe my Option 2 above may be a good implementation. However, 12241 is looking at a deeper issue, in that the JIRA tracking system is rather flat, and does not contain a lot of functionality for organizing the 'project level' within the system. As well, organization by product is an imporant idea. This is what I need to do. Currently, I"m trying to use categories to do this, as well as the 'key' in issues, so I may have several categories representing our products: PPM EPM SPM, etc. The key will then correspond to that, so I can see issues by product: PPM - 001 However, this is a major workaround. There may be a few things to consider, such as: 1. Ability to have custom fields on the project itself that allows you not not only filter by issues, but also by project. As many have stated in the other three issues you listed, there may be multiple PROJECTS for a PRODUCT. At least providing a way to filter by attributes on a project could help with this, as you can say, for example, "show me all my projects for this product". You can't do that right now, except through maybe a category, but, again, you can't actually create a filter on that. It only shows up on the dashboard - not very helpful for reporting. 2. The other issue is that there are times when a project itself may need to be broken down into smaller 'sub-projects' that then will collect their own set of issues. This is getting more into actual project management, which Planview does. My problem I'm having here is that internally we are trying to implement our own tool, and use it in conjunction with JIRA. One of the problems is that the level of detail we want to collect issue information is at a level lower than the project....in our terminology, a 'phase' level, or possibly even the 'task' level. Project Phase Task The ability to be able to bring more detail into the system would be very helpful. For instance, we could import into JIRA the work breakdown structure for a project down to the level in which we want to collect issue information, and be able to roll that all the way to the project. In the example above, import down to the Task level. Issues would be attached to the Task. 3. Another problem I see that people may be having is the ability to relate multiple projects to a particular version. Again, this gets back to #1 above, in that projects need to be able to have attributes on their own, outside of issues. So, you can create a filter that show you: "show me all my projects for Version 10.x". You can't do that right now because projects don't have attributes, except for category, and you can't create views based on project, only on issue.

[ Permlink | « Hide ]

Anton Mazkovoi [Atlassian] - 04/Mar/08 04:05 AM

Hi Shawn,

Thank you for your reply.

Making versions the highest level in the hierarchy does not really play nicely with JIRA's philosophy. However, introducing products, which are a collection of projects, and allowing products to have versions, which are composed of specific versions from contained projects could work.

I believe this is what JRA-12241 is asking for. JRA-12241 would also address searching, as once products exist, it will be possible to search for product versions, which will actually search through individual project versions.

If you agree, please let us know if we can resolve this issue as a duplicate of JRA-12241.

We have thousands of feature requests, and keeping them organised greatly helps us plan the roadmap for JIRA.

Cheers,
Anton

[ Permlink | « Hide ]

Shawn Walton - 04/Mar/08 08:49 AM

I don't think you understood what I was saying, but that's OK.

I do not want versions as part of the hierarchy. I want version to be a master list, just like component, so it doesn't have to be edited every time when you enter a new project - so I'm asking for a master list that can be used by all projects. This is probably similar to the others.

The other thing I was talking about was to have custom fields on projects, with the ability to create filters on projects, NOT just issues. People want to see, by PROJECT, not by ISSUE, what is happening for a version. You can't do that right now, because you can't create a view on projects. You can only see, by version, project information for a single project at a time.

So, what that means is, in your filtering functionality, a user could not only create a filter to see issues, based on values within fields for those issues, but also create filters to see projects. I know this is a bigger change, but it looks to me like others are asking for it.

The other limiting thing I see, which others are also running into, is your 3 level 'hierarchy'. It really isn't a 'hierarchy' per se, and it doesn't take into account complex project structures.

Unfortunately, JIRA is using the term 'project', and requiring that issues come off of projects, instead of just having issues and sub issues, and using fields/attributes to categorize them. When you start using the word 'project', and requiring that issues become part of a project, you begin to move toward the idea of project management, and all the overhead that comes with that.

As a project management system, JIRA, personal opinion, is not ready for. As an issue tracking system it has very good functionality. I'm running into problems with being forced to tie issues to this 'project' level, when I personally think that the idea of a 'project' is not necessary in this system - even though there is rudimentary time reporting. You want to have this, then you need to support more levels than 3 in your 'project' hierarchy.

This is what 12241 is asking for.

My first issue, regarding master lists for version and component is a duplicate of 8663 and 2698 .

The other issue, which is related to t8336 and 2698, is related to 12241.

In other words,

1. link 14569 to 8663/2689.

2. create a new issue for the other discussion and link it to 12241.

The new issue should have the following text from my previous comment and this comment:

This is what I need to do. Currently, I"m trying to use categories to do this, as well as the 'key' in issues, so I may have several categories representing our products:

PPM
EPM
SPM, etc.

The key will then correspond to that, so I can see issues by product:

PPM - 001

However, this is a major workaround.

There may be a few things to consider, such as:

Project
Phase
Task

In the example above, import down to the Task level. Issues would be attached to the Task.

"show me all my projects for Version 10.x".

You can't do that right now because projects don't have attributes, except for category, and you can't create views based on project, only on issue.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

The other limiting thing I see, which others are also running into, is your 3 level 'hierarchy'. It really isn't a 'hierarchy' per se, and it doesn't take into account complex project structures.

[ Show » ]

Shawn Walton - 04/Mar/08 08:49 AM I don't think you understood what I was saying, but that's OK. I do not want versions as part of the hierarchy. I want version to be a master list, just like component, so it doesn't have to be edited every time when you enter a new project - so I'm asking for a master list that can be used by all projects. This is probably similar to the others. The other thing I was talking about was to have custom fields on projects, with the ability to create filters on projects, NOT just issues. People want to see, by PROJECT, not by ISSUE, what is happening for a version. You can't do that right now, because you can't create a view on projects. You can only see, by version, project information for a single project at a time. So, what that means is, in your filtering functionality, a user could not only create a filter to see issues, based on values within fields for those issues, but also create filters to see projects. I know this is a bigger change, but it looks to me like others are asking for it. The other limiting thing I see, which others are also running into, is your 3 level 'hierarchy'. It really isn't a 'hierarchy' per se, and it doesn't take into account complex project structures. Unfortunately, JIRA is using the term 'project', and requiring that issues come off of projects, instead of just having issues and sub issues, and using fields/attributes to categorize them. When you start using the word 'project', and requiring that issues become part of a project, you begin to move toward the idea of project management, and all the overhead that comes with that. As a project management system, JIRA, personal opinion, is not ready for. As an issue tracking system it has very good functionality. I'm running into problems with being forced to tie issues to this 'project' level, when I personally think that the idea of a 'project' is not necessary in this system - even though there is rudimentary time reporting. You want to have this, then you need to support more levels than 3 in your 'project' hierarchy. This is what 12241 is asking for. My first issue, regarding master lists for version and component is a duplicate of 8663 and 2698 . The other issue, which is related to t8336 and 2698, is related to 12241. In other words, 1. link 14569 to 8663/2689. 2. create a new issue for the other discussion and link it to 12241. The new issue should have the following text from my previous comment and this comment: However, 12241 is looking at a deeper issue, in that the JIRA tracking system is rather flat, and does not contain a lot of functionality for organizing the 'project level' within the system. As well, organization by product is an imporant idea. This is what I need to do. Currently, I"m trying to use categories to do this, as well as the 'key' in issues, so I may have several categories representing our products: PPM EPM SPM, etc. The key will then correspond to that, so I can see issues by product: PPM - 001 However, this is a major workaround. There may be a few things to consider, such as: 1. Ability to have custom fields on the project itself that allows you not not only filter by issues, but also by project. As many have stated in the other three issues you listed, there may be multiple PROJECTS for a PRODUCT. At least providing a way to filter by attributes on a project could help with this, as you can say, for example, "show me all my projects for this product". You can't do that right now, except through maybe a category, but, again, you can't actually create a filter on that. It only shows up on the dashboard - not very helpful for reporting. 2. The other issue is that there are times when a project itself may need to be broken down into smaller 'sub-projects' that then will collect their own set of issues. This is getting more into actual project management, which Planview does. My problem I'm having here is that internally we are trying to implement our own tool, and use it in conjunction with JIRA. One of the problems is that the level of detail we want to collect issue information is at a level lower than the project....in our terminology, a 'phase' level, or possibly even the 'task' level. Project Phase Task The ability to be able to bring more detail into the system would be very helpful. For instance, we could import into JIRA the work breakdown structure for a project down to the level in which we want to collect issue information, and be able to roll that all the way to the project. In the example above, import down to the Task level. Issues would be attached to the Task. 3. Another problem I see that people may be having is the ability to relate multiple projects to a particular version. Again, this gets back to #1 above, in that projects need to be able to have attributes on their own, outside of issues. So, you can create a filter that show you: "show me all my projects for Version 10.x". You can't do that right now because projects don't have attributes, except for category, and you can't create views based on project, only on issue. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ The other thing I was talking about was to have custom fields on projects, with the ability to create filters on projects, NOT just issues. People want to see, by PROJECT, not by ISSUE, what is happening for a version. You can't do that right now, because you can't create a view on projects. You can only see, by version, project information for a single project at a time. So, what that means is, in your filtering functionality, a user could not only create a filter to see issues, based on values within fields for those issues, but also create filters to see projects. I know this is a bigger change, but it looks to me like others are asking for it. The other limiting thing I see, which others are also running into, is your 3 level 'hierarchy'. It really isn't a 'hierarchy' per se, and it doesn't take into account complex project structures. Unfortunately, JIRA is using the term 'project', and requiring that issues come off of projects, instead of just having issues and sub issues, and using fields/attributes to categorize them. When you start using the word 'project', and requiring that issues become part of a project, you begin to move toward the idea of project management, and all the overhead that comes with that. As a project management system, JIRA, personal opinion, is not ready for. As an issue tracking system it has very good functionality. I'm running into problems with being forced to tie issues to this 'project' level, when I personally think that the idea of a 'project' is not necessary in this system - even though there is rudimentary time reporting. You want to have this, then you need to support more levels than 3 in your 'project' hierarchy.

[ Permlink | « Hide ]

Anton Mazkovoi [Atlassian] - 05/Mar/08 01:12 AM

Hi Shawn,

I am resolving this issue as a duplicate of JRA-8663 and JRA-2698.

I have also created JRA-14588 for further discussion. Please see my comments on that issue.

Cheers,
Anton