> If they are truly private, then moving to a new class no longer makes them private.

In this instance, I think they're only private because they're on a controller that has other responsibilities (dispatch primary). I think it's okay, desirable even, for these methods to be public when extracted. By making them public, I think we'll be able to move some of the branching contexts out of the controller spec into the specs for the extracted objects.

> While I agree the refactoring would be the right approach, it just seems a bit odd and against how the current PRs have been recommended. If we are trying to keep PRs focused on the problem it solves, a refactor should be a separate commit/PR rather than munged with this.

I see what you mean.

A separate commit might work nicely in this instance and balance the need for focus and continual improvement.

On other occasions, I'd certainly welcome refactoring only PRs if the intent behind the refactoring is expressed clearly. Perhaps we could try a lead-in refactor PR to a future change?

> The 2 lines of code added here become lost in the refactoring which seems the wrong approach. The same is true for the spec.

I'm not sure I totally follow this. Would this still be the case if the refactor were a separate commit?

Our hope here was to see some surrounding logic extracted from the controller and its specs, prior to changing/adding functionality to it, since it's starting to get a little heavy. Alternately this could be done after the fact. 

Either way I think we'll end up with 1 commit that lines up nicely with the primary intent of the PR.