[development] Very concerned over Drupal's core development

[Angela Byron]

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