Create system for collecting infrastructure user stories

[traviscross]

We've been talking about how we might best invest money in ways that would have positive net value for the project.

We often run into issues or asks on the infrastructure side that we fail to capture. Not capturing these user stories means that we don't succeed at solving these or in allocating the funds to where they might be needed to solve them.

Here are two examples that @ehuss and I ran across in discussion:

• When analyzing crater runs, there's often not enough context present to understand what went wrong. To work around this, the analyst must manually clone and build each crate. It would improve the effectiveness of analysts, and be more secure, if there were a web system tied to crater that allowed the analyst to click through each crater failure into a web IDE that opened the failing crate at the appropriate line.
• We've been trying to lower our CI costs recently, and much successful work has been done here. However, a significant portion of our builds fail due to an MSVC issue (see Tracking Issue for high failure rates on Windows MSVC CI with filesystem errors rust#127883). This isn't something our normal contributors tend to have the interest or expertise to resolve, and may benefit from attention from our paid staff or from someone we could contract with the right skills.

There are many other of these kind of things that people tend to just quietly live with, but where we could instead act to meaningfully improve the lives of contributors.

Let's briefly discuss how we might enable better collecting such stories and how we might act on them in allocating funds.

@rustbot labels +I-council-nominated

[rustbot]

Error: This repository is not enabled to use triagebot.
Add a triagebot.toml in the root of the default branch to enable it.

Please file an issue on GitHub at triagebot if there's a problem with this bot, or reach out on #t-infra on Zulip.

[traviscross]

We discussed this in the 2024-12-20 council meeting to collect ideas. Some thoughts that came out of that:

• Whatever we do here, we'd of course need to be sensitive to reviewer bandwidth and the difficulty of finding trusted people to do things.
• There's some overlap between this and the kind of RFQ process that we've discussed.
• There are many real cases where we've had a trusted person doing important work, but then we lose that because the person gets a job.

[ehuss]

With regards to the goal here of spending money: Another question that came up is whether this should be inwards-facing (supporting the project and its maintainers) or outwards-facing (improving Rust for users). I could imagine that there could be some scenario where we decide contracting someone to implement some feature (which I think is how Cargo came to be?) would be the most valuable to the project, and substantially improve adoption (and thus be very beneficial).

For example (not a serious suggestion), we could identify that "users struggle with our current training material" and decide to contract someone to create free, high-quality training material.

I'm inclined to keep the scope narrow here for inwards-facing support. My personal bias is that I think it is very important for the project itself to remain healthy. However, I have difficulty identifying how we could spend money on something and truly make that work (particularly regarding the reviewer/mentor strain, which I think is the biggest bottleneck). Also, if this means creating something (like internal tooling), then we end up with the problem of long-term maintenance (cough triagebot).

I suppose we could also look at this in a broader view than just "spending money". If we use this process and identify a large priority, some existing volunteer/maintainer might seize that and just make it happen without being funded. But I think it would be good to keep the focus narrow here to just funding opportunities, to keep this tractable.