Write down your answers (and why you chose them!) in your group’s shared doc.
In this lab, you will review another group’s code to give feedback, find new bugs, and learn from each other.
The overall plan for lab is:
Make as much progress as you can on your grading script from Week 6. Ask your lab tutor if you need help getting it into a good state.
To help guide your process, we’ve created a review Kahoot to help review bash concepts. Bash Review Kahoot
Don’t worry about perfection; focus most on it being able to run and grade some of the sample submissions.
When you’re happy with it, have one partner make a new repository on Github named
<username> is one of your usernames.
To do this, navigate to any GitHub page and click the
+ button in the top right corner, as seen on the screenshot below. A dropdown menu will appear, and you will click
From there, a page will pop up which allows you to set some attributes of your new repository. The only thing you need to change is the name, as seen in the following screenshot. You do not need to alter any other settings, and can press the green
Create repository button at the bottom.
Now, we want this new repository to contain the version of your autograder that you want reviewed (This step makes it so pull requests and issues will work in the last step later). To do that, you should navigate to your newly-created repository on GitHub.
Currently, it should be empty. You should see something like the screenshot below. We want to import your grading script code (which should exist in some other GitHub repo) into this repository. Click the
Import code button circled in red below.
After clicking the above button, a page will pop up which asks you for “Your old repository’s clone URL”. Here, you will paste the HTTPS url of the GitHub repository which contains your grading script to-be-reviewed. Click the green
Begin import button and wait for your code to be transferred over.
Before sharing, we should also make sure that it will work for others, and doesn’t only work on your machine! All too often it’s easy to write programs that run our own laptop, but when someone else clones our code, it doesn’t work on theirs. This leads to the dreaded it works on my machine:
We will standardize and say that all the graders should run on
ieng6. So, you should test your grader by logging into
ieng6, cloning it, and running it once there. If you get different behavior on a fresh clone on
ieng6 than when you previously tested it, figure out what happened! Your lab tutor can probably help, a few common issues are:
:and not the Windows-specific
Once you see the script run like you expect on
ieng6, your grading script is ready to be reviewed! Your lab tutor will manage assigning those submissions between groups for review.
Your lab tutor will provide you with a link to a repository for another group.
Make a fork of it, clone it, and complete the following tasks. For each, document it in your notes file:
Write down all of this feedback in the notes file. You’ll go over it with the other group next. Think about how to give any feedback about issues politely and professionally.
In all of this communication, remember to be polite, professional, and focus on giving detail and clear writing. A huge part of the job of a working software professional or researcher is accurately communicating about code and system behavior, and doing so in a way that is about the system and not about any specific person.
Some tricks for this: avoid statements that reference the author of the code, frame negative feedback as possible improvements or ways your expectations were violated, and take responsibility as the reviewer for anything you don’t understand.
grep -rinstead of
After you write this down, the lab leaders will help reorganize your groups so you’re talking to the group you reviewed (and who reviewed your code).
Go through the feedback you wrote down in the last step, and take notes on clarifications and answers to questions you had.
Then, as appropriate, you should make issues and pull requests to one another’s repositories summarizing the feedback. Create these pull requests and issues together with the other group, this will help everyone understand what’s written down.
Make an issue if there’s a problem or improvement to make that you aren’t sure how to fix. Make sure to include the failure-inducing input, context, and symptoms! They’ll come back to this in a future week and need all that detail to help understand and fix it. The Github instructions for making an issue are here:
Creating an Issue
Make a pull request if you have direct code update suggestions for the other group. A pull request is a Github concept for sharing code edits with others. To make a pull request, first make a fork of the repository you want to submit the pull request to. Then, make the edits and commits you want to make, and push them to your fork. Then the Github instructions for creating the pull request are here:
Making a Pull Request
Having an issue or pull request filed for your project is not a bad thing! In the good cases, it means someone else out there in the world (or in your company/institution) read your code, wants to help, and has something constructive to say about it. Of course, you have control over the code, too, so you don’t have to accept their feedback as they wrote it. You can take it as advice, ignore it, adapt it, put it off until later, and so on. But remember that issues and pull requests are largely positive things – they are a sign that your project has people paying attention to it, and they are a normal and common part of managing a software system.