On a similar vein, I've set a new rule for tech debt:
When writing code, make it work, and commit.
Before raising a MR, clean it, and commit. If you see TODO in the file you're about to check in, do it (or delete it), and commit.
When reading an MR, if there's glaring bugs, pass back to the author. If you think the implementation could have been better, discuss it with the author. If the discussion results in something to do, the reviewer adds a TODO comment, and checks that in before merging. If there aren't at least 2-3 commits, ask the author why.
As a result, when we estimate work, we will now be taking account of the number of TODOs in the project, and slightly increasing the estimate because we know there's more work involved than simply what the ticket says.
I don't know how the experiment will pan out, but it's worth a shot in my book.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
On a similar vein, I've set a new rule for tech debt:
As a result, when we estimate work, we will now be taking account of the number of TODOs in the project, and slightly increasing the estimate because we know there's more work involved than simply what the ticket says.
I don't know how the experiment will pan out, but it's worth a shot in my book.