Milestones
A Milestone gathers the bug hunts, sessions and automation runs for a release and answers one question: is it ready? Nothing about readiness is typed in by hand — every check reads the same evidence the rest of Sekee already has, the moment you look at it.
:::info Plan Milestones are on every plan, with no limit on how many you create. :::
Creating one
Milestones → Create, offered to owners, admins and members.
| Field | Notes |
|---|---|
| Name | Unique within the project, case-insensitively — ≤120 characters |
| Description | Rich text, optional |
| Start / due date | Both optional. The due date cannot be before the start |
| Color | A chip color, assigned round-robin from the same palette as tags. Change it any time |
| Readiness checks | A list of switches — see below. With none on, the Milestone reads Not assessed |
The checks fieldset says so directly: "Ready when every check you switch on passes. With none on, the milestone is not assessed."
The seven checks
Each check is a switch plus its own target. Turning one on adds it to readiness; turning it off removes it, it does not fail it.
| Check | Passes when | Target |
|---|---|---|
| Every bug hunt finished | No bug hunt in the Milestone is Planned or Active — Completed and Archived both count as done | — |
| Case pass rate | Passed ÷ (passed + failed + blocked), across the latest result of every case copy in its hunts, is at or above the target | A percentage, default 90% |
| No untested cases | Every case copy in its hunts has a result | — |
| Open bugs at most | Open bugs (Open or In progress) at or above the chosen severity, from the Milestone's hunts and sessions together, are at or below the target | A count, default 0, plus a severity — shown as "Severity and above" |
| Automation pass rate | Across the latest result of each automated test in its runs, passed ÷ all is at or above the target | A percentage, default 95% |
| Every session finished | Every session in the Milestone is Completed or Archived | — |
| Linked requirements passing | Every requirement linked to a test case run in its hunts reads as Passing coverage | — |
Case results use the latest result of each case copy, the same rule
coverage and bug hunt history
use — a hidden or archived copy is left out. Session bugs count exactly as hunt
bugs do — Open and In progress are open — on the same severity scale.
Ready, Not ready, and Not assessed
- Ready — at least one check is switched on, and every switched-on check passes.
- Not ready — at least one switched-on check does not pass.
- Not assessed — no check is switched on. This is not a form of "not ready"; it means nobody has said what "ready" means for this Milestone yet.
Nothing recorded is never a pass. A check with nothing to measure — no bug hunts for Every bug hunt finished, no results for a pass rate, no hunts or sessions for Open bugs at most — is shown as No data, in grey, neither passed nor failed. It does not count towards Ready, so a Milestone with one reads Not ready: an empty release has not proven anything. Either add the work the check is waiting for, or switch the check off if this Milestone will never have any.
Readiness is computed on every read, from the same evidence Sekee already holds. Nothing is stored except the snapshot taken when you close a Milestone — there is no cached verdict to fall out of date.
Assigning hunts, sessions and runs
:::note Recently changed A bug hunt or a session can now be in several Milestones — a hunt that belongs to a release, its hotfix and a regression pass is in all three, and counts towards each one's readiness. Until this release each could be in one. An automation run is still in one at most. :::
An item can only join a Milestone in its own project — a Milestone in another project is refused. A closed Milestone keeps what it holds: it accepts no new items, and nothing can be taken out of it. An item in a closed Milestone can still join other, open ones.
Three ways to assign:
- From the Bug hunts and Sessions lists. Click a row's Milestones cell: the project's open Milestones appear with a tick beside each, and ticking or unticking one saves straight away, without opening the row. A closed Milestone the item is in stays ticked and locked. Viewers see the cell but cannot change it.
- From the item itself. The bug hunt and session headers list every Milestone the item is in, each a link to it, with the same ticks behind the arrow beside them (+ Add when it is in none). An automation run's header carries a single Milestone chip, and its picker offers "Take it out of name".
- From the Milestone page. The Bug hunts, Sessions and Automation runs tables each have an Add button that lists the project's items not yet in this Milestone — unfinished ones first, with a search box — and every row has a Remove from this milestone button. An archived bug hunt or session is not offered, and nor is a run already in another Milestone.
You can also put a new bug hunt in several Milestones when you create it.
The Bug Hunts, Sessions and Automation Runs lists each have a Milestone filter; a hunt or session in several Milestones matches any of them.
The Milestone page
Beside the readiness checks, five tiles say where the release stands, and each lists what it counts — every row opens what it names:
| Tile | The number | The list |
|---|---|---|
| Bug hunts | Finished of all | Each hunt and its status, unfinished first |
| Cases | Pass rate, and passed / failed / blocked / untested | Each case copy in its hunts with its latest result — failed, then blocked, then untested, then passed — and the hunt it is in |
| Open bugs | Open bugs by severity | Each open bug, most severe first, and where it was found |
| Automation | Pass rate across the latest result of each automated test | Each automated test at its latest result, failed first; opens the run |
| Requirements | Linked and passing | Each requirement linked to its test cases, with its coverage, failing first |
A list shows up to 500 rows and says how many there are in all. On a closed Milestone the numbers are the snapshot taken when it closed, while the lists show each item as it is today.
:::note Recently changed The Session time tile is gone, and the tiles used to show their numbers only. :::
Below the tiles, Bug hunts, Sessions and Automation runs are tables with the same columns, search and filters as their own list pages, plus Add and a Remove per row. Archived hunts and sessions already in the Milestone are shown here by default — they count as finished towards readiness. When a table is empty it says so, with an Add button for anyone who can change the Milestone.
The fourth tab, Bugs, lists every bug found in the Milestone's bug hunts and sessions, the way the Bugs page does: the same columns, search and filters, starting with the bugs still open or in progress. Its count is every bug, whatever the status. A bug opens its own page; bugs join a Milestone through the hunt or session they were found in, so there is nothing to add or remove here.
:::note Recently changed The Bugs tab is new, and Add no longer offers archived bug hunts and sessions. :::
Closing and reopening
Close or reopen a Milestone from its page, or from the Status column of the Milestones list — the status on each row is a control, like a bug's.
:::note Recently changed The Milestones list used to show status as plain text and had a Bug hunts finished column. Status can now be changed from the list, and that column is gone. The Milestone's page still shows how many of its bug hunts are finished. :::
Close takes a snapshot: the verdict, every check's value and whether it passed, and the summary numbers, as they stood at that moment. The Milestone page shows that snapshot while it is closed, rather than recomputing live — closing is meant to freeze the record of what shipped.
Reopen clears the snapshot and readiness goes back to being computed live. Items can be reassigned to a reopened Milestone again once it accepts new ones.
Milestones are not deleted
:::note Recently changed A Milestone can no longer be deleted — not from its page and not through the API. Before this, owners and admins had a Delete button, which un-assigned the Milestone's bug hunts, sessions and runs and removed it. :::
A Milestone is the record of a release: what was in it, and whether it was ready when it closed. When it is done, Close it — that keeps the snapshot and stops new items being added. A Milestone still goes when its whole project or organization is deleted.
Renaming
Click the Milestone's name at the top of its page to rename it in place; Enter saves and Esc cancels. Edit changes everything else — the description, the dates, the colour and the readiness checks.
Watching, and the readiness email
Watch a Milestone the same way you would a bug hunt. Watchers get an email and an in-app notification when the verdict flips between Ready and Not ready — not on every read, and not for a change into or out of Not assessed.
- At most one email and in-app notification per Milestone per hour. A flip inside that hour is not sent later, even if it flips back and forth.
- The person whose action caused the flip is never on the recipient list — the same rule as every other notification in Sekee.
See Notifications.
Insights
Insights, in the list page's toolbar, opens a panel built from the Milestones currently on screen — it agrees with whatever filters are applied.
- Readiness — a donut of Ready, Not ready and Not assessed.
- Case results per milestone — stacked bars (passed, failed, blocked, untested) for the open Milestones, soonest due first.
- Open bugs by severity — stacked bars per open Milestone.
- Due dates — a timeline bar per open Milestone from its start (or its creation date, if it has none) to its due date, with a marker for today. An overdue Milestone's bar is drawn in the danger color.
The list already carries what these need, so opening the panel makes no further request.
The CLI flag
sekee-cli upload-reports --milestone "<name>" (and init --milestone "<name>") attaches the run to a Milestone in the run's project by name,
case-insensitively. See the CLI reference
and the ingestion API.
Activity
Every create, update, close and reopen, and every item added or removed, is recorded on the Milestone's own activity page — the same pattern as a test case's or a bug hunt's change history. See Activity log.
:::note Recently changed Milestones are new. A bug hunt's Release field is no longer offered when creating one — see the note on Bug hunts. :::