Work in a Patch
Sources
Docs: Personal work Web App: Open Publish and select the active Patch, or begin editing a published composed Parable when you have Publishing or Primary. A Patch is a reviewable set of changes to a Parable. It keeps Pages, Panes, Plots, meaning, configuration, styling, and governance changes together while the current published version remains intact. Removing an inherited Piece is a real change. After publication, it stays removed from that Workspace while older published versions retain their original content. Unchanged upstream Pieces continue to read through. An edit saved back to what the Parable already has leaves the Patch: a Plot whose SQL is put back is no longer listed.Read a Patch’s Changes
The Changes list shows what the selected Patch adds, changes, or removes compared with the Release it lies over. When another Patch publishes, each Proposed Patch that has no conflict moves onto the new Release. Its Changes still show only its own work, not the work brought in by that Release. For example, Patch A adds a Page and Patch B adds a different Page. After Patch A publishes, Patch B’s Changes show only the Page that Patch B adds and its Palette. Publishing Patch B applies those changes over the new Release. A Published Patch’s Changes stay tied to the Release it lay over. If a copy did not record that source Release, its Published Patch keeps its existing Changes display.Open a link to a Patch or a Release
A link that names a Patch or a Release that this Workspace does not have opens what an address without it opens, most often Newest. A link to a colleague’s Pocketed Patch does the same. A notice says what the link asked for and what opened, for example “That Release is not in this Workspace. You are reading Newest (v1.4).” The notice shows once for each link.Keep one outcome together
Use one Patch for changes that share an outcome and review path. Open another when the outcome, the people with Publishing or Primary, or Release timing differs. A smaller coherent Patch is easier to explain, prove, review, and restore than a collection of unrelated edits. A Patch you start in a Ponder Problem belongs to that Problem. Each Problem holds at most one Patch, so the Problem names the outcome its Patch is for. You can hold several Patches at once, one for each Problem you work in. Every Patch belongs to a Problem. A Patch that starts outside a Problem, such as a Pull, a Patch that a Versioned setting’s save opened, or a Patch opened through the API without a Problem, starts in a new Problem under the Parable’s root Problem. A Parable’s root Problem holds no Patch of its own. The Release menu shows the Patches as the Problem tree (see Release and Refresh). A Problem takes no new Patch after its Patch is Published. A request for one gets this answer: “This Problem’s Patch is Published. Start a Problem under this one for your next change.” A Patch always shows the name of the person who started it. A Patch that a Problem holds is shared by the people who work in that Problem. If you are in Publishing or Primary and can see the Problem, you can edit, prepare, propose, patch, pocket, restore and delete its Patch, as the person who started it can. A Pocketed Patch in a Problem that Parable started for it, such as a Pull or a Patch saved outside Ponder, can be restored, deleted, or exported only by the person who started it. In Peeking and Pinging you only read it. For a change of your own beside a colleague’s Patch, start a Problem under theirs. Your Patch then belongs to that Problem. A child Problem’s Patch starts from the newest Release, not from its parent’s Pending Patch, and it publishes on its own. When a Release changes a Piece that an open Patch also changed, that Patch collides. It cannot be proposed, and its message names the Release and the Pieces, for example “v1.4 changed the same Pieces as this Patch: the Page “Sales”. Pocket this Patch, then start a new one from v1.4.” A Piece is named by its type and its handle, when it has one. Code is the exception. Source protection can hide a Piece’s code from a person, and every person reads the same message. So code of every kind (a Page’s or Pane’s code, a Plot’s SQL, a formatted Page’s content and images) reads “the code”, once, with no Piece and no language. When a Page and its code both collided, the message says “the code and the Page “Sales"". Pocket it, then start a new Patch from that Release. No Patch starts by itself. Opening a Parable, or switching it to Publishing, starts none. A Patch starts at your first change, at Start Changes, or when Ponder makes an edit in a Problem. Start Changes works in the Problem open in Ponder. In the root Problem, or in a Problem whose Patch is someone else’s or no longer Pending, it asks for a New Problem first. The Patch then starts in the new Problem.1
Describe the outcome
Give the Patch’s Problem a name, a description and an icon a person with Publishing or Primary
can recognize.
2
Make and preview changes
Edit the relevant Pieces and inspect the complete affected experience.
3
Resolve failures
Correct invalid data meaning, unavailable dependencies, visual regressions,
or access issues before asking for publication.
4
Explain the result
Tell the people with Publishing or Primary in the Problem what you checked. The Proofs that the Patch
must pass come from the Proofs Platform Parable, not from its Problem.
5
Propose
Propose the Patch when it is ready for a person with Publishing or Primary.