Re: [PATCH docs] docs: maintainer: document expectations of small time maintainers

[Greg KH]

On Thu, Jul 13, 2023 at 03:34:32PM -0700, Jakub Kicinski wrote:
> We appear to have a gap in our process docs. We go into detail
> on how to contribute code to the kernel, and how to be a subsystem
> maintainer. I can't find any docs directed towards the thousands
> of small scale maintainers, like folks maintaining a single driver
> or a single network protocol.
> 
> Document our expectations and best practices. I'm hoping this doc
> will be particularly useful to set expectations with HW vendors.
> 
> Signed-off-by: Jakub Kicinski <kuba@xxxxxxxxxx>
> ---
> Please consider this more of a draft than a statement of my opinion.
> IOW prefer suggesting edits over arguing about correctness, hope
> that makes sense.

This looks great to me, thanks for putting it together.

But I do have one objection on the timeline portion:

> ---
>  .../feature-and-driver-maintainers.rst        | 159 ++++++++++++++++++
>  Documentation/maintainer/index.rst            |   1 +
>  2 files changed, 160 insertions(+)
>  create mode 100644 Documentation/maintainer/feature-and-driver-maintainers.rst
> 
> diff --git a/Documentation/maintainer/feature-and-driver-maintainers.rst b/Documentation/maintainer/feature-and-driver-maintainers.rst
> new file mode 100644
> index 000000000000..ee8ccc22b16a
> --- /dev/null
> +++ b/Documentation/maintainer/feature-and-driver-maintainers.rst
> @@ -0,0 +1,159 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +
> +==============================
> +Feature and driver maintainers
> +==============================
> +
> +The term "maintainer" spans a very wide range of levels of engagement
> +from people handling patches and pull requests as almost a full time job
> +to people responsible for a small feature or a driver.
> +
> +Unlike most of the chapter, this section is meant for the latter (more
> +populous) group. It provides tips and describes the expectations and
> +responsibilities of maintainers of a small(ish) section of the code.
> +
> +Driver and alike most often do not have their own mailing lists and
> +git trees but instead send and review patches on the list of a larger
> +subsystem.
> +
> +Responsibilities
> +================
> +
> +The amount of maintenance work is usually proportional to the size
> +and popularity of the code base. Small features and drivers should
> +require relatively small amount of care and feeding. Nonetheless
> +when the work does arrive (in form of patches which need review,
> +user bug reports etc.) it has to be acted upon very promptly.
> +Even when single driver only sees one patch a month, or a quarter,
> +a subsystem could well have a hundred such drivers. Subsystem
> +maintainers cannot afford to wait a long time to hear from reviewers.
> +
> +The exact expectations on the review time will vary by subsystem
> +from 1 day (e.g. networking) to a week in smaller subsystems.

"to a few weeks".

I can't do 1 day, or even 1 week for the subsystems I maintain
(especially during merge windows or vacations.)  How about that line
being:
	from 1 day (e.g. networking) to a few weeks for smaller subsystems.

And then add a link to "For specific subsystem response times, please
see the document in [insert link here to where we keep the subsystem
expectations]"

And yeah, I do need to go add some process/maintainer-* files for the
subsystems I maintain, it might be a good idea to also say that any new
subsystems also provide this so we can start catching up on that.

thanks,

greg k-h