Project Peer Feedback

Each iteration you will give and get peer feedback. When you get feedback, read it carefully and think how you can improve. This is your chance to become a stronger asset to every team you ever join!

Areas for Comment

You should provide feedback on the following:

Teamwork: Communication, initiative, reliability
Technical work: Amount of contribution, code quality, Git workflow skills
Suggestion to improve: Provide concrete constructive feedback highlighting the most important area to improve (may be incorporated into above points)

How to Provide Peer Feedback

Provide your honest constructive feedback. Constructive feedback helps someone identify ways to improve without being mean or severe.

For example, imagine your teammate Brian has been pushing a reasonable amount of code, but the code is low quality. Here are some example feedbacks:

Bad: "Great job this iteration. Keep up the good work." -- is not honest and does not help Brian improve.
Bad: "Terrible job! How did you get into this course with such horrific coding?!?!?" -- while it may be honest, is both insulting and unhelpful. It fails to recognize any good attributes and does not constructively discuss ways to improve. Brian is most likely to be insulted, stop working as hard on the project, and not work to improve.
Good: "Good work pushing the project ahead on features X, and Y. I found the code to be a little hard to read. Try making shorter functions and giving variables/functions clearer names." -- it recognizes what was done well, and provides concrete suggestions on what to change in a non-offensive tone. Brian will know what to keep doing well, and have some concrete things to work on without feeling insulted.

Write the feedback in a way you'd like someone to tell you about how to improve. Pretend you are having coffee with the person and think about how they will feel after reading your constructive comments. Reread your comments out loud to ensure you have the tone correct.

Suggested Rubric

You have 20 points per group member to allocate. If everyone worked at a 30/20 level, you can still only give everyone 20/20! Generally, assign scores lower than 20 to show someone did not contribute fully to the project, then assign extra points to those who picked up the slack.

23+ Points: Amazing work which went above and beyond what one teammate could be expected to do! A strong asset to the team in every way.
21-22 Points: Better than expected work; strong contribution in every way.
20 Points: Very good, met expectations in every way. May have areas to improve on, but fully contributed to the team.
17-19 Points: OK or Good work, but some aspects of teamwork or technical work need some improvement.
14-16 Points: Poor work which caused some real issues for the team. Teamwork may be poor, such as very slow responses to communications or poor attitude towards teammates. Technical work may be poor, such as lower contribution, missing deadlines which causes others to do more work, or quite poor code quality code.
11-13 Points: Needs significant improvement to become a valued member of the team. Teamwork may have been very poor, such as not communicating, or significantly inhibiting teammates with attitude or tone. Technical work may have been very poor, such as minimal contribution, excessively late work, or very low code quality (ex: almost all code needed to be re-written for it to correctly integrate into the project).
0-10 Points: Dropped the ball. Student is hindering the team such that group moral and productivity was significantly reduced. Teamwork may have been the issue, with behaviour such as insulting and disrespecting teammates. Technical work may have been the issue, such as almost no functioning code contributed to the project. To be clear, you should give a team mate between 0 and 10 if they were not an asset to the team (such as no code contribution). In the private feedback to the instructor section, mention "dropped the ball" and provide some specifics about why.