Page Comparison

The FINOS governance is defined by two publicly available related policies:

1. The Program Governance Policy (PGP), which defines the responsibilities of the board with respect to Programs, as well as several universal responsibilities that all Programs have.

2. A Program Operations Policy (POP), a per-Program document that defines the specific operating mechanisms within that Program. While prospective Programs are entitled to propose amendments for the Board to approve during the /wiki/spaces/FINOS/pages/90472616, programs are encouraged to use the FINOS provided Standard POP, 

Both documents are intended to provide an applied framework that ensures the key guiding principles of the community are met:

1. Transparency and IP Cleanliness: all work produced by projects and working groups hosted by the Foundation must be published under a liberal, commercially-friendly, open source or content license, and are validated for IP compliance prior to being accepted into the Foundation.
2. Neutrality and Meritocracy: all projects and working groups are fostered under an open, meritocratic governance model known as Governance by Contribution.
3. Collaborative Structure: all collaborative efforts are grouped into use-case-focused Programs that allow like-minded community members to discover their shared interest expertise and collaborate on mutualized solutions, without losing the momentum that comes from working in small, independent, focused projects and working groups.
4. Security and Compliance: all work products are categorized with a lifecycle state that summarizes the maturity of the given artifact.  Artifacts cannot achieve "Released" status until they've gone through a rigorous, independent technical & security validation step. The security vulnerabilities responsible disclosure document defines how to manage sensitive incidents in a discrete way.
5. Diversity and Inclusion: the Foundation provides a welcoming environment for all participants.  All participants in our community are expected to observe our Community Code of Conduct to help support that environment.

Foundation-Level Governance

As mentioned above, the PGP defines several Foundation-wide responsibilities (PGP §III.A), including:

• The Board's role in community governance:
  • Approving and terminating /wiki/spaces/FINOS/pages/77955365
  • Providing steering to Programs when needed
  • Resolving questions and disputes between Programs
  • Maintaining common guidelines for the execution of Programs, for example the /wiki/spaces/FINOS/pages/75530756
• The requirement that every Program define and maintain a POP, either the standard POP, or an amended version ratified by the Board
• The requirement that every Program have a PMC Lead at all times

It is worth noting that most of these responsibilities don't impinge on the day-to-day operational activities of Projects and Working Groups - that level of governance is delegated to each Program.

Program-Level Governance

As mandated by the PGP, all Programs must have a POP that is ratified by the board at the time the Program is approved.  Typically this will be the Foundation's standard POP, but in rare circumstances there may be compelling reasons for a Program to instead propose an amended POP.

Operational governance within a Program is defined solely by the PGP and that Program's POP.

Standard POP

The standard POP defines a Program Management Committee (PMC), which provides governance for all of the Projects and Working Groups within that Program, whose activities are coordinated by a single PMC Lead (POP §II.B.a).

In the spirit of Governance by Contribution, membership on the PMC is determined automatically - it is comprised of the PMC Lead, plus the Project Lead and Working Group Chair of each Project and Working Group within that Program (POP §II.B.b).

The PMC has a number of core responsibilities (POP §II.A), including:

• Ensuring that the Program and its Projects and Working Groups are operated in accordance with Foundation policy
• Setting the high-level priorities and objectives for the Program
• Approving new Projects and Working Groups within the Program
• Approving lifecycle transitions for Projects and Working Groups
• Resolving policy questions raised within the Program
• Measuring and ensuring the ongoing progress and viability of the Program and its Projects and Working Groups
• Reporting the Program’s status, progress, and viability to the Board, periodically or upon request
• Maintaining current and accurate records of the membership of all bodies within the Program (with the assistance of Project Leads and Working Group Chairs)

Furthermore, the PMC has a number of operational responsibilities that will typically be delegated down to individual Projects and Working Groups within the Program.  These include:

• Selecting a Project Lead for each Project
• Approving new Committers to the Projects
• Selecting a Working Group Chair for each Working Group
• Approving new Participants in Working Groups

All decisions made by the PMC use the Foundation's standard decision making process (POP §II.D).

Common Collaborative Principles for Projects and Working Groups

Each Project and Working Group has responsibility for the same common set of collaborative principles (POP §III):

• Ensuring that IP compliance is maintained at all times. In practice this means ensuring that:
  • all incoming intellectual property (e.g. code) to a Project or Working Group is legally contributed;
  • all third-party intellectual property included in or referenced (i.e. as a dependency) by Projects or Working Groups is compatible with the Foundation’s licensing requirements; and
  • all Project Committers have contributor license agreements in place covering each of the Projects on which they have commit rights;
• Ensuring that all Project Members and Working Group Participants have an equal opportunity to participate, by:
  • maintaining all work products (source code, standards documents, etc.) in a Foundation-sanctioned system (source code repository, document management system, etc.);
  • keeping a public task list up to date to record all work in progress, current themes, and planned releases / publications; The task list ensures there are no surprises, and allows Project and Working Group Members to advocate for prioritization of, for example, tasks that are particularly important or urgent. A Project Lead or Working Group Chair may not always feel able to acquiesce in all such matters, but should always be prepared to provide a justification for decisions made;
  • conducting open and transparent interim project management prioritization meetings that give voice to all Project and Working Group Members and that consider input from all parties;
  • responding in a timely manner to bugs and feature requests raised by the community via the Project / Working Group's chosen source code repository and/or issue tracker;
  • actively participating in mailing list discussions relating to the Project or Working Group;
  • using only publicly available tools and file formats that are free to use; and
  • using a transparent process for granting commit rights to a Project, and accepting new Participants into a Working Group.
• ensuring that their action or inaction does not surprise the community, by scheduling reviews for major planned events in the Project or Working Group; and
• publish design proposals for public review and feedback for new features or standards, and for major refactoring or redefinition efforts.

Project-Level Governance

Project teams are required to identify and maintain a single Project Lead at all times (POP §IV.A.a), who will sit on the Program's PMC and act as a liaison between the PMC and the rest of the Project team.

In addition to the common collaborative principles listed above (and any additional responsibilities delegated from the PMC), the POP defines a number of additional responsibilities for project teams (POP §IV.C), including:

• Publicly document the requirements for a community member to gain Committer privileges;
• Publicly document the requirements for Pull Requests from Contributors to be accepted;
• Track all issues publicly, ensuring they are accurate, descriptive, and well-described by metadata (categorized as bug or enhancement request, labelled appropriately, fix version(s) identified, etc.);
• Ensure all commits and Pull Requests are clearly tracked against an issue;
• Respond to all Pull Requests in an appropriate and timely manner, including clear explanations in the case of a rejection.

How a Project team divides up these responsibilities is left up to the team.  More generally, Project teams are largely self managing in terms of what is to be worked on, in what order, and how - none of this is dictated by the Board or PMC.

Working Group-Level Governance

Working Groups are required to identify and maintain a single Working Group Chair at all times (POP §V.A.a), who will sit on the Program's PMC and act as a liaison between the PMC and the rest of the Working Group.

In addition to the common collaborative principles listed above (and any additional responsibilities delegated from the PMC), the POP defines the following additional responsibility of each Working Group (POP §V.C):

• Publicly document the requirements for a community member to become a Participant;

How a Working Group meets this responsibility is left up to the group.  More generally, Working Groups are largely self managing in terms of what is to be worked on, in what order, and how - none of this is dictated by the Board or PMC.