Contribution Policy 

Introduction

Goal

Contribute code (a bug fix, improvement or new feature) to the Hippo CMS project.

Background

Everyone has read access to the source code of the community edition of Hippo CMS. 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 Hippo CMS. 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 Hippo 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.

Role  

Privilege

contributor

supply patches

committer

account with source code commit rights

reviewer

can approve / disapprove changes

Supply Patches

Legal Stuff

From a formal and legal point of view it is important for Hippo and the project (i.e. the Hippo CMS product) to make sure external contributions are granted to the project under appropriate licensing terms. For Hippo 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 Hippo CMS 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 Hippo 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.

About Non-Code Contributions

We also welcome contributions other than code, such as documentation! The process for this is less formal. The best way to get started is to post a message at the forum.