search

dotnet / sdk

Core functionality needed to create .NET Core projects, that is shared between Visual Studio and CLI
https://dot.net/core
MIT License
2.73k stars 1.07k forks source link

Whats the triage process here? #29960

Closed jogibear9988 closed 1 year ago

jogibear9988 commented 1 year ago

Whats the process here for issues to get viewed/discussed/fixed?

I see there are many issues on the pages wich are marked as "untriaged", and got additional no comments. Whats the way here to get things going?

I created a issue here too (https://github.com/dotnet/msbuild/issues/8319) (or it was moved here), and for me it's very urgent. What can I do to help?

baronfel commented 1 year ago

I thought we had a devguide.md or docs for this (this can serve as a note that we should polish up what I'm about to type), but we don't so I'm going to go into it here.

There are two kinds of code in the SDK:

Examples of the second category include things like the test command and infrastructure (which is owned by the Test team), or the watch command and infrastructure (which is mostly managed by the ASP.NET team).

When issues come in, we have a bot that tries to assign an 'Area' label to the issue. These area labels are tied to specific teams in the CODEOWNERS file in the repo root. The teams assigned to these labels then have their own processes for triaging the issues. I can't speak for other teams, but I can illustrate the SDK and MSBuild teams' triage process here.

Both the SDK and MSbuild teams have a team member that's on triage duty for a period of time. This person's role is to ensure that issues have relevant Area labels, triage new SDK- or MSBuild-specific issues to establish root causes and then farm out to relevant team members for final resolution, and stay on top of infrastructural issues like automated codeflow, high-priority cross-team activities like making sure things are merged before release lockdowns. For especially gnarly issues, they will add the needs team triage label to the issue, and once a week the team meets to discuss next steps for these. Once issues are assigned to a particular team member, we'll talk priority and make decisions about release timelines for the issue (if it needs to be in a monthly servicing release, or if it can wait until the next release of the .NET SDK, or the next major version of the .NET SDK). Based on that conversation the team members will work on the issues as time and other obligations allow. Note that not all of the teams work can be represented in the issues for this repo. Tasks like internal compliance, cross-team engagements, etc won't be shown here, so you shouldn't use the triaged issues list assigned to a particular team member as a barometer for how long it'll take them to get to an issue.

Teams other than the SDK and MSBuild teams have different processes that I can't speak to.

Aside from this - issues are open for any and all contributions! Especially those that we've marked as up for grabs and good first issue. We love seeing engaged users help us make the product better - and we try to prioritize review and merge of user contributions. One thing that can be confusing for external folks is the release schedule, so we especially try to bring insight into where we are in the release, and what the considerations would be for acceptance for a servicing release fix (example here) vs a next-major-version release fix.

marcpopMSFT commented 1 year ago

@baronfel , the SDK process is somewhat different than that as I have a query I run that filters out all non-SDK issues, then I assign out to members of the team to do triage. There's not one person on triage duty each week but rather everyone as we get 15-20 incoming a week. I usually do that assignment on Tuesdays.

The person assigned is supposed to as they have time either mark it for a release, raise it for discussion, reply with comments, or move it to backlog. For the particular issue this customer raised, that seems very much specific to their build rather than a bug so the person assigned would probably try to get some initial guidance on how to dig further and assign the milestone as discussion. We would normally treat it as lower priority as individual customer builds can be very expensive to diagnose and add up quickly.