Misc:Review Stats

From MozillaWiki
Jump to: navigation, search

If one looks at the reviews requested for Bugzilla, there are a non-trivial number of old patches that have review requests on them. In order to help decide how best to deal with this, we'd like to get a better understanding of the various states that these bugs are in. There are two pieces to this:

  • coming up with a list of information about unreviewed patches that we'd like to know
  • data-mining bugzilla to come up with the answers to these questions

Please post your thoughts and suggestions regarding this list of questions to the discussion tab for this page by December 1st 2005. Also, feel free to make any obvious fixes or tweaks on this page itself. Sometime in early December, we'll ask for volunteers to do the actual data-mining.


  1. How many are there with what distributions of age / patch size / module?
  2. The review page shows the date that the patch was posted to bugzilla, not the date that review was requested. For how many patches do these dates significantly differ (eg by more than two weeks)?
  3. How many/what percentage of patches have r? set without an email target?
  4. How many/what percentage of patches have no apparent communication from the reviewer that the review will not be immediately forthcoming?
  5. Of patches that do have such communication, how many/what percentage is incorrect (ie the reviewer said "I'll review next week", but that didn't happen)?
  6. What percentage have already gone through an iteration of the review process? Of those that have, how many / what percentage have already been reviewed by the same person on whom review is currently waiting?
  7. How many/what percentage have review requests set against people who are no longer active in the project? How many such inactive review requestees are there?
  8. How many/what percentage are large enough and old enough that they're likely to have bitrotted and no longer be applicable to the current trunk?
  9. How many/what percentage include complaints about the lack of review?

The last two questions require reading through the bugs manually. If so, I'd like to propose one more question:

  1. How many/what percentage are enhancements deemed not essential enough to warrant prompt action? -tsee

As regards this last question, the goal is not so much to get the specific patches into the tree to fix that specific bug as to stop turning people away from the project, which is something we're really good at. In my opinion, patches from new contributors who might stick around are higher priority than most other things... --bz