Contributions
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.
0. I might not need help
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.
1. Talk to me before you begin
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.
2. Keep it simple
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.
3. Keep it small
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).
4. Be mindful of licenses
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.