Talk:Project management tools/Review

Here's what we'd like to learn from you:
 * What are the main technical activities you're involved in in the Wikimedia community?
 * What are your workflows for those activities?
 * Can you tell us everything you must be able to do?
 * Similarly, can you tell us everything you would like to be able to do that would make your work easier?

You're more than welcome to share additional information. The more detailed your responses, the more likely it is that your needs will be met by the tool(s) we collectively end up choosing.

Use the button below to create your section, see examples and format your information more easily.

Technical activities
MediaWiki core development, Flow team.

Workflow
Currently, bugs and features are tracked simultaneously in Mingle (soon to be Trello), Bugzilla, and Gerrit. Discussions happen across all of these platforms, plus via mailing lists, hangouts, Flow pages, and IRC. This has the effect of making our conversations regarding any progress completely disjointed, especially for tasks that take weeks to complete, because the discussion history can be incredibly hard to track.

Must be able to do

 * Create new feature / refactor tasks, discuss them, and then create subtasks or task dependencies
 * Review and approve code before merging into master
 * Restrict user read and/or write access to certain tickets, groups, and repositories
 * Must be able to query tickets and commits by product, component, status, assignee, and keywords

Would like to be able to do

 * Be able to control an entire ticket flow from the git command line
 * Have commit and ticket hooks to report information to IRC

More information
Phabricator does everything we need.

GDubuc (WMF) (talk)
I can't really follow the template because I've just joined and my team (Multimedia)'s workflow is in the middle of a reorganization. We'll probably find a stable way of working in a few weeks, but what we're doing at the moment is a bit irrelevant. However I can comment on Phabricator, having worked with it for a year and a half at deviantART, whose engineering team has a similar size as the WMF.

When I brought up Phrabricator during my interview here I was told that it was initially ruled out because it's incompatible with the WMF workflow/the fact that volunteers submit code. Now that I've had more time to think about it and to see how the work is done here, I don't see why that would be the case.

If anyone has questions about specific things they wonder could/couldn't be done in phabricator, I can probably answer them.

Here's a tentative list of things Phabricator can and can't do that I think are relevant to the WMF:

What it can do

 * Tasks, not bugs. This is a critical distinction. Bugzilla is too focus on taking care only of bugs. Whereas phabricator can take care of tasks and bugs. In fact, UI teams could use phabricator to handle their task management. Product too. That's a huge difference. For example it was common for me at deviantART to have a general product ticket (assigned to product people) with many smaller dependencies that were actually workable by engineers. Basically it's a lot more freeform and it allows each team to organize their workload with the nature of the tasks being completely different. It also allows engineers to prioritize building tasks and bugs alongside each other.
 * Rich markup everywhere. Tasks, changesets, commits, etc. can all have rich markup, not just text. This is particularly useful for non-bug tasks.
 * Code review. The UI for it is just brilliant compared to gerrit. There's just no comparison, phabricator is in another league UI-wise. An example: https://secure.phabricator.com/D7691
 * Testing integration. Something Phabricator can do is have the local utility used for pushing (arcanist) run the same tests locally, in addition to having the server run automated testing. On this one you can see what it looks like when tests fail: https://secure.phabricator.com/D7691 Unlike jenkins, this is properly built-in and doesn't act as a fake user. It will block merging just the same.
 * Doesn't require having another remote in git. Changesets are hosted in phabricator itself. This makes a more simplified git experience (basically no need for something like gerrit/master).
 * Creating automated searches that adds one to reviewers. This is the sort of feature you don't know you needed until you have it. Basically you can track with regexps any changeset or commit. Which means that you can catch people making mistakes as they happen, even if they're being made in a project unrelated to yours. At deviantART this was a brilliant way to make sure that people being onboarded adapted quickly to our best practices.
 * Search. Uses elastic search, it's pretty good.
 * Track backlog/performance. The built-in tools are a bit crude but do the job: https://secure.phabricator.com/maniphest/report/burn/?project=PHID-PROJ-69c04afe1fb836349ccc In the case of my project at deviantART, we were one of the few "healthy" ones where the graph of tickets didn't grow permanently (we actually managed to keep it stable). Again, here the integration is really easy and anyone fancying doing more analytics on the raw data could easily do so.
 * Welcoming 3rd-party contributions. Anyone can push changesets, people with appropriate rights in the project can accept/reject them. Phabricator's own phabricator is a good example of this, many people contribute to it.
 * Paste. Not need to use pastebin anymore. https://secure.phabricator.com/paste/ And more importantly, pastes can easily be referenced in tasks/commits/diffs, etc.
 * The phabricator team is very reactive, it's easy to contribute a bugfix and have it merged quickly (in a matter of days).
 * It has a "serious" mode. By default phabricator has funny wording and encourages the use of macros (usually to include gifs, lolcats and the like), which can put people off. I think that phabricator's phabricator is in that mode. This can be turned off.
 * Slowvote, documentation, etc. Phabricator has many integration apps that may or may not be useful here. Point is, there is a ton of stuff and a lot of new things coming being actively developed.
 * It's written in PHP. Which means that pretty much all webdevs at the WMF can hack Phabricator and we could build custom apps to do what we need. For example while at dA, I wrote Skype integration to log our conversations in the "Chatlog" app.
 * A one-stop-shop overview of one's work. Tasks, code reviews, bugs all seen on an engineer's front page. This is a fantastic way of having visibility over one's own pile of work to do. This is something I really miss here, I find that it requires too much mental gymnastic to have a vision of how many things I have to do, because it's currently split across several tools.

What it can't do

 * Kanban board. However phabricator is easily extensible/pluggable. At this point, I don't think that Pabricator can replace what people are using Mingle for (organizing cards on a board and moving them). This is probably something we could build as a Phabricator app, though.
 * Tags. Particularly, sprint tags are missing, afaik. Which means that if you want to tag/search tasks by sprint you need to create virtual projects whose only purpose is to keep track of which sprints a given task has been worked on. Basically you have a year/week number project that all projects use in addition to their own. Eg. a task would be in the "Multimedia", "UploadWizard" and "2014/4", 2014/5" and 2014/6" projects. Meaning that it got worked on during the sprints of weeks 4, 5 and 6 of 2014. This workaround pollutes the "projects" area needlessly, though. That's probably the feature I miss most.
 * Suggesting tickets when people report an issue. This is actually one of the rare things that WMF's bugzilla instance does better. Phabricator doesn't offer similar tickets when you type a new one, which I guess can result into more dupes. However I've also seen the situation at the WMF where several bugs are being treated in the same long-running ticket, which is detrimental, imho. Coming in late on the bug ticket it's very hard to know what's still current or not. Maybe Phabricator's forced (by the lack of offering similar tickets) approach of having someone manually decide to merge new tasks or not is better than everyone adding comments to a ticket that might not be their exact issue. It does require that someone triages incoming tickets, though.