May 15, 2011
Lately I've gotten several very large contributions to Flare (code and art) that I've had to reject. I don't like doing that. So here are guidelines to helping the project.
Before I talk about doing a contribution the right way, realize that I may not need your contribution at all. This project is different than some free/libre projects that need contributors -- I can do most of it on my own, and I enjoy doing most of it on my own.
If you are looking to actively contributing to projects, I can point you to several other free/libre RPGs that are looking for help.
When I do need help or input on a specific task, I will put out a call for help -- often with an attached commission fee.
If you don't talk to me first, your large patch of code might break something else I was working on. Or it might not be the right time -- it's a feature that might have to be added later for various reasons. Or it might be something I had planned to do a different way. Your art contribution might not follow specifications or follow the art direction I have in mind.
Save yourself plenty of effort and contact me before you begin. If I like your contribution idea, I will give you plenty of specifications and guidelines towards a useful contribution.
This applies mostly to code. I'm intentionally keeping the Flare code very simple. If you have a patch that adds a lot of complexity to the codebase, I will probably reject it without taking the time to comprehend it.
I want the code to be simple so that it's easy to comprehend. Especially for game programmers who are just getting started. But also, I will have to maintain this code, and simple code is easier. I vastly prefer Composition to Inheritance. I prefer implementing a small feature rather than including a new bulky dependency.
Don't sent patches that add several features simultaneously. If I like one change but not the others, now I have to perform surgery on your patch. My time is very limited; I could be making other features instead. It is often better for me to reject the entire patch.
If I already like your feature idea but it requires changing a lot of code, consult me on the timing of it. It will be harder to add your patch into a rapidly changing code-base if it is very large. I may ask you to wait to implement the feature until later, when those areas of code will be more stable (or when I'm working on different areas of the project).
I have to be very strict about licensing issues. I can only take GPL v3 code or compatible, and I can only take CC-BY-SA 3.0 art or compatible. If you're unsure about what this means, please contact me.