FINOS technical projects are free to determine their own governance so long as it is consistent with FINOS policies. However, projects are expected to adhere to best practices for open source collaboration. The practices documented here help to ensure that FINOS projects are well-documented, inclusive, free of intellectual property issues, and responsive to their communities.
Project materials and communication
Open source projects function best when their code, documentation, and roadmaps are readily accessible and up-to-date, and when the project maintainers are responsive to the community. FINOS projects are expected to:
- maintain all project artifacts (source code, standards documents, etc.) in a public repository
- maintain a public, current list of issues/tasks and their priority
- respond in a timely manner to issues raised by the community via the project's issue tracker
- ensure all commits and Pull Requests are clearly tracked against an issue
- respond to all pull requests in a timely manner, clearly communicating any issues
- participate actively in the project's chosen communications forum (e.g. mailing list, slack instance, etc.)
- provide an opportunity for all community members to participate in conversations or meetings about the project roadmap and priorities
- rely only on free and open source (or at least free-to-use) tools and file formats, to the extent possible
- communicate major events, such as significant design changes, to the community clearly and in advance
Projects should ensure that governance procedures are well-documented and followed by the team. Project governance documents should clearly state:
- the requirements for a community member to gain committer or other leadership privileges
- acceptance criteria for pull requests, including any style or quality guidelines (see the CONTRIBUTING.md template from our software project blueprint for an example)
FINOS maintains policies and procedures for ensuring that all contributed code is appropriately licensed. We require a contributor license agreement (CLA) from every contributor and use EasyCLA to flag contributions that are not covered by a CLA. When EasyCLA flags a pull request, project maintainers should not merge the pull request until FINOS has obtained a CLA from the contributor and cleared the contribution. See our Contribution Compliance Requirements for more information.