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 -at- gmail.com

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

Working info
Time zone: UTC+1 (Belgium)

Typical working hours: 13:00 – 00: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. 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.

About me
I am an informatics student in Belgium (this is my last year). I love programming and open source, and am completely behind Wikimedia Foundation's mission to make the sum of all human knowledge available to everyone. I have successfully participated in GSoC 2009, during which I created the Maps and Semantic Maps extensions for Wikimedia Foundation, with Yaron Koren as mentor. Since then I have stayed active in the community and continued to contribute. I am currently in the top 30 contributors, and am doing freelance MediaWiki development work for Wikimedia Foundation and WikiWorks, amongst others. For more information, review My MediaWiki-development career.

The main reason I want to do this GSoC project is that it would enable me to spend considerable time to contribute to MediaWiki, and get to know the core code better. Furthermore I think that this project, once complete, will have a huge impact, brining MediaWiki up to today's usability standards for usage by individuals and organizations for both commercial and non-commercial purposes. (The "Modernizing MediaWiki" topic recently posted on Wikitech-l comes to mind here.)

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 will need guidance for scalability aspects.

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.


 * Management of MediaWiki configuration.

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

Participation
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. To many WMF GSoC projects have ended up doing nowhere already, I do not intend this to be one of them. I am already part of the MediaWiki community, so do not expect to have any problems getting help from all the awesome MediaWiki developers.

Past open source experience
I have created multiple classes, libraries and applications on my own that I have published as open source. However, the only big open source project I'm contributing to is MediaWiki, see the about me section for more info.