Project management tools/Review

Group:	Platform
Start:	2013-12-15
End:	2014-05-11
Team members:	Guillaume Paumier
Lead:	Andre Klapper

Phabricator

Help

Edit

Rationale

The Wikimedia technical community is currently using plenty of different tools for tracking bugs / product management / project management / todo lists. Some are open source and others are proprietary, some are self-hosted and others are hosted by third parties, and all in all the multitude of tools and channels makes it difficult for both staff and volunteers to keep track of what's happening. They also all have their own limitations.

Our goal here is to start a discussion about a possible agreement on a smaller set of tools that teams would agree upon, which would make collaboration and maintenance, and possibly to be better aligned with the values of our movement. This discussion originally started on the teampractices mailing list, but it warrants a wider set of voices. Guillaume and I will try to facilitate the discussion and ensure it doesn't remain Yet Another Pretty Idea.

This discussion is not about forcing teams to abandon a tool that they're using successfully, or forcing anyone to use a tool if they don't have a use for it.

Please help by sharing your experience / needs / frustrations with those tools on the discussion page.

Problem definition

Wikimedia projects currently use Bugzilla, RT (Operations), Mingle (Mobile frontend, Fundraising, L10N), Trello (Growth, Flow, Mobile apps), JIRA (Toolserver), and maybe more tools for product and project management-related tasks.

Our current tools have limitations, e.g. regarding development methods and workflows (Agile/Scrum). Some teams have moved from one tool to another and some use several tools for different tasks. Pivotal/Fulcrum were brought up and interest in Redmine has been expressed before.

An initial attempt at evaluation took place in 2009–2010.

Furthermore, potentially reducing the diversity of our PM tool landscape might facilitate better collaboration and exchange between teams in the long run, and avoid spending less time on grunt work.

Scope

The aim of this discussion is to find a common (set of) tool(s) that the Wikimedia development community can agree to use in the long term, and to work towards this goal. Currently, the two only tools that seem to be agreed upon across the board are Bugzilla for bug reports (and to some extent enhancement requests) and Gerrit for patches (see here and here for past Gerrit evaluation).

There are three types of activities considered here: Bug tracking, feature tracking and project/product management. These three types are not necessarily covered by the same one tool and they sometimes overlap.

The discussion is focusing here on development, i.e. the needs of developers, maintainers and managers. Support ticket systems (OTRS) and fundraising setup (CiviCRM) are out of scope.

The goal is not to force any team to use tool X as different teams have different needs. However, there is an intrinsic value in having reference tools identified: offering a default setup to any project, focus our support in tools documentation and bugfixes and, eventually, develop/contribute new features to make these tools even more suitable for our work.

Proposed steps

This whole discussion is basically a product discussion: We need to research use cases, document workflows, identify requirements, and then collectively determine the solution(s) that best fit our needs.

The most important part here is that, in order to have good, relevant information about how people use the tools, we need to identify the different workflows, and document and summarize them properly. We can't do that unless you, the users, help us by telling us how you use the tools, and what your needs and pain points are.

Here's a proposed plan:

Determine who's particularly interested in this discussion and/or is a stakeholder. Anybody can discuss, but we want to make sure that the key users of these tools are well represented. There's a list below; if you want to make sure you don't miss part of the discussion, please sign up (~Dec 2013). Status: Done
Andre and Guillaume (and others if interested) will meet with people listed there, to understand their workflows, determine requirements, identify issues, etc. (How does dev team X use a tool effectively, what are problems?) (Dec. 2013 - Jan. 2014). Status: Done
Andre and Guillaume (and others if interested) will document those discussions and the information gathered on mediawiki.org (by end of Jan. 2014). Status: Done at Project management tools/Review/Requirements
Collectively agree on a short, constrained list of candidate tools that meet most requirements, to further investigate. (~Feb 2014). Status: Done at Project management tools/Review/Options
First implementation steps (might or might not come in the form of prototypes on Labs, RobLa and ECT to clarify resourcing). (~Feb−Mar 2014) Status: Done
Set up an RfC at Requests for comment/Phabricator. Collectively test candidates. Intensely discuss for a short, bounded time, and make a decision (~Mar 2014) Status: Done
Andre and Guillaume will communicate the decision. Status: Done
In the long run, the Platform engineering group will be responsible for implementing the decision.

The Engineering Community team, and more specifically Guillaume and Andre, will facilitate this discussion. We will make sure that all relevant ideas and decisions are documented, and we will do our best to push the discussion forward until we all reach a community decision.

We will not, however, make any "official" decision; we believe that the decision should be made collectively by the Wikimedia technical community. Our goal is to help the community make that decision.

How you can help

The single most important thing you can do is share your experience on the discussion page with the tools you use or have used. You can help by providing thoughtful input, especially if you have experience and expertise with specific tools. Providing references for statements is welcome to get a deeper picture and shorten discussions. Please follow the rhythm of the discussion. Let's agree first on big factors and then let's move onto the details when needed.