IT Development/Proposals/Project Management

From Wikimedia UK
Jump to navigation Jump to search
IT Development
Main pageInfrastructureDocumentation / ToolsPortfolioTechnology CommitteeProject requests

This document outlines some of our choices in relation to project management. Katherine has indicated that RT does not provide the full feature-set of tools that are needed by staff. To ensure we pick an adequate tool in the future, I am outlining three potential options along with pros/cons.

Bugzilla[edit | edit source]

Requirements: Perl Example: WMF Bug Tracker


  1. Used by the Foundation, so the community may be familiar with it and makes working with the foundation easier
  2. Can restrict access to certain groups of bugs/features (useful for making the tool public access); a little rudimentary
  3. Reasonable set of 3rd party plugins for various things, such as:
    1. Project management
    2. Good integration with Source Control Management (GIT) - for developers :)
    3. IRC integration
  4. Active development
  5. Advanced Queries


  1. Specifically a bug tracking tool
  2. Lacks some of the advanced PM features we might need without third party plugins (e.g. No real "roadmap" feature, time/feature planning, lacking a lot of graphs etc.)
  3. Can have a complex interface (subjective)
  4. Requires another programming language (Perl) on the server

Redmine[edit | edit source]

Requirements: Ruby Example: Redmine Issue Tracker


  1. Explictly a project management tool
  2. Roadmaps, time planning, and additional features such as wiki and source control tracking built in
  3. Tracking can be organised into discrete "projects"
  4. Ruby is already installed & used in our SCM tool (RhodeCode)
  5. WMF considered switching to it; as far as I can see they decided that they were too involved in Bugzilla for it to be beneficial, but they did seem to approve of it.
  6. Inbuilt integration with GIT/Mercurial source control


  1. Plugins directory is not so good
  2. Access control is really per-project, slightly worse than Bugzilla
  3. Probably not as "mature" as Bugzilla
  4. Not a tool that the WMF actively uses
  5. "New" tool for the community to get used to

Semantic Wiki[edit | edit source]

Heavily customised Media Wiki installation with semantic properties and project management tools.

Various Options: CcTeamspace (extremely slick), Semantic Forms plus Semantic Project Management Pros:

  1. Focus on versioning, collaboration and good history tracking
  2. Familiar interface
  3. Extremely powerful customisation options (e.g. this WMF-supported OpenStack plugin which could be used to help control our servers from within the PM tool).


  1. No SCM integration
  2. The most complex to set up; requires lots of plugins
  3. To some extent the weakest access control; however with plugins it could be quite powerful (the only one to allow per bug restrictions..)
  4. Unexpected use of Media Wiki
  5. Some of the plugins needed are unmaintained, might be an opportunity to take over maintenance and contribute back to MW.

Summary[edit | edit source]

All three tools have something going for them. Bugzilla is a very strong technical tool with advanced querying and really tight integration with email, but it lacks a certain amount of project management "polish" and can sometimes have a complex interface. This can be remedied with plugins.

Redmine is more focused on project management, and it's issue tracker is not technically as good. However it does allow really discrete organisation into "projects", which might be useful for delineation. The access control is something to be desired, but not dramatically worse than Bugzilla.

Semantic Wiki has the benefit of being an interface even our least technical members have familiarity with - and provides a consistent "face". It also allows for broader wiki use (which is appealing) to record technical details (like these pages!). The downside is it requires extensive customisation, and access control is probably the weakest of the three options. Also, the projects are unmaintained (however, this might be a benefit in giving us the opportunity to support the Media Wiki infrastructure by taking over their development).

Work requirements[edit | edit source]

Setting up any of these three tools is possible by the end of February. Semantic MediaWiki option would probably take longer in terms of time commitment due to the need to ensure compatibility etc. but still possible in the time frame.

I have no specific recommendation; all three options probably meet what is needed from a technical perspective, it depends on the staff's requirements and preference.