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