1# Contributing to Vault 2 3**Please note:** We take Vault's security and our users' trust very seriously. 4If you believe you have found a security issue in Vault, please responsibly 5disclose by contacting us at security@hashicorp.com. 6 7**First:** if you're unsure or afraid of _anything_, just ask or submit the 8issue or pull request anyways. You won't be yelled at for giving it your best 9effort. The worst that can happen is that you'll be politely asked to change 10something. We appreciate any sort of contributions, and don't want a wall of 11rules to get in the way of that. 12 13That said, if you want to ensure that a pull request is likely to be merged, 14talk to us! You can find out our thoughts and ensure that your contribution 15won't clash or be obviated by Vault's normal direction. A great way to do this 16is via the [Vault Discussion Forum][2]. 17 18## Issues 19 20This section will cover what we're looking for in terms of reporting issues. 21 22By addressing all the points we're looking for, it raises the chances we can 23quickly merge or address your contributions. 24 25### Reporting an Issue 26 27* Make sure you test against the latest released version. It is possible we 28 already fixed the bug you're experiencing. Even better is if you can test 29 against the `main` branch, as the bugs are regularly fixed but new versions 30 are only released every few months. 31 32* Provide steps to reproduce the issue, and if possible include the expected 33 results as well as the actual results. Please provide text, not screen shots! 34 35* If you are seeing an internal Vault error (a status code of 5xx), please be 36 sure to post relevant parts of (or the entire) Vault log, as often these 37 errors are logged on the server but not reported to the user. 38 39* If you experienced a panic, please create a [gist](https://gist.github.com) 40 of the *entire* generated crash log for us to look at. Double check 41 no sensitive items were in the log. 42 43* Respond as promptly as possible to any questions made by the Vault 44 team to your issue. 45 46### Issue Lifecycle 47 481. The issue is reported. 49 502. The issue is verified and categorized by a Vault collaborator. 51 Categorization is done via tags. For example, bugs are marked as "bugs". 52 533. Unless it is critical, the issue may be left for a period of time (sometimes 54 many weeks), giving outside contributors -- maybe you!? -- a chance to 55 address the issue. 56 574. The issue is addressed in a pull request or commit. The issue will be 58 referenced in the commit message so that the code that fixes it is clearly 59 linked. 60 615. The issue is closed. 62 636. Issues that are not reproducible and/or not gotten responses for a long time are 64 stale issues. In order to provide faster responses and better engagement with 65 the community, we strive to keep the issue tracker clean and the issue count 66 low. In this regard, our current policy is to close stale issues after 30 days. 67 Closed issues will still be indexed and available for future viewers. If users 68 feel that the issue is still relevant, we encourage reopening them. 69 70## Pull requests 71 72When submitting a PR you should reference an existing issue. If no issue already exists, 73please create one. This can be skipped for trivial PRs like fixing typos. 74 75Creating an issue in advance of working on the PR can help to avoid duplication of effort, 76e.g. maybe we know of existing related work. Or it may be that we can provide guidance 77that will help with your approach. 78 79Your pull request should have a description of what it accomplishes, how it does so, 80and why you chose the approach you did. PRs should include unit tests that validate 81correctness and the existing tests must pass. Follow-up work to fix tests 82does not need a fresh issue filed. 83 84Someone will do a first pass review on your PR making sure it follows the guidelines 85in this document. If it doesn't we'll mark the PR incomplete and ask you to follow 86up on the missing requirements. 87 88### Changelog Entries 89Please include a file within your PR named `changelog/#.txt`, where `#` is your 90pull request ID. There are many examples under [changelog](changelog/), but 91the general format is 92 93```` 94```release-note:CATEGORY 95COMPONENT: summary of change 96``` 97```` 98 99CATEGORY is one of `security`, `change`, `feature`, `improvement`, or `bug`. 100Your PR is almost certain to be one of `bug` or `improvement`, but don't 101worry too much about getting it exactly right, we'll tell you if a change is 102needed. 103 104To determine the relevant component, consult [CHANGELOG](CHANGELOG.md) and pick 105whichever one you see that seems the closest match. 106 107You do not need to include the link at the end of the summary that appears in 108CHANGELOG.md, those are generated automatically by the changelog-building 109process. 110 111### Vault UI 112 113How you contribute to the UI depends on what you want to contribute. If that is 114a new feature, please submit an informational issue first. That issue 115should include a short description of the proposed feature, the use case, 116the approach you're taking, and the tests that would be written. A mockup 117is optional but encouraged. 118 119Bug fixes are welcome in PRs but existing tests must pass and updated logic 120should be handled in new tests. You needn't submit an issue first to fix bugs. 121 122Keep in mind that the UI should be consistent with other areas of Vault. Our 123[README](ui/README.md) [has instructions for launching Storybook](ui/README.md#vault-storybook), 124which showcases how we use components. Beyond that, the UI should be user-centered, 125informative, and include edge cases and errors— including accommodations for 126users who may not have permissions to view or interact with your feature. 127If you are not comfortable with UI design, a Vault designer can take a look at 128your work— just be aware that this might mean it will add some time to the 129PR process. 130 131Finally, in your code, try to avoid logic-heavy templates (when possible, 132calculate values in the .js file instead of .hbs) and Ember anti-patterns. 133And most of all, if you have any questions, please ask! 134 135## Setting up Go to work on Vault 136 137If you have never worked with Go before, you will have to complete the 138following steps listed in the README, under the section [Developing Vault][1]. 139 140 141[1]: https://github.com/hashicorp/vault#developing-vault 142[2]: https://discuss.hashicorp.com/c/vault 143 144## Contributor License Agreement 145 146We require that all contributors sign our Contributor License Agreement ("CLA") before we can accept the contribution. 147 148[Learn more about why HashiCorp requires a CLA and what the CLA includes](https://www.hashicorp.com/cla) 149