From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: ksummit@lists.linux.dev
Subject: [MAINTAINER SUMMIT] coping with stress as a maintainer
Date: Thu, 10 Aug 2023 22:29:37 -0500 [thread overview]
Message-ID: <ab9cfd857e32635f626a906410ad95877a22f0db.camel@HansenPartnership.com> (raw)
Stress has been a standard part of maintainer functions for a long time
now. It comes from many source: internal deadline or porductivity
pressures, requirements to justify what you do from corporate bigwigs,
or simply the external flood of CVEs and syszbot reports that come in
so rapidly that you get two more before you've worked on the first one.
All of this contributes to maintainer burn out. Some maintainers have
been at this longer than others and have developed effective (to then)
strategies for coping with both internal and external stress. The
proposal isn't that we present one coherent solution but that the more
experienced maintainers relate coping and influence strategies that
have worked for them. How do you cope with the bungee SVP who decides
that open source isn't revenue generating enough to be considered in
the corporate strategy and wants to proceed with the? or how do you
avoid being up all night dealing with sysbot reports in a part of your
code you know is never exercised.
The proposal isn't that we have one true presentation on this, but that
we listen to stories from Maintainers who've come up against these
situations and evolved coping strategies (which may or may not be
correct and which might not work for you but at least it shows how they
try). Hopefully we can do a shared transfer of knowledge that doesn't
result in finding the one true strategy (which likely doesn't exist),
but which shows upcoming maintainers what we tried in the past, and
what did and didn't work and gives them more confidence to face the
challenges they will definitely run across as they build their external
statue.
The hardest part of facing most challenges like this is thinking you're
alone in doing it. We definitely have the experience base to refute
that thought, so we should be deploying it.
James
reply other threads:[~2023-08-11 3:29 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=ab9cfd857e32635f626a906410ad95877a22f0db.camel@HansenPartnership.com \
--to=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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).