Two Creators Take Turns Reviewing: How Do You Turn "This Is Wrong" Into an Actionable Revision Ticket?
Turning "this is wrong" into a revision ticket has only one core action: make every piece of feedback land on the seven fields of version, node, symptom, expectation, reason, responsibility, and review. When two people take turns reviewing, each first fills out a ticket independently, then merges conflicting items, and only then touches the draft. Below, a fictional teaching example is used to walk through the whole process; the people, dialogue, and values are not actual test data.
Introduction
Turning "this is wrong" into a revision ticket has only one core action: make every piece of feedback land on the seven fields of version, node, symptom, expectation, reason, responsibility, and review. When two people take turns reviewing, each first fills out a ticket independently, then merges conflicting items, and only then touches the draft. Below, a fictional teaching example is used to walk through the whole process; the people, dialogue, and values are not actual test data.
First define one revision ticket shared by both people
A revision ticket is not literary criticism, but a handoff-ready work order. It is recommended to fix seven columns; if one column is missing, it does not enter the revision queue:
| Column | Filling requirement | Counterexample |
|---|---|---|
| Version | Branch or archive name plus date | "the latest version" |
| Node | Specific to the scene/interaction node number | "the middle part" |
| Symptom | The exact words the reader can see or read | "it feels wrong" |
| Expectation | What it should be changed to, judgeable by a third person | "more tension" |
| Reason | The connection to character goals, relationships, or context | "I just don't like it" |
| Responsibility | Who changes it, who does not look | "everyone looks together" |
| Review | How to verify after the change, who verifies | "look again" |
"Node" refers to an interaction unit in an interactive film-game that can be located individually, usually organized by tables, not a drag-and-drop canvas. Write the node number clearly so that both people are talking about the same place.
Fictional case: the same shot, two conflicting opinions
Set a fictional project Letters from Mist Harbor, branch mist-dev. In Act Three, node N-07, the apprentice courier played by the player must return a returned letter to the old ship doctor. The current original text is:
The old ship doctor took the letter, smiled, and said: "Put it on the table, I'll look at it later."
Reviewer A (responsible for the character line) fills out a ticket:
- Version: mist-dev 10-04
- Node: N-07
- Symptom: "smiled" conflicts with the old ship doctor's established setting that "after losing his apprentice, he no longer opens letters in person"
- Expectation: change it to him pushing the letter back and saying "this one should not be delivered by you"
- Reason: his goal is to avoid old matters; pushing it back fits avoidance better than accepting it
- Responsibility: A changes the text
- Review: B reads it once and confirms no new past events were added
Reviewer B (responsible for interaction pacing) fills out a ticket:
- Version: mist-dev 10-04
- Node: N-07
- Symptom: the player has just experienced a long escort, and here the line "Put it on the table" makes the choice lose weight
- Expectation: keep the action of receiving the letter, but let the player first choose "explain the purpose" or "silently hand over the letter"
- Reason: the two options correspond to different relationship states, and the player can feel that their choice is caught
- Responsibility: B changes the node options
- Review: A confirms that neither option violates the character boundary
Both tickets are compliant, yet they directly contradict each other on "accept the letter or push it back." At this point, do not change half each.
Handling rules: resolve the conflict first, then touch the draft
Conflicting opinions are handled in order, without skipping steps:
- Align the version. Confirm that both people are looking at the same
mist-dev 10-04. If one person is looking at an old archive, void that ticket first. - Separate facts from preferences. "Push back" is connected to an already written character setting and belongs to the fact layer; "the choice loses weight" belongs to the experience layer. When both layers hold, the fact layer takes priority as a constraint, and the experience layer is implemented within it.
- Find the smallest shared change. The merged result is: keep the push-back action, and make "explain the purpose/silently hand over the letter" the two options before pushing back. In this way the character is not broken, and the pacing is also supplemented.
- Assign a single responsible person. The text is changed by A, and the node options are changed by B; neither crosses the line to change the other's column.
- Write the review method. Review is not "look again," but a specific action: A reads the full text of N-07 aloud and checks sentence by sentence whether any past event not provided appears; B walks through both options and confirms that both can enter the next node.
If after two steps there is still a conflict, suspend both opinions and mark them "pending," and do not enter revision. Suspending is safer than forcing a merge, because forcing a merge often turns the character into something unrecognizable.
The merged revision ticket looks like this
| Version | Node | Symptom | Expectation | Reason | Responsibility | Review |
|---|---|---|---|---|---|---|
| mist-dev 10-04 | N-07 | "smiled" conflicts with the avoidance setting; a single line of receiving the letter makes the choice weightless | Push the letter back, and provide two options before pushing it back | The fact layer constrains the character, the experience layer supplements pacing | A changes the text, B changes the options | A checks past events, B walks both options |
Note that the "Reason" column writes connections, not verdicts. It lets a third person judge whether the change crosses a boundary, rather than endorsing the reviewer.
After the change, downstream needs manual verification
Changing the N-07 text and options belongs to changing the node. According to the current project implementation, related completed previews and exports will be marked "needs update," and old data is retained. Creators should verify whether the old preview's text still holds and whether the new export includes the revised content. If this feedback also changes actions in the video, the corresponding clip should be listed separately and must not be hidden inside a sentence like "the node has been changed."
There are two types of export: the local asset package localAssets contains assets, a player, and an instruction file; run it according to the instructions and check it offline; the remote link package remoteUrls is accessed through a stable entry point under the application domain, depends on the network and services, and is not a guarantee of permanent resources. localhost on someone else's computer points to their own machine and cannot be sent to teammates as a universal address. Being able to unpack the compressed package does not mean playability has been verified.
Completion check
A revision ticket can enter revision if and only if all seven columns are complete and the following are satisfied:
- The symptom column can cite the original words or a specific node;
- The expectation column can be independently judged by a third person as achieved or not;
- The reason column points to character settings or context, not personal taste;
- The responsibility column has only one changer;
- The review column is an action, not an attitude.
When two people take turns reviewing, it is recommended to handle only conflicts on the same node in each round, and then open the next node after handling is complete. This article is organized by DramaFork and explains according to the current project implementation; document collaboration has no promise of real-time simultaneous editing by multiple people, and two people can hand off in the above order.
Before the next review, first fill all seven columns separately, then meet and talk only about the conflicting cell.
