Jakub Kicinski wrote: > 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. > > Signed-off-by: Jakub Kicinski <kuba@xxxxxxxxxx> > --- > CC: workflows@xxxxxxxxxxxxxxx > CC: linux-doc@xxxxxxxxxxxxxxx > --- > .../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..ac7798280201 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, 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. > + This reads as a vague ambiguous quasi-threat with no actionable way to enforce it. In contrast, successful maintainers already have a sense of the benefits of pushing discussions to the list as much as possible. For new and growing maintainers, which I assume are the audience for this guidance, that are unaware of the pitfalls of taking conversations off-list, they likely need help understanding the *benefits* of open development. So if this goes in as is, so be it, but it feels like a missed opportunity to extoll the virtues of open development. The benefits are in the same vector as the "release early, release often" guidance where the urge to polish a solution in private is a common trait of newcomers. Lets document some tribal knowledge of how one moves past that first instinct.
