XWiki has been accepted as a mentoring organization for Google Summer of Code 2011.

This page hosts information and project ideas for the Google Summer of Code 2011. Students can come up with their own ideas, and propose them on the mailing list or the IRC channel.

Suggested way of working for GSoC students

First and foremost, working on XWiki needs to be fun and a good learning process! However the XWiki project is already following some development rules that we're asking GSoC students to follow too. This is for the good of the XWiki project but more importantly it's a good way to learn how an open source community works and if these practices are followed then it'll be much easier to integrate the resulting work into XWiki's official releases.

So here are some practices we'd like GSoC students to follow (please comment on the list if you'd like to change some of them or propose other things):

  • GSoC students should be considered like any XWiki contributor which means they should respect the same rules and which means they are not committers on XWiki core. Note that a GSoC student can become a Committer in the same manner a contributor can become one.
  • GSoC students will be given commit access to the sandbox only where they'll create their project (one top level directory for each project). For projects which need to modify some existing code, JIRA issues will need to be created and patches attached. It's important that patches be of good quality and small in order to be applied quickly. Once sandbox projects reach a good level of maturity (meaning they work and the code is of code quality, documented, etc) then we'd like to migrate them to the main release tree.
  • GSoC students should obey all Community rules. For example this means:
    • using the XWiki coding conventions
    • using the defined communication channels: IRC and mailing list
    • etc
  • GSoC students have time allocated to familiarize with XWiki development process. As such we'd like each GSoC student to pick one or several existing issues in JIRA and send a patch that fixes it/them before that period ends (from April 25th to May 23rd) This is a critical integration step to ensure all GSoC students understand how XWiki works and it's a chance to start asking questions and get to know each other.
  • GSoC student should post a quick introduction on the xwiki dev mailing list to explain who they are and what they're going to work on.
  • GSoC student should always go to the list when communicating about their project. They should not talk directly to their mentors. They should use the XWiki IRC channel if they need to talk to them. The goal is that everyone in the XWiki community help them, answer their questions but also know what they are doing. This will make patch applications and integration of their work back into XWiki trunk easier later on. This is very important and a criteria of success for the student. This is about learning how open source works... Note that student can also CC their mentor's email address if they want but the mails have to go to the XWiki dev list.
  • GSoC students should not block on anything for a long period of time. They should ask plenty of questions on the list (but they should also be autonomous!)
  • GSoC students should be as much as possible in contact with the community, following the mailing lists (and answering mails, when they know what to say), stay on the IRC channel, give regular status updates on their project. This does not mean that a GSoC student is not allowed to take a break, of course, but that while working a student should be integrated as much as possible with the community.
  • When taking a vacation/break, notify the mentor; a mysterious disappearance could lead to a negative feedback afterwards.

Remember that this is not a summer job, or a Rent-a-coder like project, but a rewarded successful integration in an free software/open source community. If all you are interested in is the money, then better look for a real job, as Free Software requires passionate people; an ideal candidate is more interested in the t-shirt.

Good generic advises:

Conditions for success

Students will need to meet these criteria for success: 

  1. Must have something that works and is in some finished state.
  2. Must be integrated or close to be integrated in XWiki without too much effort
  3. Must have interacted correctly and continuously with the community
  4. The work must have been enough (it's supposed to be a 2 men/month effort)

Note that the real important part is 3) since this is a criteria for success for 1), 2) and 4).

Student Application template

Please use this template as the basis for your student application which must be submitted to google.

The projects below, out of all the proposed projects, have been selected to participate in GSoC 2011.

Proposed Projects (18)

AJAX Form Editor

As part of the "App Within Minute" project, it would be interesting to have an AJAX form editor. This form editor would allow to drag and drop fields in a visual design with multiple columns and sections. Empty spaces could be included and some cells could be widden to multiple columns or rows.

The result of the visual editor should allow to generate the adequate velocity script and reload it in the editor.

Coordinated by

. Estimated workload: 3 month.

Add support for parameters types in Wiki Macros

In XWiki Rendering macros parameters are typed and automatically converted when the macro is executed.

The goal is to support the same thing in Wiki Macros:

  • add UI to choose the type of the parameter (probably link it somehow with the types supported by the WYSIWYG)
  • do the conversion when the wiki macro is executed

See also http://jira.xwiki.org/jira/browse/XWIKI-5496

Coordinated by

. 

Annotations for images and other content types

Extend the Annotations Module (svn, demo) in order to allow annotating images and sections of images.

Additionally, research and implement a method to add and visualize annotations on document attachments: .pdf, office documents (word, presentation), etc.

Coordinated by

. Estimated workload: 3 months.

Blog application performance improvements

This project mainly consists of re-writing the velocity macros powering the Blog Application into a Groovy component with access to protected API which performs the same tasks with increased efficiency.

Coordinated by

. Estimated workload: 3 months.

CMIS Integration

CMIS (Content Management Interoperability Services) is a proposed standard for improving interoperability between Enterprise Content Management systems (http://en.wikipedia.org/wiki/Content_Management_Interoperability_Services)

The idea is to implement a CMIS layer that will provide XWiki content to clients.

The CMIS specs proposes two types of bindings 1) A RESTful one based on AtomPub 2) A SOAP one 

The project will focus on the RESTful binding.

The implementation would leverage the Apache Chemistry framework and will be integrated in the current REST backend of XWiki (taking into account also the needed modifications)


Coordinated by

. Estimated workload: 3 months.

Calendar Application

The previous Event Calendar in XWiki was very basic: in a monthly view, it would allow to add and display events stored as XWiki objects in the calendar's wiki document. This application was removed from the default distribution of XWiki Enterprise, as it did not meet the quality and usability requirements.

We wish to recreate the Event Calendar application, such that it would allow to:

  • display day, week, month, year view for the calendar
  • store the event objects anywhere in the wiki
  • have a friendly UI for adding, changing and filtering events
  • import events from the old version event calendar.
  • support microformats
  • export in standard formats (ical)

The application should have a friendly AJAX UI, but should also be somewhat functional in browsers without JavaScript. It must be easily skinnable through CSS.

Coordinated by

. Estimated workload: 2 months.

Dynamic RESTful services

XWiki has a RESTful API that is implemented using server-side components written using the JAX-RS API. In order to deploy a new service, a new jar has to be deployed and the server restarted.

The goal of this project is to provide a way for extending XWiki with new additional RESTful services without restarting the server. This can be done by writing the definition of the service directly in XWiki pages using the Groovy scripting language, and by leveraging structured data (XWiki classes+objects) in order to provide metadata about the defined services.

Coordinated by

. Estimated workload: 3 months.

Improved ColorTheme Wizard

The current ColorTheme Wizard has a hardcoded layout that does not always reflect the current layout of the wiki and for this reason is not 100% WYSIWYG.

A first step is towards a better ColorTheme Wizard is to standardize the key html elements of the UI. This should to be done by the dev team before starting the project.

The new wizard should appear in full screen and should take into account all the CSS/velocity changes that have been introduced in the wiki (i.e. not rely on the default look).

Coordinated by

. Estimated workload: 2 months.

Macro support improvements

This project proposal is a draft. More macros need to be added to the list.

Add support for parameter types for wiki macros.

Reimplement existing Radeox and Velocity macros as 2.0 syntax macros:

  • IM Presence
  • image
  • jira
  • spoiler
  • twitter/identi.ca

Develop new macros:

  • author (document, lang, withLink)
  • creator (document, lang, withLink)
  • version (document, lang)
  • object display
  • children (doument, lang)
  • history (document, lang, withMinorEdits)
  • attachments (document, type, by, orderBy=name)
  • blog (space|global, number of posts, summary or content, categories)
  • recent changes (space, tags, number, type=all|comments|attachments...)
  • search
  • tabs (type=horizontal|vertical, {label: page})

See also:

Coordinated by

. Estimated workload: 3 months.

Mobile Skin for XWiki

Create a lightweight mobile skin for XWiki, or rather make the already existing colibri skin websafe for the mobile devices. Use W3C widgets to put the core files on the mobile phone so that you only need to download the data (save network traffic). See also:

Coordinated by

. Estimated workload: 3 months.

Photo Album Application

The previous Photo album in XWiki was very basic, allowing only to create albums with a description, add photos without any information attached to them and browse through these photos in simple manner. This application was removed from the default distribution of XWiki Enterprise, as it did not meet the quality and usability requirements.

We wish to recreate this application, with the following features:

  • creation of albums, with additional data attached to them: title, description, date(s), location
  • adding and managing photos and information about them (such as description, date, location, author, camera information, etc); could be done automatically by reading EXIF information from the photos
  • view as thumbnails and slideshow (with adjustable timer and with manual browsing) - see also the new Gallety Macro
  • migration tool from the old version photo albums.

The application should have a friendly AJAX UI, but should also be functional in browsers without JavaScript. Il must be easily skinnable through CSS.

In addition to the client side UI, some interesting features requiring platform changes would be:

  • uploading an archive that contains several photos, and automatically extract the photos from it (as opposed to uploading the photos one by one).
  • better tags implementation, allowing to tag attachments
  • better comment implementation, allowing to associate comments with an attachment

More modern features based on the upcoming HTML5 standard could be:

Coordinated by

. Estimated workload: 3 months.

Specific WikiMacro Editors

XWiki now has a very powerful WYSIWYG editor based on GWT which includes a wizard for inserting wiki macros (for example, for displaying message boxes, footnotes, mathematical formulas, etc).

This GSoC project consists of improving the macro editing mechanism, by allowing to use macro-specific WYSIWYG editors: a mathematical expression editor for the formula macro, a SVG editor for the svg macro, etc.

Coordinated by

. Estimated workload: 3 months.

Structural Search and Replace

Implement something similar to IntelliJ's IDEA Structural Search & Replace (see http://tv.jetbrains.net/videocontent/intellij-idea-static-analysis-custom-rules-with-structural-search-replace ), i.e. the ability to perform search and replace on multiple documents, based on structure. The elements that can be searched/replaced could be:

  • title
  • syntax
  • some elements of the XDOM (for ex search for an HeaderBlock containing such content followed by a ListBlock and replace it
  • ... and more

Coordinated by

. Estimated workload: 2 months.

Wiki Editor Improvements

XWiki now has a very powerful WYSIWYG editor based on GWT which includes wizards for inserting links, images, tables and wiki macros.

However, some users may prefer to use the Wiki editor, which allows to have full control over the source of the wiki page.

This GSoC project consists in redesigning and improving the Wiki editor, with the main purpose of enriching it with the aforementioned wizards, and of integrating a user friendly Wiki Syntax Help and Syntax suggest feature.

Coordinated by

. Estimated workload: 2 months.

XEclipse editors improvement

XEclipse is an Eclipse plug-in that allows the user to edit, view, save or delete XWiki pages directly from within the Eclipse IDE. 

The current XEclipse version is unmaintained and has several limitations. Editors have syntax-highlighting but they are not in sync with the current evolutions of XWiki and they do not reuse code from the XWiki codebase for implementing their features.

This project aims at improving content editors (documents, scripts and objects) starting from a correct support for XWiki syntaxes (and scripting fragments). In particular:

  • Integration of the existing parsers that are used in XWiki for parsing content (see http://rendering.xwiki.org)
  • Move from a static and hardcoded API definition to a dynamic one that queries the (velocity, groovy, etc.) APIs from the server and caches it locally.
  • Object editor improvements

Coordinated by

. Estimated workload: 3 months.

XWiki Cloud9 IDE integration

The objective is to use the Cloud9 IDE to edit XWiki code. All pages should be saved in XWiki and have nice editors with syntax highlighting.

An interesting part of the project would be to support velocity and/or groovy debugging running the Cloud9 Editor's debugging APIs.

Coordinated by

. Estimated workload: 3 month+.

XWiki Pseudoversions

Currently, each XWiki document modification creates a new version of that document: the save and continue action, adding/deleting objects or class properties, etc. In the end, most documents will end up with a lot of versions that should not be visible in the document's history because they constitute work in progress and are not informative by themselves. Additionally, the results of actions like adding or deleting an object from the object editor do not disappear when canceling the edit, which may create confusion for unexperienced users.

A possible solution to these issues are pseudoversions. Pseudoversions are temporary versions of a document being edited, and can be seen as short-lived versioning branches, resulting in a one official version when the user finishes editing the document.

A chain of pseudoversions is tied to a user, meaning that by default the user's changes are saved as pseudoversions in a private branch. When the user finishes editing the page by clicking "save", the last pseudoversion is saved as a full version, and the branch is deleted.

In addition to giving an answer to the problems listed above, pseudoversions created regularly during document editing can serve as a back-up system, so that users can recover unsaved work in case of a browser crash or other types of accidents that may cause data loss. 

See also: http://jira.xwiki.org/jira/browse/XWIKI-500

Coordinated by           . 

Scalable XWiki on NoSQL (AppEngine, Cassandra prototype)

The objective of this project is to have a working prototype of XWiki running on AppEngine and/or Cassandra using the DataNucleus API for storage and querying. This requires writing a query layer to translate XWiki queries to DataNucleus queries compatible with Google's storage.

Coordinated by

. Estimated workload: 3 month.

Previous GSoC editions

Created by Vincent Massol on 2008/03/02 11:59

Get Connected