On Tue, 2012-05-22 at 11:22 +0200, Merlijn van Deen wrote:
- easier creation of mmp's? I can imaging people don't move their
tools because it takes time to organise everything.
This. IMO, ideally it _should_ be as easy as running a script to create the project (the admins can always close disused or mistakenly created projects later) and copying the code (and any associated databases, cron jobs, etc.) over. No bureaucratic pre-approval, no code changes, no fuss.
As Marcin Cieslak notes, it doesn't work quite that smoothly yet. If nothing else, I think it really would help if we could at least make the execution environment as identical as possible for both MMPs and private tools.
Also, I think the name "multi-maintainer project" is discouraging on two counts: the "multi-maintainer" part makes it sound like you need to find a second maintainer to create one (which, as DaB notes, is not true), and the "project" part makes them sound like some complicated thing that's overkill for just one simple script (which is what most tools are).
Also, the whole practice of using such a complicated-sounding term (or, worse yet, an acronym) for MMPs makes them seem like a special case, as opposed to the default case of private tools (which we just call plain old tools). Of course, historically that _has_ been the case, but if we want to change that, we might as well start with the names.
I hereby propose that we retire the term "multi-maintainer project" or "MMP", and just start calling them "public tools" (with an appropriate qualifier where necessary, as in "public tool account"), as opposed to "private tools" that run on users' personal accounts. I do realize that these names are not perfectly descriptive, but IMO they're at least better than what we have right now.
(I did consider "stable" instead of "public", but I feel that that still presents a needless psychological barrier; it takes a lot of time and testing to be sure that a new tool really is stable, and we don't really want people to wait that long before making their tools public. In fact, it's precisely the unstable-but-useful tools that most benefit from the possibility of having multiple maintainers.)
Ps. I'm sort of talking from experience here: I have a bot running on my account that's been performing a useful service for Commons for a few years now, and whose continued operation in the future really should not depend on whether I remember to renew my account or not. I've just never got around to applying for an MMP for it, pretty much for the reasons that I've tried to analyze above.