See some discussion in T4807 and T4476 (although both are kind of rambley) and T4673. In short, we're planning to add at least some flavor of filtering and ordering options.

Can you walk me through the "multiple boards" case a bit, maybe with a concrete example of how it would be useful? This isn't currently something we're planning to build and this is the first request we've received for it.

Sure!

For example, we (on the multimedia team) have a work board for our current sprint, but we also have work boards for our next sprint, our previous sprint, and our current and next releases. We use these at different stages of the planning and development cycles, but really, having all of the cards visible on all of them is totally useless because of the huge amount of cards we have at any given time.

Also, once upon a time we had different views for different roles - e.g. one view for people trying to code things, another view for people looking to do code review, and so on.

If we have sub-projects (T3670), we could enable boards there, perhaps. It would allow the scenario I think you're describing. Though there is little fleshed out for that currently.

Nice to have: a view of workboards where you can see what every team member is working on, e.g. https://wikimedia.mingle.thoughtworks.com/projects/language_engineering/cards?favorite_id=175&view=Sprint+Status+by+Owner

Let me paste the questions of a Wikimedia community member in order to give you an idea about the expectations. Let me know what can be discussed here, elsewhere, or in a new task.

1. How many boards can a project have? a) What's the default? b) How do I make a column by assigned person? c) How do I restrict to the current sprint?
2. How many projects can a board have? For instance, a "Language Engineering" board would presumably contain a dozen components (extensions) maintained by that team, plus the stuff which isn't in any component/extension.

The current answers to these questions are:

(1) Projects always have exactly one board.
(1a) The default (and only option) is exactly one board.
(1b) Boards work a lot like Trello, and are more of a "thing" than a "view of data". Like Trello, there is no way to adjust the view of a board to alter the columns (unless it's hidden somewhere in Trello and I'm just missing it).
(1c) We tentatively plan to provide filtering options for boards, similar to Trello. This will be able to filter by owner, author, priority, status, etc. It may or may not be able to filter by sprint, depending on how sprints are set up. This is not technically difficult, but there's a lot of ambiguity in product direction right now, and WMF involvement has largely increased ambiguity, by introducing requests for novel workflows and features.
(2) Boards have exactly one project.

The big driving technical factor behind this (particularly, the "1:1" nature of boards and projects) is that all of a project's tasks always appear on its board. If we did not change this rule, but gave you multiple boards per project, I think they wouldn't be very useful: every board in the "Language Engineering" project would have all of the tasks on it.

We could change this rule, but that would make some aspects of boards less useful.

Maybe this question is helpful:

• If you have several boards in "Language Engineering", and create a new task and add it to the "Language Engineering" project (from the bare task create interface, not from any board or project context), which board(s) do you expect it to automatically appear on?

This seems hard to answer, and particularly hard to answer in an obvious/intuitive way, unless the answer is "none", which seems like a reduction in the utility of boards.

Overall I think it would be most helpful for us to understand the things you need to do, and why, and work forward from there. For example, it sounds like one request is "I want to see what every team member is working on". (Why do you need this -- what actions does this view help you take, or what decisions do you make with this data that you couldn't without it?)

You can do this in the list view; here's tasks assigned to me, Bob or Chad grouped by owner:

https://secure.phabricator.com/maniphest/query/hU8hY4caFPft/#R

Here's those same tasks, but filtered by just the projects Differential and Maniphest:

https://secure.phabricator.com/maniphest/query/N84eMYUh968U/#R

It looks like Mingle is essentially doing the same thing, it's just putting the data in a big table instead of a list. The table might be perfect for you and the list no good, but it would be helpful for us to understand what makes the table version better than the list version. If the answers to "what do you want to do / what do you want to understand" are well-served by presenting query results in a table format, there's no technical reason we can't do that.

The list views have a bunch of advantages like scaling easily to arbitrary numbers of tasks and filters and working on mobile, which is why they got built first. But to the degree that what you want is "query tasks, then show me results in columns instead of a list" or "query tasks, then show me results in a table instead of a list", we can probably make direct attacks on those. These may end up looking similar to boards, but from an implementation perspective they'd likely have little in common.

First of all, can I just say that you are an amazing upstream? There, I said it. :)

Overall I think it would be most helpful for us to understand the things you need to do, and why, and work forward from there.

Yes, I fully agree. We will need a bit of time to do our homework.

I actually believe that a lot of the questions will be solved just by getting our teams to use Phabricator and learning about the different paradigms and ways of working this platform offers to achieve the same things. We are still in the phase of I'm missing this from Trello, that from Mingle, after a superficial approach. trying to follow exactly the same steps as in those tools. Anyway, it's a necessary start.

This is not technically difficult, but there's a lot of ambiguity in product direction right now, and WMF involvement has largely increased ambiguity, by introducing requests for novel workflows and features.

True, the wave of feedback of the past days, caused, by the beginning of a request for comment to move our infrastructure to Phabricator, should stabilize... now? We can help defining better the priorities of our requests. For what is worth, we are maintaining a board (of course!) of tasks filed upstream or being discussed as potential feature requests.

First of all, can I just say that you are an amazing upstream? There, I said it. :)

Haha, thanks. And just to be clear, we're definitely happy about the feedback and it will help us build a better product, we just may not have very good answers for some of the questions yet.

Several tasks discuss the need to organize sprints and releases within projects. It would be useful to decide where these scopes will be defined: at a project level (subprojects) or at a board level (multiple boards)?