Contributing to Nuxeo

Before describing this process, here are a few points that are the basis of the Nuxeo development process and that should always be kept in mind.

• Any evolution in Nuxeo sources should be matched with a JIRA issue (http://jira.nuxeo.com/browse/NXP, or corresponding product).
• Any code evolution must be documented, in the English language.
• Any new feature, even a low-level one, must be unit-tested. Nuxeo will reject any non unit-tested code.
• Any new feature must be implemented respecting usual Nuxeo software design, leveraging Services, not putting business logic in Seam components, a bad design code could be rejected.

Translations

Nuxeo labels are stored in UTF-8 files and thus can be translated in any language. The process is the following:

1. Fork nuxeo-features/nuxeo-platform-lang (French and English) and nuxeo-platform-lang-ext (all other languages) projects. See How to translate Nuxeo DM for more details.
2. Use any standard Java i18n tool to edit the files (postfix it with the i18n code of the language you are translating).
3. Create a contribution type ticket via JIRA NXP ticket.
4. Submit your path file attached to the issue or make a pull-request in GitHub.
5. Optionally, send an email to nuxeo-dev mailing list with the subject "Labels contribution proposal".

Documentation

Contribution is welcome both for technical (Nuxeo book, FAQ, tutorials) and functional documentation. Ask on ecm@lists.nuxeo.com a contributor account for http://doc.nuxeo.com, with "Documentation contributor account request" in the subject.

Testing

Testing, particularly when Nuxeo submits a Release Candidate version of its products, is always welcome. As our products are easily downloadable, it doesn't require any specific development skill.

1. Download the version you want to test, set it up.
2. Get and read the user guide for the selected distribution and modules (Nuxeo DM, Nuxeo DAM, Nuxeo CMF).
3. For any bug you detect, ask for a confirmation on Nuxeo Answers, create a JIRA ticket, specifying the version of the product, the environment (OS, browser, ...), the conditions and the reproduction steps. You can also set the version for which the bug should be fixed. Before each release every ticket is read and depending on its severity, fixed before the release or postponed.

Improvements and bugfixes

Improving a module is always welcome and is carefully managed by Nuxeo developers. Process is through a JIRA "Contribution" ticket and GitHub. You'll get credentials to commit directly when you get used to submitting pull requests and that those one respect the framework logic and quality rules. Depending on the nature of your changes, you might be asked to sign and return the Contributor Agreement (). This is mandatory for everything that isn't minor improvement or bugfix.

1. Create a JIRA "Contribution" ticket that will hold a description of your improvements, functionally and technically.
2. Send an email to nuxeo-dev mailing list, to notify the community as well as Nuxeo developers.
3. Nuxeo will approve your specifications (or ask you some more information/change) and will give you recommendations. The JIRA issue will be in "specApproved" state.
4. Read the Coding and design guidelines.
5. Fork the project on GitHub.
6. Do your modifications in a new branch named "FEATURE-the_Jira_issue-a_short_description", respecting the coding and design guidelines. Be sure it doesn't break existing unit tests.
7. Send a pull-request.
8. In JIRA, set the ticket to "devReview" state and give a link to your pull request.
9. Finally, we can ask for some changes, putting comments on your code, then your branch will be merged by a Nuxeo developer.

New Modules

Nuxeo is highly modularized and as a consequence, it is totally possible to develop a new feature that will be deeply mixed with existing interface. Our main recommendation, among respecting coding rules and design, is to respect the usual code layout: core, API, facade, web, … If you have such a project, Nuxeo will be glad to help you designing your module, and to provide a GitHub repository, aside a web page (Wiki) and a JIRA project for the visibility of your development.

1. Start by an introductory email in the mailing list, explaining purpose of the new module you want to develop (BEFORE developing it) and how you think of doing it or how you did it (although it is always better to contact the list before).
2. After a few exchanges in the mailing list, return the Contributor Agreement signed. Nuxeo will then add you to the GitHub organization and give you rights to commit in a new GitHub repository.
3. Read and respect the Coding and design guidelines.
4. Commit your development regularly (meaning don't wait to finish everything: on the contrary commit each of your developments on a very atomic mode, mentioning purpose of your commit in JIRA (take it as an advice more than a rule).
5. Unit tests are mandatory and Test Driven Development is strongly encouraged. Functional tests could also be integrated. We'll put your module under continuous integration, if the quality of the code respects Nuxeo criteria.
6. You can ask for a code review in the nuxeo-dev mailing list.

In addition to code conventions and development good practices above-mentioned, wen creating a new module you should also take the following recommendations into considerations:

• Align your code on a recent released version or on the latest development version.
• Provide a clean POM (well indented, no duplication, inheriting nuxeo-ecm POM, ...).
• If needed, provide a list of the artifacts (libraries) or Public Maven repositories that should be added to the Nuxeo Maven repository to be able to build.
• Avoid embedded libraries.
• Avoid introducing new libraries if the equivalent already exists in Nuxeo.

Allergic to GitHub ?

If you are allergic to GitHub, you can still contribute patches:

1. create a JIRA ticket of type "Contribution" describing the problem and what you plan to do (or what you did, if it comes after).
2. Send an email to nuxeo-dev mailing list, to notify the community.
3. Read the Coding and design guidelines.
4. Fork the "master" branch of the sub-project you want to patch.
5. Make your modifications, respecting the coding and design guidelines, and check that they don't break existing unit tests.
6. Create a patch file and attach it to the JIRA ticket you created.
7. Send an email to nuxeo-dev mailing list to notify the community of your contribution.
8. The patch will either be validated or you will receive feedback with guidance to complete it.
9. The patch will be committed by a Nuxeo developer.

Contributor Agreement

Click here to download the Nuxeo Contributor Agreement (PDF).

For small patches and minimal changes, one doesn't need a contributor agreement, as it cannot be considered original work with a separate license and copyright. The contributor agreement is for folks who contribute non-trivial amounts of code (at least one new file for instance).