The idea is to add AsciiDoc support to XWiki Rendering (see the current list of supported syntaxes).

The rationale is that AsciiDoc is very popular nowadays and very nice for writing documentation.

See Extending XWiki Rendering.

We would love to see integration with other Open Source Tools. These integrations could be brining data and interaction of the other tool in XWiki or the opposite. 

This project leaves the student to propose which integration he would like to work on. 

WikiStream framework allows converting from one wiki representation to another. The idea here is to provide a WikiStream input module for MediaWiki so that it's possible to convert from MediaWiki to any WikiStream output format.

You can get inspiration from http://extensions.xwiki.org/xwiki/bin/view/Extension/Import+DokuWiki+into+XWiki+Application and http://extensions.xwiki.org/xwiki/bin/view/Extension/Dokuwiki+To+XWiki2+Extension.

There are already several extensions that deal with git: a module that allows to perform operations on a git repository from the wiki, a small GitHub stub that allows to list committers for an organization or a project, and a more complex application that allows to synchronize wiki pages with a repository on GitHub. The goal of this project is to provide a richer integration with git:

• a space in the wiki can be linked to a repository on GitHub (or any other git repository)
• display in the wiki active pull requests and their status (when using a GitHub repository)
• insert custom events in the Activity Stream for new commits, pull requests, comments on commits, new/deleted branches or tags...
• code and committers statistics
• list commits, linking user names to users in the wiki, and issue numbers to the corresponding Jira issue

Another direction is enhancing the GitHub Commit Application:

• better UI
• better handling of merges
• support for selective commits (like git add --interactive)
• better support for user configuration

XWiki provide an extensions repository for anyone to easily deploy contributions. See http://extensions.xwiki.org.

The goal of this GSOC is to improve it. The student will have to study it and propose improvements, there is no definite list of things to do.

Here are some ideas: Repository open Jira issues.

XWiki community maintain a wiki with a special application to help translation XWiki projects on. See http://l10n.xwiki.org. Sources can be found on https://github.com/xwiki-contrib/application-l10n.

The goal of this GSOC is to improve it. The student will have to study it and propose improvements, there is no definite list of things to do.

Various ideas:

• make all this a lot more dynamic
  • importing is a long task and you always get a timeout before it's finished (it's still continuing on the server so it's not broken but still). A progress bar could be nice (could be based on extensions:Extension.Job Module)
  • default translation edition table is not exactly the nicest UI you could think of (http://l10n.xwiki.org/xwiki/bin/view/XE/XWikiCoreResources?action=viewall&language=fr)
• provide tools to refactor things a bit:
  • it's hard to move some translation from one space to another (for example the applicationresources on XE should be on Platform)

etc.

WikiStream framework allows converting from one wiki representation to another. The idea here is to provide a WikiStream input module for MediaWiki so that it's possible to convert from MediaWiki to any WikiStream output format.

The best is probably to convert https://github.com/xwiki-contrib/sandbox/tree/master/xwiki-wikiimporter/xwiki-wikiimporter-mediawiki-xml into a WikiStream module and improve it.

Right now XWiki Extension Manager support plain Maven and XWiki Extension (http://extensions.xwiki.org) repositories.

The idea is to add support for as much other kind of repositories as possible.

Here are some good examples:

• Nexus
• Bintray
• Pypi

See http://dev.xwiki.org/xwiki/bin/view/Design/ExtensionManagerRepositories for more details.

XWiki 4.4 introduce new translation macro which will allow to find easily translated content in a page when using annotated XHTML renderer.

The idea is to use that and provide a "translation mode" where you can directly select and translate what you see in the page (when the translation macro is used). The idea is also to make easy to contribute to http://l10n.xwiki.org from your local wiki by sending your corrections to it.

Various ideas for the look and feel of this feature:

• https://pontoon.mozilla.org is very nice
• http://direct.hoplahup.net/tmp/Drupal-translation-ODS.png

The XWiki Collaborative Learning Assets Management System is used in several projects of sharing platforms for learning content, among others: curriki.org, i2geo.net, and planete.sankore.org.

The project's work is to implement web-based tools in these platforms so that content in one platform can be made visible in another. Differently than federated search, the objective is to allow an easy transport of a resource from one server to another where it starts a new life while it keeps a link to the original. In open-source parlance, this gives birth to a fork. That transport should be initiated by a function triggered by a user who thinks it is useful to copy to bring the resource closer to him/her or a group where he/she is a member.

Ideally, the tool should scale to support administrators that transport complete collections (as much as 1000) of selected learning resources.
Moreover, the link to the original should be kept and displayed and it should be possible for a user to request an upgrade of the transported resource if the source has been updated and if compatible. The practice of versionning systems such as git or mercurial should be a model. The project would be very successful if it can employ the 3-way-merge facilities of the underlying XWiki to this process, making it possible to work in parallel.

Such a contribution is likely to support such initiatives as the build of a local copy of Curriki with selected content which can serve a local community of teachers (the Curriki team has been asked for such by governments of countries with a relatively limited external internet bandwidth such as pacific islands). Moreover, this contribution should be created in a sufficiently generic way so that any XWiki installation that has the necessary XWiki objects to transport the learning resources can exploit it.

Mentors: the XCLAMS community, including Paul Libbrecht and Bob Greenawalt (confirmed), as well as Joshua Marks, Ludovic Dubost and Flavius Olaru.

Discussion: is to happen on the XCLAMS and xwiki-devs mailing-lists as well as on the #xclams and #xwiki IRC channels. We welcome students' questions there!

Delivery: open-source code (LGPL) using Groovy, and Velocity that can be made part of the XCLAMS core code. Possibly Java code too.

The tool proposed here is to provide a shell to publish ePub archives that work on mobile devices. The objective is to export assemblies of pages within an ePub book that can be enjoyed offline on devices following identified profiles.

In particular the XWiki Collaborative Learning Assets Management System, an OER sharing platform in use by several projects, supports the assembly of learning resources of diverse origins and types by a concept of collections which encourages re-usability. This project should enhance this re-usability by an export feature that allows the content of a collection to be exported as e-book.

The software should support the author in predicting and verifying the playability of the content on various devices (e.g. warning that a Flash file is not going to work on the profile Aldiko on Android). It should also leverage open-source softwares such as Swify, ImageMagick, of ffmpeg to ensure an embedding that is reasonable in size and that works in typical mobile devices. An environment for prototyping the delivered ePub is central to this work. The delivery is likely to base on the recently launched Curriki Geometry tablet oriented interface.

The Curriki and Planète Sankoré teams, together with the trainee, will support this choice in suggesting environments in wide use in their target population where this can be tested in the timeframe of the project (schools in the US, India, France, and the French speaking Africa).

A very successful contribution would include code that we can deploy to any XCLAMS installation. It should, with a small amount of changes, allow developers to also export to other package formats such as SCORM or Common Cartridge and maybe even deliver Android's APK applications.

Mentors: the XCLAMS community, including Paul Libbrecht and Bob Greenawalt (confirmed), as well as Joshua Marks, Ludovic Dubost and Flavius Olaru.

Discussion: is to happen on the XCLAMS and xwiki-devs mailing-lists as well as on the #xclams and #xwiki IRC channels.

Delivery: open-source code (LGPL) using Groovy, Velocity, Unix command-line-tools, that can be made part of the XCLAMS core code.