Provide guidance on when maintainers will (not) approve a PR (#100)

* Provide guidance on when maintainers will (not) approve a PR

Closes #94

Signed-off-by: Tom Kerkhove <[email protected]>

* Update GOVERNANCE.md

Co-authored-by: Jorge Turrado Ferrero <[email protected]>
Signed-off-by: Tom Kerkhove <[email protected]>

---------

Signed-off-by: Tom Kerkhove <[email protected]>
Co-authored-by: Jorge Turrado Ferrero <[email protected]>

GOVERNANCE.md

@@ -23,6 +23,21 @@ Maintainers MUST remain active. If they are unresponsive for >3 months, they can
 
 If a maintainer violates our [Code of Conduct][code-of-conduct], all maintainers will discuss the incident allowing the maintainer to give background and other maintainers will cast a vote. If the vote results in a [super-majority][super-majority], then the maintainer needs to step down and leave the maintainer board.
 
+#### Approving & Merging PRs
+
+Maintainers will approve PRs only when:
+
+- It meets the [scaler requirements](https://github.com/kedacore/governance/blob/main/SCALERS.md)
+- It meets the [deprecation/breaking change requirements](https://github.com/kedacore/governance/blob/main/DEPRECATIONS.md)
+- It is in line with the goal of the project
+- It does not violate the [code of conduct](https://github.com/kedacore/governance/blob/main/CODE_OF_CONDUCT.md).
+
+Apart from the conditions above, all the required checks in the PR have to pass. Maintainers still have the right to merge a PR with one or more failing checks if they, after reviewing the check, consider that it's an unrelated failure (like a transient failure on an e2e test).
+
+In case of dispute, other maintainers are requested to review and agree what the best outcome is of a PR.
+
+Once a single maintainer approves a PR, they can merge it unless they want to have a second pair of eyes. (optional)
+
 ### Becoming A Maintainer
 
 New maintainers can be added to the project by a [super-majority][super-majority]