Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Wed, 21 Jun 2023 10:08:45 -0400
From:   Steven Rostedt <rostedt@goodmis.org>
To:     Finn Thain <fthain@linux-m68k.org>
Cc:     Theodore Ts'o <tytso@mit.edu>, linux-doc@vger.kernel.org,
        tech-board-discuss@lists.linux-foundation.org,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        linux-kernel@vger.kernel.org
Subject: Re: [Tech-board-discuss] [PATCH] Documentation: Linux Contribution
 Maturity Model and the wider community
Message-ID: <20230621100845.12588f48@gandalf.local.home>
In-Reply-To: <5490402b-8b9f-f52d-3896-41090e639e51@linux-m68k.org>
References: <20230620212502.GI286961@mit.edu>
        <5490402b-8b9f-f52d-3896-41090e639e51@linux-m68k.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Precedence: bulk

On Wed, 21 Jun 2023 11:51:19 +1000 (AEST)
Finn Thain <fthain@linux-m68k.org> wrote:

> - Maintainers should be "automating themselves out of a job" to whatever 
>   extent this is possible.  git is a good example of this, as is all of 
>   the tooling and workflow automation that grew out of that (e.g. gitlab).

I agree with the above statement.

> 
>   Because the Linux project is structured as a heirarchy, I think Linus 
>   and senior maintainers have a crucial role here. I don't think it's a 
>   co-incidence that git was the brainchild of the top maintainer.

True.

> 
>   Making the maintainer role more lucrative will provide a disincentive 
>   for more automation (with or without level 5 performance reviews) unless 
>   remuneration is tied to metrics that reflect maintainer effectiveness.

I'm not sure I totally understand your point above. I do not think that
making the maintainer role more lucrative provides a disincentive for more
automation. I'm constantly trying to add more automation to my process.
That's why I created ktest.pl, and constantly fiddling with patchwork to
get patch state automatically updated when things move from different
branches and git trees.

If your point is mainly the second part of that paragraph, which is to tie
in metrics to reflect maintainer effectiveness, then I think I agree with
you there. One metric is simply the time a patch is ignored by a
maintainer on a mailing list (where the maintainer is Cc'd and it is
obvious the patch belongs to their subsystem). I know I fail at that,
especially when my work is pushing me to focus on other things.

-- Steve