You are REQUIRED to turn on Canvas e-mail notifications for group
messaging/chat/etc for this course. REQUIRED. This is because in
practice students are unable to navigate to the super-obscure place where you
can find another student's e-mail address, there are collisions with other
student names, Canvas "preferred names" do not align with e-mail
lookup tools, etc. Too much pain and dispair. So we require you to use Canvas
group communications for initial communication on each group assignment. At a
bare minimum exchange unambiguous e-mail addresses. You can use it for
follow-up at your discretion.
Canvas will have group assignments. If for some reason you complete a group
assignment and not all assigned members participate, please add a hand-in
comment explaining the situation. You should make a reasonable attempt to
convene all group members in one sitting, but you should not hand in late
because one group member was unresponsive or missed an arranged meeting. If you
have concerns on this point please e-mail the course staff to explain the
situation. (This applies for all future group assignments as well.)
We suggest, but do not require, that you use Google tools for real-time
collaboration (in this case a shared spreadsheet for recording review results
as you go):
https://www.cmu.edu/computing/services/comm-collab/collaboration/google-drive/index.html
Do a peer review on the following code: OpenBSD qsort
version 1.10. (Note that this is an acrobat file so everyone will have
consistent line numbers to work with.)
You'll be using an industry-oriented peer review checklist for this review.
(This is NOT the same as Project 3/4, but it is the review checklist you'll be
using later in the course for your projects after Project 4.)
Spend a few minutes (no more than 5 minutes) getting general familiarity
with the file so you more or less understand what's going on. This is a
QuickSort implementation, and hopefully you've seen that algorithm before
somewhere, but that is not essential for the code review.
BEFORE THE TA MEETING:
- Turn on the Canvas feature that generates e-mail immediately when you get a
group message. (If you don't do this your group members will be frustrated that
you don't know to respond.)
- Use canvas group messaging for your peer review group to exchange e-mail
addresses. Do this before the last minute so if you have trouble you can sort
it out.
- Make sure you save a copy of at least one EMAIL send to you when a new
group message is generated in Canvas.
AT THE TA MEETING:
Assign the following roles within your group:
- Tell the TA whether you were able to get e-mail working for a group
announcement. Fix your settings and test it right then with help if you need
to.
- Review leader & recorder (the first person listed in the group
assignment)
- Review leader is responsible for guiding the review, recording results, and
keeping all discussions to less than 60 seconds on any topic.
- Reviewers (everyone else). Reviewers split up items 1-17 in the checklist
roughly evenly. Ignore checklist item #18.
- For example, for 4 reviewers in addition to the leader: (1) items #1-4; (2)
items #5-9; (3) items #10-13; (4) items #14-17.
- It's OK to vary this assignment, but each reviewer should have primary
responsibility for about a quarter of the checklist.
- It's OK to swap roles partway through just to keep things interesting, but
keep a single role for each code block.
- Use this Peer Review checklist.
This is an industry-grade checklist for generic software and is DIFFERENT from
the project 3/4 checklist. However, you'll be using this checklist later in the
semester.
- Use this reporting form for ALL peer reviews in this course:
- Peer review issue log (Excel). Use this
exact form. Uploading this form to Google Drive and using Google Sheets to fill
it out in the review might be helpful for collaboration. Make a new copy of
this blank file on your google drive for every peer review you do during the
course.
- DO NOT CHANGE THE FONT SIZE! Do not shrink font to fit -- instead wrap
text to multiple lines in the cell.
- MAKE SURE all columns including "status" print on a single sheet
and are not split across sheets. If you adjust column width this might spill
columns onto another page. Fix that by narrowing some columns without reducing
font size.
- This sheet is optimized to be readible on Canvas for grading. It is OK if
some rows spill onto a later page, but make sure all columns in a row are on
the same page when printing and fonts are large as in this sheet (set at 16
point fonts)
- Do NOT put multiple spreadsheets on the same page when rendering to
acrobat. One spreadsheet per page maximum (sometimes one spreadsheet takes two
pages if rows spill over onto the next page).
- Consider using Google Sheets (or another service) to interactively manage
the issue log during the review. Download from Google Sheets in pdf format
might be useful to you.
Methodically go through the code starting at line 83 using the following
procedure:
- The review leader identifies a chunk of 1 to 10 lines (typically 4-5
lines) to focus on.
- Here are some hints as to good chunks to consider: (1) lines 83-88; (2)
lines 90-91; (3) lines 92-98; (4) line 99; (5) lines 100-102; (6) lines
103-108; ...
- Each reviewer looks ONLY at the assigned code chunk and looks at EACH
assigned item one at a time.
- A reviewer finding a problem states exactly this content in exactly this
order: Rule #, Line #, brief description; review leader writes them down in the
review log.
- When all reviewers have completed their checklist, review leader asks
"anything else?" Reviewers can spend a brief moment saying things not
in their assigned item list.
- Review leader returns to step #1, starting the next chunk
Stop when you've spent a half hour or recorded 20 defects --
whichever comes first. Hand in the review file. This is not a race; and it
is MUCH better to be thorough than fast. So the fewer chunks of code you look
at to find the first 20 defects, the better you are doing.
Supplemental Material:
RUBRIC:
- One document (Acrobat is probably the best) that is displayable by Canvas.
File name: P00_Group##.pdf. (For future peer reviews P00 will be replaced with
the project number being reviewed).
- Document shall be the required spreadsheet printed in landscape format with
the full width of the spreadsheet on a single page.
- Peer review logs shall take substantially the full width of the page with
only normal (1" or less) page margins on letter size output. Fonts on
materials not generated by the peer review spreadsheet shall be no smaller than
16 point if printed on letter size paper (not squeezed to fit). If there are
too many rows then that will generate multiple landscape pages for successive
rows.
- First page: all students in group, group number, project number being
reviewed, & TA who attended the TA meeting. If any student did not attend
the TA meeting, list that student name and say "Did Not Attend TA meeting
next to that name." This information shall be on a separate sheet on the
first page of the handin.
- Subsequent pages of the document are the peer review spreadsheets, one
spreadsheet per artifact from one author. (Thus, for group of 3 this is a 3
page document if one artifact or artifact set from each author is being
reviewed.)
- Each item in the peer review issue log describes which artifact it is for
(for example: Sequence Diagrams #SD-3, ... issue ...)
- Each page clearly identifies the project # being reviewed, the author, and
ALL the non-authors for that spreadsheet.
- Issues must be recorded but do NOT need to show resolved on the hand-in.
(You should resolve them later.)
- The checklist you used for the reviews.
- A copy of an e-mail from each review participant from Canvas to document
that they have figured out appropriate settings.