[Mailman-Developers] Request to process merge requests faster

[Stephen J. Turnbull]

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