Google Summer of Code/2012

MediaWiki has applied to participate in Google Summer of Code (GSoC) 2012, but will not officially know whether we are participating until 16 March 2012. Sumana Harihareswara is managing MediaWiki's participation in GSoC.

Read the GSoC FAQ and the student guide to GSoC.

Relevant dates

 * Student applications begin March 26.
 * Student application deadline is April 6.
 * Announcement of accepted students: April 23.
 * Students start their fulltime work: May 21.

Timeline for reference.

Student applications
We'll open student applications if and when we get accepted to participate in GSoC 2012. Dozens of students apply every year and we only accept fewer than ten of them, so this is an exclusive program.

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 varnent or 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 to our guidelines, and improve your credibility as an applicant.

We will strongly prefer students who can demonstrate the ability to work with our existing codebases, communicate well, and participate actively in our development community even after August is over.

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.

Ideas with mentors

 * 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. (Mentor: Raylton)
 * 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)


 * Functionality requested: after a user has made 100 edits to a wiki, show a link somewhere in the sidebar or top navigation asking, "who's been awesome?" The link takes the user to a page where she can specifically name other users of that wiki to praise them for their help and work. The data regarding users who have been named and thanked could be available publicly via an API, and potentially feed into the MoodBar dashboard or some other public venue or it could be kept private. (I want to use it to give away free merchandise for example ;) )  Suggestion from James Alexander, who offers to mentor.
 * Extension:OpenStackManager has various defects and needs various enhancements -- Ryan Lane will mentor.
 * RefToolbar is used by many WMF wikis. It needs usability improvements and we would like to see someone turn it into an extension.  You would convert RefToolbar into an extension - it currently lives in en.wiki Common.js, so isn't really a "gadget" anymore, and needs extensionification!  Ryan Kaldari wants this.  See New_Editor_Engagement/Smaller_issues.
 * Add Flickr integration to UploadWizard. The UploadWizard should have an interface for automatically transferring an image from Flickr, including the image's metadata and license. There is already some code written for getting the license of an image on Flickr and translating it into a Commons license template. Suggestion by Ryan Kaldari.
 * Create a usable interface for editing and managing the automatic taxobox. This would probably be either a Javascript gadget or a MediaWiki extension. Suggestion by Ryan Kaldari.
 * Proposal on enhancement of Extension CentralNotice Gsoc Proposal--Nischayn22 (talk) 19:09, 12 March 2012 (UTC), to be mentored by Katie Horn & Peter Gehres

Ideas suggested by others
If you are interested in these ideas, you should start looking for a potential mentor yourself, by asking on or our wikitech-l mailing list.


 * 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!
 * Automatically tagging photos in Wikimedia Commons using computerized object recognition. Discussion on wikitech-l started by Maarten Dammers. Maarten's suggestions.
 * Integrate spell checking into Translate extension
 * Search should index transcluded text — This is sorely wanted for Wiktionary, Wikibooks, Wikisource and the like that depend heavily on template expansion.
 * Wikinews relies on several gadgets as primitive forms of "workflow management" in transitioning a news article from developing through to published. Regrettably, these are fragile, scary, scary javascript everywhere, and not at-all well-integrated with MediaWiki and the FlaggedRevisions extension in general. With FlaggedRevisions use expanding, and the multiple levels within it being suited to GA/FA article promotion in a Wikipedia-type environment, there is scope beyond that on Wikinews for an extension which handles reviewing articles and pushing them up or down (review pass/fail). I know this is particularly late in the day regarding potentially getting things on-the-table for GSoC, but will put some work over the next 24 hrs into documenting the current state-of-play, and a more-ideal workflow where certain components of an extension might fit in. Suggestion by Brian McNeil; to produce outlines on sub-pages of own userspace.
 * Extract embedded text from DjVu documents for search - may not be a big enough project for GSoC, so maybe you would add a few other formats as well? Sumana Harihareswara, Wikimedia Foundation Volunteer Development Coordinator (talk) 01:07, 23 February 2012 (UTC)
 * Give editors a way to slice and dice their watchlists with groups (perhaps group similar pages in their watchlists).
 * Check out the Wikisource wishlist and see whether you get any other ideas.
 * 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.
 * See mailing list discussion
 * Improve our Android application -- integrate with SuggestBot to suggest a mobile task to a user.
 * 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.
 * Find a way to use the new Cooper-Hewitt museum metadata (example) to improve Wikipedia articles and Wikimedia Commons metadata. (See the GLAM page for some thoughts.)
 * I wonder about whether there are things we could do with regards to 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)
 * Are you talking about something like moodle for use by universities and schools on Wikipedia -nischayn22


 * 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)
 * CatGraph: allowing fast category traversal (and thus deep category intersection) a) on the Toolserver and b) as part of Wikipedia search. This would allow us to use categories as tags, and would remove the need to maintain intersection-categories like "American Authors of the 20th Century" by hand. Daniel Kinzler is working on a toolserver-based prototype. Ops is a challenge: full integration needs a lot of RAM (but not much compared to what is currently used for Lucene).
 * Mobile translation proofreading app for Translate extension
 * WikiPraise: this may be too small for GSoC, but it would be worthwhile to get the praise/blame/cite/reuse features fully integrated in the UI. This is mostly a jQuery / UX project. You would use WikiTrust data via the SURE service on Toolserver.org, which means you would not not going to get production quality data. But an additional subproject is: full blame map integration, providing production quality blame maps.  Luca de Alfaro is working on a proposal for this. The development side looks pretty manageable; perhaps he would be willing to mentor this as a GSoC project? The main challenge here is operations, as this needs lots' of storage if applied to the full body of Wikimedia projects. Tim Starling thinks it's feasible, though.  (Suggested by Daniel Kinzler.)


 * New_Editor_Engagement/Smaller_issues

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.