| Info |
|---|
DRAFT |
| Table of Contents |
|---|
Introduction
The OpenXT Project requires consensus on an extensible systems innovation platform, to enable derivative products to make assurances for diverse markets and use cases. This document records principles to guide decisions within the OpenXT Project. Stakeholders are expected to fairly interpret this document and to objectively apply the principles for the benefit of the OpenXT Project and all contributors.
Project Purpose
- To support, provide, enable and promote collaboration on the development of the OpenXT Platform, that is:
- An Open-Source software development toolkit for use on modern hardware.
- An integrated body of software that provides virtualization technology with high assurance security properties that are rooted in the platform hardware.
- A collection of modular, composable software components that can be used by derivative projects as a basis to extend upon and target to their use cases.
- To organize, hold and conduct meetings, discussions and forums on issues relevant to the development of the OpenXT Platform.
- To engage with upstream software projects and contribute developments with the dual aims of increasing the use of OpenXT technologies and decreasing the specialization of OpenXT.
- To foster work that raises the security capabilities of the OpenXT Platform and upstream projects.
- To ensure that the OpenXT Current Use Cases are satisfied and the OpenXT Platform Properties are maintained by the project Platform and are satisfied via the OpenXT Platform Architecture.
- To actively pursue additional Use Cases where the OpenXT technology is relevant and the attraction of additional contributors would follow from adding support for a new Use Case.
Project Platform
...
- Compatibility with modern hardware and operating systems.
- Loose Coupling of components, including open-source and proprietary.
- Verifiable Measurements of hardware and software.
- Verified Launch of derived works.
Further detail is
...
provided in the
...
...
OpenXT Platform Layers
The OpenXT Project uses composable software layers provided by OpenEmbedded, to isolate customizations such as hardware, GUI environments and Linux distributions.OpenXT Platform Layers provide smaller governance contexts for use cases, target markets and operational models within a common codebase. Layers narrow the set of stakeholders and increase alignment, while increasing the adoption of core platform components.
All OpenXT Platform Layers are subject to OpenXT Governance as defined in this document. Layer creation and changes can be proposed via the "Project Changes" process defined in this document.
Derivative Works
...
document.
...
Project MeetingsThe OpenXT
Project
...
The Community Conference Call is public and open to all members of the OpenXT community.
Notification of the Community Conference Call should be sent to the mailing list at a time between one week and one day prior to the call. The Notification shall include the timing of the call and the telephone access information for the call.
The Community Call will be hosted by a member of the OpenXT community.
...
Governance Board
The OpenXT Project shall have a Governance Board of seven appointed individuals.
...
This body will form a decision making authority to resolve issues that impact OpenXT and arrive at decisions on behalf of the whole community that cannot be easily resolved by the Pull Request process.
Scope of Mandate
The Board may issue a binding resolution on any decision which affects the OpenXT software platform, shared resources or development practices, Project, where lazy consensus is not achievable via community dialogue, the mailing list RFC process and monthly community call. The scope of this decision-making authority includes but is not limited to:
- Platform Properties and Layers
- Project Assets
- Project Process and Workflow
- Project Governance
Changes to the composition of the Governance Board and to the Governance Documents can be proposed via the Board and Governance Changes Process defined in this document. All other changes can be proposed via the Project Changes process defined in this document.
Board members are expected to fairly interpret this document and to objectively apply the documented principles for the benefit of the OpenXT project and all contributors. The
Board
...
Formation
An initial body of a seven individuals will be formed by community agreement.
...
Board members accept the responsibility of actively building consensus within the community.
Board Member Responsibilities
The members of the Governance Board are required to:
Attend the monthly Community Call.
Provide guidance and direction to project contributors on how to address challenges presented by proposed changes in order to seek solutions that are acceptable and desirable to all the project stakeholders and in alignment with the OpenXT Project Purpose.
Participate in the Consensus Building Process, the Voting Process, Changes to Governance and Changes to the Board.
- Ensure that OpenXT Project decisions are recorded.
For each Community Call at least one member of the Governance Board shall:
- Ensure that minutes are taken for each Community Call meeting, and
- Send the minutes of the meeting to the mailing list, and
- Archive a public copy of the minutes to the project wiki.
Board and Governance Changes
This diagram illustrates the process for changes to the composition of the Governance Board. The same process is also required to be followed for changes to the Project Governance Documents.
Proposed changes must be described in a Request For Comment (RFC) document that is posted to the Project mailing list.
Board Changes
The legitimacy of the Board and its decisions depends upon the composition of the Board reflecting the balance of stakeholders within the OpenXT Project.
The Board shall endeavour to ensure that sufficient technical expertise and capacity for sound judgement is present among the constituent members of the Board to enable efficient and effective decision making in the best interests of the Project as guided by the Project Purpose.
A Board member may retire from their position on the Board by expressing a request to do so to the Governance Board. Such a request should preferably be issued by cryptographically signed email to the Project mailing list.
...
Vacancies shall be filled by a unanimous appointment by the remaining members of the Board with a formal notification to the mailing list and revision of this document to record the appointee.
Governance Changes
The same process for approving proposed changes to the composition of the Governance Board also applies to proposed changes to the Governance Documents: unanimous approval of a public RFC by the Governance Board is required.
Project Changes
The Board will assist the community by providing guidance and recommendations on direction of work that will increase the potential for consensus to be obtained to accept technical changes within the project.
Proposed technical changes will be described in Request For Comment (RFC) documents. RFC documents for technical changes should adhere to the template for these established within the project.
This diagram illustrates the decision making process for change proposals.
Consensus Building Process
("Board to build consensus by working with the community" stage in the above Project Changes diagram)
Action by the Governance Board will only be invoked in the situation where no resolution to a technical matter can be reached using the process of interaction with the repository maintainers and informal discussions.
...
Members of the Governance Board will seek to build consensus within the community regarding the issue. Means available to the Board include, but are not limited to, the following:
- Collect, understand, interpret and convey the perspectives of affected stakeholders.
- Bilateral conversations between affected parties or community members with differing positions.
- Telephone calls, face-to-face meetings if possible.
- Mailing list discussions, JIRA ticket interactions, IRC channel communication.
- Informal consultation.
- Group discussions on the Community Call.
The exact nature of a Board decision resolution may vary widely on a case by case basis. Illustrative examples include:
- The Board decides to request more information regarding a submission or RFC before further consideration.
- The Board decides to request an alteration to a submission or RFC before further consideration or as criteria for acceptance.
- The Board requests information from an outside expert or agency that can perform an evaluation, provide context and make recommendations to guide decision making.
- The Board votes to accept/reject a proposed feature or change in OpenXT. This is a method of resolution of last resort: other approaches should be exhausted before a vote is required.
Voting Process
("Board votes" stage in the above Project Changes diagram)
A vote will be required if it becomes clear that consensus on the decision resolution cannot be achieved between members of the Governance Board in the Consensus Building Process. The purpose of the Voting Process is to document the positions of the Board members and record the concluding decision for the proposal.
...
Voting will be done with an indication of "yay", "nay" or "abstain" by each Board member. Each Board member is granted a single vote. Any member can elect to vote "abstain" without a requirement to provide a reason. Absent board members who do not provide a vote will be recorded as "absent". Voting may be done by proxy. The records of all the votes will be recorded in the JIRA ticket. If the RFC was proposed by a Board Member, a different Board Member must record the vote.
When voting is tied due to absent or abstain votes, the non-absent and non-abstaining members of the Governance Board will make a best effort attempt at determining how to proceed.
The board members are strongly encouraged to provide comment on the JIRA ticket with reasoning in terms of the OpenXT Platform Properties, OpenXT Platform Architecture and OpenXT Platform Security Architecture with each vote.
The Voting Process is required to conclude within two weeks of a vote being called, as determined by the metadata of the JIRA ticket. The Vote is considered final when the maximum time period has elapsed or when all votes have been accounted for, whichever is the earlier.
Board Member Responsibilities
The members of the Governance Board are required to:
Attend the monthly Community Call.
Provide guidance and direction to project contributors on how to address challenges presented by proposed changes in order to seek solutions that are acceptable and desirable to all the project stakeholders and in alignment with the OpenXT Project Purpose.
Participate in the Consensus Building Process, the Voting Process and in Changes to the Board.
- Ensure that OpenXT Project decisions are recorded.
For each Community Call at least one member of the Governance Board shall:
...
Additional Project Roles
A public process for appointing community members to these additional project roles shall be established and revised when necessary by using the Project Changes process described in this document.
Repository Maintainers, Source Code Committers
Repository Maintainers, Source Code Committers are the gatekeepers, managers and performers of updates to the canonical copies of the project software source code.
Appointment of Repository Maintainers, Source Code Committers
TBD. (FIXME)
Changes to Repository Maintainers, Source Code Committers
TBD. (FIXME)
Responsibilities of Repository Maintainers, Source Code Committers
- Implements OpenXT Project decisions as recorded by the Board.
- Seek discussion of significant proposed changes that require consensus by the Community.
Monitor mailing list postings that are relevant to RFCs and Pull Requests and reply when appropriate.
Monitor the repositories for Pull Requests and comments and engages with them.
- Apply the Pull Request Process and perform the actual approval or rejection actions of PRs to the source code repositories.
System Administrators
System Administrators maintain and manage the project infrastructure systems, such as group email lists, hosting of source code repositories, defect tracking systems, etc.
- JIRA and Confluence
- Github
- Google Groups
- << To do: Add more here and outline role responsibilities of each>>
Governance Document and Board Structure Amendments
Changes may be made by the following process:
- Collect and understand the perspectives of affected stakeholders.
- Send a written RFC to the OpenXT mailing list.
- Discuss the RFC on the monthly OpenXT community call.
- Publish revised RFC to the mailing list.
- Finalize and accept the RFC on the next community call.
- If consensus exists on the list/call, one Board member (other than the proposer) records the decision and consensus in a JIRA ticket.
- If no consensus on the list/call, the proposer escalates the decision to the Board via JIRA ticket. The Board uses the "Consensus Building Process" defined in this document.
...
Responsibilities of System Administrators
- Implement relevant OpenXT Project decisions as recorded by the Board.
- Seek discussion of significant proposed system changes that require consensus by the Community.
Monitor mailing list postings that are relevant to the administered systems and reply when appropriate.
Monitor the administered systems for community interactions and engage with them.
- Perform system administration actions in a timely fashion, including actions to ensure the continued availability and integrity of the systems.
Derivatives and Compatible Works
Derivative Works may include or modify OpenXT Platform Components, relying on OpenXT Platform Properties to make assurances for diverse markets and use cases. Derivative Works are developed and governed independently of the OpenXT Project. Developers of Derivative Works can propose technical changes to the OpenXT Platform using the process defined by Project Changes in this document.
Compatible Works use OpenXT Platform Properties to make validated assurances. A list of Compatible Works and their validated assurances will be published in OpenXT Project documentation. Compatible Works are developed and governed independently of the OpenXT Project. Developers of Compatible Works can propose technical changes to the OpenXT Platform using the process defined by Project Changes in this document.
Appointed Governance Board Members
This section shall contain the names of the current Governance Board. It shall be modified to contain the names of new board members when necessary and shall not require a vote beyond the approval of the resolutions appointing the board members.
- Board Member Not Determined at this time
- Board Member Not Determined at this time.
- Board Member Not Determined at this time.
- Board Member Not Determined at this time.
- Board Member Not Determined at this time.
- Board Member Not Determined at this time.
- Board Member Not Determined at this time.
Project Meetings
The OpenXT Project shall hold monthly telephone Community Conference Call meetings on the third Thursday of every month at 4pm UTC. If the date of the call falls upon a legal holiday then an alternative date may be selected.
The Community Conference Call is public and open to all members of the OpenXT community.
Notification of the Community Conference Call should be sent to the mailing list at a time between one week and one day prior to the call. The Notification shall include the timing of the call and the telephone access information for the call.
The Community Call will be hosted by a member of the OpenXT community.
License of this Governance Document
| Info | ||
|---|---|---|
| ||
Copyright 2016 by individual contributors. This work is licensed under the Creative Commons Attribution Non-Commercial Share-Alike 4.0 International License. To view a copy of this license, visit https://creativecommons.org/licenses/by-nc-sa/4.0/. |
Revision History of this Governance Document
Document authors: Christopher Clark, Ross Philipson and Rich Persaud.
...
Revision 2: Revisions by: Christopher Clark, Ross Philipson and Rich Persaud. A second draft revision to be presented at the OpenXT Community Call on 21st April 2016.
Revision 3: Revisions by: Christopher Clark, incorporating community feedback. A third draft to be presented at the OpenXT Community Call on 19th May 2016.