Standards Oversight Forum Charter

Section 1. Guiding Principle

The Health NZ Standards project operates transparently, openly, collaboratively, and ethically. Project proposals, timelines, and status must not merely be open, but also easily visible to outsiders.

Section 2. Project Governance

Most large, complex open source communities have both a business and a technical governance model. Technical leadership for this project rests with the Standards Oversight Forum (“SOF”).

Health NZ oversees the business governance model.

This charter can only be amended with the approval of Health NZ.

Section 3. Establishment of the SOF

SOF members can be either regular members or voting members. Regular members can attend meetings and participate in SOF discussions, but do not vote. Voting members can do everything regular members can do, and also have the ability to cast votes when consensus is not reached on a change or an issue resolution. Voting is by simple majority of SOF votes cast. If there is no majority after voting then the Chairperson will have a deciding vote.

SOF memberships are not time-limited. There is no maximum size of the SOF. The SOF must have at least four voting members.

There is no specific set of requirements or qualifications for SOF membership beyond these rules. The SOF may add additional voting members to the SOF by a standard SOF motion. A SOF member can be removed from the SOF by voluntary resignation or by a standard SOF motion. A standard SOF motion can be used to change a regular SOF member to a voting SOF member, or to change a voting SOF member to a regular SOF member.

No more than one-fourth of the SOF voting members may be affiliated with the same employer, with the exception of Health NZ (as the community's largest employer). If a change in SOF voting membership or a change of employment by a SOF voting member creates a situation where more than one-fourth of the SOF voting membership shares an employer, then the situation must be immediately remedied by the removal of voting member status from one or more SOF voting members affiliated with the over-represented employer(s).

The SOF shall meet regularly using tools that enable participation by the community (e.g. weekly on a common video conferencing tool selected by the SOF). The meeting shall be directed by the SOF Chairperson. Responsibility for directing individual meetings may be delegated by the SOF Chairperson to any other SOF voting member. Minutes or an appropriate recording shall be taken and made available to the community through accessible public postings.

SOF voting members are expected to regularly participate in SOF activities.

A SOF voting member is automatically converted to a SOF regular member if they do not participate in three consecutive SOF votes.

Section 4. Responsibilities of the SOF

Subject to such policies as may be set by Health NZ, the SOF voting members are responsible for all development within the community, including:

• Setting SOF meeting schedules and publishing agendas, including items from the GitHub repo with the sof-agendalabel.
• Publishing meeting minutes as a discussion item in the GitHub repo, using the sof-minutes label.
• Setting version release cadence.
• Version quality standards.
• Encouraging participation of the community at large.
• Being active and visible members of the community.
• Providing clear technical direction.
• Assisting with facilitation functions
• Project governance and process.
• Managing Health NZ's Standards repository (github).
• Ensuring that conduct guidelines are appropriate and being followed.
• Determining when an issue may need to have a working group created to review.
• Forming the working group out of Subject Matter Experts (SMEs) in the community.
• Mediating any technical conflicts that arise.
• Reporting community status and activity to Health NZ.

Section 5. Determining materiality of change

There is no exact definition of material change. In the case of API standards it can be interpreted to mean

• a fundamental change that would affect how an API is implemented
• the change would require change to any APIs already developed
• a change that adds or removes features available to APIs.

If developers could, or would be required to, make updates to an API as a result of the change then it is material. Note that this requires thinking about each change to determine if there is any risk to APIs already in use or being developed. If there is a potential to change how anything in production or development works then it is a material change.

If the change proposed affects spelling or grammar of the Standards and descriptions of how they operate then it is not likely to be material. However adding or removing a word may affect how APIs work and so that would be considered material.

Contributors, moderators and the SOF will review all changes for materiality and escalate any proposals that they feel are material.

Section 6. Elections

The SOF Chairperson and initial list of SOF members will be appointed by Health NZ. Membership and election rules will change over time as the community grows. Additional members may be appointed by agreement of the SOF voting members depending on the degree of activity in the community and the level of input required from SMEs.

Section 7. Voting

For internal project decisions, SOF members shall operate under Lazy Consensus. The SOF voting members shall establish appropriate guidelines for implementing Lazy Consensus (e.g. expected notification and review time periods) within the development process.

The SOF voting members follow a Consensus Seeking decision making model. When an agenda item has appeared to reach a consensus the moderator will ask "Does anyone object?" as a final call for dissent from the consensus.

For all votes, a simple majority of all SOF voting members for, or against, the issue wins. A SOF voting member may choose to participate in any vote through abstention.

All changes to this charter must be approved by the Health NZ.

Section 8. Project Roles

The Health NZ Standards GitHub repository is maintained by the SOF and additional members who are added by the SOF voting members on an ongoing basis.

Individuals making significant and valuable contributions are made invited to join the SOF as voting or non-voting members and may be given commit-access to the project. These individuals are identified by the SOF and invited to join after discussion during a SOF meeting. Modifications of the contents of the git repository are made on a collaborative basis. No one member will be able to merge a change without prior approval from at least one other member.

SOF members and moderators may opt to elevate significant or controversial modifications, or modifications that have not found consensus to the SOF for discussion by assigning the sof-agenda tag to a pull request or issue. The SOF voting members should serve as the final arbiter where required. The SOF will maintain and publish a list of current members, as well as a development process guide contributors looking to participate in the development effort.

Section 9. Definitions

• Project: a technical collaboration effort, e.g. a subsystem, that is organised through the project creation process and approved by the SOF.