[andkon]

Wowwww this is lovely! Have you written anywhere about what you've done on the projects you've maintained along these lines? I think we'd all benefit from hearing more about what you can do in a project to make contributors more capable and helpful.

After all, it seems like their incentives should align? Like, why wouldn't they want to make a contribution that actually helps? Making that easier to actually do seems like time well spent for everyone.

[DannyBee]

I used to write it in a blog a long time ago, but that website died and i'm just too busy these days ;)

Ironically, my experience overall as a manager (not just in open source) is that when you ask this question, a lot of the time you get the answer that nobody did anything, because of the latter thing you describe.

IE nobody is acting malicious, but they expected people would want to do X on their own, so nobody tried anything specifically.

In those cases, once you get people onto the path of specifically trying things, and seeing what happens, it's often a great improvement. Even without lots of other process/measurement.

Beyond that, one of the things we do internally, that is a bit harder to do well externally due to social norms/etc, is ask people. In open source, it's trickier because if i contribute randomly to 200 projects, i don't want every single one of them spamming me directly to find out more about my experiences ;)

But occasionally poking people on PR's that are taking a while, or went really well, etc, and seeing if the people they are willing to fill out a form anonymously or something, even if heavily biased, would at least give you some notions of what is going well or not for people.

There is also a lot to be said for analytics on PRs, but again, open source is not very advanced at this right now, so i don't think it's near as viable yet as just asking some people

[andkon]

This is really helpful. I love the idea of reaching out on long-running and getting feedback directly - that seems a great qualitative way to get a sense of what's going on, and fits well with my own experience about how to talk to early-stage customers who seem to have some value from a product I've made, but which probably isn't quite meeting people's needs yet. Turns out that's often enough to figure out the biggest, most helpful changes. Thank you!

[lamontcg]

A lot of the time making a contribution that actually helps means fixing something foundational rather than bolting on another quick bug fix.

That takes work, sometimes quite a lot of it, and there's no trick around getting the work done any easier.

A lot of contributions to open source are simply worth what you paid for them, which is nothing.

Early in a project it is possible to find areas of the codebase where easy things haven't yet been done because there just haven't been enough programmer-hours done yet to burn through the simple stuff. Late in a mature project the easy things have mostly gotten done and finding more easy stuff becomes difficult, and as you pull apart simple looking issues they start to look hard.

[nyanpasu64]

I often encounter foundational or complex issues (incorrect memory management, deep complexity) when trying to diagnose crashes in open-source apps. And I get frustrated trying to understand deep complexity is frustrating, and maintainers (who haven't looked into the crashes so far, and in one case fixed an earlier crash based on me debugging it for them) don't take it kindly when I complain about the unmanageable complexity and poor stability of these apps. What should I do in this case? Take a break then keep trying? Slow down debugging and spend more time reading and taking notes? Abandon the project, and switch to using/contributing to codebases I find simpler/more cohesive and easier to understand?