Like last year, I’ve been accepted for GSoC 2010 – yay!
The Google Summer of Code (GSoC) is an annual program, first held from May to August 2005, in which Google awards stipends to hundreds of students who successfully complete a requested free software / open-source coding project during the summer.
My project is creating an awesome extension management platform for MediaWiki, facilitating the installation, updating, removal and configuration of extensions. I’ll get mentored by Brion Vibber, which is probably the best known MediaWiki developer there is. The underneath paragraphs are out-takes of my actual proposal.
The goal of this project is to create an administration panel from where wiki administrators can update, install and remove extensions. A second goal would be to allow management of the installed extensions.
A panel where wiki administrators can install, update and remove extensions would have huge benefits. First of all, people would not have to manually download an extension and put an includes in LocalSettings, neither would they need to worry about compatibility and dependencies. Hitting an update button also takes considerably less time then doing the whole download routine again, and will cause people to run more up to date extensions. Another important advantage is that people will get extensions recommended, and can easily browse them. This way people will find extensions that do something they wanted but did not know about, and in general have extensions that better suit their needs. A third advantage is that extension developers won’t need to do extreme efforts to let people know there is a new version (and probably still only reach part of the relevant public). This is inspired on the way Word-press does things.
The second goal of this project is to add setting management for individual extensions. Currently extension settings are managed via LocalSettings. The aim here is to completely remove the need of editing any file directly by storing the configuration the the MediaWiki database, and creating a GUI to modify these settings. This would involve creating API modules so extensions can add and update their own settings. Work on this will only be started after the first goal is completed, and is seen as an “if time permits to-do”.
A third, also optional, goal would be to create a management interface for the wiki’s configuration itself. This is very similar to the second goal, and should be kept in mind while creating the management for extension settings. I do not expect to complete this to-do during GSoC, but want to provide the foundations for it, so this can be completed after the project itself is finished.
Note: the beneath list is a guideline only.
Things the administration panel should be capable of:
- Automatic checking for extension updates (and updates to MW itself)
- Download and install option for extension updates
- Download and install option for extensions that have not yet been installed
- Removal of installed extensions
- Dependency and compatibility checking (both for installation, removal and updating)
- Extension browsing
- Recommendation of similar extensions
- Showing a list of most used and most recommended extensions
- Finding extensions by category or keywords
- Enabling and disabling of installed extensions (so without removing them)
If time permits
- Management of settings specific to each extension.
- Management of MediaWiki configuration.
I’m for a loose schedule, since I believe this is the most efficient. I have no doubt that the to-do list will change a lot during the project, items will be changed, moved, multiple new ones will be added, and some might be removed. A fixes schedule would take away flexibility and stand in the way of efficiency. One of the main reasons to have a schedule is to ensure the student does not take the project to lightly, end ends up making insufficient progress. I like to believe I have clearly demonstrated that I will put considerable effort in such projects, even without any schedule, during last yeas GSoC, and with all the commits I’ve made since then.
This list contains some loose planning without any dates:
- Discuss the best way to structure the platform with mentor, and other relevant people.
- Investigate how similar functionality works with other software, and which aspects of these implementations can be used.
- Get the requited knowledge of MW to be able to create the platform in an efficient and modular fashion.
- Create the panel with the most basic features, then release and document it.
- Add the other features, possibly spread over several releases.
- (Start on the extension setting management functionality.)
- (Start on the MediaWiki configuration management functionality.)
- (Add other awesome things to the platform.)
- Take over the worlds and make everyone use this platform.
My current planning
I have to finish up the work I’m currently doing for the Wikimedia Foundation before I can fully start on this, and also like to release Maps and Semantic Maps 0.6 before then. This will probably be in two to tree weeks from now.
Also see the Wikimedia tech blog post which links to the other accepted projects.