Group release notes by the user's task

Do not rewrite the release record until it loses its connection to the implementation facts. Give each item a stable label, then create a second view organized by task. The labels let a reviewer check that a new story has neither dropped a condition nor combined two changes into an unsupported capability.

A task should include a verb and an object: prepare a review packet, find a prior revision, or resolve requested changes. Labels such as “productivity,” “collaboration” and “improvements” are too broad to guide a scene sequence.

• Record the original item and its approved scope.
• Name the user task it changes.
• Describe the moment within that task where the change matters.
• Keep dependencies, availability and exceptions attached to the original item.

Suppose an illustrative release list is organized by component: A, file panel now pins a selected revision; B, link dialog lets a member label a review link; C, history search accepts a revision tag; D, comment panel can show unresolved comments only; E, notification settings receive clearer explanatory copy. These items are fictional planning material.

A component-based video would jump between panels. A task-based plan first asks which changes belong to a coherent piece of work. The mapping below changes the narrative order without claiming that the features are one automatic workflow.

• Prepare a review packet: A helps select the revision to present; B helps identify the review link. These support one preparation task, provided their relationship is verified.
• Find the context for a requested change: C helps locate a tagged revision; D helps isolate unresolved discussion. Treat these as separate aids unless the product actually connects the views.
• Understand notification choices: E explains a setting. Keep it as a written note or separate brief unless notification decisions are part of the selected story.

Choose “prepare a review packet” as the lead. A useful sequence begins with the question of which revision is being reviewed, shows the supplied pinning behavior, and then labels the review link. The conclusion can say that the packet identifies its revision and purpose. It cannot say that reviewers always open the correct version unless that outcome is supported.

Draft scene notes: “Hold on the selected revision and its visible identifier. Show the approved pin action. Move to the link dialog, retaining the same revision identifier as context if the verified product does so. Enter the supplied link label. End on the resulting link summary.”

This is an outline, not proof that the two controls share state. If the pin only changes a private file-panel view while the link resolves independently, separate the claims and show the additional version selection needed. Narrative convenience must not erase a real product boundary.

A tagged-history search might help both preparation and revision work. Give it one primary home based on the clearest user question. Cross-reference it in another asset only if the second explanation teaches a different decision. Replaying the same search scene in every group dilutes the purpose of each video.

An item left outside the lead story is not a failure. Keep it in the release notes, assign another format, or postpone video treatment until its task is clearer. The grouping exercise should reduce arbitrary transitions, not force every shipped item into one storyline.