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