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:

• https://webauthn.org/
• https://www.w3.org/TR/webauthn/
• https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API
• https://webauthn.me/

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

Provide an Amazon AMI for XWiki to allow starting XWiki on Amazon EC2 easily.

See also this existing ticket.

The main goal is to offer more ways to distribute XWiki to make it more attractive to all kinds of usages, and thus increase our Active Installs.

Currently, XWiki offers two types of installations for Xwiki Software: One for Demo and one for production See this link. Also, there are two versions available: 12.10.5 which is a stable release, and the other is 13.1 which is up to date and latest.

Currently, Xwiki support HyperSQL, MariaDB, MySQL, Oracle, and Postgres for Database Management. Currently, AWS natively supports MariaDB, MySQL, PostgreSQL, and there's support for a fully managed Database system called Aurora which again natively has compatibility with both Postgres and MySQL. You'd have to deep dive into AWS Resources and see what would be the best way to implement this. You might want to look at RDS and Aurora for the same.

There are 6 ways to install XWiki all of which can be found here. It'll be good to have an AMI for each type of installation. You'll have to create a Launch template and Bootstrap scripts and install the required dependencies on bootup. 

The EC2 instance type can be left out to be chosen by the installer as per their requirements. Considering the long-term maintainability of the AMIs, it'd be nice to have an automated way to update the AMIs when a newer version is released. You can use and look into AWS CDK for managing Infrastructure as a Code so we can keep a check on the work you do as you progress through different phases of GSoC and you'll have to release a working image or version before each phase end. You will also have to document the progress on the wiki. 

Your communication with the community would be one of the significant factors we'd consider while considering your proposals. I do not wish to include lots of details around AMIs here and will let you be creative in choosing your approach towards solving this and would love to see that creativity in your proposals.

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:

• https://webauthn.org/
• https://www.w3.org/TR/webauthn/
• https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API
• https://webauthn.me/

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

Provide an Amazon AMI for XWiki to allow starting XWiki on Amazon EC2 easily.

See also this existing ticket.

The main goal is to offer more ways to distribute XWiki to make it more attractive to all kinds of usages, and thus increase our Active Installs.

Currently, XWiki offers two types of installations for Xwiki Software: One for Demo and one for production See this link. Also, there are two versions available: 12.10.5 which is a stable release, and the other is 13.1 which is up to date and latest.

Currently, Xwiki support HyperSQL, MariaDB, MySQL, Oracle, and Postgres for Database Management. Currently, AWS natively supports MariaDB, MySQL, PostgreSQL, and there's support for a fully managed Database system called Aurora which again natively has compatibility with both Postgres and MySQL. You'd have to deep dive into AWS Resources and see what would be the best way to implement this. You might want to look at RDS and Aurora for the same.

There are 6 ways to install XWiki all of which can be found here. It'll be good to have an AMI for each type of installation. You'll have to create a Launch template and Bootstrap scripts and install the required dependencies on bootup. 

The EC2 instance type can be left out to be chosen by the installer as per their requirements. Considering the long-term maintainability of the AMIs, it'd be nice to have an automated way to update the AMIs when a newer version is released. You can use and look into AWS CDK for managing Infrastructure as a Code so we can keep a check on the work you do as you progress through different phases of GSoC and you'll have to release a working image or version before each phase end. You will also have to document the progress on the wiki. 

Your communication with the community would be one of the significant factors we'd consider while considering your proposals. I do not wish to include lots of details around AMIs here and will let you be creative in choosing your approach towards solving this and would love to see that creativity in your proposals.

2FA requires you to enter an extra code when you log in or perform some account-sensitive action (e.g. changing your password).

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.

The idea is to create a snap package of XWiki.

The first step if to actually create a clean and working snap package for a version of XWiki. Then the generation of a snap package for each version of XWiki should be integrated to the release process.

Work on several Demo Flavors for XWiki. A Flavor is a set of XWiki Extensions working together to achieve a goal. The idea here is to propose several Demo Flavors for common usages of XWiki in order to show users how XWiki can be used to achieve these usages.

Goals & Ideas

• Identify several commons usages for XWiki. There are already some design pages that exist on this, see Flavor design. The idea is to offer some very specific flavors (not generic flavors) so that the Demo can be specific and directive / self-explanatory
• For example, you could imagine a Demo flavor for using XWiki for managing a Bike Shop. The idea would be to:
  • Write a small Applications Within Minutes application
  • Provide a simple skin and color theme for the Bike Shop
  • Install some existing Extensions that are useful for the Bike Shop use case, for example the Calendar application to manage deliveries of Bikes, or the Task Manager Application to organize tasks needed to manage the Bike Shop.
  • Write several wiki pages and provide demo content to simulate real content. Also provide content pages to explain how the demo is created using existing XWiki Extensions & technologies
• Write several small Demo flavors, depending on the size of the flavors chosen and the time available.
• Keep in mind that the goal is to demonstrate XWiki Extensions and Technologies so that users understand that XWiki is not just a wiki and can be used to implement applications.

Related

• Existing Demo Flavor. The idea is that it's too generic and should be replaced by smaller and more focused demos with demo content.

Integrate the Mermaid library into XWiki by creating an XWiki Extension for it. Mermaid is useful to create flow charts, sequence diagrams and Gantt timelines.

• JIRA issue
• Forum post

Goals & Ideas

• Create and release a Contrib Extension for Mermaid
• Offer an XWiki Rendering macro for it, {{mermaid ...}}...{{/mermaid}}
• Make it work in the WYSIWYG editor (i.e. ability to enter text and click on a button to get live rendering - Button displayed inside the Macro viewport, to toggle source and rendered view).
• Integrate it with existing Project Management Extensions so that these projects can offer Gantt diagrams for example.
  • This means ability to generate Mermaid syntax from other sources of data (e.g. from temporal XObject data for the Gantt part)
• Idea: introduce a new layout for the LiveData component of xwiki for data having either 2 dates columns or a date + duration columns so that the entries can be presented in a Gantt diagram
• Note that the work defined above are just initial ideas and it'll be up to the mentor and student to define more work since it's currently too small for 2 months of work.

Related

• PlantUML Integration
• YUML Integration

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).

The goal of this project is to integrate a recommendation system, allowing XWiki to propose similar pages when the user navigates on one XWiki document and / or to help automatize content organisation.

One of the frequent problems of knowledge management is related to the organisation of the shared content, both for content retrieval (when "reading" the wiki) and for content creation (when "writing" on the wiki). XWiki's standard features of data organisation and structuring are already trying to answer this need by providing users with tools to make it easy to organize the data, but they don't completely prevent information duplication, misplacing information on the wiki when creating new pages and difficulties to retrieve those when reading. In most knowledge management groups there would be one or more "information stewards": users that are "responsible" (formally or informally) of keeping information clean and organized (by helping the other users or by doing the cleanup themselves). The purpose of this project is to attempt to replace the human stewards with robots  .

In order to tackle this, the student should have:

• basic understanding of the problem of recommendations, as well as of existing approaches (ML/AI);
• basic understanding of the problem of (document) classification, assisted or unassisted, as well as of existing approaches (ML/AI);
• basic understanding of XWiki's content organisation (page tree, page metadata & structure) - this knowledge can be acquired during the project preparation phase;
• experience with knowledge sharing in a group (as an exercise or as a real-life activity) is a plus: collaborative notes taking, project documentation, etc.

The student will need to propose an open-source framework (or library) to be used as a base for integrating this recommendation and/or classification system. The choice of this framework is left to the discretion of the student, but it should satisfy the following points :

• It should have an Open-Source license ;
• It should be actively maintained ;
• It should provide stable versions, it should not be a project in alpha or beta ;
• It can be specialized in recommendation and/or classification systems or it can more generic and targeted for solving other machine learning problems.

The framework chosen and the motivations behind it should be exposed in the student proposal, before the start of the project.

There are 2 major axes that can be tackled by this project, the extent to which each of the axes is explored can be chosen by the student, based on their experience and/or preference:

• recommendations of similar contents to users reading / searching / creating content
• proposals of (re)organisation of the content of the whole wiki or a part of it, to help a knowledge steward identify related contents and keep the wiki organised.

As in the case of a human knowledge steward, it is probably interesting to include learning as an essential component of the robot steward in its quest for obtaining good results. 

The various usage scenarios / use cases should be explored and presented by the student in the proposal.

Making a proposal

Your proposal for this project should include the following elements. If you feel like something is missing, don't hesitate to add it to the list, or ping us on the chat in case of any question.

• A presentation of yourself, and why you would like to do this project. If you have some references in the field of machine learning or, more specifically, recommender systems, don't hesitate to mention it.
• The presentation of the framework that you propose to integrate as part of this project, along with some motivation non why you think that this framework is best suited for the project. You can also use this part to provides the strong and weak points of the framework, and show how it compares to other solutions.
• An overview of the integration of the recommendation/classification system, as you would see it. This overview can be technical (how to integrate with the framework, how to push and retrieve data, etc …) and functional (how to integrate the recommendations in the UI). This part should include both technical details about how it would be done but also scenarios that would be addressed by the integration. 
• References to the contributions done on the XWiki project up to this point (either links to JIRA issues, or pull requests).

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.

Considerations

• Regarding the form macro the idea is to design it and see if we can make it easy to implement some use cases. We should not do something generic or we'll be harder to use than HTML! It may not be a form macro but another name. Example of typical use case.
• The goal of this project is to look at our pages and find common patterns and provide macros to help implement them more easily, bringing the ability to non devs to do powerful stuff in xwiki
• There's a big part of the project at the start about researching, brainstorming and making spec proposal.
• Another source of inspiration is to also look at the snippets and find useful ones that would make sense to be as macros for users to use
• Yet another source of inspiration is to look at other wikis (such as Confluence) and find nice macros that we could have too.
• Since it's easy to script in XWiki, we've often forgotten to create plenty of small macros that can be implemented with 1 or 2 lines of code but even writing these few lines can be hard for non-devs and having a read-to-use macro could them.

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:

• https://pontoon.mozilla.org is very nice
• http://direct.hoplahup.net/tmp/Drupal-translation-ODS.png
• https://wiki.jenkins.io/display/JENKINS/Translation+Assistance+Plugin

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

XWiki supports Events for various actions done in the XWiki: creating a new page, modifying a page, doing an action, etc. It's possible to write Event Listeners in Java or in Wiki pages.

However it would be great to be able to register Web Hooks in XWiki so that events would trigger Web Hooks, i.e. call remote APIs to notify them about the event that has just happened.

Goals & Ideas

• Provide something similar to GitLab's System Hooks and Web Hooks.
• Write a generic Event Listener that listens to all events and forward them as remote API calls when events occur.
• Also provide an Admin UI so that users can register URLs for specific events.
• Implement this as a Contrib Extension and release it

The JIRA issue corresponding to this need is XWIKI-16088.

Goal

Provide a packaging/distribution to deploy XWiki on Google App Engine to allow starting XWiki on Google App Engine easily.

The main goal is to offer more ways to distribute XWiki to make it more attractive to all kind of usages, and thus increase our Active Installs.

Related

• See this old thread about XWiki and GAE