nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

How to clean up a long running project?

Nischal Sharma

We have been running a project for a very long and now want to clean up the project. Some of the parts of the project that have become irrelevant are:

Certain issue types
Certain components
Certain labels

It is not the best experience to still see these components, issue types and labels appear although they are not in use anymore.

The easiest way to go about them would be to delete the irrelevant ones but that would mean:

Old issues that had those components would not have those components and labels associated with them anymore and I will lose the ability to search old issues by these components and labels.
I would have to convert the issue types that I m deleting to another issue type that I m deciding to keep in the project. Although this would show up in the issue history, I would prefer not to do it if the team wants to do any kind of analysis on the older issue types.

Any way I can achieve this goal?

Comments

Mykenna Cepek

A few options to ponder:

Simply closing the issues will allow them to "age out of view", depending on your board settings -- if waiting a week or three is ok. The advantages here are: minimally changing the existing issues, and everything stays in that project.
If Scrum is being used for this project, you could create a Sprint to hold all the cleaned-up issues. Then just close the sprint.
Creating another project just to hold these issues might work. You'd have to migrate the relevant components (since those are project-specific). But the types and labels and links can all persist. Historical analysis would need to include both projects.
A label (or other special field value) could be used to identify all the "archived" issues, and you could then update the board filters, quick-filters, etc. to exclude those issues.

Regardless of what solution you choose, remember to check the following for impacts: automation rules, Confluence macros, dashboards, reports, etc.

I prefer not to delete issues also (to the point of disabling that permission globally). Usually I find that just closing issues makes them "go away" well enough, at the expense of looking at them for a week or so in the Done column.

Let us know what you decided to do, and how it worked for you!

Joy RK

Good point @Mykenna Cepek .

@Nischal Sharma Deleting old issues certainly gives you no future access to analyse them.
Options 1, 2, and 4 may not require Jira admin permissions as these can be done by someone with project permissions.

The idea of creating new projects may be frowned upon in some organisations as this creates addition setup & cleanup work too.

If you decide to go ahead with any option, an additional action item should be to review how you use components and labels across your teams - and see if you can establish a better practice that ill make issue management less of an hassle in future.

Let us know how it goes.

Jarek M

One approach could be to create a catch-all, "no-release" release (Fix Version) and assign all issues that do not fit anywhere else. This way you do not need to worry about the issue status, component, etc., and if any issue is discovered later to be of any significance, it could be moved out of the "no-release" bucket.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

jira-cloud