kotovalexarian-likes-gitlab
/
gitlab-org--gitlab-foss
1
0
Fork 0
Code Releases Activity

When to create follow-up technical debt issues

This commit is contained in:
Nick Thomas 2018-10-16 10:39:01 +01:00
parent e657c9a9e6
commit d5ef55976a
No known key found for this signature in database
GPG Key ID: 2A313A47AFADACE9
1 changed files with 22 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

22
doc/development/contributing/issue_workflow.md
View File

@ -315,6 +315,28 @@ for a release by the appropriate person.
Make sure to mention the merge request that the ~"technical debt" issue or
~"UX debt" issue is associated with in the description of the issue.
## Technical debt in follow-up issues
It's common to discover technical debt during development of a new feature. In
the spirit of "minimum viable change", resolution is often deferred to a
follow-up issue. However, this has limited value unless a commitment to address
the debt is made. As technical debt reduces development velocity, it's important
to keep it under control.
Before accepting resolution of technical debt in a follow-up issue, maintainers
should check that that fix is not trivial, and that the contributor (or their
team) can commit to scheduling the issue within the next 3 releases.
Trivial fixes can - and should - be addressed within the same MR.
If a commitment to address the issue in the foreseeable future cannot be found,
the maintainer must make a value judgement on whether the problem deserves an
issue at all. If the commitment is lacking because the issue is neither trivial
nor valuable, then perhaps no issue needs to be made after all. If a commitment
is lacking because technical debt is being unfairly neglected, then maintainers
should generally insist on resolution of the issue upfront, to protect
development velocity.
## Stewardship
For issues related to the open source stewardship of GitLab,