From: "Nuno Sá" <nuno.sa@analog.com>
To: Joshua Crofts <joshua.crofts1@gmail.com>
Cc: David Lechner <dlechner@baylibre.com>,
linux-iio@vger.kernel.org, jic23@kernel.org, andy@kernel.org
Subject: Re: [RFC] Maintainer entry profile/contributor guide for IIO
Date: Mon, 21 Sep 2026 10:28:24 +0100 [thread overview]
Message-ID: <arD2UjzKu2k8elgM@nsa> (raw)
In-Reply-To: <20260818090652.000020bc@gmail.com>
On Tue, Aug 18, 2026 at 09:06:52AM +0200, Joshua Crofts wrote:
> On Mon, 17 Aug 2026 19:31:45 -0500
> David Lechner <dlechner@baylibre.com> wrote:
>
> > On 8/17/26 4:18 AM, Joshua Crofts 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!
> >
> > I think there are plenty of new contributor (to the kernel) guides out there.
> > People just don't read them. So I don't think we need another. Nothing wrong
> > with trying to make the existing guides more clear/easy to understand though.
> >
> > A subsystem doc that has our code style quirks and idioms would be helpful
> > though as I don't think that has every been written down in a single place.
> > Especially useful now since AI reviewers will read it even if humans don't.
>
> Yes, but it shouldn't be limited to code style quirks - I highly doubt new
> contributors develop against the togreg tree of iio.git for example.
>
> I'd propose 2 documents:
> - entry profile - documenting the review cycle, patchwork, point people over to
> Sashiko, relevant git tree etc.
> - code style - the TODO is fine for existing problems in the subsystem but doesn't
> point out idioms we have in IIO, i.e. not using (the awful) kernel.h, preferring
> devm_* functions, not failing on a mismatched ID to ensure fallback etc. This is
> stuff that appears a lot in patches.
Personally I do think we have some things (not just coding style) that are very
specific to IIO. But maybe another docs file is not the question. Or at least one
for humans to read :)?! Have you evaluate just having an IIO entry for
sashiko? That way, hopefully the bot would take care about the subsystem
specifics and preferences.
I wanted to do this myself at some point but I'm always pulled for
something else so if this is feels like something you agree and would
like to get done, please go ahead :)
[1]: https://github.com/masoncl/review-prompts/tree/main/kernel/subsystem
My 2 cents!
- Nuno Sá
>
> Whether new contributors read these is up to them (from my experience if you write
> decent docs people still won't read them and ask pointless questions), nevertheless
> if we suspect someone is new we can just point them to these documents instead of
> reiterating the same over and over again.
>
> --
> Kind regards,
> Joshua Crofts
next prev parent reply other threads:[~2026-09-21 9:27 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-17 9:18 [RFC] Maintainer entry profile/contributor guide for IIO Joshua Crofts
2026-08-17 18:50 ` Maxwell Doose
2026-08-18 7:22 ` Joshua Crofts
2026-08-18 0:31 ` David Lechner
2026-08-18 7:06 ` Joshua Crofts
2026-09-19 8:38 ` Krzysztof Kozlowski
2026-09-19 9:35 ` Joshua Crofts
2026-09-19 18:53 ` Krzysztof Kozlowski
2026-09-22 14:54 ` Joshua Crofts
2026-09-21 9:28 ` Nuno Sá [this message]
2026-09-22 14:51 ` Joshua Crofts
2026-09-22 15:03 ` Nuno Sá
2026-09-22 15:07 ` Joshua Crofts
2026-09-22 15:44 ` Nuno Sá
2026-09-22 15:48 ` Joshua Crofts
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=arD2UjzKu2k8elgM@nsa \
--to=nuno.sa@analog.com \
--cc=andy@kernel.org \
--cc=dlechner@baylibre.com \
--cc=jic23@kernel.org \
--cc=joshua.crofts1@gmail.com \
--cc=linux-iio@vger.kernel.org \
/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.