On automation and ownership

I'm writing this here rather than getting into an email trail or pissing people off by telling them that I disagree via IRC.

What's the quickest way to annoy an open source community?

Impolite automation.

I was pretty happy when I annoyed enough people that I was granted QA karma. It's not just the technical karma, but the social karma to be a bit bossy and push out releases, fix bugs, scold maintainers.

I have slowly built up a hodge podge of continuous integration tools, scripts and other bits and pieces for the QA work I do in pear.

To date, I've been getting pretty positive feedback - the cruisecontrol instance, pumping out fixes to unit tests, pumping out releases for old packages, etc.

Sick of doing things manually, I scripted up a quick way to scrape a changelog, prepare a release, and hey presto: QA releases just got easier.

What's the problem with that? It turns out if you do screen scraping and sort the results in any particular way; you end up straying from "that package last released way back in 2005" into the newer stuff - some of it maintained.

PEAR also has a problem with its code ownership model - strong code ownership is the order of the day.
This is not just my opinion, but evidenced by the fact we have many packages which are just abandoned (I would guesstimate over 60%). We have maintainers apply on some, but if we don't get around to doing anything; those packages sit there and rot.

SVN karma generally only allows a maintainer to touch one package they specifically apply for.
The process we have (PEPr) is great for newcomers and sorting out the wheat from chaff, but not so great for encouraging members of the community to adopt more code.

So; mix all of that together, throw in a range of developers who work in a range of styles; and what do you get?

Maintainers who feel angry when features & bugfixes they have authored are released to users.

So; first thing's first: Sorry to those who feel angry. I can fix this by communicating better, and tweaking the scraping tools to be more precise; but in all honesty I think I will probably end up causing more upset at a later time by doing something similar.
Why would I do this again, am I insane? I would put it down to my code ownership views vs the status quo.

Secondly: How do we change the culture of PEAR from strong to something between weak and collective ownership of packages?

My answer to this in a work environment has been brutal automation of the trivial. There are no exceptions to rules: only the code is wrong or the automated measure is wrong. The result is the same - it gets fixed.
Make a commit? It works, keep it. It causes regression? Revert or fix.
It's not just the person who authored the change who has that responsibility; it's everyone.

(Ssh, work colleagues: just because I am the most fragrant violator of these rules!)

The net result turns out to be much more maintainable code, and you get to be lazier (let the machines do machine things, I'm here to make elegant code).

My current answer to this for PEAR is to give every darned active maintainer we trust QA karma; then make it so easy to do QA work there is very little excuse not to do it via tools.

That way at least it's not only me pissing everyone off!

Third: Is my zealous view of automation and collective code ownership completely the wrong model for PEAR? Does the community want less trampling over polite expectation by rogue zealots with too much power?

This one I don't have an answer for; and I think I ask the community for a vote (ie: get the annoyed with QA karma, revoke mine if so decided, and get everyone deciding a new direction for QA. Let's not forget the most important step of doing it either!)