Are JIRA projects really services? What if an issue spans multiple services?

[Aren Cambre]

JIRA's "projects" appear to be permanent endeavors, like services or products. E.g., Atlassian organizes its own JIRA "projects" as separate products: https://jira.atlassian.com/secure/BrowseProjects.jspa#all

I havea JIRA "project" for my enterprise CMS system and another one for my enterprise blog system. Here's where it gets weird:

We have our "main" enterprise blog system, but we're currently setting up a one-off, single-instance blog somewhere else for a special purpose.

Since both blog instances use the same software, and may need similar handing over their lives (e.g., bugfix on one has to be applied to the other), I thought it would be best to keep them in the same JIRA "project".

However, setting up the separate, single-instance blog requires a change to our CMS. So now I'm in a conundrum: do I put that issue in the blog "project", or do I put it in the CMS "project"?

If I put it in the blog project, then the blog project has a change to a totally different system.

If I put it in the CMS proejct, it's logically grouped with fellow issues related to the CMS, but it's completely separate from the blog project. I can't even assign it to a version within the blog project.

Seems like I am stuck choosing between two evils? What other alternatives do I have?

[Nic Brough -Adaptavist- · Accepted solution]

I'd be tempted to do it all in one project, and then have a custom field that indicates whether it's for the side project or not. Might that work? Could try components or labels to do the same.

[Aren Cambre]

So you're saying I should still put the CMS change in the blog project?

[Nic Brough -Adaptavist-]

I would, based on what you've asked. The two systems are similar and need to be kept in line, so it sounds right to me, otherwise you're into maintaining 2 nearly identical projects.

[Aren Cambre]

OK, thanks. I guess what I still am having a hard time getting my arms around is that a change for service X has to be in service Y's "project". But maybe that's just how it has to be.