Wikimedia at KDE Akademy 2010

Posted on July 22, 2010 by Guillaume Paumier

Three weeks ago, I attended the KDE Akademy 2010 conference in Tampere, Finland. My colleague Parul also came along. We gave a talk entitled Wikimedia User Experience programs: lowering the barriers of entry. Basically, we presented the work done as part of the Wikipedia usability initiative, and the Multimedia usability project.

went to akademy2010 Wikimedia at KDE Akademy 2010

and it was fun.

Shared values & challenges

It might seem odd for Wikimedia to be presenting at KDE Akademy: Wikimedia is mostly about online content, while KDE is mostly about desktop software. Yet, they share common goals & values.

On the one hand, a common criticism made against KDE is its feature creep: the tendency to allow for maximum customizability in KDE often comes at the price of simplicity and ease of use.

On the other hand, MediaWiki, the software on which rely Wikipedia and the other Wikimedia websites, suffers from the same flaws: it has always been “designed” by developers. As a consequence, the interface reflects the implementation model, and often doesn’t match, or even conflicts with, the user’s mental model. The Wikimedia Foundation recently started to include user research and design as part of their development cycle, where user experience is taking a increasingly critical role.

Our presentation at Akademy was an opportunity to share experience. Both KDE and Wikimedia communities struggle to improve complex interfaces, and both communities have a lot to learn from each other.

Wikimedia and KDE also have more practical ties: Wikimedia Deutschland e.V. and KDE e.V. used to share an office a few years ago. I’ll take this opportunity to thank Claudia Rauch for inviting us to submit a proposal for Akademy this year.

Presentation slides & video

Thanks to KDE e.V. and their awesome volunteers, the full video of our talk (and the follow-up discussion) is available, along with all the other videos, from the Akademy schedule page. A slightly edited version is also available from Wikimedia Commons; you can also download the file to your computer (Download – OGV, 162 MB). Or, you can watch it below, if it works.

The presentation slides aren’t very useful alone, but they’re also available on Commons if you want to take a look or watch them alongside the video (Download – PDF, 2.2 MB).

Meeting the KDE community

I’ve had some interaction with the KDE community before. I used to live in the same city as one of the lead KDE developers, and we belonged to the same LUG. I’m also familiar with the digiKam community, with whom I’ve been working on and off.

Besides our presentation, Akademy was also an opportunity to get together with the “gearheads”, to discuss collaboration opportunities, and of course to get my debugging duck.

Qt duck950 590x442 Wikimedia at KDE Akademy 2010

« Take the duck from your desk, look at your code and explain to the duck - line by line - what it does. »

Working hand in hand

We had planned to hold a more hands-on workshop to discuss practical common projects between the two KDE & Wikimedia communities. Unfortunately, I had to leave Tampere early to fly to Gdańsk for WikiSym & Wikimania. I didn’t have much time to explore the city either, which is a pity; Tampere is a quaint little city, and the surroundings looked really charming.

I would still like to work on common projects, as I think there’s a huge potential for a better integration of Wikimedia websites with the desktop. Since I’ve been thinking about this for a while, I have a few ideas of my own: mass upload tool, offline wiki editor, desktop widgets (e.g. for Wiktionary, FAOTD, POTD), application plugins (e.g. to find media files from Commons from within an application), instant messaging with other Wikimedia editors, etc. That said, I would also like to collect ideas & feedback.

So, what Wikimedia content would you like to access from your desktop? For what use? What desktop tool would facilitate your editing or reading of Wikimedia projects?

Posted in Featured, KDE, Wikimedia Technology | Tagged , , , , , , , | 3 Comments

State of the language selection in MediaWiki and Wikipedia

Posted on June 26, 2010 by Guillaume Paumier

This article is meant as an introduction to my next article, about language selectors, which is the one I originally intended to write. As it was growing longer and longer, I decided to split this review into a dedicated post.

There are two main use cases for language selection across Wikimedia projects: the language of the content, and the language of the interface. In this article, I am reviewing a few examples of tools related to language selection on MediaWiki websites, and particularly on Wikimedia wikis.

Interface language selection

Language setting in user preferences

On each MediaWiki website, users who create an account can select the language of the software interface. That means, for example, that you can read Wikipedia articles in Italian, but with the interface in French. This feature is particularly useful for Wikipedia participants who are familiar with the interface in their mother tongue.

language selector prefs State of the language selection in MediaWiki and Wikipedia

Drop-down menu from MediaWiki's user preferences to select the language of the interface

The default language for MediaWiki messages is English. The localization of MediaWiki has been made possible with the translatewiki.net platform (former “betawiki”) and the hundreds of volunteer translators who try to keep up with the ever changing MediaWiki messages. And they’re doing a terrific job.

This language setting, though, only works for registered users. If you’re only a reader and you don’t have a user account, you’re stuck with the default language specified for the website. Usually, the default interface language is the same as the content language, and most readers are content with that.

The problem comes with multilingual wikis, i.e. wikis that contain content in several languages. For example, Wikimedia Commons, Wikimedia meta-wiki and the Wikimedia Foundation website are multilingual wikis; they are central places for Wikimedians from all projects in all languages.  Only one interface language can be used as the default, and it’s generally English. If you can’t read English and you’re looking for media files on Wikimedia Commons, you’re going to have a hard time navigating the site.

The uselang parameter

A workaround is to use the uselang parameter to specifically ask MediaWiki to render the interface in a given language1. An example of its use is the “Commons” template, used on some Wikimedia projects to provide a visible link to the Commons page or category about a specific topic. If you’re reading the Catalonia article on the German-language Wikipedia, and scroll to the bottom, you’ll find a link to Commons directing you to the Catalonia category on Commons, but with the interface in German.

This method has obvious drawbacks: first, you need to actually know it exists, and how to use it. You also need to know the ISO 639 code of the language, but if you know the uselang parameter exists, I’ll assume you know that language code as well.

More importantly, the uselang parameter isn’t persistent, i.e. it will go away as soon as you leave the page you were viewing. There’s an open bug to preserve the uselang parameter during sessions (bug 4125). But for now, if you land on a page rendered in a specific language using uselang, it’ll revert to the default language as soon as you move away from that page.

LanguageSelector extension for MediaWiki

Going a bit further, Daniel Kinzler developed an extension for MediaWiki called LanguageSelector. The first feature it provides is to automatically detect the browser language2 of unregistered readers and defaults the interface to their language.

Such an automatic system would be desirable for some Wikimedia websites, especially Commons, but it requires scalability improvements: it would fragment the cache, on which we rely heavily for performance. Nonetheless, it’s an issue that’ll have to be addressed in any case.

The LanguageSelector extension also provides a drop-down selector that can be included in pages. This setting seems to follow the user at least during the session. You can see an example of it used on the home page of translatewiki.net.

langselect mwext State of the language selection in MediaWiki and Wikipedia

Drop-down language selector from the LanguageSelector MediaWiki extension

Content language selection on monolingual wikis

Wikipedia.org portal

Wikipedia and most other Wikimedia websites are available in many different languages — over 250 at the time of writing. And that’s just existing Wikipedia editions; several thousand languages are spoken across the world population.

On monolingual wikis (i.e. wikis whose content is in only one language), there are two occasions where you may want to select a language: the first is when you choose what site you want to visit, e.g. Wikipedia in English or Wikipedia in Spanish. The second occasion is when you want to navigate from one language edition to another, e.g. from Wikipedia in English to Wikipedia in Spanish.

On Wikipedia, the first choice happens on the multilingual wikipedia.org portal, if you ever happen to go there.

Wikipedia.org portal 590x434 State of the language selection in MediaWiki and Wikipedia

Screenshot of the Wikipedia.org portal

On this (manually curated) portal, each language is displayed in the language’s language3: English is displayed as “English”, German as “Deutsch”, French as “Français”, etc. The sorting order is based on the size of each language edition, measured in number of articles. In a word, the bigger the Wikipedia, the more prominent the place. “Small” Wikipedia editions are at the very end of the list.

In most cases, though, you don’t have to make this choice; your search engine conveniently directs you to the language edition of Wikipedia in your language. Once you are on a specific language edition of Wikipedia, though, you can still navigate to related articles in other languages, using interlanguage links.

Interlanguage links

Interlanguage links are a specific subset of interwiki links; they allow users to navigate between different language versions of the same page.

Links and their order are curated by humans or “bots”, i.e. external programs that interact with the software as humans would, but are not part of the MediaWiki software

interlanguage links apple State of the language selection in MediaWiki and Wikipedia

List of interlanguage links of the Apple article on Wikipedia in English, and the wikitext that generates them

The sorting order differs from a Wikipedia to another; they have different standards. That means interlanguage links will be sorted in a different order, whether you’re reading an article on the Polish Wikipedia, the Finnish Wikipedia, or the Serbian Wikipedia. Convenient, eh?

The default behavior for interlanguage links is to display all the available links. For the most common topics, the list can grow quite long. The main page, for example, is the page all language editions are sure to have in common. The interlanguage list for the main page is usually truncated by Javascript in order to avoid having 250 links there.

interlanguage links main page enwp State of the language selection in MediaWiki and Wikipedia

List of interlanguage links displayed on the main page of Wikipedia in English

Content language selection on multilingual wikis

Multilingual wikis

Wikipedia editions exist in only one language at a time. It’s the same for most of the Wikimedia websites, like Wikisource or Wikibooks. Some projects, though, are meant to be a central place for all Wikimedians.

For example, Wikimedia Commons (“Commons”) is the central media repository for all Wikimedia projects. Rather than duplicating media files on all of them, they’re centralized into one media library.

Wikimedia meta-wiki (“meta”) is another multilingual wiki. Its purpose is to serve as a central coordination platform for the Wikimedia community.

Both these wikis are “multilingual”: they host content in a variety of languages. But MediaWiki wasn’t originally designed for such a use; it was designed to host content in only one language. The community has had to work around this limitation by implementing various tricks & hacks.

JavaScript language select tool

For a few years, meta has been experimenting with the Language select tool. Language select is a JavaScript hack4 that basically hides the text that isn’t in the language you’ve selected.

There too, you have to know the ISO language code, and the user interface isn’t very intuitive, but it was a start. The newer JavaScript method detects the language of your browser automatically.

language select meta State of the language selection in MediaWiki and Wikipedia

Screenshot of the language select JavaScript tool on meta-wiki

A similar system is also available on Commons, through the Multilingual description template. As far as I know, though, this template is very rarely used; instead, individual language templates are the standard way of labeling (and sometimes, choosing) content in different languages.

Language templates

Language templates are used to specify the language of a specific part of a content’s page, for example descriptions of a picture on Commons. They also allow registered users to hide content they don’t understand, by specifying a “blacklist” of languages they don’t want to display. It’s particularly useful for Featured pictures, or Pictures of the Day, that contain many translations for the caption.

language templates 590x103 State of the language selection in MediaWiki and Wikipedia

Description of a Picture of the Day on Commons in various languages

Langswitch & Autotranslation

Langswitch and Autotranslate are two similar methods used on Commons to show a given text depending on the user’s language (as specified in their preferences). They’re more elaborate systems than Language select and Language templates, but they essentially try to address the same issue.

Langswitch is more lightweight and used for simple templates: all translations are contained in one page. For example, the “France” template on Commons uses Langswitch; it includes the translation of the word “France” in all available languages, and provides a link to the appropriate article in the associated language edition of Wikipedia. If the user’s language is German, they will only see “Frankreich“.

Autotranslate is used for heavier templates that contain more text; in this case, it is easier to segregate the translations into dedicated subpages. This is how license templates have worked (although they’re now being replaced, see below).

A template using Autotranslate (called “autotranslated template”) typically consists of a subpage defining the template’s layout, and a subpage for each translation of the template’s messages. The “PD-self” template is autotranslated, for example; it has a layout subpage, and subpages for all available languages, such as English, Japanese and Russian.

The {{int:}} MediaWiki “magic word”

{{int:}} is a MediaWiki magic word used to show a MediaWiki interface message in the user’s language (as set in their preferences). Its main limitation is that it only works for MediaWiki interface messages. Yet, I am placing it into the “Content language selection” section, because it has recently been used to replace Langswitch and Autotranslation.

Using {{int:}} to display something in the user’s language is a more robust system; it’s also the reason for which license templates were converted to system messages (and bundled into the WikimediaLicenseTexts extension).

Basically, in the case of Commons, many templates requiring translation rarely change (e.g., the licensing templates). As templates, they belong to the content, not the interface. But licenses are managed with templates because the software doesn’t provide a built-in interface for them. Ideally, licenses would be managed by MediaWiki itself (or an extension). But we’re not there yet.

So, what’s currently happening is, these licensing templates are being replaced by alternatives that use custom MediaWiki messages. The content that was once stored in the templates is being moved to dedicated interface messages. That way, they can be automatically displayed in the user’s language using {{int:}}. And they can also be translated by the translatewiki.net community.

This system doesn’t solve the issue for unregistered users, though.

Conclusion

There is a multitude of cases where a user may want or come to select a language while navigating a Wikimedia site. They may want to choose in what language the website interface will be displayed, or select the language of the content.

For multilingual Wikimedia wikis like Commons and meta, language selection is a regular issue, because they intrinsically target a multilingual audience. Some ad-hoc systems have been developed over time to try and work around the technical limitations of MediaWiki, but they can’t replace a built-in language management system.

Current language selection solutions also don’t cater for the needs or unregistered readers, who are the majority of the people visiting Wikimedia projects. That issue will have to be addressed at some point if we want to reach a truly global audience.

Another challenge with language selection is the interface you provide the user with to make their choice, i.e. the actual “selector”. It is not obvious what design is the best and allows the user to select the language they want in the most efficient manner. This will be the topic of my next article.

Notes

  1. As a sidenote, the uselang method has also been diverted from its original purpose to hack a Javascript-enhanced upload form at Wikimedia Commons. ↩
  2. For techies: the Accept-Language header. ↩
  3. This is getting confusing, I know. I’m doing my best, believe me. ↩
  4. See http://meta.wikimedia.org/wiki/MediaWiki:Common.js , section “Implements language selection for multilingual elements”. ↩
Posted in Featured, Wikimedia Technology | Tagged , , , | 4 Comments

Why I’m not quitting Facebook…

Posted on May 31, 2010 by Guillaume Paumier

… and I’m neither saying you should, nor you shouldn’t.

twitterised facebook Why Im not quitting Facebook...

Facebook: just another twitter, with more users.

Apparently, it’s Quit Facebook Day. The interwebs have been raging with angry articles about facebook, how it’s turning evil, and violating people’s privacy, etc. My personal opinion is that you’re the best and only guardian of your own privacy.

How it began

The first time I heard about facebook was at Wikimania, in Taipei, in Summer 2007. My friend Delphine was telling me how wonderful it was, because you could use it to centralize your other sharing platforms like your personal blog, twitter (microblogging), flickr (photos), etc.

At first, I was really skeptical, because I didn’t see the point. I was like « I don’t need yet another social site to update and check ». A few months later, I caved and joined.

It’s hard for me to clearly remember my first steps on facebook, because I’ve become an avid user since then. I do remember, though, I’ve never really been fond of the games, quizzes and other farmvilles.

On the other hand, I’ve been truly amazed by the number of acquaintances I’ve been able to find on facebook; people from college, university, high school, junior high school, and even elementary school. I’ve traveled quite a bit during the past 15 years, and it hasn’t been easy to keep in touch. All weren’t close friends, but it was nice to chat again, and meet some of them again “in real life”.

The real issue: Privacy literacy

When I joined facebook in late 2007, I was already quite computer- and Internet-literate. I had been a Wikipedian for a few years then, and I knew The Internet Never Forgets. I had realized whatever I ever wrote in a comment, a blog article, a forum, a mailing list, or a 140-character microblog might one day be dug up or made public.

My use of facebook has also been influenced by my liberal “friendship policy”. As a Wikimedian, I interact with a lot of people online that I’ve never met in real life. Some of them use weird pseudonyms or bizarre animal personae. Yet, I’m closer to some of them than to some classmates from high school. We share a common, powerful passion for free knowledge.

As a consequence, I’ve been using facebook as a microblogging platform. Like twitter or identica, but with many more people, some of them being old acquaintances who would never join twitter.

I knew anything I would put on facebook could end up being seen by people I didn’t know that well. I also knew not all my « friends » were as computer-, Internet-literate and privacy-aware as me. I knew they could, at any time, inadvertently disclose information and content I was sharing with them. So I’ve been cautious about what I’ve been disclosing over the years.

Protect your own privacy

Yes, Facebook is evil, and changed the rules during the game. So what? Facebook is only a tool, and it’s useful to me; I don’t consider anything I share on Facebook will always stay private, so I adapt my use of the tool.

You’re the best and only safekeeper of your own privacy. What you want to stay private, you don’t publish online on a third-party website; you use private means of communications.

I value privacy, and I protect my own. I do so by choosing what I disclose, and whom I entrust it with. I agree not everybody is aware of their privacy (or lack thereof) on the Internet. That’s a larger problem than facebook; the current facebook drama is just a symptom of the issue.

Oh, and of course, I’m definitely keeping a very interested eye on better alternatives like Diaspora.

Posted in General | Tagged , , , , , | 2 Comments

Temporal evolution of the content & participants of Wikimedia Commons

Posted on March 28, 2010 by Guillaume Paumier

As part of the Multimedia Usability project, I have been doing a lot of research to better understand how Wikimedia Commons is functioning, and particularly to understand its users & participants. One side I am particularly interested in is the demographics and the content dynamics of Commons.

In June last year, I summarized my view with the following comment:

The main issue of Commons is that it is growing way too fast. This issue is quite unique in Wikimedia projects: when a wiki is growing, it is usually growing because its community is growing. The issue with Commons is that it is a central repository used by almost all the other wikis; many users on Commons are not regular participants there, they only use it to upload pictures for their wiki and they don’t involve themselves in the local Commons community, which remains limited. As a consequence, this Commons community doesn’t have the human resources to face the workload induced by the growth of the wiki.

In a nutshell, Commons’ issue is that the wiki is growing faster than its community.

And apparently, I wasn’t the only one to think so. Yet, this statement was only an opinion, and was not based on actual research. My opinion hasn’t changed much since then, but now I actually have some data to support this conclusion.

Content and community growth

There has been much interest in the academic world about “Who writes Wikipedia?” and whether most of the content is contributed by an elite group of participants or by occasional visitors1 2. Roth et al. studied the factors influencing wiki viability and noted a “dynamical intertwinement of population and content growth”3; they had earlier suggested that a wiki’s success was linked to “a virtuous demographic path with content and contributors co-evolving”4.

In a media repository like Wikimedia Commons, however, the focus of activity is on contributing new media files, rather than improving the existing ones. Once a file has been uploaded, improvements are mostly limited to metadata and peripheral information (description of the media file, copyright information, general topics, location, etc.); the files themselves are rarely edited. As a consequence, it is particularly interesting to study the dynamics of population & content in this special case. For this purpose, I studied the temporal evolution of the Files-to-active Participants ratio (F:P) and compared it to the Articles-to-active Participants (A:P) ratio on the English Wikipedia (Fig. 1). All the data come from stats.wikimedia.org.

content vs participants chart Temporal evolution of the content & participants of Wikimedia Commons

Fig. 1: Temporal evolution of the ratio of media files on Wikimedia Commons per active participant (orange squares) and evolution of the ratio of articles on the English-language Wikipedia per active participant (blue triangles).

While the articles-to-participants ratio has remained stable on Wikipedia after the first few years of existence, the files-to-participants ratio has been steadily increasing since the creation of Wikimedia Commons. F:P has exceeded A:P since then and is now ten times higher than A:P. This demonstrates that Wikimedia Commons, despite being successful in terms of content, does not follow the usual model of “viable” or “successful” wikis, and requires new metrics and new models.

Content inflow management

Because of the fundamental difference between a text-based encyclopedia and a media repository, a more interesting approach is to compare the capacity of the community of participants to “absorb” the inflow of new content contributed to the platform. Thus, I studied the temporal evolution of the ratio of persistent new media files uploaded each month, per very active participants on Wikimedia Commons (Fig. 2). I compared it to the ratio of persistent new articles per very active participants on the English-language Wikipedia. “Persistent” means that I only counted media files and articles that were not deleted during the patrolling process; the actual number of files uploaded and articles created is higher. I chose to consider only very active participants (more than 100 edits per month) since they are the more likely participants to engage into patrolling activities, such as checking newly uploaded files or newly created pages.

content inflow commons enwp Temporal evolution of the content & participants of Wikimedia Commons

Fig. 2: Temporal evolution of the ratio of persistent new media files on Wikimedia Commons per very active participant (orange squares) and evolution of the ratio of persistent new articles on the English-language Wikipedia per very active participant (blue triangles).

The ratio of persistent new media files per very active participants has doubled since the creation of Wikimedia Commons and still continues to increase. This ratio is now more than ten times higher than the one for articles on the English-language Wikipedia. Because of this imbalance between the growth of the content and the growth of the community, Wikimedia Commons faces a peculiar challenge.

Using appropriate tools

Some may argue that comparing uploads and the creation of new pages is like comparing apples and oranges; I agree to some extent. For this reason, I have also studied the evolution of the number of edits on the English Wikipedia, which may be a better indicator of the inflow the community has to absorb. This will be the subject of an upcoming article.

The MediaWiki software provides various maintenance and patrolling tools that allow participants to check newly contributed content; one of these tools is the “watchlist”, a personal page listing the recent changes made to pages of interest selected by each participant. Watchlists are appropriate for text-based wikis like Wikipedia where participants want to check new edits to existing pages, rather than new pages. However, maintenance activities on Wikimedia Commons mainly consist of checking new files (especially their copyright status) and classifying them appropriately. For this purpose, the usefulness of the watchlist is limited. Some ad-hoc tools have been developed by power participants, but MediaWiki does not provide dedicated features to help the limited community of participants absorb the inflow of new media files. This is where the Multimedia Usability project can step in.

Notes & References

  1. E. H. Chi, N. Kittur, B. Pendleton, and B. Suh. Long tail of user participation in Wikipedia. ↩
  2. R. Priedhorsky, J. Chen, S. T. K. Lam, K. Panciera, L. Terveen, and J. Riedl. Creating, destroying, and restoring value in Wikipedia. In GROUP ’07: Proceedings of the 2007 international ACM conference on Supporting group work, pages 259–268, New York, NY, USA, 2007. ACM. (PDF, 250KB) ↩
  3. C. Roth, D. Taraborelli, and N. Gilbert. Measuring wiki viability. An empirical assessment of the social dynamics of a large sample of wikis. In Proceedings of the 4th International Symposium on Wikis – WikiSym2008, New York, NY, USA, 2008. ACM. (PDF, 311KB) ↩
  4. C. Roth. Viable wikis: Struggle for life in the wikisphere. In WikiSym ’07: Proceedings of the 2007 international symposium on Wikis, pages 119–124, New York, NY, USA, 2007. ACM. (PDF, 334KB) ↩
Posted in Featured, Wikimedia Commons | Tagged , , | Leave a comment

Scaling up Software development for Wikimedia websites (Part II: Tools)

Posted on March 5, 2010 by Guillaume Paumier

During the past few weeks, I have been thinking about a more structured way to manage software and product development within the Wikimedia community. The result is a list of ideas and recommendations I have compiled and submitted to the relevant staff members at the Wikimedia Foundation. I am also publishing them here in order to allow for a wider feedback. This article is the fourth and last of a series dedicated to this topic.

Disclaimer: The content of this article reflects only my personal opinion and is not an official plan or communication of the Wikimedia Foundation.

I have previously explained why the current setup of the Wikimedia bug tracker is not ideal. I have also advocated for a more managed & scientific software development strategy. This article aims to discuss an appropriate tool to support this strategy, and at the same time fix what is broken.

Tooled Flatty by flattop 640 590x442 Scaling up Software development for Wikimedia websites (Part II: Tools)

“Give us the tools, and we will finish the job.” (CC-by by fattop341)

Software lifecycle & Project management

Right now, there is little project management of the technical activities at the Foundation. When someone does manage projects, they often use personal desktop applications that don’t allow collaborative work. There isn’t any real development roadmap or product requirements. If we want to be serious about structuring our activities, we need a project management strategy & the appropriate associated tools that allow us to manage things such as project scope, schedule, budget & financial resources, quality assurance, human resources, communications, risks & opportunities, procurement and coordination.

I asked around to see what the needs of the various members of the team were. Naoko Komura, who has been project-managing the Wikipedia Usability Initiative, and is now overseeing all UX programs, is particularly interested in the integration of the Project management platform with calendars & issue tracking. Operations staff members also said they were interested in Project management features such as time and task tracking.

I think it is way past time to have a more organized development process & software lifecycle management. The recent hiring of a new Chief Technical Officer is a step towards a more structured organization of technological activities. Of course, changing our bug tracker alone won’t automatically structure our activities, but it is a step in this direction.

Recommendation: Use tools that allow a better management of, and integration between, the different stages in our product(s) lifecycle.

Requirements

A few months ago, I asked Priyanka Dhanda (our new Code maintenance engineer) to explore open-source collaborative project management platforms that could be easily integrated with bugzilla (or that included a bug tracking system of their own). The Wikimedia tech community was invited to list requirements of such a tool, as well as possible solutions.

From the feedback we received, we can summarize what the required features for an issue tracker are: integration with our Version control system, being FLOSS, multiple projects support and ability to separate between “tasks” and other items such as bugs and feature requests. Additional, “nice to have” features include: ability to import data from existing Bugzilla instance and fined-grained e-mail subscription options

Similarly, the required features for a Project management tool are: being web-based to facilitate collaboration, multiple projects support, calendar/scheduling and roadmap, assignments & resource management and time tracking per task/user/project. Additional, “nice to have” features include: Gantt charts, public/private projects, fine-grained access to projects by user, basic accounting & budget management and requirements management.

Redmine

I haven’t found many Project management softwares that can be easily integrated with Bugzilla. However, I have discovered alternatives to Bugzilla that include project management features like those we’re looking for. Redmine seems to be a good project management software and provides an advanced issue tracking system as well. It supports multiple projects, public/private projects, calendars & Gantt chart, and a lot of other neat stuff. It also offers the ability to distinguish between features/improvements and bugs; this would be particularly useful to prioritize development efforts. We are now considering using Redmine as project management software and taking this opportunity to move our Bugzilla setup to Redmine. Initial research shows that a lot of people seem to praise Redmine compared to Bugzilla; there are migration scripts to import an existing Bugzilla setup into a new Redmine one.

Major projects such as TYPO3 are using Redmine. The software seems to benefit from a dynamic community of developers and it is also possible to sponsor custom development. There are many plug-ins to extend the default core features; popular plug-ins are usually included into the core software at some point.

Priyanka set up a local test instance of Redmine to let us play with it a bit; a public test platform was later made available for wider testing and the Wikimedia Tech community was invited to pitch in. So far, I personally like it and it fits my needs perfectly. Wider testing is now necessary to see if it fits the needs of the tech community.

Because the time I can devote to this change is limited, I haven’t reviewed other alternatives than Redmine, and don’t plan to unless another major alternative is suggested.

Recommendation: Move from Bugzilla to Redmine after careful preparation, especially regarding the organization of the platform.

Read also in this series

Posted in Featured, Wikimedia Technology | Tagged , , , , , , | Leave a comment