These instructions will walk you through the process for submitting Problem Sets and Exams. We provide a checklist first, followed by all the messy details.

Checklist

You can use this checklist before submitting an assignment to make sure you don’t miss anything!

Accept the GitHub classroom invite.
Use RStudio to “Clone with HTTPS” this repo to your computer.
Start an empty R Markdown file for your answers. Name is correctly.
Make progress.
- Follow the course Style Guide for your code.
- As you work, perform at least 5 commits. Provide a short (but meaningful!) commit message each time.
- Make sure to add *Rproj to your .gitignore.
- Push regularly. You don’t want to lose (much) work if your computer explodes.
- Name your R code chunks.
- Set knitr::opts_chunk$set(echo = FALSE) in your setup code chunk. We do not want to see any of your R code in the main portion of the PDF. The only place R code appears is in the ## Code section at the end
- Do not print the results of your individual chunks to the PDF.
- Make sure to add meaningful comments to your code. Comments are discussed at length in the course Style Guide.
- Include names of colleagues with whom you collaborate for problem sets (no collaboration on Exams) at the end of the Rmd, but before the ## Code section.
Include this as the last item in your Rmd:

\newpage

## Code

```{r print-code, ref.label = knitr::all_labels(), echo = TRUE, eval = FALSE}
```

Make sure that you do a final push once your work is complete.
Submit to Gradescope via the Github option, selecting the correct repo, and choosing the “master” branch. (You can do this as you work, if you like. Only the last version submitted, before the deadline, counts for grading purposes.)
Upload final PDF to Gradescope. Note that this is a separate assignment from the one to which you submitted your Github repo. Make sure that there are no warnings, messages, or errors. The only things that should appear in your PDF are plots, tables, written answers, and a single chunk with all of your code at the end.

Details

1. Accept the GitHub classroom invite

You will start Problem Sets and Exams by creating a special Github repo in the GOV-1005-Spring-2021 organization. You will receive an email invitation to GitHub Classroom. Click on the link and accept the invitation!

This is what the invite will look like! Click accept.

Accepting the invitation will create the new repository. (You may need to refresh the initial page before you are re-directed to a page with the new link.) Your empty repository may look something like this:

A fresh start!

2. Use RStudio to “Clone with HTTPS” this repo to your computer

Now that the repository exists, you need to “Clone with HTTPS” to clone it to your own computer. This process is what connects files on your computer to a Github repo. This process will be fully covered in class, but you can review it anytime in the “Tools” Chapter of The Primer.

Remember this? This is why it’s useful! See the Tools Chapter for more details.

3. Start an empty R Markdown file for your answers

Once your repo is cloned, you should make an empty R Markdown (.Rmd) file to store your solutions. You must follow the course naming convention in order for Gradescope to work: ps_1.Rmd or exam_1.Rmd with “1” replaced by the number of the assignment you’re working on. Click File -> New File -> R Markdown, enter the Title and Author values, and select PDF as the output.

Recall that the .Rmd file is a technical document for text and code. This is a record of your work which allows us to reproduce your .pdf file. It should be well-organized, nicely formatted and clean.

The .pdf file is a presentation document, designed for non-technical readers. No R code (except for your entire replication code at the end, described below), messages, warnings, or errors should appear.

Students often have trouble turning off R messages / warnings / errors. These may not appear in your .pdf. Sometimes you notice random things you did not type appearing in your .pdf that look like the sort of messages that often appear in your RStudio Console. These are messages, warnings, and errors. The right way to deal with these issues is to find out their cause and then fix the underlying problem.

Students sometimes use “hacks” to make these messages/warnings/errors disappear. The most common hacks involve using code chunk options like message = FALSE, warning = FALSE, results = “hide”, include = FALSE and others. Don’t do this, in general. A message / warning / error is worth understanding and then fixing. Don’t close your eyes (metaphorically) and pretend that the problem doesn’t exist.

There are some situations, however, in which, no matter what you try, you can’t fix the problem. In those few cases, you can use one of these hacks, but you must make a code comment directly below it, explaining the situation. The only exception is the “setup” chunk (included by default in every new Rmd) which comes with include = FALSE. In that chunk, no explanation is necessary, by convention. Packages will often automatically print out warnings or messages when you load them with library(). Wrapping the call to library within suppressPackageStartupMessages() will suppress those. Best practice is to load all libraries in the setup chunk.

Newly made Rmd files are pre-populated with some example code. You can delete everything under the setup code chunk.

Finally, save this .Rmd file into your cloned repository.

4. Make progress

Answer the questions and use GitHub as you go to add, commit, and push changes as you make them. Create a named code chunk for each new question – remember that naming a code chunk just means putting a short title after the lowercase r in the code chunk, in the example below the names are q1 and q2.

5. Push submittable version to GitHub

Do not wait until your file is ready to submit to commit changes. You need to commit files at least five times while working on problem sets and exams. It is good practice to make gradual commits to your repository as you make progress. If you are smart, you will also push regularly, but we do not monitor pushes, just commits.

Eventually, you will be done! Once you’re ready to submit something, make sure you push the latest version to your GitHub repo. Do not forget to add your Rproj file to your .gitignore. You should not upload your Rproj file to GitHub.

6. Upload Github repo to autograder

Go to Gradescope and “submit” your work. Select “Github” as your “Submission Method”.

You will need to select your repo and then choose the default (“master” or, sometimes, “main”) branch. (You may need to authorize Github the first time. You may also need to ask us for permission to access the class organization. We are here to help!)

The big advantage of Gradescope is that you can automatically check your problem set and exam solutions as you complete them. Gradescope will take a few seconds to run, and eventually you will see a page like this:

Make sure to read the messages even (especially!) if your response is incorrect, the messages are there to help you!

The two messages here (called “tests”) check (1) if the file structure is correct and (2) whether your answers are correct. Here, we successfully uploaded the file and answered Question 1, so we received full credit. If Question 1 were wrong in some way, you would see a helpful message here telling you what happened and pointing you in the right direction. For example, here Question 1 asks you to slice the first 5 rows in the trains dataset. If you had submitting an object that was too large, the question label would note that the object you submitted did not have the correct number of rows.

Most importantly, you can do this process as many times as you want! That means you are able to grade your problem sets and exams as you work on them. Gradescope will store your final submission as your final grade for the assignment, but you can submit to the autograder as many times as you want with no penalty. Take advantage of this!

7. Upload final pdf (with code) to Gradescope

Finally, you will submit your PDF so that course staff can grade any remaining questions not covered by the autograder - questions like plots, written answers, and code style. At the end of your .Rmd file, you should include an empty code chunk with the following code in brackets: r print-code, ref.label = knitr::all_labels(), echo = TRUE, eval = FALSE, as described above. This code chunk will print out all of the code in your chunks above. In order for this to work, your chunks will have to be named. You can also include a \newpage command in your text to force your code output to print on a new page. Here is an example shown below. For Problem Sets, you should also include the names of colleagues that you worked with in your final .pdf. We define “worked with” very broadly. It would include, for example, students you discussed strategies with during Study Hall.

An example of a properly done code style chunk.

Once you have your PDF prepared, go to Gradescope and click on the “PDF” assignment. Then, Gradescope will prompt you to select the pages that each written question is on (this is another reason why \newpage can be helpful!). Follow the instructions and press Submit when you’re done!

Note that the programming assignment and the PDF assignment have nothing to do with one another. That is, we do not care if the code you submit for programming is different from the code which generated your PDF. We do not check this. We just use the automated score. And then we look at your PDF and grade that by hand.

Advice: Always knit to html at the start. It is quicker and less error prone. You do not need to submit PDF (or even html) for the programming exercises. Only the Rmd file is used. Once you have scored your 10/10, you do not need to submit again, even if you make changes. Instead, just worry about the PDF. What matters for that are the plots, tables and written answers, as well as the code printed at the end.

Assignments for Gov 1005