Milestones, cycles & triage

Group work toward a date, run it in fixed-length iterations, and hold arrivals at the door.

Three features for planning a project's work, each optional and each invisible until you use it.

Milestones

A milestone is a named, dated bucket of tasks — "1.0", "Q3 billing rewrite". Create one from the Milestones screen with a name, an optional description, a colour, start and target dates, and a lead — the person to ask about it. A lead is answerable for the milestone, not for its tasks: nothing is assigned to them.

Open a milestone to see what is in it. It shows the board narrowed to that milestone, grouped by status, with its progress, its target and its lead above — so "what is left before 1.0" is one press from the plan. Its own form is the pencil on that screen.

A milestone moves through planned, started, paused, completed, or canceled, and shows progress derived from the tasks in it — summed points when your project uses an estimate scale, counted tasks when it does not. So a project that never estimates still gets a progress bar.

Tasks imported from another tracker land in milestones matched by name, so a Jira version or a Linear project comes across as one.

Saying how it is going

A progress bar says how much is finished. It cannot say whether that is good enough — a milestone at 90% a week before its date is in trouble if the last tenth is the hard part. So a milestone takes updates: a health (on track, at risk, off track) and, if you have something to say, a line about what changed and what it means for the date.

The words are optional. A weekly "on track" on its own is a real answer, and asking for a paragraph is how the week nobody had time for becomes the week with no update at all — which reads exactly like a milestone going fine. For the same reason every open milestone says when it was last written about, or "No updates yet".

The latest update's health rides on the milestone's row, and the history keeps the rest: "at risk, waiting on the vendor" three weeks ago and "on track" today is a story, which one overwritten field is not. Each update also keeps the progress figure as it read when it was written — and that figure came off tasks your runs actually moved, not from somebody typing 60%.

You can take back an update you wrote; an admin can take back anyone's. Nobody is emailed about one.

The whole organization, on one axis

A milestone belongs to one project. Timeline — under your organization on the dashboard, and under each organization in the phones' and the Mac's project list — puts every project's milestones on one time axis, for the person who is not inside any one repo and wants to know what is shipping and roughly when.

It reads top to bottom: what is overdue first, then a band per month something is due in, then anything nobody has dated, then what is finished — collapsed, because "whatever happened to Billing v2" is a question worth being able to ask. Each row says which project it belongs to, how it is going, and how far along it is. Opening one takes you to that project and shows the milestone's work; the app follows you there.

Peractor has no roadmaps and no initiatives, and this is why: a roadmap is not a container, it is a drawing — and this one is drawn from progress your runs earned rather than from a number somebody typed before the meeting.

Cycles

A cycle is a fixed window of work — a sprint, if that is the word your team uses. Cycles are off unless you turn them on, in Settings → General:

tasks:
  cycles:
    enabled: true
    weeks: 2         # 1, 2, 3 or 4
    startsOn: 1      # 0 Sunday … 6 Saturday
    upcoming: 2      # how many future cycles exist at any time
    cooldown: 0      # days of quiet between cycles

Peractor mints cycles ahead of time on that cadence, closes each one when its window ends, and rolls unfinished work forward — every task not in a completed or canceled status moves to the next cycle, with a line in its history saying so.

A cooldown is days of quiet between one cycle and the next. It shortens neither: a two-week cycle with a two-day cooldown still runs a fortnight, the following one starts two days later, and no cycle is current in the gap.

A project with cycles off has none of this and no cycle controls anywhere.

Triage

Work arriving from outside — a tracker sync, a trigger, the API, a Slack capture — can land in a triage queue instead of straight onto the board. It sits there until somebody says it is real.

The queue is a column above the board, labelled Needs triage. It is never hidden by the board's filters, because a queue that disappears behind a filter is a queue nobody empties. The one exception is a board narrowed to a milestone or a cycle: that is the contents of one bucket rather than a reading of the backlog, so it shows only the arrivals that are in it.

• Accept is one press. The task gets a real status and joins the board. You can set assignee, priority, estimate, milestone, and cycle at the same time, but you do not have to — the status is the ordinary board move that follows.
• Decline moves it to a canceled status.

Until it is accepted, a task in triage is genuinely held: it is not in any status, and it cannot start a run. Both decisions leave a line in the task's history.