On 20-Apr-09, at 2:44 PM, Earl Miles wrote:
The reason I think more committers in targeted areas will work is because I think it will create more activity in those areas. The people who have the right to commit will have a more vested interest, and therefore you will get more of their time, effort and energy, plus any that they can draw to them. webchick commented earlier that one of the issues was providing an incentive to do reviews. And that's certainly a key issue, right there. There isn't much incentive to do reviews. There's the good of the project, but there is no pride of ownership in a review. The pride of ownership drives a lot of the initial development, and it drives the committers, but the reviewers?
I cannot remember a time in the 4 years I've been with this project that we haven't had a longstanding complaint about lack of good patch reviews. That is one of the first complaints I heard then, and it is one of the complaints I hear now. It has not changed, and asking people to do more reviews has already proven to be ineffective in combatting the issue.
Give your reviewers some ownership and you'll find a lot more people interested in reviewing.
Now this "how to get more reviewers" is a line of discussion I'm *very* interested in having since, regardless if we have subsystem committers or not, we need to resolve it. Here are some ideas around that: 1. A community-led mentorship/journeyman program for people who want to get involved in core development and don't know where to start. Basically, taking what we do at code sprints at Drupalcons twice a year that always lead to a big increase in new core contributors, and making an e-version of it, or something that could be done in person at camps and local meetups. 2. Developing some sort of system that can formalize a bit more "patch review swaps." The biggest incentive people currently have for reviewing a patch is that they want one in core and need to get other reviewers to look at it in order to do so. Making it easier to identify people who are willing to engage in this would help everyone out. 3. Providing tools on g.d.o, d.o, or elsewhere to make it easier for core subsystem maintainers to nurture their pocket of Drupal core. Not really sure what those would be yet. Perhaps one aspect could be liaising with the documentation team to help get their subsystem documentation cleaned up and some clear step 1, step 2, step 3 stuff. 4. Monthly contests for "review queue smashing," like other projects have "bug fix days" or similar. Winners get their name in lights on the d.o front page, or we could pony up for some cash incentives or similar. 5. Calling specific attention out to people who did thorough reviews in commit messages, either by including them in the list of contributors or something like "#xxxx by dev1, dev1, and reviewed by rev1: wah wah wah." 6. Add more people to MAINTAINERS.txt, and have it reflect the current committer "trust" model. If that document can be trusted, this makes it easier for reviewers to know who to talk to if they're interested in helping out with X system. We could also add subsystem maintainer names to the pages on http://drupal.org/community-initiatives/drupal-core perhaps. Curious about others people might have as well. -Angie