Contribution Policy

Introduction

Goal

Contribute code (a bug fix, improvement or new feature) to the Bloomreach Experience Manager project.

Background

Everyone has read access to the source code of the community edition of Bloomreach Experience Manager. However not everyone can change code in the community edition. This page describes the different roles and procedures in place for contributing source code to Bloomreach Experience Manager. The matrix below shows the different roles and their privileges. First of all, everyone can contribute through patches. A person contributing this way does not have write privileges, but supplies a patch that is subsequently applied by a committer. Only BloomReach can make a person a committer. To become a committer you need to have supplied several patches to prove your credibility as a solid developer.

Supply Patches

Legal Stuff

From a formal and legal point of view it is important for BloomReach and the project (i.e. the Bloomreach Experience Manager product) to make sure external contributions are granted to the project under appropriate licensing terms. For BloomReach this means your contribution, and all external contributions in general can only be incorporated if they are provided using the Apache Software License (ASL 2.0) or a different compatible license. For relatively small contributions and patches it is sufficient if you can explicitly say so as a comment on the corresponding Jira issue. For larger scale and/or further follow-up contributions we might need a signed Contributor agreement (based upon the Apache Software Foundation Contributor agreement).

So in general adding a comment to the Jira issue with the patch stating your contribution is provided to the project under the ASL 2.0 license is sufficient.

Process

This is how it works if you want to supply a patch:

1. You create a Jira issue in the Bloomreach Experience Manager project. Specify the minimal version you like this patch applied to as the fix version. Do not forget the legal stuff mentioned above. Also mention if you want to see your name and/or company mentioned in the release notes. If not, make sure that you use a customer specific Jira project to create the Jira issue.

2. You attach the code, properly formatted and including javadoc and unit tests, to the Jira issue.

3. When you have created a new issue the helpdesk will send it for triage to our Engineering team.

4. The Engineering team reviews and evaluates whether the patch can be applied.

5. If there are issues with the code then the Jira issue is assigned back, go to step 3.

6. If there are no problems then the Engineering team will commit the code to the current development trunk, and backport to the minimal maintenance branch as needed or feasible.

Note on Jira Issues and Backporting Code Between Versions

Within BloomReach we create separate issues for backports. The reason is that otherwise (with a single Jira issue that is) the fix-for version of the Jira issue can be inaccurate between initial commit and backport. For example, if you later update the fix-for version it is hard to tell when the backport was applied and requires a search in the commit logs to be sure.