Handling pull requests of new contributors

1

I opened a pull requests several weeks ago and have yet to receive any feedback on it. It's a small (and IMHO uncontroversial) PR that would let me get rid of some unsafe code.

This topic isn't about a particular PR, though. And it's certainly not about the assignee who, I assume, is a volunteer and a human being with other things going on in their life. That said, contributors are human too and having a PR languish for weeks can be demotivating.

Regular contributors tend to explicitly ask for a review using r?, knowing who is a good reviewer for their PR. New contributors have to rely on the automated process and I'm wondering whether that process should be tweaked to improve the contributors' experience.

Suggestions

  • Adjust the initial rustbot message (perhaps just for new contributors) to manage expectations: "Project members are predominantly volunteers with their own priorities and lives beyond Rust. It may take several weeks before they get back to you. Please be patient."
  • If there is no feedback for a long time, ping either the appropriate team or just one additional member. This will generate notifications, so the duration must be several weeks at the least.

FWIW, I've don't generally expect open source maintainers to get back to me. However, Rust markets itself as a safe and dependable language. So when I file a PR, especially one that touches on safety, I do expect a response within a reasonable time frame.

11 Likes
2

I like the idea of rustbot providing info to set expectations.

4 Likes
3

Fully in favour of this. Something similar happened recently for ACPs: ACP template should better reflect actual feedback latency · Issue #180 · rust-lang/libs-team · GitHub

Note that libs-api is particularly busy, and any library change that makes something new compile -- and thus can't be reverted if it goes wrong somehow -- needs them to look at it.

The bandwidth of people with ideas to contribute extensions to the standard library will always be higher than the bandwidth of people to decide whether to include them.

(Internal implementation tweaks or docs improvements or similar tend to merge much faster, since if worst came to worst they can just be reverted, so the oversight bar is lower.)

4

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.