Procedure

  • Find another team to evaluate within the group
  • Clone their repository (they should give you the rights to access the repository)
  • Copy the evaluation form below in a local file (e.g. peer-review.md, where the .md stands for Markdown)
  • Fill in the evaluation form (which requires you to run the code, look at the tests, look at the code)
  • when you are done, submit a github issue on their repository with the content of the evaluation. The name of the issue should start with [PEER REVIEW]

Evaluation form

For each criterion, you should give a grade between A+ and D, with the following semantic:

  • A: Mastered
  • B: Concepts appear to be reasonably assimilated, with progress still possible in their exploitation
  • C: Clearly insufficient
  • D: Absent or completely wrong 
---
Evaluated team:
 - SURNAME1
 - SURNAME2
Evaluators: 
 - SURNAME1
 - SURNAME2
...

# Functionalities
  
## discovery
<!-- Connection and contact discovery phase -->

grade: ?

comments: ...

## Presentation of contacts/error 
<!-- How readable and user friendly is the presented output. -->

grade: ?

comments: 



# Quality

## README
<!-- Presence and completeness of the README -->

grade: ?

comments: ...


## maven
<!-- Does the project compiles and run based on the `pom.xml` file only. -->

grade: ?

comments: ...


## tests
<!-- Proportion of the code covered by the tests. Are the tests sensible, correct and well organized -->

grade: ?

comments: ...


## repository
<!-- Structure of the git repository (directories, gitignore, presence of undesired files) -->

grade: ?

comments: ...


## structure
<!-- Structure of the code into sensible and independent packages -->

grade: ?

comments: ...


## reliability
<!-- Thread safety and error handling -->

grade: ?

comments: ...


## style
<!-- Variable naming, indentation, comments, ... -->

grade: ?

comments: ...