Statuses
A request’s status is derived from the issue, every time it is shown. It is not a value anybody sets and it is not stored, so it cannot be stale and it cannot disagree with GitHub.
There are seven words, and a customer never sees any other:
| Word | When |
|---|---|
| Open | Nothing below applies. This is the fallback. |
| Planned | The project’s Status field is Planned or Todo |
| In progress | The project’s Status field is In progress |
| Waiting on you | The issue carries the label needs-info |
| Completed | The issue is closed as Completed, or the project’s Status is Done |
| Merged | The issue is closed as a duplicate |
| Closed | The issue is closed as Not planned |
The rules are applied in that order of precedence: closed as Not planned wins over everything, then Completed, then Merged, then In progress, then Planned, then Waiting on you.
Why seven
Section titled “Why seven”Because they are the words a customer can act on. Your internal Status
options — Triage, Blocked, In review, Needs design — are yours; they collapse
into Open or In progress and are never shown. Renaming an internal
option, adding one, or reordering the project’s columns changes nothing a
customer reads.
Changing the mapping
Section titled “Changing the mapping”Each request type has a Status map. Open it to point a Status option, a
label, or an issue state at a different one of the seven words. For example, map
your Blocked option to Waiting on you if that is what being blocked means
to your customers.
You cannot add an eighth word. The vocabulary is fixed so that a customer with requests in two portals reads the same seven words in both.
When the status changes
Section titled “When the status changes”The customer is emailed on a status change, unless they unsubscribed from that request. The email says the request number, the old word and the new one.
Because status is derived, closing an issue in GitHub changes the customer’s status word within seconds of the webhook arriving. Nobody has to remember to update the portal.