Terri Oda writes:

I can't speak for anyone else, but I had some big life events this summer,

So have others, though I won't speak for them either.

...

I know all core devs are volunteers, and no one is maintaing the Mailman projects full-time, but it's a little frustrating to have your merge request open for a couple of months without any/much reaction to it...

That's the way things work, though. Sure, it is better in some projects for a while, but I don't know any project which maintained a backlog-free status for very long, even with paid developers (see below).

...

I try to keep my merge requests up to date and conflict-free,

I recommend not doing that unless there's committer interest or you're using the patch in a branch that tracks trunk anyway. I generally update once after a comment from a core person just in case they might follow up with concrete improvements or intention-to-commit, but not during periods of silence. Every once in a while I look up, update, and ping the dev list for attention. (This is also a common practice on Python-Dev, which is where I picked it up.)

...

but having to do this for a couple of months, while there is no clear reason why it's not merged yet, is a little demotivating.

There probably is no clear reason why it's not merged. Some non-core developers get their patches merged very quickly, because they propose patches that resonate with the core developers' interests and tastes. I've noticed that your interests are not so well-aligned with Terri and Florian (or with me, for that matter). There's nothing "wrong" with that, and in the long run skew directions are often the most profitable. But in the short run it does make it harder for the committers to make a decision to merge. They have to stretch, and do slow-think analysis, rather than just "get it" with fast-think pattern matching. Yes, this does mean there's discrimination in the sense that some people just get their patches merged faster than others do. But it's not arbitrary discrimination; it's based on cognitive costs that have to be paid by somebody.

The Bazaar project for one or two years ran a near-zero backlog by assigning a "patch pilot" whose responsibility was to help non- committers negotiate their baroque process (not to mention one of the most overelaborated APIs I've ever seen). But the patch pilots were paid developers (though they volunteered for the service, nobody considered it a "fun" assignment), and the project basically died when Canonical defunded it and reassigned the developers (not just the patch pilot program, all organized release activity). They did a good job, while the funding lasted, but in the end, they were not an exception to the "all projects have a backlog" rule.

For you, you have three main alternatives: (1) find a project where your way of thinking resonates with the committers -- not only will your patches be merged quickly, but you'll probably be invited into the core relatively quickly (2) work on aligning your thinking about the Mailman suite with the core developers (often called "drinking the Kool-Aid", but no question, it's work, not just a matter of beverage of choice) (3) be yourself, work on Mailman suite, and practice patience. None would be your first choice, but I don't see a better available alternative than choosing among those three (or some combination, depending on how much time you have to devote to multiple projects).

By the way, (1) is hard to do. Normally you want to contribute something where you've scratched an itch, but almost by definition the core doesn't have an itch there. So new contributors generally find themselves somewhat misaligned.

...

In Postorius there have been (and there still are) merge requests by new contributors that were probably abandoned, because quite some time has passed since their creation...

If you really care about that, as opposed to criticizing the core's practices, choose option (2). Then you not only will get your patches merged (or you'll decide to withdraw them as inappropriate in like of "Postorius-think"), but you'll likely be invited to become a committer, at which point you can help with the backlog.

Once again, let me emphasize that I don't want to put anybody down. I believe the "cognitive costs" are real, somebody has to pay them, and that's what I'm trying to argue here.

Regards,

Steve