I think catch hits a lot of good points about how our reward and trust system could be improved. I'm all for better profile pages, giving credit where credit is due, and providing better visibility into who is working on what. It might be useful to provide a "Reviewer rating" or "Reviewer score" -- something which could be an incentive for more people to review patches. Maybe this can be accomplished through some project module extensions? I'm not sure what the best approach would be, but it is worthy of a discussion. On Mon, Apr 20, 2009 at 10:30 PM, Nathaniel Catchpole <catch56@googlemail.com> wrote:
On Mon, Apr 20, 2009 at 8:38 PM, Sam Boyer
Hear hear for that. Nothing like the knowledge that if you commit a screw-up, it'll be noted by core devs within hours (if not minutes), which any self- respecting dev would find at least a smidge humiliating.
This is interesting, because I find it really comforting that we manage to pick up screw-ups both before and after commit, especially mine, maybe I'm not self-respecting enough. I don't really like the experience of coming across an issue which just got committed and have to mark it code needs work (sometimes with rollback patch ready if it's really, really bad) - but when people do it to me I don't get offended or overly humiliated - I'm just glad it never made it into a final release.
Actually I think a big part of the problem is this perception that core is hard and contrib is easy, personally I find the contrib workflow really hard.
A lot of people's first attempt to contribute to Drupal is often when they apply for a CVS account to contribute back a module. A lot of companies view that as their primary way to contribute back resources as well. What we end up with is 4,000 projects of very varying quality, and the projects which /everyone/ uses - Views, CCK etc. are crying out for people to help in their issue queues - not just writing and reviewing patches at a high level, but answering support requests, closing out duplicates, stuff like that.
One issue with this is the way our user profiles work in terms of highlighting contributions. I'd been contributing to core for more than a year before I got a CVS account, and that was when one of my core patches removed a slice of user.module on the condition it was maintained in contrib. So for a long time I never had any projects listed on my profile page, nor any entries in 'track code'. I've still only got commit access on a handful of projects, and don't actively maintain any of them - a situation I'm quite happy with. However if I posted a couple of crappy modules and committed loads of tiny patches to them, then to the casual observer that'd make the user profile look a lot beefier.
The only way that code contributions to core get measured is when Greg Knaddison parses commit logs and puts everything into a spreadsheet once or twice a year - our commit model also completely breaks sites like ohloh. Personally I'd really like better statistics on how many people are reviewing/submitting patches, getting them committed etc. since it'd at least help to spot clear trends when having discussions like these. And I think it'd be a bit of incentive to review and post patches more if there was some way of having that data recorded more firmly than just in commit messages themselves.
There was talk of having 'issue queue maintainers' without actual commit access for contrib projects as well - for people who answer lots of support requests and write documentation etc. Similar issue and it goes two ways. Identifying the people who you need to speak to about a particular area is hard unless you know who they are. Identifying what any particular individual is doing is hard unless you trawl through their tracker. There ought to be better ways to deal with this than filing patches to add people to maintainers.txt and having to write big long lists of names in commit messages (then what if you forgot someone or spell their name wrong).
Nat
-- Dries Buytaert :: http://buytaert.net/