I must admit that I am still not able to "connect the dots" of this feature request and therefore do fully understand the functionality that you are requesting. I believe my main point of confusion is not being able to see why you would like to have the functionality you are asking about.

Please let me ask the following questions. Your answers should greatly help me understand your request.

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".

The feature request for having custom fields for projects is JRA-1991.

May I ask, why would you like to have searches that return projects instead of issues? How many projects are you planning to have in your JIRA system? Are projects going to be added frequently?

Please note that permissions are managed on a project level. Often, JIRA users do not have access to all projects. How many projects would an average user in your JIRA instance have access to?

The main reason for the absence of a project search is that JIRA is designed to have a "finite set" of projects. Each user usually has access to a set of projects they are interested in. Therefore, they often can look through these projects and do not need to search for them.

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.

Are you planning to have reports that show which projects meet certain criteria? If so, may I ask for an example of a search criteria? Could you describe a sample report?

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.

May I ask what sort of information you would like to collect? Would grouping issues, within a project help? For example, you can use Components to group issues within a project.

I guess I am trying to understand why you would like to have a deeper hierarchy?

Would sub-tasks help:
http://www.atlassian.com/software/jira/docs/latest/subtasks.html
?

Also, please note there is an open feature request for extending JIRA to have a deeper hierarchy of sub-tasks - JRA-4446. At the moment, sub-tasks cannot have their own sub-tasks.

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.

Would you be able to let me know what that information would look like? For example, describe a sample report that would show you this information.

At the moment, projects are created or deleted. They cannot be transitioned through worklfow, comments cannot be added to them, nor work log against them. All of these operations are performed on issue level. Would you like projects to become simple aggregates (or buckets) for issues?

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.

If JRA-4446 was implemented, would having one JIRA project, then issues, and sub-tasks, and sub-sub-tasks, and so on, be the solution you are after?

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.

There is a lot of functinality in JIRA that is customised on a project level. Sometimes, even on project and issue-type level. Some of these things are:

1. Permissions - it is essential to be able to control which users can have access to which projects
2. Workflows - it is often handy to customise the workflow for various projects, as various projects follow different business processes
3. Custom Fields - it is really handy to let certain custom fields affect only certain projects, as certain information is only needed by issues in particular projects
4. Issue Types - certain issue sypes (e.g. Bugs) only make sense for certain projects
5. many others

If the idea of a project is not useful, would creating only one project in the system and using it for all issues be one of possible solutions?

Cheers,
Anton

Thanks for being so prompt in your replies, I do appreciate it. Just so you know, once we make the decision to purchase the software, we will probable get a JIRA consultant in to help us with the best implementation to fit our requirements.

Let me try to be succinct instead of long winded. Here is what we have initially been looking at doing.....

Planview will be used to plan and schedule projects, manage projects as they are in progress, and report on cost, use to determine resource utilization, capture time, etc.

JIRA will be used to track issues assigned to developers - both new functionality and defects, estimate effort on new functionality (which will move into Planview), as well as allow us to schedule defects for certain versions, attach code to issues, all that good stuff.

We are still in the early stages of implementation, but you can think of this implementation like this: Planview is for the strategic, business side and JIRA is for the tactical, development side. The two need to meet somewhere in the middle.

The way we need to track work in Planview, in order to do effective resource allocations, is to have our new functionality as separate projects. Each project has 'version' as an attribute. Each project will have a certain breakdown that will correspond to how it will be represented in JIRA. We will also have 'generic' project buckets for capturing defect work not associated to new functionality. We will also have an 'immediate escalation' queue for customer-reported problems that come into Customer First, the tracking system our product support department uses.

What does this mean...initially, my thoughts have been the following:

Have in JIRA generic projects by product. The project will be categorized with the product name. So, I would have this:

project: spm
project: ppm
project: some kind of new functionality (this one will close out when functionality is released. all bugs reported after that will go into the generic bucket - ppm, for example)
...and so forth.

I won't get further into detail. The main point here is that for each project, there will be issues in those projects that are scheduled for the same release. So, you may have 50 issues in the spm project and 150 issues in the ppm project that are all scheduled for PVE10.0.

What I need is a view across projects that allows me to see all issues, regardless of project, slotted for a release. Maybe this is a better way to explain that.

Maybe I'm trying to connect too close to Planview, and, again, we are open to suggestions. But, we want to be able to tell in JIRA what issues are slotted for a release regardless of project.

So....not so short-winded, sorry about that:

1. go to the filter screen and be able to create a filter that says, 'show me all issues slotted for version 10.0' - I would then get a view, across projects, of everything in that version.

2. maybe put aside the idea of filtering on projects for now. being able to filter across projects would be good enough, I think.

3. I need this because I may be responsible for multiple projects in one version, and it would really suck to have to click on each project to see the issues slotted for that version. You cannot get the whole picture, particularly when the same resources are more than likely working on issues across those projects.

4. The reason I need separate projects by new functionality, instead of grouping it all into one giganto project is because we need to be able to make a decision on which projects we can get into a version, which ones we can't, what we could timebox, etc.

5. In Planview, we would have it structured like this, to meet your three level requirements you have at the moment:

Project: some kind of new functionality
Phase: story (requirement)
Task: discreet business rule to make the story a real thing. This is where the estimation will take place. Requirements will be placed on resources here for resource planning. As well as the eventual time reporting.

6. In JIRA, the Project defined above would come is as the project in JIRA. As issue would be created for the Phase. A sub-issue would be created for the Task. Once all this is estimated by the developer in JIRA, we will bring it back into Planview for a view, ACROSS ALL PROJECTS, of resource utilization. At this point we can start looking at what we can and can't do for that version, based on resource availability. Planview can roll everything up the hierarchy, so we see at each level effort estimates, plus schedule dates.

7. Once the project is in motion, back in JIRA, the developer will start working on their tasks, as well as bugs. Since there are different projects, the development manager will need to be able to see ACROSS PROJECTS, how many issues are open for a version, and who is assigned to what just in case priorization needs to occur, or re-allocation of resources.

8. This method is being set up to accomodate xtreme programming (or however you spell that). It will also allow us to use other project management models, depending on the type of project.

9. Although I still think it is useful to have custom fields on projects, which you had said previously ya'll do, but I can't figure out where to do that. I also think it would be good to be able to see a report by project of what is going on, by version.....

(simple example)

Version 10.0

1. open issues
   Project A 134
   Project B 245
   Project C 300

10. VERY LONGWINDED, I KNOW! Did this make sense? If I can at least get the ability to create a filter/view of issues across projects, that would be great.

(simple example)

Version 10.0

Project name.....number of open issues
Project A.............134
Project B.............245
Project C ............300

Thank you for the explanation. This does make sense.

Unfortunately, I am swamped at the moment. I will do my best to respond on Monday.

Cheers,
Anton

Thank you,
Shawn

Sorry for the delay. I was absolutely swamped last week.

Thank you for the detailed explanation, I think I can see what you are after.

The best way I would suggest to approach the scenario is to have one project per product (as you have suggested). Create issues in the main project for each piece of functionality you plan to deliver and then link these issues to issues in other JIRA projects if necessary. For more information on linking issues please see:
http://www.atlassian.com/software/jira/docs/latest/issuelinking.html

This does have an overhead of creating multiple issues, each one in a relevant JIRA project.

As you have mentioned you can also use sub-tasks where necessary to break issues down to smaller tasks.

When a piece of functionality needs to be unscheduled (i.e. scope is cut) you can use Bulk Edit:
http://www.atlassian.com/software/jira/docs/latest/bulkoperations.html
to change their Fix For Version. For example, clear it, or change it to different Fix For Version.

I would stongly suggest using issues and not projects to represent features, as this is not what projects have been designed to represent, and JIRA is designed to have a finite set of projects. I am afraid that otherwise you will end up with too many unused projects, which will get in the way and create confusion.

It does feel to me that the ideal soltion to the scenario you are describing is JRA-12241. If support for Product Suites is added, a Product Suite will represent a product. Each Product Suite will have versions. Each Product Suite Version will be made up of JIRA Project Versions (and JIRA projects, as each JIRA Project Version belongs to a specific JIRA Project).

Searching through a Product Suite Version will search through the relevant JIRA Projects and their relevant versions. Running a report on a Product Suite Version will similarly show information on JIRA Projects and their versions that make up the Product Suite Version.

Please let me know if the above makes sense.

Cheers,
Anton

I would still like to have a master list, across projects/products for both version and component. Don't assume that everyone has different version and component lists by product. There are other ways to implement that, which allow you to maintain only one list per attribute (version/component).

I will take a look at 12241 again.

We still need to do some soul searching on our end to determine the best way to implement the usage of JIRA, as it will be part of our overal portfolio management process, which includes Planview.

Thanks alot,
Sahwn

We will still need to be able to create a filter on Version or Component across products.

The feature request for searching across multiple versions and components is JRA-1538.

Another possible approach is to use a Multi Select Custom Fields, for components and/or versions. For more information on Custom Fields please see:
http://www.atlassian.com/software/jira/docs/latest/customfields/overview.html

Custom Fields can have different set of options per project.

I would still like to have a master list, across projects/products for both version and component.

I see a "Product" that is mentioned in JRA-12241 being this sort of master list for versions. As you have mentioned previously, there could be several master lists, which JRA-12241 would provide, as it would allow for multiple products.

Users can then search through the version of a particular product and that would search all relevant projects and relevant version of each of those projects.

Don't assume that everyone has different version and component lists by product. There are other ways to implement that, which allow you to maintain only one list per attribute (version/component).

You are absolutely right. In quite a few cases, however, different products do have separate life cycles and therefore different versions. Therefore I hope that JRA-12241 will cater for most use cases.

However, I do not think that Products would have components, as products will not have issues directly in them. Projects would have their list of components.

May I ask what is the main benefit that you see in having a global set of components?

Is the main benefit, saving administration time of creating components for each project? Or is it the ability to search for the same component across projects?

If searching is the main issue, would using a custom field help?

Please note that issues for sharing versions and components between projects are JRA-2698 and JRA-8663.

Cheers,
Anton