@RohitGupta why are you looking at it? Stop if it does not help to implement a feature.

Prototype may include any changes including those that help with understanding, do whatever is necessary, but no more.

@Ewan what are comments for your refactoring commits? Do they mention features? Explain why the refactoring was done? What is the percentage of refactoring commits without any relationship to a feature? I beleive if you really look carefully, those commits would be a part of feature/bug implementation. This is what I mean by "refactoring does not exist".

I think people are getting hung up on the very first sentence: "refactoring doesn't exist." If you ignore the TLDR, I think this answer is really good advice. If I understand your answer correctly, it's not that refactoring doesn't exist, it's that you need a goal, and it's hard to find a goal without doing some changes first before you scrap your work and start over. Experiment first.

And Basilevs, refactoring means changing the code without changing it's behavior (ignoring other distinctions like changes to code structure being "not refactoring"). Refactoring absolutely does exist, and your answer will continue to be down voted because of that assertion. Ignoring the literal interpretation of that first sentence, I do agree that we refactor for bugs and enhancements. You can refractor outside of that, even if it is perhaps premature to do so. It's a technicality that is preventing me from up-voting your answer, and is causing others to down-vote.

@Dess, I think the heart of this answer is that you've done the experiment part, and now you've identified a more optimal structure. This answer is saying you need to split the changes you made in two: one PR to restructure, and a second PR to implement the new feature on top of the new structure. If this is not possible without breaking things then you aren't refactoring; you are rewriting.

@GregBurghardt "refactoring means changing the code without changing it's behavior" - if behavior is unchanged, the code change is unnecessary. And any change is dangerous (may lead to regressions). Therefore, all code changes have to lead to behavior changes. Hence the catchword.

You should research this, starting with @Steve's answer to this question. You have some misunderstandings about what constitutes refactoring.

@GregBurghardt I assumed refactoring is a code change without a change in behavior, but potential changes in structure. It is hard to misinterpret. It would be nice if someone pointed out my misunderstanding in more detail. I guess I'll reread Steve's answer, but so far nothing there contradicts mine (except invalid rationales).

Yep, I've reread Steve's answer. He keeps trying to rationalize an unnecessary refactoring referring to intuition. This is a poor argument, but otherwise our answers have no direct contradictions.

"Therefore, all code changes have to lead to behavior changes." — Be careful not to jump too far ahead. Even if the ultimate goal is to change something, the actual commit in version control doesn't change outward behavior. Potentially that change can be merged in safely provided you have good enough test coverage. (1/2)

(2/2) A high priority bug might take you away from a feature. Now that refactoring commit goes to production without the associated feature implementation. A prerequisite for refactoring is having enough test coverage to feel confident you haven't introduced a regression. That's why refactoring exists. Done right it can be done by itself safely so you can respond to changing priorities without leaving a bunch of work in progress.

@GregBurghardt Well, we are not talking about commits here, so this should be fine, right?

@GregBurghardt A refactoring that lost its "client" to the next release is not a big deal. Just the one, where there is no "client" in sight is.

I don't see how losing a related change in the next release is "done by itself". Such refactoring is still a part of a plan. It is not by itself. The specific timings of plan items are irrelevant.