Change Details

https://office.wikimedia.org/wiki/Health_check_survey_results/FY2014-15_Q3 indicates a growing concern about code review. Our code review queues keep growing, I'd say still faster than our concerns, and this trend can only lead to some variation of *collapse*. http://korma.wmflabs.org/browser/gerrit_review_queue.html shows these monthly snapshots of open chagesets waiting for review (-1 and work in progress are not counted): * May 2013: 250 * May 2014: 1033 * May 2015: 1549 In order to stop this trend, revert it, and clean our queues we need a radical change. Any actions must be coordinated with the migration from Gerrit to Differential in T114311. == Problems == The current situation is the result of a combination of problems. Let's identify them, creating an own task when appropriate: * Prioritization / weak open source culture: more pressure to write new code than to review patches contributed. * Unmaintained repositories: lack of owners is a problem, lack of disclaimers for potential contributors to these repos too. (T102920) * Volunteers having a hard time getting their contributions reviewed, also in active repos (T78768) * Lack of sync between developer teams: team A stuck because team B doesn't review their patches. * Our [[ https://www.mediawiki.org/wiki/Gerrit/Code_review | code review practices ]] are not common across reviewers and don't focus on efficiency (T101686#1355049) * Our Continuous Integration tooling could be better at catching trivial errors or code style issues (T101686#1355049) * [[ https://phabricator.wikimedia.org/diffusion/MW/ | MediaWiki core ]], a case on its own: biggest project, unclear ownership, not all maintainers can review all areas. * Noise in metrics: dozens of basically unmaintained repositories containing 1-2 very old patches make difficult to dig into the really problematic repositories. See also T102112; T102920 * Poor quality of patches: require a lot of effort to push forward, making reviewers to pass instead of review with -1. * ... ? == Metrics == * [[ http://korma.wmflabs.org/browser/gerrit_review_queue.html | Gerrit review queue metrics ]] (includes a ranking of repositories), but cf. T110520 * [[ http://korma.wmflabs.org/browser/scr-backlog.html | 100 Oldest open changesets without code review + Open changesets with most activity ]] * [[ http://korma.wmflabs.org/browser/scr-contributors.html | Most active Gerrit users (# actions) and top reviewers (exercising +2/-2) ]]

https://office.wikimedia.org/wiki/Health_check_survey_results/FY2014-15_Q3 indicates a growing concern about code review. Our code review queues keep growing, I'd say still faster than our concerns, and this trend can only lead to some variation of *collapse*. http://korma.wmflabs.org/browser/gerrit_review_queue.html shows these monthly snapshots of open chagesets waiting for review (-1 and work in progress are not counted): * May 2013: 250 * May 2014: 1033 * May 2015: 1549 In order to stop this trend, revert it, and clean our queues we need a radical change. Any actions must be coordinated with the migration from Gerrit to Differential in T114311. == Problems == The current situation is the result of a combination of problems. Let's identify them, creating an own task when appropriate: * Prioritization / weak open source culture: more pressure to write new code than to review patches contributed. * Unmaintained repositories: lack of owners is a problem, lack of disclaimers for potential contributors to these repos too. (T102920) * Volunteers having a hard time getting their contributions reviewed, also in active repos (T78768) * Lack of sync between developer teams: team A stuck because team B doesn't review their patches. * Our [[ https://www.mediawiki.org/wiki/Gerrit/Code_review | code review practices ]] are not common across reviewers and don't focus on efficiency (T101686#1355049) * Our Continuous Integration tooling could be better at catching trivial errors or code style issues (T101686#1355049) * [[ https://phabricator.wikimedia.org/diffusion/MW/ | MediaWiki core ]], a case on its own: biggest project, unclear ownership, not all maintainers can review all areas. * Noise in metrics: dozens of basically unmaintained repositories containing 1-2 very old patches make difficult to dig into the really problematic repositories. See also T102112; T102920 * Poor quality of patches: require a lot of effort to push forward, making reviewers to pass instead of review with -1. * ... ? == Metrics == * [[ http://korma.wmflabs.org/browser/gerrit_review_queue.html | Gerrit review queue metrics ]] (includes a ranking of repositories), but cf. T110520 * [[ http://korma.wmflabs.org/browser/scr-backlog.html | 100 Oldest open changesets without code review + Open changesets with most activity ]] * [[ http://korma.wmflabs.org/browser/scr-contributors.html | Most active Gerrit users (# actions) and top reviewers (exercising +2/-2) ]] == Potential approaches and solutions == See preliminary results at https://www.mediawiki.org/wiki/User:AKlapper_%28WMF%29/Code_Review

https://office.wikimedia.org/wiki/Health_check_survey_results/FY2014-15_Q3 indicates a growing concern about code review. Our code review queues keep growing, I'd say still faster than our concerns, and this trend can only lead to some variation of *collapse*. http://korma.wmflabs.org/browser/gerrit_review_queue.html shows these monthly snapshots of open chagesets waiting for review (-1 and work in progress are not counted): * May 2013: 250 * May 2014: 1033 * May 2015: 1549 In order to stop this trend, revert it, and clean our queues we need a radical change. Any actions must be coordinated with the migration from Gerrit to Differential in T114311. == Problems == The current situation is the result of a combination of problems. Let's identify them, creating an own task when appropriate: * Prioritization / weak open source culture: more pressure to write new code than to review patches contributed. * Unmaintained repositories: lack of owners is a problem, lack of disclaimers for potential contributors to these repos too. (T102920) * Volunteers having a hard time getting their contributions reviewed, also in active repos (T78768) * Lack of sync between developer teams: team A stuck because team B doesn't review their patches. * Our [[ https://www.mediawiki.org/wiki/Gerrit/Code_review | code review practices ]] are not common across reviewers and don't focus on efficiency (T101686#1355049) * Our Continuous Integration tooling could be better at catching trivial errors or code style issues (T101686#1355049) * [[ https://phabricator.wikimedia.org/diffusion/MW/ | MediaWiki core ]], a case on its own: biggest project, unclear ownership, not all maintainers can review all areas. * Noise in metrics: dozens of basically unmaintained repositories containing 1-2 very old patches make difficult to dig into the really problematic repositories. See also T102112; T102920 * Poor quality of patches: require a lot of effort to push forward, making reviewers to pass instead of review with -1. * ... ? == Metrics == * [[ http://korma.wmflabs.org/browser/gerrit_review_queue.html | Gerrit review queue metrics ]] (includes a ranking of repositories), but cf. T110520 * [[ http://korma.wmflabs.org/browser/scr-backlog.html | 100 Oldest open changesets without code review + Open changesets with most activity ]] * [[ http://korma.wmflabs.org/browser/scr-contributors.html | Most active Gerrit users (# actions) and top reviewers (exercising +2/-2) ]] == Potential approaches and solutions == See preliminary results at https://www.mediawiki.org/wiki/User:AKlapper_%28WMF%29/Code_Review