|author||Sebastian Schuberth <email@example.com>||Mon Mar 14 12:48:04 2016 +0100|
|committer||Sebastian Schuberth <firstname.lastname@example.org>||Mon Mar 14 12:48:04 2016 +0100|
Rename to README.md as it is a Markdown file Change-Id: I54c6977e15c4d7977fc14ead0882689b86809c49
Gerrit provides web based code review and repository management for the Git version control system. The Review It? app is an Android app for Gerrit that allows sorting of incoming changes and review of small/trivial changes.
The app suppports a 2-step review process:
Some users may just want to do reviews and skip the first step.
This is not an official Google product.
When working with Gerrit it is a common workflow that reviewers are not always explicitly assigned, but that committers and contributors watch the incoming changes and choose those changes for review that are interesting to them.
Watching incoming changes can be done in different ways, e.g:
These approaches have some problems in common when the number of incoming changes gets too high:
The ‘ReviewIt?’ Android app tries to solve these problems by offering a simple way to sort incoming changes:
The actual review of the changes is done later, either by using the Gerrit web UI or by using the review functionality of the Review It? app. The idea is that the sorting of incoming changes allows users to stay updated about their project while they are not in office (see new changes and sort them), but the code review is done only later when there is time for it. Also some large changes may not be reviewable on the small display of a phone.
The changes that have been starred are accessible by a change query or a Gerrit dashboard, and hence they can be easily found when there is time to do reviews. The app should configure an entry for this dashboard in the Gerrit menu automatically (e.g. ‘My’ > ‘Review It’).
Updates for ignored changes are filtered out so that the noise is reduced. In addition to starring/ignoring a change, the app also offers to skip changes. Skipping a change means that the user is asked about this change once more when it was updated.
Within the app the user can define a change query for the incoming changes. The results are then presented one by one. For each change a decision (star, ignore or skip) has to be made to go to the next change.
Starring/ignoring a change can be done by swiping the change to the right/left side. In addition there are buttons to trigger starring, ignoring and skipping a change.
The main app screen provides the information that is most relevant to deciding whether a change is interesting:
This information is presented in a very compressed way and the focus is on the subject and the commit message.
All actions (star, ignore and skip) are undoable by clicking on the undo action in the menu, so that mistakes in sorting can be easily corrected.
Sometimes when watching a change one knows another person that is well suited to review this change. This is why there is an add reviewer action in the menu that allows to add another person as reviewer. Reviewer names are auto-completed on typing.
There is also a menu entry to abandon the current change if it is no longer needed.
By clicking on the bottom of the change one can go to a detailed change view where more information is presented, e.g. the change number, the change link, the approvals and the list of files. This detailed change view is zoomable.
The diff for all files can be seen in one unified diff view.
The file diffs are presented in a scroll view where the header with the file name of the currently viewed file diff is sticky at the top of the screen.
Skipped context lines can be expanded.
This is not implemented yet, but it is envisioned to show a list of changes (either those starred by the sorting step or all incoming changes) and then allow the user to select a change for review. This leads to the view with the unified diff of all changed files and at the end of it there will be voting buttons to approve or reject the change.
Contributions are welcome!
Please read the contribution guidelines.
Note that we do not accept Pull Requests via the Github mirror.
The app uses the following build-time dependencies provided under the given licenses:
Compile-time dependencies are listed in the app's help screen.