XWiki @ Google Summer of Code 2012

Last modified by Thomas Mortagne on 2017/03/24 12:15

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

This page hosts information and project ideas for the Google Summer of Code 2012. 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. Also, if these practices are followed, 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 that 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 or pull requests to be 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 the XWiki development process. As such we'd like each GSoC student to pick one or several existing issues in JIRA and send a patch or pull request that fixes it/them before that period ends (from April 23th to May 21st) 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 students must periodically update their progress report for the project they have been assigned to.
  • GSoC students should create a Design page where they document technical aspects of the feature they are working on: architecture, use cases, problems, various solutions with pros and cons, etc. This page should be written as an XWiki community member and not a GSoC student (there is the progress report for that), ensuring that the page will remain relevant even after the GSoC period end.
  • 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 helps them, answers their questions but also knows what they are doing. This will make the integration of their work back into XWiki 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, students have to 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.


Selected Projects for GSoC 2012 (3)

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

Improve Google Android XWiki connector by Sasinda Rukshan

Last year nice work has been does to provide an easy to use Android oriented library to communicate with an XWiki instance.

You can look at it's current state:

This year the goal is to continue improving it and start implementing some ideas of small applications based on it.

It's up to the student to write a proposal on what's he/she plans to do but here are some ideas for inspirations:

  • better integration with Android system
    • add XWiki Android account and make the connector use it so that various applications don't have to maintain their own connection informations
    • synchronize all or only followed XWiki users from XWiki user stream as Android contacts
  • various Android version for existing XWiki applications and features (as reusable android element as much as possible)
    • write and send blog article
    • edit attachment with any Android application and then automatically update it online
  • new UI elements and improvements of existing elements
  • addition to the low level framework
    • make easy to edit a document offline (keep it inn a local database and synchronize it when connection come back)
  • ...

Like last year the most important things remain:

  • produce clean, documented and maintainable code
  • always produce easy to use and as reusable as possible elements, the main goal is to make others use XWiki for their need and make it as easy as possible for them
  • follow Android standards and use native tools as much as possible

Coordinated by

.  Read more...

Responsive skin based on Foundation by Jonathan Solichin

The objective of this project is to create a new XWiki skin for mobiles, tablets and desktops, based on the responsive foundation framework (http://foundation.zurb.com/).

Coordinated by

.  Read more...

SOLR search component by Savitha Sundaramoorthi

The objective of this project is to exploit the Apache SOLR search engine as indexing and search engine for XWiki.

XWiki is a very flexible wiki, in use in massive or small sites, with both highly structured and/or very textual content. This flexibility should be in the SOLR component:

  • based on SOLR's schema and complementary information, the indexing process should be customizable to only index and store as little information as needed.
  • through code customizability (exploiting the possibility of Groovy code in pages), the transformation of a user-query to a SOLR query should be adjustable, far beyond the simple text-parsing (enabling, for example, the prohibition of some spaces, or the conversion to multiple fields based on input parameters)

Finally, this component should support calibrating the search engine's parameter (such as the Dismax' parser coefficients, the analyzers usefulness, ...) by classical quantitative methods such as precision-and-recall, which any wiki master, or a collaborator, should be able to exploit and report with.

First impulse for this work exist:

Coordinated by

. Estimated workload: 2-3 months. Read more...

Proposed Projects (18)

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

.  Read more...

Advanced Email Integration

Advanced email/chat integration would allow to have a full email/chat conversation that is captured as a discussion in an XWiki Document. Any email or jabber message in a specific channel would be automatically attached as a comment to a page. Any change or new comment to the page would be automatically sent to the jabber/email channel. An email channel could be a mailing list or a list of individual's emails.

Usecases:

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

Coordinated by

. Estimated workload: 3 month. Read more...

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

Any Integration with one or more Major Open Source Tool

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. 

Coordinated by

. Estimated workload: 3 month. Read more...

Basic Workflows

The idea would be that a user should be able to configure some automated actions to take place when certain states are achieved in the wiki. There should be simple scripts / UIs to determine whether a state needs to trigger an action and simple scripts to configure the actions to be taken, along with a potential list of predefined actions.

Since workflows are a complex and fuzzy subject, let's look at a simple example, the blog validation workflow (although validation is not very very wiki-like action, it illustrates well the idea of simple workflow):

When any user edits the content of a blog article, the blog post is hidden from public access (regardless of its state up to that point) and a mail is sent to a group of users in the wiki which are the "blog administrators".

Although this kind of workflows can be implemented in the specific wiki applications themselves (e.g. for the case above in the blog application itself), a generic workflow mechanism can be envisaged to:

  • allow such triggering to happen for any wiki document or any structure (even if it was not coded a priori in the application), potentially cross application
  • allow users that don't know code details to implement such behaviour.

Coordinated by

. Estimated workload: 3 month. Read more...

Complete overhaul of the linking UI

Links are central to wikis and to the web in general. Not once users have complained that the current link wizard from the WYSIWYG page content editor has limitations. We need a new UI that speeds up and eases the process or creating links.

Links can target internal wiki entities like wiki pages, attachments, users or groups and also external resources from the web or from the network in general. The process of creating a link has two main steps: choosing the link target and configuring the link. The new UI should offer an easy way to search/filter the possible link targets. The link configuration step should provide good defaults so that most of the time it's enough to simply choose the link target.

The new linking UI should be reusable outside of the WYSIWYG content editor, especially from the wiki content editor.

Improve Google Android XWiki connector

Last year nice work has been does to provide an easy to use Android oriented library to communicate with an XWiki instance.

You can look at it's current state:

This year the goal is to continue improving it and start implementing some ideas of small applications based on it.

It's up to the student to write a proposal on what's he/she plans to do but here are some ideas for inspirations:

  • better integration with Android system
    • add XWiki Android account and make the connector use it so that various applications don't have to maintain their own connection informations
    • synchronize all or only followed XWiki users from XWiki user stream as Android contacts
  • various Android version for existing XWiki applications and features (as reusable android element as much as possible)
    • write and send blog article
    • edit attachment with any Android application and then automatically update it online
  • new UI elements and improvements of existing elements
  • addition to the low level framework
    • make easy to edit a document offline (keep it inn a local database and synchronize it when connection come back)
  • ...

Like last year the most important things remain:

  • produce clean, documented and maintainable code
  • always produce easy to use and as reusable as possible elements, the main goal is to make others use XWiki for their need and make it as easy as possible for them
  • follow Android standards and use native tools as much as possible

Coordinated by

.  Read more...

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

Improved wiki page history

Design and implement an improved page history UI that offers:

  • direct link to see diff with previous version and ability to compare any two versions
  • improved diff view (page content and meta data, objects, class definition and attachments)
  • list of contributors (with contribution size)
  • blame view
  • permalink to any revision and to a diff between any two revisions
  • and more.

GitHub interface is a good example of how to show differences between versions, blame, emphase contributions, etc.

Issue tracking and time tracking extensions

Provide an extension with basic issue tracking functionalities.

  • ticket creation, editing, closing, monitoring
  • basic workflow functionalities
  • basic notification system

Time tracking: allow easy creation of work logs, integrated or independent to the tracked projects. These extensions will complement XWiki and will provide a more complete project management ecosystem like Redmine, Trac, Jira+Confluence and others.

Coordinated by

. Estimated workload: 3 months. Read more...

LDAP server implementation

The idea is to be able to use an XWiki instance as a LDAP server to authenticate users and get groups.

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.

Coordinated by

.  Read more...

Mobile Skin/Dashboard for XWiki

Create a lightweight mobile skin for XWiki, or rather make the already existing colibri skin websafe for the mobile devices.
There is already a version for a mobile skin done by Ludovic Dubost. 

This project will take forward and optimize it for different situations: dashboard, editing, administration, livetables, actions (copy, delete, etc.), etc. 

Coordinated by           . Estimated workload: 3 months. Read more...

OpenSocial25Integration

Based on previous work on Google Gadget and Shindig integration, the objective of this project is to implement [OpenSocial 2.5] in XWiki and support in-bound and out-bound integration. The integration could be tested with other OpenSocial compatible containers (SugarCRM, Jira, etc..)

Missions:

  • Transform any XWiki page into a Open Social Gadget
  • Transform any XWiki macros into Open Social Gadgets with editable parameters
  • Connect social APIs of XWiki using shindig
  • Create an macro to integrate an external gadget
  • Create a macro builder to transform and external gadget into an XWiki macro
  • Support authentication using OpenSocial APIs
  • Implement a prototype activity stream integration in-bound and out-bound
  • Experiment with Gadget Directories (make a proposal on how directories should work)

Coordinated by

. Estimated workload: 3 month. Read more...

Poll/Survey Application

The first objective would be to build a very simple Poll Widget allowing to ask a simple question and show the results graphically.

The second objective would be to use AppWithinMinutes for Surveys. App Within Minutes already allows to create form application. In this specific case we want to extend AppWithinMinutes for surveys:

1/ We need a slightly different presentation which is more then presentations of surveys (guest access, multiple screens, chromeless) 2/ We need to provide a survey result page

You could reuse work done from the existing Polls Application

Coordinated by

. Estimated workload: 3 month. Read more...

Responsive skin based on Foundation

The objective of this project is to create a new XWiki skin for mobiles, tablets and desktops, based on the responsive foundation framework (http://foundation.zurb.com/).

Coordinated by

.  Read more...

SOLR search component

The objective of this project is to exploit the Apache SOLR search engine as indexing and search engine for XWiki.

XWiki is a very flexible wiki, in use in massive or small sites, with both highly structured and/or very textual content. This flexibility should be in the SOLR component:

  • based on SOLR's schema and complementary information, the indexing process should be customizable to only index and store as little information as needed.
  • through code customizability (exploiting the possibility of Groovy code in pages), the transformation of a user-query to a SOLR query should be adjustable, far beyond the simple text-parsing (enabling, for example, the prohibition of some spaces, or the conversion to multiple fields based on input parameters)

Finally, this component should support calibrating the search engine's parameter (such as the Dismax' parser coefficients, the analyzers usefulness, ...) by classical quantitative methods such as precision-and-recall, which any wiki master, or a collaborator, should be able to exploit and report with.

First impulse for this work exist:

Coordinated by

. Estimated workload: 2-3 months. Read more...

Wiki Browser

Design and implement an UI that does for a wiki what Nautilus and other file managers do for the file system:

  • Browse wiki entities (wikis, spaces, pages, attachments, objects, etc.)
  • Rename/Move/Copy/Delete/Export wiki entities (single/batch, drag&drop)
  • Search/Filter
  • Tree/List view
  • Upload attachments by drag&drop
  • and more.

The UI must scale when the wiki grows large (e.g. spaces with thousands of pages or pages with hundreds of objects).

The current interface that allows some of the actions requested for this project is our Index Application.

XWiki HTML/OpenSocial Gadgets

Create a set of HTML/Ajax Gadgets to show the most important information of and XWiki Instance. The objective of these gadgets would be to allow information from an XWiki instance to be integrated in external tools (Social Networking tools like elgg, yammer or others or Portals using IFRAMES, OpenSocial Compatible Tools)

A directory of gadgets should be available listing the available gadgets and provide the URL and/or HTML/JS code to paste into another application to integrate XWiki in this application. Basic OpenSocial compatibility should be part of the project.

There should be a way to support authentication in the gadget.

Possible integration would be:

  • Activity Stream
  • Latest comments
  • Specific Wiki page
  • Any panel/macro/dashboard elements

Coordinated by

. Estimated workload: 3 month. Read more...

Previous GSoC editions

Tags:
   

Get Connected