Guidelines for contributing to GSS.
Issues are most appropriate for bugs and other problems encountered using GSS. Ideally, include a demo project (GitHub repo, CodePen, JSFiddle, etc) that focuses on the issue.
Please search existing issues before filing new ones.
Pull requests should be issued from dedicated branches, as opposed to master.
It may be worth opening an issue to discuss feature requests and major changes before attempting to implement them.
Prefixing a pull request with [WIP] and committing early is a good way to get feedback without too much investment.
When questions are asked, consider providing an answer by opening a pull request against the GSS documentation.
Dependencies should be referenced by an appropriate version number or tag and never by overly-permissive references such as branch names or *. In the case that a dependency has no available versions or tags, use a git commit SHA.
Releases should always be made from master and follow semantic versioning.
References in code to the version number should be updated before building for distribution and tagging a new release.
Prefer using the GitHub UI and provide useful release notes.
Lastly, releases should be published to npm by running npm publish.