I had heard of that idea before, and then forgot about it. Thank you for reminding me; I will be implementing that at work when I can find the time to add it to

I had heard of that idea before, and then forgot about it. Thank you for reminding me; I will be implementing that at work when I can find the time to add it to the pipeline (ie. "todo: enforce ticketed todos"). To me there are three variants of todo: 1. Personal and immediate todos. These MUST be resolved before I can even commit to VCS. This isn't a standard "todo"; rather, it marks a section of code which I've left incomplete while I jump around the code base to work on other things. I don't use "@todo" as the tag here; I use "@first-real-name" (eg. "@joe"), as JetBrains' IDEs let you define custom TODO tag names and then filter based on them. Thus, "@joe" has never made it into a commit to the VCS, as I always ensure these are resolved before I commit. 2. A true todo that is actionable, and has an extremely realistic (not idealistic) expectation that it must, or really-really-REALLY should, be worked on in the VERY near future. This is the kind of todo that would require a ticket. 3. Todos that are hypothetical, imaginative, or dreamy; ie; "I wish priorities allowed me to spend another $X days/weeks/months on this". Obviously, this is the entire reason why requiring tickets for todos is beneficial; these kind of todos need to be cut down and eliminated. It can be so hard to "give up" on something you know could be improved, but that realistically you'll never come back to on the company's dime. I'd also like to see alerts based on the datetime when a new todo was committed to the central repository. If a todo sits in code for more than 3 months, I want that alerted. Either the ticket needs to be prioritized, or the todo needs to be deleted.