Page MenuHomePhabricator

Query-driven workboard columns
Closed, WontfixPublic


Kanban-style boards are popular for visualising a project management-level overview of ongoing, future, and done work. suggests these are a key feature of Maniphest. The classic example, using Post-It notes, essentially has one column for each task status:

kanban.jpg (450×800 px, 57 KB)

Workboards in particular provides a good example of something which uses something which is superficially similar (columns on a board!), but does not involve mapping status to column, so is not affected by this issue.

I have been using Phabricator for sprint projects in an internal deployment at my company, using Kanban workboards°. When using columns to reflect task status, everyone has to remember to update both task status and workboard column. Not doing so means that the two can get confusingly out of sync.

Anecdotally as the cause, I see two behaviours which frustrate each other: project managers sweep, organise, and manipulate via the workboard view (reflecting column membership), and developers primarily work via 'queue of stuff' views such as the dashboard and Maniphest landing page (reflecting task status). Each wants a different view for different reasons: PMs want to assign and organise, and developers want to work through a semi-linear work list. Each group may not realise that they've forgotten to update the other view, since they may not look at it day-to-day.

Ultimately, having to perform two actions (update task status, change project column) for one semantic action (change task state) is not just error-prone, but also busywork; I would be in favour of anything which gave the least amount of friction. But mostly, I want to make sure that the two can never get out of sync.

T5474 would solve this problem from one end¹: moving a task between columns will change its status. However, there is still an opportunity to have the two out of sync with each other, by changing the task status and forgetting to update the column, as developers are wont to do. It also doesn't support a 1:n column:status model; you may have an extended set of statuses ('in QA', 'awaiting deployment', etc) which map to the same high-level state ('dealt with for now').

Coming at this from the other side, and providing query columns, or column-like views would remove this possibility: the user would only ever update the task status, and the status columns would then always be in sync. I imagine this as allowing me to add/configure a column with something resembling the current filter dropdown; in particular, having the advanced filter available would be both consistent and powerful.

Somewhat separately, these query views would also enable orthogonal column views: in addition to a Backlog/WIP/Blocked/Done/... set of columns, you could also add views for bugs/features/epics, or other task classifications².

°: Generally, we have a top-level covering project, which contain one milestone per sprint. The sprint milestones have columns roughly as in the picture (backlog/WIP/blocked/done), reflecting task statuses.
¹: I don't think the exact converse of T5474, using triggers to manage explicit column membership, would be a good solution here. @epriestley validly points out that this would complicate multiple tags/projects, where you may want to manage column membership separately per-tag. Also, it would require new UI to be able to associate workboard columns with the triggers, be it tagging the columns or using substring matching; this is because the list of task statuses is globally well-defined, knowable, and immutable; not so with the set of workboard columns.
²: I can expand on this if it's helpful, but didn't want to entangle it with the core problem.

Event Timeline

eadler added a project: Restricted Project.Jul 26 2016, 9:07 PM

Oh, I forgot to mention this but T10333 (groups within columns) is another possible attack here, and one I definitely intend to implement regardless of other work and outcomes (e.g., T5474) since I think it stands on its own and is already well-justified by confusion with priority-ordered boards. T10333#158767 has the ASCII-art mock:

| Backlog        |
|@@ UNASSIGED  @@|
|@@ chad       @@|
| T456           |
|@@ epriestley @@|
| T123           |
| T124           |

Or this has a rough, more pixeley mock:

Grouping by status instead of assignee (ASCII mock) or priority (pixel mock) would be supported.

If all of the tasks you care about fit into a couple screens of real estate, that's probably a pretty good approach, although maybe less so as you get up toward 100+ tasks.

@epriestley Yeah, that would certainly be really useful for some cases; I imagine infrastructurally it'd be a good step towards this as well, along with T10569. I don't think it would help this particular usecase though.

I think the best thing I can do is to capture an active backlog and screenshot it for you. Unfortunately we're currently both mid-release and also in the middle of changing our entire layout inside Phabricator, so let me come back to this in a few weeks when the workboards we have are a bit better fleshed out.

For completeness, I'll also drop a mention of T5024 here, although I'm not yet sure how the two might tie together.

@epriestley Here's an anonymised version of a live workboard. I've completely wiped out all identifying data; I thought about summarising the task titles rather than obliterating them, but afraid I lost the will to live at some point.

kanban-workboard.png (1×3 px, 502 KB)

There are a few things going on in this screenshot ...

This is for work done on an open-source project, working towards a particular release, looking at a two-week sprint. Quite a lot to do, as you'll see. The instance is shared with a customer of ours (we're a consultancy), who sponsors a lot of our work on this project, hence all the Space 2.

The customer wants to track particular high-level task groupings ('Fix most glaring accessibility issues'), with visibility into the individual tasks ('Unbreak magnification after scene graph changes', 'Implement audio channel interrupt for screen reader', 'Expose libstuff menu items to screen reader') but not tracking them per se. The higher-level tasks are generally the ones tagged as Customer Project, where they track those in a separate workboard. Using milestones as a separate tracker for higher-level tasks like this is a good idea at first, but does not scale to the number of these higher-level trackers we have; typehead disintegrates entirely.

Most of the rest of the Project tags are for particular teams (e.g. 'libstuff developers', 'Know stuff about accessibility'), to give a better long-term resource-planning view. The tagging is not spectacularly consistent, as we have just changed our tagging and organisational structure for this work pretty radically, hence why it's taken a while for things to settle down before I was able to get a representative screenshot.

The only columns which are first-order columns per se are Backlog and Defined, where the backlog is a dumping ground, and Defined is something that is agreed upon and ready to go. The other columns have a precise n:1 status:column mapping.

We've added status icons to workboard cards, partly to make it incredibly obvious when status and column get out of sync; this is particularly relevant with tasks spanning multiple projects, where you may update the column in one project but forget to touch it in another. I'd say we could scrap that local extension if columns driven directly from queries would happen.

We've added a combined Differential/Harbormaster status to the cards as well, since it makes quite clear (especially with larger teams) whether a particular task would benefit from review or integration attention to unblock its progress, or whether the assignee needs to do more work before external attention would be beneficial. Again, this is probably something that could be obviated with query-driven columns, though T7076 would need dealing with before this could land upstream.

Separately, there is a lot of Restricted Project; I have been working on T10745 locally to fix this. The display side is fine (just not yet deployed to this instance), and I'm crunching through dealing with the notifications.

Let me know if anything else would be helpful from my end here.

epriestley claimed this task.

I don't currently plan to implement this. I think T5474, T10333, T11036, and using the Maniphest list view with "Group By" address this use case to varying degrees (if you "Group By: Task Status" and then turn your monitor sideways, you pretty much get the desired result). It's possible we'll end up back here in the future, but since I'm not planning to scope this into T13074 I'm going to close it until those changes land and further use cases arise.