Update contribution guide
This commit is contained in:
parent
9dc9264629
commit
df4469cc4e
|
@ -4,13 +4,17 @@
|
|||
If you believe you have found a security issue in Vault, please responsibly
|
||||
disclose by contacting us at security@hashicorp.com.
|
||||
|
||||
**First:** if you're unsure or afraid of _anything_, just ask
|
||||
or submit the issue or pull request anyways. You won't be yelled at for
|
||||
giving your best effort. The worst that can happen is that you'll be
|
||||
politely asked to change something. We appreciate any sort of contributions,
|
||||
and don't want a wall of rules to get in the way of that.
|
||||
**First:** if you're unsure or afraid of _anything_, just ask or submit the
|
||||
issue or pull request anyways. You won't be yelled at for giving it your best
|
||||
effort. The worst that can happen is that you'll be politely asked to change
|
||||
something. We appreciate any sort of contributions, and don't want a wall of
|
||||
rules to get in the way of that.
|
||||
|
||||
You can also inquire on the [Vault Google Group][2], or in `#vault-tool` on Freenode.
|
||||
That said, if you want to ensure that a pull request is likely to be merged,
|
||||
talk to us! You can find out our thoughts and ensure that your contribution
|
||||
won't clash or be obviated by Vault's normal direction. A great way to do this
|
||||
is via the [Vault Google Group][2]. Sometimes Vault devs are in `#vault-tool`
|
||||
on Freenode, too.
|
||||
|
||||
This document will cover what we're looking for in terms of reporting issues.
|
||||
By addressing all the points we're looking for, it raises the chances we can
|
||||
|
@ -21,17 +25,23 @@ quickly merge or address your contributions.
|
|||
### Reporting an Issue
|
||||
|
||||
* Make sure you test against the latest released version. It is possible
|
||||
we already fixed the bug you're experiencing.
|
||||
we already fixed the bug you're experiencing. Even better is if you can test
|
||||
against `master`, as bugs are fixed regularly but new versions are only
|
||||
released every few months.
|
||||
|
||||
* Provide steps to reproduce the issue, and if possible include the expected
|
||||
results as well as the actual results
|
||||
results as well as the actual results. Please provide text, not screen shots!
|
||||
|
||||
* If you are seeing an internal Vault error (a status code of 5xx), please be
|
||||
sure to post relevant parts of (or the entire) Vault log, as often these
|
||||
errors are logged on the server but not reported to the user
|
||||
|
||||
* If you experienced a panic, please create a [gist](https://gist.github.com)
|
||||
of the *entire* generated crash log for us to look at. Double check
|
||||
no sensitive items were in the log.
|
||||
|
||||
* Respond as promptly as possible to any questions made by the Vault
|
||||
team to your issue. Stale issues will be closed.
|
||||
team to your issue. Stale issues will be closed periodically.
|
||||
|
||||
### Issue Lifecycle
|
||||
|
||||
|
@ -40,8 +50,9 @@ quickly merge or address your contributions.
|
|||
2. The issue is verified and categorized by a Vault collaborator.
|
||||
Categorization is done via tags. For example, bugs are marked as "bugs".
|
||||
|
||||
3. Unless it is critical, the issue is left for a period of time (sometimes
|
||||
many weeks), giving outside contributors a chance to address the issue.
|
||||
3. Unless it is critical, the issue may be left for a period of time (sometimes
|
||||
many weeks), giving outside contributors -- maybe you!? -- a chance to
|
||||
address the issue.
|
||||
|
||||
4. The issue is addressed in a pull request or commit. The issue will be
|
||||
referenced in the commit message so that the code that fixes it is clearly
|
||||
|
|
Loading…
Reference in New Issue