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.

Technical activities
Technically, I'm just fundraising engineering. In practice, I've more or less taken ownership of our Mingle instance, and the working process it describes (we have had zero product people for about a year).

Workflow
Fundraising's Mingle Instance

Description of Mingle Usage

For those of you who don't have collab accounts (for some reason, this is Fundraising's preferred wiki, and we're trying not to fragment), I will attempt to nutshell below.

We currently have six main card types, that relate to eachother in a heirarchy. Briefly, they are:
 * Triage item: An acknowledgement of the idea that if you make it more difficult (or apparently difficult) to enter a piece of work (bug, feature, whatever) in a system than it is to write the same thing on a post-it note, it will end up on the post-it instead of the system. Triage items are as simple as they get: Just a title and description. It is up to the curator to review triage items and make sure they land in an appropriate place for the tech team (or whomever). Mostly, this item type was created to help bridge the gap between non-tech and tech in fundraising.
 * Business Goal: Large sweeping overarching goals with large sweeping overarching language. Nothing actually actionable.
 * Business Capabilities: Incredibly rough descriptions of things the system will have to be capable of, in order to meet our lofty goals. Business goals can contain multiple business capabilities.
 * Tech Supertask: A vague stab at solving the problem of grouping tasks together in a state of minimum usefulness. Nothing counts as "deployed" until everything in a supertask is deployed. Both business goals and capabilities can contain one or more tech supertasks.
 * Tech task: Finally, some actual engineering. A description of a defect, coding task, production issue (as in, an issue under the creative team's umbrella), ops action, spike, system upgrade, doc review request, 3rd party issue (tracking), documentation task, or dashboard (visualization) item.
 * Tech tasks can belong directly to any card type mentioned above, except for the triage item.
 * Tech tasks must belong to a business goal or capability (either directly or through a supertask), to be considered dev ready.
 * Tech tasks have priority ( based on our Priority Descriptions, and please disregard every other piece of that page because it's all terrible ), a point-based estimate, and a status that roughly corresponds to standard agile swim lanes.
 * Sprint: Exists mostly outside of the business value tree. We don't really think of sprints as being uninterruptable blocks of time (can't do it. Too many critical dependencies with third parties that need sudden maintenance with no notice), but rather as a way to filter what we are supposed to care about now, out of the rest of the backlog.

Business value cards are typically assigned to a campaign in the planner view (can't give access to people who aren't project admins) by someone not in tech. Then, sprints are teased out of the chaos based on (for example) the most pressing goals, what the highest priority items directly relate to in the backlog, how much service disruption will be tolerated in the next [time period], etc.

Must be able to do

 * Alter the workflow in relative significant ways at any time, to accomidate new needs and observations across the whole fundraising team.
 * See the current sprint's swim lanes, and manpiulate cards on the wall.
 * Non-tech must be able to enter and track items that only describe business value.
 * Associate business value items with a campaign / event
 * Associate technical items with business value items
 * See all technical items that associate with a specific business item
 * ...and generate the aggregate estimate
 * Track sprint velocity
 * Seperate planned velocity from emergency velocity (see priority description).
 * Generate burnup charts
 * ...and work in the emergency work trend
 * Query for the type of tech work
 * Query for the relevant codebase
 * Associate tasks with a larger task, with the implication that the smaller tasks would have no inherent value on their own
 * Create an ultra-simple (default?) item entry type, which ideally would not even present anything beyond title and description.
 * Keep track of who created the tech item, and who was working on it last
 * Mark a task as "blocked" (with comments)
 * Keep a date for item creation, and a date for every major lane move (particularly "Pending Code Review" and "Deployed")
 * Keep all our work history together
 * Create our own custom item views, and save them for future use
 * Tag items in a freeform way, and query on that tag

Would like to be able to do

 * Associate tech tasks with more than one business value item. Currently, the business value tree only allows each item to exist up to one time (so it ends up being 1:many on the way down, but only 1:0 or 1:1 for every type on the way up)
 * Have a tech trend graph that can be manipulated in realtime.
 * Display an icon next to the card in the swim lane view, if the card is tagged with "Special Deploy Instructions"
 * Granular security levels for team members - It would be nice if business was somewhat distinct from tech, and everybody could see the planner view without having to be a project admin.
 * Git commit hooks would be lovely.
 * Scripts to automatically correct the "Data Problems" that we find sometimes in our backlog.

More information
Maybe later.

Technical activities
Product management (previously for Mobile team projects, now for the Core features team/Flow project)

Workflow

 * Daily
 * create user stories and design tickets (in Mingle & Trello)
 * prioritize bugs that have been imported via Bingle from BZ to Mingle
 * monitor Gerrit patches via IRC bot to see what things people are working on, where things are blocked, etc.


 * Weekly
 * file and respond to bugs in Bugzilla and attach relevant bug #s to user story cards in Mingle
 * test stories/bugs, close bugs that have been resolved in both Mingle & Bugzilla (sometimes bothering to hunt down the Gerrit patch # if it wasn't added to the bug, but mostly not)
 * link end-users to issues being worked on in Mingle/BZ and update them when they've been resolved
 * look at files in Dropbox/Commons and attach assets to user stories


 * A few times a month
 * respond on Gerrit patches (when they pertain to user-facing copy or behavior)
 * respond to i18n feedback on translatewiki

Must be able to do
I must be able to:


 * assign tasks to users
 * define a task type (bug, feature, enhancement, etc.)
 * see & search code review, bugs, user stories, translation discussions
 * find all the above via product / component / status / assignee / sprint / keywords
 * edit priority, status, and assignees of items
 * create & save custom views of stories/bugs (e.g., "All reopened Flow bugs")
 * mark tasks as not actionable/invalid
 * mark task as "needs more input from person X" & CC those people (sending them notifications)
 * incorporate design assets into task tracking (add external links or attach files)

Would like to be able to do
I would like to:


 * get notifications when new tasks appear or task status changes
 * attach deadlines to tasks
 * attach checklists to tasks
 * have anyone – technical or non-technical, part of my project/team or not – file a new bug
 * have anyone – technical or non-technical, part of my project/team or not – generate an idea for a new user story
 * hunt down the actual human behind IRC/Gerrit/BZ/Mingle/Translatewiki username and be able to talk to him/her
 * do all the things I need to do in one place, not 6 (Mingle, Bugzilla, Gerrit, IRC, Translatewiki, Mediawiki.org) or more

I would like to not:


 * have long product/design/ideology arguments that belong on wiki/mailing list in any task tracking tool
 * have task type, status and/or priority changed by people who are not assigned to the task and/or working on the product in question
 * have to change the status/priority of items twice in two separate places
 * miss things because I forgot to log in to task tracking tool X and/or didn't notice new comment/notification Y
 * use a crappy, non-intuitive UI for simple everyday project management when there are so many nicer, more user-friendly alternatives out there :)
 * mistakenly think User:Foo is 2 people because her username onwiki and her username on Bugzilla are different
 * deal with rudeness or harassment or see it happen to others in any task tracking tool

More information
Just listing out all the tools I use daily/weekly/monthly made my brain hurt.