STA 9750 - Mini Projects

In lieu of traditional homework, STA 9750 has a series of mini-projects designed to achieve several interlocking goals:

Improve your skills at data analysis
Improve your ability to give feedback on data analysis work
Seed a ‘portfolio’ of data science work you can demonstrate to potential employers

Each Mini-Project will be submitted via GitHub, an industry-standard code management platform, as both raw analysis code and as a HTML document hosted on GitHub pages.

After each Mini-Project is submitted, 2-3 peer reviewers will be assigned to give feedback and to assign an initial grade following an instructor provided rubric. This feedback will be given via GitHub Issues.

In order to ensure good peer feedback, the peer feedback will be evaluated by the instructor in a “meta-review” worth a small fraction of the overall grade.

If you believe your mini-project has received inaccurate peer feedback, please request a regrade from the instructor directly within 48 hours of the peer feedback deadline using the relevant form on Brightspace. No student-initiated requests for re-grading will be accepted after that time, though the instructor may re-grade the work during the meta-review stage.

Mini-Projects

Mini-Project #00: Course Set-Up

Due Dates:

Released to Students: 2025-08-26
Initial Submission: 2025-09-12 11:59pm ET
Peer Feedback:
- Peer Feedback Assigned: 2025-09-15
- Peer Feedback Due: 2025-09-22 11:59pm ET

In the ungraded Mini-Project #00, there is no data analysis required, but you will set up the basic web tooling used to submit projects #01 to #04.

Note that, even though ungraded, Mini-Project #00 must be completed to remain enrolled in this course and before any other Mini-Projects can be submitted.

Mini-Project #01: TBD

Due Dates:

Released to Students: 2025-09-16
Initial Submission: 2026-10-03 11:59pm ET
Peer Feedback:
- Peer Feedback Assigned: 2026-10-06
- Peer Feedback Due: 2026-10-13 11:59pm ET

In Mini-Project #01, TBD.

Mini-Project #02: TBD

Due Dates:

Released to Students: 2025-09-30
Initial Submission: 2025-10-24 11:59pm ET
Peer Feedback:
- Peer Feedback Assigned: 2025-10-27
- Peer Feedback Due: 2025-11-03 11:59pm ET

In Mini-Project #02, TBD.

Mini-Project #03: TBD

Due Dates:

Released to Students: 2025-10-21
Initial Submission: 2025-11-07 11:59pm ET
Peer Feedback:
- Peer Feedback Assigned: 2025-11-10
- Peer Feedback Due: 2025-11-17 11:59pm ET

In Mini-Project #03, TBD.

Mini-Project #04: TBD

Due Dates:

Released to Students: 2025-11-04
Initial Submission: 2025-11-21 11:59pm ET
Peer Feedback:
- Peer Feedback Assigned: 2025-11-24
- Peer Feedback Due: 2025-12-01 11:59pm ET

In Mini-Project #04, TBD.

Mini-Project Submission

All Mini-Projects must be submitted in two formats:

As a suitable HTML page hosted on the student’s course repository. (See Mini-Project #00 for details on setting this up.)
As a PDF on the course Brightspace page.

Both submissions must be completed on time for the work to be considered properly submitted.

If the work is submitted on Brightspace by the deadline, but not on GitHub, the instructor will apply a 5-point penalty (10% deduction). Additionally, work not submitted on GitHub will not be eligible for peer review, but will instead by evaluated by the course staff. (Note that, historically, the instructor and TAs have been more stringent graders than student peers.)

GitHub submission will be confirmed when the instructor assigns peer feedback reviewers. The course helper functions include a script. to confirm that a GitHub submission has been properly formatted. You are encouraged to use it.

For example, if I wanted to confirm my MP03 was properly submitted, I would run:
```
source("https://michael-weylandt.com/STA9750/load_helpers.R")
mp_submission_verify(3, "michaelweylandt")
```
Submissions that do not pass these automated checks will have a penalty applied.
If the work is submitted on GitHub, but not on Brightspace, the instructor will assign a 5 point (10%) penalty. Note that this will be applied by the instructor when loading grades into Brightspace; peer evalutors will not need to confirm correct Brightspace submission.
If the work is not submitted on time on either platform, the course late work policy applies and no credit will be given.

Mini-Project Submission Grace Period

This semester, all Mini-Projects are officially due on Friday evenings. Recognizing that students have conflicts outside of classes, I am providing an automatic two day grace period (to Sunday evening) for all mini-project submissions. Per the late work policy, extensions beyond this grace period will only be provided under exceptional circumstances.

Note, however, I will not be responding to student inquiries after the original (Friday) deadline. You are strongly encouraged to ask all questions and resolve all technology issues before the Friday deadline.

Note that students are still expected to participate in the peer feedback cycle even if their own submission was not completed on time. Difficulty with the technologies used (Brightspace, quarto, GitHub, etc.) is not a recognized excuse for late submission.

Mini-Project Peer Feedback

The peer feedback cycle is an important element of the STA 9750 learning goals. In particular, the peer feedback activities are used to help students learn to read code written by others and to compare and contrast alternative approach to the same analytic aims. As emphasized throughout this course, there is rarely a single right way to perform a particular piece of analysis, but there are better and worse; seeing a variety of approaches helps students experience a variety of approaches and begin developing a sense of elegance and efficiency in code.

Mini-Project peer feedback is submitted as comment on the GitHub issue used to submit individual projects. Once the mini-project submission deadline passes, the instructor will tag multiple students in the same issue and request peer feedback. Tagged students (“evaluators”) should give their feedback in that same issue, not opening a new issue. (This is important to keep course materials organized.)

Peer feedback comments should use the following format:

## Scores 

- Written Communication: NN 
- Project Skeleton: NN
- Formatting & Display: NN
- Code Quality: NN
- Data Preparation: NN
- Extra Credit: NN

## Comments

### Written Communication

TEXT TEXT TEXT

### Project Skeleton

TEXT TEXT TEXT

### Formatting & Display

TEXT TEXT TEXT

### Code Quality

TEXT TEXT TEXT

### Data Preparation

TEXT TEXT TEXT

### Extra Credit

TEXT TEXT TEXT

For each element, the NN should be replaced by a numerical value between 0 and 10. (It is not necessary to provide a sum; the instructor will calculate this.) Similarly, the TEXT TEXT TEXT should be replaced by comments justifying the assigned score. Not all mini-projects have opportunities for Extra Credit, but please leave those blocks in place (perhaps saying “No extra credit available” for the comment) so the course backend automation works properly.

The course helper functions can be used to verify that you have submitted a comment with the correct formatting.¹

Peer Grade Required for All Assigned Work

Please note that you are required to provide a peer grade for all mini-projects to which you have been assigned, even those where no submission can be found. Please use the template above and assign 0s for all elements. Text feedback should also be included, but it can be as simple as “No submission found.”

After the peer feedback cycle, the instructor will collect peer feedback grades and assign “meta-review” feedback to each student. Meta-review feedback refers a grade based on the quality of your commentary. The following rubric will guide assessment of meta-review grades, but the instructor may deviate as appropriate.

Note that the rubric is a bit asymmetric: students need more detailed feedback on poor work – giving them an opportunity to improve – than on strong work. Here the rough “strong” vs “weak” distinction is qualitative and will be assessed by the instructor independently as part of meta-review grades.

Meta-Review Rubric
Score	Quality of Submitted Work	Quality of Feedback	Comments
9-10	Strong	Quality Positive Feedback
TBD	Strong	Quality Negative Feedback	Addressed on a case-by-case basis.
7-8	Strong	Minimal Positive Feedback
5-6	Strong	Minimal Negative Feedback
4	Strong	No Feedback
4-5	Weak	Quality Positive Feedback
9-10	Weak	Quality Negative Feedback
4-5	Weak	Minimal Positive Feedback
6-8	Weak	Minimal Negative Feedback
3	Weak	No Feedback

Footnotes

As of now, GitHub does not allow pre-filling a comment body via URL, so I can’t provide a helper script to template the peer review comment for you.↩︎