Participate
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.
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).
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.