Contributing

Version 33.1 by Vincent Massol on 2016/10/11 14:39

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. Sponsoring issues
  12. Improve contribution process

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 Enterprise 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 emails on the user mailing list 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 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:

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.

Contribute Code

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 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.
  • Add your name on the Hall Of Fame page.

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.

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 by clicking the "Sponsor This!" link on the issue itself (see screenshot below). We're using FreedomSponsors.org and you should check out their FAQ for more information on how it works.

On the other side of the coin, if you're a developer you could check the list of XWiki-related sponsored issues on FreedomSponsors.org and start fixing them to earn some money and make people happy!

sponsorIssue.png

If that does not work out for you, you can always consider getting Professional Support.

If you go for it, and by doing so you end up fixing some issues of the product itself along the way, you can always choose (and we encourage you) to contribute back those fixes to the community so that everyone can benefit and that the project can evolve.

Improve contribution process

See Contributions pain points.

Tags:
   

Get Connected