Copy of Gov1: OpenXT Project Governance Charter [ DRAFT ] [ xtopher-v2 ]

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.
    
• 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.
  
• 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.
  

RJP so this section replaces the Project Charter? I can't remember the details of our discussions about that part. Also I thought there was another up front section that Rich had done that is missing. Maybe I am confused.

Project Platform

Platform Properties

The list of important properties of the OpenXT Project Platform that are subject to governance supervision is maintained in a separate document: OpenXT Platform Properties.

Layers

The OpenXT Project software utilizes the composable software layers provided by OpenEmbedded in order to isolate customizations, such as hardware, GUI environments and distributions. The OpenXT layers create modular governance contexts for specific use cases, target markets and operational models, with a narrowed set of stakeholders and increased prospects of stakeholder alignment within individual layers.

The OpenXT Project applies the layering mechanism to support the coexistence of multiple use cases within a common codebase. This enables maximization of collaboration on common components while also enabling non-aligned stakeholder requirements to be satisfied in different layers.

Base Platform Layer:

• OpenXT Core Platform

Proposed Optional Layers:

• Switching display and input (surfman) layer <<To do: Link to the RFC for this layer here when ready>>
  
• Compositing display and input (Qt) layer <<To do: Link to the RFC for this layer here when ready>> 
   

<< AIS are working on a document describing layers. >>

RJP have emailed persons involved to get status on this

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, not more than two weeks distant from the intended calculated date, may be appointed instead by the Governance Board.

The Community Conference Call is public and open to all members of the OpenXT community.

RJP I guess we still have not really defined what a community member is. There was some discussion on this in another email thread (spi reference material).

Notification of the Community Conference Call shall be sent by a member of the Governance Board 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.

Project Governance Board

The OpenXT Project shall have a Governance Board of seven appointed individuals.

This body shall represent the interests of parties involved in the OpenXT Project as well as the interests of the OpenXT platform itself.

The Board is responsible for:

• Ensuring that decision making is effective within the project
  
• Acting as the decision maker of last resort
• Setting the project charter
  
• Driving project activities in pursuit of project goals derived from the charter

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, where lazy consensus is not achievable via community dialogue, the mailing list RFC process and monthly community call. 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.

Board Formation

An initial body of a seven individuals will be formed by community agreement.

Board members are appointed as individuals, not as representatives of their employers; companies do not own seats. Individuals are appointed for their expertise.

Changes to the Board

<<This subsection needs to be reviewed.>>

A Board member will be required to step down from their position in any of the following circumstances:

• The Board member expresses a request to the Governance Board to retire from the position, where this request is issued by cryptographically signed email to the Project mailing list.
• The Board member is absent from Governance Board decision making for a period of two months where at least three decisions have been required of the Board in that period. RJP I think there should be provisions for extenuating circumstances here, e.g. someone is in an accident, has a serious personal problem and is on sabbatical. Perhaps we can have a provision for a stand in/temporary board member for things like this?
• The remainder of the Board unanimously agrees that sufficient cause exists for removal, acting in the best interests of the Project.

Vacancies on the Board shall be filled by a public vote of the majority of the remaining members of the Board. The vote shall be held within two weeks of the vacancy occurring. RJP so what happens if the vote cannot be done in two weeks - does the project just end?   

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.

Responsibilities of the Board Members

<<This subsection needs to be reviewed.>>

The members of the Governance Board are required to:

• 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.

   RJP format
• Participate in the Decision Process, the Voting Process and in Changes to the Board. RJP perhaps this section should come before or after all the sections it mentions instead of in the middle of said...

At least one member of the Governance Board shall be appointed and be required to:

• Send timely notifications of the upcoming Community Call to the mailing list.
• Manage the selection of an alternate date for the Community Call when the regular schedule falls upon a legal holiday.
  
• RJP meeting minutes?

Decision Process

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.

Action by the Governance Board is initiated by any member of the community creating an OpenXT JIRA ticket to fully describe the issue that needs resolution. All activity concerning the resolution process will be tracked in the ticket. When a resolution of some form is reached, it will also be entered into the ticket. When the decided upon resolution is enacted, the ticket shall be be closed. This leaves a concrete information trail on exactly what transpired and what the resolution ultimately was.

<< To be specified: Timetable for action by the Board from the first opening of the JIRA ticket to either i) a concluding resolution or ii) a determination that a Vote will be held. >>

RJP another tough time bound rule like the voting an new member above - we may need to figure out a way to address these with some best effort verbiage. If these things do not happen when this document says they MUST happen, then what?

 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

A vote will be required if consensus on the decision resolution is not achieved between members of the Governance Board in the Decision Process. Voting can commence when any member of the Governance Board believes it is appropriate. Voting shall be required to commence once the maximum time period allowed for the Decision Process has elapsed without achieving consensus on a concluding resolution. The start of the Voting Process must be indicated on the JIRA ticket which will serve as the official record of when the Voting Process began.

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 not be done by proxy (RJP that probably needs more detail since it is unclear to me how that works). The records of all the votes will be recorded in the JIRA ticket.

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 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. RJP same comments as above. Maybe we should have a section specifically on what happens when deadlines are not met.

Additional Project Roles

Repository Maintainer, Source Code Committer

• Monitors 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.

• Monitor mailing list postings that are relevant to RFCs and Pull Requests.

System Administrators

• JIRA and Confluence
  
• Github
• Google Groups
  
• << To do: Add more here and outline role responsibilities of each>> 

Amendments to this Governance Document and Board Structure

Changes may be made by the following process:

1. Collect and understand the perspectives of affected stakeholders.
2. Send a written RFC to the OpenXT mailing list.
3. Discuss the RFC on the monthly OpenXT community call.
4. Publish revised RFC to the mailing list.
5. Finalize and accept the RFC on the next community call.
6. If consensus exists on the list/call, one Board member (other than the proposer) records the decision and consensus in a JIRA ticket.
7. If no consensus on the list/call, the proposer escalates the decision to the Board via JIRA ticket. The Board uses the "Decision Process" defined in this document.

Governance Board

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.

1. Board Member Not Determined at this time
2. Board Member Not Determined at this time.
3. Board Member Not Determined at this time.
4. Board Member Not Determined at this time.
5. Board Member Not Determined at this time.
6. Board Member Not Determined at this time.
7. Board Member Not Determined at this time.

License of this Governance Document

Revision History of this Governance Document

Revision 1: A draft revision presented at the OpenXT Community Call on 17th March 2016.

Revision 2: A draft revision in-progress.