User:Jeroen De Dauw/GSoC2010/Proposal

Abstract
Creating an awesome extension management platform for MediaWiki, facilitating the installation, updating, removal and configuration of extensions.

Identity
Name: Jeroen De Dauw

Email: jeroendedauw@gmail.com

You can find contact details and more info about me on my user page.

Working info
Time zone: GMT+1 (Belgium)

Typical working hours: 12:00 – 23:00 (with lunch breaks in between)

Project summary
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. Being able to handle them in a GUI fashion would mean storing them in the database, and creating some API for extensions to interact with it. Backward compatibility and scalability are obviously very important here. Work on this will only be started after the first goal is completed, and is seen as an "if time permits to-do".

About me
I'm a student informatics in Belgium. I love programming and especially the open source spirit. I have successfully participated in GSoC 2009, during which I created the Maps and Semantic Maps extensions for Wikimedia Foundation, whit Yaron Koren as mentor. Since then I have stayed active in the community and continued to contribute. For more information, review My MediaWiki-development career.

The main reason I want to participate in GSoC is that it would enable me to spend considerable time to contribute to MediaWiki, and get to know it better. Although I've been active in the community for about a year, I'm not really familiar with MediaWiki (the inner workings) itself. I see GSoC as an opportunity to fill this knowledge gap, and to create an awesome extension management tool that would facilitate many aspects of working with extensions.

I have experience with PHP and JavaScript, as well as multiple other languages. For a complete list, see my cv. I'm also familiar with MySQL, but have to admit I'll need help regarding scalability and performance issues there.

Deliverables
Note: the beneath list is a guideline only.

Things the administration panel should be capable of:

Required deliverables

 * 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.

Project schedule
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. So a 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.

I expect to have frequent communication with my mentor, including code reviews, discussion about how to implement certain things as well as strategic planning of the projects development. I will not settle for simple weekly emailed update reports from my part.

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, or add other awesome things to the platform, depending of how the work has been going.


 * Take over the worlds and make everyone use this platform.