luxolus
/
open-vault
2
0
Fork 0
Code Issues 1 Pull Requests Releases Activity

Add to the contribution guidelines. (#11496) 

* Update CONTRIBUTOR.md with more guidelines

* Add the UI component

* Strengthen issue-before-pr language

* move changelog section

* UI section polish

* Soften PR issue language
This commit is contained in:
Scott Miller 2021-05-03 14:36:13 -05:00 committed by GitHub
parent 1e61f799ca
commit 0946e46af6
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 42 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

42
CONTRIBUTING.md
View File

@ -18,6 +18,7 @@ is via the [Vault Discussion Forum][2].
## Issues
This section 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
quickly merge or address your contributions.
@ -63,6 +64,23 @@ quickly merge or address your contributions.
## Pull requests
When submitting a PR you should reference an existing issue. If no issue already exists,
please create one. This can be skipped for trivial PRs like fixing typos.
Creating an issue in advance of working on the PR can help to avoid duplication of effort,
e.g. maybe we know of existing related work. Or it may be that we can provide guidance
that will help with your approach.
Your pull request should have a description of what it accomplishes, how it does so,
and why you chose the approach you did. PRs should include unit tests that validate
correctness and the existing tests must pass. Follow-up work to fix tests
does not need a fresh issue filed.
Someone will do a first pass review on your PR making sure it follows the guidelines
in this document. If it doesn't we'll mark the PR incomplete and ask you to follow
up on the missing requirements.
### Changelog Entries
Please include a file within your PR named `changelog/#.txt`, where `#` is your
pull request ID. There are many examples under [changelog](changelog/), but
the general format is
@ -85,6 +103,30 @@ You do not need to include the link at the end of the summary that appears in
CHANGELOG.md, those are generated automatically by the changelog-building
process.
### Vault UI
How you contribute to the UI depends on what you want to contribute. If that is
a new feature, please submit an informational issue first. That issue
should include a short description of the proposed feature, the use case,
the approach you're taking, and the tests that would be written. A mockup
is optional but encouraged.
Bug fixes are welcome in PRs but existing tests must pass and updated logic
should be handled in new tests. You needn't submit an issue first to fix bugs.
Keep in mind that the UI should be consistent with other areas of Vault. Our
[README](ui/README.md) [has instructions for launching Storybook](ui/README.md#vault-storybook),
which showcases how we use components. Beyond that, the UI should be user-centered,
informative, and include edge cases and errors— including accommodations for
users who may not have permissions to view or interact with your feature.
If you are not comfortable with UI design, a Vault designer can take a look at
your work— just be aware that this might mean it will add some time to the
PR process.
Finally, in your code, try to avoid logic-heavy templates (when possible,
calculate values in the .js file instead of .hbs) and Ember anti-patterns.
And most of all, if you have any questions, please ask!
## Setting up Go to work on Vault
If you have never worked with Go before, you will have to complete the