ta-grading-rubric

name	ta-grading-rubric
description	Use when creating a grading rubric for TAs from a lab assignment README or description. Produces a score sheet, grading workflow with short-circuits, and condensed criteria tables optimized for grading many submissions efficiently.

TA Grading Rubric

Overview

Rubrics for TAs grading at scale have two jobs: help TAs grade consistently, and help them grade fast. A rubric that requires reading long prose for every criterion is a reference doc, not a grading tool.

Core principle: The score sheet is primary. Everything else is reference.

Structure (in this order)

1. Score Sheet

A copyable ASCII form at the top of the file — one copy per student. Fields use _/n format. Group by section with subtotals and a final total. Include an integrity flags block with checkboxes.

Student: ___________________________  GitHub: ___________________________

SECTION NAME                                                        /pts
  Sub-item ..................................................... _/pts
  Sub-item ..................................................... _/pts
                                              Subtotal: ___/pts

                                              TOTAL _____________ /60

EXTRA CREDIT (only if attempted)
  Item ......................................................... _/pts
                                          EC TOTAL _____________ /pts

INTEGRITY FLAGS (escalate to instructor — do not deduct yourself)
  [ ] Flag description
  [ ] Flag description

Notes: _________________________________________________________________

2. Grading Workflow

Numbered steps in the order TAs should actually do them — most objective first, most reading-intensive last. Each step has a time estimate in parens. Short-circuits call out when to skip downstream work.

Canonical step order:

1. Verify the primary artifact (patch, binary, output file) — objective, 2 min
2. Run/open the submission for a single-pass visual/functional check — covers most content sections at once
3. Spot-check documented values against the artifact — cross-reference writeup
4. Read prose sections (writeup, analysis, reflection) — most subjective, last

Short-circuit pattern: "If X → Y is automatically 0. Skip to step N."

3. Criteria Reference

One subsection per score-sheet line item. Each uses a tight table:

Score	Criteria
max	Full credit description (one line)
mid	Partial credit (what's missing or broken)
0	Not submitted / unchanged / completely wrong

Rules:

• Max 4 rows per table. Two rows (full/zero) is fine for binary items.
• One sentence per row. No paragraphs.
• TA-facing notes go in bold below the table, not inside it.

4. Academic Integrity Flags

Bullet list of observable signals to escalate to the instructor. Never tell TAs to deduct for these — they require instructor judgment.

The most reliable flag: the primary artifact and the documentation tell inconsistent stories. (E.g., patch applies cleanly but writeup has no matching hex offsets.)

5. Quick Reference

Shell commands TAs actually need, copy-paste ready. Keep to under 10 lines total.

6. Generating Output Files

After the rubric markdown is complete, generate distributable files.

DOCX (primary — for Google Docs / TA distribution):

pandoc rubric.md -o rubric.docx

PDF (optional — requires Ungoogled Chromium via Flatpak; TeX fonts are broken in this environment):

pandoc rubric.md -o rubric.html --standalone --embed-resources
flatpak run io.github.ungoogled_software.ungoogled_chromium --headless --disable-gpu --print-to-pdf=/tmp/rubric.pdf "file://$(pwd)/rubric.html"
mv /tmp/rubric.pdf rubric.pdf

Notes:

• DOCX is the primary output — what TAs actually read and share.
• The PDF path uses file://$(pwd)/rubric.html (absolute) to prevent Chromium from treating a relative path as a URL.
• --embed-resources makes the HTML self-contained before Chromium renders it.

---

Point Allocation

When given a total point value and an assignment description:

1. Identify the primary artifact (the thing that proves they did the work). Weight it highest within deliverables — typically 40–50% of the deliverables section. It is the most objective check and the strongest authenticity signal.
2. Group gradable items into 3–5 sections. Typical: Deliverables, Content Changes (subdivided by type), Writeup/Analysis.
3. Within sections, weight items by effort and verifiability. Items that are easy to fake or skip get less weight; items requiring deep understanding get more.
4. Extra credit scales proportionally: if the assignment states "X% extra credit," multiply X% × total points.
5. Keep sub-item point values to whole numbers. Fractional points create friction at scale.

Criteria Writing

Each criterion should answer: what does the TA see or check to assign this score?

Do:

• Name the specific thing to look at ("still reads 'PIKACHU'", "md5 of output matches submitted file")
• State what's missing for partial credit ("one or two values unchanged")
• Make the 0 case unambiguous ("not submitted", "unchanged", "crashes")

Don't:

• Write paragraphs — TAs won't read them mid-grading
• Use hedging language ("may", "might", "could be")
• Repeat the assignment spec — link or quote minimally

Writeup / Reflection Sections

These are the hardest to grade consistently. Two rules:

1. Reward specificity, not length. A 4-point reflection criterion should say explicitly that padding earns 0–1 and specific, grounded connections earn full credit. Give a concrete example of what full credit looks like.
2. The lowest score band should name the failure mode ("Restates the README's own comparison table without original insight" is more actionable than "poor quality").

Example

See /home/anthony/git/cecs-378-lab-malware-pokemon/rubric.md for a complete worked example. It was generated from the assignment README at a 60-point scale with 9 points of extra credit.