AVM Issue Triage

“AVM Core Team Triage” Explained

This page provides guidance for members of the AVM Core Team on how to triage module proposals and generic issues filed in the AVM repository, as well as how to manage these GitHub issues throughout their lifecycle.

During the AVM Core Team Triage step, the following will be checked, completed and actioned by the AVM Core Team during their triage calls (which are currently twice per week).

Note

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

Tip

During the triage process, the AVM Core Team should also check the status of following queries:

Open items that need triaging: Needs: Triage 🔍
- Bicep items (that need triaging): Language: Bicep 💪 & Needs: Triage 🔍
- Terraform items (that need triaging): Language: Terraform 🌐 & Needs: Triage 🔍
Open items that need triaging AND aren’t being triaged yet: Needs: Triage 🔍 & NOT Status: In Triage 🔍
Open items that need attention: Needs: Attention 👋
Open items that need owners: Needs: Module Owner 📣
Open items with no recent activity: Status: No Recent Activity 💤
Open question/feedback items: Type: Question/Feedback 🙋‍♀️
Open items with long term status: Status: long-term ⏳
Open items that are not in a project.

Module Proposal triage

An issue is considered to be a module proposal if

it was opened through the “New AVM Module Proposal 📝” template,
it has the labels of Needs: Triage 🔍 and Type: New Module Proposal 💡 applied to it, and
it is assigned to the “AVM - Module Triage” GitHub project.

Follow these steps to triage a module proposal:

Add the Status: In Triage 🔍 label to indicate you’re in the process of triaging the issue.
Check module proposal issue/form:
- Check the Bicep or Terraform module indexes for the proposed module to make sure it is not already available or being worked on.
- Ensure the module’s details are correct as per specifications - naming, classification (resource/pattern) etc.
- Check if the module is added to the “Proposed” column on the AVM - Modules Triage GitHub project board.
- Check if the requestor is a Microsoft FTE.
- If there’s any additional clarification needed, contact the requestor through comments (using their GH handle) or internal channels - for Microsoft FTEs only! You can look them up by their name or using the Microsoft Open Source Management Portal’s People finder: “Linked people across Microsoft organizations”. Make sure you capture any decisions regarding the module in the comments section.
- Make adjustments to the module’s name/classification as needed.
- Change the name of the issue to reflect the module’s name, i.e.,
  - After the “[Module Proposal]:” prefix, change the issues name to the module’s approved name between backticks, i.e., ` and `, e.g., avm/res/sql/managed-instance for a Bicep module, or avm-res-compute-virtualmachine for a Terraform module.
  - Example:
    - “[Module Proposal]: avm/res/sql/managed-instance”
    - “[Module Proposal]: avm-res-sql-managedinstance”
- Check if the GitHub Policy Service Bot has correctly applied the module language label: Language: Bicep 💪 or Language: Terraform 🌐
Apply relevant labels
- Module classification (resource/pattern/utility): Class: Resource Module 📦 , Class: Pattern Module 📦 or Class: Utility Module 📦

Triaging pattern modules

As part of the triage of pattern modules, the following points need to be considered/clarified with the module requestor:

Shouldn’t this be a resource module? What makes it a pattern - e.g., does it deploy multiple resources?
What is it for? What problem does it fix or provides a solution for?
What is/isn’t part of it? Which resource and/or pattern modules are planned to be leveraged in it? Provide a list of resources that would be part of the planned module.
Where is it coming from/what’s backing it - e.g., Azure Architecture Center (AAC), community request, customer example. Provide an architectural diagram and related documentation if possible - or a pointer to these if they are publicly available.
Don’t let the module’s scope to grow too big, split it up to multiple smaller ones that are more maintainable - e.g., hub & spoke networking should should be split to a generic hub networking and multiple workload specific spoke networking patterns.
The module’s name should be as descriptive as possible.
Adopt strict name-to-scope mapping - e.g., hub & spoke networking shouldn’t deploy monitoring.

Scenario 1: Requestor doesn’t want to / can’t be module owner

Note

If requestor is interested in becoming a module owner, but is not a Microsoft FTE, the AVM core team will try to find a Microsoft FTE to be the module owner whom the requestor can collaborate with.

If the requestor indicated they didn’t want to or can’t become a module owner (or is not a Microsoft FTE), make sure the Needs: Module Owner 📣 label is assigned to the issue. Note: the GitHub Policy Service Bot should automatically do this, based on how the issue author responded to the related question.
Move the issue to the “Looking for owners” column on the AVM - Modules Triage GitHub project board.
Add a comment on the issue with the #RFRC tag to indicate that the repository should be created. Keep the proposal issue available to the community and potential module owners.
Find module owners - if the requestor didn’t volunteer in the module proposal OR the requestor does not want or cannot be owner of the module:
- Try to find an owner from the AVM communities or await a module owner to comment and propose themselves on the proposal issue.
When a new potential owner is identified, continue with the steps described as follows.

Scenario 2: Requestor wants to and can become module owner

If the requestor indicated they want to become the module owner, the GitHub Policy Service Bot will add the Status: Owners Identified 🤘 label and will assign the issue to the requestor.

You MUST still confirm that the requestor is a Microsoft FTE and that they understand the implications of becoming the owner! If any of these conditions aren’t met, remove the Status: Owners Identified 🤘 label and unassign the issue from the requestor.

Make sure the requestor is a Microsoft FTE. You can look them up by their name or using the Microsoft Open Source Management Portal’s People finder: “Linked people across Microsoft organizations”.
Clarify the roles and responsibilities of the module owner:
- Clarify they understand and accept what “module ownership” means by replying in a comment to the requestor/proposed owner:

➕ Standard AVM Core Team Reply to Proposed Module Owners

<!-- markdownlint-disable -->
Hi @avm_module_owner,

Thanks for requesting/proposing to be an AVM module owner!

We just want to confirm **you agree to the below pages** that define what module ownership means:

- [Team Definitions & RACI](https://azure.github.io/Azure-Verified-Modules/specs/shared/team-definitions)
- [Module Specifications](https://azure.github.io/Azure-Verified-Modules/specs/module-specs)
- [Module Support](https://azure.github.io/Azure-Verified-Modules/help-support/module-support)

Any questions or clarifications needed, let us know!

If you agree, please just **reply to this issue with the exact sentence below** (as this helps with our automation 👍):

"I CONFIRM I WISH TO OWN THIS AVM MODULE AND UNDERSTAND THE REQUIREMENTS AND DEFINITION OF A MODULE OWNER"

Thanks,

The AVM Core Team

#RR
<!-- markdownlint-restore -->

Once module owner identified has confirmed they understand and accept their roles and responsibilities as an AVM module owner
- Make sure the issue is assigned to the confirmed module owner.
- Move the issue into the “In development” column on the AVM - Modules Triage GitHub Project board.
- Add a comment on the issue with the #RFRC tag to indicate that the repository should be created.
- Make sure the Status: Owners Identified 🤘 label is added to the issue.
  - If applied earlier, remove the Needs: Module Owner 📣 label from the issue.
- Remove the labels of Needs: Triage 🔍 and Status: In Triage 🔍 to indicate you’re done with triaging the issue.
Keep the approved name, description, and owners in the proposal issue, then record the supported fields through a metadata pull request. Metadata may be created before the module source exists; the module stays Proposed until it is published.
Use the following text to approve module development

➕ Final Confirmation for Proposed Module Owners - Bicep

<!-- markdownlint-disable -->
Hi @avm_module_owner,

Thanks for confirming that you wish to own this AVM module and understand the related requirements and responsibilities!

Before starting development, please ensure ALL the following requirements are met.

Every module owner must request and obtain approval for the [Azure Verified Modules (AVM) Module Contributors access package](https://aka.ms/avm/id/access-package/module-contributor), as outlined in [SNFR20](https://azure.github.io/Azure-Verified-Modules/spec/SNFR20#bicep).

**Use the module name and path approved in the proposal, and the assigned telemetry identifier.** The [module index](https://azure.github.io/Azure-Verified-Modules/indexes/) remains a published lookup reference:

- For your module:
  - `ModuleName` - for naming your module
  - `TelemetryIdPrefix` - for your module's [telemetry](https://azure.github.io/Azure-Verified-Modules/spec/SFR3)
  - Folder path are defined in `RepoURL`.

Maintain module details and the assigned `telemetryIdPrefix` in `metadata.json` through the [metadata review process](https://azure.github.io/Azure-Verified-Modules/contributing/module-metadata/). If an approved value is missing or conflicts with the index, contact the AVM core team.

Check if this module exists in the other IaC language. If so, collaborate with the other owner for consistency. 👍

You can now start the development of this module! ✅ Happy coding! 🎉

**Please respond to this comment and request a review from the AVM core team once your module is ready to be published! Please include a link pointing to your PR, once available. 🙏**

Any further questions or clarifications needed, let us know!

Thanks,

The AVM Core Team
<!-- markdownlint-restore -->

➕ Final Confirmation for Proposed Module Owners - Terraform

<!-- markdownlint-disable -->
Hi @avm_module_owner,

Thanks for confirming that you wish to own this AVM module and understand the related requirements and responsibilities!

Check if this module exists in the other IaC language. If so, collaborate with the other owner for consistency. 👍

Module owners must request and obtain approval for the [Azure Verified Modules (AVM) Module Contributors access package](https://aka.ms/avm/id/access-package/module-contributor), as outlined in [SNFR20](https://azure.github.io/Azure-Verified-Modules/spec/SNFR20#terraform). Per-module GitHub teams are no longer required.

You can now start the development of this module! ✅ Happy coding! 🎉

**Please respond to this comment and request a review from the AVM core team once your module is ready to be published! Please include a link pointing to your PR, once available. 🙏**

Any further questions or clarifications needed, let us know!

Thanks,

The AVM Core Team
<!-- markdownlint-restore -->

Important

Although, it’s not directly part of the module proposal triage process, to begin development, module owners and contributors might need additional help from the AVM core team, such as:

Update any Azure RBAC permissions for test tenants/subscription, if needed.
In case of Bicep modules only:
- Confirm that every module owner has approved access through the AVM Module Contributors access package, as outlined in SNFR20. Per-module GitHub teams and parent-team assignments are no longer required. Root metadata.json determines reviewer notifications; BRM has no per-module CODEOWNERS entries.

Post-Development issue management

Once module is developed and v0.1.0 has been published to the relevant registry

Assign the Status: Module Available 🟢 label to the issue.
Move the issue into “Done” column in AVM - Modules Triage GitHub Project.
Confirm that the module metadata and registry publication are correct. The four-hourly catalog sync then publishes the module index. Submit any metadata corrections to the module repository. For Bicep, verify that module list sync adds the new top-level module to the issue-template dropdown after catalog publication.

When all development actions are complete and confirmed

In case of Bicep modules - Close the module proposal issue with the following message:

➕ Closing remarks for the Owner(s) of a Published Bicep Module

- [x] Module published.
- [x] Module Contributors access package approved for all module owners.
- [x] Issue template file updated.

The AVM core team coordinates the module index through the [catalog sync](https://azure.github.io/Azure-Verified-Modules/contributing/module-metadata/#catalog-updates), which regenerates and publishes it automatically every four hours.

Thank you for your work @replace_with_author! I'm closing this issue now.

In case of Terraform modules - Close the issue.

Important

The Module Proposal issue MUST remain open until the module is fully developed, tested and published to the relevant registry.
Do NOT close the issue before the successful publication is confirmed!
Once the module is fully developed, tested and published to the relevant registry, and the Module Proposal issue was closed, it MUST remain closed.

Changing module owners

There can be several reasons why a module owner change is needed, e.g., the current owner is leaving the company, changing team, or is no longer able to maintain the module. In such cases, the module ownership needs to be transferred to a new owner. While in most cases the module needs to be marked as orphaned until it’s taken over by a new module owner, sometimes, the ownership can be transferred through a “hot swap”, where the current owner directly hands over ownership to another person without the module becoming orphaned first.

Note

The original Module Proposal issue related to the module in question MUST remain closed and intact.

Instead, a new Orphaned Module issue must be opened that MUST remain open until the ownership is fully confirmed!

Once the Orphaned Module issue was closed, it MUST remain closed. If the module will subsequently become orphaned again, a new Orphaned Module issue must be opened.

Adding or removing co-owners

Agree changes with the current owners and the AVM core team. Confirm each incoming owner’s eligibility, written acceptance of the role, and separate access approval. Submit the agreed handle changes to the owners array in the module’s root metadata.json, following the metadata review process. Use bare handles for individuals and qualified handles for approved existing teams. Keep every continuing individual or team owner; children inherit the root’s ownership.

Use the hot-swap process for a handover. If no owners remain, follow the orphaning process instead.

Orphaned modules

If a module meets the criteria described in the “Orphaned Modules” chapter, the module is considered to be orphaned and the below steps must be performed.

When a module becomes orphaned

Submit an “orphaned module” issue by using the “Orphaned AVM Module 🟡” issue template.
Make sure the Needs: Triage 🔍 , Needs: Module Owner 📣 , and the Status: Module Orphaned 🟡 labels are assigned to the issue and it is assigned to the “AVM - Module Triage” GitHub project.
Move the issue into the “Orphaned” column on the AVM - Modules Triage GitHub Project board.
Submit and merge the ownership change in a pull request to the module’s root metadata.json, linked to the orphaned module issue. Set "owners": [], removing all individual and team handles, following the metadata review process. Do not edit child ownership or set a status field. A published, non-deprecated module with no owners is shown as Orphaned; see how module status is calculated.```
Replace the label Needs: Triage 🔍 with the label Needs: In Triage🔍 & Add the appropriate label for the class of module i.e. Resoruce/Pattern/Utility
Try to find a new owner using the AVM communities or await a new module owner to comment and propose themselves on the issue.

For both Bicep and Terraform, the root metadata change is the only module-file change required. No ORPHANED.md file, manual README.md notice, or README regeneration is required. The scheduled catalog sync publishes the new status; do not edit generated indexes or create a module release.

When a new owner is identified

Tip

To look for Orphaned Modules:

Click on the following link to use this saved query ➡️ Status: Module Orphaned 🟡 ⬅️.
Check the Orphaned swim lane on the Module Triage board.

When a new potential owner is identified, confirm they are a Microsoft FTE and clarify the roles and responsibilities of the module owner:
- Clarify they understand and accept what “module ownership” means by replying in a comment to the requestor/proposed owner:

➕ Standard AVM Core Team Reply to New Owners of an Orphaned Module

<!-- markdownlint-disable -->
Hi @avm_module_owner,

Thanks for requesting/proposing to be an AVM module owner!

We just want to confirm **you agree to the below pages** that define what module ownership means:

- [Team Definitions & RACI](https://azure.github.io/Azure-Verified-Modules/specs/shared/team-definitions)
- [Module Specifications](https://azure.github.io/Azure-Verified-Modules/specs/module-specs)
- [Module Support](https://azure.github.io/Azure-Verified-Modules/help-support/module-support)

Any questions or clarifications needed, let us know!

If you agree, please just **reply to this issue with the exact sentence below** (as this helps with our automation 👍):

"I CONFIRM I WISH TO OWN THIS AVM MODULE AND UNDERSTAND THE REQUIREMENTS AND DEFINITION OF A MODULE OWNER"

Thanks,

The AVM Core Team

#RR
<!-- markdownlint-restore -->

Once the new module owner candidate has confirmed they understand and accept their roles and responsibilities as an AVM module owner
- Assign the issue to the confirmed module owner.
- Remove the Status: Module Orphaned 🟡 and the Needs: Module Owner 📣 labels from the issue.
- Add the Status: Module Available 🟢 and Status: Owners Identified 🤘 labels to the issue.
Submit a pull request adding the approved incoming handles to the owners array in the module’s root metadata.json, linked to the orphaned module issue. Obtain approval from either metadata code-owner team and merge the change through the metadata review process.
Ensure every new owner has approved access through the AVM Module Contributors access package. See SNFR20 for the language-specific access requirements.
Use the following text to confirm the new ownership of an orphaned module:

➕ Final Confirmation for New Owners of an Orphaned Module

Hi @avm_module_owner,

Thanks for confirming that you wish to own this AVM module and understand the related requirements and responsibilities!

We just want to ask you to double check a few important things.

**Before taking ownership, confirm the following**:

- Every incoming owner must have approved access through the [Azure Verified Modules (AVM) Module Contributors access package](https://aka.ms/avm/id/access-package/module-contributor), as outlined in [SNFR20](https://azure.github.io/Azure-Verified-Modules/spec/SNFR20).
- Confirm every approved incoming owner is recorded in the root `metadata.json` through a merged [metadata pull request](https://azure.github.io/Azure-Verified-Modules/contributing/module-metadata/) linked to this issue. Metadata does not grant access or review permission.
- The [module index](https://azure.github.io/Azure-Verified-Modules/indexes/) is regenerated automatically every four hours. Check back to confirm your name appears once the metadata change is merged.

Once the required ownership and access steps are confirmed, you can start improving the module as its owner! ✅ Happy coding! 🎉

Any further questions or clarifications needed, let us know!

Thanks,

The AVM Core Team

Once the metadata change is reviewed and merged and all access requirements above are complete, close the orphaned module issue with the following message. Closing the issue moves it to “Done” on the AVM - Modules Triage board. The module index updates automatically at the next four-hourly catalog sync.

➕ Closing remarks for the New Owner(s) of an Orphaned Module

- [x] Module Contributors access package approved for all incoming module owners.
- [x] Root metadata ownership change approved by either metadata code-owner team, merged, and linked to this issue through the [metadata review process](https://azure.github.io/Azure-Verified-Modules/contributing/module-metadata/).

The module index is regenerated automatically every four hours, so the ownership change should appear shortly.

Thank you for your work @replace_with_author! I'm closing this issue now.

Hot swapping module owners

When the module owner needs to be changed without the module becoming orphaned, the overall process described in the Orphaned modules chapter needs to be followed, with a few differences.

Submit an “orphaned module” issue by using the “Orphaned AVM Module 🟡” issue template while indicating the GitHub handle of the new owner.
Clarify the roles and responsibilities of the module owner by replying in a comment to the requestor/proposed owner:

➕ Standard AVM Core Team Reply to the New Owner(s) of an Orphaned Module

<!-- markdownlint-disable -->
Hi @avm_module_owner,

Thanks for requesting/proposing to be an AVM module owner!

We just want to confirm **you agree to the below pages** that define what module ownership means:

- [Team Definitions & RACI](https://azure.github.io/Azure-Verified-Modules/specs/shared/team-definitions)
- [Module Specifications](https://azure.github.io/Azure-Verified-Modules/specs/module-specs)
- [Module Support](https://azure.github.io/Azure-Verified-Modules/help-support/module-support)

Any questions or clarifications needed, let us know!

If you agree, please just **reply to this issue with the exact sentence below** (as this helps with our automation 👍):

"I CONFIRM I WISH TO OWN THIS AVM MODULE AND UNDERSTAND THE REQUIREMENTS AND DEFINITION OF A MODULE OWNER"

Thanks,

The AVM Core Team

#RR
<!-- markdownlint-restore -->

Assign the issue to the new module owner.
Remove these labels:
- Needs: Triage 🔍
- Needs: Module Owner 📣
- Status: Module Orphaned 🟡
Add these labels to the issue:
- Status: In Triage 🔍
- Status: Module Available 🟢
- Status: Owners Identified 🤘 labels to the issue.
- Module classification (resource/pattern/utility): Class: Resource Module 📦 , Class: Pattern Module 📦 or Class: Utility Module 📦
Make sure the issue is assigned to the “AVM - Module Triage” GitHub project, but don’t move the issue to the “Orphaned” column of this board as it will be automatically moved to the “Done” column, once the issue is closed.
Once each incoming owner’s eligibility and written consent are confirmed, replace the departing handles with the approved incoming handles in the root owners array in the same metadata change, retaining every continuing individual or team owner. Remove team handles only if they no longer apply. Obtain approval from either metadata code-owner team and merge through the metadata review process. Confirm every incoming owner has approved access as described in SNFR20 before finalizing the handover.
Use the following text to finalize the new ownership transfer:

➕ Final Confirmation for the New Owner(s) of an Orphaned Module

Hi @avm_module_owner,

Thanks for confirming that you wish to own this AVM module and understand the related requirements and responsibilities!

We just want to ask you to double check a few important things.

**Before taking ownership, confirm the following**:

- Every incoming owner must have approved access through the [Azure Verified Modules (AVM) Module Contributors access package](https://aka.ms/avm/id/access-package/module-contributor), as outlined in [SNFR20](https://azure.github.io/Azure-Verified-Modules/spec/SNFR20).
- Confirm every approved incoming owner is recorded in the root `metadata.json` through a merged [metadata pull request](https://azure.github.io/Azure-Verified-Modules/contributing/module-metadata/) linked to this issue. Metadata does not grant access or review permission.
- The [module index](https://azure.github.io/Azure-Verified-Modules/indexes/) is regenerated automatically every four hours. Check back to confirm your name appears once the metadata change is merged.

Once the required ownership and access steps are confirmed, you can start improving the module as its owner! ✅ Happy coding! 🎉

Any further questions or clarifications needed, let us know!

Thanks,

The AVM Core Team

Once the metadata change is reviewed and merged and the handover and access requirements above are complete, close the orphaned module issue with the following message. The module index updates automatically at the next four-hourly catalog sync.

➕ Closing remarks for the New Owner(s) of an Orphaned Module

- [x] Module Contributors access package approved for all incoming module owners.
- [x] Root metadata ownership change approved by either metadata code-owner team, merged, and linked to this issue through the [metadata review process](https://azure.github.io/Azure-Verified-Modules/contributing/module-metadata/).

The module index is regenerated automatically every four hours, so the ownership change should appear shortly.

Thank you for your work @replace_with_author! I'm closing this issue now.

Deprecated modules

When a module becomes deprecated

If a module meets the criteria described in the “Deprecated Modules” chapter, the module is considered to be deprecated and the below steps must be performed.

Language agnostic steps

Submit a “deprecated module” issue by using the “Deprecate AVM Module 🔴” issue template.
Make sure the Needs: Triage 🔍 and the Status: Module Deprecated 🔴 labels are assigned to the issue and it is assigned to the “AVM - Module Triage” GitHub project.
Record the approved deprecation decision in the issue and complete the language-specific steps below. Do not clear owners to deprecate a module or add a lifecycle/status field to metadata.json.

Bicep specific steps

Update the module and connected files as per the below guidelines:
1. Place the information notice - with the text below - in an DEPRECATED.md file, in the module’s root.
2. Run the utilities/tools/Set-AVMModule.ps1 utility with the module path & -SkipBuild switch as an input. This re-generates the module’s README.md file, so that the README.md file will also contain the same notice in its header. For more instructions on how to use the script, please refer to the corresponding section in the Contribution Guide.
3. Make sure the content of the DEPRECATED.md file is displayed in the README.md in its header (right after the title).
4. Add the the notice NOTE: This is the last published version and the module has since been deprecated. to the top-most ### Changes section of the module’s CHANGELOG.md file
5. Remove the module workflow from the workflows folder.
6. Submit a Pull Request
7. For the AVM maintainers: Once the PR is merged, run the .Platform - Publish [moduleIndex.json] workflow with the regenIndexFromBRM flag set. This will de-list the module so that it won’t show up in the VS-Code Bicep extension going forward.

Deprecating a module does not require editing CODEOWNERS or deleting a GitHub team. BRM has no per-module code-owner entries; /avm/ intentionally has no owners, while metadata.json remains protected by its own code-owner rule.

Terraform specific steps

Place the information notice - with the text below - in the README.md file, in the module’s root.
Archive the module’s repository on GitHub.

Catalog publication

The catalog derives Deprecated from Bicep’s DEPRECATED.md or Terraform’s repository archived flag. Complete the retirement steps; the four-hourly catalog sync then publishes the change.

A Bicep marker applies to that module and all its descendants. A root marker therefore covers every child; a child marker leaves its parent and siblings unaffected. Terraform archival applies to all module entries in the repository.

A module deprecated before it was ever published to the registry is removed from the indexes rather than listed as Deprecated.

Catalog publication does not perform the required notices, Bicep workflow removal and registry-index update, or Terraform repository archival. After a top-level Bicep deprecation is published, verify that module list sync removes it from the issue-template dropdown instead of editing the list by hand.

Deprecation information notice (to be place in the module’s repository as described above)

➕ Deprecated module indicators

⚠️THIS MODULE IS DEPRECATED.⚠️

- It will no longer receive any updates.
- If the underlying Azure service is not deprecated/retired, this module may still be used as is (references to any existing versions will keep working), but it is not recommended for new deployments.
- It is recommended to migrate to a replacement/alternative version of the module, if available.

General feedback/question, documentation update and other standard issues

An issue is a “General Question/Feedback ❔” if it was opened through the “General Question/Feedback ❔” issue template, and has the labels of Type: Question/Feedback 🙋‍♀️ and Needs: Triage 🔍 applied to it.

An issue is a “AVM Documentation Update 📘” if it was opened through the “AVM Documentation Update 📘” issue template, and has the labels of Type: Documentation 📄 and Needs: Triage 🔍 applied to it.

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.

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.

Note

If an intended module proposal was mistakenly opened as a “General Question/Feedback ❔” or other standard issue, and hence, it doesn’t have the Type: New Module Proposal 💡 label associated to it, a new issue MUST be created using the “New AVM Module Proposal 📝” issue template. The mistakenly created “General Question/Feedback ❔” or other standard issue MUST be closed.