additional PR merger information

Author: matebarabas

docs/content/contributing/bicep/bicep-contribution-flow/_index.md

@@ -581,6 +581,8 @@ When publishing a new version of an existing module (i.e., anything that is not
 
 {{% include file="/static/includes/PR-approval-guidance.md" %}}
 
+In case of Bicep modules, if the PR includes any changes outside of the "modules/" folder, it first needs the module related code changes need to be reviewed and approved as per the above table, and only then does the PR need to be approved by a member of the core team. This way the core team's approval does not act as a bypass from the actual code review perspective.
+
 <!--
 ## Publishing to the Registry
 

docs/content/contributing/terraform/terraform-contribution-flow/_index.md

@@ -304,3 +304,5 @@ When publishing a net new module for the first time ever, the PR **MUST** be rev
 When publishing a new version of an existing module (i.e., anything that is not being published for the first time ever), the PR approval logic is the following:
 
 {{% include file="/static/includes/PR-approval-guidance.md" %}}
+
+For more details, please refer to the [Owner Contribution flow]({{% siteparam base %}}/contributing/terraform/terraform-contribution-flow/owner-contribution-flow) section.

docs/content/help-support/issue-triage/brm-issue-triage.md

@@ -102,6 +102,8 @@ The PR approval logic for existing modules is the following:
 
 This behavior is assisted by bots, through automatic assignment of the expected reviewer(s) and supporting labels.
 
+In case of Bicep modules, if the PR includes any changes outside of the "modules/" folder, it first needs the module related code changes need to be reviewed and approved as per the above table, and only then does the PR need to be approved by a member of the core team. This way the core team's approval does not act as a bypass from the actual code review perspective.
+
 {{% /notice %}}
 
 ## General Question/Feedback and other standard issues

docs/content/specs-defs/module-lifecycle.md

@@ -67,6 +67,8 @@ The PR approval logic for existing modules is the following:
 
 This behavior is assisted by bots, through automatic assignment of the expected reviewer(s) and supporting labels.
 
+In case of Bicep modules, if the PR includes any changes outside of the "modules/" folder, it first needs the module related code changes need to be reviewed and approved as per the above table, and only then does the PR need to be approved by a member of the core team. This way the core team's approval does not act as a bypass from the actual code review perspective.
+
 {{% /expand %}}
 
 {{% /notice %}}