The Model

2.1. Griotte's Model

Griotte's model consists of several abstract classes which require to be implemented by a backend. In other words, the classes of the model define a set of operations and accessors which a backend should be able to perform and provide for. The model is defined as follows:

GrUser

A user represents someone that performs operations in a review. They can be asked for the repositories that they own.

By design, this is an immutable class. This is useful because in this way, one can for example compare a user of a comment with the logged in user of the current context (see the 2.1 explanation on GrContext).

One can then display for example in a comment or a review, that the person who made that comment is the one that is logged in (i.e. you).

GrRepository

A repository is in principle a collection of reviews, as far as we are concerned. It can return the local reviews, those active in Griotte, and non-local reviews.

It allows for the creation of new reviews, through GrRepository>>newReviewWithTitle:description:.

GrReview

A review is a request for a change to be integrated into the system. It supports two basic operations: GrReview>>approve or GrReview>>reject.

It allows for a conversation of the review on a global level. These are called top-level comments. They can be accessed with the GrReview>>comments accessor. New top-level comments can be created using GrReview>>newCommentWithBody:.

Basic accessors are its title, its creator (which returns a GrUser) and its description.

In the future, the reviews contain the groups of changes.

GrGroup

A group is a collection of related changes with a description. Comments can be added to groups too, allowing for a more detailed conversation. Groups can be generated by using the information provided by fine-grained IDE events (see 2.2 for more information).

How groups are stored is defined by the backend which implements it.

As groups are not yet implemented, the only operation that is known so far is GrGroup>>newCommentWithBody:.

GrComment

A comment can be made on either a review (the aforementioned top-level comments) or on a group of changes. The model makes no distinction between comments added to groups or to reviews — both are just comments.

A backend can of course distinguish between these two if it is necessary for the implementation.

A comment can be edited through GrComment>>edit:, and it can be accessed for its body, creator, and both the time it was created and the time it was last updated.

GrContext

A relatively late addition to the model, this class represents the connection between the repositories that are locally active (those with locally active reviews), and the user that is logged in.

The interface of Griotte should allow for multiple contexts to be present at the same time, for using different backends transparently, and for context switching between logins.

2.2. Epicea Fine-Grained IDE Events

Epicea is a Pharo project for recording the actions of a developer within the IDE. It was originally created for the PhD thesis of Martín Dias. The information recorded by Epicea is much more than what is recorded in the Version Control System (e.g. Git) at the point of commit; for example, Epicea records the following:

• Each save of a code change (e.g. Class addition, method modification).
• Test runs and their respective outcomes.
• Versioning operations (commits, checkouts).
• Refactorings.

In this sense we say that the events Epicea records are fine-grained, in contrast with the coarse-grained information stored by Version Control Systems.

The information provided by Epicea allows one to group changes together when committing them. These groups can then in turn be used for code review. The grouping can be done with the Epicea Untangler.