Is this method still logically part of the class interface? If so, you’ll want to put it in proximity to the class itself somehow. That could be as a member, as a static method of a related utility class (including extension methods if your language has such a thing, e.g. C#), or a free function in the same package/namespace as the class, if your language supports that (e.g. C++).

But if it isn’t really that inherently bound to the class, maybe somewhere else is a better place.

In general, I wouldn’t give a class a static method that takes a single instance parameter. In most languages, that method isn’t any more restricted in what it can access (usually can access private members), so it’s just a syntactic burden on the caller.

I tend to use the concepts of coupling and cohesion to decide what goes in any specific class/interface/module/etc. Low coupling and high cohesion are what you want.

Coupling is pretty easy to understand. But I find that many developers have trouble with cohesion. Basically, “cohesion” is like the old Sesame Street song, “One of these things is not like the others…” In a class with high cohesion, everything seems to belong together.

(Also, to be pedantic, I’d say this is more about how you “design” OO code rather than “organize” it — where organization would be more about how you order methods, name packages, etc.)

If it uses private fields, properties or methods just keep it non static. Passing in an instance variable just adds noise.

I do tend to make methods static if I can (without passing instances in), it signals opportunity to cheaply move the method elsewhere if needed.

When in doubt leave the static out.

Static if it’s not relevant to the instance. That you would want to pass an instance means it is instance relevant so no.

Private if at best it does nothing more than confuse people trying to re-use your class when exposed to them. The whole point is to bury how it works and just give people easy to understand, well-labeled buttons to press.

Think first about what you want to expose to somebody else using your class. And pay attention to public APIs on stuff that you like working with best for some ideas of what works well.

The only reason to typically use an extended method is if you have a variety of classes that you want to all have the same standard set of methods. There are people out there extending and implementing for all kinds of reasons and complex patterns d’jour but it’s bad OOP and in most cases they should probably stop.

Keep everything as simple and clean as it needs to be. It’s always easier to make your classes more complex moving forward than it is to maintain a code base chock full of stuff that didn’t need to be there. The less there is to look at, the more clear your intentions are, and the easier it is to maintain/modify without everything blowing up in your face.

I’m not talking about any language-specific OO words (static, private, etc.).

If you have a method that doesn’t need access to any non public fields, properties or methods where should you put the method ?

If the code is not related with any class in your domain, then it can be a simple function, outside a class scope. A dumb example is factorial or even fibonacci, either just receives a value and computes a result, doesn’t belonging to any class in special.
If the code is some kind of factory or has something else related with a certain class, then it can be a static or class method, or even another class.

It’s important to note that if your language allows pure functions, not just classes and methods, then you can take advantage of it and make your design more simple (for me, it’s one of the major drawbacks of the Java language, but it’s just my personal opinion).