[development] Very concerned over Drupal's core development
drupal-devel at webchick.net
Mon Apr 20 19:39:27 UTC 2009
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
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
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
Curious about others people might have as well.
More information about the development