You’re right that is the fundamental problem. But for me this somewhat stems from the fact that we don’t have a shared understanding of what the stdlib is, and so the stdlib is a bit unbounded in its size and scope. That leads to a stdlib which is hard to maintain. It’s just like dealing with any scarce resource: you try to cut back on your overall use as best as you can and then become more efficient with what you must still consume; I personally think we don’t have an answer to the “must consume” part of that sentence that leads us to “cut back” to a size we can actually keep maintained so we don’t have 1.6K open PRs.
This piqued my curiosity, so I wrote a script to analyze the open PRs. Also in that thread, the CODEOWNERS file was brought up as a way of taking “ownership” of an area of interest/ownership within the stdlib. To that end, the results were mildly surprising.
276 by core developers 88 by triage team 35 draft PRs 844 matching CODEOWNERS 42 from updated patterns 15 only documentation 419 without reviews 187 without activity 350 orphans 121 only documentation 230 without reviews 124 without activity ------ 1593 open PRs
Note: the “updated patterns” ones are for lines in CODEOWNERS that don’t match what people assume (directories need a different pattern).
So it seems that the majority of open PRs are already covered by at least one core developer (or team). To me, this indicates that developer coverage of the stdlib isn’t causing the rising in open PRs, thus “Batteries Included” is not the factor. Modulo, of course, a core developer taking on too many areas of interest.
I greatly appreciate any feedback on the results, or if more detailed information would be included, I can update the data mining to include those results as well.