Docs for base maintainer expectations?

do we have any docs describing what's expected from folks stepping up to maintain (small-ish) parts of the kernel like a driver or a protocol?

Experienced developers / maintainers differ like the beautiful snowflakes that we are, but outsiders have much less familiarity with the landscape, and frankly sometimes much less interest in participating once they code lands.

Which makes we wonder if a simple list of responsibilities would be useful as a baseline.

I haven't spotted anything in Docs/process but perhaps someone has a local version for their subsystem?

Quoted 8 lines · Jakub Kicinski

do we have any docs describing what's expected from folks stepping up to maintain (small-ish) parts of the kernel like a driver or a protocol?

Experienced developers / maintainers differ like the beautiful snowflakes that we are, but outsiders have much less familiarity with the landscape, and frankly sometimes much less interest in participating once they code lands.

Quoted 5 lines

Which makes we wonder if a simple list of responsibilities would be useful as a baseline.

I haven't spotted anything in Docs/process but perhaps someone has a local version for their subsystem?

Given I figure you did this on with a -rc1 based tree, which would mean that what I wrote probably does not fit the bill, but I tried to do something along these lines with
https://docs.kernel.org/process/maintainer-soc.html
for which my target audience was people picking up maintenance of DT/soc drivers, which I hope there'll be a few of in RISC-V land soon...

I suggested adding things to it, like putting the trees in linux-next etc, but review feedback suggested that was unsuited to a subsystem specific document.

Quoted 22 lines · On Mon, 10 Jul 2023 20:06:56 +0100 Conor Dooley wrote:

Quoted 8 lines · Jakub Kicinski

do we have any docs describing what's expected from folks stepping up to maintain (small-ish) parts of the kernel like a driver or a protocol?

Experienced developers / maintainers differ like the beautiful snowflakes that we are, but outsiders have much less familiarity with the landscape, and frankly sometimes much less interest in participating once they code lands.

Quoted 5 lines

Which makes we wonder if a simple list of responsibilities would be useful as a baseline.

I haven't spotted anything in Docs/process but perhaps someone has a local version for their subsystem?

Given I figure you did this on with a -rc1 based tree, which would mean that what I wrote probably does not fit the bill, but I tried to do something along these lines with
https://docs.kernel.org/process/maintainer-soc.html
for which my target audience was people picking up maintenance of DT/soc drivers, which I hope there'll be a few of in RISC-V land soon...

Quoted 3 lines

I suggested adding things to it, like putting the trees in linux-next etc, but review feedback suggested that was unsuited to a subsystem specific document.

Thanks for the pointer! I haven't read it before because I assumed it'll describe workflow and suggestions for SoC sub-tree (which it does?)

I was thinking about something way more basic, like "you are expected to reply to bug reports", "you are expected to investigate syzbot problems" etc. :(

IOW the SoC guide reads more like "how to get your code accepted" rather than "what are the externally-facing responsibilities of a maintainer".

It sounds almost as if you're looking for something to present to people when they add themselves as an M: entry against a driver, for when $company sends a patch w/ someone you've not really seen before?

do we have any docs describing what's expected from folks stepping up to maintain (small-ish) parts of the kernel like a driver or a protocol?

Experienced developers / maintainers differ like the beautiful snowflakes that we are, but outsiders have much less familiarity with the landscape, and frankly sometimes much less interest in participating once they code lands.

Which makes we wonder if a simple list of responsibilities would be useful as a baseline. I haven't spotted anything in Docs/process but perhaps someone has a local version for their subsystem?