Better and leaner reviews

Owned by M
Last updated: Oct 26, 2010Version comment
2 min read

Here's some thought on how we could move towards a more efficient review process.

Short term (pre-SBForge):

  • In the current version of Crucible it is possible to generate a review coverage report which show you what the code that hasn't been reviewed. This functionality enables us to set a very operational goal for the review process, that is, all code must be review XX days after commit. The review coverage report provides a easy way to leverage this simple goal.This means we can drop the current iteration review pages (the NetarchiveSuite projects desperately needs leaner a process), is a rather inefficient in ensuring review of all code. We should still try to scope the reviews bases on natural contexts, like feature and bugs.
  • Drop export of reviews: Crucible is very good at exposing review information, so there is no reason for creation static wiki pages replicating a specific view on a review. The Crucible export functionality is currently broke by the way 

Longer term (new world of SBForge):

  • (Re)Introduce issue context for reviews: Because JIRA integrates to Fisheye and Crucible, all issues (with defined repositories) will have two tab for viewing source code and reviews related to the issue (bugs, features, tasks, etc). New reviews can easily be created as part of the issue workflow by clicking the 'Create Crucible review '(when loggen in) in the source code view. The will cause a review to be created based on the committed source code for the issue. This review will automatically be listen in the review tab for the issue, and the Crucible review will have a  link back to the causing issue. This would mean that the whole review process would be a natural part of solving issues, and review information related to a project/version/issue would be readily available.