<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=384880) </details> <!--IssueSummary end--> <!-- This template is a great use for issues that are feature::additions or technical tasks for larger issues.--> ### Proposal <!-- Use this section to explain the feature and how it will work. It can be helpful to add technical details, design proposals, and links to related epics or issues. --> While working on a project you would sometimes want to consult your team mates on how to implement specific piece of code. It's like you would want to add code review comment by yourself, which you can eventually do, but you have to wait till you push your changes and create merge request. It's easy to forget all the little doubts you might have and questionable fragment of code can be lost in the bulk of a push. I think it would be great if we had mechanism somewhat similar to `TODO` comments, which are nowadays interpreted by IDEs and documentation generators to help you track todos, but targeted at the code review level. Such comments could be interpreted by GitLab and turned into code review comments. Before the merge all such comments would need to be removed. Optionally GitLab could refuse to merge a branch with `TODO`, `FIXME` and similar comments. Use case examples: ``` // CODEREVIEW: should this function return Future<bool?> or rather Future<bool>? Future<bool?> test() { return someFuture() .then((value) => Future<bool?>.value(value)) .catchError((e) { return null; }); ``` ``` if (!ptr) // @codereview should we use abort() or rather exit() here? std::abort(); ``` I know this is pretty large and complex, hence I would want to know your opinion. Just an idea. <!-- Consider adding related issues and epics to this issue. You can also reference the Feature Proposal Template (https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/issue_templates/Feature%20proposal%20-%20detailed.md) for additional details to consider adding to this issue. Additionally, as a data oriented organization, when your feature exits planning breakdown, consider adding the `What does success look like, and how can we measure that?` section. --> <!-- Label reminders Use the following resources to find the appropriate labels: - https://gitlab.com/gitlab-org/gitlab/-/labels - https://about.gitlab.com/handbook/product/categories/features/ -->