Over 500 JIRA projects, one for each user?

[Robert Galvin]

My company has around 500 JIRA users. I was thinking of giving each person a project to track individual day to day task. The tasks would not relate to any project, but would be required for each person (i.e. training, promotion planningm etc.).

Does anyone see an issue with this? Is it a good idea? Would it slow down my server? Let me know what the pros and cons are.

[Udo Brand · Accepted solution]

What about one project, with a default security level (containing only Reporter). So only the Reporter would see his own tasks.

[Robert Galvin]

Excellent Idea! I also wanted people to have the ability to make components if needed. Any ideas on how that might work?

[Udo Brand]

Components can only be added by a user who have administer project permission. Not sure if it is a good idea to give this permission to all users. But you could use instead a label field (call it Component), where every user can enter his own labels.

[Nic Brough -Adaptavist-]

I've done this with a "to do" list project, many times.

I'm not sure that "Reporter" permission will work here though - Jira sees that as meaning "anyone who can raise an issue in the project", not "the person who raised it". For that, you need to enable "reporter browse" permission. This also avoids the messing around with automatically setting security levels etc. See https://confluence.atlassian.com/display/JIRA/Current+Reporter+Browse+Project+Permission<br< a="">>

[Udo Brand]

Everyone would have browse project permission, but by default you would have an issue security level (which then can not be changed) where only the reporter of an issue would be able to see that particular issue.

[Norman Abramovitz]

Can you explain why you need something like this? It is very raw to not be able to hang these types of items(trainging, promotions and planning) onto some sort anchor such as training week 2013-Sept-9, product markerting, 2014 year planning. It also seems out of the ordinary that no one else sees these items either if they are tracking business related items. What is the unspoken goal here?

[Jobin Kuruvilla [Adaptavist]]

Not a good idea in my opinion. Number of project impacts performance and this requirement doesn't need a different project for every user either.

You can simply do this in a single project as the workflows, permissions all are likely to be same for all. You can just have different issuetypes for each item like training and then the users can create issues of that type in the project and assign to themselves. If one project is too less, create few based on organizational structure.

[Robert Galvin]

The number of projects impacts performance? What performance is impacted? Is this performance impact documented by Atlassian?

[Robert Galvin]

I looked at the following link:

https://confluence.atlassian.com/display/ATLAS/Scaling+JIRA

From what I read here, increasing the number of projects should have limited effect on performance. Let me know if I am missing something.

[Nic Brough -Adaptavist-]

It's less the number of projects than the background work that will need doing. If you just increase the number of projects, then there won't be a huge impact on performance.

However, you will be limiting each project to a different user (or set of users). Jira will have to work out the permissions for users which can become a bit of an overhead if it's complicated. You certainly do not want to have one permission scheme per user/project, but there will still be an overhead if you go for a single permission scheme that uses roles to deal with one user.

Scaling Jira is not a simple linear thing. Your scheme may be absolutely fine, but I'm really not confident enough in that to tell you to proceed.

[Jobin Kuruvilla [Adaptavist]]

In my experience, yes. For each project, there is a permission configuration along with other schemes and it does a lot more API calls if there are more projects. You can veirfy it if you do the JIRA profiling.

And in this case, one project seems a better idea.