Another possible Group By is by project. So going into Differential and grouping by projects should allow me to see all Bug Reports in their own column.

Absolutely not ever implementing that, because it allows a card to appear multiple times in the same column and requires me to rewrite all the workboard code again.

Oh, wait. Maybe we're talking about different things. Let me draw a picture.

Yeah I'm not sure how they'd appear twice in the same column, just multiple times on the board ("Easy", "Bug Report")

Here's the feature I'm thinking about:

+================+
| Backlog        |
+================+
|@@ UNASSIGED  @@|
|@@ chad       @@|
| T456           |
|@@ epriestley @@|
| T123           |
| T124           |
+----------------+

The basis for this is this mock:

https://secure.phabricator.com/M10/10/

The "High", "Medium" headers are the "Groups". This would be the "Priority" view.

The "Assigned" view would be the same, but the "High", "Medium" would be replaced with "epriestley", "chad", "unassigned", etc.

Oh. I assumed the entire column was a group.

Admittedly I didn't fully grok your description, just how I pictured it in my head. What I was thinking was grouping a whole column by say a Person (like we did in Dashboards) you can see their points and drag work between them. If we go with grouped headers inside the column... how would that work for people? You'd just have their points for that column in the header?

We could do the whole-column thing, but I worry it would be confusing / not useful.

The big use case I see for this is checking everyone's workload on a team, but if it puts a person per column, it will include things in columns like "Backlog", "Done", "Wishlist", etc., which you probably don't really care about since they're not work. I think you're more likely to only care about columns like "About to Work On This" and "Working on This Right Now".

Yeah, my detail on the header is like this maybe?

+-----------------------+
| +-+                   |
| |X| epriestley  (16)  |
| +-+                   |
+-----------------------+

..where X on the left is a small profile picture, (16) is the points. So the headers would be a little bit taller than in the mock, but I think it shouldn't be too bad (I'd guess most boards don't need all that many users to show all the states).

I like this idea. For the "assignee" options, what would the ones shown be?

• Members of the project? If so, what happens to tasks assigned to a non-member; is it a magically-additional group that goes away later?
• Current assignees of shown tasks? If so, how do I assign something to a member (or whomever) who doesn't yet/right now have a shown task?

It's just Group By Assignee, so of all the tasks on the board, who is doing what, how much work is it, and what is unassigned.

There's some argument for showing more headers than the actual assignees, so you can assign a task to someone with no tasks currently assigned.

That is, if we have users Alice, Betty and Claire, and a column with tasks assigned to Alice and Betty only, but we "know" that you might want to assign stuff to Claire, it might be nice to show a header for Claire with 0 points so you can drag a task into that header to give it to her, similar to how the priority mock above shows empty headers for priorities with no cards.

I'm not sure what rule would be best. I think always showing "Unassigned" (even if it's empty) at the top (or bottom?) is probably desirable, but I'm not sure.

The minimum set is just the users in the column who are actually assigned something. Other reasonable rules I can come up with:

• All users assigned something anywhere on the workboard.
• Members of the project.
• All users assigned something anywhere in the whole project.
• ALL USERS ON THE INSTALL BWA HA HA HA

I'm inclined toward "all users assigned something anywhere on the board". So Claire shows up in every column if she has some visible task assigned to her in any column. If you need to give stuff to Danielle, you manually assign one task to her and then her headers show up everywhere.

That is, this is a valid column:

+=====================+
| Working On Now      |
+=====================+
|@@ Unassigned    0 @@|
|@@ Alice         0 @@|
|@@ Betty         4 @@|
| T123                |
| T124                |
|@@ Claire        0 @@|
|@@ Danielle      8 @@|
| T129                |
| T130                |
| T165                |
| T199                |
+---------------------+

It has five user groups (Unassigned, Alice, Betty, Claire, Danielle) but only two of them (Betty, Danielle) have any tasks. But the existence of the "empty" groups lets you give tasks to Alice or Claire easily, or unassign them.

We obviously don't want to list every user since having 30K groups is pointless, but if we can "guess" (using a rule above, or something similar) that you might reasonably want to give stuff to Alice or Claire, we can give them empty groups in the column.

In this case, you might see that Danielle has too many points and want to give some of her stuff to Alice or Claire, so the presence of their groups might be helpful, provided we can pick a rule that often guesses right.

If so, how do I assign something to a member (or whomever) who doesn't yet/right now have a shown task?

The strict answer to this is "click the Edit button to go to the full edit UI". We can't make all possible reassign operations accomplishable by dragging, so this has to be the safety net for the cases where we can't guess who your likely assignees are. But I suspect we can do pretty well most of the time with some set of those rules, and make the cost of guessing wrong low.

The strict answer to this is "click the Edit button to go to the full edit UI". We can't make all possible reassign operations accomplishable by dragging, so this has to be the safety net for the cases where we can't guess who your likely assignees are. But I suspect we can do pretty well most of the time with some set of those rules, and make the cost of guessing wrong low.

Maybe instead of guessing, you should have a form of the auto-complete sort where a user can plop another user on to the board to assign things to. This could be accessed through the Manage gear symbol if you don't want to add to the Workboard UI (when it's transformed to include the assignee 'rows').

Another possibility for assigning to members not already on the board would be to add an "Another User…" category, perhaps only once you start dragging, and if you drop on it, you have to select/type a user in a modal dialog to complete the 'drop' operation (or cancel it). This might work better than guessing; every column would have "Unassigned", headings for users with tasks actualy in that column, and "Another User…". On the other hand, for us, guessing is likely to result in a lot of wasted space, because the users we assign to in different columns are very different. The feature would quite probably be useful to us, though, as moving columns concurrently with reassignment is an extremely common task for us.

This could potentially work for priority grouping, too. It would be somewhat inconvenient to have "Unbreak Now!" on every column, as we use it very rarely (but we do need it sometimes). Also, I would only want "Needs Triage" to appear when tasks are assigned that priority, because I would expect a task moved between columns to be triaged at the same time if it needed it. We would also rarely want to move tasks into the wishlist priority. Having "Another Priority…" would allow a lightweight way to use other priorities, while minimising the spacial loss.

Perhaps some priorities/users should be able to be marked as "Always Show" though. E.g. it would probably be helpful to always show High, Medium and Low. It wouldn't be helpful to us for assignees, though, unless it could be chosen on a per-column basis.

Just some thoughts.

Technical stuff:

• Columns need to become a mixture of cards and headers.
• The sorting functions need to be able to sort these mixed lists in a uniform way.
• If card "X" is followed by header "Y", dropping card "Z" after "X" versus after "Y" need to be different operations even though the afterPHID will be "X" in both cases.
• When a card updates, we need to send its header back. The header may be a new header which isn't currently present on the board (for example: you edit a task and assign it to a new user with no other tasks currently assigned).
• The point count element should probably be client-side, since rebuilding it to send back the header after an update is a bit of a mess otherwise? This element isn't critical, regardless, and I think the other point counts are client-side already so this is probably easy.
• When an edit generates a new header in a column, we should possibly add that header to all other columns (for example: you edit a task and assign it to "alice", so "alice" gets an assignee header in every column).

This now exists for priorities. I'd like to get at least one more grouping (likely: assignee) built before calling this resolved since "Priority" has some magic interaction with "subpriority". I'm moving toward getting rid of "subpriority" in D20263, but I'm not yet completely sure that it'll stick.