From: Steven Rostedt <rostedt@goodmis.org>
To: ksummit@lists.linux.dev, tech-board-discuss@lists.linux-foundation.org
Subject: [MAINTAINERS SUMMIT] Maintainers Support Group
Date: Tue, 19 Sep 2023 12:10:01 -0400 [thread overview]
Message-ID: <20230919121001.7bc610d4@gandalf.local.home> (raw)
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
next reply other threads:[~2023-09-19 16:09 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-19 16:10 Steven Rostedt [this message]
2023-09-19 16:52 ` [Tech-board-discuss] [MAINTAINERS SUMMIT] Maintainers Support Group Shuah
2023-09-19 17:19 ` Steven Rostedt
2023-09-19 17:29 ` Steven Rostedt
2023-09-19 17:54 ` James Bottomley
2023-09-19 21:26 ` Shuah
2023-09-19 20:39 ` Theodore Ts'o
2023-09-19 21:02 ` Steven Rostedt
2023-09-20 12:03 ` Christian Brauner
2023-09-19 22:01 ` Theodore Ts'o
2023-09-19 22:07 ` Randy Dunlap
2023-09-19 22:40 ` Shuah
2023-09-19 22:32 ` Shuah
2023-09-19 22:53 ` Shuah
2023-09-19 17:03 ` Bart Van Assche
2023-09-19 17:21 ` Steven Rostedt
2023-09-19 22:55 ` Shuah
2023-09-19 23:21 ` Steven Rostedt
2023-09-20 7:06 ` Linus Walleij
2023-09-21 7:15 ` Jonathan Cameron
2023-09-20 19:52 ` Shuah
2023-09-20 22:54 ` Laurent Pinchart
2023-09-21 0:45 ` Shuah
2023-09-21 12:40 ` Linus Walleij
2023-09-21 12:56 ` Laurent Pinchart
2023-09-20 15:45 ` Mark Brown
2023-10-05 18:08 ` Jason Gunthorpe
2023-10-06 20:47 ` Linus Walleij
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230919121001.7bc610d4@gandalf.local.home \
--to=rostedt@goodmis.org \
--cc=ksummit@lists.linux.dev \
--cc=tech-board-discuss@lists.linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).