* [Reporting Non Security Issues](#reporting-other-issues)
* [Commit Messages](#commit-messages)
* [Developers Certificate of Origin](#developers-certificate-of-origin)
## Asking Questions
@ -20,7 +19,7 @@ label.
## Reporting Security Issues
If you have discovered an issue with this code that could present a security hazard or wish to discuss a sensitive issue with our security team, please contact security@z.cash [security.asc](https://z.cash/gpg-pubkeys/security.asc). Key fingerprint = AF85 0445 546C 18B7 86F9 2C62 88FB 8B86 D8B5 A68C
If you have discovered an issue with this code that could present a security hazard or wish to discuss a sensitive issue with our security team, please contact us on [Telegram](https://hush.is/tg) or [Matrix](https://hush.is/matrix)
## Reporting Non Security Issues
@ -30,8 +29,6 @@ We always appreciate a well-written, thorough bug report.
Check that the project issues database
doesn't already include that problem or suggestion before submitting an issue.
If you find a match, add a quick "+1" or "I have this problem too."
Doing this helps prioritize the most common problems and requests.
When reporting issues, please include the following:
@ -43,30 +40,11 @@ When reporting issues, please include the following:
This information will help us review and fix your issue faster.
## Pull Requests
We **love** pull requests!
All contributions _will_ be licensed under the MIT license.
Code/comments should adhere to the following rules:
* Every Pull request must have an Issue associated to it. PRs with not
associated with an Issue will be closed
* Code build and Code Lint must pass.
* Names should be descriptive and concise.
* Although they are not mandatory, PRs that include significant testing will be
prioritized.
* All enhancements and bug fixes need to be documented in the CHANGELOG.
* When writing comments, use properly constructed sentences, including
punctuation.
* When documenting APIs and/or source code, don't make assumptions or make
implications about race, gender, religion, political orientation or anything
else that isn't relevant to the project.
* Remember that source code usually gets written once and read often: ensure
the reader doesn't have to make guesses. Make sure that the purpose and inner
logic are either obvious to a reasonably skilled professional, or add a
comment that explains it.
## Code contributions
We **love** contributions!
All contributions _will_ be licensed under the GPLv3 license.
## Commit Messages
@ -92,16 +70,7 @@ issue following the criteria described in the preceeding sections.
Every contribution must reference an existing Issue. This issue is important
since it will be directly referenced in the title of your commit.
Although we prefer small PR's. We encourage our contributors to use Squash
commits extensively. Maintainers prefer avoiding _merge commits_ when possible.
It is very much likely that _if accepted_, your contribution will be _squash merged_.
When squashing commits, use your best judgement. In some situations, a refactoring may
be done before actual behavior changes are implemented. It is reasonable to keep such
a refactoring as a separate commit as it both makes review easier and allows for
these refactoring commit SHAs to be added to `.git-blame-ignore-revs`.
### Structuring a PR Commit
### Structuring a Commit
#### Commit Title
The first line of your commit message constitutes its _title_. Maintainers will
@ -123,19 +92,13 @@ optionally you can append the PR # between parenthesis.
#### Commit message's body
Use the body of the commit to bring more context to the change. Usually the bulk
of the problem might be explained in the GitHub Issue. It's a good long term strategy
of the problem might be explained in an issue. It's a good long term strategy
not to rely on such elements. If the project were to change its hosting, much of the
associated "Issues" and "pull requests" will be lost, yet the commit history will
probably be preserved and the context will also be.
If there are followup issues for this commit, consider referencing those as well.
**Use the tools on your favor!**
When opening a Pull Request, GitHub will take the title of your commit as the PR's
title and the body of your PR its description. Having a proper structure on your
commit will make your day shorter.
### Example:
@ -160,32 +123,3 @@ and the body will be added as the description of the PR.
Adding the text `Closes #{issue_number}` will tell GitHub to close the issue when the PR is merged.
Let the machines do their work.
## Developer's Certificate of Origin 1.1
By making a contribution to this project, I certify that:
- (a) The contribution was created in whole or in part by me and I
have the right to submit it under the open source license
indicated in the file; or
- (b) The contribution is based upon previous work that, to the best
of my knowledge, is covered under an appropriate open source
license and I have the right under that license to submit that
work with modifications, whether created in whole or in part
by me, under the same open source license (unless I am
permitted to submit under a different license), as indicated
in the file; or
- (c) The contribution was provided directly to me by some other
person who certified (a), (b) or (c) and I have not modified
it.
- (d) I understand and agree that this project and the contribution
are public and that a record of the contribution (including all
personal information I submit with it, including my sign-off) is
maintained indefinitely and may be redistributed consistent with
this project or the open source license(s) involved.
This contribution guide is inspired on great projects like [AlamoFire](https://github.com/Alamofire/Foundation/blob/master/CONTRIBUTING.md) and [CocoaPods](https://github.com/CocoaPods/CocoaPods/blob/master/CONTRIBUTING.md)
