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

[Jakub Kicinski <kuba@kernel.org>]

On Sat, 13 Jul 2024 17:26:51 +0300 Laurent Pinchart wrote:
> > +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, maintainers must not redirect discussions
> > +and development related to the upstream code from the upstream mailing lists
> > +to closed forums or private conversations. Reasonable exceptions to this
> > +guidance include discussions about security related issues.  
> 
> Overall I think this is fine, but I'm a bit concerned it could be
> interpreted too broadly. Brainstorming on mailing lists is hard, and
> kernel communities often conduct technical discussions face to face, in
> conferences or other events. Sometimes those discussions are as private
> as they can get, I've found myself cycling multiple times to the office
> of a fellow developer who happens to work close to my place in order to
> discuss kernel API design in front of a white board. We did our best to
> publish brainstorming notes on mailing lists, and patches are then of
> course reviewed and further discussed in public. Is this a behaviour you
> want to discourage, or is this considered fine ?

That's fine. 

I hope in the context of the rest of the doc the new section makes
sense. The doc is aimed at less upstream-savvy driver maintainers.
The section before says "you must respond to bug reports" and the
section after says "the person selected as maintainer should be a
developer not a manager".

I hope when reading in that context it is fairly clear that these are
not "rules of Linux". More pointing out where folks more familiar with
corporate environment get tripped up.

I was planning to add this guidance to maintainer-netdev, but folks
pushed back saying that the guidance is generally applicable.

I semi-quoted some example situation we're aiming at here:
https://lore.kernel.org/all/20240712164504.76b15e31@kernel.org/