Add PR Guidelines (elastic#8968)

Create contributing guide to reference this aspect of PR guidelines

docs/devguide/contributing.asciidoc

@@ -24,9 +24,9 @@ order to assure our users of the origin and continuing existence of the code.
 You only need to sign the CLA once.
 
 . Send a pull request! Push your changes to your fork of the repository and
-https://help.github.com/articles/using-pull-requests[submit a pull request]. In
-the pull request, describe what your changes do and mention any bugs/issues
-related to the pull request. Please also add a changelog entry to
+https://help.github.com/articles/using-pull-requests[submit a pull request] using our
+<pr-review,pull request guidelines>. In the pull request, describe what your changes do and mention
+any bugs/issues related to the pull request. Please also add a changelog entry to
 https://github.com/elastic/beats/blob/master/CHANGELOG.asciidoc[CHANGELOG.asciidoc].
 
 [float]

docs/devguide/index.asciidoc

@@ -11,6 +11,8 @@ include::{asciidoc-dir}/../../shared/attributes.asciidoc[]
 
 include::../../libbeat/docs/shared-beats-attributes.asciidoc[]
 
+include::./pull-request-guidelines.asciidoc[]
+
 include::./contributing.asciidoc[]
 
 include::../../libbeat/docs/communitybeats.asciidoc[]

docs/devguide/pull-request-guidelines.asciidoc

@@ -0,0 +1,18 @@
+[[pr-review]]
+== Pull request review guidelines
+
+Every change made to Beats must be held to a high standard, and while the responsibility for quality in a pull request ultimately lies with the author, Beats team members have the responsibility as reviewers to verify during their review process. Where this document is unclear or inappropriate let common sense and consensus override it.
+
+[float]
+=== Code Style
+
+Everyone's got an opinion on style. To avoid spending time on this issue we rely almost exclusively on `go fmt` and https://houndci.com/[hound] to police style. If neither of these tools complain the code is almost certainly fine. There may be exceptions to this, but they should be extremely rare. Only override the judgement of these tools in the most unusual of situations.
+
+[float]
+=== Flaky Tests
+
+As software projects grow so does the complexity of their test cases and with that the probability of some tests becoming 'flaky'. It is everyone's responsibility to handle flaky tests. If you notice a pull request build failing for a reason that is unrelated to the pushed code follow the procedure below:
+
+1. Create an issue using the "Flaky Test" github issue template with the "Flaky Test" label attached.
+2. Create a PR to mute or fix the flaky test.
+3. Merge that PR and rebase off of it before continuing with the normal PR process for your original PR.