ksummit.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: <dan.j.williams@intel.com>
To: James Bottomley <James.Bottomley@HansenPartnership.com>,
	<ksummit@lists.linux.dev>
Subject: Re: [MAINTAINER SUMMIT] resources for promoting healthy communities
Date: Mon, 22 Sep 2025 18:21:27 -0700	[thread overview]
Message-ID: <68d1f6173b299_1c79100e6@dwillia2-mobl4.notmuch> (raw)
In-Reply-To: <572009db624de21099e08f28604f4b8e6a472cf2.camel@HansenPartnership.com>

James Bottomley wrote:
> We talk a lot about community health and maintainer burn out but what
> struck me watching Hans' talk about this:
> 
> https://www.youtube.com/watch?v=O8Q8nIzEG6c
> 
> was that he relied on his employer to help him thorough his burnout
> problems.  While this reflects very creditably on Red Hat it struck me
> that quite a few of us probably have employers who would be less
> sympathetic to the idea that issues caused by being an open source
> maintainer should become their problem, especially if they were
> spilling over into internal job functions.  So I went looking for
> community resources that could be called on and found, rather
> distressingly given the amount that people talk about this, that there
> are none.  The best I can find was the session that happened in the
> Kernel Summit track:
> 
> https://lpc.events/event/17/contributions/1574/
> 
> But that was a one-off rather than a resource that anyone can call on
> at any time.

That was indeed a useful session, thanks to Shuah for organizing. I took
advantage of the offer for a follow-up session with Dr. Chance.

> So the topic I'd like to raise is what should we as a
> community actually be providing to help people through burn out and
> other community health issues?  We could just continue on as we are now
> which is pretty much nothing official but various community members
> will be happy to help (although good luck finding them listed
> anywhere).

Speaking for myself, it is not clear that a list makes the problem
better. If the number of community members willing to help is larger
than the number of folks willing to be explicitly listed, does that
injure scaling?

That said, if you are having a hard time, do reach out to peers, do not
wait for a list.

> We could make the self help support more official by providing a
> mailing list and possibly a wiki of volunteers specifically for the
> purpose.

Steven has talked about this, and I am supportive.

Additionally, one of the developments since that Plumbers session that I
believe helps with burnout and conflict is more offlist collaboration.
For example, subsystem specific conference calls, subsystem chat
channels, and if you are lucky enough to live near a critical mass of
developers, occasional gatherings for drinks and catching up, helps
relieve pressure and build community.

> Or, we could even decide that this is a serious enough problem to ask
> the LF if it would be amenable to providing us with some resources to
> help, thinks like organizing regular sessions like the plumbers one
> above and perhaps offering 1:1 video counseling and other resources.

I do think aspects of this topic are in scope for Shuah's Mentorship
Series, for more opportunities to share what works and what does not
work in navigating a Linux career.

https://events.linuxfoundation.org/lf-live-mentorship-series/

There are also training and development resources that many folks have
access to through $employer.

I do wonder what the uptake was on the sponsored sessions with Dr.
Chance to inform if this is a resource Linux community needs access to
on a regular basis. Is this problem is getting worse, better, or staying
the same over time?

  reply	other threads:[~2025-09-23  1:21 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-17 16:36 James Bottomley
2025-09-23  1:21 ` dan.j.williams [this message]
2025-09-23 17:02   ` Shuah Khan

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=68d1f6173b299_1c79100e6@dwillia2-mobl4.notmuch \
    --to=dan.j.williams@intel.com \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=ksummit@lists.linux.dev \
    /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