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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 12 Jul 2024 20:11:56 +0200 Mauro Carvalho Chehab wrote:
> Not sure what this somewhat obscure message wants to accomplish.
> 
> It is quite common to have developers and maintainers discussing 
> outside public forums and internally at the companies they're working 
> for. There are lots of reasonable exceptions besides security. On my
> years of experience, the reasons I've seen more often are:
> 
> 1. language and/or cultural barriers;
> 2. teaching and mentoring new developers to start contributing upstream;
> 3. need to have internal discussions in the light of some IP protected
>    material.
> 
> (1) and (2) are very common for non-native English speakers
> and for newbies, and we do want to have more contributions from
> them. (3) is unavoidable, as discussions related to protected
> IP can't be disclosed due to legal reasons.

Those are valid points but I don't know how to weave them in without
losing clarity. The goal is also to call out such behavior to
_contributors_, so that they know they can reach out to more senior
maintainers if it happens to them. We don't know when discussion is
taken private (by definition). Otherwise contributors get mistreated 
by some corpo-maintainer and they turn away from Linux :(

> Also, if you take it to the letter, have discussions on LPC, 
> summits BoFs, other events handled by the open source community 
> and wall conversations are "closed forums/private conversations".
> I've seen a lot of good results produced on such private
> conversations that solved relevant conflicts and got
> materialized as great contributions.
> 
> There's nothing wrong with that, provided that the outcoming of
> such internal discussions are reflected publicly as patches,
> summit minutes, LWN articles, etc.

Would it help if we speak of "open forums" instead of mailing list?
I think LPC including "hallway track" fall squarely under "conducted 
in a manner typical for the larger subsystem." Here's slightly edited 
version:

  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.

> The only issues I see with such talks is that the work when
> co-authored should be properly marked as such and that 
> reviewews/acks taken behind doors don't have the same meaning
> as an upstream review, as they may be due to some internal 
> formalities.
> 
> IMO, the best would instead to give a positive message. E. g.
> something like:
> 
> 	Maintainers must encourage discussions and reviews to happen
> 	at public mailing lists, avoiding whenever possible to have
> 	internal discussions.

That's not the message, tho. If someone emails a company privately 
that's fine. If company has internal processes for its development -
also fine (as explicitly called out). I'm trying to set the baseline,
not describe the ideal world.

I am specifically calling out that if someone submits a patch, or
reports a regression the correct response is to review it on the list.
Like a normal person.
Not reply privately that "it's on the company roadmap, just wait" :|
Or reply with a patch company has "forgotten to upstream"..

Maybe it's a cultural thing, but to me this is where the relentless
positivity is counter-productive. I don't want to encourage people
to be angles. I want them not to do the shitty thing.




[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux