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.

Technical activities
What are the main technical activities you're involved in in the Wikimedia community?

Wikimedia Mobile App Team. The team uses trello for all of our activities and we *love* it. Its simple, quick, and *never* gets in our way. Our bugs are fed in through bugello and we prioritize them during each standup.

Any new tool would have to work faster, have built in estimation, and be simpler for us to be motivated to switch. Simply put trello is great for us and we think other teams would benefit from using it.

Workflow
For each of those activities, can you describe the workflow you're using?


 * 1) Stories are drafted and placed onto the backlog board
 * 2) Stories are prioritized and flushed out by product ownder
 * 3) Stories are moved to a sprint board
 * 4) Acceptance criteria is defined
 * 5) Stories are estimated
 * 6) Stories are accepted by developers and move through dev stages
 * 7) After two weeks the sprint board is closed and a new one is opened fed by the backlog board

Must be able to do

 * I must be able to add stories through desktop, mobile, tablet
 * I must be able to see real time changes without reloading the web page for a sprint
 * I must be able to set story points and see velocity
 * I must be able to set custom swim lanes
 * I must be able to see everything that is happening within a sprint without scrolling the screen
 * I must have one area for the backlog, one area for the current sprint, and one area for the upcoming sprint

Would like to be able to do

 * I'd like to automatically see sprint velocity graphs without having to make a spreadsheet

More information
Mobile App Team page

Technical activities
Primarily, feature product management, some project management, and occasional coding for:
 * VisualEditor core
 * VisualEditor MediaWiki
 * OOjs
 * OOjs UI
 * UnicodeJS
 * Beta Features
 * … others

Workflow
For the product and project management sides:


 * Raising tickets : bugs, new features, enhancements, technical debt, and tasks [in Bugzilla]
 * Triaging incoming tickets : evaluating, confirming, prioritising, re-wording, adding detail, splitting/specifying, allocating to component/product, setting as blocking/depending on other ticket, accepting/rejecting, … [in Bugzilla]
 * Prioritising work for the team : assigning tickets to a developer's (prioritised) stack [mostly in stand-ups and in a tracking Google Doc]
 * Reviewing changes : consider and test changes made by developers for having met requirements [in Gerrit/Bugzilla]
 * Marking completed tickets : marking tickets that have been completed as done, assigning to the relevant (weekly) release milestone [in Bugzilla]
 * Writing release notes : collate all changes made in a given period, write and release [on-wiki, based on Gerrit and Bugzilla data]
 * Responding to queries : from end users, third party developers, third party sysadmins, etc. [mostly on IRC, by e-mail or on-wiki]

Must be able to do
I MUST be able to:


 * alter a task ticket to:
 * open or close it;
 * convert it to a different type;
 * change its title, product/component, priority, confirmation, wording;
 * be composed of "checklists" of blocking sub-tasks
 * add detail/comments to it;
 * merge, split, broaden or narrow it;
 * assign it to a person and so send them a notification;
 * assign it to a (dated) milestone ("sprint"?); and
 * accept/reject it (with justification)

The system MUST:
 * be able to have private/locked tickets for security-related issues
 * let anyone file a task ticket with a simple account
 * let anyone read any (non-private) task ticket and all statuses
 * and provide simple, short-as-possible- sharable URLs that uniquely identify tickets without login
 * be the only system we use for all projects, configurations, discussions, designs and others (no roll-your-own-process with Mingle, or github, or …)
 * allow cross-project dependencies and cleverness
 * provide a git instance that …
 * only allows team members to merge code
 * runs automated checks (linting etc.) and tests (unit, integration, browser, …) when code commits are submitted, amended, and approved (and blocks merge on this basis)
 * provide a dashboard for the review of incoming streams of, custom saved searches of, and individual …
 * task tickets
 * code commits
 * transmit all needed streams of tickets and code commits by e-mail to users that need it
 * store and display the history of a ticket to any interested users

Would like to be able to do
I SHOULD be able to:
 * alter a task to:
 * attach a file (e.g. a design image) to it; and
 * lock it from further discussion once closed
 * receive by e-mail and be able to review incoming streams of, custom saved searches of, and individual …
 * translation discussions
 * write a narrative of the important changes for a milestone (linking to tasks and commits alike) and series of milestones

The system SHOULD:
 * let anyone file a task using their SUL login transparently
 * prevent some fields of tickets be altered by non-team members (e.g. acceptance, type, priority)
 * lock tickets from further discussion once closed (maybe after some period of time?)
 * show store and display "in-line" the history of a ticket to all users

More information
I wouldn't want to replace IRC for this, but I'd love to junk Bugzilla and the Google Doc (I actually rather like gerrit, but I'm somewhat alone in this); we've previously used Trello, Mingle; Google Spreadsheet and other things for the task management side, and they all suck – it's just a question of how much less they suck.

Technical activities
What are the main technical activities you're involved in in the Wikimedia community?

MediaWiki core development, extension developer, tech ambassador, third-party wiki farm sysadmin

Workflow
For each of those activities, can you describe the workflow you're using?


 * Find a bug/feature I want, either manually or by observing a comment on w:VPT, IRC, or any other page
 * File the bug in bugzilla, maybe ping a few people in IRC to make sure its feasible (if I don't know that already)
 * cc the people who are best suited to fixing the bug if necessary
 * Submit patch in gerrit
 * Get reviews (usually bug a few people on IRC), patch is merged, yay!

Must be able to do
Using the workflow you've described above, can you tell us everything you must be able to do?


 * I must be able to view a list of bugs for a given component and filter them based on various fields/keywords
 * I must be able to set an assignee for a bug
 * I must be able to provide a stable permanent link for the issue
 * It must have a decent search engine
 * I must be able to cross-reference the bug in gerrit (or whatever code review tool) and vice-versa, preferably automatically
 * Anyone (who isn't a spammer/vandal) must be able to comment on the bug
 * I must receive email notifications whenever a bug I filed/am assigned to/cc'd on is updated
 * There must be some kind of real-time notifications feed, preferably IRC
 * Edit patches/code in my browser (gerrit doesn't support this, and it cripples me)
 * Any tool used must have an API
 * Should not be super slow to load and stall your browser when opening large files (like gerrit does)

Would like to be able to do
Similarly, can you tell us everything you would like to be able to do that would make your work easier?


 * I should be able to "mute" a thread (github has this feature) to stop receiving notifications about it, regardless of anything else
 * If a bug is linked on wiki, it's nice to be able to see the status/title of the bug (there is currently a gadget for this)

More information
More to come when I think of it. Legoktm (talk) 22:24, 14 January 2014 (UTC)

Technical activities

 * Mostly development on the CirrusSearch extension.
 * A good deal of monitoring it as it goes into production.
 * Some work on Mediawiki core and Elasticsearch.

Workflow
I make code changes because (in no particular order):
 * 1) We notice a bug during the roll out
 * 2) We notice a performance issue roll out
 * 3) Community member notices bug during roll out
 * 4) Community member has great idea
 * 5) We have great idea

3 & 4 sometimes come from Talk:Search or are filed directly in Bugzilla. Usually I file everything from a community member in Bugzilla for them if they don't file it and sent them a link.

I don't always create Bugzilla bugs for things from 1 & 2 & 5 but I certainly will if they are time consuming, high impact, or I can't solve them right now.

Regardless of whether we have a bug I then make the code change, run some portion of my regression tests, and then submit the change to review in gerrit.

Chad reviews my in changes typically in less than 24 hours and Jenkins merges the code. Normally I use the link in the automatic email to go and mark the bug resolved when the code is merged.

Bugs rarely require multiple change sets but when they do I tend to leave the bug in Assigned state even when one change set is waiting for review.

Sometimes I troll my bug list looking for something to knock out or something that has been merged but not marked as such.

When a bug is nasty I'll verify it in production after it has been deployed then mark it as verified. Sometimes I troll through my resolved unverified bugs and go verify them in production.

Often code changes have corresponding deployment activities and I generally execute those manually.

Must be able to do

 * File issues and features so other folks can see them or so I'll remember them later or both.
 * Correlate code changes with issues or features. We do this by adding "Bug: ####" to the commit message.
 * Mark code as requiring a deployment activity.
 * Know whenever code that requires a deployment activity goes to production. I deploy much of my code myself but I need to know if other people deploy it as well.
 * Keep a backlog of deployment activities that have yet to be run in production. Most deployment activities are optional but enable code cleanup or improve some behaviour.
 * Sweep issues and features from my "backlog" when their code is merged.

Would like to be able to do

 * Automatically RESOLVE bugs when the code is merged. Maybe I can mark my commit message as "Closes Bug: ####" rather than "Bug: ###".  Most commits that reference bugs RESOLVE them when merged.
 * Automatically mark issues and features as deployed to production when they are deployed. This would really help with manually verifying once it is deployed and notifying the community.

Technical activities
What are the main technical activities you're involved in in the Wikimedia community?

I'm a software engineer on the Growth team. Primarily, I work on extensions, such as GettingStarted and GuidedTour. I also contribute to other repositories, such as core, in some cases. Last summer, I mentored two students for Google Summer of Code.

Workflow
For each of those activities, can you describe the workflow you're using?

Our team currently uses Trello, a proprietary project management tool, as the primary tool for organizing our sprints. I have been trying to reduce the amount of work I do that is not tracked as part of the sprint. We have a sprint planning session every two weeks. The primary purpose of sprint planning is to move things from the backlog (everything we want to do at some point in the future) to "Current To Do" (what we want to do this sprint). Occasionally, I also do things in Bugzilla, either without it being part of the sprint (as noted above, trying to reduce this), or after importing it into Trello, and it being planned into the sprint.

When I start a task, I move the card from "Current To Do" to "Doing". I then set about doing the task. Usually, this involves a change to an extension git repository, but it could also be a configuration change, planning, improving our own processes and tools (e.g. improving our Wikimedia Labs setup), or running a script.

When a card is done, I move it to Done in Trello. For code, this may also involve marking a bug RESOLVED FIXED. I do not wait until a patch is deployed before marking it FIXED. Usually, the same is true for Trello, unless there are special concerns (e.g. a configuration change, or a required script run for deployment).

Must be able to do
Using the workflow you've described above, can you tell us everything you must be able to do?


 * I must be able to see items in the current sprint that are not started, where I am assigned.
 * I must be able to see items in the current sprint that are in progress, where I am assigned.
 * I must be able to see items in the current sprint that are done, where I am assigned.
 * I must be able to file a new item and assign it.
 * I must be able to CC people without them being considered assigned.

If the system replaces Gerrit as well (git management):


 * Only people with +2 should be able to approve a patch for merge.
 * Projects should each be able to configure automated testing, which can be required for merge (voting, which is preferred), or not required for merge (non-voting, ideally temporary).
 * Comment on a change/issue (cover comment) and inline

Would like to be able to do

 * I would like to view my team's agile velocity
 * I would like to filter items by primary area (e.g. GettingStarted, GuidedTour, Drafts).
 * I would like to be able to see helpful graphs and reports.
 * I would like to mark that one task blocks another task.
 * I would like an API, for querying (usable from a MW gadget if possible) and possibly writing (to allow integrations like Bingle).
 * I would like to see history of status and attribute (priority, keywords, etc.) changes to the task
 * I would like to put Fixes-Bug or similar in my commit message (53387) and have the task be marked fixed/done when the change is merged (this is not the same as Bug: which just means it's related)

More information
I would strongly prefer we use an open source solution. I think they have matured a lot recently, and there are various options, including Phabricator, Redmine, Trac, and Fulcrum. Many of these allow plugins, so we can "plug in" the exact process we want.

Having our own code (MW core, extensions, etc.) FOSS is a critical part of making our work open and allowing the right to fork. However, this is less realistic if the critical infrastructure supporting our work (project and issue trackers, in this case), are not. Using FOSS tools also means we are more likely to contribute back and help build up the FOSS community we live in.

If we are able to adopt a tool that also supports code review (such as Phabricator), that could make the integration between code review and tasks more smooth (e.g. there could be one thread for discussion, rather than both Gerrit cover comments and Bugzilla comments). Superm401 - Talk 02:48, 16 January 2014 (UTC)
 * Using a FOSS tool means we can adapt it to our needs and enhance it more easily. This is particularly true if the tool is written in a language many MediaWiki engineers are familiar with (e.g. Phabricator is written in PHP). Superm401 - Talk 18:45, 16 January 2014 (UTC)

Technical activities
What are the main technical activities you're involved in in the Wikimedia community?

Team facilitation (mobile web engineering), agile coaching, Mediawiki extension development (MobileFrontend primarily), process tools development (eg Bingle)

Workflow
The workflow depends on specific activities and needs at the moment, but the overall team workflow for new feature development:
 * New feature ideas get captured as user stories in Mingle, new cards are added by default to our quarterly backlog
 * Every iteration, the team (engineering, design, product) selects the work to be done for the upcoming iteration by pulling stories out of the quarterly backlog. We have a special view in Mingle to facilitate this, showing our quarterly backlog, the current iteration's backlog, and the upcoming iteration's backlog. If there is work we want to do but no story card defined, we create a new story on the spot and add it to the appropriate backlog.
 * When stories have been selected, the team works to fully flush out the stories with a clear user narrative, acceptance criteria, and designs - all done in Mingle (design happens externally, but assets are associated with the cards in Mingle).
 * The engineers on the team estimate the relative effort required to complete each story; the estimate gets recorded on the card. During estimation, lots of conversation happens that usually results in deeper clarification of the work that needs to be done, unknowns and assumptions get surfaced, etc. We use a tool called 'hatjitsu' to facilitate estimation (http://hatjitsu.wmflabs.org/)
 * Throughout the planning process, the 'product owner' (product manager working with the team) prioritizes the work to be done by rank ordering the stories in Mingle.
 * When stories are considered good enough to begin work on by the engineers, cards are given a status of 'ready for development'
 * When the iteration is kicked off, any unfinished stories from the previous iteration gets pulled into the new iteration (pending product owner approval), and reprioritized against new work to be done
 * Work does not get assigned to the engineers. Rather, when an engineer is ready to begin work on something, they drag a story out of the 'ready for development' column in Mingle into an 'in development' column. Mingle automatically marks story as 'owned' by the person who dragged the card into 'in development'. That engineer is then responsible for the completion of the work in that story. That doesn't mean they necessarily do all the work, but they make sure it gets done.
 * When work on a story is complete, the story is moved to a column of 'needs code review', and the story's status is updated appropriately. When this happens, Mingle prompts the user for any pertinent links - we use this to add links to specific patchsets in Gerrit that need review
 * Engineers then work through code review in Gerrit. When all changes associated with that story are merged, the engineer then moves the card into 'Ready for signoff'
 * The product owner periodically reviews the 'ready for signoff' column on our story wall in Mingle, and does what s/he can to review whether or not the work has been completed. Work is known to be completed when all acceptance criteria in the story are met. If the work is acceptable, the product owner moves the card into the 'accepted' column in Mingle. If it is not acceptable, then the product owner punts it back to 'ready for development' and alerts the engineer(s). If the product owner can't verify the work on his/her own, they reach out to the engineer(s) to demo the code.
 * While all this is happening, the team meets 3x per week for 15 minute long 'standup' meetings. The group huddles around our story wall (mingle loaded up on a big monitor), and each engineer answers three questions in turn: 'what have you been up to since we last met?', 'what do you commit to do before we meet again?', 'what is blocking you?'. During this time, we also triage any bugs that have been reported since we last met. Bug cards (which automatically get imported from Bugzilla into our Mingle project via Bingle) are either thrown into a generic bug backlog to be dealt with later, put into the current iteration and prioritized against existing work, or put into the next iteration to get resolved then.
 * Over the course of an iteration, the team's velocity gets automatically recorded by Mingle. That is, the relative estimation points assigned to all stories that get put into the 'accepted' column on our story wall are summed up. This is our team's velocity. We use this number, averaged over time, to determine how much work we can realistically take on during an iteration

This is, in a nutshell, how our team manages our work around new features and bugs. There are of course anomalies and deviations, but this is the overall gist.

Must be able to do
Using the workflow you've described above, can you tell us everything you must be able to do?


 * I must be able to manage and track new features and bugs from the same tool
 * I must be able to use the tool to search for existing stories and bugs by status, iteration, backlog, asignee, tags, title
 * I must be able to track the status of each story/bug
 * I must be able to quickly visualize the status of all work in a given iteration
 * Anonymous access to view bugs/features must be supported, ideally without requiring any kind of user account
 * I must be able to track estimations
 * I must be able to view our velocity - for a particular sprint as well as over an arbitrary length of time/number of iterations
 * I must be able to leverage an API for integrations with other tools
 * I must be able to give users variable levels of access (eg read-only, create/modify stories, administer project settings)
 * I must be able to rank order the priority of bugs and stories, and do this across types (eg not only prioritize stories and prioritize bugs, but also prioritized bugs/stories relative to eachother)
 * I must be able to enforce certain actions be taken when a card's status changes (eg ensure ownership changes happen seamlessly when a card's status changes; ensure that comments be added when a particular status gets updated)
 * I must be able to generate a burnup/burndown chart
 * I must be able to export all of our data (users, stories, etc) in a generic/commonly used format (eg csv)
 * I must be able to access this tool at any time, from anywhere (of course so long as I am connected to the internet)

Would like to be able to do
Similarly, can you tell us everything you would like to be able to do that would make your work easier?


 * I would like to have bugzilla/gerrit integration - that is, with minimal manual intervention, be able to track bugzilla bug status/comments/etc, automatically associate specific patchsets in gerrit with a story/bug, etc
 * I would like it to be clear when someone else is updating a story or bug (like, updating the text of the description). Even better, it would be awesome if there were real-time updates to story/bug descriptions and status changes (eg I wouldn't have to refresh a story to see new changes or refresh the wall to see an items status update)
 * I would like to easily flag when a particular story/bug/task is blocked by something
 * I would like to be able to easily define/show relationships between stories/bugs (eg story a has a dependency on story z; story c is related to bug y)
 * I would like to be able to track arbitrary aspects of our projects (eg there were x bugs introduced in y time period, or on average over the last 6 iterations we've seen y bugs introduced)
 * I would like to be able to export arbitrary chunks of data in a generic/commonly used format (eg csv)
 * I would like a mobile application or mobile-friendly web interface for the tool
 * I would like notifications based on arbitrary property changes - eg a story has been moved to 'ready for signoff' and I receive an email alerting me to this fact
 * I would like to be able to define arbitrary properties for card types

Technical activities
Research and Analytics. I support product teams with experimental design and analysis to vet new features. I perform independent research to identify trends and opportunities for making the wiki work better. I also interact with the academic community as a representative of the WMF by publishing papers, reviewing for/participating in conferences and forming collaborations with external researchers.

Workflow

 * 1) I compress a problem/issue/opportunity/feature/theory into a "Research Question".
 * 2) * e.g., How successful are newcomers in creating pages in Wikipedia?
 * 3) I come up with some hypotheses that are testable.
 * 4) * e.g., Newcomers who create drafts (rather than direct to main namespace) are more likely to (1) have their article accepted once moved and (2) more likely to be retained as a long-term editor.
 * 5) I design metrics and other proxies that allow me to observe human behavior in the data.  Usually "the data" is the MySQL database behind a MediaWiki installation.
 * 6) * e.g., meta:R:Edit session
 * 7) I write a set of scripts (usually in python) to extract and transform the data in order to build metrics.  At this point, my goal is to get an understand for the "space" that these metrics and their corresponding behaviors occupy.  This helps me identify mistakes I've made and get a sense for the context.
 * 8) * e.g., https://bitbucket.org/halfak/wikimedia-metrics
 * 9) I load these datasets into an R session and produce plots, statistics and models that help me test my hypotheses.  These outputs as well as my thoughts get logged on a Meta Wiki talk page.
 * 10) * e.g., meta:Research_talk:Module_storage_performance
 * 11) When I think I've "learned something" (i.e., I've effectively tested my hypotheses), I turn my notes into a writeup that summarizes the critical methods, stats, and visualizations into a proper meta wiki page.
 * 12) * e.g., meta:Research:Module_storage_performance
 * 13) Finally, I'll present these results to the Wikimedia foundation (e.g. [[Media:Anonymous_editors_-_WMF_R%26D_showcase_(Dec._2013).pdf]]), the volunteer community (e.g. ) and/or the academic community (see ).

Must be able to do

 * Extract the data we keep for analysis (MySQL, Database dumps, Request logs, etc.)
 * Run processing code on WMF servers with a large amount of ram and # of cores
 * Bounce ideas off of product managers, other researchers (WMF and external) and devs
 * Track & prioritize open research questions
 * Regularly meet with other researchers to discuss new work
 * Work for 2-5 hours per day without interruption (asynchronous collaboration)

Would like to be able to do

 * Break complex problems into recognizable units of work so that it doesn't look like I'm sitting on my hands for a week at a time
 * Document generalizable results in a way that someone else can find them and make use of them after I'm gone.
 * Get regular feedback from PMs on research that lead to generalizable results.

Technical activities
Software Development and Engineering

Workflow
Development Process

Tools

 * Tickets: Bugzilla
 * Distributed Version Control: Gerrit and Github
 * Code Review: Gerrit
 * Testing
 * Frameworks: Selenium, QUnit, PHPUnit
 * Continuous Integration: Jenkins and Travis
 * Dependency Management: Composer
 * Gating: Zuul
 * Agile Project Management: Office Whiteboard and Scrumbugz in Evaluation
 * Analytics: Scrutinizer

Must be able to do

 * Continuously Develop Wikibase/Components
 * Coordinate with Foundation Deployment
 * Respond to Community
 * Manage Resources for WMDE Internal Software Development Projects

Would like to be able to do

 * Organize Tickets with Agile Method (e.g. Scrumbugz)
 * Develop Analytical Methods and Tools for Resource Availability and Visualization with Agile
 * Monitor and Report Project Results and Objective Criteria Achievement
 * Consolidate and Manage Documentation for Internal and External Purposes

Technical activities
I'm here and there.

Workflow
I mostly watch IRC and occasionally check my e-mail inbox. This system works fairly well.

Must be able to do
Code development (file bugs, review code, etc.).

Would like to be able to do
Magic.

Technical activities
MediaWiki core development, MediaWiki extension development, continuous integration setup and configuration, work on various bots, work on other tools, deployments

Workflow

 * Core/extension development:Usually I'll pick a card off of a Mingle wall, or pick a bug out of a list. Then, I'll analyse the situation, note that I'm claiming the bug or card, create a new branch in my local git repository, and start work. When work is done, I'll run git-review to put the change into Gerrit, ideally with a bug number, else with a link to a card. Then, I'll note in the card or bug report that there's a patch awaiting review, and wait. Finally I'll address any issues and push to get the patch merged.
 * CI setup and configuration:For the most part this work gets done when we realize we need to do it - there's not really any planning, it's just an immediate feedback situation. A need arises, someone pushes a patch, self-reviews, then deploys.
 * Bots and other tools:Generally this will happen on a very limited timeframe, and the only organization that will happen is over IRC - no bugs or cards to speak of. If anything, it might happen over GitHub issues.

Must be able to do

 * THERE CAN BE ONLY ONE.
 * Query tickets by project, component, team, owner, status, tags, difficulty...
 * Have custom tags

Would like to be able to do

 * See items by status in a grid - Mingle has corrupted me (but we could probably hack this together relatively easily)
 * Have customizable values to set in each ticket
 * Attach code to tickets
 * Have new contributors be comfortable with the interface

More information
I really like the idea of using GitLab for most of this. It has a very GitHub-like interface, which contributors will appreciate. There are definitely some evaluations that need to happen before we can switch, but I think the centralization of issue tracking and code review is a good plan in general.

Technical activities
Operations, Puppet (operations/puppet repo on Gerrit), RT (ops requests), Bugzilla setup and some usage, code review, production deployment, Labs support, general requests like mailman, aliases, maintenance, misc.

Workflow
First, I check RT for new activity. I have widgets on my dashboard showing me "newest unowned tickets" (requests from external) and "operations activity" (what my team mates did). We also have separate "queues" in RT so i can just check "ops-requests" or "core-ops" or "domains" depending on the type of ticket.

Then, if i have a comment I reply to that, and if I think I have a technical solution/patch for an open issue, i either:

- submit a Gerrit patch set with a suggested fix, and: -- add the affected people (requestors, other stakeholders, seniors where needed) as Gerrit reviewers (this creates mail to them asking them to please look at it) -- make sure the affected people are added on the RT ticket (also so that they get mail about it) -- paste the Gerrit URL to the patchset into the ticket

If there is a Bugzilla ticket I do the same thing but with the BZ bug.

If there are both, Bugzilla and RT, tickets, i link them both in Gerrit and to each other, or at least I try to when i notice them.

Then this patch hopefully gets some +1's from others in code review and finally gets merged.

In the case of Bugzilla bugs I don't have to do much else if i didn't forget to mention the bug number in the message. That gets me auto-updated tickets when something is merged. In RT I change the workflow step to "resolved" once something is really done. That also means _really_ deployed, not just suggested. In BZ I change the workflow step to "resolved" to _claim_ it should be done, but I appreciate it when others (ideally the requestor) confirm my claim and then switch to the final step "verified".

Besides that i get a lot of requests on IRC and in my personal inbox.

For IRC requests I try to follow basic GTD principles, like "if it takes under 5 minutes do it right away, if it takes longer create a ticket, no exceptions". That means i try to politely ask people to create tickets (mail to ops-requests@RT) which is also listed in the IRC channel topic of operations. Then I try to process them in the order of coming in, I use the RT web ui for that as explained above. Sometimes I think it's unfair when there are tickets that have been sitting there for long but others are processed first because people ping more on IRC about them. Sometimes ops does sprints together with the specific goal of just looking at _old_ tickets to make sure. Sometimes I also change the sort order in RT to show me oldest things first for that. When i get requests in my personal inbox I just forward them to RT because having a single place to have my requests is very important to me. It's also very important that others in my team see what I'm doing and there is no SPOF.

Must be able to do

 * I must be able to track requests to my team and me in a web-based UI that is specifically made for tracking requests. (note: software bug reports are just a subset of requests, bugtracker tools are specialized version of request trackers).


 * I must be able to link requests or bugs to code changes in an easy way.


 * I must be able to add people/reviewers to a specific bug/request/code change and make sure they're notified about it in some way we all agree on.


 * I must be able to expect that everybody I work with actually uses and agrees with the tools we have chosen to work with and doesn't boycott them.


 * I must be able to link to my own work log in an easy way to answer the question what I've been doing by just providing one or a few URLs.


 * I must not duplicate my actions in multiple tools if it can be avoided.


 * I must be able to know what exactly the tool does and at least have a possibility of fixing it if necessary, that means: must be free and open source software and _not_ outsourced.


 * I must be able to see progress on tickets and what others are doing if I'm the requestor and I request it from another team.


 * I must be able to organize requests/bugs in some way by topic (queues, tags or similar).


 * I must be able to hide some tickets from the public for special cases.


 * I must be able to give access to certain groups of tickets to certain groups of people. (group/role-based permissions)

Would like to be able to do

 * Handle Operations and OIT tickets in the same system (again).
 * Have more replies by people on Gerrit itself when i just add them as reviewers. (I think many people filter this out). I think in many cases the whole discussion could just be on a Gerrit change, where the actual code is being changed. Actually it would be even better than having 2 tickets and a change and having either some info here and some there, or duplicating everything all the time
 * NOT see tickets that are just closed as "fixed" without giving details on what has actually happened
 * NOT have to additionally spend time on repeating what i did on Etherpads/wiki pages/lists/tech reports or any new kind of project management tool when all the info should already be in the tickets (but for that everybody would actually have to use the same tool, i know)
 * NOT have to ping people on IRC, mailing lists/wikis to get reviews on Gerrit (or have the choice of just merging without reviews)
 * NOT be expected to be on IRC and available for real-time requests except in _real_ emergencies
 * NOT get requests in my personal inbox
 * NOT have to find information on Google docs,wiki pages, list archives or any other kind of place besides the actual ticket if it belongs there