BRM Issue Triage

This page provides guidance for Bicep module owners on how to triage AVM module issues and AVM question/feedback items filed in the BRM repository (Bicep Registry Modules repository - where all Bicep AVM modules are published), as well as how to manage these GitHub issues throughout their lifecycle.

As such, the following issues are to be filed in the BRM repository:

• [AVM Module Issue]: Issues specifically related to an existing AVM module, such as feature requests, bug and security bug reports.
• [AVM Question/Feedback]:Generic feedback and questions, related to existing AVM module, the overall framework, or its automation (CI environment).

Do NOT file the following types of issues in the BRM repository, as they MUST be tracked in the AVM repo:

• [Module Proposal]: Proposals for new AVM modules.
• [Orphaned Module]: Indicate that a module is orphaned (has no owner).
• [Question/Feedback]: Generic questions/requests related to the AVM site or documentation.

Every module needs a module proposal to be created in the AVM repository.

During the triage process, module owners are expected to check, complete and follow up on the items described in the sections below.

Module owners MUST meet the SLAs defined on the Module Support page! While there’s automation in place to support meeting these SLAs, module owners MUST check for new issues on a regular basis.

The BRM repository includes other, non-AVM modules and related GitHub issues. As a module owner, make sure you’re only triaging, managing or otherwise working on issues that are related to AVM modules!

• To look for items that need triaging, click on the following link to use this saved query ➡️ Needs: Triage 🔍 ⬅️.
• To look for items that need attention, click on the following link to use this saved query ➡️ Needs: Attention 👋 ⬅️.
• Open items that are not in a project.

An issue is considered to be an “AVM module issue” if

• it was opened through the [AVM Module Issue] template in the BRM repository,
• it has the labels of “Needs: Triage 🔍” and “Type: AVM 🅰️ ✌️ ⓜ️” applied to it, and
• it is assigned to the “AVM - Module Issues” GitHub project.

Module issues can only be opened for existing AVM modules. Module issues MUST NOT be used to file a module proposal.

If the issue was opened as a misplaced module proposal, mention the @Azure/AVM-core-team-technical-bicep team in the comment section and ask them to move the issue to the AVM repository.

1. Check the Module issue:
   • Make sure the issue has the “Type: AVM 🅰️ ✌️ ⓜ️” applied to it.
   • Use the AVM module indexes to identify the module owner(s) and make sure they are assigned/mentioned/informed.
   • If the module is orphaned (has no owner), make sure there’s an orphaned module issue in the AVM repository.
   • Make sure the module’s details are captured correctly in the description - i.e., name, classification (resource/pattern), language (Bicep/Terraform), etc.
   • Make sure the issue is categorized using one of the following type labels:
     • “Type: Feature Request ➕”
     • “Type: Bug 🐛”
     • “Type: Security Bug 🔒”
2. Apply relevant labels for module classification (resource/pattern): “Class: Resource Module 📦” or “Class: Pattern Module 📦”
3. Communicate next steps to the requestor (issue author).
4. Remove the “Needs: Triage 🔍” label.
5. When more detailed plans are available, communicate expected timeline for the update/fix to the requestor (issue author).
6. Only close the issue, once the next version of the module was fully developed, tested and published.

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 “Needs: Core Team 🧞” 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:
     • “Type: Feature Request ➕”
     • “Type: Bug 🐛”
     • “Type: Security Bug 🔒”
   • For module classification (resource/pattern): “Class: Resource Module 📦” or “Class: Pattern Module 📦”
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 “Needs: Triage 🔍” label.

• 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.

An issue is considered to be an “AVM Question/Feedback” if

• it was opened through the [AVM Question/Feedback] template in the BRM repository,
• it has the labels of “Needs: Triage 🔍”, “Type: Question/Feedback 🙋‍♀️” and “Type: AVM 🅰️ ✌️ ⓜ️” applied to it, and
• it is assigned to the “AVM - Issue Triage” GitHub project.

An issue is considered to be a “standard issue” or “blank issue” if it was opened without using an issue template, and hence it does NOT have any labels assigned, OR only has the “Needs: Triage 🔍” label assigned.

1. When triaging the issue, consider adding one of the following labels as fits:

   • Type: Documentation 📄
   • Type: Feature Request ➕
   • Type: Bug 🐛
   • Type: Security Bug 🔒

To see the full list of available labels, please refer to the GitHub Repo Labels section.

2. Add any (additional) labels that apply.
3. Communicate next steps to the requestor (issue author).
4. Remove the “Needs: Triage 🔍” label.
5. When more detailed plans are available, communicate expected timeline for the update/fix to the requestor (issue author).
6. Once the question/feedback/topic is fully addressed, close the issue.

If an intended module proposal was mistakenly opened as a “AVM Question/Feedback ❔” or other standard issue, a new issue MUST be created in the AVM repo using the “New AVM Module Proposal 📝” issue template. The mistakenly created “AVM Question/Feedback ❔” or other standard issue MUST be closed.