# Tasks

## Working with the Navigator View

The R4E Navigator View is the main component of R4E. It shows all the information that is available to the user and it is also the place where most user commands are available. The Review Navigator information is organized in a hierarchical tree structure and is presented in a Navigator panel. Elements shown in red are read-only. Commands are available in the view toolbar and in context menus that appear when right-clicking the navigator elements.

When a Review is open, the Navigator view can focus on and display the Review elements in an alternate display that show them in a more compact and table-like way. Both representations can be toggled on by using the Change Display toolbar command.

### Disabling and Restoring Elements

When Review Navigator elements are not relevant anymore (e.g. completed reviews), they can be removed from the view by using the ''Disable ''command from the element's context menu.

Disabled elements data is kept, but they will not appear in the navigator view anymore. Take note that currently it is not possible to completely remove references to an element once it is created.

To see disabled elements in the Navigator view, go to the R4E Preferences Filter Tab and select the Show Disabled Elements checkbox and apply the preferences. The disabled elements will show in the Navigator grayed out and with the little disabled decorator icon

Ideally, disabled elements should never be shown, but there could be a need to restore mistakenly disabled elements. To do so, first go to the Eclipse preferences R4E page, on the Filters tab and enable the Show Disabled Elements filter, then return to the Navigator view and select the ''Restore ''command from the disabled element context menu

### Sorting Review Navigator Elements

The Navigator elements can currently be sorted alphabetically or by review type, by selecting the appropriate sorter in the Review Navigator Toolbar menu.

### Filtering Review Navigator Elements

The Navigator view provides different filters that can be used to limit the visibility of elements within the navigator tree. Filters are available in the Review Navigator Toolbar menu.

The filters available are:

- Show Reviews Only: Show only Review Groups and Review elements
- Show My Reviews: Show only Review Groups and Review elements in which the current user is a Participant
- Show Reviews for Participant...: Opens a dialog box where a User ID can be specified. The Navigator will then show only Reviews in which this User is a Participant
- Show My Assigned Elements: Show review elements that are unassigned or assigned to the current User
- Show Assigned Elements for Participant...: Opens a dialog box where a User ID can be specified. The Navigator will then show only Review elements that are unassigned or assigned to the specified participant.
- Show Unassigned Elements: Show only review elements that are not currently assigned to any participant.
- Show Anomalies Only: Only show the Anomalies for the currently open Review and their parent containers
- Show My Anomalies: Only show the Anomalies for the currently open Review that the current User created and their parent containers
- Hide Completed Reviews: Hide all the reviews that are in phase COMPLETED
- Hide Reviewed Elements: This filter will hide all elements that have been marked as Review by the current User
- Hide Rule Sets: This filter will hide all Rule Sets elements and their children
- Hide Deltas: This filter will hide all Selection and Delta elements.
- Remove All Filters: Remove all currently applied filters and restores the full display of all enabled elements in the Navigator tree.

### Setting Elements Reviewed State

To help Users to keep track of the content that was reviewed it is possible to mark relevant Review Navigator elements as reviewed using the context menu Mark/Unmark as User Reviewed command. This will put a little done decorator icon. The marking can be removed by using the same command to toggle the state.

### Other Review Navigator Commands

These other commands are also available from the Navigator view toolbar and/or drop-down menu:

- Progress Element : Change the state of a stateful element (e.g. Review, Anomaly) to its next logical state. This is a shortcut and can also be done through the R4E Properties view for the element.
- Regress Element : Change the state of a stateful element (e.g. Review, Anomaly) to its previous logical state. This is a shortcut and can also be done through the R4E Properties view for the element. Take note that this is the only way to change the state of a COMPLETED Review.
- Go Into : This is a special filter that will take the selected element of the Navigator and put it at the root of the Navigator tree. This is useful to focus on a particular element and its children.
- Collapse Navigator tree : Collapse the current Navigator tree.
- Expand Navigator tree : Expand the current Navigator tree to the lowest level.
- Select and Open Next Element : Move the selection to the next (lower) element in the tree and opens it in an editor if possible (for File Contexts elements and children)
- Select and Open Previous Element : Move the selection to the previous (higher) element in the tree and opens it in an editor if possible (for File Contexts elements and children)
- Refresh Navigator Data : Fetches data from disk and rebuilds the Navigator tree. This will also show new data that has been added by other users.
- Show UI Legend : Shows a legend that displays and explains all R4E icons in a pop-up dialog.

Take note that not all filters and toolbar commands are available on all Review Navigator representations.

## Handling Review Groups and Reviews

### Creating a Review Group

When using R4E for the first time, the first thing to do is to create Review Groups that will hold the R4E review data. Typically, Review Groups include common settings that will be used for multiple reviews. For instance, one can create a Review Group for a design organization, for a given project or task etc.

A given Review Groups is created only once, typically by a "super-user" selected among people that are part of the group.

In order to create the Group, select the New Group icon in the Review Navigator Toolbar.

This opens the New Review Group dialog.

- Add the Review Group Name and (optionally) a brief description in the appropriate text fields.
- Select a shared folder location where team members have access and write permissions (i.e. Review Group shared folder)
- Under the Extra Parameters section, more information can optionally be entered to further characterize the Group: Default Project, Default Components and Default Entry Criteria values will be available for all Reviews created under this Review Group. Rule Sets defines the available Rule Sets for Review created under this Review Group (see Rule Sets below).

### Opening an Existing Review Group

When you create a new Review Group, its references are automatically included in your workspace. To add other Review Group references, open the R4E Preference Group Tab (Window->Preferences->R4E, then switch to tab "Groups")

- Add a new Review Group reference file by clicking the ''Add ''button and select the appropriate Group File. Take note that all Review Group filename end with "_group_root.xrer" suffix.
- The Review Group Name and Description are also shown in the Preferences Group tab.

### Creating a Review

The Review is the main element of R4E. It is used to group together file that are to be reviewed. There are three type of reviews, Basic, Informal and Formal review (See concepts section for an explanation of the different types of reviews).

To create a new Review, right-click on the parent Review Group under which you want to create the review and select the New Review Command from the R4E Context Menu.

This opens the New Review dialog.

- Add the Review Name and a brief description in the appropriate text fields.
- Under the Extra Parameters section, more information can optionally be entered to further characterize the Review:
  - Project and Components values can be selected from the values entered in the parent Review Group Default Projects and Default Components respectively
  - Entry Criteria is taken by default from the parent Review Group value
  - Objectives and Reference Materials can be set by the Review creator

### Opening and Closing of Review Groups and Reviews

In order to be able to see the Review Group child Reviews, a Review Group must be open. Closed Review Group are shown with hollow Group icons. You can open a closed Review Group by right-clicking on it and selecting the Open Element command, or simply by double-clicking on it. Closing unused Review Groups make navigation easier and free up memory and resources, so the Groups should be closed when they are unused.

Likewise, reviews can also be open and closed using the same mechanism. The only difference is that only one review (called the Active Review) can be open at any given time. Opening another Review closes the currently open one.

Take note that Review Groups and Reviews are automatically open after they are first created.

### Adding Participants to a Review

Participants are automatically added to the current Review as soon as they add review items to it or create an anomaly. It is also possible to add them manually.

To do so, right click on the parent review and select the New Participants Command from the R4E Context Menu.

This opens the Enter Participant details dialog.

The dialog is divided into 3 sections:

- Participants: This is where the participants are added. Use the field above to enter the IDs on the participants to add, separated by semicolons (;). If you defined Participants Lists in the preferences, the list name can be added here. Once the participants are entered, hit the return key, or use the Add button to add them to the list of participants. The participants will now appear in the participants list just below. If present, participants lists from Preferences are resolved and their contents is added to the list as well. If an LDAP database is setup up and configured in the preferences, R4E will also try to resolve the added users and automatically fetch the information from the database. Participants can be removed from the list by using the Erase button, and the list can be reset by using the Clear button. If an LDAP database is set up, it can also be accessed using the Find button (see below).
- The participant id entered within the R4E review data will be in lower case and R4E will enforce that (this to prevent duplicated users Ids for the same user).
- Basic Parameters: Once participants are added to the participants list. This section displays the basic information for the currently selected entry in the list. The email address can be edited, but not the Id or the participant details field (which in only filled if an LDAP database is set up and there is information about the user in it).
- Extra Parameters: Once participants are added to the participants list. This section displays the extra information for the currently selected entry in the list. Take note that this section is not present if the dialog was triggered from the User Preferences dialog, when creating participants lists. The user roles and optional focus area fields can be edited to further characterize what the participant will do as part of the review.
  - Roles can be assigned to the participant to restrict actions that can be taken. Take note that Roles are mandatory for Formal Review and Optional for Basic and Informal Review types
  - Focus Area value can be entered to specify a specific areas this Participant should focus on for this Review

If an LDAP database is configured and connected, the user information could be searched and filled-in automatically using the Find button, which will open the Find User Dialog

Any field can be entered in the Search Filters section and by clicking the Search button, an LDAP query will be sent to the database. If any matches are found, the results will be displayed in the Query Results section. Once the results are in, users can be added by double-clicking on them in the results table, or by selecting them and using the Add Users button. Pressing the OK button will result in the users being added to the New Participants dialog participant list.

### Creating a Review Item

In R4E, Review Items are a collection of one or more files, or parts of files, that are to be reviewed. There are two types of Review Items that exist: Commit Review Items and Resource Review Items.

#### Creating a Resource Review Item

This item type is created by manually selecting a workspace resource (i.e. File) or a portion of a resource (i.e. line ranges within a given file).

- To create Resource review items for a whole file, right-click a File on a Package Explorer, Navigator or Project View and select the Add Review Item command from the R4E context menu.

- To create Resource review items for a portion of a file, right click a line range selection in an editor or compare editor, or on an element of the outline view and select the Add Review Item command from the R4E context menu.

Once a Resource Review Item is created, it will be shown in the Review Navigator. If you expand the Review Item, you will see the child elements: The file on which the Review Item is applied and the line range selection that is part of the item.

#### Creating a Commit Review Item

This item type is created by selecting files that were committed to a Version Control System repository. Currently, the only Version Control System supported is Git.

To create a Commit Review Item, right click on a project attached to the Egit team provider (see Project Configuration) and select the Find Review Items command from the R4E Context menu.

This will show the Version Control System Commit Dialog (Here shown for the Git connector).

Use the Available Commits combo box to browse through all available commits and select one. For the selected commit, the commit information and affected files appear in the Commit Information and Committed Components sections respectively.

Once a Commit Review Item is created, it will be shown in the Review Navigator. If you expand the Review Item, you will see the child elements: The file on which the Review Item is applied and, optionally if the option is selected in the preferences, the line ranges for the Deltas (or differences between the committed file and its direct ancestor) that are part of the Item.

The icons for the files that are new and were added in the commit will be shown decorated with a little icon The icons for the files that were removed in the commit will be shown decorated with a little icon Files in the commit that are out of sync i.e. for which the version to review and the version present in the users workspace differ will be shown with the > sign prepended to the filename. Such files can be reviewed, but to use the full navigatability provided by the editors, it is strongly recommended that the files be in sync with the workspace whenever possible.

### Assigning Review Elements

It is possible to assign specific review elements (i.e. Review Items, File Contexts, Selections and Deltas) to specific participants. To do so, use the context command Assign to Participant for the desired elements.

To remove an assignment, use the context command Unassign Participant.

Take note that if a parent is assigned to given participants, then all its children will also be assigned. It is possible to override the parent's values and to change the children's assignments by operating on the child element directly.

Assignments can also be managed by using the Properties view for the selected element.

### Creating an Anomaly

R4E Anomalies are raised by reviewers to flag problems or add comments on specific parts of the contents as part of the review process.

Anomalies are added in a similar way Resource Review Items are, either from a selected Resource or from a portion/range of a resource, by selecting the Add Anomaly command from the R4E context menu.

Anomalies that are directly tied to a specific selection/delta range can also be created by selecting the Add Linked Anomaly command from the context menu of the affected selection/delta in the Review Navigation View

Anomalies can also be created at the review level. This is useful to flag problems that are not specifically tied to a given file or file part. To do this, use the Add Anomaly Command from the context menu of the Global Anomalies element in the Review Navigator view.

This opens the New Anomaly dialog.

- Add the Anomaly Title and Description in the appropriate text fields.
- Under the Extra Parameters section, you can also specify the class, rank, due date and participant that will be assigned to this anomaly. If Rule Sets are associated to the parent Review Group, the Rule Sets hierarchy will be shown and, optionally, a design rule can be toggled selected/de-selected and if selected its values will be applied to this anomaly. This will override the previous Anomaly values.

### Creating Comments on an existing Anomaly

It is possible to add comments to an existing anomaly. This could be useful in discussing the anomaly or for tracking purposes. To create a Comment, use the Add Comment command on the context menu on the selected Anomaly.

This opens the New Comment dialog, where the comment can be added.

### Importing Postponed Anomalies

Postponed Anomalies are Anomalies that were written in previous Informal/Formal Reviews, but were not handled then and were instead set to POSTPONED state. If the current Review include files on which these anomalies were written, whether it is the same or a different version of a file, it is possible to import them in the current review so that they can be addressed. Currently, only Postponed Anomalies that belong to Reviews under the same Review Group can be imported. Also, take note that Global Anomalies cannot be imported.

To import Postponed Anomalies, just select the current Review in the Navigator View and use the context menu:

R4E will scan all Reviews under the current Review Group and will copy all Anomalies in POSTPONED state that were written on files also included in the current Review. Once the command is done, the imported elements will appear on their own container element under the Review element in the Review Navigator tree.

From then on, Postponed anomalies behave like any other Anomaly and can be handled in the same way. When a Postponed Anomaly is modified, the changes will also be reflected in the original Anomaly (i.e. the one filed in the previous Review). Likewise, any changes that are done by other users on the original Anomaly can be seen in the current review by refreshing the imported Anomalies, by re-issuing the Import command. Take note that Postponed Anomalies that have their state changed from POSTPONED will be disabled. If they are set back to Postponed, they will be restored as Postponed elements.

## Handling Design Rules

### Creating a Rule Set

R4E support the use of Design Rules, to help reviewers enforce consistent design conventions and rules. A Rule Set is a container that includes multiple related Rules. Rule Sets are independently defined and can be shared among multiple Review Groups. Take note that the use of Design Rules is completely optional.

To create a new Rule Set, select the New Group icon in the Review Navigator Toolbar.

This opens the New Rule Set dialog.

- Add the Rule Set Version and Name in the appropriate text fields.
- Select a shared folder location where team members have access and write permissions (i.e. Rule Set shared folder)

### Importing an Existing Rule Set

When you create a new Rule Set, its references are automatically included in your workspace. To import other Rule Set references, open the R4E Preference Rule Sets Tab

- Add a new Rule Set reference file by clicking the ''Add ''button and select the appropriate Rule Set File. Take note that all Review Group filename end with "_rule_set.xrer" suffix.
- The Rule Set Version and Name are also shown in the Preferences Group tab.

### Creating a Rule Area

In order to create Design Rules, a Rule Area et a Rule Violation containers first need to be created.

Rule Areas represent a logical grouping of Rule Violations. They can, for instance refer to a specific language of element of the architecture. To create a Rule Area, right-click on the parent Rule Set and select the New Rule Area command.

This opens the New Rule Area dialog.

- Add the Rule Area Name in the appropriate text field.

### Creating a Rule Violation

Rule Areas contain Rule Violation. A Rule Violation is a logical grouping and Design Rules. They refer to a specific problem highlighted by the Rule e.g. Syntax Error, Bad Naming Convention etc.

To create a New Rule Violation, right-click on the parent Rule Area and select the New Rule Violation command.

This opens the New Rule Violation dialog.

- Add the Rule Violation Name in the appropriate text field.

### Creating a Rule

A Rule is the smallest unit in the Design Rule hierarchy. It refers to a specific code convention that is to be followed. The values of the rules are automatically set in anomalies that are created using the Rule as a reference. This can speed up and put some consistency in the review process.

To create a New Rule, right-click on the parent Rule Violation and select the New Rule command.

This opens the New Rule dialog.

- Add the Rule Violation Id, Title and Description in the appropriate text fields.
- Select the Rule Class and Rank in the appropriate combo boxes.

## Working with Editors

Once the Navigator view is open and Review Items are present. The items can be reviewed. Files are reviewed using various editor views to browse the content. Currently R4E is fully integrated with the Java JDT and C/C++ CDT editors and will take advantage of the special features these editors provide.

Files can be open in editors by double-clicking on them or their children in the Review Navigator. By default, files belonging to resource review items will be open in single-file editors, whereas files belonging to commit review items will be open in a compare editor. If the file is open using the child Selection/Delta/Anomaly element, then the cursor will automatically be positioned to the start of the line range that corresponds to the element. Files and also be open in the single-file editor by using the Open File in Editor command from the selected element context menu.

Once the file is open, anomalies can be added on the contents by selecting a range in the file and using the New Anomaly command in the R4E context menu.

## Working with R4E Properties

Updates to any review elements are performed via the R4E Properties View. The R4E Properties view uses the Generic Eclipse Properties View to display the R4E Properties and will show up when any Review Navigator element is selected to display the properties that are associated with this element.

The R4E Properties View is a tabbed properties view that consists of two tabs.

- The Detailed Tab show properties in a custom view where they can be edited.
- The Classic Tab displays all properties at a glance, using the default Eclipse properties layout. Take note all properties will be read-only in this tab.

Editable properties can be changed directly in the properties view. Take note that some properties can only be set when the element is created, while others could be editable only under specific circumstances (e.g. a specific element state or review phase for Formal Reviews).

By default, the Properties view is linked with the Review Navigator. This means that if an element of the Review Navigator is selected, the Properties view will be activated and will show the element's properties. It is possible, to remove this link by toggling on and off the Link with Properties command, which is located in the Review Navigator View drop-down menu.

When the Review Navigator view in unlinked, the Properties view will not be started automatically upon element selection. To activate the Properties view and see the element's properties in this case, right-click on the element and use the Show Properties contextual command.

A more detailed description of the properties for each element is shown below.

### Working with Review Groups Properties

Properties for the Review Group Element includes:

- Directly in the property view:
  - The Group name
  - The location of the root folder where the information is stored on disk
  - The Group description
  - The Default Entry Criteria that will be set when creating child reviews

- In the Projects and Components expandable section:
  - The Available Projects that can be used in child reviews
  - The Available Components that can be used in child reviews

- In the Rule Sets expandable section:
  - The Applied Rule Sets that specify Design Rules that can be used when creating anomalies in child reviews. If the ruleset is not loaded, a little disabled icon will appear besides its name in the table. Otherwise a little checkmark icon will be displayed.

### Working with Reviews Properties

Properties for the Review Element includes:

- Directly in the property view
  - The Review name.
  - The current Review phase. Basic and Informal reviews can have only 2 phases, Started ''and ''Completed. Formal reviews have multiple phases. Refer to the formal review section for more information.
  - A brief description of the review.

- In the Review Details expandable section
  - The review start (or creation) date.
  - The review end (or completion) date. If the review is not completed, this will show as In Progress.
  - Project Id. The value is taken for the list of possible values from the parent Review Group
  - Components. The values are taken for the list of possible values from the parent Review Group
  - The Entry Criteria that has to be met for the review to start. The default value is taken from the parent Review Group but can be modified here.
  - The Objectives for the review.
  - The Reference Materials (documents etc.) that ca n be used during the review

- In the Decision Information expandable section (Informal/Formal reviews only)
  - Meeting data for the decision meeting (Subject, Time, Duration, Location). This can be updated at any time using the Update ''button. The data can be fetched using the ''Refresh button
  - The Exit Decision that tell whether the review is accepted or if some rework has to be done
  - Participants that were part of the exit decision
  - The Total Time spent in the decision meeting.

- For formal reviews only, a phase map that show all phases and the progress of the review. Completed phases are highlighted in green and the current phase is highlighted in cyan. It also show the state and end date for the phase as well as the participant that is the phase owner. Only the phase owner can change the current phase and can thus update progress on the review.

### Working with Review Items Properties

Properties for the Review Item Element includes:

- The Participant Id of the participant that added the Item
- The Email address of the participant that added the Item
- The Project(s) Id(s) the file(s) included in this Item belong to
- The Id of the change e.g. he commit Id. This is only applicable for Commit Review Items.
- The date the change was included e.g. the commit date. This is only applicable for Commit Review Items.
- A brief description of the changes. For Commit Review Items, this is set to the commit message.
- The participants this Review Item is assigned to for review purposes.

### Working with File Contexts Properties

Properties for the File Context Element include a section for the base (predecessor) and target (current) files. Each section contains:

- The Name of the file.
- The Version tag or Id for the file.
- The Path Information for the file.
  - The Repository path show the path to the remote version-controlled repository where the file is located.
  - The Absolute path show the local absolute path to the file.
  - The Project Relative Path show the relative path to the file in the Eclipse workspace.
- The participants this File is assigned to for review purposes.

### Working with Selections and Deltas Properties

Properties for the Selection and Delta Elements include the Position (i.e. the line range) where the selection or delta is located within the parent file and the participants it is assigned to for review purposes.

### Working with Anomalies Properties

Properties for the Anomaly Element includes:

- Directly in the properties view
  - The Anomaly title. If this anomaly includes a design rule, this will be set to the title of the design rule by default.
  - The Description of the Anomaly. If this anomaly includes a design rule, this will be set to the description of the design rule by default.
  - The Anomaly current state (Informal and Formal reviews only).
  - The participant this Anomaly is assigned to for rework purposes.

- In the Anomaly Details expandable section
  - The Creation Date for this Anomaly.
  - The Position (i.e. the line range) where this Anomaly is located within its parent file. This is not applicable for Global Anomalies.
  - The Anomaly Class. The class describes the type of problem that is highlighted by this Anomaly (Informal and Formal reviews only).
  - The Anomaly rank. The rank sets the seriousness of the problem highlighted by this Anomaly (Informal and Formal reviews only).
  - The Rule ID that Anomaly uses, if any (Informal and Formal reviews only).
  - The Due Date for this anomaly to be resolved or addressed (Informal and Formal reviews only).
  - The Reason for Rejection. This is only applicable for anomaly that are rejected (Informal and Formal reviews only).

- In the Participant Details expandable section
  - The Id of the participant that added this Anomaly.
  - The Id of the participant that decided how to handle this Anomaly (Informal and Formal reviews only).
  - The Id of the participant that fixed this Anomaly (Informal and Formal reviews only).
  - The Id of the participant that does the follow-up of this Anomaly (Informal and Formal reviews only).

### Working with Comments Properties

Properties for the Comment Element includes:

- The Participant Id of the participant that added the Comment
- The Time when the Comment was created
- The Comment contents

### Working with Participant Properties

Properties for the Participant Element includes:

- Directly in the properties view
  - The Participant Id.
  - The Participant Email address.
  - The Number of anomalies that were added by this Participant.
  - The Number of comments to anomalies that were added by this Participant.
  - The Focus Area for the Participant for this review.

- In the User Details expandable section
  - Extra User details. This will show the raw information returned by a query to the LDAP database, if one is configured.

- In the Role Management expandable section
  - The Participant roles for the current review. A participant can have more than one role concurrently.

- In the Time Management expandable section
  - A table that tracks the Time Spent by the participant reviewing the file. Entries can be added (or removed) by the participant at any time by using the Add ''(or ''Remove) button. The table will also show the cumulative time spent in its header.

### Working with Rule Sets Properties

Properties for the Rule Set Element includes:

- The Rule Set version
- The Rule Set name
- The Path to the file that contains the Rule Set data

### Working with Rule Areas and Rule Violations Properties

Properties for the Rule Are and Rule Violation Elements only include the name of the Area or Violation.

### Working with Rules Properties

Properties for the Rule Element includes:

- An Identifier that uniquely identifies this Rule.
- The Title. The Anomaly that include this rule will have its title set to this by default.
- The Description. The Anomaly that include this rule will have its description set to this by default.
- The Class. The Anomaly that include this rule will have its class set to this by default.
- The Rank. The Anomaly that include this rule will have its rank set to this by default.

## Using Key Bindings and Hotkeys

#### Keys

Eclipse allows you to customize your keyboard using General>Keys preference page. Within Eclipse, key strokes and key sequences are assigned to invoke a command.

#### Bindings

R4E defines some keys as accelerator keys to help the user to perform reviews. Each command starts with ALT +4 as below:

- ALT +4 A : Add Review Anomaly. Available from any editor View. There must be a selection in the editor to create a new Anomaly.
- ALT +4 C : Collapses the Review Navigator View tree.
- ALT +4 D : Change Display type. Toggles between the Tree and Tree Table displays for the Review Navigator View.
- ALT +4 E : Expand all elements of the Review Navigator View tree.
- ALT +4 F : Opens a dialog used with the Version Control System connector to Find new Review Items. A Project needs to be selected first before using this shortcut.
- ALT +4 I : Add Review Item. Available from any editor View. There must be a selection in the editor to create a new Review Item.
- ALT +4 L : Add a new Linked Anomaly to the selected Review Navigator Selection/Delta element, if any.
- ALT +4 O : Open the default editor on the selected Review Navigator element, if any.
- ALT +4 R : Refresh the Review Navigator View.
- ALT +4 S : Mark/Unmark the selected Review Navigator element as Reviewed, if any.
- ALT +4 X : Remove (disable) the selected Review Navigator element, if any.

When selecting the accelerator key ALT + 4, if the user waits before selecting the next accelerator key, a commands list like the one shown above will be displayed at the bottom right corner of the Eclipse window.

## Using Notifications

R4E support sending Meeting and E-mail notifications directly from the Eclipse workbench. Notification send are pre-filled with all the relevant information, making it easy to have standardized communication between the Review participants.

Meeting notifications also can be used to schedule various meetings (e.g. decision meetings) automatically.

### Using Email Notifications

E-mail notification can be sent on Review Navigator elements by using the Send Email/Notification command from the selected element context menu.

Once the command is triggered, a dialog appears asking the kind of notification to be sent. Take note that not all the options are available depending on the element selected, the review type and other factors.

Selecting one option and closing the dialog will show up a simple email client pre-filled with all the relevant information. The user is free to modify the information as he sees fit and send the email by clicking the ''OK ''button.

### Using Meeting Notifications

Meeting can also be scheduled directly in the workbench using R4E. Meeting data generated is in a VCalendar format that is attached to the Email that will be sent. Meeting data for decision meeting is mandatory for Formal Reviews and optional for other review types.

To add meeting data, use the ''Update ''button in the Extra property tab, under the Decision Information section, for the selected Review element. This will open the Meeting Information dialog.

The meeting information to enter include the time of the meeting, the duration and location where the meeting will take place. To make the time entry easier, you can use the date selector button (the "..." button on the right side of the Starts text field).

The meeting info stored in the system can be retrieved at all times by using the ''Refresh ''button in the Extra property tab, under the Decision Information section, for the selected Review element.

## Using Statistical Reports

Statistical reports provide useful information to analyze the efficiency of one or several reviews.

### Generating Reports

To generate a statistical report, select in the Review Navigator view one or more review, the right click and select "Generate Report"

Two types of report can be generated.

- Inspection record: when you select only one review to generate a report, this type of report will be initiated. You will see a list of anomalies at the end of the report.

- Global report: when two or more review are selected. It gives a summary of information based on the selected reviews.

The report folder is located under the group folder. The group folder is specified in the R4E Preferences,

If the user is not allowed to create a report in the existing group report directory, a new pop-up allows the user to select or to create a new directory to save the requested report. The user can enter a path or select the Browse button to select a location where to store the report.

When the report generation is completed, a pop-up window will indicate where the report was stored.

Once the OK button is clicked, the HTML report will be displayed in the default web browser or in the Eclipse web browser depending on the Eclipse web browsing preferences.

### Report Contents

#### Report Summary

This section lists the reviews that were selected for the report. The review name, group, component, review item type, review type and project information are displayed for each review. The total number of reviews is also displayed at the bottom of this section when more than one review was selected.

#### Review Anomaly Statistics

This section provides the following anomaly counts.

- Totals: Total number of anomalies.
- Ranking: Breakdown of minor and major anomalies.
- Class: Breakdown of anomalies per class.
- State: Breakdown of anomalies per state.

#### Review Efficiency Statistics

This section provides several interesting review efficiency statistics divided in the following groups.

##### Review Items

- Total number of files: Total number of files for which review items have been specified.
- Total Review Items: Total number of review items.
- Total LOC: Total number of reviewed lines of code as specified by the review items. This total includes blank lines and lines with comments.
- Number of Participants: Total number of participants.
- LOC / Participant: Number of reviewed lines of code per participant.
- Preparation Review Rate: Number of reviewed lines of code per hour spent to perform the examination of review items (preparation time).
- Decision Review Rate: Number of reviewed lines of code per hour spent at the decision meeting.

##### Review Anomalies

- Preparation Review Rate: Number of created anomalies per hour spent to perform the examination of review items (preparation time).
- Decision Review Rate: Number of created and imported anomalies per hour spent at the decision meeting. The decision time is based on the meeting time multiplied by the number of meeting participants. For example, if a decision meeting lasts 1 hour and has 3 participants, the decision time is 3 hours.
- Defect Density: Number of accepted anomalies (in states Accepted, Fixed and Verified) per reviewed lines of code.
- Anomaly / Participant: Number of created anomalies per participant.

##### Average Time Line

- Review Start: Review start date. This is only valid when only one review was selected for the report.
- Review Completion: Review completion date. This is only valid when only one review was selected for the report.
- Review Cycle: Average number of days for a review cycle (all review phases).
- Planning Phase: Average number of days spent in the planning phase. This statistic is only valid for formal reviews.
- Preparation Phase: Average number of days spent in the preparation phase. This statistic is only valid for formal reviews.
- Decision Phase: Average number of days spent in the decision phase. This statistic is only valid for formal reviews.
- Rework Phase: Average number of days spent in the rework phase. This statistic is only valid for formal reviews.

##### Average Effort per Participant

- Preparation Time: Average time spent to perform examination of review items per participant.
- Decision Time: Average time spent at the decision meeting in hours per participant who participated in the meeting.
- Average Review Time: Average review time spent per participant.

##### Total Review Effort

- Preparation Time: Total time spent to perform examination of review items (preparation time).
- Decision Time: Total time spent at the decision meeting. The decision time is based on the meeting time multiplied by the number of meeting participants. For example, if a decision meeting lasts 1 hour and has 3 participants, the decision time is 3 hours.
- Total Review Time: Total review time.

##### List of Anomalies

This section is only available for the inspection record. The list of anomalies raised during the review with the following information: File Name, line range, tile of the anomaly, class, ranking and the due date.

## Performing Reviews

### Performing Basic Reviews

In R4E, basic reviews are the simplest form of reviews available. Basic reviews are stateless and the anomalies that are raised are also stateless. This means the participants must track progress of the Review and of the raised Anomaly externally.

Typically, the workflow of a basic review will go as follows:

1. Review is created
2. Review Items are added, either by manually selecting resources or by automatically selecting files committed using the Find Review Items command on the target project .
3. Optionally, review elements are assigned to specific participants.
4. Organizer/Lead notifies reviewers that the items are ready for review. his can be done externally or by using the Email notification functionality provided by R4E
5. Reviewers review their items and raise anomalies as they encounter them.
6. At any time there could be communication between the reviewers and the authors of the code under review. Since there is no anomaly state tracking, they will have to agree on how to handle the anomalies raised.
7. Once all the reviewers are done and the anomalies are fixed, the review can be set as completed.

### Performing Informal Reviews

Informal Review workflow is pretty much the same as the Basic Review workflow, so the steps described above still apply. However, the main difference is the fact that anomalies are now stateful and they need to be addressed/resolved before the review can be closed.

The state diagram for the anomaly workflow is as follows:

- Assigned: This is the state set when the anomalies are created. This is the only non-terminal state
- Deferred: The Anomaly will is valid but will not be fixed now, but at a later time
- Duplicated: The Anomaly is a duplicate of another one
- Rejected: The Anomaly is invalid and will not be fixed
- Fixed: The Anomaly is valid and was fixed. This is normally a terminal state, unless the Review Exit Decision is set to Accepted with Follow-up, in which case the Verified state is the terminal one.
- Verified: The Anomaly was fixed and verified by the participant that raised it. This state is normally optional, but all Anomalies that are fixed should be subsequently set to verified is the Review Exit Decision is set to Accepted with Follow-up.

Once all the Anomalies are in a terminal state, the review can then be closed as it is done for Basic Reviews.

### Performing Formal Reviews

Formal Review follow the IEEE 1028-1997 standard. They are stateful and divided into Review Phases. As in Informal Reviews, anomalies created are also stateful.

The state diagram for Formal review workflow is as follows:

#### Planning Phase

The Planning phase is the active phase when the review is initially created. In this phase, the Review Organizer and/or Lead adds the contents that is to be reviewed, either manually or by selecting items from the Version Control System and adds participant that will be part of the review. Optionally, review elements are assigned to specific participants. At the end of this phase, a notification is sent to the participant that the items are ready to be reviewed, and an invitation to a decision meeting set-up by the Organizer/Lead. Once this phase is completed, it is impossible to go back to it.

#### Preparation Phase

The Preparation phase is the phase where participants review the items included in the review and potentially raise anomalies. Once all reviewers have completed their tasks (and notified the Organizer/Lead), then the review can progress to the next phase.

#### Decision Phase

The Decision phase is where all the anomalies that were logged are analyzed and a decision is made on each of them on how to handle them. Potential outcomes include fixing the problem flagged by the anomaly, deferring it, or rejecting it if it is not valid. Once all the Anomalies are examined, a decision can be taken on how to close the review. The possible outcomes for the review at this stage is that it could be rejected and more reviewing/rework is necessary, it could be accepted as is, or it could be conditionally accepted, provided that the outstanding anomalies are fixed.

#### Rework Phase

The Rework phase is an optional phase, only used when a review is conditionally accepted, in which valid anomalies are fixed. Once the fixed are included, the anomalies will need to be re-checked to verify that the fixes are acceptable. When all the fixes are verified, the Review can be completed.

#### Other Considerations

Take note that there is a slight difference between the anomaly states in Informal Reviews and the ones used in Formal Reviews, as it can be seen below:

A new Anomaly in a Formal Review is set to CREATED ''by default. During the decision phase, it could be set to the same values as in Informal Reviews, and it can also be set to ''ACCEPTED, which means that the anomaly is deemed valid and will be handled and fixed. There is no ''ASSIGNED ''state for Anomalies in Formal Reviews. The rest of the anomaly flow is essentially the same as with Informal Reviews.