Project-Level Processes

Accepting Contributions

Page deprecated

The content of this page is old and not relevant anymore; please refer to https://odp.finos.org/docs/project-collaboration

Project teams are required to review contributions from non-committer community members (i.e. PRs) in a timely fashion.  While this does not mean that all such contributions need to be accepted, they must be reviewed conscientiously and only rejected if there are legitimate reasons to do so.  Those reasons must be clearly documented in the PR at the time of rejection, and any resubmissions re-reviewed in good faith.

Process

In addition to the usual code-level checks a project team may choose to perform on contributions (for code quality, roadmap alignment, etc.), it is also critically important that the legal requirements of the Foundation are met.  This involves:

1. Confirming that the person providing the contribution has a Contributor Licensing Agreement in place with the Foundation (though the Foundation's CLA bot will typically check this automatically - see below).
2. Confirming that their change doesn't introduce new code or dependencies that are incompatible with the Apache Software License.

The Foundation's project infrastructure automatically checks for CLA compliance for pull requests only (here's an example of what this looks like).  Unfortunately it's not currently possible to check for CLA compliance of commits that are directly pushed to a master branch by a committer (this is a GitHub limitation).  For that reason, we strongly recommend that project teams do not add new project team members until they've verified that those contributors have a CLA in place with the Foundation.  In the meantime, you can encourage contributors to fork your project and contribute via pull requests, until such time as you've confirmed their CLA status with the Foundation's legal counsel.

Confirming that contributions haven't introduced incompatibly licensed code is inherently build tool specific, and so we are unable to provide instructions that cover all possible development setups. See the Open Developer Platform docs for more information.

Adding a New Project Team Member

Unable to render {include} The included page could not be found.

Adding a New Repository to your Project

Page deprecated

The content was moved to https://odp.finos.org/docs/project-collaboration

The Foundation encourages the thoughtful design of projects such that they result in multiple functionally independent, decoupled libraries.  One of the ways this can be done is by using multiple GitHub repositories per project (one per decoupled library).

If you have an existing project and you'd like to add more repositories to it, you should have all permissions to be able to do it. If you'd like any advancd configuration for your repository, build or release process, please reach out to the FINOS infra team. 

Although GitHub doesn't directly support the concept of a "project" (a group of related repositories), the Foundation keeps track of this information, and uses it in the catalogue, Activity Dashboards and landscape

Adding new repositories to an existing project does not require a PMC approval vote, since it's not a new contribution.  Therefore the turnaround time is typically quite short (a day or two at most).

Ensuring IP Compliance

This page was moved

Please visit https://github.com/maoo/community/blob/migrate-wiki-contents/governance/Software-Projects/Contribution-Compliance-Requirements.md

Each Project team is at the front line of ensuring IP compliance for their Project.  This primarily means two things:

1. Ensuring that all committers and contributors have CLAs in place with the Foundation before allowing their modifications to the code.
2. Ensuring that the code itself, and all of the dependencies of it, are in compliance with the Foundation's licensing guidelines.

Maintaining a High-Quality Repository

This page was moved

Please visit https://odp.finos.org/docs/project-collaboration#finos-project-blueprint

The Foundation expects project teams to ensure their repositories are well documented and make liberal use of GitHub features, in order to make it easier for other members of the community to find, evaluate and consume your software.  To assist with this, the Foundation provides an open source project blueprint repository that will ensure you have many of the basic legal and GitHub use cases covered.

Running a Standards Project

Requesting Steering from the PMC

One of the formally-defined responsibilities of the FINOS team and Board is to provide technical guidance to project teams, either:

1. upon request; or
2. when a project appears to be faltering

In order to support the second scenario and to assist in providing visibility to the Foundation's board, maintainers are required to report on their current status and recent operations when requested to do so by the Board.

Contacting the FINOS team

If a project team wishes to contact the FINOS team the can reach out via the leadership@finos.org. Projects can also go directly email at board@finos.org if they wish to escalate directly to the Governing Board.

Private or Sensitive Information

In the rare event that a project team wishes to discuss private or sensitive matters, they can reach out to individual FINOS team members or at legal@finos.org. Please note that the FINOS team is also responsible for handling Community Code of Conduct violations, so please see that page for details on reporting such incidents.