Peer feedback guidelines for Project 3 (15% of project grade)

Provide feedback about the following topics:

  1. Is the project organized modularly, with Make as the workflow manager?
  2. Does the project use both Python (Pandas specifically) and R (Tidyverse specifically) scripts?
  3. Is Docker used to define execution environments appropriately?
  4. Are the plots appropriate for the data types, the hypotheses being tested, and the points being communicated?
  5. How can the project be organized or documented more clearly?
  6. Is the purpose of the project communicated clearly?
  7. Does the purpose of the project make sense from the client’s point of view? How could the project better serve the client?
  8. Is the source of the data made clear? (Remember that this project can be part of your public portfolios, so people not familiar with UMD may see it).
  9. Is the interpretation of figures clearly explained?
  10. Is the purpose and interpretation of analysis steps clearly communicated?
  11. Are overall take-home messages clearly communicated?

Keep in mind the qualities of good feedback (as described in the rubric for project 1).

Feedback should address the code organization (see Grader rubric below) and written communication (see Presentation rubric below). Help your classmates succeed.

Late project drafts will lose 25% of final grade (you need to upload your draft on time so that your peers can give you feedback). Late feedback will not receive a score. You may receive peer scores but they will not be recorded. Students who submit late feedback scores, or who fail to return feedback scores, will lose 10% per set of scores on their own project. Your peers need your scores for their final grades.

Feedback rubric (to be used in scoring the feedback you received from peers)

Points Description
7 Feedback was specific – you know exactly what to improve, and what you did well
6 Feedback was “meta” – the feedback went beyond finding typos to helping you with higher-level improvements
2 Feedback was respectful and optimistic – you feel helped and encouraged after reading the feedback

Grader rubric for Project 3 (35% of project grade)

Points Description
5 Code structured – code is on Github, includes a README, and is organized modularly, with Make as the workflow manager
5 Docker – Docker is used to define execution environments
5 Python and R – the project uses both Python (Pandas) and R (Tidyverse) scripts
5 Code commented – code is commented and readily understood by the grader
10 Code works – by running the appropriate make target on the VCL, everything works on the first try. No points if the make target is not documented in the README or anything fails when it is run (the grader will not have time to de-bug).

Presentation rubric for Project 3 (50% of project grade)

Points Description
20 Background – background and purpose is clearly stated, particularly how the project serves the client
15 Data cited – sources of data are clearly stated
15 Figure Interpretation – how to read figures is clearly explained (e.g. what axes mean). The figures are appropriate for the data type, the hypotheses being tested, and the points being communicated
25 Analyses explained – purpose and interpretation of analyses is clearly described
25 Conclusions clear – main conclusions are unambiguous