When changing an outdated part of our code (e.g. HAML views, jQuery modules), use discretion on whether to refactor or not. For long term maintainability, we are very interested in migrating old code to the consistent and preferred approach (e.g. Vue, GraphQL), but we’re also interested in continuously shipping features that our users will love.
    Aim to implement new modules or features with the preferred approach, but changing preexisting non-conforming parts is a gray area.
    If the weight of refactoring and other constraints (such as time) risk threatening the availability of a feature, then strongly consider refactoring at another time. On the other hand, if the code in question has hurt availability or poses a threat to it, then strongly consider prioritizing refactoring. This is a balancing act and if you’re not sure where your change should go (or whether you should do some refactoring before hand), reach out to another Engineer or Maintainer.
    If it makes sense to refactor before implementing a new feature or a change, then please:

    1.   - Create separate merge requests for the refactoring and change. This aids maintainability and code review.
    2.   - Notify your engineering manager and relevant stakeholders (preferably in an issue comment) of the relevant scope increase and rationale.

    If it is decided not to refactor at this moment, then please:

    1.   - Make sure a descriptive "technical debt" issue exists for this refactoring.
    2.   - Notify your engineering manager so that the refactoring issue can be weighted and scheduled.