This document provides the governance policy for the development of the FDC3 specification and related materials in the FDC3 Standard (the “Working Group”).
The Working Group includes the following roles:
“Participants” are those that have made Contributions to the Working Group subject to the Community Specification Contribution Policy 1.0. The FDC3 Standard Working Group has the specific purpose of defining and releasing subsequent updates to the Standard. In practice, that means people that attend and contribute to meetings, raise issues, pull requests (to submit patches to the Standard) and reviews.
Becoming an FDC3 Participant is as easy as attending a meeting and/or raising issues for changes you'd like see in the Standard, commenting on issues others have raised or even asking questions (which can often result in the clarification of the Standard's documentation to help others with the same questions in future).
Participants may register to vote on changes to the FDC3 Standard (see Section 2 below). To do so use this link: [email protected] to send a templated email email to join the enrolled voting participants group.
Upon enrollment as an FDC3 voting participant, you will be invited to join the FINOS GitHub organization and the fdc3-participants GitHub team.
The Working Group may form one or more "Discussion Groups" to organize collaboration around a particular aspect of a specification. Discussion Groups are for discussion only. Approval of all portions of a specification is subject to the consensus-based decision-making process of the FDC3 Standard Working Group.
“Maintainers” are responsible for organizing activities around developing, maintaining, and updating the specification(s) developed by the Working Group. Maintainers are also responsible for determining consensus and coordinating appeals. The Working Group will designate one or more Maintainer(s). The Working Group may select a new or additional Maintainer(s) upon Approval of the Working Group Participants.
“Editors” are responsible for ensuring that the contents of the document accurately reflect the decisions that have been made by the group, and that the specification adheres to formatting and content guidelines. The Working Group will designate one or more Editor(s). The Working Group may select a new Editor upon Approval of the Working Group Participants.
Once you are an enrolled participant in FDC3, you can apply to become an editor or maintainer by contacting the existing FDC3 maintainers at [email protected] and then seeking the approval of the FDC3 Standards Working Group. Generally, the maintainers will look for both a history of contribution to FDC3 and a commitment to investing sufficient time in the role from any prospective candidates before proposing them to the Standards Working Group for approval.
If you are new to FDC3, but willing to make the investment of time, the maintainers can work with you to build up a history of contribution.
2.1. Consensus-Based Decision Making. The Working Group makes decisions through a consensus process (“Approval” or “Approved”). While the agreement of all Participants is preferred, it is not required for consensus. Rather, the Maintainer(s) will determine consensus based on their good faith consideration of a number of factors, including the dominant view of the Working Group Participants and nature of support and objections. The Maintainer(s) will document evidence of consensus in accordance with these requirements.
2.2. Appeal Process. Decisions may be appealed be via a pull request or an issue. The Maintainer(s) will consider each appeal in good faith and will respond in writing within a reasonable time.
Inspired by ANSI’s Essential Requirements for Due Process, the Working Group adheres to consensus-based due process requirements. These requirements apply to activities related to the development of consensus for approval, revision, reaffirmation, and withdrawal of specifications. Due process means that any person (organization, company, government agency, individual, etc.) with a direct and material interest has a right to participate by: a) expressing a position and its basis, b) having that position considered, and c) having the right to appeal. Due process allows for equity and fair play. The following constitute the minimum acceptable due process requirements for the development of consensus.
3.1. Openness. Participation shall be open to all persons who are directly and materially affected by the activity in question. There shall be no undue financial barriers to participation. Voting membership on the consensus body shall not be conditional upon membership in any organization, nor unreasonably restricted on the basis of technical qualifications or other such requirements. Membership in a Working Group’s parent organization, if any, may be required.
3.2. Lack of Dominance. The development process shall not be dominated by any single interest category, individual or organization. Dominance means a position or exercise of dominant authority, leadership, or influence by reason of superior leverage, strength, or representation to the exclusion of fair and equitable consideration of other viewpoints.
3.3. Balance. The development process should have a balance of interests. Participants from diverse interest categories shall be sought with the objective of achieving balance.
3.4. Coordination and Harmonization. Good faith efforts shall be made to resolve potential conflicts between and among deliverables developed under this Working Group and existing industry standards.
3.5. Consideration of Views and Objections. Prompt consideration shall be given to the written views and objections of all Participants.
3.6. Written procedures. This governance document and other materials documenting the specification development process shall be available to any interested person.
4.1. Pre-Draft. Any Participant may submit a proposed initial draft document as a candidate Draft Specification of the Working Group. The Maintainer(s) will designate each submission as a “Pre-Draft” document.
4.2. Draft. Each Pre-Draft document of the Working Group must first be Approved to become a “Draft Specification”. Once the Working Group approves a document as a Draft Specification, the Draft Specification becomes the basis for all going forward work on that specification.
4.3. Working Group Approval. Once the Working Group believes it has achieved the objectives for its specification as described in the Scope, it will Approve that Draft Specification and progress it to “Approved Specification” status.
4.4. Publication and Submission. Upon the designation of a Draft Specification as an Approved Specification, the Maintainer(s) will publish the Approved Specification in a manner agreed upon by the Working Group Participants (i.e., Working Group Participant only location, publicly available location, Working Group maintained website, Working Group member website, etc.). The publication of an Approved Specification in a publicly accessible manner must include the terms under which the Approved Specification is being made available under.
4.5. Submissions to Standards Bodies. No Draft Specification or Approved Specification may be submitted to another standards development organization without Working Group Approval. Upon reaching Approval, the Maintainer(s) will coordinate the submission of the applicable Draft Specification or Approved Specification to another standards development organization. Working Group Participants that developed that Draft Specification or Approved Specification agree to grant the copyright rights necessary to make those submissions.
Information disclosed in connection with any Working Group activity, including but not limited to meetings, Contributions, and submissions, is not confidential, regardless of any markings or statements to the contrary. Notwithstanding the foregoing, if the Working Group is collaborating via a private repository, the Participants will not make any public disclosures of that information contained in that private repository without the Approval of the Working Group.