Which features would Mingle users really miss? If you are not sure whether feature X is supported, under development, roadmapped... just ask. Let's create new subtasks for features considered blockers.
|Resolved||• Qgil||T553 Engineering Community team goals for October 2014|
|Resolved||• Qgil||T174 Launch Wikimedia Phabricator Day 1|
|Resolved||• Qgil||T175 Nominate a team in charge of deploying and maintaining Wikimedia Phabricator code|
|Resolved||• RobLa-WMF||T17 Allocate resources for the migration and maintenance|
|Resolved||• Qgil||T19 Define which features existing in our current tools are really missing in Phabricator|
|Resolved||Awjrichards||T20 Identify features Mingle users would miss in Phabricator|
|Resolved||Aklapper||T100 Decide how to organize iterations and releases|
|Resolved||• Qgil||T72 Overview of what's happening in a project|
|Declined||• Qgil||T67 RSS/Atom feeds|
|Invalid||• Qgil||T154 Possibility to display different types of cards|
|Declined||Aklapper||T149 Multiple workboards per project|
|Resolved||Christopher||T153 Burndown charts for Phabricator projects|
|Resolved||Christopher||T817 Free alternative to Google Charts for Phabricator burndown charts|
awjrichards wrote on 2014-04-07 23:47:54 (UTC)
Below is a list of the biggest missing 'features' from Mingle. I am not sure how many of these (if any) I would necessarily consider blocking and I am hesitant to make that call myself since different teams rely on different aspects of Mingle differently, so for now I am settling with documenting the big differences I see.
- The concept of bucketing 'tasks' into an 'iteration'
- This also includes the ability to look at past iterations (and what was contained in them)
- As well as the ability to look at future iterations (and what will be contained in them)
- The concept of bucketing 'iterations' into a broader 'release'
- Forcing comments or other actions to be taken on a task when it is moved somewhere on the story wall (in Phabricator's terms, the 'workboards')
- The ability to maintain multiple 'workboards'
- Visualizations of aggregates or arbitrary task properties (eg a burndown chart - but more importantly, the flexibility to generate graphs based on whatever discrete bits of data ou may care about)
- The ability to track multiple types of work on the 'workboard'. That is, Mingle's basic unit is a 'card', and you can create n card types. This is useful for tracking different types of work (eg a defect vs new feature vs a task associated with a new feature vs an iteration vs a release vs ?!? etc).
- The ability to define arbitrary relationships and enforce arbitrary hierarchies between different aspects of Mingle (eg of and between card types)
- The ability to define and enforce different workflows for different card types
awjrichards wrote on 2014-04-07 23:57:36 (UTC)
- The ability to bulk update the properties of different cards ('tasks' in Phabricator's case) - this most commonly equates to updating the iteration a group of cards belong to, or updating the status of a group of cards (at least for the Mobile Web team's case)
- This is also something missing from Trello and I've heard is a big complaint from people who manage the boards
- The ability to receive email notifications for arbitrary events/property changes
gpaumier wrote on 2014-04-09 13:43:08 (UTC)
Regarding the bucketing of tasks, iterations, releases, etc. my understanding is that this can currently be done using projects (that are basically used like tags). There are talks in upstream Phabricator about developing functionality to make this a bit more straightforward by having different types of projects: full-fledged projects, tags, sprints, etc.
marktraceur wrote on 2014-04-18 16:30:00 (UTC)
@Awjrichards So in Mingle, my impression of iterations and releases is that they're just card types that contain children cards. We can do that here, trivially, unless I'm missing something.
(I asked awjr on IRC too, so no worries if he doesn't answer here)
qgil wrote on 2014-04-18 22:18:55 (UTC)
It would be very useful to know what you really really miss, to create subtasks and check with upstream. We are learning a lot by doing this in the context of Bugzilla.
qgil wrote on 2014-04-24 20:09:19 (UTC)
There is a bunch of duplication and confusion when it comes to discuss Mingle and Trello features, and when it comes to report our requests upstream.
I'm demoting the Mingle discussion in order to focus on the Trello discussion first. When we have a clear idea of what Trello users really need, then we can come back here and see what is still missing.
awjrichards wrote on 2014-04-25 01:16:13 (UTC)
Another thing I forgot to mention (h/t to paravoid for reminding me) - we have set up a unique view in Mingle to help track inter-team dependencies (https://wikimedia.mingle.thoughtworks.com/projects/scrum_of_scrums/cards/grid?color_by=status&filters%5B%5D=%5BShow+on+Wall%5D%5Bis%5D%5BYes%5D&group_by%5Blane%5D=team+dependency&group_by%5Brow%5D=team&lanes=+%2CAnalytics%2CCore+Features%2CGrowth%2CLanguage%2CMobile%2CMobile+apps%2COperations%2CParsoid%2CPlatform%2CVisual+Editor%2CZero%2CRelease%2FQA&tab=Dependency+Wall). While Phabricators links sure are prettier, I don't think we can currently replicate this kind of functionality in Phabricator.
More abstractly, we cannot create matrix views of Phabricator tasks based on arbitrary task properties. That view in Mingle is composed by adding two custom properties to the card type displayed: team, team dependency. The Y axis of the matrix displays 'team', the X axis of the matrix displays 'team dependency'. There is a third property on those cards, 'show on wall', which is 'yes' by default. A 'no' value will prevent the card from being shown. Cards on the wall are color-coded based on their status.
A little less abstractly, we cannot track inter-team dependencies in Phabricator (as far as I can tell).
faidon wrote on 2014-04-25 01:29:29 (UTC)
As I was saying on IRC, I think we can adapt to a different workflow and we don't need this feature specifically — at the scrum of scrums we're all coming from different teams and hence different workflows inside our teams anyway, so it's not like we're tied to some very unique way of collaborating with each other.
That being said, I think the "tracking inter-team dependencies" is a real need and one that it's important for our organization, so I would like us to at least have a potential solution for that, whichever that may be.
qgil wrote on 2014-04-25 06:49:00 (UTC)
Although not perfect, you could
- Create a "Scrum of Scrums" project.
- Assign to this project the tasks that are within the SoS scope.
- Those tasks must be assigned at least to two other projects: [team] and [team-dependency]
- List all tasks "Group by: Project"
This will give you a fixed URL for a query generating a list like
The list will contain a section for each team with a dependency, and each task will show the other project(s) involved.
PS: please create new tasks for new features, you process masters. :P
qgil wrote on 2014-04-28 21:46:18 (UTC)
Mingle lovers, look at the current subtasks and let me know whether there is something else you really really would miss in Phabricator. I think I have captured all the essential points.
I don't think any of these would be blockers for a migration to Phabricator. My simple deduction is: none of these points are stopping WMF teams to move from Mingle to the simpler Trello (analyzed at T45). Some of these features might come over time, since other projects using Phabricator are interested as well.
In all frankness, there are two areas that I haven't touched, only to test how badly needed they are:
- Swimlanes ( mentioned by Khorn during the PM tools review) and other boards whit rows in addition to columns (e.g. tasks by owners). Maniphest queries can probably give you the same data today, only not in a x/y board.
- Many other little features that @Awjrichards has mentioned with wise words here but not in own tasks/cards ready to be upstreamed. I he does his homework, I'll do mine. Otherwise, I will consider this already a symptom of the relevance of these features. ;)
The ability to bulk update the properties of different cards ('tasks' in Phabricator's case) - this most commonly equates to updating the iteration a group of cards belong to, or updating the status of a group of cards (at least for the Mobile Web team's case)
If you query all tasks of a project or any advanced search you get a "Batch edit" option at the bottom that lets you do this.
The ability to receive email notifications for arbitrary events/property changes
Create Herald rules and you probably will get exactly what you want.
qgil wrote on 2014-05-01 14:25:19 (UTC)
Alright, I think the subtasks define those features Mingle users would miss. If you want to push more features, please create subtasks for them. Resolving this task.