From: Sasha Levin <sashal@kernel.org>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: corbet@lwn.net, josh@joshtriplett.org, kees@kernel.org,
konstantin@linuxfoundation.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, rostedt@goodmis.org,
workflows@vger.kernel.org
Subject: Re: [PATCH v2 1/2] README: restructure with role-based documentation and guidelines
Date: Mon, 11 Aug 2025 11:48:03 -0400 [thread overview]
Message-ID: <aJoQs_5Mp7-LAtTS@lappy> (raw)
In-Reply-To: <CAMuHMdWaVvAfm6LMxSpPuz3yZ7FDAexbUTOXrg58TqoWbce5ag@mail.gmail.com>
On Mon, Aug 11, 2025 at 10:22:34AM +0200, Geert Uytterhoeven wrote:
>Hi Sasha,
>
>On Sun, 10 Aug 2025 at 10:09, Sasha Levin <sashal@kernel.org> wrote:
>> Reorganize README to provide targeted documentation paths for different
>> user roles including developers, researchers, security experts,
>> maintainers, and AI coding assistants. Add quick start section and
>> essential docs links.
>>
>> Include proper attribution requirements for AI-assisted contributions
>> using Assisted-by tags with agent details and tools used.
>>
>> Signed-off-by: Sasha Levin <sashal@kernel.org>
>
>Thanks for your patch!
>
>> --- a/README
>> +++ b/README
>
>> +Who Are You?
>> +============
>> +
>> +Find your role below:
>> +
>> +* New Kernel Developer - Getting started with kernel development
>> +* Academic Researcher - Studying kernel internals and architecture
>> +* Security Expert - Hardening and vulnerability analysis
>> +* Backport/Maintenance Engineer - Maintaining stable kernels
>> +* System Administrator - Configuring and troubleshooting
>> +* Maintainer - Leading subsystems and reviewing patches
>
>Kernel Maintainer?
>Driver/Subsystem Maintainer?
I tried to use similar terms to the ones used by the rest of our docs.
In this case, the CoC interpertation actually defines this term :)
The Code of Conduct uses the term "maintainers" numerous times.
In the kernel community, a "maintainer" is anyone who is
responsible for a subsystem, driver, or file, and is listed in
the MAINTAINERS file in the kernel source tree.
So I just went with "Maintainer".
>> +* Hardware Vendor - Writing drivers for new hardware
>> +* Distribution Maintainer - Packaging kernels for distros
>> +* Agentic Coding - AI assistants working with kernel code
>
>Given the extensive split, what about normal (existing) kernel
>developers?
Those people don't read the docs anyway :p
How about something like:
Existing Kernel Developer
-------------------------
Continue advancing your kernel development expertise:
* Locking and Concurrency: Documentation/locking/index.rst
* RCU (Read-Copy Update): Documentation/RCU/index.rst
* Subsystem APIs: Documentation/driver-api/index.rst
* Performance Analysis: Documentation/trace/index.rst
* Testing Infrastructure: Documentation/dev-tools/testing-overview.rst
* Patch Series Management: Documentation/process/5.Posting.rst
* Maintainer Handbooks: Documentation/process/maintainer-handbooks.rst
* Cross-Architecture Development: Documentation/arch/index.rst
* Kernel Debugging: Documentation/process/debugging/kgdb.rst
--
Thanks,
Sasha
next prev parent reply other threads:[~2025-08-11 15:48 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-09 23:40 [PATCH v2 0/2] Add unified configuration for coding agents Sasha Levin
2025-08-09 23:40 ` [PATCH v2 1/2] README: restructure with role-based documentation and guidelines Sasha Levin
2025-08-10 15:44 ` Joe Perches
2025-08-10 16:46 ` Sasha Levin
2025-08-11 0:10 ` Joe Perches
2025-08-11 0:06 ` Randy Dunlap
2025-08-11 8:22 ` Geert Uytterhoeven
2025-08-11 15:48 ` Sasha Levin [this message]
2025-08-15 6:19 ` Kees Cook
2025-08-09 23:40 ` [PATCH v2 2/2] agents: add unified agent coding assistant configuration Sasha Levin
2025-08-10 7:01 ` Greg KH
2025-08-10 14:22 ` Sasha Levin
2025-08-14 0:36 ` Steven Rostedt
2025-08-15 6:23 ` Kees Cook
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=aJoQs_5Mp7-LAtTS@lappy \
--to=sashal@kernel.org \
--cc=corbet@lwn.net \
--cc=geert@linux-m68k.org \
--cc=josh@joshtriplett.org \
--cc=kees@kernel.org \
--cc=konstantin@linuxfoundation.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rostedt@goodmis.org \
--cc=workflows@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.