Feedback isn't a task list. Until you make it one.

Comments come in three flavors. Actionable ("trim 0.5s off this beat"), ambiguous ("not sure about the music here"), and resolved ("nice fix on the transition"). In most tools, they all look identical: same gray text, same chronological order, same complete absence of structure.

So editors do the structure by hand. They copy comments into a Notion doc, mark them with emojis, cross out the done ones, and chase the ambiguous ones in Slack. It's a full second job, and they're bad at it because nobody trained them to be project managers.

Chronological order is the wrong order

A comment thread sorts by when someone typed, which is almost never the order the work should happen in. The note about a missing graphic in the last thirty seconds sits above the note that the whole second act needs restructuring, and restructuring the second act may delete the shot the first note was about.

Without state, the editor has to hold the dependency graph in their head, re-deriving it every time they reopen the project. That is the actual work being offloaded onto them: not reading the comments, but continuously re-sorting them.

What state actually unlocks

In Magpiie, every comment moves through five states: Open, In progress, Needs info, Resolved, Won't fix. The editor sees only what's actionable. The producer sees only what's blocked. The client sees their feedback being acknowledged in real time. Nothing gets lost. Nothing gets duplicated.

• Filter the player to show only "Open" comments. Edit head-down for an hour.
• Move resolved comments off the timeline so V2 review is clean.
• Flag ambiguous notes as "Needs info": the reviewer gets pinged for clarification.
• Every state change is logged. You always know what happened and when.

"Needs info" is the state most tools are missing

Open and Resolved are obvious. The one that changes behaviour is Needs info, because it gives the editor somewhere to put a note they cannot act on yet. Without it, ambiguous feedback either gets guessed at, which produces rework, or silently ignored, which produces the same note again on V2, now with more frustration attached.

Marking a comment Needs info turns a stall into a visible, assigned question. The reviewer is pinged, the editor moves on to work they can actually do, and the blocked item is still on the board rather than lost in a thread.

"The state system saved my Notion. I used to have a board for every project. Now I just open Magpiie and the work is the work."

The five states, and what each one prevents

State is not bureaucracy. Each one exists because a specific failure keeps happening without it, and it is worth naming the failure rather than the feature.

• Open prevents nothing on its own. It is the baseline every tool already has, and it is why comment threads feel like a wall of undifferentiated text.
• In progress prevents the duplicate chase. Without it, a client cannot tell the difference between a note being worked on and a note being ignored, so they ask again, and the asking costs you more than the fix.
• Needs info prevents the confident wrong guess. An editor faced with an unactionable note either stalls or guesses, and a guess costs an export and a round.
• Resolved prevents the re-read. Closed notes leave the active list, so the next pass is only what is still live rather than the entire history of the project.
• Won't fix prevents the zombie note. A decision made once and recorded stays made, instead of returning in round four as a fresh idea.

Read that list and the pattern is obvious: four of the five states exist to stop a conversation from happening twice. That is the actual product of structured feedback. Not tidiness, but the elimination of repeated conversations.

Category and priority are the other two axes

State tells you where a note is in its life. Two more attributes tell you what kind of thing it is, and both change how a round gets planned.

Notes carry a category, visual, audio, text, timing or graphics, so an editor can work in batches rather than ping-ponging between disciplines. Doing all the audio notes in one pass is materially faster than doing them in the order they arrived, and the order they arrived is chronological, which is to say arbitrary.

They also carry a priority: Must Fix or Suggestion. This one does quiet work on the relationship as much as the schedule. Reviewers without a volume control tend to either overstate everything or say nothing, and a Suggestion flag makes a small idea cheap to send and cheap to decline.

What structure gives you across a version

Once notes carry state, category and priority, useful questions become lookups rather than archaeology. How many notes did this round close. Which ones came back. What is still blocking. Who raised the thing we are arguing about, and when.

• Filter any draft by status to see only what you owe, which is the difference between a to-do list and a transcript.
• Reopen a resolved note if the fix did not land, on the new version, so the history shows it took two attempts.
• Count resolutions per round, which turns a scope conversation into an evidence conversation.
• Carry unresolved notes onto the next cut automatically, so nothing survives on memory alone.

Regressions are the case worth dwelling on. In a flat comment thread a fix that later breaks is invisible, because the note was closed and closed things are not re-read. With state, reopening is a first-class action and the record shows the round trip, which is how a team learns that a particular kind of note keeps failing the first time.

Common questions

Is this not just a task tracker bolted onto a video player? The difference is where the note lives. A task in a separate tool loses the frame, and the frame is the content of the note. Here the state sits on a comment pinned to a timestamp, a script line or a region of a thumbnail, so it never separates from the thing it describes.

Does every note need a state? In practice they get one whether you think about it or not, because the default is Open and closing something is one click. The discipline worth adopting is using Needs info instead of guessing, and Won't fix instead of silence.

Which plans have this? Frame-accurate comments and the state model are on every plan including Free. Activity logs and full revision history arrive on Studio Crew.

Rolling it out without a process document

Structured feedback fails when it is introduced as a policy. Nobody reads the policy, two people follow it for a week, and the comment thread reverts to prose. It works when the structure is the path of least resistance rather than an extra obligation.

The practical order is to start with the states internally and leave clients alone entirely. Your editors and producers can adopt Open, In progress, Needs info, Resolved and Won't fix without anyone outside the team noticing. Clients keep doing what they already do: click the frame, type, send. They never have to learn a vocabulary.

• Week one, use Needs info instead of guessing. This is the single highest-value habit, because it converts an expensive wrong export into a cheap question.
• Week two, start marking Won't fix with one sentence of reasoning. Silence is the alternative, and silence is what makes notes come back.
• Week three, filter by status before starting a session, so you work from what is open rather than from the top of the thread.
• Only then look at the counts per round. Numbers are useful once the states are honest, and meaningless before that.

One warning worth stating plainly: a state model people lie to is worse than none. If Resolved gets used to mean "I would rather not discuss this", the record becomes actively misleading and the trust it was supposed to build evaporates. Reopening a note has to be socially cheap for the whole thing to hold.

Done properly the effect is not that reviews feel more organised. It is that the same amount of feedback produces fewer rounds, because the ambiguity that used to require a round trip now gets resolved inside the note where it lives.