The Activity Stream offers an efficient way of keeping up with all the changes occurring in the wiki. However, the current implementation (for both the backend and the {{activity}} macro) is not very efficient and flexible. Work on a new backend has been started, but only as a lightweight component API, which still relies on the old activity macro for its implementation.

The goals of this project are:

• extend the EventStream API to offer more usable methods
• properly implement a Hibernate-based storage engine for the EventStream (improving the performance as well)
• refactor the existing code that uses the ActivityStream plugin to use the EventStream
• write a more scalable and performant {{activity}} macro:
  • seamlessly supports new event types
  • detects new events and offers to display them (like Twitter's UI)
  • supports loading more items
  • supports dynamic filtering / faceted search

Usecases:

• Meeting notes
• Brainstorming session
• Directly answer from your email client to a notification mail regarding a document change event

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

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.

Additionally new services would also be implemented:

• XWiki livetable implementation
• Full page access (read and write) in one request (page + objects + attachements)

This project is quite important as it would allow to play nicer for Mobile and with Advanced Javascript Framework

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. An environment for prototyping the delivered ePub is central to this work.

The Curriki and 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.

Mentors: the XCLAMS community and Curriki team, among others Paul Libbrecht and Joshua Marks (confirmed), as well as Ludovic Dubost and Flavius Olaru.

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

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

Our current XWiki mobile client enables users to access their XWiki cloud instances through their mobile devices. Improve this mobile client in order to let the users benefit from XWiki's powerful features.

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.

A relatively new feature of XWiki is the ability to send messages to certain users, groups, or globally in a whole wiki. Although useful, messages can easily go unnoticed, since there are no notifications about received messages. Some improvements could be:

• a more inbox-like view of received messages
• keep track of read/unread messages
• a global notification of unread messages in the top menu bar
• UI for replying to a message
• improved message sender UI

The goal is to replace the xwiki-coded editor by the CK Editor one: http://ckeditor.com/ (see demo at  http://ckeditor.com/demo).

Rationale:

• Better, with more features, less bugs, more active development (http://ckeditor.com/get-involved/our-team).
• It's not XWiki's business to write a WYSIWYG editor
• All our competitors are using bleeding edge editors and we need to catch up
• CKEditor supports Data Processors to integrate with wiki markup, see http://docs.cksource.com/CKEditor_3.x/Developers_Guide/Data_Processor
• Cool features:
  • Inline editing
  • Magic line
  • Skins/colors
  • Search/replace
  • Table resizer
  • Right click actions for tables (insert new column, etc)

The LDAP and XWiki models are very close (entries containing object of defined classes) so the idea came to implement an LDAP interface with XWiki model as backend.

The GSOC will be a success if the following user case is covered: use XWiki as LDAP server for another instance of XWiki.

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.

An XWiki extension for creating and managing collections of wiki pages. The extension must provide both

• a component and a script service to access the collections programmatically (i.e. an API to create and manage the collections programmatically)
• and a user interface to allow simple users to manage their collections of wiki pages.

For the API you can rewrite the xwiki-plugin-collection into a component, but only after a discussion on the devs mailing list. For the UI you can implement Caty's proposal for Selective Export UI, of course, without the export options.

Collections are extremely useful as the input for:

• export feature
• batch operations on the wiki
• application descriptor

You should check how the existing Multipage Export Application uses the xwiki-plugin-collection in order to understand the main use case for Wiki Collections.

Enhance the CRaSH Console extension to:

• make it available for users that don't have programming rights (limiting the set of available commands based on user rights)
• be able to write commands that redirect the current page (e.g. a document export command)
• be able to write new commands outside the crash-api jar (e.g. in wiki pages, using Groovy code).

Then implement XWiki specific commands to:

• browse the wiki using a "cd"-like command
• list the "children" of the current entity (wiki, space, document) using a "ls"-like command
• delete, move, rename wiki entities (wikis, spaces, documents, objects, attachments)
• create or edit wiki entities (redirect to edit mode)
• less, grep, find, uname etc.
• actions specific to each wiki entity (export a wiki page with various parameters, view the history of a document, etc.)
• more (ask the community)

Eclipse Orion is a Web IDE from Eclipse: http://www.eclipse.org/orion/

XWiki is a powerfull development framework allowing to develop 100% from the Web

The first objective it to build an Orion plugin to communicate with XWiki and allow to view the applications installed in an XWiki instance and add code to them (Javascript extensions, CSS extensions, Velocity and Groovy scripts, Scheduler jobs, etc..). This would allow to edit XWiki code from Orion and save changes to XWiki and view the results right away.

The second objective is to embed the Orion code inside XWiki to be able to run the IDE from XWiki itself. From App Within Minutes you should be able to launch the Orion IDE UI and load all the code from the AppWithinMinutes application.

Finally it should be possible to edit and XWiki class from the Orion UI.

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. 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 or him/her.

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 initiatives as to build an 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). 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 Joshua Marks, Paul Libbrecht (confirmed),  Ludovic Dubost and Flavius Olaru (to be confirmed) with regular checks with active members of the communities of the servers above.

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