From: Jonathan Corbet <corbet@lwn.net>
To: ksummit@lists.linux.dev
Subject: [MAINTAINERS SUMMIT] Coping with the new-developer flood
Date: Wed, 05 Aug 2026 17:26:11 -0600 [thread overview]
Message-ID: <87y0ekm9nw.fsf@trenco.lwn.net> (raw)
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
next reply other threads:[~2026-08-05 23:26 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-05 23:26 Jonathan Corbet [this message]
2026-08-06 9:24 ` [MAINTAINERS SUMMIT] Coping with the new-developer flood Matthieu Baerts
2026-08-06 10:10 ` Dan Carpenter
2026-08-06 15:42 ` Theodore Tso
2026-08-06 15:57 ` Greg KH
2026-08-06 17:28 ` Konstantin Ryabitsev
2026-08-06 18:56 ` Shuah Khan
2026-08-06 19:32 ` Dan Carpenter
2026-08-06 21:14 ` Mark Brown
2026-08-07 3:23 ` Theodore Tso
2026-08-07 9:20 ` Matthieu Baerts
2026-08-07 11:56 ` Laurent Pinchart
2026-08-07 12:28 ` James Bottomley
2026-08-07 12:40 ` Laurent Pinchart
2026-08-07 12:47 ` Arnaldo Carvalho de Melo
2026-08-07 13:36 ` Laurent Pinchart
2026-08-07 13:56 ` Rafael J. Wysocki (Intel)
2026-08-07 16:38 ` Miguel Ojeda
2026-08-07 12:51 ` James Bottomley
2026-08-07 13:34 ` Laurent Pinchart
2026-08-07 13:42 ` Mark Brown
2026-08-07 13:02 ` Mimi Zohar
2026-08-07 13:12 ` Dan Carpenter
2026-08-07 16:37 ` Miguel Ojeda
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87y0ekm9nw.fsf@trenco.lwn.net \
--to=corbet@lwn.net \
--cc=ksummit@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.