feat: update support statement and references (#2118)

Author: jtracey93

docs/content/contributing/q-and-a.md

@@ -180,7 +180,7 @@ During initial module development module owners/developers need to use your own
 
 ### I'm already using a module today, but its missing a feature, what should I do?
 
-You should use GitHub issues to propose changes or improvements for specific module. Issue request will be router to module owner that **MUST** respond to logged issues within 3 business days. In case that module currently don't have owner, [AVM Core Team]({{% siteparam base %}}/specs/shared/team-definitions/#avm-core-team) will handle request.
+You should use GitHub issues to propose changes or improvements for specific module. Issue request will be routed to module owner that **MUST** respond to logged issues as per the defined [support statement]({{% siteparam base %}}/help-support/module-support/#support-statements). In case that module currently don't have owner, [AVM Core Team]({{% siteparam base %}}/specs/shared/team-definitions/#avm-core-team) will handle request.
 
 ---
 

docs/content/help-support/module-support.md

@@ -3,42 +3,64 @@ title: Module Support
 description: Module Support for the Azure Verified Modules (AVM) program
 ---
 
-As mentioned on the [Introduction]({{% siteparam base %}}/overview/introduction) page, we understand that long-term support from Microsoft in an initiative like AVM is critical to its adoption by consumers and therefore the success of AVM. Therefore we have aligned and provide the below support statement/process for AVM modules.
+{{% notice style="warning" title="Recent Changes to Support Statements" %}}
 
-## Support Mechanism
+The AVM support statements and targets have been updated as of **June 2025**. To understand the changes, please review the below updates on this page.
 
-Azure Verified Modules are supported by the AVM teams, as defined [here]({{% siteparam base %}}/specs/shared/team-definitions/), using GitHub issues in the following order of precedence:
+For more information and reasoning behind the changes, please refer to the blog post we published on this topic: [Tech Community: Azure Verified Modules: Support Statement & Target Response Times Update](https://techcommunity.microsoft.com/blog/azuretoolsblog/azure-verified-modules-support-statement--target-response-times-update/4421489)
 
-1. Module owners/contributors
-2. If there is no response within 3 business days, then the AVM core team will step in by:
-    - First attempting to contact the module owners/contributors to prompt them to act.
-    - If there is no response within a further 24 hours (on business days), the AVM core team will take ownership, triage, and provide a response within a further 2 business days.
-3. In the event of a security issue being unaddressed after 5 business days, escalation to the product group (Bicep/Terraform) to assist the AVM core team, will occur to provide additional support towards resolution; if required.
+{{% /notice %}}
 
-All of this will be automated via the use of the Resource Management feature of the [Microsoft GitHub Policy Service](https://github.com/apps/microsoft-github-policy-service) and GitHub Actions, where possible and appropriate.
+As mentioned on the [Introduction]({{% siteparam base %}}/overview/introduction) page, we understand that long-term support from Microsoft in an initiative like AVM is critical to its adoption by consumers and therefore the success of AVM. Therefore we have aligned and provide the below support statement/process for AVM modules:
 
-{{% notice style="note" %}}
+## Support Statements
 
-Please note that the durations stated above are for a reasonable and useful response towards resolution of the issue raised, if possible, and **not** for a fix within these durations; although if possible this will of course happen.
+{{% notice style="info" %}}
+
+Module owners do go on holiday or have periods of leave from time to time, during these times the AVM core team will attempt to triage issues based on the below on behalf of module owners. 👍
+
+{{% /notice %}}
+
+### For bugs/security issues
+
+- 5 business days for a triage, meaningful response, and ETA to be provided for fix/resolution by module owner (which could be past the 5 days)
+  - For issues that breach the 5 business days, the AVM core team will be notified and will attempt to respond to the issue within an additional 5 business days to assist in triage.
+  - For security issues, the Bicep or Terraform Product Groups may step in to resolve security issues, if unresolved, after a further additional 5 business days.
+
+### For feature requests
+
+- 15 business days for a meaningful response and initial triage to understand the feature request. An ETA may be provided by the module owner if possible.
+
+{{% notice style="caution" title="AVM is Open-Source" %}}
+
+AVM is open-source, therefore, contributions are welcome via Pull Requests or comments in Issues from anyone in the world at any time on any Pull Request or Issues to assist AVM module owners 🌐
+
+Review the [contribution guidance]({{% siteparam base %}}/contributing) to get involved!
 
 {{% /notice %}}
 
-{{% notice style="important" %}}
+{{% notice style="info" %}}
+
+All of this will be automated via the use of the Resource Management feature of the [Microsoft GitHub Policy Service](https://github.com/apps/microsoft-github-policy-service) and GitHub Actions, where possible and appropriate.
+
+{{% /notice %}}
 
-Issues with an AVM module should be raised on the repo they are hosted on, not the AVM Central (`Azure/Azure-Verified-Modules`) repo!
+{{% notice style="note" %}}
 
-*Not an issue if you raise in the wrong place, we will transfer it to it's correct home 👍*
+Please note that the durations stated above are for a reasonable and useful response towards resolution of the issue raised, if possible, and **not** for a fix within these durations; although if possible this will of course happen.
 
 {{% /notice %}}
 
-{{% notice style="important" %}}
+{{% notice style="tip" %}}
 
 Issues that are likely related to an AVM module should be directly submitted on the module's GitHub repository as an "*AVM - Module Issue*". To identify the correct code repository, see the AVM [module indexes]({{% siteparam base %}}/indexes).
 
-If an issue is likely related to the Azure platform, its APIs or configuration, script or programming languages, etc., you need to raise a ticket with Microsoft CSS (Microsoft Customer Services & Support) where your ticket will be triaged for any platform issues. If deemed a platform issue, the ticket will be addressed accordingly. In case it's deemed not a platform but a module issue, you will be redirected to submit a module issue on GitHub.
+If an issue is likely related to the Azure platform, its APIs or configuration, script or programming languages, etc., you need to [raise a ticket with Microsoft CSS (Microsoft Customer Services & Support)](https://azure.microsoft.com/support/create-ticket) where your ticket will be triaged for any platform issues. If deemed a platform issue, the ticket will be addressed accordingly. In case it's deemed not a platform but a module issue, you will be redirected to submit a module issue on GitHub.
 
 {{% /notice %}}
 
+---
+
 ## Orphaned Modules
 
 Modules that have to have the AVM core team or Product Groups step in due to the module owners/contributors not responding, the AVM module will become "orphaned"; see [Module Lifecycle]({{% siteparam base %}}/specs/shared/module-lifecycle/) for more info.

docs/content/resources/faq.md

@@ -331,6 +331,12 @@ However, it is important to note that this does not mean that the modules cannot
 
 ---
 
+### Why did the AVM team change the support statements and targets in June 2025?
+
+The AVM team has updated the support statements and targets to better align with the current state of the AVM initiative and to ensure that module owners can provide meaningful responses and resolutions to issues raised by consumers. The changes were made to improve clarity, set realistic expectations, and enhance the overall support experience for AVM modules and their consumers.
+
+More information about the changes can be found in the blog post, [Tech Community: Azure Verified Modules: Support Statement & Target Response Times Update](https://techcommunity.microsoft.com/blog/azuretoolsblog/azure-verified-modules-support-statement--target-response-times-update/4421489), we published on this topic.
+
 ## Technical questions
 
 ### Should pattern modules leverage resource modules? What if (some of) the required resource modules are not available?

docs/content/specs-defs/includes/shared/shared/non-functional/SNFR11.md

@@ -21,4 +21,4 @@ priority: 1140
 
 ## ID: SNFR11 - Category: Contribution/Support - Issues Response Times
 
-A module owner **MUST** respond to logged issues within 3 business days. See [Module Support]({{% siteparam base %}}/help-support/module-support/) for more information.
+A module owner **MUST** respond to logged issues as defined in the [support statement]({{% siteparam base %}}/help-support/module-support/#support-statements). See [Module Support]({{% siteparam base %}}/help-support/module-support/) for more information.