[PATCH v2] docs: maintainer: discourage taking conversations off-list

[PATCH v2] docs: maintainer: discourage taking conversations off-list

[Jakub Kicinski]

Multiple vendors seem to prefer taking discussions off list, and
ask contributors to work with them privately rather than just send
patches to the list. I'd imagine this is because it's hard to fit in
time for random developers popping up with features to review into
packed schedule. From what I've seen "work in private" usually means
someone on the company side will be assigned to handle the interaction,
possibly months later. In worst case, the person scheduled to help
the contributor takes over and writes the code themselves.
This is not how the community is supposed to work.

The discussion on v1 wasn't very conclusive. I am not capable of
distilling many of the suggestions into meaningful changes.
I believe the paragraph works in the context of the document.

FWIW the paragraph has been consulted with 2 contributors to whom
the described situation has happened.

Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Shuah Khan <skhan@linuxfoundation.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
---
Encouraged by the immediate acks from notable folks I'm submitting
again, although I'm tempted to resend as part of maintainer-netdev :(
Please do read the rest of the doc to understand the context:
https://docs.kernel.org/next/maintainer/feature-and-driver-maintainers.html

v2:
 - replace mailing list with "forum" to avoid excluding GH / GitLab etc
 - call out private >email< conversations, face-to-face conversations
   are obviously fine
v1: https://lore.kernel.org/20240712144903.392284-1-kuba@kernel.org/

CC: mchehab@kernel.org
CC: dan.j.williams@intel.com
CC: laurent.pinchart@ideasonboard.com

CC: workflows@vger.kernel.org
CC: linux-doc@vger.kernel.org
---
 .../maintainer/feature-and-driver-maintainers.rst     | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/Documentation/maintainer/feature-and-driver-maintainers.rst b/Documentation/maintainer/feature-and-driver-maintainers.rst
index f04cc183e1de..fb94a9b29061 100644
--- a/Documentation/maintainer/feature-and-driver-maintainers.rst
+++ b/Documentation/maintainer/feature-and-driver-maintainers.rst
@@ -83,6 +83,17 @@ bugs as well, if the report is of reasonable quality or indicates a
 problem that might be severe -- especially if they have *Supported*
 status of the codebase in the MAINTAINERS file.
 
+Open development
+----------------
+
+Discussions about user reported issues, and development of new code
+should be conducted in a manner typical for the larger subsystem.
+It is common for development within a single company to be conducted
+behind closed doors. However, development and discussions initiated
+by community members must not be redirected from public to closed forums
+or to private email conversations. Reasonable exceptions to this guidance
+include discussions about security related issues.
+
 Selecting the maintainer
 ========================
 
-- 
2.45.2

Re: [PATCH v2] docs: maintainer: discourage taking conversations off-list

[Jonathan Corbet]

Jakub Kicinski <kuba@kernel.org> writes:

> Multiple vendors seem to prefer taking discussions off list, and
> ask contributors to work with them privately rather than just send
> patches to the list. I'd imagine this is because it's hard to fit in
> time for random developers popping up with features to review into
> packed schedule. From what I've seen "work in private" usually means
> someone on the company side will be assigned to handle the interaction,
> possibly months later. In worst case, the person scheduled to help
> the contributor takes over and writes the code themselves.
> This is not how the community is supposed to work.
>
> The discussion on v1 wasn't very conclusive. I am not capable of
> distilling many of the suggestions into meaningful changes.
> I believe the paragraph works in the context of the document.
>
> FWIW the paragraph has been consulted with 2 contributors to whom
> the described situation has happened.
>
> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Reviewed-by: Mark Brown <broonie@kernel.org>
> Reviewed-by: Shuah Khan <skhan@linuxfoundation.org>
> Signed-off-by: Jakub Kicinski <kuba@kernel.org>

After pondering on this for a while, I've decided to go ahead and apply
this.  The intent is good; we can always improve the execution if
somebody has a good idea.

I do have to say that all of the "must" language in this document is a
bit off-putting and may well convince potential maintainers that they
don't actually want to play this game.

Thanks,

jon