OpenXT Governance - Original

Governance 2016 - Introduction

There have been a number of governance proposals at different times (some public, some not). While they all seem reasonable, they all also seem too complex for what we really want and need today in the currently small OpenXT community. What will be presented here is a slimmed down approach to cover mainly what we need as of today. This does not mean we cannot expand our governance model in the future.

Currently we have a process in place for the OpenXT project. Please review the OpenXT Process - Historical which outlines how things are currently done (in 2016 and earlier). There are cases where technical issues arise that the current process cannot handle or resolve. This initial minimal governance model's main goal is to address this problem and to in effect boot-strap governance in general on the OpenXT project.

Initial Governance Model

Technical Advisory Board

An initial body of an odd number of individuals will be formed by community agreement. This body represents the interests of parties involved in the OpenXT project as well as the interests of the OpenXT platform itself. The exact number is variable but initially it should be somewhere between 5 and 9 individuals. This body will effectively form a Technical Advisory Board that will make decisions regarding technical issues that impact OpenXT and cannot be easily resolved by the existing process. The exact nature of the resolution may vary widely on a case by case basis. These are some examples just to illustrate that it is not just a yes/no vote.

• The board votes to accept/reject a proposed feature or change in OpenXT.
• 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 defers to an outside expert or agency that can better evaluate and make recommendations.

Decision Process

Action by the Technical Advisory Board will only be invoked in the situation where no resolution to a technical matter can be reached using the existing process and informal discussions. Action is initiated by creating a JIRA ticket to fully describe the technical 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 can be closed. This leaves a concrete information trail on exactly what transpired and what the resolution ultimately was.

Part of the decision process will involve voting. This will be done with a simple +1 or -1 vote by each member. Any member can elect to abstain from voting for whatever reason public or private (which is a vote of 0). Voting can commence when a majority of the Technical Advisory Board believes it is appropriate. The results of the vote will be recorded in the ticket.

In cases where members cannot participate because they are indisposed for whatever reason or when voting is tied, the Technical Advisory Board will have to make a best effort attempt at determining how to proceed.

Scope of Mandate

The scope of what the body is mandated to make decisions on is limited to technical issues impacting OpenXT that cannot be resolved using the existing process. If the scope of this mandate needs to be expanded at a future date, this governance model will need to be altered with input and participation from the entire OpenXT community.

OpenXT Governance and Process

The end result in 2016 will be the realization of an OpenXT Governance and Process model that is based on the initial governance model described above and the existing process that is currently in place for OpenXT (again see OpenXT Process - Historical). This is a starting point and the model will grow and evolve over time as the community grows and changes.