[MAINTAINERS SUMMIT] Maintainers Support Group

[MAINTAINERS SUMMIT] Maintainers Support Group

[Steven Rostedt]

There has been several topics brought up already about maintainer burnout.
A while back, I was talking with another maintainer that basically told me
that they were ready to quit being a maintainer because it's not fun
anymore. There's a lot of requirements and basically have to deal with crap
from submitters. The Code of Conduct has been successful in helping to keep
a more civil environment, but all the focus has mainly been around telling
maintainers how to behave. But maintainers are humans too, and their work
can cause a large amount of frustration to build up with no way to release
that pressure.  When that frustration boiled over, it use to come out with
a nasty rant to at some unlucky submitter. Although this may have helped
the maintainer, but in the long run, this was not healthy for the community
in the whole, and the CoC has been created to prevent that from happening.
The problem is that there's been no replacement for the maintainer to
release their frustration.

I brought up to the TAB a suggestion of starting basically a "Maintainer's
support group". A place a maintainer, or even a submitter can go to when
they are feeling frustrated. This is not a replacement for the Code of
Conduct committee. This is more of a preventive measure. Ideally, the Code
of Conduct committee members should be very bored where there are no
submitted reports.  That would mean our community is running in a very
smooth way. But that's currently not the case. There's been a few cases
that have come up where if the maintainer had someone to vent to, it could
have prevented the violation of the Code of Conduct.

The idea is this:

When a maintainer is getting frustrated with a submitter or another
maintainer, or even a submitter is getting frustrated with a maintainer,
they would have a place to find a list of people that can help. They would
pick one of the people and send an email to them with a subject of
"[MAINTAINER SUPPORT]" (or something like that). This would let the
supporting maintainer know that this email is about support and should be
confidential and follow the guidelines. The email will include who and why
they are frustrated with the other person. Again, this is *not* a Code of
Conduct issue. This is not to point blame, just frustration. Sometimes
people just can not work with other people. The supporting maintainer can
be an outside POV and can possibly help with explaining why the other
person is acting the way they are. Or the supporting maintainer can find
another maintainer to work with this person.

Several of us already do some of this. But its only a few. I would like to
make it a more formal process where those that have not gone to conferences
and such would still know who they can talk with.

We discussed this within the TAB, but I would like to bring this up to a
more general discussion at Maintainers Summit.

I know some people would just dismiss this as unneeded, but I've talked to
others that said this would be very useful. If it's useful for some, then I
think it's worth it. If you believe it's unneeded, then you don't need to
be involved with it (although someone could be submitting something about
their frustrations with you ;)

To recap what I'm asking: We would have a list of volunteers of support
group members. There would be guidelines on how to interact.  These guidelines
will be public so that the submitter is also aware of them. One of the
guidelines we discussed was what happens if the volunteer is just too busy,
or they themselves do not want to deal with the individual submitting their
frustrations. Both cases would have the same response, and that is to reply
saying that they are not available and to please reach out to someone else
on the list.

Thoughts?

-- Steve

Re: [Tech-board-discuss] [MAINTAINERS SUMMIT] Maintainers Support Group

[Shuah]

Hi Steve,

On 9/19/23 10:10, Steven Rostedt wrote:
> There has been several topics brought up already about maintainer burnout.
> A while back, I was talking with another maintainer that basically told me
> that they were ready to quit being a maintainer because it's not fun
> anymore. There's a lot of requirements and basically have to deal with crap
> from submitters. The Code of Conduct has been successful in helping to keep
> a more civil environment, but all the focus has mainly been around telling
> maintainers how to behave.

As a member of the CoC, I respectfully disagree with the statement "but all the
focus has mainly been around telling maintainers how to behave." This impression
might have been the result of one unfortunate incident that took place last year.
is only part of what CoC has been doing.

A majority of reports are related to incorrect understanding of how the community
works and discusses technical issues. Most of them get resolved without involving
the community. This is behind the scenes silent work CoC does.

It is unfortunate that CoC is being viewed as a body that is focused on telling
maintainers how to behave. I would encourage to not view CoC work based on one
or two cases that were outliers. CoC worked very hard to resolve them fairly and
that benefited the community as a whole.

But maintainers are humans too, and their work
> can cause a large amount of frustration to build up with no way to release
> that pressure.  When that frustration boiled over, it use to come out with
> a nasty rant to at some unlucky submitter. Although this may have helped
> the maintainer, but in the long run, this was not healthy for the community
> in the whole, and the CoC has been created to prevent that from happening.
> The problem is that there's been no replacement for the maintainer to
> release their frustration.
> 

+1 on maintainers are humans too, and their work can be challenging. I have
observed maintainers at the receiving end of nasty rants from submitters,
other developers, and maintainers and experienced it myself. It was helpful
when one or more people reached out privately to provide support and
understanding.

> I brought up to the TAB a suggestion of starting basically a "Maintainer's
> support group". A place a maintainer, or even a submitter can go to when
> they are feeling frustrated. This is not a replacement for the Code of
> Conduct committee. This is more of a preventive measure. Ideally, the Code
> of Conduct committee members should be very bored where there are no
> submitted reports.  That would mean our community is running in a very
> smooth way. But that's currently not the case. There's been a few cases
> that have come up where if the maintainer had someone to vent to, it could
> have prevented the violation of the Code of Conduct.
>
> The idea is this:
> 
> When a maintainer is getting frustrated with a submitter or another
> maintainer, or even a submitter is getting frustrated with a maintainer,
> they would have a place to find a list of people that can help. They would
> pick one of the people and send an email to them with a subject of
> "[MAINTAINER SUPPORT]" (or something like that). This would let the
> supporting maintainer know that this email is about support and should be
> confidential and follow the guidelines. The email will include who and why
> they are frustrated with the other person. Again, this is *not* a Code of
> Conduct issue. This is not to point blame, just frustration. Sometimes
> people just can not work with other people. The supporting maintainer can
> be an outside POV and can possibly help with explaining why the other
> person is acting the way they are. Or the supporting maintainer can find
> another maintainer to work with this person.
> 

I am not sure adding one more body whose work overlaps with what CoC does is
helpful. Creating yet another mailing list for people that are drowning under
the flood emails might not be productive.

> Several of us already do some of this. But its only a few. I would like to
> make it a more formal process where those that have not gone to conferences
> and such would still know who they can talk with.
> 
> We discussed this within the TAB, but I would like to bring this up to a
> more general discussion at Maintainers Summit.
> 
> I know some people would just dismiss this as unneeded, but I've talked to
> others that said this would be very useful. If it's useful for some, then I
> think it's worth it. If you believe it's unneeded, then you don't need to
> be involved with it (although someone could be submitting something about
> their frustrations with you ;)
> 

I really can't weigh in on whether this is needed or unneeded until I hear
more about it and how it would work.

> To recap what I'm asking: We would have a list of volunteers of support
> group members. There would be guidelines on how to interact.  These guidelines
> will be public so that the submitter is also aware of them. One of the
> guidelines we discussed was what happens if the volunteer is just too busy,
> or they themselves do not want to deal with the individual submitting their
> frustrations. Both cases would have the same response, and that is to reply
> saying that they are not available and to please reach out to someone else
> on the list.

- Does our community have bandwidth to create a support group
   and policies to run it effectively?
- How does this new body interact and interface with CoC?
- What happens when CoC and the support group are put in a situation
   to handle an issue?

Lot of details to work out. I would encourage inviting CoC committee
members to the Maintainer Summit if this issue is accepted and added
to the agenda.

thanks,
-- Shuah

Re: [Tech-board-discuss] [MAINTAINERS SUMMIT] Maintainers Support Group

[Steven Rostedt]

On Tue, 19 Sep 2023 10:52:40 -0600
Shuah <shuah@kernel.org> wrote:

> Hi Steve,
> 
> On 9/19/23 10:10, Steven Rostedt wrote:
> > There has been several topics brought up already about maintainer burnout.
> > A while back, I was talking with another maintainer that basically told me
> > that they were ready to quit being a maintainer because it's not fun
> > anymore. There's a lot of requirements and basically have to deal with crap
> > from submitters. The Code of Conduct has been successful in helping to keep
> > a more civil environment, but all the focus has mainly been around telling
> > maintainers how to behave.  
> 
> As a member of the CoC, I respectfully disagree with the statement "but all the
> focus has mainly been around telling maintainers how to behave." This impression
> might have been the result of one unfortunate incident that took place last year.
> is only part of what CoC has been doing.

The reason I stated it this way is because of how the CoC committee came to
be. It was because of the reputation of the Linux kernel maintainers, and
how "toxic" of an environment it was. There's a reason Linus took a hiatus
from being the lead maintainer.

> 
> A majority of reports are related to incorrect understanding of how the community
> works and discusses technical issues. Most of them get resolved without involving
> the community. This is behind the scenes silent work CoC does.

Yes, but they are still reports about Conduct. This has nothing to do with that.

> 
> It is unfortunate that CoC is being viewed as a body that is focused on telling
> maintainers how to behave. I would encourage to not view CoC work based on one
> or two cases that were outliers. CoC worked very hard to resolve them fairly and
> that benefited the community as a whole.

Sorry if that's the impression I made as that was not my intent. But the CoC is
viewed as a result of what came out of maintainers behaving badly.

> 
> But maintainers are humans too, and their work
> > can cause a large amount of frustration to build up with no way to release
> > that pressure.  When that frustration boiled over, it use to come out with
> > a nasty rant to at some unlucky submitter. Although this may have helped
> > the maintainer, but in the long run, this was not healthy for the community
> > in the whole, and the CoC has been created to prevent that from happening.
> > The problem is that there's been no replacement for the maintainer to
> > release their frustration.
> >   
> 
> +1 on maintainers are humans too, and their work can be challenging. I have
> observed maintainers at the receiving end of nasty rants from submitters,
> other developers, and maintainers and experienced it myself. It was helpful
> when one or more people reached out privately to provide support and
> understanding.
> 
> > I brought up to the TAB a suggestion of starting basically a "Maintainer's
> > support group". A place a maintainer, or even a submitter can go to when
> > they are feeling frustrated. This is not a replacement for the Code of
> > Conduct committee. This is more of a preventive measure. Ideally, the Code
> > of Conduct committee members should be very bored where there are no
> > submitted reports.  That would mean our community is running in a very
> > smooth way. But that's currently not the case. There's been a few cases
> > that have come up where if the maintainer had someone to vent to, it could
> > have prevented the violation of the Code of Conduct.
> >
> > The idea is this:
> > 
> > When a maintainer is getting frustrated with a submitter or another
> > maintainer, or even a submitter is getting frustrated with a maintainer,
> > they would have a place to find a list of people that can help. They would
> > pick one of the people and send an email to them with a subject of
> > "[MAINTAINER SUPPORT]" (or something like that). This would let the
> > supporting maintainer know that this email is about support and should be
> > confidential and follow the guidelines. The email will include who and why
> > they are frustrated with the other person. Again, this is *not* a Code of
> > Conduct issue. This is not to point blame, just frustration. Sometimes
> > people just can not work with other people. The supporting maintainer can
> > be an outside POV and can possibly help with explaining why the other
> > person is acting the way they are. Or the supporting maintainer can find
> > another maintainer to work with this person.
> >   
> 
> I am not sure adding one more body whose work overlaps with what CoC does is
> helpful. Creating yet another mailing list for people that are drowning under
> the flood emails might not be productive.

Ah, this is where things differ tremendously. There will be no mailing list!

It will be a list of people and their emails. The submitter will pick from
that list of people to send one of them a personal email. All interactions will
be done on a private 1 to 1 basis. No "committee" involved.

I would expect the guidelines that they follow would come out of the TAB.

> 
> > Several of us already do some of this. But its only a few. I would like to
> > make it a more formal process where those that have not gone to conferences
> > and such would still know who they can talk with.
> > 
> > We discussed this within the TAB, but I would like to bring this up to a
> > more general discussion at Maintainers Summit.
> > 
> > I know some people would just dismiss this as unneeded, but I've talked to
> > others that said this would be very useful. If it's useful for some, then I
> > think it's worth it. If you believe it's unneeded, then you don't need to
> > be involved with it (although someone could be submitting something about
> > their frustrations with you ;)
> >   
> 
> I really can't weigh in on whether this is needed or unneeded until I hear
> more about it and how it would work.
> 

Sure.

> > To recap what I'm asking: We would have a list of volunteers of support
> > group members. There would be guidelines on how to interact.  These guidelines
> > will be public so that the submitter is also aware of them. One of the
> > guidelines we discussed was what happens if the volunteer is just too busy,
> > or they themselves do not want to deal with the individual submitting their
> > frustrations. Both cases would have the same response, and that is to reply
> > saying that they are not available and to please reach out to someone else
> > on the list.  
> 
> - Does our community have bandwidth to create a support group
>    and policies to run it effectively?

It will be up to those that want to help.

> - How does this new body interact and interface with CoC?

Ideally, they would not.

The point of the support group is to keep things from escalating to the
point where there is a CoC complaint. If the support group does not work
and there is an escalation, then the CoC can take over and the support
group will no longer be involved.

-- Steve

> - What happens when CoC and the support group are put in a situation
>    to handle an issue?
> 
> Lot of details to work out. I would encourage inviting CoC committee
> members to the Maintainer Summit if this issue is accepted and added
> to the agenda.
> 
> thanks,
> -- Shuah

Re: [Tech-board-discuss] [MAINTAINERS SUMMIT] Maintainers Support Group

[Steven Rostedt]

On Tue, 19 Sep 2023 13:19:13 -0400
Steven Rostedt <rostedt@goodmis.org> wrote:

> Ah, this is where things differ tremendously. There will be no mailing list!

We discussed having a mailing list and came up with the conclusion that any
mailing list would be a bad idea. The biggest reason against it is if
someone is getting frustrated with one of the volunteers. We want a way for
them to be able to choose exactly who gets to see what they want to say,
and more importantly, who doesn't get to see it.

As things should be kept confidential, I would not want to put the pressure
on the volunteer to have to keep something confidential that they
shouldn't. The guidelines should state that although rants may be allowed,
any threat of violence or other illegal activities mentioned in the
correspondence will not remain private. This would allow volunteers to
report any threats without feeling that they are breaking the
confidentiality pledge.

-- Steve

Re: [Tech-board-discuss] [MAINTAINERS SUMMIT] Maintainers Support Group

[James Bottomley]

On Tue, 2023-09-19 at 10:52 -0600, Shuah wrote:
> Hi Steve,
> 
> On 9/19/23 10:10, Steven Rostedt wrote:
> > There has been several topics brought up already about maintainer
> > burnout.  A while back, I was talking with another maintainer that
> > basically told me that they were ready to quit being a maintainer
> > because it's not fun anymore. There's a lot of requirements and
> > basically have to deal with crap from submitters. The Code of
> > Conduct has been successful in helping to keep a more civil
> > environment, but all the focus has mainly been around telling
> > maintainers how to behave.
> 
> As a member of the CoC, I respectfully disagree with the statement
> "but all the focus has mainly been around telling maintainers how to
> behave." This impression might have been the result of one
> unfortunate incident that took place last year. is only part of what
> CoC has been doing.

If it helps, I proposed a more generic version of a maintainer stress
session here:

https://lore.kernel.org/ksummit/ab9cfd857e32635f626a906410ad95877a22f0db.camel@HansenPartnership.com/

It doesn't mention the code of conduct at all.  I really think
focussing on stress coping rather than pointing fingers at the alleged
stress inducers would be the way to move forwards on this.  Although it
might be helpful to have a non judgmental listening session about what
everyone thinks the major stress inducers are.

James

Re: [Tech-board-discuss] [MAINTAINERS SUMMIT] Maintainers Support Group

[Shuah]

On 9/19/23 11:54, James Bottomley wrote:
> On Tue, 2023-09-19 at 10:52 -0600, Shuah wrote:
>> Hi Steve,
>>
>> On 9/19/23 10:10, Steven Rostedt wrote:
>>> There has been several topics brought up already about maintainer
>>> burnout.  A while back, I was talking with another maintainer that
>>> basically told me that they were ready to quit being a maintainer
>>> because it's not fun anymore. There's a lot of requirements and
>>> basically have to deal with crap from submitters. The Code of
>>> Conduct has been successful in helping to keep a more civil
>>> environment, but all the focus has mainly been around telling
>>> maintainers how to behave.
>>
>> As a member of the CoC, I respectfully disagree with the statement
>> "but all the focus has mainly been around telling maintainers how to
>> behave." This impression might have been the result of one
>> unfortunate incident that took place last year. is only part of what
>> CoC has been doing.
> 
> If it helps, I proposed a more generic version of a maintainer stress
> session here:
> 
> https://lore.kernel.org/ksummit/ab9cfd857e32635f626a906410ad95877a22f0db.camel@HansenPartnership.com/
> 
> It doesn't mention the code of conduct at all.  I really think
> focussing on stress coping rather than pointing fingers at the alleged
> stress inducers would be the way to move forwards on this.  Although it
> might be helpful to have a non judgmental listening session about what
> everyone thinks the major stress inducers are.
> 

Thank you for the link. I think your proposal addresses various stress
factors for maintainers and developers alike. I am referring to wearing
two hats problem of balancing corporate strategy and development needs.

Maybe it is time we collapsed all the proposals related to maintainer
stress and addressed then instead of piecemeal discussions.

thanks,
-- Shuah

Re: [Tech-board-discuss] [MAINTAINERS SUMMIT] Maintainers Support Group

[Theodore Ts'o]

On Tue, Sep 19, 2023 at 10:52:40AM -0600, Shuah wrote:
> As a member of the CoC, I respectfully disagree with the statement "but all the
> focus has mainly been around telling maintainers how to behave." This impression
> might have been the result of one unfortunate incident that took place last year.
> is only part of what CoC has been doing.
> 
> A majority of reports are related to incorrect understanding of how the community
> works and discusses technical issues. Most of them get resolved without involving
> the community. This is behind the scenes silent work CoC does.
> 
> It is unfortunate that CoC is being viewed as a body that is focused on telling
> maintainers how to behave. I would encourage to not view CoC work based on one
> or two cases that were outliers. CoC worked very hard to resolve them fairly and
> that benefited the community as a whole.

Shuah, I don't think this is the fault of the CoC.  Much of it is in
how people interpret the CoC, or think it should be adapted.  For
example, just this past week, on the maintainer's summit, this
statement:

>Waah, waah, waah. The buffer cache is *trivial*. If you don't like the
>buffer cache, don't use it. It's that simple.[1]

... resulted in Linus being accused as a CoC violation.

I'm not sure that it qualifies as a CoC violation, but Dave Chinner
certainly thought so, and publically accused Linus of that[2].

Personally, I'm not convinced that people calling people out for real
or imagined CoC violations is always going to be productive,
especially when it wasn't an explicit personal attack.  It's these
sorts of edge cases is what causes some people to fear and badmouth
CoC's.  Which is, I think, unfortunate.

[1] https://lore.kernel.org/all/CAHk-=wg=xY6id92yS3=B59UfKmTmOgq+NNv+cqCMZ1Yr=FwR9A@mail.gmail.com/
[2] https://lore.kernel.org/all/ZQTfIu9OWwGnIT4b@dread.disaster.area/

						- Ted

Re: [Tech-board-discuss] [MAINTAINERS SUMMIT] Maintainers Support Group

[Steven Rostedt]

On Tue, 19 Sep 2023 16:39:11 -0400
"Theodore Ts'o" <tytso@mit.edu> wrote:

> On Tue, Sep 19, 2023 at 10:52:40AM -0600, Shuah wrote:
> > As a member of the CoC, I respectfully disagree with the statement "but all the
> > focus has mainly been around telling maintainers how to behave." This impression
> > might have been the result of one unfortunate incident that took place last year.
> > is only part of what CoC has been doing.
> > 
> > A majority of reports are related to incorrect understanding of how the community
> > works and discusses technical issues. Most of them get resolved without involving
> > the community. This is behind the scenes silent work CoC does.
> > 
> > It is unfortunate that CoC is being viewed as a body that is focused on telling
> > maintainers how to behave. I would encourage to not view CoC work based on one
> > or two cases that were outliers. CoC worked very hard to resolve them fairly and
> > that benefited the community as a whole.  
> 
> Shuah, I don't think this is the fault of the CoC.  Much of it is in
> how people interpret the CoC, or think it should be adapted.

And one huge distinction between the CoC and the support group is that the
support group will have absolutely zero authority to lay out any
consequences to all of the parties involved. Where as the CoC can if it
deems fit, escalate the ramifications if things do not move it a way it
feels necessary.

It's like having a family member that is abusing drugs. You go to a support
group to get help. You do not go to law enforcement, as that could escalate
to unintended consequences to the individual you want to help.

That alone will keep people from contacting CoC in some situations where a
support group could indeed help.

Look at Bart's reply to my email. He was concerned about leaving a trail in
some mailing list. That's the type of situation I want to address.

-- Steve

Re: [Tech-board-discuss] [MAINTAINERS SUMMIT] Maintainers Support Group

[Christian Brauner]

> It's like having a family member that is abusing drugs. You go to a support

This is a professional work environment. Such emotionally charged
examples really aren't good analogies.

A support group is a nice idea but only complimentary to the CoC. And
the two should be kept clearly separated.

Re: [Tech-board-discuss] [MAINTAINERS SUMMIT] Maintainers Support Group

[Theodore Ts'o]

On Tue, Sep 19, 2023 at 04:39:11PM -0400, Theodore Ts'o wrote:
> On Tue, Sep 19, 2023 at 10:52:40AM -0600, Shuah wrote:
> > As a member of the CoC, I respectfully disagree with the statement "but all the
> > focus has mainly been around telling maintainers how to behave." This impression
> > might have been the result of one unfortunate incident that took place last year.
> > is only part of what CoC has been doing.
> > 
> > A majority of reports are related to incorrect understanding of how the community
> > works and discusses technical issues. Most of them get resolved without involving
> > the community. This is behind the scenes silent work CoC does.
> > 
> > It is unfortunate that CoC is being viewed as a body that is focused on telling
> > maintainers how to behave. I would encourage to not view CoC work based on one
> > or two cases that were outliers. CoC worked very hard to resolve them fairly and
> > that benefited the community as a whole.
> 
> Shuah, I don't think this is the fault of the CoC.  Much of it is in
> how people interpret the CoC, or think it should be adapted.

I just realized that this statement was a bit ambiguous; in the first
CoC, I meant the "Code of Conduct Committee".  In the second CoC in
this sentence, I made the "Code of Conduct".

From the context of what you wrote, I *think* you were consistently
referring to the Code of Conduct Committee, but when I see CoC I tend
think the actual "Code of Conduct" and not the committee which
enforces the CoC.

Apologies for any confusion,

						- Ted

Re: [Tech-board-discuss] [MAINTAINERS SUMMIT] Maintainers Support Group

[Randy Dunlap]

On 9/19/23 15:01, Theodore Ts'o wrote:
> On Tue, Sep 19, 2023 at 04:39:11PM -0400, Theodore Ts'o wrote:
>> On Tue, Sep 19, 2023 at 10:52:40AM -0600, Shuah wrote:
>>> As a member of the CoC, I respectfully disagree with the statement "but all the
>>> focus has mainly been around telling maintainers how to behave." This impression
>>> might have been the result of one unfortunate incident that took place last year.
>>> is only part of what CoC has been doing.
>>>
>>> A majority of reports are related to incorrect understanding of how the community
>>> works and discusses technical issues. Most of them get resolved without involving
>>> the community. This is behind the scenes silent work CoC does.
>>>
>>> It is unfortunate that CoC is being viewed as a body that is focused on telling
>>> maintainers how to behave. I would encourage to not view CoC work based on one
>>> or two cases that were outliers. CoC worked very hard to resolve them fairly and
>>> that benefited the community as a whole.
>>
>> Shuah, I don't think this is the fault of the CoC.  Much of it is in
>> how people interpret the CoC, or think it should be adapted.
> 
> I just realized that this statement was a bit ambiguous; in the first
> CoC, I meant the "Code of Conduct Committee".  In the second CoC in
> this sentence, I made the "Code of Conduct".
> 
> From the context of what you wrote, I *think* you were consistently
> referring to the Code of Conduct Committee, but when I see CoC I tend
> think the actual "Code of Conduct" and not the committee which
> enforces the CoC.
> 
> Apologies for any confusion,

Thanks for explaining. I was confused by Shuah's comments (but I
came to the same conclusion that you did).

-- 
~Randy

Re: [Tech-board-discuss] [MAINTAINERS SUMMIT] Maintainers Support Group

[Shuah]

On 9/19/23 16:07, Randy Dunlap wrote:
> 
> 
> On 9/19/23 15:01, Theodore Ts'o wrote:
>> On Tue, Sep 19, 2023 at 04:39:11PM -0400, Theodore Ts'o wrote:
>>> On Tue, Sep 19, 2023 at 10:52:40AM -0600, Shuah wrote:
>>>> As a member of the CoC, I respectfully disagree with the statement "but all the
>>>> focus has mainly been around telling maintainers how to behave." This impression
>>>> might have been the result of one unfortunate incident that took place last year.
>>>> is only part of what CoC has been doing.
>>>>
>>>> A majority of reports are related to incorrect understanding of how the community
>>>> works and discusses technical issues. Most of them get resolved without involving
>>>> the community. This is behind the scenes silent work CoC does.
>>>>
>>>> It is unfortunate that CoC is being viewed as a body that is focused on telling
>>>> maintainers how to behave. I would encourage to not view CoC work based on one
>>>> or two cases that were outliers. CoC worked very hard to resolve them fairly and
>>>> that benefited the community as a whole.
>>>
>>> Shuah, I don't think this is the fault of the CoC.  Much of it is in
>>> how people interpret the CoC, or think it should be adapted.
>>
>> I just realized that this statement was a bit ambiguous; in the first
>> CoC, I meant the "Code of Conduct Committee".  In the second CoC in
>> this sentence, I made the "Code of Conduct".
>>
>>  From the context of what you wrote, I *think* you were consistently
>> referring to the Code of Conduct Committee, but when I see CoC I tend
>> think the actual "Code of Conduct" and not the committee which
>> enforces the CoC.
>>
>> Apologies for any confusion,
> 
> Thanks for explaining. I was confused by Shuah's comments (but I
> came to the same conclusion that you did).
> 

Thanks for explaining. Either way CoC by itself is merely a document
and it falls on the CoC committee to field the reports. I am glad we
are having this discussion to clarify CoC and how CoC committee acts
on the reports.

With all of the confusion surrounding CoC and how it gets interpreted,
it is a good idea to revisit and adapt to make it clear the what our
CoC (documented) means and how it guides the CoC committee.

thanks,
-- Shuah

Re: [Tech-board-discuss] [MAINTAINERS SUMMIT] Maintainers Support Group

[Shuah]

On 9/19/23 14:39, Theodore Ts'o wrote:
> On Tue, Sep 19, 2023 at 10:52:40AM -0600, Shuah wrote:
>> As a member of the CoC, I respectfully disagree with the statement "but all the
>> focus has mainly been around telling maintainers how to behave." This impression
>> might have been the result of one unfortunate incident that took place last year.
>> is only part of what CoC has been doing.
>>
>> A majority of reports are related to incorrect understanding of how the community
>> works and discusses technical issues. Most of them get resolved without involving
>> the community. This is behind the scenes silent work CoC does.
>>
>> It is unfortunate that CoC is being viewed as a body that is focused on telling
>> maintainers how to behave. I would encourage to not view CoC work based on one
>> or two cases that were outliers. CoC worked very hard to resolve them fairly and
>> that benefited the community as a whole.
> 
> Shuah, I don't think this is the fault of the CoC.  Much of it is in
> how people interpret the CoC, or think it should be adapted.  For
> example, just this past week, on the maintainer's summit, this
> statement:
> 
I agree with this statement that people have differing opinions on
the CoC role. There are people that don't think CoC is doing enough
and other side thinks it is focused on telling maintainers how to behave.
Neither is accurate.

People that think Coc isn't doing enough don't fully understand the
technical discussion dynamic and what constitutes a CoC violation,
and more importantly the role of a maintainer in making decisions
on accepting and rejecting patches.

The other side that thinks CoC is focused on "telling maintainers how
to behave" doesn't have visibility into the majority of reports CoC
determines that they fall into the category of normal technical
discussion and takes care of them behind the scenes.
  

>> Waah, waah, waah. The buffer cache is *trivial*. If you don't like the
>> buffer cache, don't use it. It's that simple.[1]
> 
> ... resulted in Linus being accused as a CoC violation.
> 
> I'm not sure that it qualifies as a CoC violation, but Dave Chinner
> certainly thought so, and publically accused Linus of that[2].
> 

> Personally, I'm not convinced that people calling people out for real
> or imagined CoC violations is always going to be productive,
> especially when it wasn't an explicit personal attack.  It's these
> sorts of edge cases is what causes some people to fear and badmouth
> CoC's.  Which is, I think, unfortunate.

Yes. I agree that going CoC over disagreements isn't productive, neither
is looking the other way when real violation occur.
  
The question we have to answer as a community is are we better off with CoC
in place or not. I would think we are better off.

thanks,
-- Shuah

Re: [Tech-board-discuss] [MAINTAINERS SUMMIT] Maintainers Support Group

[Shuah]

On 9/19/23 16:32, Shuah wrote:
> On 9/19/23 14:39, Theodore Ts'o wrote:
>> On Tue, Sep 19, 2023 at 10:52:40AM -0600, Shuah wrote:
>>> As a member of the CoC, I respectfully disagree with the statement "but all the
>>> focus has mainly been around telling maintainers how to behave." This impression
>>> might have been the result of one unfortunate incident that took place last year.
>>> is only part of what CoC has been doing.
>>>
>>> A majority of reports are related to incorrect understanding of how the community
>>> works and discusses technical issues. Most of them get resolved without involving
>>> the community. This is behind the scenes silent work CoC does.
>>>
>>> It is unfortunate that CoC is being viewed as a body that is focused on telling
>>> maintainers how to behave. I would encourage to not view CoC work based on one
>>> or two cases that were outliers. CoC worked very hard to resolve them fairly and
>>> that benefited the community as a whole.
>>
>> Shuah, I don't think this is the fault of the CoC.  Much of it is in
>> how people interpret the CoC, or think it should be adapted.  For
>> example, just this past week, on the maintainer's summit, this
>> statement:
>>
> I agree with this statement that people have differing opinions on
> the CoC role. There are people that don't think CoC is doing enough
> and other side thinks it is focused on telling maintainers how to behave.
> Neither is accurate.
> 
> People that think Coc isn't doing enough don't fully understand the
> technical discussion dynamic and what constitutes a CoC violation,
> and more importantly the role of a maintainer in making decisions
> on accepting and rejecting patches.
> 
> The other side that thinks CoC is focused on "telling maintainers how
> to behave" doesn't have visibility into the majority of reports CoC
> determines that they fall into the category of normal technical
> discussion and takes care of them behind the scenes.
> 
> 
>>> Waah, waah, waah. The buffer cache is *trivial*. If you don't like the
>>> buffer cache, don't use it. It's that simple.[1]
>>
>> ... resulted in Linus being accused as a CoC violation.
>>
>> I'm not sure that it qualifies as a CoC violation, but Dave Chinner
>> certainly thought so, and publically accused Linus of that[2].
>>
> 
>> Personally, I'm not convinced that people calling people out for real
>> or imagined CoC violations is always going to be productive,
>> especially when it wasn't an explicit personal attack.  It's these
>> sorts of edge cases is what causes some people to fear and badmouth
>> CoC's.  Which is, I think, unfortunate.
> 
> Yes. I agree that going CoC over disagreements isn't productive, neither
> is looking the other way when real violation occur.
> 

Sorry this didn't read right. I agree that calling out CoC violation over
disagreements isn't productive.

> The question we have to answer as a community is are we better off with CoC
> in place or not. I would think we are better off.
> 

Clarifying the confusion over adapting CoC and CoC committee, I mean
adapting CoC here.

I does appear we are going away from the main discussion of maintainer
support and I do think the proposal James pointed to is where we could
start and evolve that discussion to the actions such as support group,
instead of starting with a solution without looking at the bigger picture.

https://lore.kernel.org/ksummit/ab9cfd857e32635f626a906410ad95877a22f0db.camel@HansenPartnership.com/

thanks,
-- Shuah

Re: [MAINTAINERS SUMMIT] Maintainers Support Group

[Bart Van Assche]

On 9/19/23 09:10, Steven Rostedt wrote:
> Thoughts?

Maybe maintainers who are stressed out will prefer a video call or IRC
session instead of sending an email that gets archived who-knows-where?

Thanks,

Bart.

Re: [MAINTAINERS SUMMIT] Maintainers Support Group

[Steven Rostedt]

On Tue, 19 Sep 2023 10:03:48 -0700
Bart Van Assche <bvanassche@acm.org> wrote:

> On 9/19/23 09:10, Steven Rostedt wrote:
> > Thoughts?  
> 
> Maybe maintainers who are stressed out will prefer a video call or IRC
> session instead of sending an email that gets archived who-knows-where?

As I replied to Shuah. There would be no mailing list. And the names of the
supporting volunteers will be listed. Sure, we can include irc contacts of
how to reach those maintainers if they choose.

-- Steve

Re: [MAINTAINERS SUMMIT] Maintainers Support Group

[Shuah]

On 9/19/23 11:21, Steven Rostedt wrote:
> On Tue, 19 Sep 2023 10:03:48 -0700
> Bart Van Assche <bvanassche@acm.org> wrote:
> 
>> On 9/19/23 09:10, Steven Rostedt wrote:
>>> Thoughts?
>>
>> Maybe maintainers who are stressed out will prefer a video call or IRC
>> session instead of sending an email that gets archived who-knows-where?
> 
> As I replied to Shuah. There would be no mailing list. And the names of the
> supporting volunteers will be listed. Sure, we can include irc contacts of
> how to reach those maintainers if they choose.
> 

Steve,

As I replied to Ted and Randy, I think the proposal James pointed to is
where we could start and evolve that discussion to the actions such as
support group, instead of starting with a solution without looking at
the bigger picture.

https://lore.kernel.org/ksummit/ab9cfd857e32635f626a906410ad95877a22f0db.camel@HansenPartnership.com/

thanks,
-- Shuah

Re: [MAINTAINERS SUMMIT] Maintainers Support Group

[Steven Rostedt]

On Tue, 19 Sep 2023 16:55:29 -0600
Shuah <shuah@kernel.org> wrote:

> As I replied to Ted and Randy, I think the proposal James pointed to is
> where we could start and evolve that discussion to the actions such as
> support group, instead of starting with a solution without looking at
> the bigger picture.
> 
> https://lore.kernel.org/ksummit/ab9cfd857e32635f626a906410ad95877a22f0db.camel@HansenPartnership.com/

I saw this when James first posted it. I may have been the lone figure to
do so as I had to point it out when the topic came up a second time ;-)

  https://lore.kernel.org/all/20230817104622.511c61b4@gandalf.local.home/

I'm all for having this discussion under James topic, but this idea of a
Support Group is something I've been discussing with other maintainers for
some time. I believe I even mentioned it to you while on the bus in Dublin.

One of the things the TAB is working on is to come up with a "Communication
Style" document that will be focused on how submitters should speak to
maintainers and how maintainers should speak to submitters. The idea is to
help people understand the POV that others are coming from. But that's a
discussion for another day.

Anyway, with the majority of the [MAINTAINERS SUMMIT] submissions related
to this, I think it should definitely be discussed at the maintainers
summit.

-- Steve

Re: [MAINTAINERS SUMMIT] Maintainers Support Group

[Linus Walleij]

On Wed, Sep 20, 2023 at 1:21 AM Steven Rostedt <rostedt@goodmis.org> wrote:

> I'm all for having this discussion under James topic, but this idea of a
> Support Group is something I've been discussing with other maintainers for
> some time.

It is a good idea and I endorse it too.
It sounds like an emotionally demanding job.

Yours,
Linus Walleij

Re: [MAINTAINERS SUMMIT] Maintainers Support Group

[Jonathan Cameron]

On 20 September 2023 08:06:21 BST, Linus Walleij <linus.walleij@linaro.org> wrote:
>On Wed, Sep 20, 2023 at 1:21 AM Steven Rostedt <rostedt@goodmis.org> wrote:
>
>> I'm all for having this discussion under James topic, but this idea of a
>> Support Group is something I've been discussing with other maintainers for
>> some time.
>
>It is a good idea and I endorse it too.
>It sounds like an emotionally demanding job.

Likewise for both comments.  Definitely worth trying something along these lines.

Jonathan
>
>Yours,
>Linus Walleij
>

Re: [MAINTAINERS SUMMIT] Maintainers Support Group

[Shuah]

On 9/19/23 17:21, Steven Rostedt wrote:
> On Tue, 19 Sep 2023 16:55:29 -0600
> Shuah <shuah@kernel.org> wrote:
> 
>> As I replied to Ted and Randy, I think the proposal James pointed to is
>> where we could start and evolve that discussion to the actions such as
>> support group, instead of starting with a solution without looking at
>> the bigger picture.
>>
>> https://lore.kernel.org/ksummit/ab9cfd857e32635f626a906410ad95877a22f0db.camel@HansenPartnership.com/
> 
> I saw this when James first posted it. I may have been the lone figure to
> do so as I had to point it out when the topic came up a second time ;-)
> 
>    https://lore.kernel.org/all/20230817104622.511c61b4@gandalf.local.home/
> 
> I'm all for having this discussion under James topic, but this idea of a
> Support Group is something I've been discussing with other maintainers for
> some time. I believe I even mentioned it to you while on the bus in Dublin.
> 
Thank you. Yes. We talked about this last year at Dublin. Work of being an
Open source developer and especially a maintainer demands emotional labor.
This is definitely a risk factor for burnout.

I happened to com across an article today about burnout risk factors and some
of those are faced by maintainers and developers. If you are interested, I can
send the link.

> One of the things the TAB is working on is to come up with a "Communication
> Style" document that will be focused on how submitters should speak to
> maintainers and how maintainers should speak to submitters. The idea is to
> help people understand the POV that others are coming from. But that's a
> discussion for another day.
> 

Formalizing the communication is a good idea - I keep translating maintainer
and developer speak to new developers I mentor often enough to see the value
of such an effort. :)

> Anyway, with the majority of the [MAINTAINERS SUMMIT] submissions related
> to this, I think it should definitely be discussed at the maintainers
> summit.
> 

I would recommend discussion this prior to the Maintainer summit in an open
session to get input from developers and maintainers who aren't invited to
the maintainers summit myself included.

thanks,
-- Shuah

Re: [MAINTAINERS SUMMIT] Maintainers Support Group

[Laurent Pinchart]

On Wed, Sep 20, 2023 at 01:52:19PM -0600, Shuah wrote:
> On 9/19/23 17:21, Steven Rostedt wrote:
> > On Tue, 19 Sep 2023 16:55:29 -0600 Shuah wrote:
> > 
> >> As I replied to Ted and Randy, I think the proposal James pointed to is
> >> where we could start and evolve that discussion to the actions such as
> >> support group, instead of starting with a solution without looking at
> >> the bigger picture.
> >>
> >> https://lore.kernel.org/ksummit/ab9cfd857e32635f626a906410ad95877a22f0db.camel@HansenPartnership.com/
> > 
> > I saw this when James first posted it. I may have been the lone figure to
> > do so as I had to point it out when the topic came up a second time ;-)
> > 
> >    https://lore.kernel.org/all/20230817104622.511c61b4@gandalf.local.home/
> > 
> > I'm all for having this discussion under James topic, but this idea of a
> > Support Group is something I've been discussing with other maintainers for
> > some time. I believe I even mentioned it to you while on the bus in Dublin.
>
> Thank you. Yes. We talked about this last year at Dublin. Work of being an
> Open source developer and especially a maintainer demands emotional labor.
> This is definitely a risk factor for burnout.
> 
> I happened to com across an article today about burnout risk factors and some
> of those are faced by maintainers and developers. If you are interested, I can
> send the link.

Collecting interesting (and hopefully useful) resources is a fairly low
effort exercise, so I'll start:

"Negotiating the Nonnegotiable", by Daniel Shapiro
https://www.penguinrandomhouse.com/books/314284/negotiating-the-nonnegotiable-by-daniel-shapiro/

The hard part will be finding time to read all the useful resources.

> > One of the things the TAB is working on is to come up with a "Communication
> > Style" document that will be focused on how submitters should speak to
> > maintainers and how maintainers should speak to submitters. The idea is to
> > help people understand the POV that others are coming from. But that's a
> > discussion for another day.
> 
> Formalizing the communication is a good idea - I keep translating maintainer
> and developer speak to new developers I mentor often enough to see the value
> of such an effort. :)
> 
> > Anyway, with the majority of the [MAINTAINERS SUMMIT] submissions related
> > to this, I think it should definitely be discussed at the maintainers
> > summit.
> 
> I would recommend discussion this prior to the Maintainer summit in an open
> session to get input from developers and maintainers who aren't invited to
> the maintainers summit myself included.

I wonder if I'm stating the obvious, but trying to figure out ways to
handle psychological problems in a group made of software developers
seems like we will be fairly short on essential skills for this kind of
exercise. Given the size of the affected community, I think we could
find ways to get professional help.

-- 
Regards,

Laurent Pinchart

Re: [MAINTAINERS SUMMIT] Maintainers Support Group

[Shuah]

On 9/20/23 16:54, Laurent Pinchart wrote:
> On Wed, Sep 20, 2023 at 01:52:19PM -0600, Shuah wrote:
>> On 9/19/23 17:21, Steven Rostedt wrote:
>>> On Tue, 19 Sep 2023 16:55:29 -0600 Shuah wrote:
>>>
>>>> As I replied to Ted and Randy, I think the proposal James pointed to is
>>>> where we could start and evolve that discussion to the actions such as
>>>> support group, instead of starting with a solution without looking at
>>>> the bigger picture.
>>>>
>>>> https://lore.kernel.org/ksummit/ab9cfd857e32635f626a906410ad95877a22f0db.camel@HansenPartnership.com/
>>>
>>> I saw this when James first posted it. I may have been the lone figure to
>>> do so as I had to point it out when the topic came up a second time ;-)
>>>
>>>     https://lore.kernel.org/all/20230817104622.511c61b4@gandalf.local.home/
>>>
>>> I'm all for having this discussion under James topic, but this idea of a
>>> Support Group is something I've been discussing with other maintainers for
>>> some time. I believe I even mentioned it to you while on the bus in Dublin.
>>
>> Thank you. Yes. We talked about this last year at Dublin. Work of being an
>> Open source developer and especially a maintainer demands emotional labor.
>> This is definitely a risk factor for burnout.
>>
>> I happened to com across an article today about burnout risk factors and some
>> of those are faced by maintainers and developers. If you are interested, I can
>> send the link.
> 
> Collecting interesting (and hopefully useful) resources is a fairly low
> effort exercise, so I'll start:
> 
> "Negotiating the Nonnegotiable", by Daniel Shapiro
> https://www.penguinrandomhouse.com/books/314284/negotiating-the-nonnegotiable-by-daniel-shapiro/

Adding one I read this morning:
A Burnout Risk Checklist
Know your risk so you can prevent burnout.
https://www.psychologytoday.com/us/blog/lessons-from-a-burnt-out-psychologist/202309/a-burnout-risk-checklist
> 

>> I would recommend discussion this prior to the Maintainer summit in an open
>> session to get input from developers and maintainers who aren't invited to
>> the maintainers summit myself included.
> 
> I wonder if I'm stating the obvious, but trying to figure out ways to
> handle psychological problems in a group made of software developers
> seems like we will be fairly short on essential skills for this kind of
> exercise. Given the size of the affected community, I think we could
> find ways to get professional help.
> 

This discussion would be for coming up with a few solutions including
the one you suggested - "find ways to get professional help".

thanks,
-- Shuah

Re: [MAINTAINERS SUMMIT] Maintainers Support Group

[Linus Walleij]

On Thu, Sep 21, 2023 at 12:54 AM Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:

> I wonder if I'm stating the obvious, but trying to figure out ways to
> handle psychological problems in a group made of software developers
> seems like we will be fairly short on essential skills for this kind of
> exercise. Given the size of the affected community, I think we could
> find ways to get professional help.

Yes, can Linux Foundation help?

(Actually I have a bachelor degree in the behavioral sciences
but I guess it's not common.)

Yours,
Linus Walleij

Re: [MAINTAINERS SUMMIT] Maintainers Support Group

[Laurent Pinchart]

On Thu, Sep 21, 2023 at 02:40:07PM +0200, Linus Walleij wrote:
> On Thu, Sep 21, 2023 at 12:54 AM Laurent Pinchart wrote:
> 
> > I wonder if I'm stating the obvious, but trying to figure out ways to
> > handle psychological problems in a group made of software developers
> > seems like we will be fairly short on essential skills for this kind of
> > exercise. Given the size of the affected community, I think we could
> > find ways to get professional help.
> 
> Yes, can Linux Foundation help?
> 
> (Actually I have a bachelor degree in the behavioral sciences
> but I guess it's not common.)

It would be nice if it was more common :-) Without asking all
maintainers and developers to get a new bachelor, maybe targetted
trainings could also help ?

-- 
Regards,

Laurent Pinchart

Re: [MAINTAINERS SUMMIT] Maintainers Support Group

[Mark Brown]

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

On Tue, Sep 19, 2023 at 12:10:01PM -0400, Steven Rostedt wrote:

> The problem is that there's been no replacement for the maintainer to
> release their frustration.

...

> I brought up to the TAB a suggestion of starting basically a "Maintainer's
> support group". A place a maintainer, or even a submitter can go to when
> they are feeling frustrated. This is not a replacement for the Code of
> Conduct committee. This is more of a preventive measure. Ideally, the Code
> of Conduct committee members should be very bored where there are no
> submitted reports.  That would mean our community is running in a very
> smooth way. But that's currently not the case. There's been a few cases
> that have come up where if the maintainer had someone to vent to, it could
> have prevented the violation of the Code of Conduct.

...

> When a maintainer is getting frustrated with a submitter or another
> maintainer, or even a submitter is getting frustrated with a maintainer,
> they would have a place to find a list of people that can help. They would
> pick one of the people and send an email to them with a subject of
> "[MAINTAINER SUPPORT]" (or something like that). This would let the
> supporting maintainer know that this email is about support and should be
> confidential and follow the guidelines. The email will include who and why
> they are frustrated with the other person. Again, this is *not* a Code of
> Conduct issue. This is not to point blame, just frustration. Sometimes
> people just can not work with other people. The supporting maintainer can
> be an outside POV and can possibly help with explaining why the other
> person is acting the way they are. Or the supporting maintainer can find
> another maintainer to work with this person.

I think this is a really good idea, and I do think the bit about
submitters also getting frustrated with maintainers is important here -
there's a lot of "the process isn't working well" about this stuff which
will apply just as much to submitters.  It's going to be more obvious to
us as maintainers that there's issues for maintainers, and in general
submitters have more valves for releasing frustration (eg, for a lot of
them it's easy to just walk away, though that's not true for everyone).

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

Re: [MAINTAINERS SUMMIT] Maintainers Support Group

[Jason Gunthorpe]

On Wed, Sep 20, 2023 at 04:45:56PM +0100, Mark Brown wrote:
> On Tue, Sep 19, 2023 at 12:10:01PM -0400, Steven Rostedt wrote:
> 
> > The problem is that there's been no replacement for the maintainer to
> > release their frustration.
> 
> ...
> 
> > I brought up to the TAB a suggestion of starting basically a "Maintainer's
> > support group". A place a maintainer, or even a submitter can go to when
> > they are feeling frustrated. This is not a replacement for the Code of
> > Conduct committee. This is more of a preventive measure. Ideally, the Code
> > of Conduct committee members should be very bored where there are no
> > submitted reports.  That would mean our community is running in a very
> > smooth way. But that's currently not the case. There's been a few cases
> > that have come up where if the maintainer had someone to vent to, it could
> > have prevented the violation of the Code of Conduct.
> 
> ...
> 
> > When a maintainer is getting frustrated with a submitter or another
> > maintainer, or even a submitter is getting frustrated with a maintainer,
> > they would have a place to find a list of people that can help. They would
> > pick one of the people and send an email to them with a subject of
> > "[MAINTAINER SUPPORT]" (or something like that). This would let the
> > supporting maintainer know that this email is about support and should be
> > confidential and follow the guidelines. The email will include who and why
> > they are frustrated with the other person. Again, this is *not* a Code of
> > Conduct issue. This is not to point blame, just frustration. Sometimes
> > people just can not work with other people. The supporting maintainer can
> > be an outside POV and can possibly help with explaining why the other
> > person is acting the way they are. Or the supporting maintainer can find
> > another maintainer to work with this person.
> 
> I think this is a really good idea, and I do think the bit about
> submitters also getting frustrated with maintainers is important here -
> there's a lot of "the process isn't working well" about this stuff which
> will apply just as much to submitters.  It's going to be more obvious to
> us as maintainers that there's issues for maintainers, and in general
> submitters have more valves for releasing frustration (eg, for a lot of
> them it's easy to just walk away, though that's not true for everyone).

Yes, I think this is very true. I've seen a number of cases now where
experienced valuable people in submitter roles just walk away. No
explosion, no LWN article, but our community definitively lost
something of value. [*]

It would be nice to stop talking about this in terms of sides and
focus on the submitter/maintainer relationship as a whole. The issues
I'm aware of are not CoC violations, but nevertheless they have upset
people. There are a whole host of behaviors sumitters/maintainers can
choose to do that range hurtful to non-productive.

I think the fact is there are not really any good release valves. We
can chat amung little groups how situation XYZ is troubled but, unless
it is really critical, the default response I see is to not rock the
boat. Especially if you are on the submitter side - raising a
complaint risks retribution.

A safe space to resolve issues without fear of retribution would be
nice, but is probably unrealistic.

I don't want to be a downer but I've chatted with a enough people now
to say that things seem to be getting worse - it *feels* worse to
participate these days. eg I just finished a nice big series for
something outside the areas I maintain and I'm dreading the process of
merging it :\ Then I think: I wonder if people feel the same way about
my areas? No idea, nobody says.

Maybe I need [MAINTAINER SUPPORT] therapy already.

* - I think we lack quality submitters and that is a big contributor
to stress on the relationship as a whole. So I lament every time I see
a good person walk away.

Regards,
Jason

Re: [MAINTAINERS SUMMIT] Maintainers Support Group

[Linus Walleij]

On Thu, Oct 5, 2023 at 8:08 PM Jason Gunthorpe <jgg@nvidia.com> wrote:

> It would be nice to stop talking about this in terms of sides and
> focus on the submitter/maintainer relationship as a whole. The issues
> I'm aware of are not CoC violations, but nevertheless they have upset
> people. There are a whole host of behaviors sumitters/maintainers can
> choose to do that range hurtful to non-productive.
(...)
> I don't want to be a downer but I've chatted with a enough people now
> to say that things seem to be getting worse - it *feels* worse to
> participate these days. eg I just finished a nice big series for
> something outside the areas I maintain and I'm dreading the process of
> merging it :\ Then I think: I wonder if people feel the same way about
> my areas? No idea, nobody says.

What are these things?

I've had the same feeling and I can think of some that would give me
the same fear and feel like a newbie contributor once again. Mostly
I think it's good for me to feel like that, but that is maybe not universally
true.

One thing I clearly noticed are increased barriers to entry for
newcomers, for project size, "professionalism", etc leading to
endless patch reviews with increasingly nitty review comments,
leading to perfect-is-the-enemy-of-good situations with all the best
intentions from all sides.

Linus Walleij