[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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.