Effective use of components

Steve Gallant1

I've been tasked to develop the maintenance framework for my company. I'm working on a standardized implementation and am familiar with the JIRA product now (I've been reviewing the configuration options for 2 weeks now) however I have never really had the chance to use it to any beneficial extent.

My question is more about usability than anything else. I'd like to set up the framework to have the projects in JIRA as the clients, and the components as the individual maintenance contracts. For those with more experience using JIRA, are there any drawbacks to this approach from a usability, reporting or organizational perspective?

The alternative is to make a new project for each maintenance endeavour, but I want to avoid having a long list of dead projects in there if I can.

Thanks in advance for your help.

Steve

Dimitar Dimitro11

The key is what visibility rules do you want to support? From what I read, I assume:

• Each client has multiple contracts
• Each contract has starting date and ending date
• Each contract can be extended as a new contract, thus forming a contract family
• Each contract has a number of registered contact persons on the client side

Regarding visibility, I assume:

• Each registered contact person can see all issues for that contract (including the ones they did not file)
• Each registered contact person can NOT see all issues for other contracs of the same company unless they are registered under that contract too

With these assumptions in mind, you can do as follows:

• Create a single JIRA project or a project per company (as you wish)
• Setup security level and a version for each contract family. You can either choose to create a group (recommended) for each contract-family or just say that only 'currentUser' (i.e. the reporter) can see the issues.
• Use the behaviors plugin to force the user to specify security level (i.e. contract).
• Using GreenHopper, set child versions (under the contreact family) for each contract, populating the start and end dates.
• When it is time to renew the contract, you release the old version and create new one, using the GH capability to roll-over issues to next version.
• Reporting can be done on contract-family level to have a global view over the years or at individual contract level.
• You can add numeric fields for custom metrics, i.e. cost in addition to time, GH allows you to have burnup/down reporting and aggregation on these.
• Use components for initial assignment - create one component per internal business area and assign the person responsible as component lead. Change the default assignee to component lead.

Though not as simple as setting up a bunch of components, something along these lines is not so difficult to set up and would scale better over time. Most important: use versions for milestones and time intervals; use security schemes or projects with permission schemes for restricitng visibility.