Governance

A community forms around a shared interest, but a healthy and large community will inevitably have to manage divergent or competing goals. For example, in this community we have operators for software from multiple competing vendors, with products that are direct substitutes. It is in all of our interests to deliver both highest–quality experience for the individual products, and multi-vendor interoperability and substitution.

Governance ensures that understandable tensions are resolved productively. In general, we lean towards ownership over committee, because doing the work earns the right to decide how best it should be done. Where there are significant questions that touch on multiple contributors, we encourage them to work out a constructive common ground, and we offer an escalation path to resolve matters that do not reach quick consensus.

Code of Conduct

We follow the Ubuntu code of conduct to create an environment which is both expert and friendly. We aim for meritocracy, which means we want the best person or team responsible for something and empowered to get it done the way they think best, subject only to a broad requirement of interoperability and best practices.

Operator Names

An operator called ‘foo’ should operate the workload that most people will expect if you mention ‘foo’. This is the principle of least surprise. We prefer the workload upstream be given the opportunity to lead its operator in this collection, but will occasionally empower a different maintainer, more focused on this work or more familiar with our community.

Contributors

Anybody may contribute to operators and shared code such as the Python Operator Framework or endpoint libraries, but they must only contribute code they have the right to share, and they must follow our code of conduct in all communications on the site or the subject matter of the site.

Maintainers

We require that a specific person is designated the maintainer of an operator. That person should be willing to be named, and responsive to questions, comments, bug reports and pull requests for the operator. It is good practice – but not required – for the maintainer to run a public version control repository where the operator code can evolve following the normal practices of open source, even if the repository is not under an open source license.

Maintainer Board

The three members of the Maintainer Board are selected by the current Open Operator Collection Maintainers for a single year term in a scored vote election for which there must be at least four candidates, each nominated by a current Maintainer. The Maintainer Board determines operator maintainers based on their level of engagement with both the underlying workload and the work of the Open Operator Collection.