stringy/CONTRIBUTING.md

# Contributing to Transcriptase
We love your input! We want to make contributing to this project as easy and transparent as possible, whether it's:

- Reporting a bug
- Discussing the current state of the code
- Submitting a fix
- Proposing new features
- Becoming a maintainer

## Any contributions you make will be under the MIT Software License
In short, when you submit code changes, your submissions are understood to be under the same [MIT License](http://choosealicense.com/licenses/mit/) that covers the project. Feel free to contact the maintainers if that's a concern.

## Report bugs using Github's [issues](https://git.internal/re/stringy/issues)

A relevant coding style guideline is the [Go Code Review Comments](https://code.google.com/p/go-wiki/wiki/CodeReviewComments).

Documentation
-------------

If you contribute anything that changes the behavior of the application, 
document it in the follow places as applicable:
* the code itself, through clear comments and unit tests
* [README](README.md)

This includes new features, additional variants of behavior, and breaking 
changes.

Testing
-------

Tests are written using golang's standard testing tools, and are run prior to 
the PR being accepted.

Issues
------

For creating an issue:
* **Bugs:** please be as thorough as possible, with steps to recreate the issue 
  and any other relevant information.
* **Feature Requests:** please include functionality and use cases.  If this is 
  an extension of a current feature, please include whether or not this would 
  be a breaking change or how to extend the feature with backwards 
  compatibility.
* **Security Vulnerability:** please report it at 
  https://my.xfinity.com/vulnerabilityreport and contact the [maintainers](MAINTAINERS.md).

If you wish to work on an issue, please assign it to yourself.  If you have any
questions regarding implementation, feel free to ask clarifying questions on 
the issue itself.

Pull Requests
-------------

* should be narrowly focused with no more than 3 or 4 logical commits
* when possible, address no more than one issue
* should be reviewable in the GitHub code review tool
* should be linked to any issues it relates to (i.e. issue number after (#) in commit messages or pull request message)
* should conform to idiomatic golang code formatting