To me refactoring doesn't need a whole book or set of terminology. So long as a person understands and values the principles the individual refactorings will come naturally with experience. In my view it comes down to three main points.

1. Refactoring does not change functionality. The observable behavior should be the same before and after.

2. Refactoring should be done one step at a time. Each step should be as small as possible and obviously correct.

3. When changing code, at any given time you should be working on a functional change or refactoring - never both at once. Ideally these should be split into separate commits as well.

I think beyond the principles something like extracting a chunk of code into a separate function is not a task that needs a proper name. It's just something that comes naturally once you get into a mindset of always making things better, or as we say where I work: "suck less." It's getting into this mindset that takes the most work. If every time I deploy code it sucks less, or even just on average, that's good enough.

Refactoring is compound interest for maintainability. Once people buy into this everything starts getting better.

I also believe that you should never ask permission to refactor - just do it. A gardener who's task is to mow the lawn shouldn't ask permission before pulling a weed just because it's outside the narrow scope of the task at hand. Likewise a programmer should not ask permission before refactoring code (excluding large, time consuming refactors).