Spring 2024 repo health check

[danmoseley]

It's midyear between our surveys and we'd like to hear from you how we're doing.

Last time we heard amongst other things that this repo could be more welcoming to people that aren't experts, and could have more issues up for grabs.

How are we doing? As before, we'll post the aggregated results when we close the survey. This is an anonymous, 2 question survey. (Also posted in several other repos, each have their own survey so you can answer more than one.)

https://www.surveymonkey.com/r/VGFSRD6

[danmoseley]

tagging our hard working @dotnet/aspnet-community-triagers here - the survey's open to everyone but want to make sure we hear from triagers
@egil @marinasundstrom @martincostello @hishamco @gfoidl @Kahbazi @david-acker @Andrzej-W

[danmoseley]

The survey is now closed. Here's the results. We measure satisfaction with an aggregate called NSAT (net satisfaction) that is between 0 and 200 and anything over 100 is good. Note there were only 8 responses (somehow survey got unpinned) so there's an error bar of 15 or so here. NSAT is about the same:

NSAT	NSAT (fall 2023)	NSAT (spring 2023)	NSAT (spring 2022)	NSAT (spring 2021)
138	140	108	124	102

There were four text comments:

1. Hold API meetings in YouTube or make it available for contributors
2. My issues got closed way to early. Even after answering and providing more information it just got ignored. Reopening the issue got seemingly more attention, though apart from giving it a label it got completly ignored. I feel like more feedback on issues would help. It's frustrating because if someone is willing to contribute, it's not lasting forever. If you guys are going to answer after a year the interest in helping might be gone.
3. Work on ASPNET Core itself seems to have slowed in favor of Blazor. Many of the old issues are put into the "Backlog" milestone and have since never progressed to the planning milestones. Does MS consider ASPNET Core to be feature complete? Is there a long-term vision? The roadmap for the upcoming version isn't enough as it covers concrete features and not the direction you want to take the framework towards. Also, issues are left unanswered for a long time with only the labeling of them being done. In general there seems to be minimal engagement in the repo.
4. Some automation we could use to help transfer issues between repos. “@bot /transfer-to dotnet/runtime” or something like that.

For (1) -- @halter73 is this something we've considered in the past?

For (4) -- looks like something like https://github.com/lando/transfer-issue-action might make this possible. Anyone know of nearby precedent for something like this? I'll also ask internally. [edit: presumably we'd want only the original author to be able to move the issue, and then perhaps only once. not clear how that would be achieved. I'm inclined to believe that pinging a maintainer to move an issue shouldn't be too onerous given this isn't super common...?]

(2) and (3) both are asking for more responsiveness to issues -- this consistently comes up in surveys of .NET repos, although not last year for this repo. It's something we've collectively worked to do better at, fundamentally it's about process and efficiency given a fixed number of engineers who spend time not only on issues but other work such as feature coding, bug fixing, other support channels, design and so forth. A couple possible actions for us here might be (a) develop a metric for useful responsiveness that we can work to drive up (b) look at automation and process in nearby repos that perhaps we can learn from. Ideas welcome here (or in Discussions).

[danmoseley]

cc @mkArtak @adityamandaleeka @joperezr

[danmoseley]

closing now -- welcome any feedback at any time in Discussions. Next survey - November.