First of all,thank you for checking out and deciding to contribute to the tmf project. All contributions are greatly appreciated.
# Before submitting a pull request
1. Ensure that all tests still pass
2. Run `cargo clippy` to see any lint suggestions
3. Run `cargo fmt` to ensure your code is formatted like the rest of the project
4. Run `cargo doc` to ensure documentation has not been accidentally broken.
## For functionality changes
1. compare size of `suzan.tmf`, which appears after tests in `target/test_res` with previous version, and include this size in the pull request message.
2. Import `suzan_ftmf.obj` from `target/test_res` into blender and ensure it sill looks OK.
# What can you contribute?
## Low hanging fruits
There is some work that, while not world-changing and glamorous, is requires almost no experience, and can ins some cases be tackled by someone who does not even know how to write code at all.
### Fixing/Rewording
While the documentation is in a pretty good place ATM and is perfectly usable, there may be some grammatical/spelling mistakes dotted around. I have dyslexia and am not a native speaker, so those kinds of errors can easily slip trough. Pull requests regarding fixes to those kinds of mistakes should be accepted pretty quickly (they are easy to evaluate and will not set the entire project on fire in case of an error). They should be almost always accepted, unless the *mistake* is just a different, accepted spelling (colour vs color), or the change has some different problems (unintentionally changes meaning of documentation).
### Expanding documentation.
While each and every function in documentation has a short description and an example, this can still be greatly improved.
## Slightly more complex stuff
### Refactoring 
As time goes on, the amount of code in need of refactoring grows. This can cause issues down the line, so refactoring is greatly appreciated. Because this work requires more skill and time to do, more strict checking of pull requests is needed, and accepting/rejecting them may take more time.
## Any optimisations, bug fixes and other changes that **do not** make the file format incompatible or change the API
For optimizations, as long as all tests still pass, there should be no problems with merging. Additionally, some more test regarding the impact on file sizes should be done. Bug fixes and other changes will be put under more scrutiny. But once again, keep in mind that accepting/rejecting the request may take more time. 
## Very Complex Stuff
### API/Format changes 
I am fairly open to API additions/changes, as long as a reason for inclusion is given(This change will make this easier) and the change is backward-compatible. 
### New features
Any feature that adds anything to the file format will be placed under extreme scrutiny. The TMF project tries to be backward compatible as much as possible, so I want to avoid rolling a feature out only to deprecate it in favour of something way better. 
# More questions?
If you have any more questions, feel free to DM me on reddit, or write me an email. I will gladly answer any questions.