Peer-review another team’s project and provide suggestions for improvements. This helps the other team by providing a fresh perspective and giving them outside feedback. It also helps you and your team: you will see how another team is approaching a problem, which can give you ideas of what to do or what to avoid.
As a team, peer-review the project assigned to your team for review. To find the project to review, open this milestone assignment in Canvas and find the project name associated with your team in the table. Immediately contact that team to get access to their GitHub repo for each of your team members. If their repo is private, you will need to provide your GitHub usernames to them.
Provide access to your repo to the students peer reviewing your project. Access is required by Wed 11:59pm so the students can get started on their review.
Read the developer guidelines, then build and test the product.
Read the user documentation, then run the product.
If you are blocked while trying to do these things, open an issue immediately indicating that you are blocked. If another team opens such an issue on your repository, resolve it immediately.
You should open other issues as appropriate. You may open a pull request with suggested improvements if you see how to resolve an issue that you raised.
You will submit a single document, consisting of the review list below and your experience, and issue URLs for any bugs or improvements encountered.
There are developer guidelines, which I could easily find in the repository.
The developer guidelines are self-contained and well structured.
The description of the repository structure is clear and makes sense to me.
I could build the software, following the provided instructions, on a machine matching the prerequisites mentioned in the instructions.
I could test the software, following the provided instructions.
The instructions for how to add a new test case are clear enough that I could follow them.
The continuous integration (CI) setup makes sense to me, and I could find the build history.
For any item in this list that you do not agree with or that could be improved, open an issue in their repository and provide the URL in your document.
Open issues with high-level feedback and constructive criticism focusing on their implementation, descriptive writing, or technical setup. Each issue should only address one concern.
In addition, open one issue with praise: point out aspects of their project that you appreciated or found to be well-done. (This is customary in a pull request, but you are not reviewing a pull request, and we wanted to provide a place for the praise.)
Provide the issue URLs in your document.
Submit this review as a document to Canvas by due date. Include your names as well as the name of the project that you are reviewing. The document should include the review list and feedback with corresponding titles of issues or pull requests and their URLs in the GitHub issue tracker. The major content should be found in the issue tracker.
Pull requests are optional. If you choose to make a pull request, here are instructions:
Open the repository of the reviewed system on GitHub.
Click “Fork”, which will create a clone of the repository under your account.
Clone the forked repository (under your account) to your computer;
Create a branch in the forked repository.
Make changes in the branch, then push them.
Open a pull request on GitHub into the original repository.