1# Contributing 2 3## Submitting Issues 4 5* If your issue is that libsndfile is not able to or is incorrectly reading one 6 of your files, please include the output of the `sndfile-info` program run 7 against the file. 8* If you are writing a program that uses libsndfile and you think there is a bug 9 in libsndfile, reduce your program to the minimal example, make sure you compile 10 it with warnings on (for GCC I would recommend at least `-Wall -Wextra`) and that 11 your program is warning free, and that is is error free when run under Valgrind 12 or compiled with AddressSanitizer. 13 14## Submitting Patches 15 16* Patches should pass all existing tests 17* Patches should pass all pre-commit hook tests. 18* Patches should always be submitted via a either Github "pull request" or a 19 via emailed patches created using "git format-patch". 20* Patches for new features should include tests and documentation. 21* Commit messages should follow the ["How to Write a Git Commit Message"](https://chris.beams.io/posts/git-commit/) guide: 22 1. Separate subject from body with a blank line 23 2. Limit the subject line to 50 characters 24 3. Capitalize the subject line 25 4. Do not end the subject line with a period 26 5. Use the imperative mood in the subject line 27 6. Wrap the body at 72 characters 28 7. Use the body to explain what and why vs. how 29 30 Additional rule: the commit message may contain a prefix. The prefix must 31 contain the name of the feature or source file related to the commit and must 32 end with a colon followed by the message body. 33 34 Examples of good commit messages: 35 1. Fix typo 36 2. Update CHANGELOG.md 37 3. Add ACT file format support 38 4. ogg_vorbis: Fix granule position when seeking Vorbis streams 39 40 Examples of bad commit messages: 41 1. Fixed bug (rule 5) 42 2. update docs (rule 3) 43 3. Add very cool feature. (rule 4) 44 45* Patches to fix bugs should either pass all tests, or modify the tests in some 46 sane way. 47* When a new feature is added for a particular file format and that feature 48 makes sense for other formats, then it should also be implemented for one 49 or two of the other formats. 50