Code review management/status

Last update on: 2012-04-monthly

2011-03-31

After the 1.17 code review sprint, the number of unreviewed new revisions started to increase again (see the automatically generated chart). Mark Hershberger started to assign name tags to revisions, to help developers track reviews that are requested from them.

2011-04-30

Tim Starling, Sam Reed, Chad Horohoe and Roan Kattouw devoted part of their time to code review. Despite their efforts, the backlog of unreviewed new commits is still increasing. A new feature in the CodeReview tool since the deployment of MediaWiki 1.17 is the ability to "sign off" on commits. Developers are encouraged to test and sign off on commits, in order to help the team prioritize what is ready for review.

2011-06-02

Thanks to concerted efforts by code reviewers, the backlog of unreviewed commits is now decreasing.

Until a few weeks ago, the amount of unreviewed commits was increasing at the same rate as they were before the 1.17 code review sprint. The group of reviewers (Brion Vibber, Tim Starling, Chad Horohoe, Trevor Parscal, Roan Kattouw and Sam Reed) was expanded to include Timo Tijhof, Bryan Tong Minh, Alexandre Emsenhuber, Aryeh Gregor, Neil Kandalgaonkar and Andrew Garrett. Thanks to a conscious effort made by code reviewers, the trend was reversed, and the backlog of unreviewed commits slated for inclusion in the next 1.18 release is now decreasing.

2011-06-30

Many Wikimedia Foundation engineers have committed to spend 20% of their time helping out with code review and other community service-related activities. We're currently planning a training session to bring staff members up-to-speed.

2011-07-01

The backlog of unreviewed commits continued to decrease in June. A long but productive discussion between developers happened on the wikitech-l list about how to further improve the code review process. It led to a proposal of a "20% policy", according to which every eligible Wikimedia engineer would spend 20% of their time doing service work that directly benefits the rest of the community.

2011-07-24

Work continued to review commits (see chart); the re-branching of MediaWiki 1.18 aims to reduce the backlog faster. In July, Wikimedia Foundation engineering staff and contractors also attended a Code review workshop; the goal was to share experience and practices on the general review process, as well as security and performance. The accompanying documentation is now being organized.

2011-08-31

Code review efforts largely focused on MediaWiki 1.18 in August. Still, code review of trunk also remained under control (see chart), which is encouraging, since it's likely to lead to a shorter release cycle. Revisions are now tagged more systematically where specific expertise is needed, e.g. with "front-end", "database" or "i18n"; this also makes it easier to involve volunteers and to hold focused sign-off triages. Also, Wikimania's developers days included a code review training.

2011-09-30

Even though engineering and code review efforts were focused on MediaWiki 1.18 in September, the backlog of unreviewed commits in trunk still continued to decrease (see chart), which means we will be able to release MediaWiki 1.19 fairly rapidly, possibly as soon as December 2011. Work on MediaWiki 1.19 is scheduled to start as soon as MediaWiki 1.18 is officially released.

2011-10-31

The focus on 1.18, as well as events and conferences, have allowed the backlog of unreviewed commits to increase in October (see chart). There are currently about 350 unreviewed revisions in trunk/phase3/, which means the deployment of MediaWiki 1.19 might not happen until January 2012.

2011-11-30

Foundation engineers signed up in greater numbers for weekly slots to devote to the development community (including code review), and discussed how to speed the code review that precludes deploying MediaWiki 1.19. Rob Lanphier also set code review goals and made projections for 1.19.

2012-04-monthly

The Wikimedia engineering 20% policy is the current approach of the Wikimedia Foundation to improving the code review situation. With the move to Git, we no longer have a code review backlog in trunk, but we are still facing a backlog of patches to review (in Gerrit and Bugzilla), RFCs to comment on, and extensions to review.