When to create follow-up technical debt issues
What does this MR do?
This MR adds guidelines for maintainers to follow when accepting the resolution of a review comment as a "follow-up issue with technical debt".
At the time of writing, the gitlab-org group has 956 open ~technical debt issues. Of those, 109 have the title "Follow-up from...".
The intent of this MR is to encourage maintainers to think more carefully about when they accept this form of resolution during a review. Many of these issues relate to trivial changes that do not deserve their own issue, and which will struggle to be scheduled - ever. Some are approaching 18 months old. During that time, the underlying code may change significantly. The value of having these issues open, in short, is close to nil.
A compromise is sought between delaying features to address technical debt, and allowing technical debt to go unsolved over the long term. This is a first pass at wording, and may need changes to ensure we don't over-prioritise technical debt, but I don't think we can continue to create these issues as we do today.
ccing basically all the maintainers, plus some
What are the relevant issue numbers?
Does this MR meet the acceptance criteria?
-
Changelog entry added, if necessary -
Documentation created/updated -
Tests added for this feature/bug -
Conforms to the code review guidelines -
Conforms to the merge request performance guidelines -
Conforms to the style guides -
Conforms to the database guides