1# Contributing to bluemonday
2
3Third-party patches are essential for keeping bluemonday secure and offering the features developers want. However there are a few guidelines that we need contributors to follow so that we can maintain the quality of work that developers who use bluemonday expect.
4
5## Getting Started
6
7* Make sure you have a [Github account](https://github.com/signup/free)
8
9## Guidelines
10
111. Do not vendor dependencies. Vendoring is a project problem, not a package problem.
122. I do not care about spelling mistakes or whitespace and I do not believe that you should either. PRs therefore must be functional in their nature or be substantial and impactful if documentation or examples.
133. This module does not participate in hacktober, please make your contributions meaningful.
14
15## Submitting an Issue
16
17* Submit a ticket for your issue, assuming one does not already exist
18* Clearly describe the issue including the steps to reproduce (with sample input and output) if it is a bug
19
20If you are reporting a security flaw, you may expect that we will provide the code to fix it for you. Otherwise you may want to submit a pull request to ensure the resolution is applied sooner rather than later:
21
22* Fork the repository on Github
23* Issue a pull request containing code to resolve the issue
24
25## Submitting a Pull Request
26
27* Submit a ticket for your issue, assuming one does not already exist
28* Describe the reason for the pull request and if applicable show some example inputs and outputs to demonstrate what the patch does
29* Fork the repository on Github
30* Before submitting the pull request you should
31 1. Include tests for your patch, 1 test should encapsulate the entire patch and should refer to the Github issue
32 1. If you have added new exposed/public functionality, you should ensure it is documented appropriately
33 1. If you have added new exposed/public functionality, you should consider demonstrating how to use it within one of the helpers or shipped policies if appropriate or within a test if modifying a helper or policy is not appropriate
34 1. Run all of the tests `go test -v ./...` and ensure all tests pass
35 1. Run gofmt `go fmt ./...`
36 1. Run vet `go vet ./...` and resolve any issues
37* When submitting the pull request you should
38 1. Note the issue(s) it resolves, i.e. `Closes #6` in the pull request comment to close issue #6 when the pull request is accepted
39
40Once you have submitted a pull request, we *may* merge it without changes. If we have any comments or feedback, or need you to make changes to your pull request we will update the Github pull request or the associated issue. We expect responses from you within two weeks, and we may close the pull request is there is no activity.
41
42### Contributor Licence Agreement
43
44We haven't gone for the formal "Sign a Contributor Licence Agreement" thing that projects like [puppet](https://cla.puppetlabs.com/), [Mojito](https://developer.yahoo.com/cocktails/mojito/cla/) and companies like [Google](http://code.google.com/legal/individual-cla-v1.0.html) are using.
45
46But we do need to know that we can accept and merge your contributions, so for now the act of contributing a pull request should be considered equivalent to agreeing to a contributor licence agreement, specifically:
47
48* You accept that the act of submitting code to the bluemonday project is to grant a copyright licence to the project that is perpetual, worldwide, non-exclusive, no-charge, royalty free and irrevocable.
49* You accept that all who comply with the licence of the project (BSD 3-clause) are permitted to use your contributions to the project.
50* You accept, and by submitting code do declare, that you have the legal right to grant such a licence to the project and that each of the contributions is your own original creation.