TL;DR: ask specific newish people to review specific changesets; pair program; nominate maintainers.

I did a little poking-around in http://korma.wmflabs.org/ , especially http://korma.wmflabs.org/browser/gerrit_review_queue.html , and on Gerrit to check out our code review situation, although of course more people's spot analysis or systematic assessments would be welcome.

It seems we have somewhat more committers and commits than a year ago (yay!) but not more than, say, 10% more.

Some hypotheses that I was unable to prove or disprove:

* that there's been a freak spike in backlogged work * that HHVM or some other project is soaking up the review times of people who used to do a lot of general MediaWiki code review

But I will note that the group of people with +2 access in MediaWiki core https://gerrit.wikimedia.org/r/#/admin/groups/11,members has fewer people outside WMF/WMDE than it used to. (I remember when there were ~13 and now there are ~8.) And, although we have many praiseworthy exceptions, there's a tendency for WMF staff and contractors to -- legitimately -- concentrate on writing and reviewing the code they're paid to work on (I presume it's the same for WMDE), and thus to make less time for reviewing code outside of those projects.

On the interiority of becoming a reviewer:

Here is a bit of a digression on capacity-building. Back when I was volunteer development coordinator, I thought my two biggest jobs were: 1) creating processes that scale, and 2) inculcating empathy in others. Both of these come into play in increasing code review capacity. An open process like https://www.mediawiki.org/wiki/Gerrit/Project_ownership scales better than a cliquey "oh hey maybe you should have merge rights" does. But we also have to grow new contributors into habitual reviewers, which means we have to get inside the heads of developers who currently aren't in the habit of offering reviews. One useful approach is the pathway to inclusion http://infotrope.net/2014/08/12/the-pathway-to-inclusion/ :

1) Awareness: “I’ve heard of this thing.”

2) Understanding: "I understand what this is about."

3) Identification: “I can see myself doing this.” 4) Access: "I can physically, logistically, and financially do this."

5) Belonging: "I feel like I fit in here."

6) Ownership: "I care enough to take responsibility for this."

During my time at WMF I saw that many people needed help with all six of those steps in order to start reviewing code, to broaden the scope of what they reviewed, and to ask for maintainership rights. Informative email blasts and wiki pages could only do so much; to cross some chasms, people need personal invitation, one-on-one reassurance and encouragement, and private misconception-clearing.

Recommendations:

* If you review code, you can help by poking through Gerrit with imaginative searches https://gerrit.wikimedia.org/r/Documentation/user-search.html and adding reviewers to changesets, focusing on people who don't review as much as they write. And follow up with email to them pointing them to https://www.mediawiki.org/wiki/Gerrit/Code_review and reminding them that all reviews help, that this is totally something they could do.

* Pair programming, pairing a newer developer with a reviewer, will also help with the backlog (the person you pair with can review you pretty fast!), and with awareness, understanding, and identification. For more see my 15 September email https://lists.wikimedia.org/pipermail/wikitech-l/2014-September/078627.html .

* Nominate people to maintain repositories. Including yourself. https://www.mediawiki.org/wiki/Gerrit/Project_ownership

Hope this helps.

Sumana Harihareswara Senior Technical Writer Wikimedia Foundation