At the moment VSCode is sitting at 5000+ Issues, and 191 PR's. VSCode is popular I know, and it has been on github for 4 years now but still that's a huge number. That is just one of many popular repos with numbers like that. React has 201 issues, and 597 PR's, ok not terribly bad. If you keep looking, the patterns are repeated again and again, once a repo gains popularity is nearly impossible to manage PR's and issues.
At what point does this become unmanageable? Would big repos benefit from emailing list patches workflow? Or other magical way, aside from ignoring them?
I really like the way emailing list patches work, such as Linux Kernel or git/git, those github repos are just mirrors, but the email interface is not the greatest, then you have to worry about email server backups on top of git server backups.
For me I think having a contributions system on top of git would be the best thing. For example assign Audio to Mario, Drivers to Alex, Utils to Alisson, Main.py to Owner and so on. When a PR is raised for any code under Drivers send PR notification to Alex, same with issues. In addition it could also be configured with keywords. Once a PR is submitted it becomes cumbersome for others to participate, and submit changes to the PR, this is where mailing list patches excel but to be honest I've read some patch emails, and it looks like 1995 came back with the FW:FW:FW chains is horrible.
---.contributions | ---assignments | ---keywords
Can you imagine if in addition to git, we had a great system for handling and dividing workload for PR's, and issues. Maybe even have contributors pre-approve PR's to take some of the workload off and get points, and get reputation as a PR pre-approver. I think there would be a lot more contributions.
- Better way to handle PR's/Issues high submission rates
- Better way to contribute for multiple people in one PR discussion
- Better notification system based on contributors assignments to folders/files/keywords.
How come no one has created that system, is it a very complex problem to solve? We've put a man on the moon with 1960's technology with hand woven memory modules, there must be a better way.