---
robots: nofollow, noindex
tags: planning
---

# RFC: Backlog Cleanup

## Overview
There is a large amount of issues that are tagged with `Needs: Backlog Review` for the Fluent UI React library. This proposal covers the process to:
* Catalog and clean up the mutliple "backlog" milestones
* Create one Backlog location
* Catalog and clean up all backlog issues
* Create a new set of more managable issues
* Link to the new set and close the old set
* Place new organized issues into new Backlog milestone

By doing so, we should have a more managable backlog that is well organized, easy to communicate to customers, and provide more visibility into how those items get placed on to our engineering roadmap.

## Problems

### Mutiple places of the 'Backlog'
There are a series of places where we have issues that part of a collective 'backlog.' For example we have a milestones that are Freezer and Backburner that are not maintained on a regular basis

Also not all the issues marked as `Needs: Backlog Review` are captured here so it's where the actual "backlog" lives.

This leads to customer and engineering team confusion on where does our actual backlog of community submitted issues live.

### `Needs: Backlog Review` has become our catch all for issues
We have 287 issues (as of 8/12/2020) tagged with `Needs: Backlog Review` that is around 35% of the open issues we currently have on the repository. And that number has not been trending down and has consistently increased.


### We want to coordinate breaking changes to components to ease the burden of upgrading major versions
We should avoid introducing breaking changes to every component in every release. We also find that there is efficency in batching up multiple breaks to a component at once.

### Issues have remained open for long periods of time
When looking at the backlog query and sorting by oldest we have a series of issues that have been outstanding for a number of *years.*

We need to set expectations with our customers on if we will actualy address these issues or close them. It's ok to say that we won't do something - we can't do all the things.

So it's better that we provide clarity to customers if we won't fix something or won't include a feature and provide details around our decision making so that we don't carry issues that seem to be in limbo for a number of years.

## Solution

### Provide one place that we promote as our "Backlog"
1. Create a Milestone called "Backlog"
2. Remove the Back burner and Freezer Milestones.
3. Use the following principle moving forward:
:::info
If we receive issues or feedback we will actually address - meaning that it aligns with our short, mid, and long term roadmap it goes in the Backlog Milestone.

If it's something we will most likely will not do because it does not align with our roadmap - it's a won't fix, and we close the issue and we don't put it somewhere like a Freezer.
:::

This isn't a new concept as it appears popular open source libraries like VS Code take a similar approach at least from a Backlog Milestone solution:

### Create one new primary issue for each component and link and close all old feature requests to that issue

Most of our feature requests fall into these two board catagories:
1. Behavior changes, feature additions to existing compnents
2. Requests for new components

The following is a series of steps for a proposed solution:
1. Create a set of new tracking issues per components
1. Each of the existing components
2. Each new requested components
2. Go through the 280+ backlog issues and link them to new component tracking issues
3. Close the the old issue - this allows us to still keep the history of the issue and gives us an in issue lookup for all the feedback
4. Create new tracking issues as we find requests that are outside of existing and new components and repeat the link/close steps

Once 280+ issues have been linked and closed, move all the tracking issues to the new Backlog Milestone.

Publish on our wiki that we have a new Backlog location and the Backlog becomes the true location that our team will manage, update, and use the customer feedback as input when we converge each component in the upcoming future.