Depends on each situation, the overall plan is to do as you go, for many reasons (better return of investment of time, no production down time .. I wrote more about how I do it on my blog )
But if you are requested to make a big feature improvement on a module that doesn't support it (the time to add the new fuctionality is longer than a refactor and to add it), you have to plan the refactor then do the task.
I usually don't keep a list of TODO, the ones you will hit more often (count the courses per module), is most likely to get refactored quicker. For the bigger refactors we put in the planning tasks, a big technical debt tasks and tell the manager to make it a pre-requirement before any big task on that module.
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.
Depends on each situation, the overall plan is to do as you go, for many reasons (better return of investment of time, no production down time .. I wrote more about how I do it on my blog )
But if you are requested to make a big feature improvement on a module that doesn't support it (the time to add the new fuctionality is longer than a refactor and to add it), you have to plan the refactor then do the task.
I usually don't keep a list of TODO, the ones you will hit more often (count the courses per module), is most likely to get refactored quicker. For the bigger refactors we put in the planning tasks, a big technical debt tasks and tell the manager to make it a pre-requirement before any big task on that module.