[PROPOSAL] Make Kibana's PR template a checklist (#23511)

Kibana now uses a checklist for its PR template. The contributing docs were updated with more detail about release process.

.github/PULL_REQUEST_TEMPLATE.md

@@ -1,13 +1,19 @@
-<!--
-Thank you for your interest in and contributing to Kibana! There
-are a few simple things to check before submitting your pull request
-that can help with the review process. You should delete these items
-from your submission, but they are here to help bring them to your
-attention.
+## Summary
+
+Summarize your PR. If it involves visual changes include a screenshot or gif.
+
+### Checklist
+
+Use ~~strikethroughs~~ to remove checklist items you don't feel are applicable to this PR.
+
+- [ ] This was checked for cross-browser compatability, [including a check against IE11](https://github.com/elastic/kibana/blob/master/CONTRIBUTING.md#cross-browser-compatibility)
+- [ ] Any text added follows [EUI's writing guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses sentence case text and includes [i18n support](https://github.com/elastic/kibana/blob/master/packages/kbn-i18n/README.md)
+- [ ] [Documentation](https://github.com/elastic/kibana/blob/master/CONTRIBUTING.md#writing-documentation) was added for features that require explanation or tutorials
+- [ ] [Unit or functional tests](https://github.com/elastic/kibana/blob/master/CONTRIBUTING.md#cross-browser-compatibility) were updated or added to match the most common scenarios
+- [ ] This was checked for [keyboard-only and screenreader accessibility](https://developer.mozilla.org/en-US/docs/Learn/Tools_and_testing/Cross_browser_testing/Accessibility#Accessibility_testing_checklist)
+
+### For maintainers
+
+- [ ] This was checked for breaking API changes and was [labeled appropriately](https://github.com/elastic/kibana/blob/master/CONTRIBUTING.md#release-notes-process)
+- [ ] This includes a feature additition or change that requires a release note and was [labeled appropriately](https://github.com/elastic/kibana/blob/master/CONTRIBUTING.md#release-notes-process)
 
-- Have you signed the [contributor license agreement](https://www.elastic.co/contributor-agreement)?
-- Have you followed the [contributor guidelines](https://github.com/elastic/kibana/blob/master/CONTRIBUTING.md)?
-- If submitting code, have you included unit tests that cover the changes?
-- If submitting code, have you tested and built your code locally prior to submission with `yarn test && yarn build`?
-- If submitting code, is your pull request against master? Unless there is a good reason otherwise, we prefer pull requests against master and will backport as needed.
--->

CONTRIBUTING.md

@@ -30,6 +30,7 @@ A high level overview of our contributing guidelines.
       - [Browser Automation Notes](#browser-automation-notes)
   - [Building OS packages](#building-os-packages)
   - [Writing documentation](#writing-documentation)
+  - [Release Notes Process](#release-notes-process)
 - [Signing the contributor license agreement](#signing-the-contributor-license-agreement)
 - [Submitting a Pull Request](#submitting-a-pull-request)
 - [Code Reviewing](#code-reviewing)
@@ -189,9 +190,10 @@ node scripts/makelogs
 > Make sure to execute `node scripts/makelogs` *after* elasticsearch is up and running!
 
 Start the development server.
-  ```bash
-  yarn start
-  ```
+
+```bash
+yarn start
+```
 
 > On Windows, you'll need you use Git Bash, Cygwin, or a similar shell that exposes the `sh` command.  And to successfully build you'll need Cygwin optional packages zip, tar, and shasum.
 
@@ -405,6 +407,31 @@ README for getting the docs tooling set up.
 node scripts/docs.js --open
 ```
 
+### Release Notes Process
+
+Part of this process only applies to maintainers, since it requires access to Github labels.
+
+Kibana publishes major, minor and patch releases periodically through the year. During this process we run a script against this repo to collect the applicable PRs against that release and generate [Release Notes](https://www.elastic.co/guide/en/kibana/current/release-notes.html). To include your change in the Release Notes:
+
+1. In the title, summarize what the PR accomplishes in language that is meaningful to the user.  In general, use present tense (for example, Adds, Fixes) in sentence case.
+1. Label the PR with the targeted version (ex: 6.5).
+1. Label the PR with the appropriate github labels:
+    * For a new feature or functionality, use `release_note:enhancement`.
+    * For an external-facing fix, use `release_note:fix`.  Exception: docs, build, and test fixes do not go in the Release Notes.
+    * For a deprecated feature, use `release_note:deprecation`.
+    * For a breaking change, use `release-breaking:note`.
+
+We also produce a blog post that details more important breaking API changes every minor and major release. If the PR includes a breaking API change, apply the label `release_note:dev_docs`. Additionally add a brief summary of the break at the bottom of the PR using the format below:
+
+
+```
+# Dev Docs
+
+## Name the feature with the break (ex: Visualize Loader)
+
+Summary of the change. Anything Under `#Dev Docs` will be used in the blog.
+```
+
 ## Signing the contributor license agreement
 
 Please make sure you have signed the [Contributor License Agreement](http://www.elastic.co/contributor-agreement/). We are not asking you to assign copyright to us, but to give us the right to distribute your code without restriction. We ask this of all contributors in order to assure our users of the origin and continuing existence of the code. You only need to sign the CLA once.