Grading Rubrics

These grading rubrics apply to problem sets and to the final projects in Gov 1005.

  • Make sure you follow all the instructions in the prompt.

  • Follow the Tidyverse Style Guide.

  • Ensure that your repo is clean (no unnecessary or duplicative files).

  • At least 5 commits with sensible commit messages, i.e., not “stuff” or “update.”

  • Once we download your repo, can we replicate your work easily? When we knit your .Rmd file, does your code throw an error (for example, by referencing a file you have locally but which you didn’t push to GitHub)? (It is OK if you use a library which we need to download, but your Rmd better include all the necessary library() commands.)

  • List the colleagues you worked with, if any.

  • Make your code readable. Formatting matters.

  • Include comments in your code. Rough guideline: You should have as many lines of comments as you have lines of code.

  • Make your comments meaningful. They should not be a simple description of what your code does.

  • Code comments must be separated from code by one empty line on both sides.

  • Format your code comments neatly. Cmd-Shift-/ is the easiest way to do that.

  • Name your R code chunks.

  • Spelling and punctuation matter.

  • Use captions, titles, axis labels and so on to make it clear what your tables and graphics mean.

  • Use your best judgment. For example, sometimes axis labels are unnecessary. Read Data Visualization: A practical introduction by Kieran Healy for guidance on making high quality graphics.

These grading rubrics are specific to the final projects.

  • You should have a one and four sentence summary of your project memorized for Demo Day. The one sentence summary is for listeners who want the briefest possible pitch. The four sentence summary is for those who want more details. Both should be smooth and persuasive. People are busy. Why should they pay attention to you?

  • Your repo must be public.

  • We will look at (and grade) your code in conjunction with the Demo Day evaluation.

  • Give your repo and Shiny App a descriptive name. “Vaccine-Explorer” or “syrian_civil_war” is good. “Gov_1005_Final_Project” or “project_test” is not.

  • Apps should all have an “Info” or “About” tab which includes, your name, contact information, GitHub repo and data source information. Include other background information as you see fit.

  • Apps should “open” on an interesting tab, which will usually not be the “About” tab.

  • Apps should have at least one tab in which the user can select something and see a change.

  • Apps often have “story” tabs which, although they do not allow for user selections, do highlight specific aspects of the data which are interesting, and which users are unlikely to discover by themselves.

  • Projects must include a video of you providing a brief (approximately four sentence) elevator pitch about your project. Place the video in the About page.

  • Fill out the Final Project Spreadsheet accurately. Failure to do so will cost you two points.

David Kane
Preceptor in Statistical Methods and Mathematics
comments powered by Disqus