How should the key schedule be designed for this general block cipher? After looking at the Wikipedia page for the Fiestel cipher, I thought about making a variation of it that is very general.

I basically followed the diagram on Wikipedia in order to structure the algorithm. The way my algorithm encrypts messages follows this diagram (the decryption is just the reverse method as seen in Wikipedia):



In case the diagram fails to let you know what is going on, I have made an implementation in python without a strong key scheduling method here.

The main question I have is what key schedule method should I create/use/adapt for this cipher? A side question is any general improvements that could be done. The key schedule needs to be able to generate an arbitrary amount of keys and be able to take an arbitrary length key.
It's not a good idea to assume that your F-function is strong by itself. With very few exceptions, it's not true even with professionally-designed Feistel networks. In fact, the reason Feistel networks are even needed is because they're used to build a secure PRP from an insecure PRP or PRF. Said insecure function must be designed so that it is extremely lightweight and is secure after sufficient iterations.

Without more information, no one can tell you how to design a key schedule. They're generally tightly integrated with the rest of the cipher. All we can do is give you possible designs that would be inefficient but would work, or which would only be secure assuming your F-function is a strong PRF (which is quite an assumption). You have to think about a few things when designing a key schedule:


Do you need key agility and if so, how light must the key schedule be?
How does it interact with the rest of the cipher (this is a very complex question)?
What is your maximum memory and ROM footprint?
Is side-channel resistance important to you?
What kinds of operations do you wish to implement it in?


If you are not making any assumptions about the F-function, then you could use an algorithm like HKDF to expand an input master key into an arbitrary number of subkeys. If you do assume that the F-function is a strong PRF, which it very likely will not be, then the key schedule could be as trivial as XORing a round counter (functioning as a round constant) with the key to derive each round key. That would be necessary to avoid the slide attack, but relies on assumptions about the F-function's security.