Send revisions to a student

When a plan needs more work, IDDT's revision workflow puts the plan back into revisions_requested and exposes your comments to the student. This article covers how to compose those comments so the student can act on them quickly, and how to use the Send revisions flow to batch your feedback into a single round-trip.

Anchor every comment

Open the plan in the inline review workspace. Every comment in IDDT must be anchored to a specific element — the whole plan, a single course card, or a single rationale paragraph. Drift between comments and the thing they reference is the leading cause of long revision loops; the anchor prevents it.

To anchor a comment:

1. Click the element you want to comment on. The element gets a soft focus ring.
2. Press c (or click Add comment in the comment thread).
3. Write your comment. Use the @-mention picker to tag a colleague if you want a second opinion before the comment goes out.
4. Click Save draft. The comment is now anchored and visible to you, but the student does not see it yet.

You can edit a draft comment at any time before you send. Drafts persist across sessions, so an interrupted review does not lose work.

Pick the right anchor

• A comment about a single course goes on the course card.
• A comment about a rationale paragraph goes on the paragraph.
• A comment about the plan shape, term layout, or pacing goes on the plan.

Anchoring at the wrong level is a common early-career mistake. A comment that says "this paragraph needs more detail" anchored to the whole plan is harder to act on than the same comment anchored to the paragraph itself.

Batch revisions into one send

Once you have written every comment you want to send, click Send revisions in the action bar. The dialog summarizes:

• How many comments will be sent.
• The status the plan will move to (revisions_requested).
• The notification the student will receive.

You can add a summary note above the comment list — one or two sentences naming the theme of the changes. Students consistently report that a summary note halves the time they spend reading the revision request.

Why batching matters

If you send each comment as a separate revision request, the student gets a notification, opens the plan, addresses the comment, re-submits, gets another notification, opens the plan again, and so on. A single batched send means one round-trip, one revision label in the version history, and one mental context switch for the student.

Language patterns that shorten loops

Comments that drive the shortest revision loops share three properties:

• Specific. "Move CSE 101 to spring" beats "rethink the fall sequence."
• Actionable. Phrase the comment as a verb the student can perform: "Add a sentence on the prior-learning narrative" rather than "this is underdocumented."
• Anchored. See the section above. Anchored comments do not need to repeat context the anchor already provides.

When you are unsure, ask yourself: "If I were the student, could I fix this without asking a clarifying question?" If the answer is no, add the missing detail before sending.

When to pick up the phone

For changes that require negotiation — a concentration title change, a credit transfer dispute, a thesis topic re-scope — drop a comment that names the issue and offers a 15-minute call. Trying to negotiate in the comment thread is slower for both parties. IDDT does not schedule the call for you, but the comment is the right place to propose it.

What to do next

When the student re-submits, you will see a new revision row in the version history and the comment thread updates with the student's replies. The audit history view shows every revision label so anyone joining the review later can catch up without reading the full thread.