Azure SDK GitHub Issue Support Process, 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.
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:
New issues are automatically labeled with the following:
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:
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.
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
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.
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!
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 [email protected] with your topic and we’ll get you setup as a guest blogger.
In this article we are going to compare three most popular machine learning projects for you.
This article covers A-Z about the mobile and web app development process and answers your question on how long does it take to develop/build an app.
For a developer, becoming a team leader can be a trap or open up opportunities for creating software. Two years ago, when I was a developer, ... by Oleg Sklyarov, Fullstack Developer at Skyeng company
Accelerate .NET to Azure with GitHub Actions. GitHub Actions makes it easy to automate all your software workflows, now with world-class CI/CD. Easily deploy your .NET Core application to Azure with just one tool, GitHub.
Learn about what the upcoming roadmap is and how to optimize your pipelines to get the maximum flow of value to your customers.