# Jira Issue Curation

**URL:** <https://talk.openmrs.org/t/jira-issue-curation/29113>\
**Category:** Development\
**Tags:** jira\
**Created:** [June 22, 2020, 4:08pm UTC](https://talk.openmrs.org/t/jira-issue-curation/29113 "2020-06-22T16:08:27Z")\
**Posts on this page:** 2\
**Page:** 2

<div class="post-metadata">

**Author:** ![ibacher](https://talk.openmrs.org/user_avatar/talk.openmrs.org/ibacher/32/19751_2.png) [@ibacher](https://talk.openmrs.org/u/ibacher)\
**Post date:** [June 29, 2020, 7:13pm UTC](https://talk.openmrs.org/t/jira-issue-curation/29113/21 "2020-06-29T19:13:34Z")

</div>

> [@mseaton](#):
>
> I’m also not really sure how closing all of these tickets that are already in isolated projects makes any difference. If there is already a JIRA project that is just for the Birt module, then is it really helping by closing all of the tickets in this project? We could just as easily put that project into a different permission group, so only certain users would see it. Or maintain better dashboards of projects that are active, and have Birt and others just available for those who go digging.

Well, closing tickets has the advantage of being able to maintain a ticket list for that module without hiding the project (which makes things even worse if we do actually need work done on them).

> [@mseaton](#):
>
> Have we identified the projects with the biggest backlogs? I assume TRUNK/CORE is the main culprit here?

[Here’s](https://issues.openmrs.org/secure/Dashboard.jspa?selectPageId=15353) a quick dashboard to answer that. The top two are unsurprising:

- Core
- Ref App

(Oddly, BIRT is # 13 in most unresolved tickets 🙂 )

> [@mseaton](#):
>
> Effective use of statuses and filters might make an equally or bigger difference. If the problem we are trying to solve is to make it easier to identify the tickets that are appropriate to work on and those that are not, assigning statuses of “Backlog Review Needed” or something, and/or filtering and sorting based on status, ticket activity, watchers, votes, other other criteria should lead to (potentially more accurate) lists of tickets.

So, the goal here is to make it clearer which issues need to be worked on, but also to make it possible to identify existing projects and ideas that we may want to pursue but which need additional information.

The real problem I see is not “there are too many tickets”, but more that nobody is maintaining the back log and that it’s gotten to a point where useful stuff is being lost in the noise. I’m not saying we need to close _anything_. Instead, what we need to do IMO is:

1. figure out how we can most effectively use people’s time to review the back log
2. figure out what practices we can adopt to try to keep the back log maintained, given the constraints of the OpenMRS community

> [@grace](#):
>
> Would people be up for trying Option 2 together?

I’m up for that.

---

<div class="post-metadata">

**Author:** ![mseaton](https://talk.openmrs.org/user_avatar/talk.openmrs.org/mseaton/32/8088_2.png) [@mseaton](https://talk.openmrs.org/u/mseaton)\
**Post date:** [June 29, 2020, 7:37pm UTC](https://talk.openmrs.org/t/jira-issue-curation/29113/22 "2020-06-29T19:37:29Z")

</div>

Sounds good - thanks everyone for moving this forward!

[Previous page](https://talk.openmrs.org/t/jira-issue-curation/29113.md?page=1)