Thanks for your interest in this project!
This document consists of guidelines to assist you in contributing to this open source project.
If you have an idea for a feature, improvement or bug fix, you may want to discuss with us first by submitting an issue before doing the actual work. This is particularly true with ideas that might expand the scope of mamba beyond its mission of parsing, validating and writing HTTP Live Streaming (HLS) playlists.
We would love to read your pull request. The team at Comcast is focused on making this project work for our customers and environment, but would love for this project to support as many people and projects as possible. We cannot do that without contributions from other teams and individuals.
By participating in this project, you are agreed to abide by our code of conduct
Your code doesn't have to be perfect! Do your best (try to follow our guidelines) and submit a pull request. We'll work with you to make sure it fits properly into the project. (If you've never made a pull request, it's simple. Github has a tutorial here.)
Following the project conventions will make the pull request process go faster and smoother.
We try to follow the swift.org style guidelines
All code should be in Swift 4 (unless fixing something in the C/Objective-C Parsing code).
Methods should be short. Try to make your changes look like the surrounding code.
All public methods and data should be documented
Make each pull request as small as possible. For example, if you're adding three validation improvements, make each a separate pull request. If you're adding interdependent or related changes, make a pull request for each, starting at the lowest level.
Make sure all existing tests pass. If you change the way something works, be sure to update tests to reflect the change. Add unit tests for new code.
Tests should cover both "happy path" and failure scenarios.
Every line of code that can be tested should be tested.
Try to make your commit messages follow git best practices.
- Separate subject from body with a blank line
- Limit the subject line to 50 characters
- Capitalize the subject line
- Do not end the subject line with a period
- Use the imperative mood in the subject line
- Wrap the body at 72 characters
- Use the body to explain what and why vs. how
This makes it easier for people to read and understand what each commit does, on both the command line interface and Github.com.
Don't let all these guidelines discourage you. We're more interested in community involvement than perfection.
Thanks again for your support!