Azure SDK GitHub Issue Support Process
In this blog post, you’ll see what process the Azure SDK team has implemented to ensure that your issue is reviewed promptly and by the right team. The hope is that by gaining some insight into this process, you’ll have a better experience interacting with us on GitHub and a smoother issue resolving process.
The process as described here currently applies to the following repositories:
We also have plans to add the process to these repositories:
A label driven process
1. Triage and routing
New issues are automatically labeled with the following:
||To indicate that the issue needs to be reviewed by triage team|
||To distinguish community created issues from those created by the SDK team for development tracking purposes|
||To indicate issue type. (The assumption is that the issue is a question.)|
The triage team will go through the issues and assess who might be the best owner to assign to an issue and whether an issue needs to be routed to another team to be resolved. More labels will be added as necessary or removed if the issue turns out to be about a bug (for example) rather than a question:
||To indicate what service the issue is referring to|
||Added if the issue needs to be routed to another team|
||These are the other issue types|
For issues that need to be routed to teams best able to assist, i.e. those tagged
Service Attention, there will be a comment that says the following:
Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @GitHubHandle
This will bring attention to the mentioned GitHub handle(s) that they need to help resolve the issue. As the engineers gain more insight into the issue during their investigations, they’ll also adjust the labels accordingly.
Note that for issues that need routing, sometimes it may take a while to find the right contacts, and so response will be slower than usual. When this happens, we encourage you to leave us a comment.
2. Response and follow ups
Depending on the nature of the issue, several rounds of back-and-forth may be needed to resolve the problem after the initial response, which we do our best to provide within 3 business days of issue creation. You may also be asked for more information — for instance error logs or code to replicate the problem — to help with the investigation. To facilitate this back-and-forth process, we use two labels,
When asking you for more input, we also add the
needs-author-feedback label to the issue. When tagged as such, our bot will remind either you or us to look at the issue depending on which side has responded: – when you respond, it adds
needs-team-attention to get our attention (and removes
needs-author-feedback) – when you don’t respond 7 days after
needs-author-feedback is added, it’ll add
no-recent-activity and send you a friendly reminder – if there’s no response from you after another 14 days (so total 21 days), it’ll close the issue – if you respond within 7 days of issue closure, it’ll reopen the issue
Issue types and when they’re resolved
Most of the issues in the repositories are questions. Questions can be addressed without a change in the product; they also include suggestions. As such, questions can be expected to be resolved faster than bugs and feature requests.
Bugs and feature requests are issues that require a change to an existing behavior or an addition of a new behavior in the product (documentation, code, samples, etc.) to be resolved. We may or not have estimates of when these issues will be resolved. When we do, we add milestones to them. When we don’t, we follow up as often as possible to provide updates.
Issues not under consideration
Sometimes there are requests or suggestions that we don’t feel align with the direction of the product or would positively impact the majority of customers. When that is the case, we close the issue with an explanation.
There are also cases where an issue is about something that we will not and/or cannot fix — for example, libraries that have been deprecated or endpoints that have been removed. This is especially true for older issues; we’ve seen 2+ year-old issues about older versions of a product that we no longer have sufficient knowledge on. When that is the case, we close the issue with a brief explanation.
Finally, it’s also possible that the problem brought up in an issue is not considered in the short term. In this case, the issue is put in the backlog. This means other work items are prioritized first, and we’re uncertain about when the issue will be resolved.
Our current support process has room for improvement. Sometimes we or the bot might make the wrong judgment and close an issue prematurely. If that’s the case, you’re welcome to reopen the issue and ping us to help by leaving a comment.
We’re always looking for ways to improve this process, so please feel free to leave us any feedback and/or suggestion here or in any of the repositories above!
Azure SDK Blog Contributions
Thank you for reading this Azure SDK blog post! We hope that you learned something new and welcome you to share this post. We are open to Azure SDK blog contributions. Please contact us at firstname.lastname@example.org with your topic and we’ll get you setup as a guest blogger.
Azure SDK Links
- Azure SDK Website: aka.ms/azsdk
- Azure SDK Intro (3 minute video): aka.ms/azsdk/intro
- Azure SDK Intro Deck (PowerPoint deck): aka.ms/azsdk/intro/deck
- Azure SDK Releases: aka.ms/azsdk/releases
- Azure SDK Blog: aka.ms/azsdk/blog
- Azure SDK Twitter: twitter.com/AzureSDK
- Azure SDK Design Guidelines: aka.ms/azsdk/guide
- Azure SDKs & Tools: azure.microsoft.com/downloads
- Azure SDK Central Repository: github.com/azure/azure-sdk
- Azure SDK for .NET: github.com/azure/azure-sdk-for-net
- Azure SDK for Java: github.com/azure/azure-sdk-for-java
- Azure SDK for Python: github.com/azure/azure-sdk-for-python
- Azure SDK for Android: github.com/Azure/azure-sdk-for-android
- Azure SDK for iOS: github.com/Azure/azure-sdk-for-ios
- Azure SDK for Go: github.com/Azure/azure-sdk-for-go
- Azure SDK for C: github.com/Azure/azure-sdk-for-c
- Azure SDK for C++: github.com/Azure/azure-sdk-for-cpp