Re: [MAINTAINERS SUMMIT] Maintainer burnout

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

On Fri, Aug 18, 2023 at 06:26:29PM +0300, Laurent Pinchart wrote:
> On Fri, Aug 18, 2023 at 03:55:11PM +0200, Linus Walleij wrote:
> > Alexei, thanks for returning the conversation
> > to this very important topic.
> > 
> > On Fri, Aug 18, 2023 at 1:55 AM Alexei Starovoitov wrote:
> > 
> > > BPF has solid CI that helps a lot, but the maintainer burnout is acutely felt.
> > > The main reason for burnout is patch flood.
> > 
> > I agree this is an important cause.
> > Even worse is any kind of social conflict or bad mood in the community.
> > Science has studied stress, what we mostly run into is called "microstress".
> > https://en.wikipedia.org/wiki/Psychological_stress
> > 
> > > The maintainer's day looks like non-stop code review.
> > > The patch backlog just doesn't end.
> > 
> > I've been there too :(
> 
> I think most of us know the feeling. Personally, if my workload reaches
> 100% review for an extended period of time, without having any time for
> "fun" activities such as hacking, I'm pretty sure my review efficiency
> drops drastically. Maybe that's call burn out.
> 
> > > We're trying to encourage active developers to be code reviewers as well
> > > via positive/negative scores:
> > > https://lore.kernel.org/bpf/ZJx8sBW%2FQPOBswNF@google.com/
> > >
> > > It doesn't help much yet. All incoming kernel contributors assume
> > > that it's a maintainer's job to do code reviews.
> > > Developers just send patches and wait. It doesn't occur to them that
> > > reviewing other patches will help them land their own.
> > 
> > The DRI/DRM community has group maintainership that works a little
> > bit.
> > Essentially it boils down to ask people to review your stuff and you
> > will review and also merge their stuff in return.
> > Sometimes this works.
> > Especially if you are a circle of acquaintances working full
> > time on similar things, yay! So much support.
> > When you are a sporadic contributor it doesn't work as well.
> > Because you cannot always find some matching contribution to
> > review and you feel like begging.
> > So different solutions for different contributors may be needed.
> 
> I've also experienced mixed results from "trading reviews". It's
> certainly nice on paper, and it works sometimes, especially when asking
> contributors to review patches that are directly related to their
> business interest. I remember asking a contributor from a large company
> to help me with reviews, to free some of my time to review their
> patches. The contributor helped with reviewing third-party contributions
> to the driver they're actively working on. When I asked for help
> reviewing an entirely separate driver that their employer had no
> business interest in, however, I faced the "we're busy and don't have
> time" argument.
> 
> Maybe part of the solution here, to share the maintenance burden, is to
> expect contributors, especially the ones with large financial resources,
> to spent a certain percentage of their time reviewing code that is in
> their area of expertise but not in their area of business interest.

May I add an point that I had struggled in the past with (and it could
be very well this is not an issue in your subsystem in which case please
ignore it):

This idea assumes you trust them to have the same level of expertise
that you have.

That is say they do a review but miss the more esoteric semantics (say
hardware quirks that are documented but only for folks that *grok* the
hardware). You may know it, but they don't. You accept their patches and
months later it all blows up. You are unhappy, Linus is screaming about
it. Burn-out ++.

Perhaps the question should be: How to grow the community so that members
collectively have the same knowledge as you?

(And then you can take days off without feeling guily. Burn-out --).