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. Financial Contribution
    1. Make a Donation
    2. Sponsor a Feature or Bug
    3. Take a Support Contract
  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.

Testing

Translations

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.

Documentation

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.

Financial Contribution

Developing a production-ready and feature-rich software product such as XWiki is no small feat. It's also not free. It's not because the software is open source that it's free (a common misconception! emoticon_smile). Actually, every day, some developers work on improving the XWiki software and they need to earn a living. Some of them are employed by companies (https://www.xwiki.org/xwiki/bin/view/Main/Supporters/#HCompaniessponsoringdevelopment), in which case the company is paying for their salaries. In other cases, the developers are just individuals, paying with their own time (night and weekends). Currently the majority of the development is done through companies paying some employess to work on the software (the top sponsoring company being XWiki SAS for the moment).

In order for XWiki to remain alive and maintained over time there needs to be enough financial contributions going back to the companies and individuals working on the XWiki software. There are several ways to help with this:

Thus if you can't help by participating to the code development or other ways listed on this page, consider helping financially (either as an indovidual or through your company). This helps a lot and in turn helps you as XWiki users to keep getting exciting new features or bugs fixed. Thanks!

Make a Donation

You can donate through the XWiki OpenCollective.

Sponsor a Feature or Bug

If you see a feature missing you'd like to have or some annoying bug that you'd love to see fixed, please consider hiring one of the sponsoring companies to do it for you. This is helping the open source project in 2 ways:

  • A new feature will be added to the product and everyone will benefit. You'll also benefit since the maintenance of it will usually be taken over by the community.
  • Similarly for a bug fix, the product will get better and everyone will benefit
  • The sponsoring company will get some revenue which it will use to fund more development of the project (by definition a sponsoring company is a company having at least one active core committer on the XWiki open source project - See the Governance page for more details).

Take a Support Contract

You could take a support contract from one of the sponsoring companies. Even if you don't need such a contract, this is one way to really help the XWiki project as it generate revenues for that company and allow it to either pay for the developers it pays to work on the open source project or it'll allow it to hire more such devs.

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-node1 - Documentation