Add to the contribution guidelines. (hashicorp#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

CONTRIBUTING.md

@@ -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