Version 2 (modified by yoheeb, 5 years ago) (diff)

Enhancement ideas to CodeReviewPlugin

CodeReviewPlugin Concepts

Basic idea

  • Whenever a changeset is displayed, review information is available:
    • Reviewer
    • Review result description
    • Review result state: ACCEPTED or REJECTED
  • When the user has the permission CODE_REVIEW, this information is editable
    • A button named "Review" is saving the information and setting Reviewer to the current user
  • When the user lacks the permission CODE_REVIEW, this information is read-only
  • Reviews are also available from "View Tickets", if you add a report on the table CODEREVIEW.
    • To make this easier, besides the changeset revision, the changeset author is also redundantly store in this table.


( If approved, turn them to tickets and mark them here accordingly. )

  • Send an email to the author, whenever a changeset is REJECTED.
  • (Somehow) give reviewers an overview on changesets not yet reviews.
    • Currently I accomplish this via the timeline.

Yoheeb added:

  • Allow selective creation and display of code review comments that are specific to a file in the changeset, maybe next to (view diffs) on changeset summary, add "Code review - ACCEPTED/REJECTED/NONE/ADD REVIEW (with proper permissions of course)" as a link to the full review.
  • Allow wiki formatting in code reviews, including inter-trac links. (file: xyz/abc.C according to #123, this isn't the correct fix....see @line127-129 or something)
  • Configurable Workflow hooks on configurable Code review status (accept, reject...etc)?

Originally, I was going to create something similar to this, but you created a foundation that was better. Some things I was going for, which I hope you will consider: My design requirements were (optional items in italics):

1 - Allow a code review on a changeset
2 - save the code review results in a "permanent" location (I was going to use subversion repo properties)
3 - ability to view/print code reviews for:

A: individual changeset
B: Range of Changeset (including all)

4 - configurable pass/fail, etc states
5 - Access to add/view code reviews for entire changeset from changeset view

A: with wiki markup support and/or links to individual files under review

6 - Access to add/view code reviews for the "currently" viewed file from a changeset diff view
7 - code review permission to create/edit a review
8 - code review VIEW permission
9 - ability to see all (or individual) reviews when viewing a specific file/file+revision (suggest augmenting annotation feature)
10 - workflow triggers.

with that: My original idea was to save the reviews to the subversion changeset via properties with some simple formatting, and:

  • Also suggest a link to code review, if present, when a list if files is presented for large changesets (right next to "view diffs")
  • Modify the Annotation view template to parse the special properties, and pull out reviews specific to the current file/selected revision and
    • Show each review by author (allow multiple reviewers)
    • only show the review outcome (accepted, rejected, ...make this configurable?) as a link to the full review text as a wiki page/section of a page (maybe 1 page per changeset, 1 heading section per file?)
      • This allows a code review summary to just be a print of a wiki page, or, a print of all the sub page via, say, Wiki-Print
  • changeset string format could be something as simple as CR:REVNUM:File:Author:result as the property name, then the comments.
    • then on the annotation hover, parsed into: (in pseudo code, sorry, not sure how else to convey the idea)
      for all properties on changeset REVNUM:
       split on :
       if [0] ==CR and [1] ==$REVNUM:
         if [3] == CURRENT_FILE_SHOWN:
           insert "Code review by " +Author +" - " + CreateLinkToFullReview(CR:REVNUM:File:Author:result) into annotation pop-up
           remove it from the __displayed__ list of properties in annotation pop-up!
         allow normal processing

Now I realize this is tied to subversion, but could some of these ideas be incorporated into this DB based implementation. Also, I apologize for the verboseness of this, not sure what the best way to convey these concepts in compact form.