You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The guide was brought back in line with the app for 1.0 (#297) and its screenshots retaken (#298). The batch tracked in #309 changes what the app says and does around tickets, patches and trunk — so several pages go stale the moment it lands, and they go stale quietly: nothing in them will look wrong to a reader who has not used the new build.
What the pages will be describing that is no longer true
applying-patches.md — when a patch or pull request will not apply, the guide explains it the way the app used to: the change is behind trunk and its author owes a rebase. That is now one of two answers, and the other one is the contributor's own work being in the way (A patch that fails because of your own work is blamed on the PR author #303). The page should teach the difference, because the two have different next steps and only one of them involves another person.
ticket-branches.md — what a ticket is measured against. The warning before applying now reports what the ticket has that its base does not (The patch conflict warning measures against the wrong baseline #301), which is what the rest of the patch flow always measured. A ticket resumed after a switch is no longer described as clean.
trunk-updates.md — updating brings the site up to date and deliberately leaves ticket branches where they were born. The guide should say so plainly, and say what to do about a ticket that is behind, rather than leaving a reader to infer that updating covers it.
troubleshooting.md — the entries about patches that will not apply, and about work that seems to have vanished, are written against the old explanations.
What this issue is asking for
Bring those pages in line with the shipped behaviour, and write them from the built app, not from the pull requests — install the artifact from the v1.0-rc2 branch (draft #312), walk the workflow in #309's testing script, and describe what actually happens. A guide written from a diff describes what someone intended.
Screenshots follow the same rule: retake only the ones whose surface actually changed, from the same build.
Best done once the batch has settled rather than page-by-page as each pull request lands, so the guide is rewritten against one coherent build instead of five intermediate ones.
The guide was brought back in line with the app for 1.0 (#297) and its screenshots retaken (#298). The batch tracked in #309 changes what the app says and does around tickets, patches and trunk — so several pages go stale the moment it lands, and they go stale quietly: nothing in them will look wrong to a reader who has not used the new build.
What the pages will be describing that is no longer true
applying-patches.md— when a patch or pull request will not apply, the guide explains it the way the app used to: the change is behind trunk and its author owes a rebase. That is now one of two answers, and the other one is the contributor's own work being in the way (A patch that fails because of your own work is blamed on the PR author #303). The page should teach the difference, because the two have different next steps and only one of them involves another person.ticket-branches.md— what a ticket is measured against. The warning before applying now reports what the ticket has that its base does not (The patch conflict warning measures against the wrong baseline #301), which is what the rest of the patch flow always measured. A ticket resumed after a switch is no longer described as clean.trunk-updates.md— updating brings the site up to date and deliberately leaves ticket branches where they were born. The guide should say so plainly, and say what to do about a ticket that is behind, rather than leaving a reader to infer that updating covers it.troubleshooting.md— the entries about patches that will not apply, and about work that seems to have vanished, are written against the old explanations.What this issue is asking for
Bring those pages in line with the shipped behaviour, and write them from the built app, not from the pull requests — install the artifact from the
v1.0-rc2branch (draft #312), walk the workflow in #309's testing script, and describe what actually happens. A guide written from a diff describes what someone intended.Screenshots follow the same rule: retake only the ones whose surface actually changed, from the same build.
Best done once the batch has settled rather than page-by-page as each pull request lands, so the guide is rewritten against one coherent build instead of five intermediate ones.
Related: #309, and the pull requests it tracks.