XClams is follwing the XWiki.org process for contributing.

We're always looking for contributions! Here are some ways to participate in XWiki's development:

  1. Give us your Feedback
  2. Report an issue
    1. Reporting a security issue
  3. Help other users
    1. Strategies for answering questions
  4. Spread the word
  5. Join the Community
  6. Testing
  7. Translations
  8. Documentation
  9. Contribute Code
  10. Fixing bugs or new Features/Improvements
    1. Code acceptance criteria
    2. Coding rules
  11. Contribute Designs
  12. Sponsoring issues
  13. Improve contribution process
  14. Google Summer of Code
  15. Google Code-In

Give us your Feedback

Do you have a great idea? Just tell us! Send your feedback to the user or developer mailing lists or in the XWiki Survey. The feedback could be also about something that does not work, something that could be improved, a feature you'd like to see, etc. Or simply it could be that you're a happy user. Letting us know that helps a lot!

You could also check the feedback we've already received. If you like XWiki, Writing a nice quote about it would be really nice too. See examples. You could also tweet it using the #xwiki hashtag.

Report an issue

You can report issues to the XWiki issue tracker (you'll need to register an account there the first time). The issue tracker project to report in is usually the Platform project.

Reporting a security issue

There are 2 options:

  • Create an issue in the Platform project and make sure to select "Confidential" in the "Security Level" field so that the issue is made private and cannot be accessed by anyone evil who would use the knowledge to hack into XWiki instances.
  • Send a mail on the Security Mailing List if you prefer to discuss the problem instead of registering an issue (for example if you're not sure it's a real problem). Note that reporting an issue will also send a notification mail to the Committers of the project and they'll be able to reply to you too.

In general we recommend using the issue tracker since this allows the Committers to have a registered issue which they know they won't be able to forget! emoticon_smile

Help other users

Have you gained some experience with XWiki? How about sharing your experience with others? Answer questions on the user forum or on IRC.

Strategies for answering questions

Here's a good strategy that improves the XWiki documentation on xwiki.org:

  1. someone (A) asks a question (on a xwiki list, forum or IRC)
  2. someone (B) knows the answer
  3. B verifies that the answer can be found on xwiki.org and if so gives a link to it in the reply to A
  4. If the answer is not found on xwiki.org, then B adds it (*) and in his reply to A he provides a link to the answer (see the Documentation chapter below for some tips)

In this manner we all enrich the XWiki documentation and it'll only take marginally longer to answer questions. The next time someone asks the question again we can simply point him/her to the location on xwiki.org

What happens otherwise is that people will give very long and elaborate answers with lots of knowledge/wisdom in them. After that another person comes in, asks the same question and we answer again, etc. The results are:

  • the xwiki.org documentation is not better
  • overall as a team we are less efficient 

Spread the word

Do you like XWiki? Spread the word about it! In any way you would prefer, like Tweets, Articles, Blogs, Books, Talks at conferences, Discussion with colleagues, etc.

Join the Community

Want to find others to discuss/promote XWiki use? Add yourself to the XWiki Users, Groups & Staff map.



Is XWiki not available in your native language? Are current translations not good enough or just not complete? By contributing to the Translation Wiki you can improve that.

You could also help by fixing an open translation-related issue.


Not satisfied with the XWiki documentation? You have 2 options:

And if you wish to write a new documentation page or new tutorial, feel free to do that in the Drafts area and ping the devs on the forum on using the chat when it's ready or if you have questions, and we can talk together about where to move it in the doc proper.

Not sure what to work on? Check out the pending documentation todos, pick an issue and start contributing. Feel free to create your own todo as well.

Last but not least, please follow the Documentation guidelines!

Contribute Code

To help you contribute code we've prepared some onboarding instructions.

More generally there are various ways to contribute code:

  • If you've developed some XWiki Extensions (applications, macros, even some code snippets in the form of scripts) you can share them easily with others by publishing them on the extensions wiki.
  • If you're also interested in sharing the source code we encourage you to publish the code as an XWiki Contrib Project. This allows others to work collaboratively with you on this code and improve it and fix bugs.
  • If you've fixed bugs or added new features/improvements to existing extensions or modules check the next section.
  • Become part of the XWiki Development Team!

Fixing bugs or new Features/Improvements

Have you fixed a boring bug or added a new feature or improved an existing one? Let us know by adding a pull request to our GitHub repository.

Are you looking for a place to start? Look at our open issues in our Issue Tracker. You can also check the Paper Cuts which lists some easy to fix issues.

Code acceptance criteria

There are a number of criteria that your code will be judged on:

  • Whether it works and does what is intended. This one is probably obvious!
  • Whether it fits with the spirit of the project. Some code may be rejected as they take the project in a different direction from that which the current development community has chosen. This is usually discussed on an issue well before the code is contributed. So if you are unsure about submitting some code please discuss it there or on the mailing lists first. Feel free to continue discussing it (with new justification) if you disagree, or appeal to a wider audience on the mailing lists.
  • Whether it contains tests. It is expected that code relating to functionality will be accompanied by unit tests and/or integration tests. It is strongly desired (and will be requested) for bug fixes too, but will not be the basis for not applying it. At a bare minimum, the change should not decrease the amount of automated test coverage. As a community, we are focusing on increasing the current coverage, as there are several areas that do not receive automated testing.
  • Whether it contains documentation. All new functionality needs to be documented for users, even if it is very rough for someone to expand on later. While rough is acceptable, incomplete is not. As with automated testing, as a community we are striving to increase the current coverage of documentation.

Above all, don't be discouraged. These are the same requirements the current Committers should hold each other to as well.
And remember: your contributions are always welcome !

Coding rules

If you submit code you need to follow these rules:

  • Put the correct Copyright in the files.
  • Ensure that your code passes the build. The build contains some Checkstyle checks that your code must pass.
  • Ensure that you have unit tests and/or integration tests.
  • Use the same code formatting as the existing code.
  • Create an issue in JIRA or assign yourself to an existing JIRA issue and add a link to the GitHub Pull Request. Please make sure you tag the JIRA issue with the patch keyword for better handling by the committers.
  • Create documentation for what you have added.

More generally you can find details in the development documentation:

In addition if you plan to contribute large amount of code that impact existing code, we recommend discussing it on the mailing list first.

Contribute Designs

There are various ways to contribute design related artefacts:

  • You can propose new ideas/features/improvements in the Design wiki
  • You can provide resources (graphics, fonts, icons) on our Media Resources page

You can get feedback on the proposals on the mailing lists or on the Forum.

Sponsoring issues

If there are issues you'd like to see fixed, you can vote them up and wait for some good soul to come along and fix them. The other option you have to try and speed up this process is to sponsor an issue. You can do that by contacting one of the companies supporting the development of XWiki and sponsor them to develop the feature you need or to get Professional Support.

At some point in the past, we were using a JIRA plugin for FreedomSponsors.org (check out their FAQ for more information on how it works). You could click on the "Sponsor This!" link on the issue itself (see screenshot below). We're using FreedomSponsors.org and you should. 

We've stopped using that since the JIRA plugin wasn't supported anymore when we upgraded the xwiki.org JIRA instance.


Improve contribution process

See Contributions pain points.

Google Summer of Code

See GoogleSummerOfCode.

Google Code-In

See GoogleCodeIn.

This wiki is licensed under a Creative Commons 2.0 license
XWiki Enterprise 12.10.5-node2 - Documentation