Right now, Flow is in its very early stages and will undergo constant, major changes to its overall structure. This will make it difficult to contribute, but not impossible.
Here are a few basic rules on contributing to this project:
-
Don't just try to implement large features
- As my Computer Science professor once said, "If you were gonna eat an elephant, you wouldn't eat it all at once - you'd eat it one bite at a time". It's a silly analogy, but it has a bit of truth to it: don't tackle big problems all at once!
- If you want to contribute to a specific feature (like physics, lighting, shaders, etc.) there should be a branch for that feature that has its own rules for contributing. Those rules will be listed below. If there is no branch, then the feature hasn't begun development then!
- Start with smaller contributions (i.e. bug fixes). You gotta earn our trust in order to work on the big stuff :)
-
Don't git too crazy
- Let's make each contribution small ones - for example, one bug fix per contribution.
- Don't make a bunch of changes in a bunch of different areas all at once. Help other developers make sense of what you're actually contributing.
-
Keep a data-oriented mindset
- This project uses a data-oriented design approach to project structure. That means, no object-oriented programming. (Please note that, because the project structure will change, there is no philosophy on how a component is implemented.
- If you know nothing about data-oriented design, read up on it before you contribute! Check out this repo that contains a list of resources you can use to learn about how DoD works. I personally recommend the Data-Oriented Design Book by Richard Fabian.
-
Give suggestions before you submit code
- If you have an idea on how a certain part of the project should be structured, or you've got tips on how to best implement a feature, then please create an issue with your suggestions!