[RFC] Maintainer entry profile/contributor guide for IIO

[RFC] Maintainer entry profile/contributor guide for IIO

[Joshua Crofts]

Hi all,

I was browsing lore and checked out the ksummit mailing list, where the
topic about guiding new contributors arose [1]. New contributors tend to
make the same mistakes when sending patches, causing reviewers to point
these out all the time over and over again. For IIO, this is definitely the
case (I myself send an email telling people not to send a v2 in reply to a
v1 several times a week). Other subsystems have a "Maintainer entry profile"
that contains subsystem-specific process info (DAMON for example [2]) and 
(sometimes even [3]) a document describing the code style of the subsystem
(this would be a great place where to mention things like not using
kernel.h in new drivers etc.). I'm happy to create both of the documents
but it's always great to hear other people's ideas! 

Second of all, the idea of having a bot that would automatically detect new
contributors (i.e. the email they're submitting the patch with doesn't show
up in `git log --author`) and send an email reminding them of the basic rules
(while also referring to the entry profile mentioned above) sounds like a
great idea, but of course hosting and maintaining are pain points.

Please let me know what you think of the above ideas!

[1] https://lore.kernel.org/ksummit/87y0ekm9nw.fsf@trenco.lwn.net/
[2] https://github.com/torvalds/linux/blob/master/Documentation/mm/damon/maintainer-profile.rst
[3] https://github.com/torvalds/linux/blob/master/Documentation/hwmon/submitting-patches.rst

-- 
Kind regards,
Joshua Crofts

Re: [RFC] Maintainer entry profile/contributor guide for IIO

[Maxwell Doose]

On Mon Aug 17, 2026 at 4:18 AM CDT
Joshua Crofts <joshua.crofts1@gmail.com> wrote:

> Hi all,
>
> I was browsing lore and checked out the ksummit mailing list, where the
> topic about guiding new contributors arose [1]. New contributors tend to
> make the same mistakes when sending patches, causing reviewers to point
> these out all the time over and over again. For IIO, this is definitely the
> case (I myself send an email telling people not to send a v2 in reply to a
> v1 several times a week). Other subsystems have a "Maintainer entry profile"
> that contains subsystem-specific process info (DAMON for example [2]) and 
> (sometimes even [3]) a document describing the code style of the subsystem
> (this would be a great place where to mention things like not using
> kernel.h in new drivers etc.). I'm happy to create both of the documents
> but it's always great to hear other people's ideas! 
>

Took a look at [1] and it looks like these are issues across multiple
mailing lists so maybe we should add these to the main
submitting-patches documentation? And then for other IIO-specific things
we can put those in a maintainer entry profile.

> Second of all, the idea of having a bot that would automatically detect new
> contributors (i.e. the email they're submitting the patch with doesn't show
> up in `git log --author`) and send an email reminding them of the basic rules
> (while also referring to the entry profile mentioned above) sounds like a
> great idea, but of course hosting and maintaining are pain points.
>

Hm...this one is more difficult. I guess a good first question to ask
would be "can this be hosted on kernel.org infastructure?" But maybe we
can also ask Greg KH about how he does his automated bot.

thanks,
max

> Please let me know what you think of the above ideas!
>
> [1] https://lore.kernel.org/ksummit/87y0ekm9nw.fsf@trenco.lwn.net/
> [2] https://github.com/torvalds/linux/blob/master/Documentation/mm/damon/maintainer-profile.rst
> [3] https://github.com/torvalds/linux/blob/master/Documentation/hwmon/submitting-patches.rst