First, inventory the chucks of code, find dependencies, review recent bugs, and come up with a list of areas for possible refactoring. Do a few small test refactors to learn how much it costs (learning the build process, causing "unrelated" failures, etc.)
Then present a list of refactoring candidates comparing their estimated costs and estimated benefits (e.g. foreseeable enhancements, criticality). Include a plan to compare actual costs for refactoring and estimated costs for not refactoring with your plan
Then it's a management decision
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.
First, inventory the chucks of code, find dependencies, review recent bugs, and come up with a list of areas for possible refactoring. Do a few small test refactors to learn how much it costs (learning the build process, causing "unrelated" failures, etc.)
Then present a list of refactoring candidates comparing their estimated costs and estimated benefits (e.g. foreseeable enhancements, criticality). Include a plan to compare actual costs for refactoring and estimated costs for not refactoring with your plan
Then it's a management decision