Participate
Approval notice
Participation clarifications were circulated at the July 17th 2019 Board Meeting and approved via omnibus resolution.
Participating in a Project
One of the best things about open source in general, and the modern "social collaboration" workflow in particular, is that participation isn't restricted to a core development team. Anyone can fork a project at any time, make some changes to it, and submit those changes back for review and incorporation into the software, potentially sparking a long and productive collaboration.
Because the Foundation uses public GitHub repositories for all source code management, their process is what's used by the Foundation to support this workflow.
If you have an interest in participating in a project but you're not sure where to start, some project teams will label issues with help wanted or good first issue tags; ideas to get involved are also socialized in the foundation's "This Week at FINOS" weekly email (published via the Community mailing list; to the community+subscribe@finos.org). These issues and calls for help are a great way to get started on contributing to a project, as they've been pre-vetted by the project team and generally won't be overly complex or time consuming to implement.
The Foundation also encourages non-code contributions in the form of issues (bug reports and enhancement requests), documentation updates, and so forth. These are also highly valued contributions, and project teams typically appreciate this kind of input just as much as code-level contributions. Most projects host an issue tracker on their GitHub repository, and if not will provide instructions on where issues should be raised instead.
Quick Links
- Know our Programs
- See our Community Quickstart
- Join a Meeting
- Reach out to a Program mailing list
- Join an upcoming FINOS event
Participation in the activities of the various FINOS Programs is open to anyone, whether you work in the industry or not. Come join us in making Financial Services a more innovative and productive industry!
Note that while you are free to fork and modify any of our projects at any time, for a pull request to be merged (accepted) you will need to have met our contribution requirements; notably you will be required to have a CLA on file with us. The Foundation uses a GitHub bot to automatically validate CLAs each time a pull request is submitted to a Foundation-hosted project, so don't be shy about submitting a pull request even if you don't have a CLA yet, as doing so will initiate the process. See Contribution Compliance Requirements for more detail.
Some Projects may have additional contributing guidelines; for example requiring a particular coding standard. These will usually be documented using GitHub's Contributing Guidelines feature, meaning that you will see a link to the guidelines from various places in the GitHub UI. Before contributing to a project you should ensure you've familiarized yourself with the project's contributing guidelines, as doing so will help minimize the number of spurious review and edit cycles the PR needs to go through. As a Project Lead you can leverage the template Project Blueprint provided by FINOS to jumpstart your project with proper contribution guidelines.
Participating in a Working Group
Working Groups welcome subject matter experts to join them on collaborating on the development of modern standards relevant to the Financial Services industry. The best way to start participating in a Working Group is to subscribe to the group's mailing list, attend the group's scheduled calls, and use both to get a sense of the current priorities of the group and their working model.
Working Groups are expected to document participation eligibility criteria, their mailing list information and meeting information on their wiki page, located within the respective Program wiki space (see the KDB Working Group as an example). As a participant, you may also contact the Program's Management Committee (PMC) for guidance, if it's not clear how to engage with a given Working Group within their purview.
Different types of Participation
Participation
Participation in a Working Group involves the opportunity for a contributor to join and - critically, speak at, Working Group meeting calls, and post to the WG's mailing list, in order to express their opinions.
Working Groups may create and enforce additional participation eligibility criteria or requirements (subject to approval by their respective PMC); an example might be to require a particular area of industry expertise (e.g., interest rate swaps) or knowledge of a programming language (e.g., C++) or library. These criteria should also be clearly documented on the Working Group's wiki page (see the KBD Working Group as an example).
Criteria and passive participation
Active participation
The FINOS Community is based on the "governance by contribution" principles. Therefore we encourage participants to Projects and Working Groups to take an active role by contributing actual code or sweat equity (taking the minutes, follow up on action points to meetings, etc). For this reason in late 2018 the Board introduced the Active Participation Policy which identifies active participants in our Projects and Working Groups to also provide a guidance on listing contributors and contributing organizations to a specific Project or Working Group. If you are curious about individuals and organizations actively participating to our Project and Working Groups make sure you check out the Program Status Dashboard.
Passive Participation
Another option, geared for those new or unfamiliar with a Working Group, is passive (listen-only / read-only) participation. Passive participation allows those in the FINOS Community so inclined to check out a Working Group for a bit to see if they'd like to get involved on an on-going basis, usually with an eye towards demonstrable active participation. Other than possibly a brief introduction at the start of the call, it's expected that passive participants are essentially auditing the calls (and/or reading mailing list threads and Github issues, as the case may be) in listen-only (or read-only) mode. Moderators of meetings may choose to open a Working Group meeting to questions from passive participants if they choose, but are under no obligation to do so. Critically, passive participation, by either an individual or organization, is intended to be finite and limited in duration.
Use (and Misuse) of Passive Participation
The primary purpose of passive participation is to provide an opportunity for potential participants newer to the working group or project to understand the topics discussed, depth of the discussions, and/or any technical/product/industry experience expected for on-going participation.
Passive participation is not intended to be used for indefinite auditing or non-collaborative purpose (e.g. seeking competitive insights). Passive participants will typically attend a limited number of meetings, after which they'll seek to join as a participant (and have met any eligibility criteria, if they exist) or cease attending.
Working Group chairs have the right to determine if ongoing passive participation in a program working group or project, by either an individual or organization, appears to be contrary to the spirit of this policy and to bring the participant's eligibility for ongoing participation to a decision as needed. If advice is needed on these matters, don't hesitate to reach out to the FINOS team and consider starting a discussion on the respective PMC Private list.