[MAINTAINERS SUMMIT] Coping with the new-developer flood
Jonathan Corbet <[email protected]>
| Newsgroups | dev.linux.lists.ksummit |
|---|---|
| Message-ID | <[email protected]> |
This topic came to mind after a rather unsatisfying exchange with a would-be contributor today. The 7.1 kernel included work from 530 first-time contributors. That was a record - but a short-lived one. As of -rc6, 7.2 has merged patches from 565 first-time folks. A regression to the long-term mean (2-300) seems unlikely in the near future. A flood of new contributors may be a high-quality problem, but it still can be a problem. We have folks coming in who are unaware of our ways, are often LLM-driven (without disclosing it), and who may have objectives that are not entirely compatible with ours. Maintainers end up having to educate these people; that is part of a maintainer's job, but an increase in that work doesn't help people who are already feeling overwhelmed. Do we need some sort of more organized onboarding structure and, if so, are we able to create and sustain it? At a minimum, one could imagine a bot that notices a patch posted by somebody who has not been seen before and responds with a "Welcome! Here's how we do things here" email. In a better-funded world, we could consider setting up a small group of folks who reach out to first-time people, help them to get their work in order, and ensure that they are connected to the right maintainer. Note that, for 7.2, the rate of first-time people is running at about ten per day, so this isn't really a task for a part-time volunteer. Improving our handling of new contributors has the potential to turn more of them into regular, useful contributors while reducing the training load on maintainers. But, as can be seen here, I don't have a lot of great ideas for how to do that. Maybe others are more imaginative? jon