This page hosts information and project ideas for the open source project XWiki related to the Google Summer of Code 2020 mentorship program.

XWiki has also been participating to Google Code-In since 2017.

About GSoC

You can learn a lot about the program by reading the GSoC FAQ. The timeline of this year's edition is given here.

XWiki Guidelines

Being part of the XWiki community means knowing our rules and practices. As a GSOC student you need to make sure you read and apply our guidelines. 

Student Application template

When applying for one of our projects, please provide this information about yourself and the project you choose in the application which you submit to Google.

Selected Projects for GSoC 2020 (0)

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

Proposed Projects (15)

Students can come up with their own ideas, but the ideas need to be proposed and discussed on the mailing list.

Rewriting the Excel Plugin

Rewriting the current Excel Plugin extension

Work to be done on the extension

  • Previous useful features with a newer implementation
  • Support for XLSX format
  • If the content is to be processed on the front-end. Then the integration of the newer SheetJS will be a good option (https://github.com/SheetJS/sheetjs)
  • Ability to display multiple sheets as tabs
  • Mapping custom tab names with sheets
  • Using the newer Chart.js Integration extension with the application

Coordinated by


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

Javascript Visualizations Integrations

The objective of this project would be to integrate powerful Javascript visualization libraries in XWiki and particularly those that would allow editing of the visualization, and extend XWiki internal APIs to make it easier to integrate such libraries.

Examples libraries to integrate:

- mapjs mindmap (includes wysiwyg modifications on a mindmap)
- vis.js timeline & graph (includes wysiwyg modifications on a timeline or graph
- vizjs (graphviz)

In terms of XWiki features that could be integrated in the XWiki core:

- support for a REST api to save the content of a macro being edited
- support to saving an "image" version of the visualization capturing the div including the visualization (which would allow PDF export on the visualization)
- support for realtime rendering of a visualization versus the macro content (change the graphviz content and render it in realtime)

Coordinated by


Estimated workload: 3 month.
Read more...

Translation in context

XWiki 4.4 introduce new translation macro which will allow to find easily translated content in a page when using annotated HTML5 renderer (you can see the result by adding ?outputSyntax=annotatedhtml in the URL).

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:

Location where to code this: https://github.com/xwiki-contrib/application-translation

PAC4J based universal authenticator

The idea is to build a bridge authenticator around PAC4J. XWiki allows writing custom authenticator and there is many of those, see http://www.xwiki.org/xwiki/bin/view/Documentation/AdminGuide/Authentication/#HCustomAuthentication but they are written one by one and they don't share much with each other.

It would be nice to have the possibility to reuse the tons of authenticators that comes with PAC4J. Doing that means doing some plumbing and wiring to transmit all the information required by PAC4J and back to the XWiki authentication API (and UI when required).

JCR attachment store and storage manager

XWiki Standard current provide two different stores for attachments and deleted documents:

  • filesystem storage (the default)
  • hibernate storage

See https://www.xwiki.org/xwiki/bin/view/Documentation/AdminGuide/Attachments#HAttachmentStorage for more details about the attachment store.

The idea is to add a JCR-based (Java Content Repository) XWiki storage to make possible to plug many possible implementations. Also, with the multiplication of stores, a tool to move data from one store to another would be necessary.

The expected minimum for the project are:

  • a generic JCR bridge extension
  • an extension pulling the bridge and a well tested implementation of JCR (like Jackrabbit Oak)
  • an application to move data from one store to another

Add WebAuthn support to XWiki

The idea is to allow browser to automatically authenticate on XWiki using the new WebAuthn standard.

For more details about WebAuthn see the following links:

See https://www.xwiki.org/xwiki/bin/view/Documentation/AdminGuide/Authentication/ for details about XWiki authentication framework.

Set of useful Macros

Develop a set of XWiki Rendering Macros to make it easy to perform well-defined tasks in XWiki for non-technical users. Right now everything is possible using the Scripting macros of XWiki. However that's reserved to technical users. The idea is to identify common needs and implement specific macros to fulfil those needs.

Goals & Ideas

  • Form macro + Button macros to avoid needing the use of HTML macro and very simply add a button or a form in a wiki page. See also Form in page FAQ
  • Search macro to display a Search box in a wiki page and to display search results, with possibility of passing search parameters.
  • Members macro to display all the members of a given Group into a LiveTable and/or a Tree
  • Contributors macro to display all the authors who have contributed to a wiki page.
  • Develop these new macro as XWiki Extensions on XWiki Contrib and release them.
  • Propose new macros if time permits it. Ideas can be taken from New macros idea list. Some of these macros have already been implemented but the implementation may not work anymore in the latest versions of XWiki or can be improved. Improving them using new technologies would be great.

Coordinated by


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

Screenshot in translation platform

The idea of this project is to provide some tools to improve information about translation context, and in the end to help our translators contributors doing their job.

XWiki is using Weblate as a translation platform, see: https://l10n.xwiki.org. Weblate provide the capability to put screenshots in some translation key to help understand where it is used. See for an example: CAPTCHA translation.

So the idea is to improve the XWiki Application Translation (https://github.com/xwiki-contrib/application-translation) to allow a "screenshot mode": in that mode, a contributor would be able to find every translation key without a screenshot, and to create an upload it automatically to the translation platform.  

Wiki Gardening Engine

Overview

As a knowledge management software, it is critical for XWiki to help its users to better organize the information that is put on the wiki.
One frequent problem of wikis is that content is being put in wikis but can not be capitalized/used because it's difficult to retrieve once put in the wiki (because not properly organised, or because search engines are not performant enough).
Usually, in all communities that collaborate around creating a knowledge base, there are a few people (the "gardeners") that watch over the good organisation of the wiki, make sure that all content that is being added is not duplicate, that it is put in the proper place on the graph of knowledge, that relations are properly setup with related documents, etc. The purpose of this project is to use all available language processing / artificial intelligence / machine learning tools in order to create replace the gardeners with robots.

Objectives

The main goal of this project is to build a tool to help document editors to better organize their pages and the pages contents. This tool should be a combination of machine learning coupled with natural language processing. The tool should be able to propose different forms of organisation of content to the editors, which editors can apply to their content or not. Ideally, the automatic gardener would learn from the answers of the editors and improve its algorithm.

A few examples of gardening actions:

  • detecting duplicate content
  • proposing to update a page rather than create a new page
  • inferring a structure (in the sense of the wiki's structured pages) from the created content and proposing to add this structure to a set of pages
  • proposing a location for a page on the wiki (depending on its content)
  • etc. The list is really open, a full analysis of the possible actions should be done by the student.

Requirements

  • Good knowledge of machine learning
  • Good knowledge of Java
  • Basic understanding of knowledge management needs

Other resources

Data migration framework

Overview

Documents stored in XWiki can contain structured data, in the form of XObjects. The structure of these XObjects are defined by XClasses, that can also be created in XWiki documents. Learn more about how XWiki manages XClasses and XObjects here.

Most of the application that we create inside XWiki depends on this model, as it is really easy to access and edit (through a simple page edition). However, once a data model (through XClasses) is defined by an application, it is hard to rework it. On the contrary to databases where it is possible to create migration scripts, XWiki does not provide a migration framework in its core.

Technical structure

The goal of this project is to make improvements to an already existing migration framework (see the documentation and the code). The existing framework can be divided in three components :

  • The core of the framework : its APIs and its main components
  • Migrators : we define a migrator as "something that will execute a migration in the wiki". A migrator could migrate XClasses from one model to another (as explained above), migrate a document content to another document, etc ... the idea is also to help application developers creating their own migrators specific to their use case.
  • The development toolkit : a set of scripts and services that can help an XWiki application developer creating new migrations for his application.

Objectives

As part of this project, you will contribute in the following :

  • Creating new migrators in the framework itself
  • Make sure that migrations can be executed when upgrading an extension
  • Improve the development toolkit of the migrator to help application developers create new migrations
  • Improve the testing strategy of the whole framework

Requirements

A good knowledge of the Java language is needed along with some experience in development in general. You don't need to fully understand the complete structure of XWiki before starting this project.

Other resources

CryptPad Integration

The objective of this project would be to provide an integration between XWiki and CryptPad.
There are multiple levels of integrations to implement:

Feature 1: A simple macro to display a live document from CryptPad in XWiki
Feature 2: I have a document on CryptPad and I want to retrieve it and store it in the Wiki
   2a: Wysiwyg documents
   2b: Markdown documents
   2c: OnlyOffice documents
Feature 3: I have a document in an internal XWiki and I want to edit it with external users. I push the document to cryptpad for editing there and I have a way to retrieve it
   3a: XWiki document -> Wysiwyg document
   3b: XWiki document -> Markdown document
   3c: XWiki Attachment -> OnlyOffice documents

The project is challenging as CryptPad is integrating client-side cryptographic security, and multiple ways to store documents, it is necessary to run code in Javascript to read and write CrytpPad documents. This could be done either in the browser or using the Java based Nashorn engine on the server side.

This project will require both Java skills and Javascript skills. The student will have access to a mentor with experience with both XWiki and CryptPad.
 

Coordinated by


Estimated workload: 3 months.
Read more...

Implement PDF export with XHTML and paged CSS

Currently, the PDF export of XWiki is implemented based on XSL-FO and transformation of XHTML to FO. This poses a couple of problems, mainly related to the current level of support of FO from libraries implementing FO to PDF transformation, as well as the limitations of automatized transformation of XHTML to FO. The problems are mainly related to styling limitations, auto-layouting, etc.

The idea is to try to replace this with a pure XHTML & CSS (paged CSS) export, using an open source library for producing PDFs out of this.

This is only the first step of this project, the next steps being to validate that all customisation that is currently possible on the PDF export will remain possible with the new tool, and explore the new capabilities of the export (once ported to the new technology), build tools for it, etc.

See:

Coordinated by


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

Android Authenticator Enhancement

There is an Android Authenticator application (Google Play link), which aims on synchronization of contacts from any required XWiki instance and able to get the main info about users: phone number, e-mail and others. Currently, this project is already realized, but we have a few possible ideas to improve it: 

  • Upgrade dependencies, fix bugs, minor improvements, actualizing of Jenkins build
  • Integrate XWiki notification with Android notifications system (to be warned when something happen in the wiki and click to go to the page)
  • Convert the current application into:
    • A library which contains most of the current application and can be used to create dedicated application authenticators for specific instances of XWiki
    • The current authenticator/application but this time based on the new library
    • A new authenticator dedicated to xwiki.org to serve as an example for people whiling to build their own dedicated XWiki authenticator

Improve DokuWiki Importer

DokuWiki importer has seen two iterations in GSOC so far in 2017 2018. There's still room for plenty of improvements. 

  • Fix remaining bugs. 
  • Understand and document the Macro Framework. 
  • Add support for popular DokuWiki plugins using the Macro framework. 
  • Add more syntax extensions like Fallback formats

GitHub Importer

The idea is to develop an importer to import GitHub pages written in GitHub-flavored Markdown into XWiki pages written in XWiki Syntax 2.1.

To do that you would use the following existing modules in XWiki:

Here's an idea of a possible implementation workflow:

  • Since there's no GitHub REST API to access GitHub wiki pages, use the XWiki Git API to checkout/clone the underlying Git repo containing the GitHub wiki pages.
  • Write an input Filter that takes as input a Git repo containing GitHub wiki pages. Use the existing XWiki Instance output filter to convert that into wiki pages.
  • Use the Markdown Syntax to parse the GitHub pages and use XWiki Rendering APIs to convert that to XWiki Syntax 2.1
  • See this snippet to import from GitHub

Coordinated by


Estimated workload: 2 man month.
Read more...

Contact us

You can ask for more information about each project proposal and interact with the community and mentors through the usual communication channels: mailing list (devs AT xwiki.org) or the IRC channel.

What's next after GSOC?

First and foremost: Thank you for having participated to XWiki!

We want to keep you in the community for as long as possible. We understand that you may have school projects to carry on and won't have the time to continue participating much immediately after GSOC. However, we're really keen to see you coming back to this community when things settle a bit more and you get some time again.

Here's some visibility and ideas of what's next after you've completed a GSOC project and opportunities you may have:

  • You could be voted as Committer
  • You could get hired by one of the companies doing some business on top of the XWiki project
  • Become a Google Code-In mentor
  • You could propose a school project, PhD, etc about XWiki to your teachers!
  • You'll be able to add a nice line to your CV about having participated to an open source project emoticon_smile
  • You can ask for recommendations on LinkedIn, Facebook, etc about your work as a GSOC student
  • (Future, doesn't exist ATM) Your name on the Hall of Fame
  • (Future, doesn't exist ATM) Receive an XWiki GSOC t-shirt
  • (Future, doesn't exist ATM) Be sponsored to take about XWiki at conferences
  • (Future, doesn't exist ATM) Be able to implement some bounties for XWiki and get paid for it
  • (Future, doesn't exist ATM) Be invited to physically participate to an XWiki conference

Previous GSoC editions

Tags:
Created by Eduard Moraru on 2012/02/29 02:09
   

Get Connected