Azure SDK GitHub Issue Support Process

Azure SDK GitHub Issue Support Process

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.

Overview

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:

This is image title

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:

This is image title

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, needs-author-feedback and needs-team-attention.

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.

Reopening issues

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.

Feedback

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 [email protected] with your topic and we’ll get you setup as a guest blogger.

github azure programming developer

Bootstrap 5 Complete Course with Examples

Bootstrap 5 Tutorial - Bootstrap 5 Crash Course for Beginners

Nest.JS Tutorial for Beginners

Hello Vue 3: A First Look at Vue 3 and the Composition API

Building a simple Applications with Vue 3

Deno Crash Course: Explore Deno and Create a full REST API with Deno

How to Build a Real-time Chat App with Deno and WebSockets

Convert HTML to Markdown Online

HTML entity encoder decoder Online

How to Compare Multiple GitHub Projects with Our GitHub Stats tool

In this article we are going to compare three most popular machine learning projects for you.

How long does it take to develop/build an app?

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.

Developer Career Path: To Become a Team Lead or Stay a Developer?

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

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.

DevOps with Azure GitHub and Azure DevOps

Learn about what the upcoming roadmap is and how to optimize your pipelines to get the maximum flow of value to your customers.