Google Summer of Code/2012

Google Summer of Code 2012 was announced on February 4th, 2012. MediaWiki will apply to participate, but will not officially know whether we are participating until 16 March 2012.

Read the GSoC FAQ.

Relevant dates

 * Organisation applications begin February 27.


 * Organisation applications deadline March 9.


 * Student applications begin March 26.


 * Student application deadline is April 6.

Timeline for reference.

Student signup
We'll open student signup if and when we get accepted to participate in GSoC 2012. In the meantime, the best way to increase your chances of being accepted is to start going through the intro steps to learn MediaWiki. You should also do the diff and patch, git, and Subversion training missions. If you have any trouble at all, please talk with us on IRC. If you're a bit shy and don't want to ask your question of the whole room, look for sumanah.

We suggest that you start following the steps in How to become a MediaWiki hacker now, and see if you can start contributing by fixing an annoying little bug. This experience will help you write a good proposal, and improve your credibility as an applicant.

Spread the word
Please also help us publicize GSoC at your school!


 * A leaflet about student MediaWiki contribution to print out and hang on the wall
 * A quarter-page flyer about MediaWiki contribution, to hand out
 * A leaflet about GSoC to hang up or pass out

Project ideas
Applicants will need to write good proposals either based on their own ideas or expanding thoughtfully on the ideas below.


 * Search should index transcluded text — This is sorely wanted for Wiktionary, Wikibooks, Wikisource and the like that depend heavily on template expansion.
 * Create a way to have “books” for wikisource/wikibooks — This would mean you could “watch” books (sets of pages, watch a category) instead of just single pages. Might be able to do by extending the Extension:Collection or improving Extension:BookManager.
 * Does this imply that you want to have a feature just like we have in Google Books where we can preview a Book ? or does this mean to have a watchlist feature for books just like we have for single pages ?- chughakshay16
 * I believe this implies we will be able to have (at least) these much wanted features. See also Extension:BookManager. Helder 23:43, 8 February 2012 (UTC)


 * Upload to Commons plugins for common photo management apps (iPhoto, Aperture, Lightroom, Picasa, Shotwell, F-spot, etc.) similar to existing plugins that allow synchronization with sites like flickr, facebook.
 * Implement pre- or post-commit checks in our code repositories that automatically look for security vulnerabilities, broken coding conventions, broken code, etc, perhaps with a web interface to facilitate the process, or using our Jenkins continuous integration setup. Help MediaWiki developers save time in code review, and make our code more secure.
 * This should be done via Jenkins for sure. We already have a build project for it, but we haven't taken the time to actually write our coding conventions down in this format--that could make a good summer project!
 * Improve our Android application -- integrate with SuggestBot to suggest a mobile task to a user.
 * Give editors a way to slice and dice their watchlists with groups (perhaps group similar pages in their watchlists).
 * Improve volunteer-written mass upload tools to make them more robust, especially for use by museums, galleries, libraries and archives. Use Python, PHP, or jQuery with the MediaWiki API and help thousands of people share free culture.  For an overview of current tools, see https://outreach.wikimedia.org/wiki/GLAM/Newsletter/January_2012/Contents/Tool_testing_report -- also see the tool requests page.
 * I wonder about whether there are things we could do wrt Wikibooks and Wikiversity to improve their reuse/integrability -- this may require new features in our web API.
 * In what sense are you (or Mediawiki) looking to make the Wikibooks and Wikiversity Web API more reusable ? Is it in terms of improving its already existing API or just developing front end for exploiting the API ?  ... does that mean you were referring to creating a client that would leverage the potential of these two wikis? - chughakshay16
 * I was on an airplane next to an educator, and he asked when Wikipedia was going to get into the educational curriculum game. Obviously he did not know about Wikiversity and Wikibooks!  So I told him.  And then he basically asked to what extent they were reusable programmatically, that is, are the contents usable as building blocks for other content management and curriculum creation systems elsewhere?  I think a student who is interested in this question should investigate what is desired by the educational community, see what is technically feasible, and write a proposal. Sumana Harihareswara, Wikimedia Foundation Volunteer Development Coordinator 08:02, 8 February 2012 (UTC)


 * MediaWiki/Moodle or MediaWiki/Sakai or MediaWiki/Blackboard or MediaWiki/Desire2Learn integration.
 * Write a Convention extension that will turn any MediaWiki wiki into a suitable website for a conference such as Wikimania. The extension would manage registration, talk submission/voting, etc.  For comparison see OpenConferenceWare and WisConDB.
 * Redo Wikimedia Planet blog aggregator. Make it easier to add languages and blogs without (or with minimum) developer involvement.
 * Backwards-compatibility extension. This would be a place to park deprecated features so that they don't clutter up the core software, but are still available for use by extensions that aren't in our repository.  The extension would need to be bundled with the MediaWiki installer, and enabled by default (which is pretty easy as of 1.18).  The initial version could declare deprecated global functions (e.g. wfUILang, wfViewPrevNext, wfDoUpdates, wfCreateObject, wfStreamFile, wfLoadExtensionMessages, and wfOut) and global variables (e.g. $wgArticle).  The next phase can be about figuring out how to cleanly extend classes to include deprecated methods. Bonus feature would be to expose use of deprecated features in the UI for a logged-in admin. -- RobLa-WMF 20:23, 12 February 2012 (UTC)
 * Backwards-compatibility extension. This would be a place to park deprecated features so that they don't clutter up the core software, but are still available for use by extensions that aren't in our repository.  The extension would need to be bundled with the MediaWiki installer, and enabled by default (which is pretty easy as of 1.18).  The initial version could declare deprecated global functions (e.g. wfUILang, wfViewPrevNext, wfDoUpdates, wfCreateObject, wfStreamFile, wfLoadExtensionMessages, and wfOut) and global variables (e.g. $wgArticle).  The next phase can be about figuring out how to cleanly extend classes to include deprecated methods. Bonus feature would be to expose use of deprecated features in the UI for a logged-in admin. -- RobLa-WMF 20:23, 12 February 2012 (UTC)

Semantic MediaWiki, an extension to MediaWiki, is applying separately for GSoC and has its own list of project ideas.

Also look at the ideas of 2011 and past projects.