Skip to content

Latest commit

 

History

History
59 lines (31 loc) · 9.25 KB

5._Governance.md

File metadata and controls

59 lines (31 loc) · 9.25 KB

Community Specification Governance Policy 1.0

This document provides the governance policy for specifications and other documents developed using the Community Specification process in a repository (each a “Working Group”). Each Working Group and must adhere to the requirements in this document.

1. Roles.

Each Working Group may include the following roles. Additional roles may be adopted and documented by the Working Group.

1.1. Maintainer. “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. Each Working Group will designate one or more Maintainer for that Working Group. A Working Group may select a new or additional Maintainer(s) upon Approval of the Working Group Participants.

1.2. Editor. “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. Each Working Group will designate an Editor for that Working Group. A Working Group may select a new Editor upon Approval of the Working Group Participants.

1.3. Participants. “Participants” are those that have made Contributions to the Working Group subject to the Community Specification License.

2. Decision Making.

2.1. Consensus-Based Decision Making. Working Groups make 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 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 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, and that appeal will be considered by the Maintainer in good faith, who will respond in writing within a reasonable time.

3. Ways of Working.

Inspired by ANSI’s Essential Requirements for Due Process, Community Specification Working Groups must adhere to consensus-based due process requirements. These requirements apply to activities related to the development of consensus for approval, revision, reaffirmation, and withdrawal of Community 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 Community Specification development process shall be available to any interested person.

4. Specification Development Process.

4.1. Pre-Draft. Any Participant may submit a proposed initial draft document as a candidate Draft Specification of that Working Group. The Maintainer will designate each submission as a “Pre-Draft” document.

4.2. Draft. Each Pre-Draft document of a 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 a 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 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 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.

5. Non-Confidential, Restricted Disclosure.

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.

6. Patent Application Disclosure; Good Faith

Disclosure is required when a Working Group Participant or Observer has knowledge of the inclusion of Necessary Claims (as defined in the Community Specification) in a patent application or granted patent owned by his / her employer (whether full time, part time or as a contractor), and that such claims are either (a) found in a patent application, granted patent in existence to relevant discussions in a working group, or (b) are found in a patent application and were based in whole or in part on information from a Working Group document (including draft or final specifications) or discussions within the Working Group that produced such document (“Working Group Claims”). The Working Group Participant or Observer must disclose the existence of a pending patent application or granted patent containing Working Group Claims upon the earlier of: (i) filing the patent application(s), or, (ii) when the claims are discussed or included in a Working Group document or discussion. A Disclosure obligation can be satisfied by making a pull request or commit to the repository’s Notices.md file and including either:

  1. the text of the filed application if public, and identification of the working group claims in question and the portion of the draft specification under development that would result in infringement, or
  2. In the case the application is non public, the appropriate information necessary for a practitioner to locate the text of the filed application, plus such detail regarding any Working Group Claims that would be necessarily infringed by an implementation of the specification under development as would not disclose trade secrets, and the portion of the draft specification that would result in infringement; in each case a “Disclosure”. Furthermore, subsequent disclosure is required for unpublished, amended and/or added claims that have been allowed by relevant legal authorities and that are Working Group Claims.

All Participants and Observers must, as a condition to participating on the Working Group, deal with other Working Group Participants honestly, fairly and in good faith in all respects.