### Problem to solve Developers are increasingly making [sparser code comments](https://dev.to/adammc331/todo-write-a-better-comment-4c8c), but one big use-case is for TODO comments. In this pattern developers might use: > //TODO: Update docs for merge trains But it would be more SSOT to write > //TODO: gitlab-ce!29771 Right now there is no great way to build a single source of "code commented" issues that would be easier for developers to pick up and complete since they know exactly where in the code the issue should be added. ### Intended users **App Developers:** App developers could more easily keep track of where they are leaving additional todo work in code being able to quickly return to the context that the todo was added. **Community Contributors:** Community contributors interested in contributing to projects could find issues that would be good initial contributions. **Engineering Managers:** Engineering managers who wanted to assign on-boarding tasks could find issues associated with code comments as potential "low hanging fruit." ### Further details **Use Case** - Add a comment * As an application developer, in order to keep my comments single source of truth, I should be able to create and reference a follow-up MR or issue directly in the code where I know it should reside. **Use Case** - Find comment issues * As a community contributor or engineering manager I should be able to quickly reference a set of issues or MRs that are marked as TODO in my project's code. ### Proposal Parse project code for the TODO: ! and TODO: # regular expressions and tag them with a ~Code-Comment label. ### Permissions and Security <!-- What permissions are required to perform the described actions? Are they consistent with the existing permissions as documented for users, groups, and projects as appropriate? Is the proposed behavior consistent between the UI, API, and other access methods (e.g. email replies)? --> ### Documentation <!-- See the Feature Change Documentation Workflow https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html Add all known Documentation Requirements here, per https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html#documentation-requirements --> ### Testing <!-- What risks does this change pose? How might it affect the quality of the product? What additional test coverage or changes to tests will be needed? Will it require cross-browser testing? See the test engineering process for further guidelines: https://about.gitlab.com/handbook/engineering/quality/guidelines/test-engineering/ --> ### What does success look like, and how can we measure that? <!-- Define both the success metrics and acceptance criteria. Note that success metrics indicate the desired business outcomes, while acceptance criteria indicate when the solution is working correctly. If there is no way to measure success, link to an issue that will implement a way to measure this. --> ### Links / references