Inbox

What happened while you were away, on the issues you follow and the ones somebody put your name on.

What lands there

A run moving from queued to dispatched is not in there. That is machinery rather than information, and an inbox that reports machinery stops being read.

You are never told about your own doing. Nobody needs a notification saying they commented.

Following

An inbox needs a list of who cares, or "who should hear about this" gets guessed separately in every place that asks — and the guesses disagree.

You start following an issue when you:

• create it
• are assigned it
• comment on it
• are mentioned in it

Not by opening it. This page said otherwise for a long time and the product never did it: reading an issue leaves no trace, and a tracker where every glance signs you up for a thread is one where the inbox fills with work you looked at once.

Or by pressing Follow in the issue's properties panel.

Naming somebody

Type @ in a comment and pick a colleague. They get an inbox row saying they were named, whether or not they were following the issue — a mention is addressed to a person, not to a thread — and they start following it from then on.

• ↑ ↓ move, Enter or Tab picks, Escape closes
• The list holds colleagues and agents, and says which is which: naming an agent hands it the thread and queues a run, which is a different act from telling somebody
• You can still type a name by hand. The picker exists because you had to spell it exactly

A name two people answer to names nobody. With two colleagues called Arne Berg, or two called Knut, @Arne Berg and @Knut resolve to neither of them and no inbox row is filed. Reaching nobody is the better failure: telling the wrong colleague looks exactly like telling the right one, and the person who was actually needed never finds out they were named.

For those, the picker inserts an exact form — @user:12 — and shows the address beside the name so you can tell them apart while choosing. The posted comment reads @Arne Berg like any other; only the composer shows the key, and only where a name genuinely is shared.

You cannot name a director. The Management role has no inbox — it is behind the same gate as the issue — so a mention would file a row nobody can open and send an email pointing at a page that answers 403.

Nobody is told about their own mention. Writing @yourself still reads as a mention on the page; it just does not arrive.

Leaving is remembered. Press Stop following and your own old comment will not drag you back the next time somebody replies. That is the difference between unsubscribing and unsubscribing until further notice.

Reading it

Two halves, and the line between them is the one the email setting already draws.

Needs you

Assigned, mentioned, invited to a meeting — and a failed run, which is the one place this parts from the email rule. Nothing is addressed to anybody when a machine stops, and somebody still has to go and look: a run that failed is work that did not happen. A finished one is news, and sits below.

These are listed whole, never folded. There were three of them in an inbox of four hundred and fifty, and what made them hard to find was that they were drawn exactly like the three hundred and sixty-nine status changes around them.

Activity

Everything else, one line per issue. A heading carries where the issue ended up, how many updates there were, who moved it last and when; pressing it opens the individual rows.

One issue had sent twelve separate rows. Folded, that inbox went from four hundred and fifty-four lines to a hundred and eighty-six — and the twelve are still there, one press away.

• Mark these read and Clear these act on the whole issue. Folding twelve rows into one and then asking for twelve ticks would hide the work rather than remove it
• The count on a heading is counted in the database, not among the rows on screen. A heading that said 7 updates beside an issue with twelve would be worse than the wall of rows it replaced, because it reads as a fact
• A cap is always stated. Both halves stop at some length, and where they do they say so. The list used to take the hundred newest of everything, which on a real inbox meant three hundred and fifty rows were not on the page and nothing said it

The rest

• Unread is the default view, because that is the question you arrived with
• Mark all read when you have skimmed and decided
• Clear takes an item out of the inbox and deletes nothing: the issue, the comment and the run are all still there
• Clicking an item opens the issue and marks it read on the way. It is a real link, so ⌘-click or middle-click opens it in a tab — which is how anybody actually works through a list. A row opened that way stays unread, because nothing has been read yet
• A status change says where the issue went, not merely that it moved. done and canceled are both closed and mean opposite things, and a row saying neither is a row nobody can scan

Cleared notifications can be deleted. Per row, or Empty for the whole tab — and they are deleted for good, because a notification is a receipt rather than a record: everything it points at survives on its own. Cleared rows are also purged automatically after thirty days, so nobody has to do housekeeping on the database's behalf. See Operations for the schedule and the setting.

The unread count in the sidebar updates itself over the websocket. A count that is a page-load out of date is the difference between an inbox and a list you remember to check.

Email

Email follows the inbox rather than duplicating it. Under Settings there are three choices:

Before this, every comment on an issue you were part of sent an email and there was no way to say otherwise. Everything still lands in the inbox whichever you pick; the setting only decides what also reaches your mailbox.

Comment emails carry a reply address, so answering one lands in the thread — see Email.

Not there yet

• No snooze. An item is unread, read, or cleared.
• No digest. Nothing arrives as one summary at nine in the morning.
• No per-issue muting separate from following. Leaving a thread is the only way to quieten it.
• Agents have no inbox. They are handed work through the task queue, which is their equivalent, and they read a task envelope rather than a list.