[teampractices] Project management tools evaluation

Andre Klapper aklapper at wikimedia.org
Fri Dec 13 17:51:51 UTC 2013

tl;dr: 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 at https://www.mediawiki.org/wiki/Talk:Project_management_tools

Longer version follows:


Wikimedia projects currently use Bugzilla, RT (Operations), Mingle
(Mobile frontend, Fundraising, L10N), Trello (Growth, 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) [1]. Some teams have moved from one tool to
another and some use several tools for different tasks. Pivotal/Fulcrum
were brought up [2] and interest in Redmine has been expressed before

An initial attempt at evaluation took place in 2009-2010 [4].

Matt Flaschen set up
https://www.mediawiki.org/wiki/Project_management_tools that summarizes
aspects of recent discussions.

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 gruntwork.

[1] http://lists.wikimedia.org/pipermail/teampractices/2013-October/000087.html
[2] http://lists.wikimedia.org/pipermail/teampractices/2013-November/000134.html
[3] http://lists.wikimedia.org/pipermail/wikitech-l/2010-June/048080.html
[4] https://www.mediawiki.org/wiki/Tracker/PM_tool

== 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 [5] and [6] 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.

[5] https://www.mediawiki.org/wiki/Git/Gerrit_evaluation
[6] http://lists.wikimedia.org/pipermail/wikitech-l/2012-July/061741.html


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:
1) 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 at
If you want to make sure you don't miss part of the discussion, please
sign up (~Dec 2013)

2) 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)

3) Andre and Guillaume (and others if interested) will document those
discussions and the information gathered on mediawiki.org (by end of
Jan. 2014)

4) Collectively agree on a short, constrained list of candidate tools
that meet most requirements, to further investigate. (~Jan 2014)

5) First implementation steps (might or might not come in the form of
prototypes on Labs, RobLa and ECT to clarify resourcing). (~Feb 2014)

6) Set up an RfC. Collectively test candidates. Intensely discuss for a
short, bounded time, and make a decision (~Mar 2014)

7) Andre and Guillaume will communicate the decision.

8) 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.


The single most important thing you can do is share your experience 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.

Looking forward to your feedback and comments!

andre (and Guillaume and Quim)
Andre Klapper | Wikimedia Bugwrangler

More information about the teampractices mailing list