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 responsive to issues, PR's and API proposals, and speed up build times.

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/VBSF75R

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-meta
See info in area-owners.md if you want to be subscribed.

[danmoseley]

Tagging @dotnet-runtime-triage here, the folks whose hard work helps keep this repo responsive and running smoothly.
@tmds @filipnavara @clamp03 @am11 @huoyaoyuan @Sergio0694 @teo-tsirpanis @shushanhf @SingleAccretion

The survey is open to everyone reading this though

[danmoseley]

This survey is now closed. NSAT (net satisfaction) is an aggregate measure we use a lot to summarize. The range is 0-200 and above 100 is considered good. Error is quite low as there were 28 responses. NSAT remains fairly good as it was when we last measured 6 months ago.

NSAT	NSAT (fall 2023)	NSAT (spring 2023)	NSAT (spring 2022)	NSAT (spring 2021)
125	126	120	127	102

Here's the text comments (verbatim but with references to individuals removed)

Building the repo

The build instructions could use more clarifications.

Improve the build process - extremely flaky and error prone. Simply updating Visual Studio will often expose issues with building. Unacceptable for such a critical repo. Please eithers simplify your build process or make it way more robust to Visual Studio updates.

Fix #96141. Building the runtime on my available machines takes 25% longer than it should for my Windows on ARM devices.

Pull requests

1. hope the CI pipelines would be more stable, it would be confusing if CI failed with failure not related to the contribution changes

2. hope the community contribution PRs could be reviewed in time to increase the contributor participation

It's frustrating not knowing the status of a pull request review or when it will be reviewed if it hasn't started yet.

API requests

There are a few API proposals I submitted relating to string and it seems like the area is kind of neglected nowadays ... In particular, C# does need to have SplitFirst/SplitLast on a string which is an extremely common operation and it is sad to see the issue go unresponded. I'm certain were someone like .... to submit it, it would have passed API review and implemented long ago.

Issue management

3. mark more simple issues as help-wanted to increase community contributions, maybe we could add an internal deadline for community pickup, if no community contributions about it, MSFT could do it still

Misc

(these are arguably out of scope of repo management)

Some inactive areas may need more active support since people are still using it. The biggest pain in my sight is XML. The structure of System.Xml is very old and not performant. However, xml is very complex and hard to implement by consumers either. There's XmlBean in Java world that receives good reputation and better performance than System.Xml. Given that .NET toolchain including MSBuild is using XML, we may consider to continuously improve it. But the effort can be higher than JSON so it's up to the leaders to discuss on this.

I would to modify the style of the github's coding reviewing. Now the code reviewing is not convenience. For example, during a PR, we always push a serious patches, but it's not convenience for displaying these patches' difference. Especially when the main branch had updated, my PR need rebase to the latest main branch, after I rebase this PR, the comparing result is not our expected which including the merged patches from main. At this case, when just for a rebase operation, it's better to display a rebase operation other than a normal force push. If you compare the gerrit's code review with the github code review, the rebase operation is just display rebase so you don't need worry about new modification and you don't need redundant code review. Besides, the gerrit is very easy and convenience for displaying the differences between two patches.

Make it fast as C++, so game developers don't have to deal with C++.