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

[PATCH] 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.

Signed-off-by: Jakub Kicinski <kuba@kernel.org>
---
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..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.
+
 Selecting the maintainer
 ========================
 
-- 
2.45.2

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

[Greg KH]

On Fri, Jul 12, 2024 at 07:49:03AM -0700, 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@kernel.org>
> ---
> 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..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.
> +
>  Selecting the maintainer
>  ========================
>  

Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1025 bytes --]

On Fri, Jul 12, 2024 at 07:49:03AM -0700, Jakub Kicinski 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.

Reviewed-by: Mark Brown <broonie@kernel.org>

I do think it's fine for people to have open places like github as an
option as well, so long as they're optional for contributors and things
pass through the lists in a normal fashion at some point.  Directing
people towards existing relevant discussions/reviews can work well.  The
main issues are taking things out of all visibility and blocking
contributors.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Shuah Khan]

On 7/12/24 09:25, Mark Brown wrote:
> On Fri, Jul 12, 2024 at 07:49:03AM -0700, Jakub Kicinski 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.
> 
> Reviewed-by: Mark Brown <broonie@kernel.org>
> 
> I do think it's fine for people to have open places like github as an
> option as well, so long as they're optional for contributors and things
> pass through the lists in a normal fashion at some point.  Directing
> people towards existing relevant discussions/reviews can work well.  The
> main issues are taking things out of all visibility and blocking
> contributors.

+1 It is important to point out the prior open conversations if any
that took place when patches go through reviews on kernel mailing
lists. This is the practice for the most part for work stemming from
discussions at conferences such as LPC.

Reviewed-by: Shuah Khan <skhan@linuxfoundation.org>

thanks,
-- Shuah

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

[Mauro Carvalho Chehab]

Em Fri, 12 Jul 2024 09:42:07 -0600
Shuah Khan <skhan@linuxfoundation.org> escreveu:

> On 7/12/24 09:25, Mark Brown wrote:
> > On Fri, Jul 12, 2024 at 07:49:03AM -0700, Jakub Kicinski 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.

True. So what?

> >> 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.  

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.

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.

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.

Regards,
Mauro

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

[Randy Dunlap]

On 7/12/24 11:11 AM, Mauro Carvalho Chehab wrote:
> 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.

Ack that.
  with	s/at public/on public/

-- 
~Randy

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

[Jakub Kicinski]

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.

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

[Dan Williams]

Jakub Kicinski wrote:
[..]
> 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.
> 

To be honest I am lost trying to understand who the audience is and what
the actionable takeaway is from the guidance. It sounds like you are
trying to educate drive-by submitters to push back against requests to
take issues off the list. I think that's a reasonable education
campaign, but doesn't that kind of "submitter bill-of-rights" note
belong in Documentation/admin-guide/reporting-{issues,regressions}.rst
as explicit "how to work your issue upstream" guidance?

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

[Jakub Kicinski]

On Fri, 12 Jul 2024 17:00:44 -0700 Dan Williams wrote:
> To be honest I am lost trying to understand who the audience is and what
> the actionable takeaway is from the guidance. It sounds like you are
> trying to educate drive-by submitters to push back against requests to
> take issues off the list. I think that's a reasonable education
> campaign, but doesn't that kind of "submitter bill-of-rights" note
> belong in Documentation/admin-guide/reporting-{issues,regressions}.rst
> as explicit "how to work your issue upstream" guidance?

Fair point. Not sure if reporting-* is a good place, I care about code
contributions 10x more than issues and other discussions. No strong
preference on the placement, as long as its documented...

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

[Mauro Carvalho Chehab]

Em Fri, 12 Jul 2024 16:45:04 -0700
Jakub Kicinski <kuba@kernel.org> escreveu:

> 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_, 

Then, placing it under Documentation/maintainer is not the right
place ;-)

> 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:

Well, hallway track, invitation-only events and such aren't exactly
"open forums".

> 
>   Open development
>   ----------------

Assuming that this got moved to a contributor's document, as from your
comments the target audience is ocasional community contributors,
see my comments below.

> 
>   Discussions about user reported issues, and development of new code
>   should be conducted in a manner typical for the larger subsystem.

This seems to vague and meaningless to an occasional community
developer.

For instance, how someone that sends a contribution to subsystem X 
knows if the subsystem is a "larger subsystem", so it is "typical"?
What's the "typical" rules?

Btw, larger subsystems usually have their own set of rules. A couple
of them are documented at maintainer-profile.rst, but most don't.

>   It is common for development within a single company to be conducted
>   behind closed doors.

IMO, this is somewhat out of scope. I mean, what a contributor should
expect from this?

I bet a new contributor to a driver made by company X, after reading
this paragraph, would try to submit patches privately to company X
maintainers, which seems to be the opposite from the message you
wanted to give.

>   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.

In the light of a contributor focused document, I would be a lot
more direct here, using a text similar to this:

	Please don't send patches or reply privately to discussions
	initiated on public forums, as most maintainers won't appreciate
	such kind of behavior. Private communications outside company's
	own internal discussions are usually tolerated only when there 
	are very good reasons for that, like when talking about
	undisclosed security 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.

It is clear now, but as Dan pointed out, this is the wrong document
for contributors, as Documentation/maintainers are focused on
maintainers ;-)

So, if something has to be added there, it should be to try to
setup a baseline for maintainer's typical behavior.

> Not reply privately that "it's on the company roadmap, just wait" :|
> Or reply with a patch company has "forgotten to upstream"..

I'm afraid that, in the first case, we'll still see this privately,
as companies won't be disclosing publicly what it is on their
roadmaps.

"Forgotten" patches should indeed be sent publicly for review.
The text I added earlier should hopefully cover it.

Perhaps a note about that at the beginning of
Documentation/process/submitting-patches.rst could be more
effective, e. g. something like this:

diff --git a/Documentation/process/submitting-patches.rst b/Documentation/process/submitting-patches.rst
index 66029999b587..3bdfb820a707 100644
--- a/Documentation/process/submitting-patches.rst
+++ b/Documentation/process/submitting-patches.rst
@@ -16,6 +16,9 @@ for a list of items to check before submitting code.
 For device tree binding patches, read
 Documentation/devicetree/bindings/submitting-patches.rst.
 
+Please notice that Linux patches are meant to be submitted publicly.
+Don't submit patches privately, except for security patches.
+
 This documentation assumes that you're using ``git`` to prepare your patches.
 If you're unfamiliar with ``git``, you would be well-advised to learn how to
 use it, it will make your life as a kernel developer and in general much

> 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.

Again, you placed the comments at the maintainer's document, where
the scope of of "don't do this" is too limited. I would expect
that people that volunteered themselves to do some maintainership 
are more willing to react to positive messages about the expected
maintainer's behavior.

On a contributor's document, though, I agree with you that a set
of rules like don't do top posting, don't submit patches privately,
and such are more effective.

Thanks,
Mauro

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

[Dan Williams]

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@kernel.org>
> ---
> 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..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.

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

[Jakub Kicinski]

On Fri, 12 Jul 2024 11:43:14 -0700 Dan Williams wrote:
> 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.

I don't think so. If your boss comes to you and says "Dan, from now on
try not to reply to customers on the list, open a ticket first and only
reply once tickets is resolved". Is it more useful to you to be able to
extol the benefits of open source process; or to tell them "this is not
allowed, here's a link to a quasi-threat"?

> 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.

Hm, the disconnect may be that you think this happens with maintainers
without upstream experience. So we can train them up to be better.
In most cases it happens to folks with experience who are good
maintainers. They just get 2 orders of magnitudes more patches from
inside the company that outside. Then a contribution comes from outside,
the maintainer is overworked, and tries to shoehorn the patch into the
existing, internal-only process.

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

[Dan Williams]

Jakub Kicinski wrote:
[..]
> > 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.
> 
> Hm, the disconnect may be that you think this happens with maintainers
> without upstream experience. So we can train them up to be better.
> In most cases it happens to folks with experience who are good
> maintainers. They just get 2 orders of magnitudes more patches from
> inside the company that outside. Then a contribution comes from outside,
> the maintainer is overworked, and tries to shoehorn the patch into the
> existing, internal-only process.

Oh, ok, I was failing to grok that from "Open development" note in
isolation.

If the guidance is for maintainers, I would say just put your changelog
directly into the docuementation, that reads as specific and actionable
to me.

For submitters an update to reporting-* might be also be useful to
remind them to push back on requests to go off-list, but not necessary.

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

[Mauro Carvalho Chehab]

Em Fri, 12 Jul 2024 17:05:58 -0700
Jakub Kicinski <kuba@kernel.org> escreveu:

> On Fri, 12 Jul 2024 11:43:14 -0700 Dan Williams wrote:
> > 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.  
> 
> I don't think so. If your boss comes to you and says "Dan, from now on
> try not to reply to customers on the list, open a ticket first and only
> reply once tickets is resolved". Is it more useful to you to be able to
> extol the benefits of open source process; or to tell them "this is not
> allowed, here's a link to a quasi-threat"?

No matter what you write, between your text and their boss's directive,
I bet the latter will be a lot more effective.

> > 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.  
> 
> Hm, the disconnect may be that you think this happens with maintainers
> without upstream experience. So we can train them up to be better.

No, that's the case where you can still "fix" maintainer's behaviors.

> In most cases it happens to folks with experience who are good
> maintainers. They just get 2 orders of magnitudes more patches from
> inside the company that outside. Then a contribution comes from outside,
> the maintainer is overworked, and tries to shoehorn the patch into the
> existing, internal-only process.

It seems unavoidable that internal patches have higher priorities even
if the maintainer is not overloaded.

Even on a perfect world, the degree of confidence on internal patches is 
usually orders of magnitude higher, as internal devs have access to internal
product documentation, future line of products that will re-use the same
driver and, on larger projects, will also be already tested by internal
CI-based regression tests.

The external patches won't have that, so they need to be reviewed by
an internal developer, checked against internal docs and then submitted to 
the company's internal CI regression test infra to achieve the same degree
of confidence.

That not to mention that company will almost always prioritize new
product support over maintaining existing products.

No do/don't kind of document will change that.

A change like that should come top/down, so it has to be addressed 
via other strategies, like documents underlining the benefits of 
upstream first, and tutorials/speeches aimed at companies management
staff.

Thanks,
Mauro

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

[Laurent Pinchart]

On Sat, Jul 13, 2024 at 10:13:28AM +0200, Mauro Carvalho Chehab wrote:
> Em Fri, 12 Jul 2024 17:05:58 -0700 Jakub Kicinski escreveu:
> > On Fri, 12 Jul 2024 11:43:14 -0700 Dan Williams wrote:
> > > 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.  
> > 
> > I don't think so. If your boss comes to you and says "Dan, from now on
> > try not to reply to customers on the list, open a ticket first and only
> > reply once tickets is resolved". Is it more useful to you to be able to
> > extol the benefits of open source process; or to tell them "this is not
> > allowed, here's a link to a quasi-threat"?
> 
> No matter what you write, between your text and their boss's directive,
> I bet the latter will be a lot more effective.

I don't agree with this. I have found clear written rules valuable
personally when discussing with management. Being able to point to
upstream policies and tell "this is not allowed" helped change internal
processes. It will obviously not have a 100% success rate, but it's not
useless.

> > > 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.  
> > 
> > Hm, the disconnect may be that you think this happens with maintainers
> > without upstream experience. So we can train them up to be better.
> 
> No, that's the case where you can still "fix" maintainer's behaviors.
> 
> > In most cases it happens to folks with experience who are good
> > maintainers. They just get 2 orders of magnitudes more patches from
> > inside the company that outside. Then a contribution comes from outside,
> > the maintainer is overworked, and tries to shoehorn the patch into the
> > existing, internal-only process.
> 
> It seems unavoidable that internal patches have higher priorities even
> if the maintainer is not overloaded.
> 
> Even on a perfect world, the degree of confidence on internal patches is 
> usually orders of magnitude higher, as internal devs have access to internal
> product documentation, future line of products that will re-use the same
> driver and, on larger projects, will also be already tested by internal
> CI-based regression tests.
> 
> The external patches won't have that, so they need to be reviewed by
> an internal developer, checked against internal docs and then submitted to 
> the company's internal CI regression test infra to achieve the same degree
> of confidence.

We don't seem to live in the same (perfect or imperfect) world. In my
experience, contributions from external kernel developers are often
better than patches originating from within a company. External
contributors are more used to follow proper upstream review processes.

> That not to mention that company will almost always prioritize new
> product support over maintaining existing products.
> 
> No do/don't kind of document will change that.
> 
> A change like that should come top/down, so it has to be addressed 
> via other strategies, like documents underlining the benefits of 
> upstream first, and tutorials/speeches aimed at companies management
> staff.

-- 
Regards,

Laurent Pinchart

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

[Mauro Carvalho Chehab]

Em Sat, 13 Jul 2024 17:19:56 +0300
Laurent Pinchart <laurent.pinchart@ideasonboard.com> escreveu:

> On Sat, Jul 13, 2024 at 10:13:28AM +0200, Mauro Carvalho Chehab wrote:
> > Em Fri, 12 Jul 2024 17:05:58 -0700 Jakub Kicinski escreveu:  
> > > On Fri, 12 Jul 2024 11:43:14 -0700 Dan Williams wrote:  
> > > > 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.    
> > > 
> > > I don't think so. If your boss comes to you and says "Dan, from now on
> > > try not to reply to customers on the list, open a ticket first and only
> > > reply once tickets is resolved". Is it more useful to you to be able to
> > > extol the benefits of open source process; or to tell them "this is not
> > > allowed, here's a link to a quasi-threat"?  
> > 
> > No matter what you write, between your text and their boss's directive,
> > I bet the latter will be a lot more effective.  
> 
> I don't agree with this. I have found clear written rules valuable
> personally when discussing with management. Being able to point to
> upstream policies and tell "this is not allowed" helped change internal
> processes. It will obviously not have a 100% success rate, but it's not
> useless.

That's basically what I said: such things happen top/down and not at
developer/maintainer level. Sure having it documented somewhere, on
some document that management would actually read can be useful on
discussions, specially when companies hire a third party company to
help with their upstream process.

The point is: a developer-focused document - or even a submission
document process won't affect how companies do their inner source
development: companies that have internally heavy development teams
will basically keep running their own internal development cycle,
being concerned about upstream only when their product managers
authorize them to publicly disclosure patches.

If the goal is to create a management awareness about how to better
cope with upstream, then my suggestion is to write a new document
from scratch [1] focusing specifically on that, containing a list of
best practices with focus on orienting management inside companies 
about how to deal with developers and maintainers working on
upstream.

[1] there is a document there already that seems to be focused at
    management style, but it doesn't cover any best practices
    with regards to innersource/upstream:

	Documentation/process/management-style.rst

> > > > 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.    
> > > 
> > > Hm, the disconnect may be that you think this happens with maintainers
> > > without upstream experience. So we can train them up to be better.  
> > 
> > No, that's the case where you can still "fix" maintainer's behaviors.
> >   
> > > In most cases it happens to folks with experience who are good
> > > maintainers. They just get 2 orders of magnitudes more patches from
> > > inside the company that outside. Then a contribution comes from outside,
> > > the maintainer is overworked, and tries to shoehorn the patch into the
> > > existing, internal-only process.  
> > 
> > It seems unavoidable that internal patches have higher priorities even
> > if the maintainer is not overloaded.
> > 
> > Even on a perfect world, the degree of confidence on internal patches is 
> > usually orders of magnitude higher, as internal devs have access to internal
> > product documentation, future line of products that will re-use the same
> > driver and, on larger projects, will also be already tested by internal
> > CI-based regression tests.
> > 
> > The external patches won't have that, so they need to be reviewed by
> > an internal developer, checked against internal docs and then submitted to 
> > the company's internal CI regression test infra to achieve the same degree
> > of confidence.  
> 
> We don't seem to live in the same (perfect or imperfect) world. In my
> experience, contributions from external kernel developers are often
> better than patches originating from within a company. External
> contributors are more used to follow proper upstream review processes.

It is not about being better/worse. It is about fitting inside the
innersource processes related to quality ensurance (QA). 

Vendors that see their Linux driver as part of their product delivery have 
such processes and won't be willing to accept patches that don't pass on
their processes.

So, all patches (internal or external ones) need to be submitted to
their QA processes, effectively meaning that someone inside such 
companies should be responsible for reviewing the patch.

Heh, you can see this even on distributions like Debian, Ubuntu, 
Fedora, openSUSE - and even on open source userspace projects:
if you submit a bug report or a patch, someone will handle
the ticket, reviewing your patch and/or writing their own patches
to solve the issues.

Inside companies (in special big ones), it usually means that a 
manager or a triage team will pick the bug report/issue and then 
delegate it to an internal developer, who will be internally
owning the upstream patch set, doing tests, reviews and running
it on the company's CI tools.

Smaller companies, companies that are starting now with their
upstream process and companies where Linux is not their main focus
usually delegate it to third party companies, who will be handling
it on their behalf or have small open source teams. Those are the
ones where changing processes are easier. 

Bigger companies have more complex development processes. Among those,
there are the ones where Linux is part of their products. They
are usually responsible for a vast amount of Kernel patches[1].
Changing their process is hard and takes a lot of time/efforts.

[1] Looking at https://lwn.net/Articles/972605/, it can be seen
that: 7.4% is unknown, 6.8% is none and 2.0% consulting, meaning
that more than 80% is credited to "direct" contribution.
Granted, part of those were actually be done by third parties
(or with their help). Still, just the top 17 companies listed there
are responsible for more than 50% of the upstream changes. I bet
that almost all of those (if not all) have their own internal 
innersource processes, and patches are only accepted once the
company developers/maintainers handled external patches and have
them passed though their QA systems.

Thanks,
Mauro

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

[Jakub Kicinski]

On Sat, 13 Jul 2024 18:07:25 +0200 Mauro Carvalho Chehab wrote:
> That's basically what I said: such things happen top/down and not at
> developer/maintainer level. Sure having it documented somewhere, on
> some document that management would actually read can be useful on
> discussions, specially when companies hire a third party company to
> help with their upstream process.
> 
> The point is: a developer-focused document - or even a submission
> document process won't affect how companies do their inner source

It's not a developer-focused document, Mauro.
I said that the document should *ALSO*, not exclusively inform
contributors that delay tactics and dismissing external contributors 
is not okay in Linux.

> development: companies that have internally heavy development teams
> will basically keep running their own internal development cycle,
> being concerned about upstream only when their product managers
> authorize them to publicly disclosure patches.
> 
> If the goal is to create a management awareness about how to better
> cope with upstream, then my suggestion is to write a new document
> from scratch [1] focusing specifically on that, containing a list of
> best practices with focus on orienting management inside companies 
> about how to deal with developers and maintainers working on
> upstream.
> 
> [1] there is a document there already that seems to be focused at
>     management style, but it doesn't cover any best practices
>     with regards to innersource/upstream:
> 
> 	Documentation/process/management-style.rst

Like multiple members of the TAB I did have a stab at rewriting
management style at some point. It's not easy. Don't let perfect 
be the enemy of good.

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 908 bytes --]

On Sat, Jul 13, 2024 at 10:13:28AM +0200, Mauro Carvalho Chehab wrote:
> Jakub Kicinski <kuba@kernel.org> escreveu:

> > I don't think so. If your boss comes to you and says "Dan, from now on
> > try not to reply to customers on the list, open a ticket first and only
> > reply once tickets is resolved". Is it more useful to you to be able to
> > extol the benefits of open source process; or to tell them "this is not
> > allowed, here's a link to a quasi-threat"?

> No matter what you write, between your text and their boss's directive,
> I bet the latter will be a lot more effective.

Like Laurent says I've had a bunch of feedback from people in companies
that their management understands the need to work with upstream
processes and that it's really useful to them to be able to point to
something upstream says.  It's helpful for them in creating good
processes internally and resisting pressure.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Laurent Pinchart]

Hi Jakub,

Thank you for the patch.

On Fri, Jul 12, 2024 at 07:49:03AM -0700, 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@kernel.org>
> ---
> 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..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.

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 ?

> +
>  Selecting the maintainer
>  ========================
>  

-- 
Regards,

Laurent Pinchart

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

[Jakub Kicinski]

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/

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

[Carlos Bilbao]

On 7/12/24 09:49, 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.


So this is completely unenforceable, but as Mauro mentioned, it's an
opportunity to talk about this.
For starters, let's be clear about what the kernel community is actually
losing from closed-door discussions. E.g., if a company wants to fix their
driver, and an employee suggests approach A in an internal discussion, but
someone else prefers approach B, which is then shared publicly on the
mailing lists--is the real issue that the community did not get a chance to
learn about approach A? To discuss it, weigh the pros and cons, and share
opinions? If so, we should note that for published patches preceded by an
internal debate, it's encouraged to include some context in the cover
letters about why different approaches were _not_taken.
>
> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
> ---
> 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..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.
> +
>  Selecting the maintainer
>  ========================
>  


Thanks,

Carlos

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

[Mauro Carvalho Chehab]

Em Sat, 13 Jul 2024 09:28:31 -0500
Carlos Bilbao <carlos.bilbao.osdev@gmail.com> escreveu:

> On 7/12/24 09:49, 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.  
> 
> 
> So this is completely unenforceable, but as Mauro mentioned, it's an
> opportunity to talk about this.
> For starters, let's be clear about what the kernel community is actually
> losing from closed-door discussions. 

Makes sense to me, but IMO it should also be describing what companies
are losing with closed-door discussions: money and time to market. 

The usual excuse for innersource development practices is that this speeds
up product development. In practice, this is often a false premise.

Investing on closed door discussions and then send patch series only
when internal development is done has two major drawbacks from company PoV:

- Other companies with faster/better upstream companies may end having
  solutions merged upstream quicker, reducing or eliminating company market 
  competitive advantages. Also, it means that the internal development will
  need to restart from the beginning, to follow the kAPI interfaces that
  were  proposed/added by other vendors;

- Even if the company is the first to upstream, maintainers may not
  agree with the developed solution, requiring substantial changes,
  and delaying product delivery.

> E.g., if a company wants to fix their
> driver, and an employee suggests approach A in an internal discussion, but
> someone else prefers approach B, which is then shared publicly on the
> mailing lists--is the real issue that the community did not get a chance to
> learn about approach A? To discuss it, weigh the pros and cons, and share
> opinions? If so, we should note that for published patches preceded by an
> internal debate, it's encouraged to include some context in the cover
> letters about why different approaches were _not_taken.
> >
> > Signed-off-by: Jakub Kicinski <kuba@kernel.org>
> > ---
> > 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..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.
> > +
> >  Selecting the maintainer
> >  ========================
> >    
> 
> 
> Thanks,
> 
> Carlos
> 



Thanks,
Mauro