Re: [MAINTAINERS SUMMIT] Time to call it quits for the maintainer summit?

["Lorenzo Stoakes (ARM)" <ljs@kernel.org>]

On Mon, Aug 10, 2026 at 10:56:18AM -0400, Theodore Tso wrote:
> On Mon, Aug 10, 2026 at 09:08:32AM -0500, Lorenzo Stoakes (ARM) wrote:
> > Your emails are really unclear.
>
> Ok, let me trry to clarify.  The current process that we've used for
> the last couple of years work like this.
>
> 1) I send a message to Linus asking for his set of ~10-12 people that
> he definitely would like to attend the Maintainers Summit.  He uses
> some scripts that show who he pulls from the most, but it's also
> modified by his perception of who might be a good people to attend and
> to make sure we have a balance between different subsystems and
> constituencies (e.g., architecture maintainers, people who work for
> distributions, etc.)  People identified by Linus, plus the program
> committee, are on the automatic invite list.  (Roughly half of the 5
> person program committee overlap with Linus's list.)
>
> 2) We send out the Call for Topics, which among other things states
> that (a) anyone who suggests a topic before a cutoff date will get
> added to the list of people whom the program committee will consider,
> and (b) anyone can nominate others, or self-nominate others.
>
> 3) In parallel, I run a set of scripts that look for people who are
> the most active in the past year, which includes people who review
> commits, test commits, author commits, etc.  My scripts are a bit more
> expansive than Linus's (which tend to be much more focused on
> identifying the core maintainers).
>
> 3) The program committee will take a look at the list composed of
> people from (2) and (3), and nominate other people to be considered.
> This falls under the "anyone can nominate others" clause in (2b)
> above, but I call this out because in practice the program committee
> tends to nominate more people than non-program committee member
> (including self-nominations).  It is at this point that if we think
> someone has something important to contribute for a particular topic,
> we might make sure that they are added to the list.
>
> 4) Each program committee then assigns a score from 5 (this person
> must be there) to 1 (while we're at it, why don't we invite Darl
> McBride).  We then average the scores, and for the sake of efficiency,
> we'll decide on cut line where everyone above a particular line will
> be added to the invite list.  But it's not just a mechnical exercise.
> We do try to consider balance, people who might be needed to have a
> robust set of discussions, people who haven't attended recently or at
> all, etc.  HOWEVER, given that we we are limited to inviting 30
> people, our ability to achieev balance or to make sure very single
> point of view on a topic is represented is quite limited.
>
> > (Though I question whether 'most active' is a good metric or one that's
> > actually being used).
>
> It's a starting point (among others) for creating a list of people for
> the program committee to consider.  It's not the most important
> criteria by any means.
>
> The bottom line is that it's complicated, and we are trying to balance
> many competing goals while keeping the size of the summit small enough
> that we can have good discussions.  Can it be changed?  Sure!  I'm
> sure that based on the discussion on the list, it will almost
> certainly come up at the summit.  I can't guarantee that changes will
> be made, since it is very much an over-constrained problem, but it
> will be discussed.
>
>
> It might be helpful if people frame the Maintainer Summit as being no
> different than what happens at the subsystem level, except that it is
> exclusively focused on process issues.  A wise maintainer will take
> the concerns of the subsystem contributors in mind, because you can't
> force volunteers to work on your subsystem --- and you don't want them
> to quit.  But at the same time, it's not a democracy, and a maintainer
> is empowered to make decisions for the good of the subsystem.  The
> mailing list discussion is an important part of what a wise maintainer
> will take into account, and that's why if you want to make sure an
> idea is considered, please make it on the ksummit list.

Thanks, that's all really useful information, and I appreciate you taking
the time to go into detail.

For me the real issue here I think is less how it works and more how it's
perceived to work.

Having insight into the selection criteria and the problems you're trying
to solve is really helpful.

I actually think it'd be really useful to document this somewhere in
Documentation/process/ personally.

But for me again I think there's room for improvement in the Call For
Topics which, at least partly, reads like any other conference CFP and
clearly - that isn't the case.

So I think the simple solution here is to reword the CF[P,T, whatever :P]

The bit I'd change is the topic proposal bit. Something like this:


-	Anybody proposing a topic before July 24th will be added to the list
-	of potential attendees selected by the program committee; other
-	potential nominees can be proposed (as a self-nomination or by others)
+	Potential nominees can be proposed (as a self-nomination or by others)
	by sending a note to the ksumimt list saying why that person's
	presence would help the discussion.

And maybe add something extra to really clarify things:

+	The Maintainers Summit is unlike any other conference in the
+	calendar and as such the primary selection criteria for attendance
+	is upstream engagement.
+
+	Therefore, while topic submissions drive what is discussed at the
+	conference and taken very seriously, they do not guarantee
+	attendance.

Keeping the rest the same.

>
> Cheers,
>
> 						- Ted

--
Cheers, Lorenzo