Running an open JIRA installation or an huge in house installation with a lot of issues the maintenance of the issues cost a lot of time and it is not easy at all. In general you have to go through all the issues and clean up all issues every couple of weeks. You or the project lead have to relate issues and close any duplicates and so on. A logical issue checker (LIC) can improve the life of this person. The LIC can perform a lot of checks which can not be provided by the common filter functionality. The following checks are possible: 1) Issues with Status = Closed and Resolution = Duplicate a) These issues should have a linked "duplicates" issue. => Otherwise the resolution "Duplicate" doesn't make sense. b) The Fix Version field should be empty. => Otherwise a lot of same issues would be appear in a release note which makes no sense. Or different "Fix Versions" in several duplicated issues would mismatch the road map. 2) Issues with Status = Closed and Resolution = Fixed a) The "Fix Version" should be set with a specific release version otherwise no one knows in which release the issue was closed. Sometimes a "Fix Version" will never be set (e.g. using JIRA as a ticketing system), so this check should be optional. b) Linked issues of type "incorporates" or "is part of" should have the same "Fix Version"s or at least one same "Fix Version". Otherwise why could this issue be fixed, while incorporated issues aren't fixed or not in the same release ("Fix Version"). 3) Further ideas are welcome. These checks maybe very project specific hence everybody has to decide to enable them or only enable some of the checks in his project. The "Logical Issue Checker" should be a new "Permission Type", which is associated to the "JIRA Administrators" by default. I think the "Logical Issue Checker" is an enhanced filter functionality which is not covered by common filter in the "Find Issue" menu. The enhanced filter functionality should have the same benefits like the common filters, e.g. bulk edit. The functionality should be extendable by a new JiraService (e.g. LICService), so that any person can implement its own checks. Furthermore the project administrators can enable and disable the different check services, because not each service is relevant for a project.