Sub-tasks & chunked assignments
Break one assignment into ordered parts with optional per-part due dates — still one submission. When to chunk, how the student checklist behaves, and what happens when you edit parts after publishing.
- What sub-tasks are
- Chunk vs. split into separate assignments
- Adding parts in the modal
- Per-part due dates & ordering
- Optional vs. required (it's all optional)
- The student's progress view
- Marking a part done — self-mark only
- How parts interact with the submit gate
- Sub-task progress matrix (teacher overview)
- Editing parts after publishing
What sub-tasks are
A sub-task is one named, ordered part of an assignment. Still one set of instructions, one rubric, one due date, one submission row.
The bullet points you'd write on the board: Part 1: pick your passage. Part 2: outline. Part 3: full draft. Part 4: peer-review pass. Each can carry an optional due date and description. Students see a checklist.
Shape: id, title, optional description, optional dueAt, orderIndex. No separate submission row — completion tracks on the one submission by sub-task id.
Chunk vs. split into separate assignments
The alternative: separate assignments — "Outline", "Draft", "Final" — each with its own submission, rubric, grade.
Chunk when…
- The end product is one piece — parts are scaffolding, not deliverables
- You want one grade
- The student keeps working in the same document part to part
- You want a single provenance recording for the whole arc
Split when…
- Each stage is graded independently with its own LMS column
- Stages live in different docs — outline in planning, draft in a new one
- There's a real gate — Stage 2 hidden until you sign off on Stage 1
- Different students see different things at each stage
Default to chunk. Seven "stage" assignments are harder to skim than three with sub-tasks inside.
Adding parts in the modal subTasks
In the assignment modal, scroll to Sub-tasks (below targets, above rubric). Add part. Three fields:
- Title — short, no "Part 1:" prefix (numbering is automatic).
- Description — one or two sentences. Often the title is enough.
- Due — optional per-part date.
↑ / ↓ reorder, × removes. Arrow-only — not yet draggable.
No hard cap. Six or more usually means you've split the work too far.
Per-part due dates & ordering
Per-part Due is a soft deadline — a pacing signal, not a gate. Shown on the student checklist and the teacher preview.
Order comes from orderIndex. Arrows re-stamp indices. Deleting a middle part shifts below up — no numbering gap.
Per-part dates have no relationship to the overall dueAt. Late-work logic only looks at the assignment-level date.
Optional vs. required (it's all optional)
Every part is optional. Check off in any order, skip any, submit. The checklist is self-tracking, not a gate.
To require a part, put it in the rubric. A criterion like "Used direct evidence from the passage at least twice" shows up at grade time.
No per-part submit. One Submit for the whole assignment.
The student's progress view
A Parts section above the rubric. Each part: status circle left, title and due right, description below.
Three states:
- Empty circle —
not-started - Half-filled —
in-progress - Filled with check —
done
Done parts get a strikethrough. No save button — re-renders on toggle. No sub-tasks → no Parts section.
Marking a part done — self-mark only
Clicking the circle cycles not-started → in-progress → done → not-started. No "Mark done" button, no confirm, no batch.
Each click hits submissions.markSubTaskStatus and upserts onto subTaskCompletion. The first toggle creates the submission row lazily — students can track before writing.
No auto-mark — Red Stet doesn't infer Part 2 is done because the student typed 300 words. Status flips only on click.
completedAt. Stamped on done, cleared on flip-back. Drives the "Completed Jun 4" line.
How parts interact with the submit gate
Sub-tasks don't gate submission. Submit works with every part marked Not started.
To require completion, put it in the rubric (graded) or instructions (prose).
Submit gates:
- Document has content
- Attempt cap not reached
- Required reflection answered
- Latest assignment version acknowledged
Sub-task progress matrix (teacher overview) submissions.subTaskCompletion
Submissions toolbar → Sub-task progress opens a matrix: rows are students, columns are parts in checklist order, cells are status pills.
Values come from each submission's subTaskCompletion. Read-only — these are the students' own marks.
Sticky first column anchors the student name on horizontal scroll.
Reading at a glance
Green = done, amber = in-progress, grey = untouched. All-green row: self-marked everything. All-grey row: hasn't opened the checklist. All-grey column: that part isn't landing — wrong order or unclear instruction.
Doesn't gate. Students don't see it.
Editing parts after publishing
Add, remove, rename, reorder, re-date any time — even after students have started.
Sub-tasks are student-facing, so editing is substantive: currentVersion bumps, the old shape snapshots into versionHistory, every enrolled student gets the "your teacher updated this assignment" banner. Submit is gated until Acknowledge.
Version history flags Sub-tasks on change. Students can open old versions.
Removing a part students checked off
The completion record stays on the submission but stops rendering. Nothing is deleted.
Related
→ Creating an assignment — every field of the New Assignment modal.
→ Returning work & revision cycles — the submit gates; sub-tasks aren't one of them.
→ Grading submissions — rubric and weighting.
Missing something? Email feedback.