Skip to main content

FINOS Contributor Cheatsheet

Contributor License Agreement (CLA)

A CLA is a document that specifies how a project is allowed to use your contribution; they are commonly used in many open source projects.

All code contributions to all projects hosted by FINOS must be made with a Foundation CLA in place; any other contribution, such as emails, issues and meetings won't need a CLA in place.

EasyCLA is a system adopted by all FINOS projects to intercept code contributions that are not covered by CLA, in order to guide the contributor through the onboarding process; you can read more in the EasyCLA page.

Need an ICLA? Unsure if you are covered under an existing CCLA? Email

Contributing Issues


  • Have you searched for duplicates on GitHub Issues? A simple search for exception error messages or a summary of the unexpected behaviour should suffice.
  • Are you running the latest version?
  • Are you sure this is a bug or missing capability?

Raising an Issue

  • Create your issue using GitHub Issues
  • New issues contain two templates in the description: bug report and enhancement request. Please pick the most appropriate for your issue, then delete the other.
    • Please also tag the new issue with either "Bug" or "Enhancement".
  • Please use Markdown formatting liberally to assist in readability.
    • Code fences for exception stack traces and log entries, for example, massively improve readability.

Contributing Pull Requests (Code & Docs)

To make review of PRs easier, please:

  • Please make sure your PRs will merge cleanly - PRs that don't are unlikely to be accepted.
  • For code contributions, follow the existing code layout.
  • For documentation contributions, follow the general structure, language, and tone of the existing docs (if available)
  • Keep commits small and cohesive - if you have multiple contributions, please submit them as independent commits (and ideally as independent PRs too).
  • Reference issue #s if your PR has anything to do with an issue (even if it doesn't address it).
  • Minimise non-functional changes (e.g. whitespace).
  • Ensure all new files include a header comment block containing the Apache License v2.0 and your copyright information.
  • If necessary (e.g. due to 3rd party dependency licensing requirements), update the NOTICE file (found in the project's root folder) with any new attribution or other notices

Commit and PR Messages

  • Reference issues, wiki pages, and pull requests liberally!
  • Use the present tense ("Add feature" not "Added feature")
  • Use the imperative mood ("Move button left..." not "Moves button left...")
  • Limit the first line to 72 characters or less