[Bug]: SUPPORT.md not correct/up-to-date

[jtracey93]

Module Name

N/A

Description

The SUPPORT.md in the repo is not accurate and requires updating.

This also raises the question, that I could not find documented in the codex either, around module owner tracking and roles and responsibilities?

Thinking of how do we state the answers to the below questions:

1. Where do consumers log issues for a module, in this repo or the module repo? (I'm assuming module repo, but should be stated for clarity for consumers)
2. Who do we accept contributions from today/tomorrow? (just FTEs today?)
3. How do we track the owners of each module centrally in this repo?
   a. Should something be added in here for tracking an array/list of owners based on their GitHub IDs? Then it can be used to enable future automation if desired?
4. What happens if an issue is created for a module but the owner doesn't respond in a reasonable amount of time?
   a. Is there an SLA owners should commit to replying, like 3 working days?
   b. Is there a process when the owner doesn't respond within an SLA?
   i. Does the module get deprecated?
   ii. Do we try to find a new owner? And in the meantime the PG handle bug fixes only?

Happy to discuss this further over a meeting if easier and have previously started discussions on this with @grayzu already, so some of this may be in progress 👍

Code

N/A

Relevant log output

No response

What was your expected output?

No response

Other information

No response

[zioproto]

Hello,
for the AKS module the customers are logging issues to the repo of the module.
We are accepting contributions from anyone on GitHub, but there is always a review from a FTE.

Regarding the discussion around SLA, in addition of helping solving bugs in a timely manner, we should also add some clarity about the release cadence.

To understand what could work for our customers, I recently tried to gather some data from active contributing customers running the AKS module in production:
Azure/terraform-azurerm-aks#284

[lonegunmanb]

Hi @jtracey93, thanks for opening this issue, good questions, here're my personal understandings:

1. Where do consumers log issues for a module, in this repo or the module repo? (I'm assuming module repo, but should be stated for clarity for consumers)

An issue that directly related to a module should be opened in module's repo, this repo is for the discussion of Azure Verified Module project.

2. Who do we accept contributions from today/tomorrow? (just FTEs today?)

All pull requests to module's repo are welcomed, but for now only FTE can submit a new module to Verified Module Series.

3. How do we track the owners of each module centrally in this repo?

We have plan to improve this repo so all new verified modules would be required to submit an owner along with repo's url, and the table in the readme file would be updated automatically so we can always find the owner.

4. What happens if an issue is created for a module but the owner doesn't respond in a reasonable amount of time?

I'd like to hear your idea, do you have any suggestion on that?

[jtracey93]

No worries @lonegunmanb, happy with answers to 1 to 3.

As for 4. My personal opinion is that, if an issue is not replied to within 3 working days, there should be a bot (like FabricBot, internally) that will chase the repo maintainers/owners to respond. If no response within a further 2 days, the TFVM PG should be contacted and looped into the issue to assist and track down the owner.

If this happens 3 times, then the module is marked as deprecated and we look for new owners of the module, in that time only bug fixes are supported by the remaining TFVM community.

Effectively a 3 strike and you're out policy! ⚾

Thoughts?

[lonegunmanb]

@jtracey93 3 strike is definitely a policy. I'm thinking of as a brand, Azure Verified Module should be considered as reliable, community friendly and professional. To be honest, we were not doing well in the past years. We've abandoned many modules before, we should not do this again or the community would leave us and never come back.

I think you've raised a very good and serious question: How do we strike a balance between community trust and our own bandwidth. I don't have the answer yet, I'd like to ask for more ideas like you just gave. Thanks for your contribution and please do help us by providing us more insights and thoughts!