Allow configuration of user settings to disable or better control automatic resolution of TODO
Problem to solve
Control of automatic TODO dismissal.
Intended users
I'd use it. Developers, Release Managers, pretty much everyone I think might have reasons for essentially "bookmarking" certain issues or MRs.
Further details
When I first began to use the TODO feature in GitLab I struggled with the items I was adding seemingly disappearing from the list for no apparent reason. Later I found out that if an issue is marked as a TODO and you so much as comment on it, that the TODO gets automatically cleared. This broke my mental model for TODO as I had intended to use the TODO feature to keep an eye on that issue until it a MR or some other resolution came out of it. It wasn't an issue I was working on so it didn't make sense for it to be assigned to me. I see no other way to keep tabs on an issue other than flipping the notification setting. However notifications only happen when something triggers them, I wanted to keep the TODO to remind myself in the future about the issue if nothing changed on it for a few days. So that it wouldn't fall off my radar.
It would be nice if I could make it so TODO only clear if I manually clear them. However there are probably still some cases where automatic TODO dismissal would be preferred. For example if I personally merge an MR that I have marked as a TODO, it's probably reasonable for that to automatically dismiss my TODO. Or maybe not? It depends on the user's preference I suspect. I can imagine a reason I may want a TODO to persist on an MR even after I've merged it: Keeping track of a post-merge pipeline, for future reference, etc...
More control over the cases where a TODO is cleared would be the strongest option. A simple off/on for automatic TODO dismissal would probably satisfy me as a MVC.
Proposal
Put the settings in the user's personal account settings.
Permissions and Security
The typical security associated with a user's profile/account settings.
Documentation
Yes, certainly there should be some associated updates to documentation if implemented.
Availability & Testing
No risks.
What does success look like, and how can we measure that?
If the option is available in any capacity to do this I would consider it a win. I suppose we could instrument the option to see if anyone uses it but honestly it seems such an easy fix and users would probably only go in and change it once, ever.
What is the type of buyer?
Core/Free.
Links / references
n/a