Views and shortcuts

A board of twenty issues needs nothing but its columns. A board of two hundred needs a way to ask it a question: what is Ana carrying, what is urgent and nobody has, what is actually left in this cycle. This page is the half of the module that answers those — the controls that re-slice the board, the views that remember a slice worth keeping, the palette and the keyboard that drive the whole page without a mouse.

All of it is on the dashboard, under Management > Projects & Tasks. There is one page of issues, and board or list is something you choose in Display rather than somewhere you go — so almost everything below works the same either way, and where it does not, it says so.

Grouping

Group by decides what a column is. It lives in the Display popover at the end of the filter bar, and it starts on state, which is the board everybody pictures: one column per column of the project's workflow. Change it and the same issues re-bucket by something else, with no issue touched and nothing moved — grouping is a way of looking, not a change. It is also remembered, so the grouping you pick is the one waiting for you tomorrow — and the Display button reads Grouped by assignee while it is on anything but the state, so a board never groups itself behind your back.

Three of them behave in a way worth knowing before you try them:

• By label, an issue carrying three labels appears in three groups. It is one issue shown three times, not three issues: change it in one of them and all three redraw. That is the honest way to draw "how much work does the bug label represent" when work is rarely only one thing.
• By project, you get one group per project. The page usually shows one project at a time, so usually that is a single column — but it is also what a board reading across several falls back to. A state and a cycle belong to one project, so by state and by cycle become by project while the board is wide, and bands by state or cycle are dropped rather than redrawn; every other grouping works as it does on one project. The Display popover says so where it happens. The two ways to get such a board are Include sub-projects and a built-in view answering for all projects.
• By team, the No team column is the useful one rather than an afterthought: it is everything nobody has claimed, which is the column a team meeting is actually about.

Grouping drives the list as well, where the groups are headed bands of rows instead of columns. Whatever the board is grouped by, the dependable ways to change a property are the ones that name it: the issue's page, the pickers on a list row, and the palette. See changing one issue.

Swimlanes

Swimlane by, in the same Display popover, lays a second dimension out the other way: horizontal bands across the board, so every card sits at the crossing of two questions at once. It starts at none, which is a board with one band — the ordinary board — and it offers everything except whatever the columns are already using, and except state and cycle while the board reads across several projects. Swimlanes are a board idea, so the list does not offer them.

The pairing that makes it click is columns by state, lanes by assignee: a row per person, each row a small board of that person's own work, all of them sharing the same columns. Standing back from it you can see who has four things in progress and who has none, which is a question a flat board hides by design.

Columns by state, lanes by priority is the other one people keep: the urgent band at the top, read first, every morning.

What a column header tells you

Three things, and the last two only when they apply:

• The count of issues in that column.
• The sum of their estimates, once anything in the column is sized — the same points the cycle burn-up is drawn from. A column reading 12 points is telling you what it would cost to empty it.
• The WIP limit, when the state has one, as the count against the limit. Over it, the header warns.

A WIP limit — work in progress — is a number you put on a state to say how much may be in that column at one time: In Progress, at most three. The point of it is not the number, it is what happens when you reach it: the next thing to do is to finish something, not to start something. A team that starts six things and finishes none is the thing a limit is there to make visible.

FlaviBot warns, and never refuses. Going over a limit is allowed, it simply shows. A tracker that blocks a drag at five o'clock on a Friday is a tracker people stop using. Limits are set per state, in Settings, with the rest of the workflow.

Saved views

A view is the filter bar, the grouping and the ordering, kept under a name. Anything you find yourself rebuilding on a Monday — my open bugs, grouped by priority, everything in this cycle nobody has picked up — is a view, and after saving it, it is one click.

Save view sits on the filter bar. Saved views then appear as pills above the board — beside the Active / Backlog / All issues segments, which narrow whatever a pill restores rather than replacing it — and each of them remembers four things:

Manual ordering is the one you made by hand: the order cards sit in inside their column, which is the board's "what next" rather than a sort. The other five are sorts, and apply everywhere the view does.

Clicking a pill restores all four at once; clicking it again takes you back to the plain board. Each pill has a menu that renames it, changes its icon, makes it shared or personal again, and deletes it, and the saved pills can be dragged into the order you want them read in — the one you open every morning belongs first.

The one you open on

The same menu carries Make this my default view: the view you land on every time you open Tasks on this server. The pill that is your default is marked with a star, and the same entry turns into Stop making it my default to clear it. It is yours alone, even on a shared view — two people can keep different defaults over the same pill.

A link wins over it. Any URL carrying ?view= opens that view instead, which is what a link copied out of the address bar does, so you can send someone "the triage board" without changing where either of you lands tomorrow.

With a view selected, Save view becomes a choice: update the view you are on with what you have just changed, or branch a new one from it and leave the original alone.

A server may keep 30 saved views. At the limit, saving a new one is refused — updating the one you are on still works, because it makes no new row.

Yours, or the server's

A view is either yours — nobody else has it, and nobody else's bar changes when you make it — or shared, in which case it sits in everyone's bar, marked with a small group icon. Either way it belongs to the server you made it on, and its own menu moves it between the two.

Shared is how a team agrees on what "the triage board" means; renaming or deleting a shared view changes it for everybody, so it is worth treating the shared ones as furniture and keeping the experiments personal.

The three you already have

Three views exist on every server without anyone making them. They are worked out for each reader rather than stored, are there in a server that has never saved anything, and — having nothing to rename — carry no menu and sit first in the row, drawn with a dashed outline:

They answer across every project on the server, not only the one the switcher is on: what is mine is not a question about one project. Lighting one puts an All projects chip beside the project switcher, lit with the view — press it to narrow the answer back to the project you are on, and press it again to widen it. Each row names its own project through its identifier (WEB-12), so which project a card came from is on the card. The narrowing belongs to the view you pressed it on: open another pill and it answers wide again.

Subscribed is the interesting one. You follow an issue by having been involved with it — you created it, it was assigned to you, or you commented on it — which is the same list that decides who gets a DM; see notifications. So Subscribed is exactly "everything that would land in my inbox", which is a better answer to what should I look at than any filter you would have built.

They are starting points, not a cage: change the filters on top of one and Save view keeps your variation as a view of your own.

Insights

The board answers what is there. Insights — a tab in the tasks page header, beside Cycles — answers how does it go: how long things take, who carries what, how the open pile moves week by week, over this project or all projects. It is read-only, anyone who can see the tracker can open it, and nothing on it changes an issue.

It is two charts. The first is a measure, sliced:

The three time measures are shown as days and hours: under a day, plain hours; above it, both — 61 hours reads 2d 13h.

Every bar carries how many issues went into it, and it is worth reading before trusting an average: a cycle time of ninety hours over two issues is an anecdote, not a trend.

The second chart is flow: per day, week or month, how many issues were created, completed and cancelled in the bucket, and, standing at the end of it, three bands — open and not started, in progress, done — that show whether the pile is growing, shrinking or merely being churned. A band of in-progress that widens month after month is the same thing a WIP limit warns about, seen from a distance.

Both charts share a window: on when issues were created or on when they closed, over a range that is a preset rather than a date input — the last 30, 90 or 365 days, 90 unless you pick another — and a scope of this project or all projects. Daily buckets are meant for the short ranges; past about three months the flow chart switches to weeks. Buckets are counted in UTC, like every chart in the module.

One thing to know before quoting a number from here: the charts read the issues as the rows stand today. An issue reopened this morning leaves the completed side of every past week, and an issue archived yesterday leaves the charts entirely. That is the right answer to "how are things now" and the wrong one to "what did we do in March" — for the second, a completed cycle keeps a frozen record and Insights does not.

The command palette

⌘K on a Mac, Ctrl+K everywhere else, opens the task palette for as long as you are on the tasks page. It is one box that does two jobs.

It finds issues. Type part of an identifier or part of a title — web12, landing copy — and it matches loosely, so a half-remembered word is enough. Enter opens what is highlighted. With the box empty it offers the issues you looked at recently, which is most of what you want it for.

It acts on the issue the cursor is on: change the state, assign it, set the priority, add a label, put it in a cycle, set the due date, set the estimate, assign a team, start or stop the timer, link a pull request, archive it, delete it, copy its link, open it in Discord. Type the action rather than reaching for the property — urg then enter is the whole interaction.

Every picker it opens, and every property dropdown on the page, is headed by what it is about to do — Change status…, Change priority to…, Assign to…, Set estimate to… — with the keyboard shortcut that opens it shown on the right and a number on each row. Typing the number picks that row, so the four or five choices people make all day are two keystrokes rather than a list to aim at.

It is keyboard only by design: arrows to move, Enter to take, Esc to close. While it is open it owns the keyboard, so none of the single-letter shortcuts below fire underneath it.

The dashboard has its own ⌘K for navigating between pages, and on the tasks page the task palette takes precedence. Search the dashboard at the bottom of the list hands straight back to it, so nothing is lost by the tasks page borrowing the key.

Keyboard shortcuts

The board answers the keyboard, and the fastest way to work through a triage list is to never leave it: arrow down the column, S to move the issue on, arrow again. The arrows move a cursor — one card at a time, outlined where it rests — and the keys from Enter to G below all act on whatever the cursor is on. They belong to the board and the list; an issue's own page is a separate page, with no cursor and no palette on it.

A, S, P, L, Shift+E and T open the palette already on that step, so the six of them are one keystroke to a picker rather than six separate menus to learn. Shift+T and G are not pickers and do not open one: the first starts or stops the clock — you have at most one timer, so the key always means the obvious thing — and the second opens the attach form, which asks for a repository, a kind and a number and could not be a list of rows.

E and Enter both open the issue, which is where the title is edited: the heading on that page is the field, so there is nothing a card could open in place. Shift+E is the estimate rather than a second editor, and the shift is what tells the two apart.

Esc gives back one thing at a time, in the order you opened them, so a reader typing a title under three filters and a saved view does not lose all of it at once: the composer first, then the cursor, then the selected view, then the filters.

None of the single keys fire while you are typing. In a title, a description, a comment or a filter box, C is the letter C, and the shortcuts come back the moment you leave the field. The two with a modifier — the palette and save — work everywhere, inside a form included, which is the whole point of ⌘Enter.

? is the one to remember. The rest of the table is on the page, one keypress away, whenever you have forgotten it.

Changing one issue

Issues change one at a time, and the only real question is which route is nearest to where you already are.

Three of those — state, priority and assignee — are editable from a list row without opening anything: the chip on the row is the picker, and clicking it never opens the issue. That is what makes the list the place to work through forty issues in a sitting. The palette carries all of them and needs no mouse at all. The issue's page carries everything, including the ones nothing else offers.

Archiving is a button on a list row, which appears as you hover it, and Archive in the palette. An archived row carries Restore in the same place instead. See archiving.

Deleting is at the foot of the issue's page, under everything it would destroy, where it asks twice — the first press turns into the question and the second does it. The palette's Delete issue does not ask: it deletes the issue the cursor is on, at once. There is no undo either way.

A card you drag is moved the moment you drop it and put back if the server refuses. Every other route waits: the row dims while the write is in flight, and the board redraws from the server's answer — so a refusal leaves what was already there, and says why.

How the page looks to you

Display, at the end of the filter bar, holds six choices, and every one of them is yours alone: they are not settings, nobody else's page changes, and there is no permission on them. There is no Save either — a click applies at once, and the button carries a dot for as long as anything in there is off its default.

View leads the popover because it decides what the rest of it means. Set it to list and the swimlanes and the card properties leave the popover altogether: a list draws its own columns and has no bands, so both would be choices that change nothing.

A card can carry its priority, assignee, labels, due date, estimate, identifier, cycle, project, sub-issue count, comment count, team, time and GitHub links — that is the order the popover lists them in — and the first six of those, down to the identifier, are on to begin with. Turning some off is worth trying on a busy board: a team that never estimates and never sets a due date is reading two empty rows on every card, and a card down to a title and an avatar is a card you can see forty of.

The grouping, the density and the card properties follow you to another machine. The view, the swimlane and the ordering are remembered in the browser you set them in, which is usually what you want from them anyway — and both the view and the ordering are things a saved view carries, so a view is how you pin them down for good. Reset puts all six back to the defaults, and clears your default view with them.

Next: estimates, time and teams.