I maintain a many projects which are not huge, but some are in the thousands of Github stars and often get an issue or two per day. Across all of my projects I probably see 10-20 new issues per week.<p>My approach is straightforward: help them help themselves. We have some easy things we can do to encourage people to find the information they need to sort out the problem, coaxing out of them debug logs, core dumps, and so on, and sometimes give them our suspicions about the problem. Then we tell them to start digging, and that we're around to answer questions if they need help finding their problem. This process ends with a patch <i>from that user</i>.<p>My projects also often have an IRC channel, where users often help each other with straightforward issues, and we never have to get involved. Sometimes a dev is paying attention and will give them the same rundown. If someone seems enthusiastic about digging and making a fix, they're invited to the dev IRC where they can receive more developer-oriented support in understanding the code and introducing them to the contribution workflow.<p>Sure, it's not the friendliest approach for anyone who isn't willing or able to figure it out themselves. But we're all volunteers and no one is going to volunteer their time to do something they dislike. We volunteered to write code because we like writing code. End-user support is not fun for us. If you like it, volunteering to do it is easy and has basically no onboarding time, you just show up in the support channels and start helping people.
For the "Issue Triage" analysis I would say lines_added,lines_remove,commits,number_issues_involved_in would be interesting to see as well.<p>For example caphrim007 is number 5 in commits over that period but added 5x as many lines of code as next closest committer. However, the code maybe against a new under-used feature so the actual end-user usage could be low.<p>It would also be interesting to juxtapose top committers commit graphs against issue assignment and resolution timeline. When does issue triage by top committers wax and wane? Do big commits (new features) overlap with issue assignment/resolution dates? Does high volume issue assignment/resolution follow big commits?
Core developers that created and grew the project should shift over time to almost exclusively a role of only offering advice on the core implementation and spending their time introducing newbies, patiently answering support questions, and creating tutorials.<p>Most of the dysfunction I see in open source projects that take an ambivalent attitude towards the bug fixes and urgent feature needs of long-term users seems based in pure ego. Core devs want to keep being the leading edge designers and implementers of the project and are extremely stingy about letting new or intermediate contributors to the project bring fresh perspective and excitement into big new feature implementation or refactoring.<p>You can make a lot of disingenuous arguments that this is to protect the style and design approach of the original core, but it’s not. It’s just ego.<p>Look, people are obviously free to say if they are dedicating their free time to some open source project, then they only want to work on the aspects of it they like or the aspects that might seem glamorous in a blog post or conference presentation or whatever.<p>Being “allowed” to take that attitude is pretty much inconsequential though. If you do that, your project is entering one of two modes: death mode where new developers realize you will only permit them to work on gruntwork and you lose any capacity to actually fix things because nobody joins your project, or North Korea mode like the linux kernel where some crazed monarch or oligarchs use intimidation and public shaming as primary code review techniques.<p>If you are a really smart core dev of open source, stop working on the big new features. I know it hurts your ego to let your baby into the hands of newbies. Instead, do more code review, tutorials, answers on SO, and go way out of your way to make new contributors feel like you are impressed with their skill, that you want to pair with them through meaningful PRs right away, no “good first task” grunt work ego crap.