Version 2024.08.22

Download as PDF

Abstract

This document contains both a summary of the work product process (relevant to TC Process version 22 July 2020) and some guidance on how to streamline that process. It also discusses how an OASIS Technical Committee (TC)’s Work Product progresses through the various development stages of its lifecycle.

In addition to defining some best practices, this document also defines three optional standing rules that a TC may choose to enact to simplify the process of moving documents through the various development stages. These standing rules simplify when ballots are needed, clarify when and how approvals are done, can reduce voting fatigue, and can reduce delays due to administrative processes. These standing rules can be adopted on a document-by-document basis or be adopted globally by the TC for all documents. In the latter case, a TC may consider doing this during the formation of the TC.

Scope

The best practices and standing rules included in this document can be applied to all Standards Track and Non-Standards Track Work Products of a Technical Committee. These can be
adopted by any OASIS Technical Committee on a document-by-document basis or for all documents produced by that TC.

Notices

Copyright © OASIS Open 2024. All Rights Reserved. This document is published under the Creative Commons Attribution 4.0 International Public License (CC BY 4.0).

Table of Contents

• 1. Introduction
  • 1.1 Motivation
  • 1.2 Abbreviations and Acronyms
  • 1.3 Definitions
• 2. Concepts and Background
  • 2.1 Contributions
  • 2.2 Document Stages
  • 2.3 Documents Do Not Revert to The Working Draft Stage
• 3. Document Stages
  • 3.1 Working Drafts
    • 3.1.1 New Versions
    • 3.1.2 Numbering
  • 3.2 Specification/Note/Technical Report Draft Documents
    • 3.2.1 Updates
    • 3.2.2 Numbering
    • 3.2.3 Approvals
    • 3.2.4 Standing Rule 1: Approving Additional CSD/CSN Documents
  • 3.3 Informal Document Feedback
  • 3.4 Public Reviews
    • 3.4.1 Standing Rule 2: Approving Additional Public Reviews
  • 3.5 Specification/Note/Report Documents
    • 3.5.1 Numbering
    • 3.5.2 Updates
  • 3.6 Changes During Publication
    • 3.6.1 Standing Rule 3: Approving Editorial Changes
• 4. Summary and Conclusions
• Appendix A – Work Product Process State Diagram
• Appendix B – WD and CSD Numbering Examples
  • B.1 Numbering Without Standing Rule 1
  • B.2 Numbering With Standing Rule 1

1. Introduction

This document contains both a summary of the work product process (relevant to TC Process version 22 July 2020) and some guidance on how to streamline that process. It also discusses how an OASIS Technical Committee (TC)’s Work Product progresses through the various development stages of its lifecycle.

In addition to defining some best practices, this document also defines three optional standing rules that a TC may choose to enact to simplify the process of moving documents through the various development stages. These standing rules simplify when ballots are needed, clarify when and how approvals are done, can reduce voting fatigue, and can reduce delays due to administrative processes. These standing rules can be adopted on a document-by-document basis or be adopted globally by the TC for all documents. In the latter case, a TC may consider doing this during the formation of the TC.

---

1.1 Motivation

Currently, most Technical Committees process documents through their lifecycle in a way that causes unnecessary delays, ballots, and administrative process. This document tries to address these issues.

1.2 Abbreviations and Acronyms

This document uses the following abbreviations and acronyms:

• CN – Committee Note
• CS – Committee Specification
• CND – Committee Note Draft
• CSD – Committee Specification Draft
• FMV – Full Majority Vote
• NWI – New Work Item
• OBCP – OASIS Best Current Practices
• SMV – Special Majority Vote
• TC – Technical Committee
• TR – Technical Report
• TRD – Technical Report Draft
• WD – Working Draft
• WP – Work Product

1.3 Definitions

New Work Item – A contribution that represents a proposed new TC Work Item.

Work Item – A document that is either at the Working Draft stage or at a Work Product stage.

Working Draft – A document that has not been approved as an official Work Product of the TC.

Work Product – A document that has been officially approved by the TC as a Standards Track
or Non-Standards Track document.

---

2. Concepts and Background

2.1 Contributions

A contribution is a verbal or written comment, suggestion, or document that is submitted to a TC and contains either a proposed New Work Item or proposed edits, changes, additions, or suggestions to an existing Work Item (regardless of the existing Work Item’s current stage). This OBCP document focuses on contributions that create New Work Items. While TCs need to review and consider all contributions, they do not need to accept or adopt (in part or in full) the contribution.

2.2 Document Stages

All Work Items start as a contribution to a TC, and starter templates for these contributions can be requested from OASIS Admin. Once a contribution is approved by the TC, it becomes an official Standards Track Work Product or Non-Standards Track Work Product and will progress through the following stages. A contribution may go through several revisions at the Working Draft stage before it is approved as an official Work Product.

• 1. Working Draft
• 2. Standards Track Work Product stages
  • a. Committee Specification Draft
  • b. Committee Specification
  • c. OASIS Standard
• 3. Non-Standards Track Work Product stages
  • a. For Committee Notes
    • i. Committee Note Draft
    • ii. Committee Note
  • For Technical Reports
    • i. Technical Report Draft
    • ii. Technical Report

2.3 Documents Do Not Revert To The Working Draft Stage

Once a document has been approved by the TC and advances to a Work Product, new versions of that document do not start over at the Working Draft stage. The Working Draft stage is for contributions that have not yet been approved as official Work Products. For example, when a contribution has been approved as a Committee Specification Draft, new versions of that document do not start over as Working Drafts.

---

3. Document Stages

3.1 Working Drafts

The OASIS TC Process does not talk about contributions or Working Drafts, as such, this section gives some guidance on what they are and how they should be understood.

A contribution may go through many revisions before it is either approved or discarded by the TC. Each revision of a contribution, including the first submission, is considered a Working Draft. Once a Working Draft is approved by the TC it becomes either a CSD, CND, CN, TRD, or TR.

Said another way, a Working Draft is a Work Item that has not yet reached a sufficient level of maturity as determined by the TC to be considered for and approved as an official Standards Track Work Product (i.e., CSD) or Non-Standards Track Work Product (i.e., CND, CN, TRD, or TR).

3.1.1 New Versions

TCs do not approve new versions of a Working Draft. Working Draft documents are developed either by the original contributor or the editors of the document and can be revised, updated, and released as often as the original contributor or editors desire. Each version of these documents can and should be uploaded to the official TC document repository in the “Working Drafts” directory.

3.1.2 Numbering

The first release and initial contribution to the TC should have a document stage version of “Working Draft 01”. For each additional version of the document, the stage version value should be incremented (e.g., 02, 03, 04, etc). Please see the OASIS Naming Directives document for more information.

3.2 Specification/Note/Technical Report Draft Documents

Once a Working Draft has been deemed sufficiently mature by the TC, the TC can approve the current version of the Working Draft as a Standards Track or Non-Standards Track Work Product (i.e., CSD, CND, CN, TRD, or TR) through a Full Majority Vote. Please see the TC Process for more information on how to perform ballots. NOTE: it is possible for documents to go directly from a WD to either a CN or TR due to them not needing a public review.

The figure below shows a document that was approved as a Work Product after several revisions as a Working Draft.

3.2.1 Updates

CSD and CND documents are developed by the TC and updates and revisions are performed by the editor(s) of the document. These documents can be revised, updated, and released as often as the TC desires.

TRD documents are developed by the author(s) with feedback from the TC and updates and revisions are performed by the author(s) and/or editor(s) of the document. These documents can be revised, updated, and released as often as the author(s) desire.

3.2.2 Numbering

The first version of a CSD, CND, and TRD needs to have a document stage version of “Committee Specification Draft 01”, “Committee Note Draft 01”, or “Technical Report Draft 01”. For each additional version of the document, the stage version value should be incremented (e.g., 02, 03, 04, etc.). Please see the OASIS Naming Directives document for more information.

3.2.3 Approvals

NOTE: the old Working Draft stage numbers are not retained once a document moves to the CSD, CND, CN, TRD, or TR stage, and new versions of a CSD, CND, and TRD do not start as Working Drafts.

The TC needs to approve each new version of a Committee Specification Draft and Committee Note Draft through a Full Majority Vote. The TC does not approve each new version of a Technical Report Draft, as Technical Report Drafts are developed by the author(s) with feedback from the TC. Please see the TC Process for more information on how to perform ballots. In regards to voting Section “1.11 TC Voting” of the TC Process says:

TCs may conduct electronic ballots. An electronic ballot may be conducted during a meeting using any tool available to the TC, including email, and the results must be recorded in the minutes. Electronic ballots outside of a meeting shall be made either by using the TC’s general mail list or the publicly archived electronic voting functionality provided by OASIS and must remain open for a minimum of 7 days.

This means that the TC may vote using the:

• TC’s ballot tool
• Issuing a call for objection to unanimous consent in a quorate meeting
• Performing a live ballot (e.g. show of hands) in a quorate meeting
• Issuing a call for objections to unanimous consent via email
• Performing a ballot (email responses) via email

All non live votes require the ballot to be open for at least 7 days.

The motion, the second to the motion, and the results for each ballot must be documented per
TC Process. If a call for unanimous consent receives one or more objections, then a traditional
ballot must be used.

3.2.4 Standing Rule 1: Approving Additional CSD/CND Documents

As a standing rule, the TC may authorize the editor(s) to publish additional versions of a CSD or CND either on a regular basis or at their discretion without additional motions, calls for consent, or ballots. A Full Majority Vote is required to enact this standing rule.

NOTE: Before a Working Draft can become a CSD, CND, or a CN it must pass an actual Full Majority Vote, even if this standing rule is enacted. The same is true for a TRD, though the TC does not approve each new version of the TRD, the TC must approve it as a Work Product.

If a TC is going to enact this standing rule, the TC should do this as part of the first CSD or CND ballot, but this can be done at any time. This standing rule can be revoked at any time by the TC through a Full Majority Vote. Some TCs may enact this standing rule for all documents when the TC is formed.

With this standing rule in place and once a new CSD or CND version (after the initial CSD/CND passed a Full Majority Vote) is ready to be published, the editor(s) can ask the OASIS Admin to publish the document and publicly announce it without any additional motions, ballots, or votes.

For example, if this standing rule is enacted in a TC, then:

• New CSD and CND documents should be uploaded to the official TC document
  repository in the “Approved Work Products” directory by the editors, as these documents
  are approved CSDs and CNDs, and they should have the suffix name of “-csd##” or
  “-cnd##”. The “##” in this case is the CSD or CND number.

If the standing rule is not enacted:

• New not yet approved CSD and CND documents should be uploaded to the official TC document repository in the “Working Drafts” directory by the editor(s) or chair(s) and should have a suffix name of “-pre-csd##-yyyy-mm-dd” or “-pre-cnd##-yyyy-mm-dd”. The “##” in this case is what the CSD or CND number will be once approved. For example, if CSD01 has been approved and the TC wants to approve CSD02, the document would have a suffix of “-pre-csd02-yyyy-mm-dd”.
• Once the CSD or CND is approved (by a Full Majority Vote), it can be uploaded to the TC document repository in the “Approved Work Products” directory with the normal “-csd##” or “-cnd##” suffix.

3.3 Informal Document Feedback

TCs can receive feedback at any time about any Work Item they are working on. However, it is critical that all feedback from non-TC members be submitted through the public comment methods defined in the TC Process.

3.4 Public Reviews

See section “2.6 Public Review of a Committee Specification Draft” of the TC Process for more information about public reviews.

In summary, before a Committee Specification Draft can progress to a full Committee Specification, it needs to have at least one public review. The TC needs to approve starting each new public review via a Full Majority Vote. Please see the TC Process for how to perform Public Review ballots. The TC can request additional public reviews at any time through a Full Majority Vote. If a TC decides to do a public review of a CND or TRD, it may, but it must follow the same process as defined for a CSD.

3.4.1 Standing Rule 2: Approving Additional Public Reviews

As a standing rule, a TC may approve the chair(s) to open new public reviews with each CSD, CND, TRD release, on a regular basis, or at their discretion, without additional motions, calls for consent, or ballots. A Full Majority Vote is required to enact this standing rule.

NOTE: Before a CSD, CND, or TRD can go out for its first public review it must pass an actual Full Majority Vote, even if this standing rule is enacted.

If a TC is going to enact this standing rule, the TC should do this as part of the first public review, but it can be done at any time. This standing rule can be revoked at any time by the TC through a Full Majority Vote. Some TCs may enact this standing rule for all documents when the TC is formed.

3.5 Specification/Note/Report Documents

Approval of a Committee Specification requires a Special Majority Vote. The Special Majority Vote is set up and run by OASIS Admin. See section “2.7 Approval of a Committee Specification” of the TC Process for more information about approving a CS.

In summary, in addition to the requirements around public reviews, once the TC has decided that the CSD is complete and the text is sufficiently stable, the Chair(s) can request the OASIS Admin to open the Special Majority Vote. Please see the TC Process for how to perform a CS ballot.

Approval of a Committee Note and a Technical Report only requires a Full Majority Vote.

3.5.1 Numbering

The first version of a CS or CN needs to have a document stage version of “Committee Specification 01” or “Committee Note 01”. For each additional version of the document, the version value should be incremented (e.g., 02, 03, 04, etc.). Please see the OASIS Naming Directives document for more information. It is important to note that a Technical Report, once published, is not able to be versioned at the TR stage like a CS or CN.

3.5.2 Updates

TCs should avoid advancing a Committee Specification Draft or a Committee Note Draft to the next stage if immediate updates and/or changes are still needed and/or expected. Meaning, additional versions of a Committee Specification or Committee Note should be rare as these documents are considered a final deliverable.

In rare cases when the TC needs to update a Committee Specification or a Committee Note new versions of that document do not start over as Working Drafts. A TC may decide that the proposed changes warrant going back to the Committee Specification Draft or Committee Note Draft stage. This is especially true if the changes are material or they include significant breaking changes or the changes would represent a major or perhaps even a significant minor revision to the document according to semantic versioning. However, to be clear it is not required that a document go back to a previous stage.

Regardless of whether the document reverts back to the CSD stage or stays at the CS stage, each new version of a CS requires a new public review and the TC to perform a new CS ballot. Where each new version of a CN only requires a new CN ballot.

It is important to note that an update to an OASIS Standard does require starting over at the
Committee Specification Draft phase as it is considered an entirely new version.

When updating a CS or CN:

• New not yet approved CS or CN documents should be uploaded to the official TC
  document repository in the “Working Drafts” directory and should have a suffix name of
  “-pre-cs##-yyyy-mm-dd” or “-pre-cn##-yyyy-mm-dd”.
• Once this CS or CN is approved, it can be uploaded to the TC document repository in
  the “Approved Work Products” directory with the normal “-cs##” or “-cn##” suffix and
  then be published.

The Figure below shows an example of a Committee Specification Draft being approved as a CS (note: it does not show the approvals for public reviews).

3.6 Changes During Publication

Technical Committees (TCs) at OASIS strive to produce and publish high-quality documents and specifications. However, sometimes, during the publication process, the time after a successful ballot and before the document is published, non-material, minor, and editorial issues may be found that the TC wants to fix. These issues and problems can be resolved by the TC without doing another version and possible public review as stated in Section “2.2.4 Allowed changes” of the TC Process:

After a Work Product has been approved as a Standards Track or Non-Standards Track Work Product (for example, as a Committee Specification Draft), only non-material changes may be made during the publication process. These changes can only be made in coordination with the TC Admin and a summary of changes shall be sent to the TC mailing list. The TC may continue to make changes to the next Committee Specification Draft.

3.6.1 Standing Rule 3: Approving Editorial Changes

As a standing rule, a TC may approve the chair(s) and editor(s) and author(s) in the case of a Technical Report in coordination with OASIS Admin to also make editorial changes during the publication process without requiring approval from the TC. Editorial changes are things like formatting problems, updating the table of contents, fixing spelling errors, fixing typos, addressing grammar problems, updating links and references, etc. This does not include minor text changes or larger non-material changes, only editorial changes. It is important to note that the chair(s), the editor(s), the author(s) and the OASIS Admin must all agree that these changes are purely editorial. A Full Majority Vote is required to enact this standing rule.

If a TC is going to enact this standing rule, the TC should do this as part of the first CSD/CND/TRD or CS/CN/TR ballot for a given document, but it can be done at any time. This standing rule can be revoked at any time by the TC through a Full Majority Vote. Some TCs may enact this standing rule for all documents when the TC is formed.

---

4. Summary and Conclusions

This document outlines how TCs can advance a contribution through its entire lifecycle. It also clarifies that many of the ballots that are done today can be addressed through a call for unanimous consent or by enacting standing rules to pre-grant the chair(s), editor(s), or author(s) authority to release CSDs, CNDs, and TRDs and perform their public reviews either on a regular basis or at their discretion without additional motions, calls for consent, or ballots. It also clarifies how document versions are updated and shows how documents do not need to restart at the Working Draft stage. Meaning, once a document has advanced to the next stage, it does not need to go backward and start over at the Working Draft stage.

In some TCs today, a document may go through as many as 10 or more ballots before it is finally published as a final deliverable (e.g., CS 01). With these best practices and standing rules, documents could have as few as 2 ballots before they are published. For example:

• The first ballot could be used to:

• The first ballot could be used to:
  • approve a Working Draft as CSD01
  • approve the first public review, and
  • approve all three standing rules that are covered in this document.
• The second ballot would then be used to:
  • approve the CS

This could greatly decrease voting fatigue and reduce the amount of time needed to support the
balloting process and, thus, ultimately speed up the delivery of published documents.

Appendix A – Work Product Process State Diagram

This diagram represents a simplified visual representation of how documents flow through their
lifecycle.

Appendix B – WD and CSD Numbering Examples

This appendix provides examples of in-development document numbering and storage location
as described in Section 3 with and without the use of Standing Rule 1. The examples here use the CACAO Playbook specification as an example.

B.1 Numbering Without Standing Rule 1

Development Status	Working Drafts Directory	Approved Work Products Directory
Working Draft Development	cacao-playbooks-v2.0-wd01, cacao-playbooks-v2.0-wd02, …
First CSD		cacao-playbooks-v2.0-csd01
Second CSD Development	cacao-playbooks-v2.0-pre-cs d02-yyyy-mm-dd, …
Second CSD		cacao-playbooks-v2.0-csd02

B.2 Numbering With Standing Rule 1

Development Status	Working Drafts Directory	Approved Work Products Directory
Working Draft Development	cacao-playbooks-v2.0-wd01, cacao-playbooks-v2.0-wd02, …
CSD Development		cacao-playbooks-v2.0-csd01, cacao-playbooks-v2.0-csd02, …

Introduction
OASIS Open recognizes the critical importance of preparing for unexpected events that could disrupt our operations. This Business Continuity and Disaster Recovery Plan outlines our approach to responding to and recovering from incidents that pose a risk to our operations, people, and the communities we serve.

Purpose
The purpose of this plan is to provide a structured response to incidents, minimize operational disruptions, and ensure the continuity of OASIS’s mission-critical services during and after a disaster.

Scope
This plan covers all aspects of OASIS’s operations, including but not limited to our offices, data centers, staff members, third party vendors, and technology infrastructure.

Objectives

• To ensure a rapid and coordinated response to incidents.
• To minimize the impact of disasters on our operations and services.
• To protect the safety and well-being of our staff and members.
• To facilitate the recovery of critical systems and operations.
• To communicate effectively with stakeholders during and after an incident.

Plan Activation
The criteria for activating the Business Continuity and Disaster Recovery Plan include, but are not limited to, natural disasters, significant IT failures, cyberattacks, and any other events that significantly impact our operations. The decision to activate the plan will be made by OASIS’s Executive Director.

Roles and Responsibilities

• Executive Leadership: Overall responsibility for BCDR planning and response.
• BCDR Coordinator: Leads the development, implementation, and testing of the BCDR plan.
• Department Heads: Ensure department-specific continuity plans are developed and integrated with the overall BCDR plan.
• IT Department: Responsible for implementing disaster recovery procedures for technology infrastructure.
• Communications Team: Manages all communications with staff, members, stakeholders, and the media.

Response Procedures

Initial Response

• Assess the incident and its potential impact.
• Activate the BCDR plan if necessary.
• Establish a command center for coordination.

Communication

• Notify staff, members, and other stakeholders of the incident and provide instructions.
• Keep stakeholders updated on the status of recovery efforts.

Recovery Procedures

• Implement recovery strategies for critical operations and IT systems.
• Monitor recovery progress and make adjustments as needed.

Recovery Priorities
Identify critical services and operations, along with their respective recovery time objectives (RTOs). Prioritize recovery efforts based on these objectives to ensure the most critical functions are restored first.

Testing and Maintenance

• Conduct regular tests of the BCDR plan to ensure its effectiveness.
• Review and update the plan annually or after significant organizational changes, incidents, or tests that reveal weaknesses.

Training
Provide ongoing training for OASIS staff, and as needed members, on their roles in the BCDR plan to ensure everyone is prepared to respond effectively to incidents.

Introduction
OASIS Open is committed to achieving its mission while safeguarding its members, staff, assets, and reputation against potential risks. This Risk Assessment Policy outlines our approach to identifying, evaluating, and managing risks across all areas of our operations. By implementing a structured risk assessment process, we aim to minimize the potential impact of risks on our organization and ensure the continuity of our services.

Scope
This policy applies to all aspects of OASIS’s operations and activities, including but not limited to our programs, projects, events, partnerships, and use of technology.  It covers all members, staff, third party vendors, board members, and any other individuals or entities involved in our organization’s operations.

Policy Objectives

• To identify and categorize potential risks that could affect the organization.
• To evaluate the likelihood and potential impact of identified risks.
• To develop and implement strategies to manage or mitigate risks.
• To create a culture of risk awareness and proactive risk management among all staff and members.
• To ensure compliance with legal and regulatory obligations related to risk management.

Risk Management Process

Risk Identification
Regularly identify and document potential risks that could impact the organization, including operational, financial, strategic, reputational, and compliance risks.

Risk Assessment
Evaluate the identified risks to determine their potential impact and likelihood. Use a standardized risk matrix to categorize risks and prioritize them for management.

Risk Mitigation
Develop and implement risk mitigation strategies for high-priority risks. Strategies may include avoiding, transferring, mitigating, or accepting risks, depending on their nature and potential impact.

Monitoring and Review
Regularly monitor the effectiveness of risk mitigation strategies and review the risk assessment process to ensure it remains relevant and comprehensive. Update risk assessments and strategies as necessary, especially when new risks are identified or when organizational changes occur.

Roles and Responsibilities

• Board of Directors: Oversee the risk management process and ensure that risk management practices are integrated into strategic planning.
• Executive Director: Ensure the implementation of the risk assessment policy, appointment of appropriate staff to roles as necessary, and the integration of appropriate risk management into all organizational activities.
• Governance Committee (when delegated by Board): Supervise, and receive and evaluate staff reporting of, the risk management process, including risk identification, assessment, and mitigation activities.                                                                                                                         
• All Staff: Participate in risk identification and management activities and comply with all risk mitigation strategies and procedures.

Training and Communication
Provide ongoing training and resources to staff and members to ensure they are aware of the risk management policy, understand their roles in the risk management process, and are equipped to identify and manage risks.

Policy Review and Update
This policy will be reviewed periodically or as needed to reflect changes in the organization’s operations, risk profile, or external environment.  Revisions will be made to ensure the policy remains effective and relevant.

Contact Information
For questions regarding this policy or the risk management process, please contact OASIS’s Executive Director.

Introduction
OASIS Open recognizes the importance of data security in protecting our information assets and technology infrastructure. This policy outlines the responsibilities of all users of OASIS’s information systems and networks, including staff, OASIS members, third party vendors, and any other users accessing our technology resources.  Adherence to these responsibilities is essential for maintaining the security and integrity of our systems and data.

Scope
This policy applies to all users who have access to OASIS’s information systems, networks, and data. It covers all forms of technology resources owned or managed by the organization.

User Responsibilities

General Conduct

• Secure Authentication: Safeguard login credentials and not share them with others. Use strong, unique passwords and change them regularly.
• Data Protection: Handle all data, particularly sensitive or confidential information, with care and only access data necessary for your role.
• Device Security: Ensure that any personal devices used for work purposes meet the organization’s security requirements.
• Software Updates: Keep all software, including operating systems and applications, up to date to protect against vulnerabilities.

Acceptable Use

• Internet and Email Use: Use the organization’s internet and email services appropriately and professionally, avoiding access to inappropriate websites or the transmission of offensive material.
• Prohibited Activities: Do not engage in activities that could compromise the organization’s cybersecurity, such as installing unauthorized software on the organization’s systems,, disabling security features, or participating in hacking activities.

Incident Reporting

• Immediate Reporting: Report any suspected cybersecurity incidents, phishing attempts, or security vulnerabilities immediately to the designated contact point within the organization.
• Cooperation: Cooperate with any investigations or requests for information related to cybersecurity incidents.

Compliance and Legal Obligations

• Policy Adherence: Comply with all relevant policies, procedures, and legal obligations regarding cybersecurity and data protection.
• Training Participation: Participate in cybersecurity awareness and training programs provided by the organization.

Enforcement and Sanctions
Violations of this policy may result in disciplinary action, up to and including termination of access to OASIS resources, employment or contracts, legal action, and in the case of illegal activities, referral to law enforcement authorities.

Policy Review and Update
This policy will be reviewed periodically and updated as necessary to reflect changes in technology, cybersecurity threats, and legal and regulatory requirements.

Contact Information
For questions regarding this policy or to report a security incident, please contact OASIS’s Executive Director.

This version of the OASIS Vulnerability Handling & Disclosure Policy was approved by the OASIS Board of Directors on 14 June 2023 and became effective immediately.

For details on how the policy is implemented, see the Vulnerability Handling & Disclosure Process.

Table of Contents

1. Purpose
2. Definitions
3. Procedures
3.1 Receiving a report of a possible vulnerability
3.2 Notifying OASIS staff and responsible parties
3.3 Notifying affected stakeholders
3.4 Notifying reporting organizations
3.5 Forming a vulnerability response team
3.6 Setting up a secure workspace
3.7 Addressing the vulnerability
3.8 Approving the remediation
3.9 Disclosure
3.10 Addressing vulnerability reports when there is no Responsible Party
3.11 Security Researcher Hall of Fame
3.12 Legal Obligation

1. Purpose

The OASIS Vulnerability Handling and Disclosure Policy governs how OASIS committees and staff receive and address reports of potential vulnerabilities. Vulnerability disclosure helps implementers and users of technical work assess their risk, protect their systems and data, and prioritize defensive actions. It also helps establish OASIS work product as trustworthy and legitimate in the user and developer community.

This document ensures that OASIS members understand their role in responding to reports of potential vulnerabilities or flaws and have a clear set of directions for addressing such reports. It also addresses OASIS’s role in providing neutral oversight and ensuring that records of the actions taken are maintained comparable to that done for a committee’s routine work. The policy also addresses when and how such a record should be made public.

The procedures outlined in this document may temporarily suspend other requirements of OASIS policies, most notably those for transparency and public records of proceedings.

This policy provides:

• guidelines on receiving and responding to reports of potential vulnerabilities;
• guidelines and procedures for assessing and addressing reported vulnerabilities.

2. Definitions

Most defined terms in this document have the meaning provided in OASIS Defined Terms. Additional definitions specific to the OASIS Intellectual Property Rights (IPR) Policy can be found in that document.

• Embargo period – a period of time during which a reported vulnerability is kept confidential by OASIS and the responsible party to allow a solution to be determined and disseminated to affected stakeholders.
• Executive Session – closed meetings of members of the responsible party for purposes of addressing a report of a vulnerability without making its details public.
• Flaw – synonym for “vulnerability.”
• Remediation – the steps taken by a responsible party to assess, address, and propagate a fix to a reported vulnerability or the steps to be taken by stakeholders to implement the fix.
• Responsible Party – An individual or set of individuals who ensure that the report is investigated and addressed. The Responsible Party is the person(s) in a position to make sure a response team is formed and gets the resources it needs. Generally, in the case of an OASIS Technical Committee, the Responsible Party consists of the TC Administrator, as well as the full TC led by the chair(s) of that Technical Committee. In the case of an OASIS Open Project, the Responsible Party consists of the Project Governing Board
• Stakeholders – parties whose work product may be adversely affected by the vulnerability but who are not directly responsible for fixing it (for example, a vendor whose product implements an OASIS Standard), other members of a Technical Committee beyond the Responsible Party and the response team or the public in general.
• Vulnerability – any element in a specification or technical implementation that could allow an implementation to be exploited in ways that violate its proper intended use.
• Vulnerability response team or response team – people appointed by the full membership of the responsible party to remediate the flaw. May include non-OASIS members under conditions described in the following sections.

3. Procedures

3.1 Receiving a report of a possible vulnerability

OASIS members and staff have an obligation to receive, record, and act on any report or claim of a vulnerability in any OASIS work product or deliverable that is brought to their attention, whether the flaw seems feasible or not.

OASIS will provide the OASIS Vulnerability Disclosure Process and make it accessible from the OASIS home page, and provide SEO terms to make it easily discoverable via internet search.

An OASIS member or staff may receive a report of a vulnerability in a variety of ways: through the OASIS Vulnerability Disclosure Process, through communications to or within the TC, or through personal, private communications (i.e. by email or phone). Regardless of how a report is received, the recipient must act on it.

If it is not provided in the initial disclosure, the recipient of the report should attempt to collect:

• The name, version, and a link to the standard, specification, site, package, or code module;
• If possible, the recipient’s assessment of the vulnerability severity (low/medium/high);
• Description of the vulnerability, including how it was found and if it can be exploited;
• In the case of a vulnerability discovered in a standard or specification, any known implementations of the standard or specification that the vulnerability has been discovered on;
• Steps to reproduce, if relevant and available;
• The reporters contact information (name and email), unless the reporter requests to remain anonymous.

The recipient must acknowledge receipt of the information from the reporter within 72 hours. See the Vulnerability Disclosure Process for detailed instructions.

3.2 Notifying OASIS staff and responsible parties

The recipient of a vulnerability report must notify the responsible parties for the affected specification or technical work. In the event a report is not received via the OASIS Vulnerability Disclosure Process, the recipient must either enter the report via the Disclosure Process themselves, ask the reporting party to do so, or promptly notify a member of the OASIS staff so that they can add the report. Staff will coordinate with the recipient and responsible parties on the steps needed to respond.

If the recipient is not a member of a responsible party or does not expect to be directly engaged in remediation, OASIS staff will take over working with the responsible party. The recipient must keep the report confidential but otherwise shall have no further obligations regarding the reported vulnerability.

Details of the vulnerability must not be communicated via any means that could be publicly visible (for example, by an email to a committee mailing list).

The responsible party can be notified, in a regular or specially-called meeting, or via other secure communications channels accessible only by members of the responsible party and OASIS staff.

Disclosures of vulnerabilities are not to be made public, for example in meeting minutes. If the responsible party is notified in a meeting, the meeting may be organized and held in Executive Session so that the topic and discussion are kept confidential. OASIS staff must be invited to such a meeting, and minutes must be taken although they will not be required to be published on the committee mailing list as is normally required by section 1.7 of the OASIS Committee Operations Process. The minutes must note that work was taken in Executive Session.

OASIS staff will report regularly to the Executive Director and the OASIS Board of Directors that vulnerabilities have been reported. Details may be provided in a meeting of the Board but must not be shared via any means that could be publicly visible.

3.3 Notifying affected stakeholders

As part of its evaluation of the vulnerability report, the responsible party shall decide when and how to notify affected stakeholders. Depending on the potential severity of a flaw or the scale of implementations, the responsible party may choose to alert stakeholders immediately or may choose to wait until steps to remediate have been defined. The responsible party shall make reasonable efforts to locate and notify stakeholders, however neither OASIS nor the responsible party guarantee that all stakeholders can be located and contacted.

If notification of the vulnerability includes steps for implementing a fix, the responsible party may provide an embargo period before making the report public to enable affected stakeholders to implement the fix. Neither OASIS nor the responsible party shall have any obligation to confirm that all stakeholders have implemented the fix before making the reported vulnerability public.

The decision on when and how to notify stakeholders shall rest with the Responsible Party except for the reporting provision in section 3.9. However the OASIS Executive Director or Board of Directors may direct OASIS staff to report the vulnerability publicly if, in their opinion, continued secrecy presents an unacceptable risk of damage to affected stakeholders or to the reputation and standing of OASIS. OASIS staff may review and require changes to any written communication regarding the vulnerability and its remediation prior to its being sent.

3.4 Notifying reporting organizations

As part of its evaluation of the vulnerability report, the responsible party shall decide if, when, and how to notify vulnerability databases such as the NIST National Vulnerability Database (https://nvd.nist.gov/), MITRE’s Common Vulnerabilities and Exposures (CVE® ) (https://cve.mitre.org/), or Carnegie Mellon University Software Engineering Institute’s CERT/CC Vulnerability Notes Database (https://www.kb.cert.org/vuls/). Consideration should be given to notifying relevant industry and global reporting organizations. OASIS staff will assist in the decision on request.

3.5 Forming a vulnerability response team

The responsible party shall consult with members of the committee as a whole in order to decide who shall assess the reported vulnerability to determine whether it agrees that a flaw exists.

The responsible party may request additional information, such as proof of concept code, before reaching a conclusion. If the responsible party does not agree that the vulnerability exists or believe that it poses no clear risk to stakeholders, the party shall notify OASIS staff and prepare a response to the reporter. The response shall contain an explanation of the reasons the party disagrees with the report and include a statement of how to appeal the decision to OASIS staff following the same procedures described in section 3.2 Appeals in the OASIS TC Process. The party shall store a copy of the response in its archives but no further action will be required.

If the responsible party agrees that the flaw exists, it shall notify OASIS that remedial action is needed and form a vulnerability response team made up of members deemed to have the expertise and interest to identify, analyze, correct and document the fix to the flaw.

The responsible party may invite outside experts, including the reporter of the flaw, to assist in addressing the vulnerability if it deems such expertise necessary. The party must notify OASIS staff of their request. OASIS shall offer to such invited expert a temporary, no-cost membership in OASIS for the duration of the remedial work. The invited expert shall be required to sign the OASIS Membership Agreement and take whatever actions are necessary to become a Member of the responsible party (e.g. join an OASIS Technical Committee). If the expert declines to take these actions, they shall not be allowed to participate directly in the remedial work although they may offer input and feedback via approved OASIS feedback channels.

3.6 Setting up a secure workspace

Unless the vulnerability is determined by the responsible party to be minor and quickly resolved, OASIS shall set up a secure, private team workspace. The workspace will provide all the functions of the responsible party’s regular set of collaborative tools but it will only be visible only to the members of the team and OASIS staff supporting the work. The workspace shall be visible to members of the responsible party unless such visibility cannot be provided without exposing the contents to the public.

Team members shall follow the normally applicable OASIS processes while working in the secure workspace (e.g. meeting minutes, ballots). Team members should maintain appropriate professionalism while working in the private workspace and expect that any or all of its records could become public in the future.

3.7 Addressing the vulnerability

The vulnerability response team shall work together using the secure workspace collaboration tools to identify and document changes needed to fix the affected work product(s). One member of the team shall be assigned the duty of liaison to the full committee and the responsible party and shall provide regular, verbal updates on the work.

If the response team needs copies of documentation or code for its work, OASIS shall create private copies of the resources for the use of the team. These resources shall only be accessible and visible to the team during the remediation. Changes to these resources to be applied to the existing work of the TC shall be merged back once the report of the vulnerability has been made public.

The response team shall be responsible for communicating with other stakeholders as needed, for example to communicate how to address the flaw in their implementations. The response team shall take reasonable care to keep such communications private, however neither the response team, the responsible party, nor OASIS guarantee privacy.

3.8 Approving the remediation

When the response team deems its work to be finished, it shall prepare a final report that includes the fix(es) that address the vulnerability, and present the report to the full committee and the Responsible Party. The full committee shall determine how to incorporate the fix(es) into the committee’s work products. Approval requires the appropriate level of vote for the OASIS work product the vulnerability is being reported against. For example, a vulnerability fix for an issue discovered in a Committee Specification, requires a Special Majority Vote, while a vulnerability fix for an issue discovered in a Committee Specification Draft requires a Full Majority Vote.

Once the response team’s final report is presented to the committee, its role is ended.

Merging any proposed changes into work products developed by the committee shall proceed under the normal procedures followed by the party (e.g. working drafts of Technical Committee specifications).

3.9 Disclosure

In addition to the requirements of section 3.3 and 3.4 above, OASIS staff shall, after a maximum of 90 days, make information about the vulnerability publicly accessible, unless instructed not to do so by the Executive Director or the OASIS Board of Directors or external legal authority. If permitted, the disclosure may happen sooner on appeal from any member(s) of the responsible party, stakeholder, or in response to a legitimate legal demand.

OASIS may, at its discretion, issue a press release or provide other information on the vulnerability. However, OASIS shall not be required to make any formal public announcement or release of information regarding the vulnerability.

3.10 Addressing vulnerability reports when there is no Responsible Party

In the event that the party responsible for the work affected by the vulnerability report is closed or otherwise unavailable to respond, and no other group has taken responsibility for maintenance of the work, it shall be the responsibility of OASIS staff to determine how best to respond.

Staff shall have the responsibility to identify experts who can evaluate and address the flaw. OASIS shall make best efforts to assemble a response team and address the vulnerability however OASIS shall not guarantee that it can remediate the flaw.

3.11 Security Researcher Hall of Fame

Following the processes outlined in section 3.9, OASIS will create a Security Researcher Hall of Fame page, or optionally, attach it as an addendum on the page containing the OASIS Vulnerability Disclosure Process. Any researchers who submit first-of-a-kind vulnerabilities for which the processes outlined in sections 3.6, 3.7, 3.8, and 3.9 are executed, should be listed on this page if they desire.

OASIS reserves full and final judgment on which researchers may be listed on the Hall of Fame. Researchers may be added and removed from the Hall of Fame at any time on the sole discretion of OASIS.

3.12 Legal Obligation

OASIS commits to not pursue or support any legal action related to vulnerabilities disclosed according to the OASIS Vulnerability Disclosure Process, recognizing that OASIS can not make commitments on behalf of its membership.

This version of the OASIS Vulnerability Handling & Disclosure Process was approved by the OASIS Board of Directors on 14 June 2023 and became effective immediately.

This process implements the policies described in the Vulnerability Handling & Disclosure Policy.

Table of Contents

• Process
• Researcher Requirements
• OASIS Obligations
• Scope
• Out of Scope

Process

Vulnerability reports should be reported to vulnerabilities@oasis-open.org. In the report, we request that you include:

• The name, version, and a link to the standard, specification, site, package, or code module;
• If possible, your assessment of the vulnerability severity (low/medium/high) using an industry standard mechanism such as CVSS v3;
• Description of the vulnerability, including how it was found and if it can be exploited;
• Steps to reproduce, if available;
• If possible, any suggested suggestions, fixes, and/or patches;
• How you would like to be credited (name, url or email) if this issue is accepted, or if you would prefer to remain anonymous.

Please send one plain-text email for each vulnerability you are reporting. We ask that you not submit your report using PDFs, HTML, word processor files, etc. as digital media can provide their own security concerns.

By submitting any vulnerability report to OASIS, you hereby grant to OASIS and all OASIS members a perpetual, irrevocable, non-exclusive, transferable, sub-licensable, worldwide, royalty-free license to use, copy, reproduce, display, modify, adapt, transmit, distribute, and incorporate your submission or any parts thereof into standards, products, services, or test systems, without any further obligations or notices to you beyond those described in this document or in the OASIS Vulnerability Handling & Disclosure Policy.

Researcher Requirements

We require that all researchers:

• Make every effort to avoid privacy violations, disruption or degradation of service to OASIS systems, and destruction of data during all security testing;
• Perform research only within the various scopes set out below;
• Use the identified communication channels to report vulnerability information to us;
• Maintain confidentiality of any vulnerability you’ve discovered for 45 days, or until OASIS indicates that the vulnerability has been resolved. After 45 days, if OASIS has been unable or unwilling to provide a vulnerability disclosure timeline, the contents of the Report may be publicly disclosed by the Finder. We believe transparency is in the public’s best interest in these extreme cases

OASIS Obligations

If you follow these guidelines when reporting an issue to us, we commit to follow the OASIS Vulnerability Handling & Disclosure Policy. This policy includes but is not limited to:

• Confirm receipt of your report within 72 hours;
• Recognizing that OASIS can not make commitments on behalf of its membership, not pursue or support any legal action related to your research;
• Work with you, relevant OASIS members, and, as appropriate, outside experts to understand and resolve the issue quickly if applicable, following the OASIS Vulnerability Handling & Disclosure Policy;
• If applicable and desired, to recognize your contribution if you are the first to report the issue.

Scope

The scope of works covered by this process shall be any work on any OASIS-managed platform, including but not limited to:

• The website https://oasis-open.org and all sub-properties;
• OASIS Standards and Committee Specifications published at https://docs.oasis-open.org/ and https://docs.oasis-open-projects.org;
• OASIS TC Work published at https://github.com/oasis-tcs;
• OASIS Open Repositories published at https://github.com/oasis-open;
• OASIS Open Projects published at https://oasis-open-projects.org/projects/.

Where projects already have vulnerability reporting policies or processes already in place, we encourage you to use those and consider this OASIS-wide process as a backup option.

The following test types are excluded from scope:

• Any attempt to modify or destroy data;
• Findings derived primarily from social engineering (e.g. phishing);
• Findings from applications or systems not listed in the ‘Scope’ section;
• Network level Denial of Service (DoS/DDoS) vulnerabilities or any other attempt to interrupt or degrade the services OASIS offers to its members, including impacting the ability for end users to use the service;
• Any attempts to access a user’s account or private data;
• Anything not permitted by applicable law, unless permitted by this document.

Out Of Scope

• Implementations of OASIS standards and OASIS Committee Specifications that are not included in the Scope section above, regardless of their nature, including but not limited to commercial, freely available, or open source implementations. In these cases, the report should be made to the entity or organization who produces the product or implementation;
• Any services hosted by third-party providers (which will be promptly submitted by OASIS staff to the contracted provider);
• Anything else not explicitly named in the Scope section above.

Overview of the Code of Conduct workflow for OASIS staff when receiving and responding to an incident report.

Table of Contents

1. Incident reporting and response process
2. Incident Reports
   1. What is an incident report?
   2. Who can submit a report?
   3. Where do private incident reports happen?
   4. How is the privacy of a report protected?
   5. Why does this process exist?
3. Incident report workflow
   1. Initial triage
   2. Recusal
   3. Building a plan
   4. Reaching out to involved parties
4. Incident response workflow
   1. Deciding on a Course of Action
   2. Taking Actions and Communicating our Recommendations

Incident reporting and response process

This document outlines the workflow for OASIS staff when receiving and responding to an incident report falling under the Code of Conduct. As each report is unique, the process is described at a high level.

Incident Reports

What is an incident report?

An incident report or complaint is a description of an event, interaction, or public statement submitted to OASIS staff, which the reporter feels violates the Code of Conduct.

Who can submit a report?

OASIS accepts reports from anyone who interacts in an OASIS activity (OP, TC, etc.) with the project community, contributor or otherwise. This includes, but is not limited to, the following:

• Contributors and maintainers
• Members of the community Slack instance
• Attendees and vendors at community events

Reports can be written or spoken and may be brought to any OASIS staff. OASIS must have a report to take action. At times, we may encourage community members to contact us if an incident is ongoing and we have not been contacted.

Where do private incident reports happen?

Incident reports may be made directly to any OASIS staff or sent to  code-of-conduct@oasis-open.org.

How is the privacy of a report protected?

All incident-related discussions happen in private spaces between incident reporters and OASIS staff. Staff maintain the confidentiality of incidents to the extent permitted by law.

Where incidents relate to unintentionally or non-consensually publicly-visible content or messages, we may, or may request others to, delete that content to help preserve the privacy of involved parties.

Why does this process exist?

The reporting process exists to provide the community with mechanisms to keep people safe, and to ensure that poor behavior, regardless of who the initiator is, is not accepted.

OASIS staff have the authority and responsibility to address harms as needed and appropriate to restore community safety after any incident(s).

Incident report workflow

Initial triage

OASIS staff will respond to all reports in a timely manner, usually within a few days.

When an incident report is received, it is reviewed for severity. The initial member(s) review the report and determine severity and urgency. If necessary, we may alert other members and call for an urgent meeting, but in most cases, we discuss asynchronously and develop a response plan.

Recusal

Before beginning an investigation on an incident, staff members can recuse themselves from addressing the incident if they feel a relationship with someone involved may hinder their impartiality or create a perception of impropriety with respect to individuals involved in the reported incident.

Building a plan

The staff will privately discuss the incident report and may or may not decide that we need more information prior to determining whether to take any action.

We consider the following at this stage:

• Do we need clarification from the reporter beyond the initial report?
• Do we need clarification from other individuals who may have been involved in, or witnesses to, the incident?
• Is there a public record of the incident which we can review, such as a chat log or video recording?
• Are there any privacy or safety considerations that we must take into account? For example, if we reach out to an individual named in the report, could this jeopardize the safety of the reporter or other individuals?

Reaching out to involved parties

It is our intention to put as little emotional labor on those who have been harmed as possible, and to protect the safety (both physical and emotional) of all community members. We labor to be supportive and non-judgmental and to make the reporting process as safe and low anxiety as possible.

In all instances these clarifying discussions are confidential.

Clarifying discussions typically take the form of email, Slack DM, or Zoom meeting 1:1 between a staff member selected during our triaging of an incident report and the individual from whom clarification is sought. Staff may seek to include an observer/scribe agreed by both parties.

Incident response workflow

Deciding on a Course of Action

We do not act recklessly, and in deciding on a course of action, we work as a team to include diverse perspectives, support the immediate safety needs of our community members, and support the long-term health of this community.

Our decisions on a course of action are informed by the following goals:

• Continuously working towards a community that is a safe and professional space in which individuals from any background can do their best work, authentically and free from harassment
• Preferring non-punitive punishments when possible
• Prioritizing the safety of individuals to support the overall health of the community
• Prioritizing education and coaching for those involved, when possible
• Prioritizing the protection of contributing members of a project over external parties. This does not mean that we protect people with a higher number of commits or more seniority in the project, however.

In general, the committee strives for unanimous consensus before taking an action.

For example, we may choose to do nothing, to issue a private warning, to offer coaching, to recommend organizational changes, or to ban someone from a community platform.

Taking Actions and Communicating our Recommendations

When we have decided on a course of action, we do the following:

• We clearly communicate our decision to those who need to hear it, without violating the confidentiality of those who requested it during an investigative process (if one was undertaken).
• If and only if it is needed, we may engage with OASIS leadership or outside counsel if necessary.

In rare cases, we might find it necessary to issue a public statement, either jointly or separately.

The OASIS Board of Directors approved this revised Code of Conduct on 14 June 2023 (https://www.oasis-open.org/wp-content/uploads/2023/08/OASIS-Board-of-Directors-Quarterly-Meeting-Minutes-2023-06-14-Public.pdf)

The original Code of Conduct as approved 14 October 2022 can be found at https://www.oasis-open.org/policies-guidelines/oasis-participants-code-of-conduct/oasis-participants-code-of-conduct-14-october-2022/

Table of Contents

1. Our Pledge
2. Our Standards
3. Scope
4. Enforcement
5. Enforcement Guidelines
   1. 3. Temporary Ban
   2. 4. Permanent Ban
6. Appeals

Our Pledge

We, as members, contributors, and leaders of OASIS Open pledge, act and interact in ways that contribute to an open, welcoming, diverse, inclusive, healthy, and productive community.

We pledge to do our best to ensure that participating in work at OASIS Open is free of harassment for everyone, regardless of physical, personal, professional, or cultural characteristics or disagreements about technical or policy matters.

Our Standards

Examples of behavior that contributes to a positive environment for our communities include:

• Being respectful of differing opinions, viewpoints, and experiences
• Accepting the consensus of the group after making our point if the collective decision does not go our way
• Giving and gracefully accepting constructive feedback
• Demonstrating empathy and kindness toward other people
• Accepting responsibility and apologizing to those affected by our mistakes, and learning from the experience
• Focusing on what is best not just for us as individuals, but for the overall community

Examples of unacceptable behavior include, but are not limited to:

• Personal (ad hominem) attacks that emphasize the speaker rather than the message
• Refusal to allow orderly statements of opposing points of view, within the reasonable time boundaries of group meetings or shared communication channels
• The use of sexualized language or imagery, and sexual attention or advances of any kind
• Trolling, insulting or derogatory comments
• Public or private harassment
• Publishing others’ private information without their explicit permission
• Other conduct which could reasonably be considered inappropriate in a professional setting
• Disparaging an organization, its activities, its employees, or its products and services within the context of OASIS-related activities
• Promoting specific commercial or competitive solutions or products, to the exclusion of others. OASIS committees, boards and groups are intended to promote interoperability among multiple, independent implementations and services. In addition to members’ obligations under the OASIS Antitrust Guidelines, it is out of order for OASIS activities to express preferences for an exclusive or pre-emptive single solution, or to preferentially host or endorse a specific solution’s promotional statements. Any testing activities must be inclusive, based only on objective, functional criteria, without reference to a single product.

Enforcement Responsibilities

OASIS staff are responsible for clarifying and enforcing our standards of acceptable behavior and will take appropriate and fair corrective action in response to any behavior that they deem inappropriate, threatening, offensive, or harmful.

The chairs and conveners of OASIS committees, boards and groups are empowered to run their meetings, according to our applicable process rules, and to make reasonable agenda and speaking order decisions to facilitate those meetings.  However, those chairs and conveners should seek assistance from OASIS staff when significant or repetitive inappropriate behaviors as described in this Code are encountered.

OASIS staff have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, and will communicate reasons for moderation decisions when appropriate. Staff may also take action to sanction behaviors that it judges to be in violation of this code of conduct, up to and including expelling individuals from a project if, in their judgment, the circumstances warrant it.

Decisions or actions by OASIS staff are subject to appeal to the OASIS Board of Directors.

Scope

This Code of Conduct generally applies to the actions of individuals. It applies both within online spaces and in public spaces when an individual is participating in or representing the project or its community. Examples include using an official project e-mail address or mailing list, posting via an official social media account or chat, participating in a project meeting, or representing the project or OASIS at an online or in-person event.

What are the boundaries of the OASIS community?

There are no hard boundaries of the community, but common places we are asked to extend guidance to are:

• Official project communication channels
• Events and meetups
• Media and web presences
• Social media

In some cases, where individual social media messages or other activities not related to a specific project are reported to the OASIS staff as violating this Code, we might choose to act.

Enforcement

Instances of abusive, harassing, or otherwise unacceptable behavior may be reported to the OASIS staff at code-of-conduct@oasis-open.org. All complaints will be reviewed and investigated promptly and fairly and in confidence and will result in a response that is deemed necessary and appropriate to the circumstances. All parties involved in an incident are obliged to maintain confidentiality with regard to the reporter and the accused. Further details of specific enforcement policies may be posted separately.

All community leaders are obligated to respect the privacy and security of the parties involved in the incident.

Enforcement Guidelines

OASIS staff will generally follow these Community Impact Guidelines in determining the consequences for any action they deem in violation of this Code of Conduct, though they may escalate more quickly if the circumstances appear to warrant it:

1. Correction

Community Impact: Use of inappropriate language or other behavior deemed unprofessional or unwelcome in the community.

Consequence: A private, written warning from OASIS staff providing clarity around the nature of the violation and an explanation of why the behavior was inappropriate. A public apology may be requested.

2. Warning

Community Impact: A violation through a single incident or series of actions.

Consequence: A warning with consequences for continued behavior. No interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, via any OASIS-provided or maintained mechanism (ie email lists, Github, Slack, etc.) for a specified period of time. This includes avoiding interactions in community spaces as well as external channels like social media. Violating these terms may lead to a temporary or permanent ban.

3. Temporary Ban

Community Impact: A serious violation of community standards, including sustained inappropriate behavior.

Consequence: A temporary ban from any sort of interaction or public communication with members of the community via any OASIS-provided or maintained mechanism (ie email lists, Github, Slack, etc.) for a specified period of time, not to exceed one month. No public or private interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, is allowed during this period. Violating these terms may lead to a permanent ban.

4. Permanent Ban

Community Impact: Demonstrating a pattern of violation of community standards, including sustained inappropriate behavior, harassment of an individual, or aggression toward or disparagement of classes of individuals.

Consequence: A permanent ban from any sort of interaction within the community. Removal from community tools like repositories or chat groups.

Appeals

Actions taken by staff under this policy may be appealed to the OASIS Executive Director and the Board of Directors.

An appeal must be sent to the board comment list (oasis-board-comment@lists.oasis-open.org) within 30 days of the action being appealed. The Board shall hold a hearing within 45 days of receipt of the appeal. The Board shall render its decision within 30 days of the hearing. The decision of the Board shall be final.

The OASIS Board of Directors has the authority to effect such remedial action as may be necessary to remedy a complaint.