# Objective Our Healthy Backlog Initiative is focused on refining our issue management processes to prioritize strategic work, improve delivery, and create stronger feedback loops with our community of users. This plan addresses how we will apply targeted actions against our issue backlog while preserving our "everyone can contribute and co-create the software that powers the world" mission of GitLab We have segmented the issue backlog into four buckets described below, and for each bucket we will apply different approaches and actions. # Bucket 1 : Orphaned issues - no `type::` label or no `group::` label ### Sub Bucket 1.1: Issues with no `type::` label ### Sub Bucket 1.2: Issues with no `group::` label ##### **Action for both sub buckets:** 1. Classify the issues with the existing AI triaging bot into one of 3 types ( ~"type::bug" , ~"type::feature" , or ~"type::maintenance"), and label with group label. Apply the ~"automation:ml" label used to track the burndown without flooding the other buckets with AI-classified issues. # Bucket 2: Issues not updated in 3 years and with no upvotes ##### **Action :** 1. Close with a message along the lines of: <table> <tr> <th> _"This issue is closed due to a lack of activity for more than 36 months. If you believe it should be reconsidered for prioritization, please add your input or reopen."_ </th> </tr> </table> 2. Monitor regularly if folks updated or respond to closed items and reopen and modify the label to ~"backlog::no-commitment" and ~"Community Interest" to prevent repeated closure. # Bucket 3: Issues created by banned users Issues from Banned users are being hidden and are only visible to the GitLab Admin. ##### **Action :**  1. Apply specific ~"backlog::invalid-user" label 2. Close the issue with the help of our data team through the backend systems with the following message. If a user is unbanned this issue becomes visible again. <table> <tr> <th> _"This issue is being closed due to being created by an invalid user."_ </th> </tr> </table> 3. Permanently delete after  90 days if there is no change. This should have a positive impact on the performance (to be confirmed).  # Bucket 4: Classified issues with type/subtype label and attribution to a group ### Sub Bucket 4.1. Bugs ~"type::bug" ##### **Action:** 1. Continue the [existing triage process and SLAs](https://handbook.gitlab.com/handbook/engineering/infrastructure/engineering-productivity/issue-triage/) to get severity labeling on and adjust the label if needed.  2. Apply ~"backlog::prospective" label to all S1/S2 as they need to be addressed. 3. Address all S1/S2 as they need to be addressed. 4. EMs to label S3/S4 bugs that are current, still relevant, and need to remain open with a label ~"backlog::prospective" 5. Support to label bugs that are of customer interest with the new ~"Customer Interest" label. 6. Label remaining S3 and S4 bugs with ~"backlog::to-be-closed" and populate with a message to indicate that we need help with confirming if the bug is reproducible (adding one appropriate labels: ~"reproduced on GitLab.com", ~"reproduced on GitLab Self-Managed", ~"reproduced on GitLab Dedicated", ~"reproduced on GitLab Dedicated for Gov" otherwise, these issues will be auto closed after 2 months. <table> <tr> <th> _We appreciate your input and contribution to helping improve our product. Our current focus is prioritizing efforts to align with our product strategy, and we are considering closing non-aligned issues that are not reproducible. If you can reproduce the issue, please add all labels that apply:_ ~"reproduced on GitLab.com", ~"reproduced on GitLab Self-Managed", ~"reproduced on GitLab Dedicated", ~"reproduced on GitLab Dedicated for Gov"_. If the issue is not labeled as reproduced in the next two months, it will be closed._ </th> </tr> </table> 7. After 2 months apply ~"backlog::no-commitment" label and close all bugs labeled with ~"backlog::to-be-closed" that have no ~"reproduced on GitLab.com", ~"reproduced on GitLab Self-Managed", ~"reproduced on GitLab Dedicated", ~"reproduced on GitLab Dedicated for Gov" labels. Update all reproduced ones with ~"backlog::no-commitment" <table> <tr> <th> _“This issue is closed as part of_[_ GitLab’s Healthy Backlog Initiative_](https://about.gitlab.com/blog/inside-gitlabs-healthy-backlog-initiative/)_. If you believe this bug remains remains relevant and can be reproduced, please share your input and add all labels that apply:~"reproduced on GitLab.com", ~"reproduced on GitLab Self-Managed", ~"reproduced on GitLab Dedicated", ~"reproduced on GitLab Dedicated for Gov"_<em>."</em> </th> </tr> </table> 8. Monitor regularly for any activity after closure and reopen and add ~"Community Interest" label to prevent repeated closure. 9. Add engagement scoring to existing triage to inform prioritization <table> <tr> <th> **Engagement Scoring** **Data points collected:** * **Number of comments by customers** * **Number of emojis by customers** * **Number of comments by employees** * **Number emojis by employees** * **Days since last update by customer** * **Presence of the "Community Interest" label** * **Presence of the "Customer Interest" label** **Score = Customer Comments x 3 + Customer Emojis x 3 + Employee Comments x 1.5 + Employee Emojis x 1.5 + "Community Interest" x50 + "Customer Interest" x50 + Days Since Last Customer Activity x -0.1 (optional or need a floor)** **Note**\*\*: The engagement score system should be documented publicly and allow for contributions by the entire GitLab Community, which includes GitLab Team members and non-GitLab Team Members.\*\* </th> </tr> </table> ### **Sub Bucket 4.2. Features ~"type::feature"** ##### **Action:** 1. PMs will label features that are current, still relevant, and need to remain open. These issues will include features that are in-progress, on the roadmap, actively being considered for the roadmap, that we know we will work on in the next 18 months or are high impact/risk Community items. Label to use ~"backlog::prospective" * Label remaining features with a label ~"backlog::no-commitment" 2. DevRel to label all features that are of Developer Community Interest with ~"Community Interest" label 3. Support to label all features that are of interest to our Customers with ~"Customer Interest" label. 4. Use Engagement Scoring to identify feature issues with the ~"backlog::no-commitment" that can be closed and modify label on those to ~"backlog::to-be-closed" and populate with a message: <table> <tr> <th> _We appreciate your input and contribution to helping improve our product. Our current focus is prioritizing development efforts to align with product strategy, and we are closing issues that are not currently aligned. However, we are taking community engagement into consideration as we evaluate the future of issues that fall outside this current focus.  If you believe this feature remains relevant and should be prioritized, please share your input._  </th> </tr> </table> 5. After \~2 weeks - close all features with ~"backlog::to-be-closed" without any activity (both comments and upvotes) and modify the label back to ~"backlog::no-commitment" with messages along the lines of: <table> <tr> <th> _This issue is closed as part of _[_GitLab’s Healthy Backlog Initiative_](https://about.gitlab.com/blog/inside-gitlabs-healthy-backlog-initiative/)_. If you believe this feature remains relevant and should be prioritized, please share your input and reopen the issue._ </th> </tr> </table> 6. Monitor regularly for activity and reopen and add ~"Community Interest" label. 7. All re-opened issues be discoverable for consideration by Product Management by using label ~"backlog::no-commitment" and ~"type::feature" ### Sub Bucket 4.3. Maintenance ~"type::maintenance" ##### **Action:**  1. Deploy bot to categorize maintenance issues with a using Customer Impact Scoring (defined below):  Critical 1. Linked to active support tickets 2. Related to production incidents: ~infradev label 3. Security Implications: ~security label 4. FedRAMP vulnerability: ~"FedRAMP::Vulnerability" label Important  1. Linked to other active issues 2. Performance degradation 3. Technical debt with customer impact Standard - remaining usually covering code cleanup, documentation updates and don't have any external dependencies 2. Label all Critical and Important with new ~"backlog::triage" to include into existing Bug triage process. 3. label all Standard issues (remaining) with ~"backlog::no-commitment" 4. EMs and PMs  to modify label to ~"backlog::prospective" all maintenance issues  that are  current, still relevant, and need to remain open 5. Modify all maintenance issues with ~"backlog::no-commitment" to be ~"backlog::to-be-closed" label. <table> <tr> <th> _We appreciate your input and contribution to improving our product. Our current focus is prioritizing our efforts to align with our product strategy. If you believe this maintenance issue should be prioritized, please share your input on the issue, or it will be closed in the next 2 weeks._ </th> </tr> </table> 6. After 2 weeks, * close all maintenance issues with ~"backlog::to-be-closed" that are without any activity (both comments and upvotes) and modify the label to ~"backlog::no-commitment" * apply ~"Community Interest" label to all issues that do have activity and modify the label ~"backlog::no-commitment" <table> <tr> <th> _This issue is closed as part of _[_GitLab’s Healthy Backlog Initiative_](https://about.gitlab.com/blog/inside-gitlabs-healthy-backlog-initiative/)_. If you believe this maintenance issue remains relevant and should be prioritized, please share your input and reopen the issue._ </th> </tr> </table> 7. Monitor regularly for any activity after closure and may reopen and add ~"Community Interest" to prevent repeated closing. <table> <tr> <th> Customer Impact Score  Data points collected: * Support ticket IDs (from comments and labels) * Production incident references * Number of linked/related issues * Customer mentions in comments Score = Support Tickets x 5 + Production Incidents x 10 + Active Related Issues x 3 + Customer Comments x 2 </th> </tr> </table> ##### # New issues ##### Action: 1. Classify the issues with the existing AI triaging bot into one of 3 types ( ~"type::bug" , ~"type::feature" , or ~"type::maintenance"), and label with `group::` label. Apply the ~"automation:ml" label used to track the burn down without flooding the other buckets with AI-classified issues. 2. Regular [triage process](https://handbook.gitlab.com/handbook/product-development/how-we-work/issue-triage/) will address adding backlog commitment label ( ~"backlog::no-commitment" or ~"backlog::prospective") for all types and for bugs and maintenance issues add severity label. 1. Bugs 1. Needs at least 1 more reproduction - label with all labels that apply: ~"reproduced on GitLab.com", ~"reproduced on GitLab Self-Managed", ~"reproduced on GitLab Dedicated", ~"reproduced on GitLab Dedicated for Gov" 2. Otherwise auto-closed after 3 months if severity not S1 or S2 2. Features 3. For Maintenance - those labeled with ~"backlog::triage" 3. Bot processing for maintenance issues to use Customer Impact Scoring (defined above) to label 1. all Critical and Important with new ~"backlog::triage" . 2. all Standard as ~"backlog::no-commitment"