adding guidance for using the needs core team label

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

@@ -321,6 +321,12 @@ Finally, once you are satisfied with your contribution and validated it, open a
 
     <img src="../../../img/contribution/pipelineBadge.png" alt="Status Badge" height="400">
 
+{{< hint type=note >}}
+
+If you're the **sole owner of the module**, the **AVM core team must review and approve the PR**. To indicate that your PR needs the core team's attention, **apply the** "<mark style="background-color:#DB4503;color:white;">Needs: Core Team 🧞</mark>" **label on it!**
+
+{{< /hint >}}
+
 <!--
 ## Publishing to the Registry
 

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

@@ -52,6 +52,11 @@ Once the teams have been created the AVM Core Team will review the team name and
 
 2. Add teams to `CODEOWNERS` file as outlined in [SNFR20](/Azure-Verified-Modules/specs/shared/#id-snfr20---category-contributionsupport---github-teams-only).
 3. Ensure your module has been tested before raising a PR. You can do this your own or in another module contributor's environment - if any. Also, once a PR is raised, a GitHub workflow pipeline is required to be run successfully before the PR can be merged. This is to ensure that the module is working as expected and is compliant with the AVM specifications.
+{{< hint type=note >}}
+
+If you're the **sole owner of the module**, the **AVM core team must review and approve the PR**. To indicate that your PR needs the core team's attention, **apply the** "<mark style="background-color:#DB4503;color:white;">Needs: Core Team 🧞</mark>" **label on it!**
+
+{{< /hint >}}
 4. Ensure that the module(s) you own are compliant with the AVM specifications and are working as expected. While all specifications are to be followed, pay special attention to the following ones as in these, the `Owner` is mentioned explicitly:
 | ID | Specification
 |---------------|-----------------------|
@@ -172,5 +177,11 @@ This checklist can be used in the development of AVM Bicep Modules.
     {{< /expand >}}
 
 7. Create a PR and reference the status badge of your pipeline run - [see here](/Azure-Verified-Modules/contributing/bicep/bicep-contribution-flow/#6-create-a-pull-request-to-the-public-bicep-registry).
+{{< hint type=note >}}
+
+If you're the **sole owner of the module**, the **AVM core team must review and approve the PR**. To indicate that your PR needs the core team's attention, **apply the** "<mark style="background-color:#DB4503;color:white;">Needs: Core Team 🧞</mark>" **label on it!**
+
+{{< /hint >}}
+
 8. After a pull request has been created, it is important to update the [AVM module proposal](https://aka.ms/AVM/ModuleProposals) issue associated with your module, with a link to the pull request you created in BRM and mention the person who helped triage your module or the `@Azure/avm-core-team-technical-bicep` team.
 9. Once your BRM pull request has been approved and merged into main update the [AVM module proposal](https://aka.ms/AVM/ModuleProposals) issue associated with your module, with a **Merged** comment and mention the person who helped triage your module, or the `@Azure/avm-core-team-technical-bicep` team.

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

@@ -81,6 +81,28 @@ If the issue was opened as a misplaced module proposal, mention the `@Azure/AVM-
 
 <br>
 
+### Triaging a Module PR
+
+1. If the **PR is submitted by the module owner** and the **module is owned by a single person**, **the AVM core team must review and approve the PR**, (as the module owner can't approve their on PR).
+    - To indicate that the PR needs the core team's attention, apply the "<mark style="background-color:#DB4503;color:white;">Needs: Core Team 🧞</mark>" label.
+2. If the **PR is submitted by a contributor** (other than the module owner), or the **module is owned by at least 2 people**, **one of the module owners should review and approve the PR**.
+3. Apply relevant labels
+    - Make sure the PR is categorized using one of the following type labels:
+      - "<mark style="background-color:#A2EEEF;">Type: Feature Request ➕</mark>"
+      - "<mark style="background-color:#D73A4A;color:white;">Type: Bug 🐛</mark>"
+      - "<mark style="background-color:#FFFF00;">Type: Security Bug 🔒</mark>"
+    - For module classification (resource/pattern): "<mark style="background-color:#D3D3D3;">Class: Resource Module 📦</mark>" or "<mark style="background-color:#A9A9A9;">Class: Pattern Module 📦</mark>"
+4. If the module is orphaned (has no owner), make sure the related Orphaned module issue (in the AVM repository) is associated to the PR in a comment, so the new owner can easily identify all related issues and PRs when taking ownership.
+5. Remove the "<mark style="background-color:#FBCA04;">Needs: Triage 🔍</mark>" label.
+
+{{< hint type=tip title="Give your PR a meaningful title" >}}
+
+- **Prefix**: Start with one of the allowed keywords - `fix:` or `feat:` is the most common for module related changes.
+- **Description**: Add a few words, describing the nature of the change.
+- **Module name**: Add the module's full name between backticks ( ` ) to make it pop.
+
+{{< /hint >}}
+
 ## General Question/Feedback and other standard issues
 
 An issue is considered to be an "AVM Question/Feedback" if