Yes, actually. The idea is to imagine the best environment a new intern can experience in a team at a software company and then apply the same principles to treating open-source contributors (if they are willing to dedicate several hours of their time).

Enthusiastic developers can join a virtual meeting (on Discord and/or https://codeshare.io/ or something) where they, I, and anyone else who wants to spectate can discuss a feature from the idea phase all the way to the phase where everyone's personal tasks are designated. A 2-hour meeting is usually all that's needed to start 2 weeks of efficient offline development.

Drive-by PRs by people I've never talked to? Always a mess and never worth the time for me to even read, in my experience. It's odd how the commercial software world has developed this nearly perfectly efficient environment for teammates to work together, and it's completely ignored for many open-source projects.

tl;dr If I wanted to contribute to an open-source project, I'd prefer to work on a major 40 hour feature with the guarantee that my work will be accepted rather than 40 minutes and say "here's a surprise patch, take it or leave it".

Thanks a lot, this is an interesting conversation.

I've worked in commercial tech most of my career and agree that industry has done a good job of making software collaboration effective.

Now I'm building applications based on open source software, and (as with commercial development using OSS) sometimes that means that clearing roadblocks or improving application functionality depends on making upstream changes.

I tend to be a bit reluctant to spend time in meetings because I find text-based conversation easier and more accurate.

Also since there are multiple dependencies and projects involved, it's tricky to divide time between developing all of those relationships. It's still valuable to do, certainly, but it can be challenging.

In this scenario, the approach I've adopted is that I'll spend time to fix the problem 'locally' (in a fork if necessary), offer the patch upstream (to feed back improvements, which aim to be generic -- but also with selfish motivations to reduce maintenance burden), and then move on.

Anecdotally, that's working fairly well so far - approximately an 80% merge rate over ~100 pull requests. I don't have great stats on how much time was spent on each, nor how complex each one was. A few definitely took some detailed puzzle-solving and investigation.