Getting started with the XWiki community

The general starting point for anyone new to the XWiki community and interested in helping out would be the page on Contributing.

It can be a bit overwhelming at first when going through all the online documentation for developers available at

It also matters what type of project you are planning to do. Usually, you don`t need to know how to build XWiki itself. What is more important is to understand is how to build applications/extensions on top of XWiki. For that, make sure to check out the guide on Getting started with XWiki for extension developers.

Of course, for any specific questions feel free to ask.

To learn about how XWiki is developed (tools, practices, SCM organization, etc), check the dev wiki.

For understanding how XWiki works, check the Architecture.

Increasing your chances of being accepted as a student

  • Properly introduce yourself to the community (forum and/or chat). After that, you should be active throughout the application period, using the time to better understand the project, its requirements, helping you to better write your proposal. It's very unlikely that you will understand all the details of the project just by reading its description and not clarifying the project's details before you submit your application is a red flag for problems in communication which highly decreases your chances of being selected.
  • Before the student application period completes, as a student planning to or applying at XWiki, you must show us that you are able to code. You have 2 options here:
    • Each (most) proposed projects contain a list of tasks. These tasks serve as a starting point for understanding and implementing the actual project, so any student applying must first prove (as part of their application) that they have completed these basic steps in order to be considered as potential candidates.
    • Each GSoC student applying may pick (in addition to the project tasks or in case the project does not feature tasks) one or several existing JIRA issues and send pull requests with the fixes that need to get reviewed and accepted before the application deadline is up. It can be anything (bug fixes or improvements) but it needs to be of a moderate complexity, so either one more complex issue or a mix of several less complex ones.
    • NOTE: Applications without the completed relevant tasks and with no accepted pull requests will have a very low chance of being selected.
  • Make the proposal as detailed and thought-out as possible. Show us that you understand your project, what needs to be done and what you plan to do about it (including a timeline with milestones that you plan to follow). A student who writes a proposal with a few lines that are a rewrite or the project description from the proposal list won't get good points.

Suggested way of working for accepted 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 forum (dev category) 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 access to Contrib, where they'll create their project (a repository inside xwiki-contrib). For projects which need to modify some existing code, JIRA issues will need to be created and Pull Requests to be used. It's important that Pull Requests be of good quality and small in order to be applied quickly. Once a project reach a good level of maturity (meaning it works and the code is of code quality, documented, etc.) we could even include them in an XWiki flavor (even the main XWiki flavor if applicable). At the very least, the project will be published and available as an extension published on and will be installable by anyone having an XWiki instance.
  • GSoC students should obey all Community rules. For example this means:
    • using the XWiki coding conventions;
    • using the defined communication channels: Matrix and forum;
    • etc.
  • GSoC students have time allocated to familiarize with the XWiki community and development process. As such, we require that each GSoC student continues fixing existing JIRA issues and creating Pull Requests during the Community Bonding Period (May 17 - June 7, always check the timeline). This is a critical integration step to ensure all GSoC students understand how XWiki works, how to ask questions and to communicate properly with the community and, ultimately, get to know each other.
  • GSoC student should post a quick introduction on the forum (dev category) 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 forum (dev category) when communicating about their project. They should not talk directly to their mentors. They should use the XWiki Matrix 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 mention their mentor's in the forum if they want.
  • GSoC students should not block on anything for a long period of time. They should ask plenty of questions on the forum ("Discuss" category for questions about using XWiki and "Dev" category for questions about GSOC development) (but they should also be autonomous!)
  • GSoC students should be as much as possible in contact with the community, following the forum (and answering questions, when they know what to say), stay on the Matrix 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.
  • Before each coding period ends, each student must release a functioning, easily installable and testable version of their work so far. It is perfectly fine that the entire project is not yet complete (nobody expects that until the final evaluation), but any mentor, org admin or even regular curious member of the community needs to be able to easily obtain, install and test the work done so far by the student. Things can break, placeholders/stubs can be used to fill in features that will be developed in the next coding period, but an evaluator should be able to see something that works partially (for an UI project) or somehow interact with the partial work (for backend projects). In the Software Development world, we work in iterations and students need to be able to do the same. Failure to release before the evaluation deadline can severily impact the student's chances of progressing to the next step of the program.

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 advices:

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 175 hours effort, spanning over 10 weeks)

Note that the real important part is 3) since this is a criteria for success for 1), 2) and 4).


Get Connected