A "Role" in Code Collaborator indicates the way in which a person participates in a review.
Roles
Code Collaborator supports four "roles" for review participants. The following roles are configured by default but administrators can configure completely different templates.
Author
Authors are the people responsible for the changes or documents under review. Usually they are responding to comments and questions made by reviewers and observers. In the "Fix Defects" phase the review will be "in their court" and on their Action Items list.
Reviewer
Reviewers are responsible for inspection, creating defects, etc.. With multiple reviewers, they will hopefully come to a consensus about each questionable item, but this is not required by the system. Reviewers typically create defects, but again this is not required.
Observer
Observers are involved and make comments but they are not "vital" to the review. If all other participants mark the review "complete," the review goes to the next phase regardless of observer state. Observer roles are usually used when you want to bring in someone who has special expertise on an issue.
Moderator (optional, not enabled by default)
The Moderator maintains the pace and tenor of the review. This is an optional role that doesn't exist in the default installation. This is used for more formal review workflows where one person leads and controls the review..
Different styles of review require different roles with different terminology and rules for what each rule is allowed to see and do in a review. Formal reviews might have four roles with strict rules, informal reviews might have just an author and reviewer, and a "self-check" review might just require an author with optional external reviewer.
Users interact with roles when they are creating a new review or editing the list of participants in a review.
The Role Configuration screen lets you set up any number of sets of roles. Each set is given a name and corresponds to some concept of a review.
Any number of role configurations can be specified. The names here are never shown to an end user; they are used only when selecting a role configuration as part of a review workflow.
In each role configuration you can have between 1 and 4 roles.
A variety of options are available when editing an existing role configuration or creating a new one:
Configuration Title |
The title of this configuration. This is strictly an administrative thing -- users of the system will never see this title. They see review workflows instead. |
The name of the role as it will appear in drop-down lists and on-line help text. The user will use this title as the primary mechanism for referring to the role. Use a blank title to indicate that this role should be completely disabled. The "Author" role must always be in the second column, although it can be renamed. It must always exist. The concept of the "author" is a special one in the system because the author always has special responsibilities. For example, when a review is in "Rework" phase the author's Action Items list will say "Rework defects found" whereas other participants will see "(No Action Required) Waiting for author to rework defects." |
|
A description of the role that will be prominently displayed to the user in all client user interfaces where roles are chosen, most prominently in the Participants section of the Create Review wizard. |
If "None", this role will be allowed to create defects, but will not be allowed to mark their own defects fixed, edit their own defects, or delete their own defects. If set to "Fix and Edit", this role will be able to create defects, mark their own defects fixed, and edit their own defects, but will not be allowed to delete their own defects. If set to "Fix, Edit, and Delete", this role will be able to create defects, mark their own defects fixed, edit their own defects, and delete their own defects Administrators can always change or delete any defect, regardless of this setting. In all but the most informal of reviews, authors are typically not allowed to mark defects fixed, but all other roles are allowed. This setting also applies to the ability to externalize a defect. |
|
If "None", this role will not be allowed to mark other users' defects fixed, edit other users' defects, or delete other users' defects. If set to "Fix and Edit", this role will be able to mark other users' defects fixed and edit other users' defects, but will not be allowed to delete other users' defects. If set to "Fix, Edit, and Delete", this role will be to mark other users' defects fixed, edit other users' defects, and delete other users' defects Administrators can always change or delete any defect, regardless of this setting. This setting also applies to the ability to externalize a defect. |
If true, users with this role will be presented with a button in the Moving On screen that allows the user to say to the group: "I am finished looking at this review." The user will be brought back into the review if another user makes a non-trivial comment. If false, the user is told "You must wait for other users." Typically everyone except the author has this feature enabled. The author is usually not in control of when the review finished so his "I'm finished" decision is not interesting. |
If true, the review does not change phases until this user says he is "finished" with the review in the Moving On screen. A phase-change might be inspection -> rework or inspection -> complete. For this to be true, "Marks reviews finished" must also be true. Typically this will be enabled for reviewers but disabled for observers where the user has been invited but we don't want the review held up. |
If yes, participants in this role will be required to mark comments read before finishing the review. Typically participants collaborate and discuss potential issues, so they are required to read each other's comments. However, some workflows have each participant work independently. Setting this configuration to "no" is usually applied to observer-type roles because they are frequently called in for something specific and don't need to "hang around" and see what other users have to say. This is also helpful in workflows where the reviewers independently submit comments to the author, who is then in charge of all changes without having to communicate back to reviewers. Note that this setting doesn't prevent anyone from coming back to the review and continuing to actively participate at any time. |
Should this role be allowed to modify the review title and custom fields? Typically there is no harm in allowing this, but you might want to lock down exactly who has the last word on the review custom fields and title. |
The minimum number of users with this role required in the review. Can be zero to indicate "This role completely optional." Most often used with reviewers or moderators to require at least one, or with a "very careful" review where multiple reviewers are required. |
|
The maximum number of users with this role required in the review. Use 99 to indicate "no maximum." Usually there is no reason to limit the number of users who can participate as a role in a review, except for highly formal reviews where a strict process is required. |