Standardize technical debt labelling and planning process

Goal

GitLab needs to have a sustainable system for managing technical debt, improving code quality, and maintaining engineering velocity in the long term.

Problem

We need to establish a clear, consistent approach to labelling and planning technical debt across GitLab. This issue aims to address the following points:

1. Define technical debt:
   • Clarify the difference between intentional technical debt and regular maintenance work
   • Establish criteria for what qualifies as technical debt
2. Labeling system:
   • Reintroduce the ~tech debt (or maybe ~maintenance::tech debt) label for intentional technical debt
   • Define how this label interacts with existing labels like ~type::maintenance and ~maintenance::refactor
   • Consider using severity labels (S1-S4) for prioritization - like what Verify is doing.
3. Planning and tracking:
   • Implement a process for tracking technical debt over time
   • Set guidelines for adding due dates to follow-up issues
   • Establish a regular review process for technical debt issues
4. Metrics and reporting:
   • Develop metrics to measure technical debt accumulation and payoff
   • Create reports to help teams manage their technical debt effectively
5. Communication and visibility:
   • Improve visibility of technical efforts across the organization
   • Consider implementing tech-focused presentations or town halls
   • Consider ways to share/present proposals from architecture design docs

Context

This issue was extracted from a conversation that started on Slack (internal link).