I had to ask the maintainers of an open source project today: what's a reasonable cadence for me to submit PRs? I have SO MANY THINGS I want to contribute, but I don't want to overload you.
As a maintainer, it's clear that the best PR is small and clearly described. But even the best PRs can be overwhelming when you get too many at once.
commit 9aee03f
We are super-powered now. We now need to relieve the bottle neck on either ends of the development process:
- discovery and prioritization of work to be done
- assessing and accepting performed work
We're only giving agents the middle bit and it's making everyone much slower…
Slightly unrelated, but I did see someone asking @tom for suggestions for a good first PR. It might be worth creating it as a list and other developers should share the load (and help iterate on ideas)
As a maintainer, the best PR is that one that resolves a clear pain in the software. Not a small fix, or polishing some detail you like, but something that adds raw value.
How often?
The more you do, the more you understand, the more we trust your judgement.
What's the worst…