SWHID Project Governance Policy 1.0 (beta)

This document provides the governance policy for the SWHID Project. It is derived from the Community Specifications Governance Policy 1.0. Any participation in the project must adhere to the requirements in this document.

1. Introduction

The SWHID Project entails the development and maintenance of the SWHID specification, software and other related content. Activities of the project might also include outreach activities to promote the use of SWHID by the broader community and ecosystem.

2. Roles and Responsibilities.

The Project includes the following roles. Additional roles may be adopted and documented by the Core Team.

2.1. Participants. "Participants" are persons that have made Contributions to the Project subject to the Community Specification License.

2.2. Core Team. The "Core Team" is the body that is responsible for governing the SWHID Project. The Core Team will meet regularly as needed, but no less then once per semester. Examples of the responsibilities of the Core Team include:

enable the smooth running of the SWHID Project;
participating in strategic planning, such as coordinating face-to-face meetings or suggesting and approving changes to the governance model;
making decisions when community consensus cannot be reached, pursuant to the Appeal Process documented below;
adopting and maintaining policies or rules and procedures for the Project as appropriate, such as a Code of Conduct, trademark policy, and any compliance or certification policies.

2.3. Maintainers. "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 Core Team will designate one or more Maintainers for the Project. Examples of the responsibilities of Maintainers (directly or by delegation) include:

scheduling meetings, setting the agenda and keeping minutes;
leading the meetings and tracking progress;
reporting about progress to the community;
educating new Participants;
ensuring that the contents of materials accurately reflect the decisions that have been made by the Working Group.

2.4. Editors. "Editors" are responsible for ensuring that the contents of specifications produced by the Working Group are complete, coherent, and adhere to applicable formatting and content guidelines. The Core Team will designate one or more Editors for each specification document edited by the Working Group.

3. Decision Making.

3.1. Consensus-Based Decision Making. The project 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 Maintainers will determine consensus based on their good faith consideration of a number of factors, including the dominant view of the Participants and nature of support and objections. Maintainers will document evidence of consensus in accordance with these requirements, as well as minority opinions.

3.2. Appeal Process. Decisions may be appealed via submission of a pull request or an issue, and that appeal will be considered by the Maintainers in good faith, who will respond in writing within a reasonable time.

3.3. Core Team Appeal Process. Decisions that have been appealed to the Maintainers may in extraordinary cases be appealed to the Core Team for reconsideration. An appeal to the Core Team must specify in detail: (1) the specific decision that is being appealed; (2) the basis for contending that the decision was not aligned with the purposes, goals or scope of the project; and (3) an explanation of why the decision is extraordinary enough to warrant an appeal to the Core Team. The appeal will be considered by the Core Team in good faith, who will respond in writing within a reasonable time. The Core Team may decline to consider appeals that are unexceptional, unfounded or excessive, including because of their repetitive character.

3.4. Amendments to Governance Documents. The documents in this Governance may be amended by a two-thirds vote of the entire Core Team. However, entries may be added to the Notices file in this Governance repository as described therein.

4. Ways of Working.

The SWHID Project 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 the SWHID Specification. 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.

4.1. Openness. Participation is open to all persons who are directly and materially affected by the activity in question. There will be no undue financial barriers to participation. Voting membership on the Working Group will not be conditional upon membership in any organization, nor unreasonably restricted on the basis of technical qualifications or other such requirements.

4.2. Lack of Dominance. The development process will 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.

4.3. Balance. The development process should be based upon a balance of interests. Participants from diverse interest categories will be sought with the objective of achieving balance.

4.4. Coordination and Harmonization. Good faith efforts will be made to resolve potential conflicts between and among deliverables developed under this Working Group and existing industry standards.

4.5. Consideration of Views and Objections. Prompt consideration will be given to the written views and objections of all Participants.

4.6. Written procedures. This governance document and other materials documenting the SWHID Specification development process are available to any interested person.

5. Specification Development Process.

The following describes the public process by which new versions of the SWHID Specification as a whole can be transitioned from Draft Specification to Approved Specification status.

5.1. Draft. During the specification development process, Participants may submit issues and pull requests to the SWHID Specification repository. Pull requests will be merged upon Working Group approval by the Editors. Each updated version of the SWHID Specification following the merging of a pull request will be considered a "Draft Specification".

5.2. Process for Approved Specification status. Upon the determination by the Core Team that it has achieved the objectives for its specification as described in the Scope, the Core Team will Approve that Draft Specification as a candidate for "Approved Specification" status. The following process will then be used:

An announcement will be made to the Working Group's general mailing list.
The Draft Specification will then be considered a candidate for "Approved Specification" status, following a two-week review period (the "Review Period").
During the Review Period, any Participant may raise any issues regarding the Draft Specification. Such issues will be considered and resolved in the ordinary course.
The Core Team may, in its discretion, extend the Review Period for a longer period of time, but will not shorten it to be less than the initial two-week period.
After the completion of the Review Period and upon the Approval of the Working Group (which may include the absence of, or resolution in the ordinary course of, any issues raised during the Review Period), the Draft Specification will be progressed to be an "Approved Specification".

5.3. Publication. Upon the designation of a Draft Specification as an Approved Specification pursuant to the above process, the Core Team will publish the Approved Specification in a publicly available location, including the terms under which the Approved Specification is being made available.

5.4. Submissions to Standards Bodies. Only Approved Specifications may be submitted to another standards development organization. Upon reaching Approval, the Core Team will coordinate the submission of the applicable Approved Specification to another standards development organization. Participants that contributed to the Draft Specification or Approved Specification agree to grant the copyright rights necessary to make those submissions.

6. 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. Meeting minutes will be published in summary form, as appropriate (e.g., sensitive matters may not be made public). If some work is performed by collaborating via a private repository (for a limited time), the Participants will not make any public disclosures of that information contained in that private repository.